From owner-ospf@PEACH.EASE.LSOFT.COM Tue Sep 2 14:32:59 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24723 for ; Tue, 2 Sep 2003 14:32:58 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00B2FB02@cherry.ease.lsoft.com>; Tue, 2 Sep 2003 14:33:00 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 53548083 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 2 Sep 2003 14:32:55 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 2 Sep 2003 14:32:55 -0400 Received: from redback.com (pptp-6-157.redback.com [155.53.6.157]) by prattle.redback.com (Postfix) with ESMTP id DEC1985C000 for ; Tue, 2 Sep 2003 11:31:21 -0700 (PDT) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3F47A2B0.6020808@redback.com> <001301c36e50$d2949de0$cbc8c8c8@sdksoft.com> <3F4F9310.7000300@redback.com> <003701c36e58$747e0860$cbc8c8c8@sdksoft.com> <3F4FDAED.7020504@redback.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F54E1F3.9020907@redback.com> Date: Tue, 2 Sep 2003 14:31:15 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: DB Synchronization To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3F4FDAED.7020504@redback.com> Precedence: list Content-Transfer-Encoding: 7bit If the everything matches between restarts (type, LS ID, advertising router, initial sequence number, and checksum) , I don't see any solution in the base protocol specification. However, a router performing graceful restart will initially accept it's pre-restart LSAs. Hence, when graceful restart terminates the restarting router will originate a new LSA and purge the stale one. Rikki Nguyen wrote: > You seem to be correct. I missed the part about the netmasks. > The zero and negative-zero (0xff) has the same affect on > the checksum, hence they end up being the same. I don't see > any other way of correcting this besides forcibly sending > LS-Requests for self-originated LSA's. > > Parag Deshpande wrote: > >> I ran a small program with the following values - >> >> In this case the checksums are always the same! because >> m1 & m2 are multiple of 8. >> m1= 16 m2 = 24. ( also 8, 32) >> >> CK_SUM({00, 00, 00, FF}, 4) = CK_SUM( {00,00,FF,FF}, 4) >> = CK_SUM( {00,FF,FF,FF}, 4) = CK_SUM( {FF,FF,FF,FF}, 4) >> = 0xFFFF >> >> (It does not matter what N1 is) >> >> Or I am goofing up somewhere :-) >> >> Parag >> >> ----- Original Message ----- >> From: Rikki Nguyen >> To: >> Sent: Friday, August 29, 2003 12:53 PM >> Subject: Re: DB Synchronization >> >> >> >>> Parag Deshpande wrote: >>> >>>> Hi, >>>> >>>> I had a doubt -> >>>> >>>> 2 routers A and B have an ospf adjacency. >>>> >>>> Router A sends an ASExt lsa for network N1/m1 with LSID = N1. >>>> Then Router A goes down & comes up again & reoriginates >>>> ASExt lsa for network N1/m2 with LSID = N1 and then >>>> gets adjacent with Router B. >>>> >>>> **where m1 != m2 & they are multiple of 8. (/8, /16..) >>>> also assuming that all other parameters are same. >>>> >>>> However in this case the DB Exchange will fail to >>>> synchronize these LSAs bcoz they appear >>>> to be similar- LSID, SeqNum, Checksums being equal** >>>> and thus will have to wait for the LSA to get refreshed. >>> >>> >>> The checksum is computed over the entire LSA body, >>> this includes the netmask. Since the netmasks are >>> different, it would be difficult for the checksum >>> to be the same. >>> >>> >>>> I was wondering whether this can be resolved faster. >>>> >>>> Thanks >>>> Parag >>>> >>> >> > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Sep 4 10:49:09 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28143 for ; Thu, 4 Sep 2003 10:49:09 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00B3B9AA@cherry.ease.lsoft.com>; Thu, 4 Sep 2003 10:49:12 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 53822445 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 4 Sep 2003 10:49:10 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 4 Sep 2003 10:39:09 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27263; Thu, 4 Sep 2003 10:39:03 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200309041439.KAA27263@ietf.org> Date: Thu, 4 Sep 2003 10:39:03 -0400 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-bhatia-manral-diff-isis-ospf-00.txt Comments: cc: isis-wg@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IS-IS and OSPF Difference Discussions Author(s) : V. Manral, M. Bhatia Filename : draft-bhatia-manral-diff-isis-ospf-00.txt Pages : 42 Date : 2003-9-4 The increasing popularity of IS-IS [IS-IS] and OSPF [OSPF] over the years has drawn significant attention to the relative merits and de-merits of one with respect to the other. This draft presents an elaborate comparison between the two routing protocols to explain how the features and functionalities of one differs from the other. Wherever applicable the differences between OSPFv2 and OSPFv3[OSPFv3] have also been pointed out. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bhatia-manral-diff-isis-ospf-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-bhatia-manral-diff-isis-ospf-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-bhatia-manral-diff-isis-ospf-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-4095456.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bhatia-manral-diff-isis-ospf-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-bhatia-manral-diff-isis-ospf-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-4095456.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Sep 4 17:04:34 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22400 for ; Thu, 4 Sep 2003 17:04:33 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00B3DC6B@cherry.ease.lsoft.com>; Thu, 4 Sep 2003 17:04:34 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 53876288 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 4 Sep 2003 17:02:08 -0400 Received: from 207.217.120.232 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 4 Sep 2003 17:02:08 -0400 Received: from user-38ldvul.dialup.mindspring.com ([209.86.255.213] helo=earthlink.net) by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19v1F0-0004qL-00 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 04 Sep 2003 14:02:06 -0700 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <200309041439.KAA27263@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3F579AA2.3C229B36@earthlink.net> Date: Thu, 4 Sep 2003 13:03:46 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: A: Re: I-D ACTION:draft-bhatia-manral-diff-isis-ospf-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit This is going to be a multiple part comment, A) nits 1) Abstract [IS-IS] -> Has no item specified in References 2) 1. Terminologies End System - Host --> End System (ES) - Host Intermediate System - Router ---> Intermediate System (IS) - Router Need something to specify that IS-IS uses the L1 and L2 to specify Level 1 and Level 2 respectively. 3) References What are those strange characters? See [Martley], [Mesh], [OOB], [TUNNEL], 4) 8. Checks on ... atleast --> at least ------- B) Technical comments 1) 6.1 DR election deterministic.. is sticky meaning --> is somewhat sticky because after the wait time has expired and a router has been elected, it tends to stay in that elected position. The reason that it is not fully stiicky is that if a elected router is added to a interface because of area merging, a DR will be selected from the two routers. This behaviour is specified in the OSPF RFCs. 2) 7. Areas / Hierarchy There is a mixture of Level and L usages... You should probably pick one and stay with it. IS-IS - Routers are identified as L1, or L2, or L1/L2 routers. OSPF - Divides the routing domain into multiple area types. - The backbone area, area 0.0.0.0 or 0, is used to send packets from one non-backbone area to another non-backbone area. 3) MTU Limitations OSPF Add - When the MTU values differ between routers, IP protocol allows the configuration to support non-fragmenting of packets that are greater than MTU size and can result in the complete loss of packets. - When a packet is sent that is greater than MTU size and congestion occurs or is approaching (random early discard) within the internet, some implementations will drop these larger packets first. - When a packet is sent that is greater than MTU size, the loss of any part of this fragment will cause the complete packet to be resent. - Some vendors support disabling the MTU mismatch detection that would allow the adjacency to attempt to form. - Please note that MTU mismatch is one of a number of causes that can cause an adjacency to be stuck in exstart. One example could be duplicate router-ids. Mitchell Erblich Sr Software Engineer --------------------------- Internet-Drafts@IETF.ORG wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : IS-IS and OSPF Difference Discussions > Author(s) : V. Manral, M. Bhatia > Filename : draft-bhatia-manral-diff-isis-ospf-00.txt > Pages : 42 > Date : 2003-9-4 > > The increasing popularity of IS-IS [IS-IS] and OSPF [OSPF] over > the years has drawn significant attention to the relative merits > and de-merits of one with respect to the other. This draft presents > an elaborate comparison between the two routing protocols to explain > how the features and functionalities of one differs from the other. > Wherever applicable the differences between OSPFv2 and OSPFv3[OSPFv3] > have also been pointed out. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bhatia-manral-diff-isis-ospf-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-bhatia-manral-diff-isis-ospf-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-bhatia-manral-diff-isis-ospf-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ------------------------------------------------------------------------ > Content-Type: text/plain > Content-ID: <2003-9-4095456.I-D@ietf.org> From owner-ospf@PEACH.EASE.LSOFT.COM Fri Sep 5 02:22:58 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05656 for ; Fri, 5 Sep 2003 02:22:58 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00B41D26@cherry.ease.lsoft.com>; Fri, 5 Sep 2003 2:22:32 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 53937510 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 5 Sep 2003 02:22:31 -0400 Received: from 66.218.93.139 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 5 Sep 2003 02:22:30 -0400 Received: from [203.200.20.226] by web41805.mail.yahoo.com via HTTP; Thu, 04 Sep 2003 23:22:30 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20030905062230.56979.qmail@web41805.mail.yahoo.com> Date: Thu, 4 Sep 2003 23:22:30 -0700 Reply-To: Mailing List Sender: Mailing List From: Rohit Gupta Subject: Elementary Problem! To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list What happens when two OSPF speaking routers are simultaneously switched on a broadcast network? Both of them will put the DR and the BDR as Zero in their HELLO packets. They will both start with Neighbor Down state and Interface down state. Once the Interface will come up both will go to Waiting state. Now when they recieve the HELLO message listiing each other they will reach the 2-Way state. What happens after that is not clear to me from the RFC. How does the DR and BDR get elected? DO we wait for the Wait timer to get expired? The scenario is clear to me when one of them has already elected a DR and a BDR. What is not clear to me is when none of them have elected a DR and BDR. Please help! Regards, Rohit __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From owner-ospf@PEACH.EASE.LSOFT.COM Fri Sep 5 02:43:32 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06292 for ; Fri, 5 Sep 2003 02:43:31 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00B41EA3@cherry.ease.lsoft.com>; Fri, 5 Sep 2003 2:43:34 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 53938861 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 5 Sep 2003 02:43:32 -0400 Received: from 67.17.166.10 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 5 Sep 2003 02:43:32 -0400 Received: from homejtm01a43f8 (unverified [12.232.1.110]) by ucmmail.com (Rockliffe SMTPRA 5.3.4) with ESMTP id for ; Fri, 5 Sep 2003 02:43:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Message-ID: <000001c37379$ca1a3ca0$6e01e80c@homejtm01a43f8> Date: Thu, 4 Sep 2003 23:49:00 -0700 Reply-To: Mailing List Sender: Mailing List From: Farshad Tavallaei Subject: Re: Elementary Problem! To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20030905062230.56979.qmail@web41805.mail.yahoo.com> Precedence: list Content-Transfer-Encoding: 7bit Rohit, Here is a copy/paste from the RFC (please read carefully and tell me what part you don't understand): Electing the Designated Router This section describes the algorithm used for calculating a network's Designated Router and Backup Designated Router. This algorithm is invoked by the Interface state machine. The initial time a router runs the election algorithm for a network, the network's Designated Router and Backup Designated Router are initialized to 0.0.0.0. This indicates the lack of both a Designated Router and a Backup Designated Router. The Designated Router election algorithm proceeds as follows: Call the router doing the calculation Router X. The list of neighbors attached to the network and having established bidirectional communication with Router X is examined. This list is precisely the collection of Router X's neighbors (on this network) whose state is greater than or equal to 2-Way (see Section 10.1). Router X itself is also considered to be on the list. Discard all routers from the list that are ineligible to become Designated Router. (Routers having Router Priority of 0 are ineligible to become Designated Router.) The following steps are then executed, considering only those routers that remain on the list: (1) Note the current values for the network's Designated Router and Backup Designated Router. This is used later for comparison purposes. (2) Calculate the new Backup Designated Router for the network as follows. Only those routers on the list that have not declared themselves to be Designated Router are eligible to become Backup Designated Router. If one or more of these routers have declared themselves Backup Designated Router (i.e., they are currently listing themselves as Backup Designated Router, but not as Designated Router, in their Hello Packets) the one having highest Router Priority is declared to be Backup Designated Router. In case of a tie, the one having the highest Router ID is chosen. If no routers have declared themselves Backup Designated Router, choose the router having highest Router Priority, (again excluding those routers who have declared themselves Designated Router), and again use the Router ID to break ties. (3) Calculate the new Designated Router for the network as follows. If one or more of the routers have declared themselves Designated Router (i.e., they are currently listing themselves as Designated Router in their Hello Packets) the one having highest Router Priority is declared to be Designated Router. In case of a tie, the one having the highest Router ID is chosen. If no routers have declared themselves Designated Router, assign the Designated Router to be the same as the newly elected Backup Designated Router. (4) If Router X is now newly the Designated Router or newly the Backup Designated Router, or is now no longer the Designated Router or no longer the Backup Designated Router, repeat steps 2 and 3, and then proceed to step 5. For example, if Router X is now the Designated Router, when step 2 is repeated X will no longer be eligible for Backup Designated Router election. Among other things, this will ensure that no router will declare itself both Backup Designated Router and Designated Router.[5] (5) As a result of these calculations, the router itself may now be Designated Router or Backup Designated Router. See Sections 7.3 and 7.4 for the additional duties this would entail. The router's interface state should be set accordingly. If the router itself is now Designated Router, the new interface state is DR. If the router itself is now Backup Designated Router, the new interface state is Backup. Otherwise, the new interface state is DR Other. (6) If the attached network is non-broadcast, and the router itself has just become either Designated Router or Backup Designated Router, it must start sending Hello Packets to those neighbors that are not eligible to become Designated Router (see Section 9.5.1). This is done by invoking the neighbor event Start for each neighbor having a Router Priority of 0. (7) If the above calculations have caused the identity of either the Designated Router or Backup Designated Router to change, the set of adjacencies associated with this interface will need to be modified. Some adjacencies may need to be formed, and others may need to be broken. To accomplish this, invoke the event AdjOK? on all neighbors whose state is at least 2-Way. This will cause their eligibility for adjacency to be reexamined. The reason behind the election algorithm's complexity is the desire for an orderly transition from Backup Designated Router to Designated Router, when the current Designated Router fails. This orderly transition is ensured through the introduction of hysteresis: no new Backup Designated Router can be chosen until the old Backup accepts its new Designated Router responsibilities. The above procedure may elect the same router to be both Designated Router and Backup Designated Router, although that router will never be the calculating router (Router X) itself. The elected Designated Router may not be the router having the highest Router Priority, nor will the Backup Designated Router necessarily have the second highest Router Priority. If Router X is not itself eligible to become Designated Router, it is possible that neither a Backup Designated Router nor a Designated Router will be selected in the above procedure. Note also that if Router X is the only attached router that is eligible to become Designated Router, it will select itself as Designated Router and there will be no Backup Designated Router for the network. Best regards, Farshad -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Rohit Gupta Sent: Thursday, September 04, 2003 11:23 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Elementary Problem! What happens when two OSPF speaking routers are simultaneously switched on a broadcast network? Both of them will put the DR and the BDR as Zero in their HELLO packets. They will both start with Neighbor Down state and Interface down state. Once the Interface will come up both will go to Waiting state. Now when they recieve the HELLO message listiing each other they will reach the 2-Way state. What happens after that is not clear to me from the RFC. How does the DR and BDR get elected? DO we wait for the Wait timer to get expired? The scenario is clear to me when one of them has already elected a DR and a BDR. What is not clear to me is when none of them have elected a DR and BDR. Please help! Regards, Rohit __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From owner-ospf@PEACH.EASE.LSOFT.COM Fri Sep 5 15:13:55 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13838 for ; Fri, 5 Sep 2003 15:13:55 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00B48E91@cherry.ease.lsoft.com>; Fri, 5 Sep 2003 15:13:56 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 54012978 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 5 Sep 2003 15:13:55 -0400 Received: from 65.200.123.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 5 Sep 2003 15:13:55 -0400 Received: (qmail 4488 invoked by uid 404); 5 Sep 2003 19:13:54 -0000 Received: from rohit@utstar.com by lxmail by uid 401 with qmail-scanner-1.20rc1 (clamscan: 0.60. spamassassin: 2.55. Clear:RC:1:. Processed in 0.023942 secs); 05 Sep 2003 19:13:54 -0000 Received: from bigbird.nj.us.utstar.com (172.16.36.21) by lxmail.nj.us.utstar.com with SMTP; 5 Sep 2003 19:13:54 -0000 Received: from utstar.com (localhost.localdomain [127.0.0.1]) by bigbird.nj.us.utstar.com (8.9.3/8.9.3) with ESMTP id PAA07834; Fri, 5 Sep 2003 15:13:54 -0400 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200309051913.PAA07834@bigbird.nj.us.utstar.com> Date: Fri, 5 Sep 2003 15:13:54 -0400 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Re: Working Group Last Call for draft-ietf-ospf-scalability-06.txt Comments: cc: fenner@research.att.com, zinin@psg.com To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Message from Rohit Dube of "Thu, 21 Aug 2003 15:01:49 EDT." <200308211901.PAA14415@bigbird.nj.us.utstar.com> Precedence: list This working group call has ended without further comment. The drafts now goes back to the ADs. FYI, --rohit. On Thu, 21 Aug 2003 15:01:49 -0400 Rohit Dube writes: =>This is the start of a Working Group last call for =>Prioritized Treatment of Specific OSPF Packets and =>Congestion Avoidance (draft-ietf-ospf-scalability-06.txt). =>All comments should be received by 5PM (US Eastern), 09/04/2003. => =>A previous (-05) version of this draft completed a WG last call on =>June 13, 2003. It has since been reviewed by the ADs and this version =>addresses their concerns. => =>The draft can be found at =>http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-06.txt => =>--rohit. ___ From owner-ospf@PEACH.EASE.LSOFT.COM Fri Sep 5 16:52:54 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18590 for ; Fri, 5 Sep 2003 16:52:53 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00B49FC4@cherry.ease.lsoft.com>; Fri, 5 Sep 2003 16:52:53 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 54020540 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 5 Sep 2003 16:52:29 -0400 Received: from 207.217.120.122 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 5 Sep 2003 16:52:29 -0400 Received: from user-2ivfmu6.dialup.mindspring.com ([165.247.219.198] helo=earthlink.net) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19vNZD-0000wq-00 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 05 Sep 2003 13:52:27 -0700 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <200309041439.KAA27263@ietf.org> <3F579AA2.3C229B36@earthlink.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3F58F88C.A278E29A@earthlink.net> Date: Fri, 5 Sep 2003 13:56:44 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: B: Re: I-D ACTION:draft-bhatia-manral-diff-isis-ospf-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Part B: really short A) Nits 1 ) Terminology There is no DR specified. However, there is a BDR specified. BDR should be specified after Backup Designated Router. 2) 5.2 ATM Encapsulation TCP ACK ??won??t : will not 3) 8. Checks on Hellos ... remove "-" at the end of the first paragraph. [RFC1195] : should have a blank space after RFC and be specified in references RFC1195 : should have a blank space or a "-" 4) Probably should have DRothers.. B) Technical comments ADDDD: OSPFv2 and OSPFv3 only form adjacencies between DRothers with the hellos from the DR and/or the BDR in BMA and NBMA network configurations. The E-bit and N-bit are found in the options field of the hello packet. Mitchell Erblich Sr Software Engineer ------------------------------ Erblichs wrote: > > This is going to be a multiple part comment, > > A) nits > > 1) Abstract > > [IS-IS] -> Has no item specified in References > > 2) 1. Terminologies > > End System - Host --> End System (ES) - Host > Intermediate System - Router ---> Intermediate System (IS) - Router > > Need something to specify that IS-IS uses the L1 and L2 to specify > Level 1 and Level 2 respectively. > > 3) References > > What are those strange characters? See [Martley], [Mesh], [OOB], > [TUNNEL], > > 4) 8. Checks on ... > > atleast --> at least > > ------- > > B) Technical comments > > 1) 6.1 DR election deterministic.. > > is sticky meaning --> is somewhat sticky because after the wait time > has expired and a router has been elected, it tends to stay in that > elected position. The reason that it is not fully stiicky is that > if a elected router is added to a interface because of area merging, > a DR will be selected from the two routers. This behaviour is specified > in the OSPF RFCs. > > 2) 7. Areas / Hierarchy > > There is a mixture of Level and L usages... You should probably pick > one and stay with it. > > IS-IS > > - Routers are identified as L1, or L2, or L1/L2 routers. > > OSPF > > - Divides the routing domain into multiple area types. > > - The backbone area, area 0.0.0.0 or 0, is used to send packets > from one non-backbone area to another non-backbone area. > > 3) MTU Limitations > > OSPF > > Add > > - When the MTU values differ between routers, IP protocol > allows the configuration to support non-fragmenting of packets that > are > greater than MTU size and can result in the complete loss of packets. > > - When a packet is sent that is greater than MTU size and congestion > occurs or is approaching (random early discard) within the internet, > some implementations will drop these larger packets first. > > - When a packet is sent that is greater than MTU size, the loss of any > part of this fragment will cause the complete packet to be resent. > > - Some vendors support disabling the MTU mismatch detection that > would allow the adjacency to attempt to form. > > - Please note that MTU mismatch is one of a number of causes that > can cause an adjacency to be stuck in exstart. One example could > be duplicate router-ids. > > Mitchell Erblich > Sr Software Engineer > --------------------------- > > Internet-Drafts@IETF.ORG wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > Title : IS-IS and OSPF Difference Discussions > > Author(s) : V. Manral, M. Bhatia > > Filename : draft-bhatia-manral-diff-isis-ospf-00.txt > > Pages : 42 > > Date : 2003-9-4 > > > > The increasing popularity of IS-IS [IS-IS] and OSPF [OSPF] over > > the years has drawn significant attention to the relative merits > > and de-merits of one with respect to the other. This draft presents > > an elaborate comparison between the two routing protocols to explain > > how the features and functionalities of one differs from the other. > > Wherever applicable the differences between OSPFv2 and OSPFv3[OSPFv3] > > have also been pointed out. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-bhatia-manral-diff-isis-ospf-00.txt > > > > To remove yourself from the IETF Announcement list, send a message to > > ietf-announce-request with the word unsubscribe in the body of the message. > > > > Internet-Drafts are also available by anonymous FTP. Login with the username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-bhatia-manral-diff-isis-ospf-00.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-bhatia-manral-diff-isis-ospf-00.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > ------------------------------------------------------------------------ > > Content-Type: text/plain > > Content-ID: <2003-9-4095456.I-D@ietf.org> From owner-ospf@PEACH.EASE.LSOFT.COM Sun Sep 7 05:55:13 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09344 for ; Sun, 7 Sep 2003 05:55:12 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00B52937@cherry.ease.lsoft.com>; 7 Sep 2003 5:55:14 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 54183310 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 7 Sep 2003 05:55:12 -0400 Received: from 129.188.136.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 7 Sep 2003 05:55:12 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h879tB8M012585 for ; Sun, 7 Sep 2003 02:55:11 -0700 (MST) Received: from zin05exm02.corp.mot.com (zin05exm02.corp.mot.com [10.232.0.1]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h879t8tI005631 for ; Sun, 7 Sep 2003 04:55:09 -0500 Received: by zin05exm02.corp.mot.com with Internet Mail Service (5.5.2657.2) id ; Sun, 7 Sep 2003 15:25:07 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain Message-ID: <653138C25D8AD6118292000347080A37066DAB75@zin05exm02.corp.mot.com> Date: Sun, 7 Sep 2003 15:25:06 +0530 Reply-To: Mailing List Sender: Mailing List From: Manral Vishwas-G19459 Subject: Re: B: Re: I-D ACTION:draft-bhatia-manral-diff-isis-ospf-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi folks, I have taken these comments on another list. Thanks, Vishwas -----Original Message----- From: Erblichs [mailto:erblichs@EARTHLINK.NET] Sent: Saturday, September 06, 2003 02:27 To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: B: Re: I-D ACTION:draft-bhatia-manral-diff-isis-ospf-00.txt Part B: really short A) Nits 1 ) Terminology There is no DR specified. However, there is a BDR specified. BDR should be specified after Backup Designated Router. 2) 5.2 ATM Encapsulation TCP ACK ??won??t : will not 3) 8. Checks on Hellos ... remove "-" at the end of the first paragraph. [RFC1195] : should have a blank space after RFC and be specified in references RFC1195 : should have a blank space or a "-" 4) Probably should have DRothers.. B) Technical comments ADDDD: OSPFv2 and OSPFv3 only form adjacencies between DRothers with the hellos from the DR and/or the BDR in BMA and NBMA network configurations. The E-bit and N-bit are found in the options field of the hello packet. Mitchell Erblich Sr Software Engineer ------------------------------ Erblichs wrote: > > This is going to be a multiple part comment, > > A) nits > > 1) Abstract > > [IS-IS] -> Has no item specified in References > > 2) 1. Terminologies > > End System - Host --> End System (ES) - Host > Intermediate System - Router ---> Intermediate System (IS) - Router > > Need something to specify that IS-IS uses the L1 and L2 to specify > Level 1 and Level 2 respectively. > > 3) References > > What are those strange characters? See [Martley], [Mesh], [OOB], > [TUNNEL], > > 4) 8. Checks on ... > > atleast --> at least > > ------- > > B) Technical comments > > 1) 6.1 DR election deterministic.. > > is sticky meaning --> is somewhat sticky because after the wait time > has expired and a router has been elected, it tends to stay in that > elected position. The reason that it is not fully stiicky is that > if a elected router is added to a interface because of area merging, > a DR will be selected from the two routers. This behaviour is specified > in the OSPF RFCs. > > 2) 7. Areas / Hierarchy > > There is a mixture of Level and L usages... You should probably pick > one and stay with it. > > IS-IS > > - Routers are identified as L1, or L2, or L1/L2 routers. > > OSPF > > - Divides the routing domain into multiple area types. > > - The backbone area, area 0.0.0.0 or 0, is used to send packets > from one non-backbone area to another non-backbone area. > > 3) MTU Limitations > > OSPF > > Add > > - When the MTU values differ between routers, IP protocol > allows the configuration to support non-fragmenting of packets that > are > greater than MTU size and can result in the complete loss of packets. > > - When a packet is sent that is greater than MTU size and congestion > occurs or is approaching (random early discard) within the internet, > some implementations will drop these larger packets first. > > - When a packet is sent that is greater than MTU size, the loss of any > part of this fragment will cause the complete packet to be resent. > > - Some vendors support disabling the MTU mismatch detection that > would allow the adjacency to attempt to form. > > - Please note that MTU mismatch is one of a number of causes that > can cause an adjacency to be stuck in exstart. One example could > be duplicate router-ids. > > Mitchell Erblich > Sr Software Engineer > --------------------------- > > Internet-Drafts@IETF.ORG wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > Title : IS-IS and OSPF Difference Discussions > > Author(s) : V. Manral, M. Bhatia > > Filename : draft-bhatia-manral-diff-isis-ospf-00.txt > > Pages : 42 > > Date : 2003-9-4 > > > > The increasing popularity of IS-IS [IS-IS] and OSPF [OSPF] over > > the years has drawn significant attention to the relative merits > > and de-merits of one with respect to the other. This draft presents > > an elaborate comparison between the two routing protocols to explain > > how the features and functionalities of one differs from the other. > > Wherever applicable the differences between OSPFv2 and OSPFv3[OSPFv3] > > have also been pointed out. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-bhatia-manral-diff-isis-ospf-00.txt > > > > To remove yourself from the IETF Announcement list, send a message to > > ietf-announce-request with the word unsubscribe in the body of the message. > > > > Internet-Drafts are also available by anonymous FTP. Login with the username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-bhatia-manral-diff-isis-ospf-00.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-bhatia-manral-diff-isis-ospf-00.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > ------------------------------------------------------------------------ > > Content-Type: text/plain > > Content-ID: <2003-9-4095456.I-D@ietf.org> From owner-ospf@PEACH.EASE.LSOFT.COM Mon Sep 8 03:51:36 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29465 for ; Mon, 8 Sep 2003 03:51:35 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00B595F2@cherry.ease.lsoft.com>; Mon, 8 Sep 2003 3:51:39 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 54285120 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 8 Sep 2003 03:51:37 -0400 Received: from 207.217.120.122 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 8 Sep 2003 03:51:37 -0400 Received: from user-2ivfm6l.dialup.mindspring.com ([165.247.216.213] helo=earthlink.net) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19wGoC-0001Ii-00 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 08 Sep 2003 00:51:36 -0700 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <20030905062230.56979.qmail@web41805.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3F5C3475.9904D33A@earthlink.net> Date: Mon, 8 Sep 2003 00:49:09 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Elementary Problem! To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Rohit, If you want a short answer here it is. If these two routers are the only ones on this broadcast networks, then they wait until the Wait timer expires to see if anyone annouces a DR and/or BDR. During that time we will form neighbors between these new routers if a number of parameters are consistent. Each router will then do the appropriate DR/BDR election. Mitchell Erblich Sr Software Engineer ------------------------- Rohit Gupta wrote: > > What happens when two OSPF speaking routers are > simultaneously switched on a broadcast network? Both > of them will put the DR and the BDR as Zero in their > HELLO packets. > > They will both start with Neighbor Down state and > Interface down state. Once the Interface will come up > both will go to Waiting state. Now when they recieve > the HELLO message listiing each other they will reach > the 2-Way state. > > What happens after that is not clear to me from the > RFC. How does the DR and BDR get elected? DO we wait > for the Wait timer to get expired? > > The scenario is clear to me when one of them has > already elected a DR and a BDR. What is not clear to > me is when none of them have elected a DR and BDR. > > Please help! > > Regards, > Rohit > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design software > http://sitebuilder.yahoo.com From owner-ospf@PEACH.EASE.LSOFT.COM Tue Sep 9 16:47:22 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03905 for ; Tue, 9 Sep 2003 16:47:22 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00B64395@cherry.ease.lsoft.com>; Tue, 9 Sep 2003 16:47:25 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 54564596 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 9 Sep 2003 16:47:23 -0400 Received: from 192.25.240.36 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 9 Sep 2003 16:47:23 -0400 Received: from relcos2.cos.agilent.com (relcos2.cos.agilent.com [130.29.152.237]) by msgbas1x.cos.agilent.com (Postfix) with ESMTP id 6D5F9273C0 for ; Tue, 9 Sep 2003 14:47:23 -0600 (MDT) Received: from wcosbh22.cos.agilent.com (wcosbh22.cos.agilent.com [130.29.152.178]) by relcos2.cos.agilent.com (Postfix) with ESMTP id 4C9E4DA7 for ; Tue, 9 Sep 2003 14:47:23 -0600 (MDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Topic: Clarification on multiple instances for OSPFv3 Thread-Index: AcN3E4w6lHsnVO6tQeiFcGfL1QM+/w== Message-ID: <0D9185CE635BD511ACA50090277A6FCF037EA72D@axcs18.cos.agilent.com> Date: Tue, 9 Sep 2003 14:47:14 -0600 Reply-To: Mailing List Sender: Mailing List From: gail_browne@AGILENT.COM Subject: Clarification on multiple instances for OSPFv3 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi All, In OSPFv3 as per RFC2740 section 2.4, multiple instances are supported = through the parameter Instance ID. My understanding is that this is = used because multiple OSPFv3 instances will potentially run over the = same physical interface, and therefore use the same IPv6 addresses, and = the instance ID will help in delivery of incoming OSPFv3 packets. New = for OSPFv3 is the fact that neighbors are identified solely by their = router Id (Section 3.2.2.1), this should imply that there needs to be an = enforcement of no duplicate router Id's so that every instance of ospfv3 = configured on a router must have its own unique router Id. Am I correct = in this assumption? Thanks in advance, Gail From owner-ospf@PEACH.EASE.LSOFT.COM Tue Sep 9 17:01:53 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04549 for ; Tue, 9 Sep 2003 17:01:53 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00B643FE@cherry.ease.lsoft.com>; Tue, 9 Sep 2003 17:01:58 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 54565858 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 9 Sep 2003 17:00:19 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 9 Sep 2003 17:00:19 -0400 Received: from redback.com (pptp-6-171.redback.com [155.53.6.171]) by prattle.redback.com (Postfix) with ESMTP id 12F0B6E0104 for ; Tue, 9 Sep 2003 14:00:18 -0700 (PDT) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <0D9185CE635BD511ACA50090277A6FCF037EA72D@axcs18.cos.agilent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F5E3F5A.50109@redback.com> Date: Tue, 9 Sep 2003 17:00:10 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Clarification on multiple instances for OSPFv3 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <0D9185CE635BD511ACA50090277A6FCF037EA72D@axcs18.cos.agilent.com> Precedence: list Content-Transfer-Encoding: 7bit gail_browne@AGILENT.COM wrote: >Hi All, > >In OSPFv3 as per RFC2740 section 2.4, multiple instances are supported through the parameter Instance ID. My understanding is that this is used because multiple OSPFv3 instances will potentially run over the same physical interface, and therefore use the same IPv6 addresses, and the instance ID will help in delivery of incoming OSPFv3 packets. New for OSPFv3 is the fact that neighbors are identified solely by their router Id (Section 3.2.2.1), this should imply that there needs to be an enforcement of no duplicate router Id's so that every instance of ospfv3 configured on a router must have its own unique router Id. Am I correct in this assumption? > Hi Gail, No. Rather, I'd assume that the instances are part of separate areas or routing domains. Thanks, Acee > >Thanks in advance, >Gail > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Sep 9 23:22:50 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18569 for ; Tue, 9 Sep 2003 23:22:50 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00B666BF@cherry.ease.lsoft.com>; Tue, 9 Sep 2003 23:22:53 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 54608217 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 9 Sep 2003 23:17:50 -0400 Received: from 61.144.161.41 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 9 Sep 2003 23:07:49 -0400 Received: from liuyu18957n (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HKZ00K919YJB5@mta0.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 10 Sep 2003 11:06:21 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Mailer: Microsoft Outlook Express 5.50.4927.1200 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <20030731211437.48158.qmail@web13503.mail.yahoo.com> <3F298E33.5010100@redback.com> Message-ID: <005301c37748$908baf50$938a6e0a@liuyu18957n> Date: Wed, 10 Sep 2003 11:06:43 +0800 Reply-To: Mailing List Sender: Mailing List From: Liu Yu Subject: Inter-area routes reachable via multiple areas Comments: To: acee@REDBACK.COM To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: base64 SGkhIGFsbA0KDQpJIG5vdGljZSB0aGF0IHRoZSBjbGF1c2UgaW4gIFJGQyAyMzI4IDE2LjQgKDMp IGlzIGp1c3QgZm9yIGV4dGVybmFsIHJvdXRlLg0KSG93IGFib3V0ICJpbnRlci1hcmVhIHJvdXRl cyLvvJ8gUkZDIDIzMjggZG9lcyBub3QgZXhwbGljaXRseSBzdGF0ZSB0aGlzIA0Kb25lISBKdXN0 IGNob29zZSB0aGUgInRoZSBwYXRoIHdob3NlIGFzc29jaWF0ZWQgYXJlYSBoYXMgdGhlDQpsYXJn ZXN0IE9TUEYgQXJlYSBJRCAi77yf77yfIE1heWJlIGV2ZXJ5IG9uZSBoYXMgaGlzIG93biBpbXBs ZW50YXRpb24uDQoNCg0KdGhhbmtzIQ0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0g DQpGcm9tOiAiQWNlZSBMaW5kZW0iIDxhY2VlQFJFREJBQ0suQ09NPg0KVG86IDxPU1BGQFBFQUNI LkVBU0UuTFNPRlQuQ09NPg0KU2VudDogRnJpZGF5LCBBdWd1c3QgMDEsIDIwMDMgNTo0NiBBTQ0K U3ViamVjdDogUmU6IEFTQlIgcmVhY2hhYmxlIHZpYSBtdWx0aXBsZSBhcmVhcw0KDQoNCj4gUm9i LA0KPiANCj4gWW91IGFyZSBjb3JyZWN0IC0gSSBtaXNzZWQgdGhhdCBjbGF1c2UgaW4gMTYuNCAo Mykgd2hlbg0KPiByZS1yZWFkaW5nLiBJIHNob3VsZCBoYXZlIGNoZWNrZWQgbXkgaW1wbGVtZW50 YXRpb24gYmVmb3JlDQo+IHJlcGx5aW5nLiBJIGNhbid0IGVudmlzaW9uIHdoeSBpbnN0YWxsaW5n IGFuIGVxdWFsLWNvc3RzDQo+IHJvdXRlcyB0aHJvdWdoIG11bHRpcGxlIGFyZWFzIHVzaW5nIHRo ZSBzYW1lIDE2LjQuMSBzZWxlY3Rpb24NCj4gcnVsZXMgY291bGQgY2F1c2UgYSByb3V0aW5nIGxv b3Agb3Igb3RoZXIgcHJvYmxlbS4NCj4gDQo+IFRoYW5rcywNCj4gQWNlZQ0KPiANCj4gUk9CIFBB VEggd3JvdGU6DQo+ID4gLS0tIEFjZWUgTGluZGVtIDxhY2VlQFJFREJBQ0suQ09NPiB3cm90ZToN Cj4gPg0KPiA+Pklnb3IgTWlyb3NobmlrIHdyb3RlOg0KPiA+Pg0KPiA+Pj5BbGwsDQo+ID4+Pg0K PiA+Pj4gICBSRkMgMTU4MyBzdGF0ZXM6ICJBUyBib3VuZGFyeSByb3V0ZXIncyByb3V0aW5nDQo+ ID4+DQo+ID4+dGFibGUgZW50cnkgbXVzdCBpbmRpY2F0ZSBhIHNldCBvZiBwYXRocyB3aGljaA0K PiA+Pg0KPiA+Pj51dGlsaXplIGEgc2luZ2xlIGFyZWEuIiAoMTYuMSkNCj4gPj4+ICAgV2h5IG5v dCB1dGlsaXplIGFsbCBlcXVhbC1jb3N0IHBhdGhzIHRocm91Z2gNCj4gPj4NCj4gPj5kaWZmZXJl bnQgYXJlYXM/DQo+ID4+DQo+ID4+SGkgSWdvciwNCj4gPj4NCj4gPj5JIGJlbGlldmUgeW91IGNh biBjYWxjdWxhdGUgZXF1YWwgY29zdCBwYXRocyB0aHJvdWdoDQo+ID4+bXVsdGlwbGUNCj4gPj5h cmVhcyAtIHJlYWQgc2VjdGlvbiAxNi40IGFuZCAxNi40LjEgaW4gUkZDIDIzMjgNCj4gPj4od2hp Y2gNCj4gPj5vYnNvbGV0ZXMgUkZDIDIxNzggd2hpY2ggb2Jzb2xldGVzIFJGQyAxNTgzKS4NCj4g Pj4NCj4gPj4NCj4gPg0KPiA+DQo+ID4gVGhlIHNlY3Rpb24gMTYuNCBpbiBSRkMgMjMyOCBkb2Vz IG5vdCBleHBsaWNpdGx5IHN0YXRlDQo+ID4gdGhhdCBlcXVhbCBjb3N0IHBhdGhzIHRocm91Z2gg bXVsdGlwbGUgYXJlYXMgY291bGQgYmUNCj4gPiB1dGlsaXplZCAoc2F5IGZvciBsb2FkIGJhbGFu Y2luZyBwdXJwb3NlcykuDQo+ID4NCj4gPiBJdCByYXRoZXIgc3RhdGVzIHRoYXQgd2hlbiB0aGVy ZSBhcmUgbXVsdGlwbGUNCj4gPiBsZWFzdCBjb3N0IHBhdGhzIGF2YWlsYWJsZSBpbiB0aGUgcm91 dGluZw0KPiA+IHRhYmxlLCB0aGUgcGF0aCB3aG9zZSBhc3NvY2lhdGVkIGFyZWEgaGFzIHRoZQ0K PiA+IGxhcmdlc3QgT1NQRiBBcmVhIElEIGlzIGNob3Nlbi4NCj4gPg0KPiA+IEFsc28gc2VjdGlv biAxNi40LjEgcmVmZXJzIHRvIHNlY3Rpb24gMTYuNCBmb3INCj4gPiBjaG9vc2luZyBhIHBhdGgg YmFzZWQgb24gY29zdCwgd2hlbiB0aGVyZSBhcmUNCj4gPiBtdWx0aXBsZSBwYXRocyBvZiBlcXVh bCBoaWdoZXN0IHByZWZlcmVuY2VzLg0KPiA+DQo+ID4gU28gaXQgZXNzZW50aWFsbHkgbWVhbnMg dGhhdCBtdWx0aXBsZSBlcXVhbCBjb3N0DQo+ID4gaW50ZXItYXJlYSBwYXRocyBhcmUgbm90IHV0 aWxpemVkLg0KPiA+DQo+ID4gVGhhbmtzLA0KPiA+ICAgICBSb2IuDQo+ID4NCj4gPg0KPiA+DQo+ ID4+DQo+ID4+PiAgIFRoYW5rcywNCj4gPj4+ICAgSWdvcg0KPiA+Pj4NCj4gPj4NCj4gPj4NCj4g Pj4tLQ0KPiA+PkFjZWUNCj4gPg0KPiA+DQo+ID4NCj4gPiA9PT09PQ0KPiA+IFJvYiBQYXRoDQo+ ID4gRS1NYWlsIDogcm9iX3BhdGhAeWFob28uY29tDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4gRG8geW91IFlhaG9vIT8NCj4gPiBZYWhvbyEgU2l0ZUJ1 aWxkZXIgLSBGcmVlLCBlYXN5LXRvLXVzZSB3ZWIgc2l0ZSBkZXNpZ24gc29mdHdhcmUNCj4gPiBo dHRwOi8vc2l0ZWJ1aWxkZXIueWFob28uY29tDQo+ID4NCj4gDQo+IA0KPiAtLQ0KPiBBY2VlDQoN Cg== From owner-ospf@PEACH.EASE.LSOFT.COM Wed Sep 10 04:24:09 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22438 for ; Wed, 10 Sep 2003 04:24:09 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00B67F69@cherry.ease.lsoft.com>; Wed, 10 Sep 2003 4:24:12 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 54646976 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 10 Sep 2003 04:24:11 -0400 Received: from 207.217.120.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 10 Sep 2003 04:24:11 -0400 Received: from user-38lc0l5.dialup.mindspring.com ([209.86.2.165] helo=earthlink.net) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19x0Go-00077P-00 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 10 Sep 2003 01:24:10 -0700 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <20030731211437.48158.qmail@web13503.mail.yahoo.com> <3F298E33.5010100@redback.com> <005301c37748$908baf50$938a6e0a@liuyu18957n> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3F5ED54C.8700754F@earthlink.net> Date: Wed, 10 Sep 2003 00:39:56 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: ?? draft-ietf-ospf-isis-flood.opt-01.txt : Status To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, This draft was specifing nbr flooding vs interface flooding and was interested to know whether anyone was aware of what was meant by the phrase: "Multiaccess interfaces need special treatmeant" in the 3.1 Introduction section. By my read, if the interface was a BMA or a NBMA, then you would have needed "neighbor flooding active/passive" type configs. I have been asked to investigate some of its features, but believe that this draft never was pushed to RFC. Am I right and did anyone implement these features. Mitchell Erblich Sr Software Engineer ---------- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Sep 10 06:15:09 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24483 for ; Wed, 10 Sep 2003 06:15:08 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00B683CE@cherry.ease.lsoft.com>; Wed, 10 Sep 2003 6:15:12 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 54670189 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 10 Sep 2003 06:15:02 -0400 Received: from 203.199.83.246 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 10 Sep 2003 06:15:01 -0400 Received: (qmail 2921 invoked by uid 510); 10 Sep 2003 10:13:25 -0000 Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 10 sep 2003 10:13:25 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-ID: <20030910101325.2920.qmail@webmail35.rediffmail.com> Date: Wed, 10 Sep 2003 10:13:25 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: Re: Inter-area routes reachable via multiple areas To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable The case should not occur in case of standard ABR implementations for inter= -area route calculations.=0ACISCO/IBM ABR implementations might lead to suc= h scenario.=0A=0AVivek=0A=0A=0A=0A=0AOn Wed, 10 Sep 2003 Liu Yu wrote :=0A>= Hi! all=0A>=0A>I notice that the clause in RFC 2328 16.4 (3) is just for e= xternal route.=0A>How about "inter-area routes"=EF=BC=9F RFC 2328 does not = explicitly state this=0A>one! Just choose the "the path whose associated ar= ea has the=0A>largest OSPF Area ID "=EF=BC=9F=EF=BC=9F Maybe every one has = his own implentation.=0A>=0A>=0A>thanks!=0A>=0A>=0A>----- Original Message = -----=0A> From: "Acee Lindem" =0A>To: =0A>Sent: Friday, August 01, 2003 5:46 AM=0A>Subject: Re: ASBR reac= hable via multiple areas=0A>=0A>=0A> > Rob,=0A> >=0A> > You are correct - I= missed that clause in 16.4 (3) when=0A> > re-reading. I should have checke= d my implementation before=0A> > replying. I can't envision why installing = an equal-costs=0A> > routes through multiple areas using the same 16.4.1 se= lection=0A> > rules could cause a routing loop or other problem.=0A> >=0A> = > Thanks,=0A> > Acee=0A> >=0A> > ROB PATH wrote:=0A> > > --- Acee Lindem wrote:=0A> > >=0A> > >>Igor Miroshnik wrote:=0A> > >>=0A> = > >>>All,=0A> > >>>=0A> > >>> RFC 1583 states: "AS boundary router's rout= ing=0A> > >>=0A> > >>table entry must indicate a set of paths which=0A> > >= >=0A> > >>>utilize a single area." (16.1)=0A> > >>> Why not utilize all e= qual-cost paths through=0A> > >>=0A> > >>different areas?=0A> > >>=0A> > >>= Hi Igor,=0A> > >>=0A> > >>I believe you can calculate equal cost paths thro= ugh=0A> > >>multiple=0A> > >>areas - read section 16.4 and 16.4.1 in RFC 23= 28=0A> > >>(which=0A> > >>obsoletes RFC 2178 which obsoletes RFC 1583).=0A>= > >>=0A> > >>=0A> > >=0A> > >=0A> > > The section 16.4 in RFC 2328 does no= t explicitly state=0A> > > that equal cost paths through multiple areas cou= ld be=0A> > > utilized (say for load balancing purposes).=0A> > >=0A> > > I= t rather states that when there are multiple=0A> > > least cost paths avail= able in the routing=0A> > > table, the path whose associated area has the= =0A> > > largest OSPF Area ID is chosen.=0A> > >=0A> > > Also section 16.4.= 1 refers to section 16.4 for=0A> > > choosing a path based on cost, when th= ere are=0A> > > multiple paths of equal highest preferences.=0A> > >=0A> > = > So it essentially means that multiple equal cost=0A> > > inter-area paths= are not utilized.=0A> > >=0A> > > Thanks,=0A> > > Rob.=0A> > >=0A> > >= =0A> > >=0A> > >>=0A> > >>> Thanks,=0A> > >>> Igor=0A> > >>>=0A> > >>= =0A> > >>=0A> > >>--=0A> > >>Acee=0A> > >=0A> > >=0A> > >=0A> > > =3D=3D=3D= =3D=3D=0A> > > Rob Path=0A> > > E-Mail : rob_path@yahoo.com=0A> > >=0A> > >= __________________________________=0A> > > Do you Yahoo!?=0A> > > Yahoo! S= iteBuilder - Free, easy-to-use web site design software=0A> > > http://site= builder.yahoo.com=0A> > >=0A> >=0A> >=0A> > --=0A> > Acee=0A>=0A=0A________= ___________________________________________=0AMedicine meets Marketing; Dr.= Swati Weds Jayaram.=0ARediff Matchmaker strikes another interesting match = !!=0AVisit http://rediff.com/matchmaker?2=0A From owner-ospf@PEACH.EASE.LSOFT.COM Thu Sep 11 15:56:57 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11451 for ; Thu, 11 Sep 2003 15:56:57 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00B73E6A@cherry.ease.lsoft.com>; Thu, 11 Sep 2003 15:56:58 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 54669891 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 11 Sep 2003 13:40:44 -0400 Received: from 146.87.255.104 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 11 Sep 2003 13:40:44 -0400 Received: (qmail 46733 invoked by uid 85); 11 Sep 2003 13:32:39 -0000 Received: from M.C.Puddephatt@pgr.salford.ac.uk by pan.salford.ac.uk by uid 401 with qmail-scanner-1.16 (uvscan: v4.2.40/v4292. spamassassin: 2.55. Clear:. Processed in 0.312149 secs); 11 Sep 2003 13:32:39 -0000 X-Qmail-Scanner-Mail-From: M.C.Puddephatt@pgr.salford.ac.uk via pan.salford.ac.uk X-Qmail-Scanner: 1.16 (Clear:. Processed in 0.312149 secs) Received: (ofmipd 146.87.48.123); 11 Sep 2003 13:32:38 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Message-ID: Date: Thu, 11 Sep 2003 14:32:39 +0100 Reply-To: Mailing List Sender: Mailing List From: Mark Christopher Puddephatt Subject: OSPF Optional capabilities query To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, I am a PhD researcher at the University of Salford, UK, and am researching into OSPF. I have read the recent draft "Extensions to OSPF for Advertising Optional Router Capabilities", and it mentions that all the bits in the Options field of the Hello packet are now in use. However I cannot seem to find a full list of what they are all in use for. RFC-2328 lists five bits of the 8, namely the E-bit, MC-bit, N/P-bit, DC-bit and the EA-bit. RFC-2370 adds the O-bit. In Christian Huitema's "Routing in the Internet" a T-bit is mentioned for TOS routing. That makes seven. Could someone please point out to me what the final bit is being used for? Thank you, Mark Mark Puddephatt ********************************************************** m.c.puddephatt@pgr.salford.ac.uk or mark@markpud.com CNTR www.cntr.net School of Computing, Science and Engineering University of Salford www.salford.ac.uk ********************************************************** From owner-ospf@PEACH.EASE.LSOFT.COM Thu Sep 11 16:25:04 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12492 for ; Thu, 11 Sep 2003 16:25:04 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00B7446C@cherry.ease.lsoft.com>; Thu, 11 Sep 2003 16:25:07 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 54676113 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 11 Sep 2003 15:00:44 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 11 Sep 2003 14:50:43 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05127; Thu, 11 Sep 2003 14:50:37 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200309111850.OAA05127@ietf.org> Date: Thu, 11 Sep 2003 14:50:36 -0400 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-bmwg-ospfconv-term-06.txt Comments: cc: bmwg@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Benchmarking Methodology Working Group of the IETF. Title : OSPF Benchmarking Terminology and Concepts Author(s) : V. Manral, R. White, A. Shaikh Filename : draft-ietf-bmwg-ospfconv-term-06.txt Pages : 9 Date : 2003-9-11 This draft explains the terminology and concepts used in [BENCHMARK] and future OSPF benchmarking drafts, within the context of those drafts. While some of these terms may be defined elsewhere, and we will refer the reader to those definitions in some cases, we also include discussions concerning these terms as they relate specifically to the tasks involved in benchmarking the OSPF protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ospfconv-term-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bmwg-ospfconv-term-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bmwg-ospfconv-term-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-11140652.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bmwg-ospfconv-term-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bmwg-ospfconv-term-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-11140652.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Sep 11 16:51:12 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13309 for ; Thu, 11 Sep 2003 16:51:06 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00B748FF@cherry.ease.lsoft.com>; Thu, 11 Sep 2003 16:50:50 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 54681281 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 11 Sep 2003 16:12:32 -0400 Received: from 63.231.195.115 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 11 Sep 2003 16:12:31 -0400 Received: (qmail 6303 invoked by uid 0); 11 Sep 2003 20:12:16 -0000 Received: from mpls-pop-12.inet.qwest.net (63.231.195.12) by mpls-qmqp-04.inet.qwest.net with QMQP; 11 Sep 2003 20:12:16 -0000 Received: from 0-2pool146-97.nas9.minneapolis1.mn.us.da.qwest.net (HELO charita) (67.4.146.97) by mpls-pop-12.inet.qwest.net with SMTP; 11 Sep 2003 20:12:10 -0000 References: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <000d01c378a0$a75d0ea0$cbc8c8c8@sdksoft.com> Date: Thu, 11 Sep 2003 15:09:49 -0500 Reply-To: Mailing List Sender: Mailing List From: Parag Deshpande Subject: Re: OSPF Optional capabilities query To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit draft-ietf-ospf-2547-dnbit-00.txt mentions the use of high order bit called DN bit. Parag. ----- Original Message ----- From: Mark Christopher Puddephatt To: Sent: Thursday, September 11, 2003 8:32 AM Subject: OSPF Optional capabilities query > Group, > > I am a PhD researcher at the University of Salford, UK, and am researching > into OSPF. I have read the recent draft "Extensions to OSPF for Advertising > Optional Router Capabilities", and it mentions that all the bits in the > Options field of the Hello packet are now in use. > > However I cannot seem to find a full list of what they are all in use for. > RFC-2328 lists five bits of the 8, namely the E-bit, MC-bit, N/P-bit, DC-bit > and the EA-bit. RFC-2370 adds the O-bit. In Christian Huitema's "Routing in > the Internet" a T-bit is mentioned for TOS routing. That makes seven. > > Could someone please point out to me what the final bit is being used for? > > Thank you, > > Mark > > Mark Puddephatt > ********************************************************** > m.c.puddephatt@pgr.salford.ac.uk or mark@markpud.com > CNTR www.cntr.net > School of Computing, Science and Engineering > University of Salford www.salford.ac.uk > ********************************************************** > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Sep 11 16:57:47 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13569 for ; Thu, 11 Sep 2003 16:57:46 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00B74B7B@cherry.ease.lsoft.com>; Thu, 11 Sep 2003 16:57:44 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 54685550 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 11 Sep 2003 16:38:34 -0400 Received: from 192.75.23.69 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 11 Sep 2003 16:28:34 -0400 Received: (qmail 7952 invoked from network); 11 Sep 2003 20:40:15 -0000 Received: from unknown (HELO alcatel.com) (138.120.252.76) by kanmx1.ca.alcatel.com with SMTP; 11 Sep 2003 20:40:15 -0000 X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3F60DAF0.34C51B73@alcatel.com> Date: Thu, 11 Sep 2003 16:28:32 -0400 Reply-To: Mailing List Sender: Mailing List From: Ehsan Rezaaifar Organization: Alcatel CID Subject: Re: OSPF Optional capabilities query To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi, The DN bit is used for OSPF PE-CE, introduced in "draft-rosen-ppvpn-ospf2547-area0" Take care, Ehsan Mark Christopher Puddephatt wrote: > Group, > > I am a PhD researcher at the University of Salford, UK, and am researching > into OSPF. I have read the recent draft "Extensions to OSPF for Advertising > Optional Router Capabilities", and it mentions that all the bits in the > Options field of the Hello packet are now in use. > > However I cannot seem to find a full list of what they are all in use for. > RFC-2328 lists five bits of the 8, namely the E-bit, MC-bit, N/P-bit, DC-bit > and the EA-bit. RFC-2370 adds the O-bit. In Christian Huitema's "Routing in > the Internet" a T-bit is mentioned for TOS routing. That makes seven. > > Could someone please point out to me what the final bit is being used for? > > Thank you, > > Mark > > Mark Puddephatt > ********************************************************** > m.c.puddephatt@pgr.salford.ac.uk or mark@markpud.com > CNTR www.cntr.net > School of Computing, Science and Engineering > University of Salford www.salford.ac.uk > ********************************************************** From owner-ospf@PEACH.EASE.LSOFT.COM Thu Sep 11 23:43:09 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24665 for ; Thu, 11 Sep 2003 23:43:08 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00B762E6@cherry.ease.lsoft.com>; Thu, 11 Sep 2003 23:43:12 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 54729183 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 11 Sep 2003 23:43:10 -0400 Received: from 203.197.140.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 11 Sep 2003 23:33:09 -0400 Received: from kailash1.future.futsoft.com (unverified [203.197.140.36]) by fsnt.future.futsoft.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Fri, 12 Sep 2003 09:07:07 +0530 Received: from suryam (suryam.future.futsoft.com [10.4.5.30]) by kailash1.future.futsoft.com (8.11.0/8.11.0) with SMTP id h8C3Uia31360 for ; Fri, 12 Sep 2003 09:00:44 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <004601c378df$36151fa0$1e05040a@future.futsoft.com> Date: Fri, 12 Sep 2003 09:07:36 +0530 Reply-To: Mailing List Sender: Mailing List From: "M.N.V.Suryanarayana" Subject: unsubscribe To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-ospf@PEACH.EASE.LSOFT.COM Fri Sep 12 02:39:15 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10528 for ; Fri, 12 Sep 2003 02:39:15 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00B76B10@cherry.ease.lsoft.com>; Fri, 12 Sep 2003 2:39:18 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 54749585 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 12 Sep 2003 02:39:17 -0400 Received: from 64.104.129.195 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 12 Sep 2003 02:29:17 -0400 Received: from cisco.com (64.104.129.221) by india-ironport-1.cisco.com with ESMTP; 12 Sep 2003 12:16:26 +0530 Received: from cisco.com (localhost [127.0.0.1]) by india-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h8CBukdP002070 for ; Fri, 12 Sep 2003 11:56:57 GMT Received: from dmukunda-w2k.cisco.com ([10.77.139.63]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA24119 for ; Fri, 12 Sep 2003 11:56:15 +0530 (IST) X-Sender: dmukunda@megha.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.2.7.2.20030912115037.04270ba0@megha.cisco.com> Date: Fri, 12 Sep 2003 11:58:52 +0530 Reply-To: Mailing List Sender: Mailing List From: "Divya Mukundan (dmukunda)" Subject: RFC1850 - compilation error To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi, I'm getting the following compilation error in "compliance statements" of RFC1850 (OSPF-TRAP-MIB). I'm using smicng and Fred Baker said that the MIB compiled with it and that smicng could have changed subsequently. Is anyone aware of an option in smicng that can suppress this error? Any other suggestions? -----------------------------------RFC1850-------------------------------------------- -- compliance statements ospfTrapCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement " MODULE -- this module MANDATORY-GROUPS { ospfTrapControlGroup } <<<==== GROUP ospfTrapControlGroup <<<==== DESCRIPTION "This group is optional but recommended for all OSPF systems" -----------------------------------ERROR---------------------------------------------- E: f(OSPF-TRAP-MIB.my), (470,21) Group "ospfTrapControlGroup" is both a MANDATORY and conditional group for module "OSPF-TRAP-MIB" Thanks, -Divya From owner-ospf@PEACH.EASE.LSOFT.COM Fri Sep 12 14:11:39 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07967 for ; Fri, 12 Sep 2003 14:11:39 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00B79FCB@cherry.ease.lsoft.com>; Fri, 12 Sep 2003 14:11:43 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 54809564 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 12 Sep 2003 14:11:35 -0400 Received: from 207.159.120.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 12 Sep 2003 14:11:35 -0400 Received: by xmxpita.excite.com (Postfix, from userid 110) id C7D90B6DC; Fri, 12 Sep 2003 14:11:31 -0400 (EDT) Received: from [64.47.48.10] by xprdmailfe14.nwk.excite.com via HTTP; Fri, 12 Sep 2003 14:11:31 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = ce00c10647f1b9e7db16a67db0936ee4 MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20030912181131.C7D90B6DC@xmxpita.excite.com> Date: Fri, 12 Sep 2003 14:11:31 -0400 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: RFC1850 - compilation error To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Divya, You can try using -CT. For more on smicng, contact Dave Perkins at www.snmpinfo.com as he is the author of smicng. These option are also described in his book "Understanding SNMP MIBs" which is where I looked. -don ==================================================== Hi, I'm getting the following compilation error in "compliance statements" of RFC1850 (OSPF-TRAP-MIB). I'm using smicng and Fred Baker said that the MIB compiled with it and that smicng could have changed subsequently. Is anyone aware of an option in smicng that can suppress this error? Any other suggestions? -----------------------------------RFC1850-------------------------------------------- -- compliance statements ospfTrapCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement " MODULE -- this module MANDATORY-GROUPS { ospfTrapControlGroup } <<<==== GROUP ospfTrapControlGroup <<<==== DESCRIPTION "This group is optional but recommended for all OSPF systems" -----------------------------------ERROR---------------------------------------------- E: f(OSPF-TRAP-MIB.my), (470,21) Group "ospfTrapControlGroup" is both a MANDATORY and conditional group for module "OSPF-TRAP-MIB" Thanks, -Divya _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ospf@PEACH.EASE.LSOFT.COM Sat Sep 13 11:06:10 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21034 for ; Sat, 13 Sep 2003 11:06:10 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00B7E5B0@cherry.ease.lsoft.com>; Sat, 13 Sep 2003 11:06:11 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 54898474 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 13 Sep 2003 11:06:10 -0400 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 13 Sep 2003 11:06:10 -0400 Received: from PEACH.EASE.LSOFT.COM (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00B7E613@cherry.ease.lsoft.com>; Sat, 13 Sep 2003 11:06:10 -0400 Message-ID: Date: Sat, 13 Sep 2003 11:06:10 -0400 Reply-To: Mailing List Sender: Mailing List From: Igor Miroshnik Subject: Incremental update of Fletcher's checksum To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Dear All, Why should one wish to bother with this? Well, I thought not to issue a new LSA if it differs from the predecessor merely in the sequence number. (Unless the sequence is promoted on purpose.) The checksum comparison is a reasonable first measure for decision on identity of two instances. Thus, one would first compute the checksum for the old instance with the old sequence number, and then, if needed, do the same with the next sequence number. Doing the things incrementally would save some effort. 1) May the Fletcher's checksum be updated incrementally? 2) Does anybody know another way to effectively determine the need of promoting the sequence? Thanks, Igor From owner-ospf@PEACH.EASE.LSOFT.COM Sat Sep 13 11:19:55 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21191 for ; Sat, 13 Sep 2003 11:19:54 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00B7E7B9@cherry.ease.lsoft.com>; Sat, 13 Sep 2003 11:20:00 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 54898551 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 13 Sep 2003 11:19:27 -0400 Received: from 205.152.59.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 13 Sep 2003 11:09:26 -0400 Received: from jdbws ([68.211.171.112]) by imf16aec.mail.bellsouth.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP id <20030913150926.BONH21511.imf16aec.mail.bellsouth.net@jdbws> for ; Sat, 13 Sep 2003 11:09:26 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C379E7.D2A0DDB0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: <000001c37a09$59b27db0$0b01a8c0@jdbws> Date: Sat, 13 Sep 2003 11:11:47 -0400 Reply-To: Mailing List Sender: Mailing List From: "Jeremy D. Buford" Subject: unsubscribe To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C379E7.D2A0DDB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ------=_NextPart_000_0001_01C379E7.D2A0DDB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

------=_NextPart_000_0001_01C379E7.D2A0DDB0-- From owner-ospf@PEACH.EASE.LSOFT.COM Sat Sep 13 12:10:44 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22173 for ; Sat, 13 Sep 2003 12:10:43 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00B7ED51@cherry.ease.lsoft.com>; Sat, 13 Sep 2003 12:10:49 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 54899645 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 13 Sep 2003 12:08:05 -0400 Received: from 61.140.60.50 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 13 Sep 2003 11:58:05 -0400 Received: from [192.168.0.13]([127.0.0.1]) by 21cn.com(AIMC 2.9.5.6) with SMTP id jm43f634ae8; Sun, 14 Sep 2003 00:00:53 +0800 Received: from [192.168.0.13]([211.80.36.21]) by 21cn.com(AIMC 2.9.5.4) with SMTP id AISP action; Sun, 14 Sep 2003 00:00:41 +0800 References: <000001c37a09$59b27db0$0b01a8c0@jdbws> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.06.02 X-AIMC-AUTH: xiaoguiwxd X-AIMC-MAILFROM: xiaoguiwxd@21cn.com Message-ID: <20030813235525.7A7F.XIAOGUIWXD@21cn.com> Date: Wed, 13 Aug 2003 23:55:36 +0800 Reply-To: Mailing List Sender: Mailing List From: wxd Subject: unsubscribe To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000001c37a09$59b27db0$0b01a8c0@jdbws> Precedence: list Content-Transfer-Encoding: 7bit -- wxd From owner-ospf@PEACH.EASE.LSOFT.COM Sun Sep 14 20:41:07 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20320 for ; Sun, 14 Sep 2003 20:41:06 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00B8C228@cherry.ease.lsoft.com>; 14 Sep 2003 20:41:07 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 54993696 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 14 Sep 2003 20:25:15 -0400 Received: from 156.147.1.151 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 14 Sep 2003 20:15:15 -0400 Received: from [150.150.41.210] (hongjm@lge.com) by mail1.lge.co.kr (Terrace Internet Messaging Server) with ESMTP id 2003091509:02:37:572914.3140.10 for ; Mon, 15 Sep 2003 09:02:37 +0900 (KST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C37B69.1C0A3780" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: Date: Mon, 15 Sep 2003 09:09:46 +0900 Reply-To: Mailing List Sender: Mailing List From: ??? Subject: unsubscribe To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000001c37a09$59b27db0$0b01a8c0@jdbws> Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C37B69.1C0A3780 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 DQogIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogIEZyb206IE1haWxpbmcgTGlzdCBbbWFp bHRvOk9TUEZAUEVBQ0guRUFTRS5MU09GVC5DT01dDQogIFNlbnQ6IFN1bmRheSwgU2VwdGVtYmVy IDE0LCAyMDAzIDEyOjEyIEFNDQogIFRvOiBPU1BGQFBFQUNILkVBU0UuTFNPRlQuQ09NDQogIFN1 YmplY3Q6IHVuc3Vic2NyaWJlDQoNCg0KDQo= ------=_NextPart_000_0004_01C37B69.1C0A3780 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXVzLWFzY2lpIj4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI4MDAuMTIyNiIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+QHBhZ2UgU2VjdGlvbjEge3Np emU6IDguNWluIDExLjBpbjsgbWFyZ2luOiAxLjBpbiAxLjI1aW4gMS4waW4gMS4yNWluOyB9DQpQ Lk1zb05vcm1hbCB7DQoJRk9OVC1TSVpFOiAxMnB0OyBNQVJHSU46IDBpbiAwaW4gMHB0OyBGT05U LUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiINCn0NCkxJLk1zb05vcm1hbCB7DQoJRk9OVC1TSVpF OiAxMnB0OyBNQVJHSU46IDBpbiAwaW4gMHB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21h biINCn0NCkRJVi5Nc29Ob3JtYWwgew0KCUZPTlQtU0laRTogMTJwdDsgTUFSR0lOOiAwaW4gMGlu IDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iDQp9DQpBOmxpbmsgew0KCUNPTE9S OiBibHVlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5Nc29IeXBlcmxpbmsg ew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KQTp2aXNpdGVk IHsNCglDT0xPUjogcHVycGxlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5N c29IeXBlcmxpbmtGb2xsb3dlZCB7DQoJQ09MT1I6IHB1cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1 bmRlcmxpbmUNCn0NClNQQU4uRW1haWxTdHlsZTE3IHsNCglDT0xPUjogd2luZG93dGV4dDsgRk9O VC1GQU1JTFk6IEFyaWFsDQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6IFNlY3Rpb24xDQp9DQo8 L1NUWUxFPg0KPC9IRUFEPg0KPEJPRFkgbGFuZz1FTi1VUyB2TGluaz1wdXJwbGUgbGluaz1ibHVl Pg0KPERJVj4mbmJzcDs8L0RJVj4NCjxCTE9DS1FVT1RFIGRpcj1sdHIgc3R5bGU9Ik1BUkdJTi1S SUdIVDogMHB4Ij4NCiAgPERJViBjbGFzcz1PdXRsb29rTWVzc2FnZUhlYWRlciBkaXI9bHRyIGFs aWduPWxlZnQ+PEZPTlQgZmFjZT1UYWhvbWEgDQogIHNpemU9Mj4tLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLTxCUj48Qj5Gcm9tOjwvQj4gTWFpbGluZyBMaXN0IA0KICBbbWFpbHRvOk9TUEZAUEVB Q0guRUFTRS5MU09GVC5DT01dPEJSPjxCPlNlbnQ6PC9CPiBTdW5kYXksIFNlcHRlbWJlciAxNCwg MjAwMyANCiAgMTI6MTIgQU08QlI+PEI+VG86PC9CPiBPU1BGQFBFQUNILkVBU0UuTFNPRlQuQ09N PEJSPjxCPlN1YmplY3Q6PC9CPiANCiAgdW5zdWJzY3JpYmU8QlI+PEJSPjwvRk9OVD48L0RJVj4N CiAgPERJViBjbGFzcz1TZWN0aW9uMT4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0 Ij48L1NQQU4+PC9GT05UPiZuYnNwOzwvUD48L0RJVj48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRN TD4NCg== ------=_NextPart_000_0004_01C37B69.1C0A3780-- From owner-ospf@PEACH.EASE.LSOFT.COM Sun Sep 14 23:18:45 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25031 for ; Sun, 14 Sep 2003 23:18:45 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00B8C5EC@cherry.ease.lsoft.com>; 14 Sep 2003 23:18:49 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55006354 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 14 Sep 2003 23:15:53 -0400 Received: from 61.144.161.41 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 14 Sep 2003 23:15:53 -0400 Received: from liuyu18957n (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HL800AF1JO5OK@mta0.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Mon, 15 Sep 2003 11:14:30 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 5.50.4927.1200 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <20030910101325.2920.qmail@webmail35.rediffmail.com> Message-ID: <000401c37b37$852de0e0$938a6e0a@HUAWEI.COM> Date: Mon, 15 Sep 2003 11:14:47 +0800 Reply-To: Mailing List Sender: Mailing List From: Liuyu Subject: Re: Inter-area routes reachable via multiple areas To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: base64 SSBoYXZlIHJlYWQgUkZDIDM1MDk6QWx0ZXJuYXRpdmUgSW1wbGVtZW50YXRpb25zIG9mIE9TUEYg QXJlYSBCb3JkZXIgUm91dGVycw0KDQpCdXQgaXQgc3RpbGwgZG9lcyBub3QgZXhwbGljaXRseSBz dGF0ZSBob3cgdG8gIGNob29zZSBhIGludGVyLWFyZWEgcm91dGUgZnJvbSBtdWx0aSBhc3NvY2lh dGVkIGFyZWFzLg0KDQpGb3IgZXhhbXBsZToNClIzIGF0dGFjaGVzIHRvIEFyZWEgMiBhbmQgQXJl YSAxLCBidXQgaXQgaXMgbm90IGEgQUJSIGFjcnJvZGluZyB0byBSRkMgMzUwOS4NCldoZW4gUjMg Y2FjdWxhdGUgdGhlIHJvdXRlIHRvIGludGVyLWFyZWEgcm91dGUgTmV0IEssIGl0IHdpbGwgZmlu ZCBvbmUgd2l0aCBuZXh0IGhvcCB0byBSMg0Kd2l0aCBtZXRyaWMgZXF1YWwgdG8gNCBpbiBBcmVh IDEgYW5kIHRoZSBvdGhlciBvbmUgd2l0aCBuZXh0IGhvcCBzZXQgdG8gUjQgd2l0aCB0aGUgc2Ft ZSBtZXRyaWMuDQoNCkhvdyB3aWxsIFIzIGluc3RhbGwgdGhlIGludGVyLWFyZWEgcm91dGUgTmV0 IEsgaW4gaXRzIHJvdXRpbmcgdGFibGU/ICBIdWF3ZWkncyBWUlAgd2lsbCBjaG9vc2UgdGhlIGxh dGVzdA0KY2FjdWxhdGVkIHJvdXRlLg0KDQpBcyB5b3Uga29udyAsIHRoZSBFQ01QIGluIE9TUEYg bXVzdCAgYmUgdGhlIHNhbWUgdHlwZSBhbmQgaW4gdGhlIHNhbWUgYXJlYS4NCg0KVGhhbmtzIGEg bG90IQ0KDQogICAgICAgICAgICAgICAgICAgICAgLiAgICAgICAgQmFja2JvbmUgICAgICAgICAu DQogICAgICAgICAgICAgICAgICAgICAuICAgICAgICAgICBOZXQgSyAgICAgICAgICAgLg0KICAg ICAgICAgICAgICAgICAgICAgLiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLSAgIC4NCiAgICAgICAg ICAgICAgICAgICAgICAuICAgfDEgICAgICAgICAgICAgICAxfCAgIC4NCiAgICAgICAgICAgICAg ICAgICAgICAgLi4rLS0rLi4uLi4uLi4uLi4uListLSsuLg0KICAgICAgICAgICAgICAgICAgICAg ICAuLnxSMXwuLi4uLiAgICAuLi4ufFI0fC4uDQogICAgICAgICAgICAgICAgICAgICAgLiAgKy0t KyAgICAgLiAgLiAgICArLS0rICAuDQogICAgICAgICAgICAgICAgICAgICAgLiAgIDF8ICAgICAg LiAgLiAgICAgLzQgICAuDQogICAgICAgICAgICAgICAgICAgICAgLiAgICB8ICAgIDIgKy0tKyA0 ICAvICAgICAuDQogICAgICAgICAgICAgICAgICAgICAgLiAgICB8ICAgICstfFIzfC0tLSsgICAg ICAuDQogICAgICAgICAgICAgICAgICAgICAgLiAgIDF8ICAgLyAgKy0tK1w0ICAgICAgICAuDQog ICAgICAgICAgICAgICAgICAgICAgLiAgKy0tKyAvICAgLiAgLiBcIDQgKy0tKyAuDQogICAgICAg ICAgICAgICAgICAgICAgLiAgfFIyfC8yICAgLiAgLiAgKy0tfFI1fCAuDQogICAgICAgICAgICAg ICAgICAgICAgLiAgKy0tKyAgICAgLiAgLiAgICAgKy0tKyAuDQogICAgICAgICAgICAgICAgICAg ICAgLiAgIHwgICAgICAgLiAgLiAgICAgICB8ICAuDQogICAgICAgICAgICAgICAgICAgICAgLiAt LS0tLS0tLS0gLiAgLiAtLS0tLS0tLSAuDQogICAgICAgICAgICAgICAgICAgICAgLiAgIG5ldCBO ICAgLiAgLiAgbmV0IE0gICAuDQogICAgICAgICAgICAgICAgICAgICAgLiAgICAgICAgICAgLiAg LiAgICAgICAgICAuDQogICAgICAgICAgICAgICAgICAgICAgLiAgQXJlYSAxICAgLiAgLiAgQXJl YSAyICAuDQogICAgICAgICAgICAgICAgICAgICAgIC4uLi4uLi4uLi4uICAgIC4uLi4uLi4uLi4N Cg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlZpdmVrIER1YmV5IiA8 dml2ZWtfb3NwZkBSRURJRkZNQUlMLkNPTT4NClRvOiA8T1NQRkBQRUFDSC5FQVNFLkxTT0ZULkNP TT4NClNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDEwLCAyMDAzIDY6MTMgUE0NClN1YmplY3Q6 IFJlOiBJbnRlci1hcmVhIHJvdXRlcyByZWFjaGFibGUgdmlhIG11bHRpcGxlIGFyZWFzDQoNCg0K VGhlIGNhc2Ugc2hvdWxkIG5vdCBvY2N1ciBpbiBjYXNlIG9mIHN0YW5kYXJkIEFCUiBpbXBsZW1l bnRhdGlvbnMgZm9yIGludGVyLWFyZWEgcm91dGUgY2FsY3VsYXRpb25zLg0KQ0lTQ08vSUJNIEFC UiBpbXBsZW1lbnRhdGlvbnMgbWlnaHQgbGVhZCB0byBzdWNoIHNjZW5hcmlvLg0KDQpWaXZlaw0K DQoNCg0KDQpPbiBXZWQsIDEwIFNlcCAyMDAzIExpdSBZdSB3cm90ZSA6DQo+SGkhIGFsbA0KPg0K Pkkgbm90aWNlIHRoYXQgdGhlIGNsYXVzZSBpbiAgUkZDIDIzMjggMTYuNCAoMykgaXMganVzdCBm b3IgZXh0ZXJuYWwgcm91dGUuDQo+SG93IGFib3V0ICJpbnRlci1hcmVhIHJvdXRlcyLvvFkgUkZD IDIzMjggZG9lcyBub3QgZXhwbGljaXRseSBzdGF0ZSB0aGlzDQo+b25lISBKdXN0IGNob29zZSB0 aGUgInRoZSBwYXRoIHdob3NlIGFzc29jaWF0ZWQgYXJlYSBoYXMgdGhlDQo+bGFyZ2VzdCBPU1BG IEFyZWEgSUQgIu+8We+8WSBNYXliZSBldmVyeSBvbmUgaGFzIGhpcyBvd24gaW1wbGVudGF0aW9u Lg0KPg0KPg0KPnRoYW5rcyENCj4NCj4NCj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+ IEZyb206ICJBY2VlIExpbmRlbSIgPGFjZWVAUkVEQkFDSy5DT00+DQo+VG86IDxPU1BGQFBFQUNI LkVBU0UuTFNPRlQuQ09NPg0KPlNlbnQ6IEZyaWRheSwgQXVndXN0IDAxLCAyMDAzIDU6NDYgQU0N Cj5TdWJqZWN0OiBSZTogQVNCUiByZWFjaGFibGUgdmlhIG11bHRpcGxlIGFyZWFzDQo+DQo+DQo+ ID4gUm9iLA0KPiA+DQo+ID4gWW91IGFyZSBjb3JyZWN0IC0gSSBtaXNzZWQgdGhhdCBjbGF1c2Ug aW4gMTYuNCAoMykgd2hlbg0KPiA+IHJlLXJlYWRpbmcuIEkgc2hvdWxkIGhhdmUgY2hlY2tlZCBt eSBpbXBsZW1lbnRhdGlvbiBiZWZvcmUNCj4gPiByZXBseWluZy4gSSBjYW4ndCBlbnZpc2lvbiB3 aHkgaW5zdGFsbGluZyBhbiBlcXVhbC1jb3N0cw0KPiA+IHJvdXRlcyB0aHJvdWdoIG11bHRpcGxl IGFyZWFzIHVzaW5nIHRoZSBzYW1lIDE2LjQuMSBzZWxlY3Rpb24NCj4gPiBydWxlcyBjb3VsZCBj YXVzZSBhIHJvdXRpbmcgbG9vcCBvciBvdGhlciBwcm9ibGVtLg0KPiA+DQo+ID4gVGhhbmtzLA0K PiA+IEFjZWUNCj4gPg0KPiA+IFJPQiBQQVRIIHdyb3RlOg0KPiA+ID4gLS0tIEFjZWUgTGluZGVt IDxhY2VlQFJFREJBQ0suQ09NPiB3cm90ZToNCj4gPiA+DQo+ID4gPj5JZ29yIE1pcm9zaG5payB3 cm90ZToNCj4gPiA+Pg0KPiA+ID4+PkFsbCwNCj4gPiA+Pj4NCj4gPiA+Pj4gICBSRkMgMTU4MyBz dGF0ZXM6ICJBUyBib3VuZGFyeSByb3V0ZXIncyByb3V0aW5nDQo+ID4gPj4NCj4gPiA+PnRhYmxl IGVudHJ5IG11c3QgaW5kaWNhdGUgYSBzZXQgb2YgcGF0aHMgd2hpY2gNCj4gPiA+Pg0KPiA+ID4+ PnV0aWxpemUgYSBzaW5nbGUgYXJlYS4iICgxNi4xKQ0KPiA+ID4+PiAgIFdoeSBub3QgdXRpbGl6 ZSBhbGwgZXF1YWwtY29zdCBwYXRocyB0aHJvdWdoDQo+ID4gPj4NCj4gPiA+PmRpZmZlcmVudCBh cmVhcz8NCj4gPiA+Pg0KPiA+ID4+SGkgSWdvciwNCj4gPiA+Pg0KPiA+ID4+SSBiZWxpZXZlIHlv dSBjYW4gY2FsY3VsYXRlIGVxdWFsIGNvc3QgcGF0aHMgdGhyb3VnaA0KPiA+ID4+bXVsdGlwbGUN Cj4gPiA+PmFyZWFzIC0gcmVhZCBzZWN0aW9uIDE2LjQgYW5kIDE2LjQuMSBpbiBSRkMgMjMyOA0K PiA+ID4+KHdoaWNoDQo+ID4gPj5vYnNvbGV0ZXMgUkZDIDIxNzggd2hpY2ggb2Jzb2xldGVzIFJG QyAxNTgzKS4NCj4gPiA+Pg0KPiA+ID4+DQo+ID4gPg0KPiA+ID4NCj4gPiA+IFRoZSBzZWN0aW9u IDE2LjQgaW4gUkZDIDIzMjggZG9lcyBub3QgZXhwbGljaXRseSBzdGF0ZQ0KPiA+ID4gdGhhdCBl cXVhbCBjb3N0IHBhdGhzIHRocm91Z2ggbXVsdGlwbGUgYXJlYXMgY291bGQgYmUNCj4gPiA+IHV0 aWxpemVkIChzYXkgZm9yIGxvYWQgYmFsYW5jaW5nIHB1cnBvc2VzKS4NCj4gPiA+DQo+ID4gPiBJ dCByYXRoZXIgc3RhdGVzIHRoYXQgd2hlbiB0aGVyZSBhcmUgbXVsdGlwbGUNCj4gPiA+IGxlYXN0 IGNvc3QgcGF0aHMgYXZhaWxhYmxlIGluIHRoZSByb3V0aW5nDQo+ID4gPiB0YWJsZSwgdGhlIHBh dGggd2hvc2UgYXNzb2NpYXRlZCBhcmVhIGhhcyB0aGUNCj4gPiA+IGxhcmdlc3QgT1NQRiBBcmVh IElEIGlzIGNob3Nlbi4NCj4gPiA+DQo+ID4gPiBBbHNvIHNlY3Rpb24gMTYuNC4xIHJlZmVycyB0 byBzZWN0aW9uIDE2LjQgZm9yDQo+ID4gPiBjaG9vc2luZyBhIHBhdGggYmFzZWQgb24gY29zdCwg d2hlbiB0aGVyZSBhcmUNCj4gPiA+IG11bHRpcGxlIHBhdGhzIG9mIGVxdWFsIGhpZ2hlc3QgcHJl ZmVyZW5jZXMuDQo+ID4gPg0KPiA+ID4gU28gaXQgZXNzZW50aWFsbHkgbWVhbnMgdGhhdCBtdWx0 aXBsZSBlcXVhbCBjb3N0DQo+ID4gPiBpbnRlci1hcmVhIHBhdGhzIGFyZSBub3QgdXRpbGl6ZWQu DQo+ID4gPg0KPiA+ID4gVGhhbmtzLA0KPiA+ID4gICAgIFJvYi4NCj4gPiA+DQo+ID4gPg0KPiA+ ID4NCj4gPiA+Pg0KPiA+ID4+PiAgIFRoYW5rcywNCj4gPiA+Pj4gICBJZ29yDQo+ID4gPj4+DQo+ ID4gPj4NCj4gPiA+Pg0KPiA+ID4+LS0NCj4gPiA+PkFjZWUNCj4gPiA+DQo+ID4gPg0KPiA+ID4N Cj4gPiA+ID09PT09DQo+ID4gPiBSb2IgUGF0aA0KPiA+ID4gRS1NYWlsIDogcm9iX3BhdGhAeWFo b28uY29tDQo+ID4gPg0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+ID4gRG8geW91IFlhaG9vIT8NCj4gPiA+IFlhaG9vISBTaXRlQnVpbGRlciAtIEZyZWUsIGVh c3ktdG8tdXNlIHdlYiBzaXRlIGRlc2lnbiBzb2Z0d2FyZQ0KPiA+ID4gaHR0cDovL3NpdGVidWls ZGVyLnlhaG9vLmNvbQ0KPiA+ID4NCj4gPg0KPiA+DQo+ID4gLS0NCj4gPiBBY2VlDQo+DQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTWVkaWNp bmUgbWVldHMgTWFya2V0aW5nOyBEci4gU3dhdGkgV2VkcyBKYXlhcmFtLg0KUmVkaWZmIE1hdGNo bWFrZXIgc3RyaWtlcyBhbm90aGVyIGludGVyZXN0aW5nIG1hdGNoICEhDQpWaXNpdCBodHRwOi8v cmVkaWZmLmNvbS9tYXRjaG1ha2VyPzINCg== From owner-ospf@PEACH.EASE.LSOFT.COM Mon Sep 15 02:10:49 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08690 for ; Mon, 15 Sep 2003 02:10:49 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00B8CAF0@cherry.ease.lsoft.com>; Mon, 15 Sep 2003 2:10:51 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55022704 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 15 Sep 2003 02:10:50 -0400 Received: from 66.28.8.211 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 15 Sep 2003 02:10:50 -0400 X-VirusChecked: Checked X-Env-Sender: rmalhotra@bankofny.com X-Msg-Ref: server-11.tower-20.messagelabs.com!1063606410!1985689 X-StarScan-Version: 5.0.7; banners=bankofny.com,-,- Received: (qmail 1881 invoked from network); 15 Sep 2003 06:13:30 -0000 Received: from unknown (HELO lgsbrc01.bankofny.com) (160.254.107.25) by server-11.tower-20.messagelabs.com with SMTP; 15 Sep 2003 06:13:30 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Message-ID: Date: Mon, 15 Sep 2003 02:10:48 -0400 Reply-To: Mailing List Sender: Mailing List From: rmalhotra@BANKOFNY.COM Subject: Ravi Malhotra is out of the office. To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list I will be out of the office starting 09/12/2003 and will not return until 09/17/2003. I will respond to your message when I return. Thank You, Ravi Malhotra ________________________________________________________________________ The information in this e-mail, and any attachment therein, is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although The Bank of New York attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. From owner-ospf@PEACH.EASE.LSOFT.COM Mon Sep 15 04:25:06 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17298 for ; Mon, 15 Sep 2003 04:25:06 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00B8CE66@cherry.ease.lsoft.com>; Mon, 15 Sep 2003 4:25:10 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55026097 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 15 Sep 2003 04:24:46 -0400 Received: from 171.71.176.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 15 Sep 2003 04:24:45 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 15 Sep 2003 01:24:45 -0700 Received: from cisco.com (megha.cisco.com [192.122.173.140]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h8F8OgS4018751 for ; Mon, 15 Sep 2003 01:24:43 -0700 (PDT) Received: from dmukunda-w2k.cisco.com ([10.77.139.63]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA29324; Mon, 15 Sep 2003 13:52:02 +0530 (IST) X-Sender: dmukunda@megha.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.2.7.2.20030915134101.00b3f3b0@megha.cisco.com> Date: Mon, 15 Sep 2003 13:54:40 +0530 Reply-To: Mailing List Sender: Mailing List From: "Divya Mukundan (dmukunda)" Subject: Re: RFC1850 - compilation error To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20030912181131.C7D90B6DC@xmxpita.excite.com> Precedence: list Don, Thanks for your tip. That did not work though :( I'm passing the following options to smicng. In addition to these, I tried compiling with -CT but that did not suppress the error. SMICOPTS = "-CF -C0N -CN -C0T -C03" Am I doing the right thing by adding CT to these options or does it conflict with any of the above? Thanks, -Divya At 02:11 PM 9/12/2003 -0400, Don Goodspeed wrote: >Divya, > >You can try using -CT. For more on smicng, contact Dave Perkins >at www.snmpinfo.com as he is the author of smicng. These option >are also described in his book "Understanding SNMP MIBs" which >is where I looked. > >-don > >==================================================== >Hi, > >I'm getting the following compilation error in "compliance statements" >of RFC1850 (OSPF-TRAP-MIB). I'm using smicng and Fred Baker >said that the MIB compiled with it and that smicng could have changed >subsequently. Is anyone aware of an option in smicng that can suppress >this error? Any other suggestions? > >-----------------------------------RFC1850-------------------------------------------- >-- compliance statements > >ospfTrapCompliance MODULE-COMPLIANCE >STATUS current >DESCRIPTION >"The compliance statement " >MODULE -- this module >MANDATORY-GROUPS { ospfTrapControlGroup } <<<==== > > >GROUP ospfTrapControlGroup <<<==== >DESCRIPTION >"This group is optional but recommended for all >OSPF systems" > > >-----------------------------------ERROR---------------------------------------------- >E: f(OSPF-TRAP-MIB.my), (470,21) Group "ospfTrapControlGroup" is both a >MANDATORY and conditional group for module "OSPF-TRAP-MIB" > >Thanks, >-Divya > >_______________________________________________ >Join Excite! - http://www.excite.com >The most personalized portal on the Web! From owner-ospf@PEACH.EASE.LSOFT.COM Mon Sep 15 12:30:28 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10512 for ; Mon, 15 Sep 2003 12:30:27 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00B8ED43@cherry.ease.lsoft.com>; Mon, 15 Sep 2003 12:30:29 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55085695 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 15 Sep 2003 12:04:04 -0400 Received: from 171.71.176.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 15 Sep 2003 12:04:02 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h8FG40Xq027165 for ; Mon, 15 Sep 2003 09:04:01 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ALO29629; Mon, 15 Sep 2003 08:52:15 -0700 (PDT) X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.0.0.22.2.20030915080011.04255368@mira-sjc5-b.cisco.com> Date: Mon, 15 Sep 2003 09:03:48 -0700 Reply-To: Mailing List Sender: Mailing List From: Fred Baker Subject: Re: Incremental update of Fletcher's checksum To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list At 08:06 AM 9/13/2003, Igor Miroshnik wrote: >1) May the Fletcher's checksum be updated incrementally? Yes. ISO DIS 8473 (CLNS) actually requires that to be done, and specifies in Annex C how to go about it. Of course, the copy of DIS 8473 I have doesn't actually have such a section, although it refers to it... From owner-ospf@PEACH.EASE.LSOFT.COM Mon Sep 15 14:58:31 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19515 for ; Mon, 15 Sep 2003 14:58:30 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00B90E08@cherry.ease.lsoft.com>; Mon, 15 Sep 2003 14:58:32 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55098626 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 15 Sep 2003 14:58:31 -0400 Received: from 207.159.120.60 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 15 Sep 2003 14:58:31 -0400 Received: by xmxpita.excite.com (Postfix, from userid 110) id 928AE3DF5; Mon, 15 Sep 2003 14:58:28 -0400 (EDT) Received: from [64.47.48.10] by xprdmailfe9.nwk.excite.com via HTTP; Mon, 15 Sep 2003 14:58:28 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = ce00c10647f1b9e7db16a67db0936ee4 MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20030915185828.928AE3DF5@xmxpita.excite.com> Date: Mon, 15 Sep 2003 14:58:28 -0400 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: RFC1850 - compilation error Comments: To: dmukunda@CISCO.COM To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Divya, I think so, so at this point, it's probably best to contact Dave Perkins at snmpinfo.com. An alternate source within Cisco might be Simon Chow who I used to work for and also knows Dave and knows smic and smicng. -don =================================== Don, Thanks for your tip. That did not work though :( I'm passing the following options to smicng. In addition to these, I tried compiling with -CT but that did not suppress the error. SMICOPTS = "-CF -C0N -CN -C0T -C03" Am I doing the right thing by adding CT to these options or does it conflict with any of the above? Thanks, -Divya At 02:11 PM 9/12/2003 -0400, Don Goodspeed wrote: >Divya, > >You can try using -CT. For more on smicng, contact Dave Perkins >at www.snmpinfo.com as he is the author of smicng. These option >are also described in his book "Understanding SNMP MIBs" which >is where I looked. > >-don > _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ospf@PEACH.EASE.LSOFT.COM Tue Sep 16 15:10:40 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03655 for ; Tue, 16 Sep 2003 15:10:40 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00B98BCD@cherry.ease.lsoft.com>; Tue, 16 Sep 2003 15:10:43 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55229293 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 16 Sep 2003 15:10:40 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 16 Sep 2003 15:10:40 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 425EC7A9801 for ; Tue, 16 Sep 2003 12:10:39 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030910101325.2920.qmail@webmail35.rediffmail.com> <000401c37b37$852de0e0$938a6e0a@HUAWEI.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Message-ID: <3F6760CF.9070705@redback.com> Date: Tue, 16 Sep 2003 15:13:19 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Inter-area routes reachable via multiple areas To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000401c37b37$852de0e0$938a6e0a@HUAWEI.COM> Precedence: list Content-Transfer-Encoding: 8bit Liuyu wrote: > I have read RFC 3509:Alternative Implementations of OSPF Area Border Routers > > But it still does not explicitly state how to choose a inter-area route from multi associated areas. > > For example: > R3 attaches to Area 2 and Area 1, but it is not a ABR acrroding to RFC 3509. > When R3 caculate the route to inter-area route Net K, it will find one with next hop to R2 > with metric equal to 4 in Area 1 and the other one with next hop set to R4 with the same metric. > > How will R3 install the inter-area route Net K in its routing table? Huawei's VRP will choose the latest > caculated route. > > As you konw , the ECMP in OSPF must be the same type and in the same area. Note that RFC 3509 is an informational RFC and not a standard. Therefore, you shouldn't treat it as such. In this situation, I see no reason why you couldn't install an ECMP route. > > Thanks a lot! > > . Backbone . > . Net K . > . --------------------- . > . |1 1| . > ..+--+.............+--+.. > ..|R1|..... ....|R4|.. > . +--+ . . +--+ . > . 1| . . /4 . > . | 2 +--+ 4 / . > . | +-|R3|---+ . > . 1| / +--+\4 . > . +--+ / . . \ 4 +--+ . > . |R2|/2 . . +--|R5| . > . +--+ . . +--+ . > . | . . | . > . --------- . . -------- . > . net N . . net M . > . . . . > . Area 1 . . Area 2 . > ........... .......... > > > ----- Original Message ----- > From: "Vivek Dubey" > To: > Sent: Wednesday, September 10, 2003 6:13 PM > Subject: Re: Inter-area routes reachable via multiple areas > > > The case should not occur in case of standard ABR implementations for inter-area route calculations. > CISCO/IBM ABR implementations might lead to such scenario. > > Vivek > > > > > On Wed, 10 Sep 2003 Liu Yu wrote : > >>Hi! all >> >>I notice that the clause in RFC 2328 16.4 (3) is just for external route. >>How about "inter-area routes"ï¼Y RFC 2328 does not explicitly state this >>one! Just choose the "the path whose associated area has the >>largest OSPF Area ID "ï¼Yï¼Y Maybe every one has his own implentation. >> >> >>thanks! >> >> >>----- Original Message ----- >>From: "Acee Lindem" >>To: >>Sent: Friday, August 01, 2003 5:46 AM >>Subject: Re: ASBR reachable via multiple areas >> >> >> >>>Rob, >>> >>>You are correct - I missed that clause in 16.4 (3) when >>>re-reading. I should have checked my implementation before >>>replying. I can't envision why installing an equal-costs >>>routes through multiple areas using the same 16.4.1 selection >>>rules could cause a routing loop or other problem. >>> >>>Thanks, >>>Acee >>> >>>ROB PATH wrote: >>> >>>>--- Acee Lindem wrote: >>>> >>>> >>>>>Igor Miroshnik wrote: >>>>> >>>>> >>>>>>All, >>>>>> >>>>>> RFC 1583 states: "AS boundary router's routing >>>>> >>>>>table entry must indicate a set of paths which >>>>> >>>>> >>>>>>utilize a single area." (16.1) >>>>>> Why not utilize all equal-cost paths through >>>>> >>>>>different areas? >>>>> >>>>>Hi Igor, >>>>> >>>>>I believe you can calculate equal cost paths through >>>>>multiple >>>>>areas - read section 16.4 and 16.4.1 in RFC 2328 >>>>>(which >>>>>obsoletes RFC 2178 which obsoletes RFC 1583). >>>>> >>>>> >>>> >>>> >>>>The section 16.4 in RFC 2328 does not explicitly state >>>>that equal cost paths through multiple areas could be >>>>utilized (say for load balancing purposes). >>>> >>>>It rather states that when there are multiple >>>>least cost paths available in the routing >>>>table, the path whose associated area has the >>>>largest OSPF Area ID is chosen. >>>> >>>>Also section 16.4.1 refers to section 16.4 for >>>>choosing a path based on cost, when there are >>>>multiple paths of equal highest preferences. >>>> >>>>So it essentially means that multiple equal cost >>>>inter-area paths are not utilized. >>>> >>>>Thanks, >>>> Rob. >>>> >>>> >>>> >>>> >>>>>> Thanks, >>>>>> Igor >>>>>> >>>>> >>>>> >>>>>-- >>>>>Acee >>>> >>>> >>>> >>>>===== >>>>Rob Path >>>>E-Mail : rob_path@yahoo.com >>>> >>>>__________________________________ >>>>Do you Yahoo!? >>>>Yahoo! SiteBuilder - Free, easy-to-use web site design software >>>>http://sitebuilder.yahoo.com >>>> >>> >>> >>>-- >>>Acee >> > > ___________________________________________________ > Medicine meets Marketing; Dr. Swati Weds Jayaram. > Rediff Matchmaker strikes another interesting match !! > Visit http://rediff.com/matchmaker?2 -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Tue Sep 16 17:23:24 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13294 for ; Tue, 16 Sep 2003 17:23:24 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00B99B84@cherry.ease.lsoft.com>; Tue, 16 Sep 2003 17:23:29 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55088057 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 16 Sep 2003 17:23:27 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 16 Sep 2003 17:23:27 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 33872628DC0; Tue, 16 Sep 2003 14:22:24 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F677FAF.8080803@redback.com> Date: Tue, 16 Sep 2003 17:25:03 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Comments on draft-ietf-ospf-2547-dnbit-00.txt Comments: To: Eric Rosen To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Eric, Here are my comments: Section 2 Introduction The terminology is somewhat confusing. Normally, we "export" or "redistribute" routes rather than "convert" them. In this case routes are being installed from backbone BGP into the VPN route table. When they are redistributed (or exported) into the OSPF in the VPN they are advertised as summary and AS external LSAs. Similarly, routes that OSPF installs into the VPN route table will be redistributed and advertised across the VPN backbone. Section 3 Replace all instances of "decision process" with "routing computation". The text in parenthesis (The reader will note...) should be explained better or removed. The OSPF-VPN draft dictates that a PE router has to be part of area 0. If it is part of area 0, the summaries in area 0 are used for the route computation and hence feedback is prevented if the PE-CE connection is not in area 0. With the generalized use of the DN bit, the PE area 0 restriction could be relaxed a bit to say that the PE router must advertise itself as an ABR (via its router bits in its router LSA) and the CE routers must not have any area 0 connections when the PE router connection isn't an area 0 connection. However, I'm not sure there is a requirement since no has complained heretofore. Section 4 Please add a diagram of the OSPF options bits with the DN bit included. -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed Sep 17 10:34:16 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15280 for ; Wed, 17 Sep 2003 10:34:15 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00B9EF07@cherry.ease.lsoft.com>; Wed, 17 Sep 2003 10:34:19 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55186793 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 17 Sep 2003 10:34:17 -0400 Received: from 216.136.226.178 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 17 Sep 2003 10:24:16 -0400 Received: from [65.194.140.2] by web20705.mail.yahoo.com via HTTP; Wed, 17 Sep 2003 07:24:16 PDT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-202961741-1063808656=:97796" Message-ID: <20030917142416.98604.qmail@web20705.mail.yahoo.com> Date: Wed, 17 Sep 2003 07:24:16 -0700 Reply-To: Mailing List Sender: Mailing List From: vj cadman Subject: ospfv3 MIB - ospfv3NbrTable To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --0-202961741-1063808656=:97796 Content-Type: text/plain; charset=us-ascii Regarding the ospfv3NbrIfIndex defined in the ospfv3NbrTable for ospfv3 MIB, is it the neighbor's interface ID specified in the neighbor's hello packet? Thanks, Viva --------------------------------- Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software --0-202961741-1063808656=:97796 Content-Type: text/html; charset=us-ascii
Regarding the ospfv3NbrIfIndex defined in the ospfv3NbrTable for ospfv3 MIB, is it the neighbor's interface ID specified in the neighbor's hello packet?
 
Thanks,
Viva

Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software --0-202961741-1063808656=:97796-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Sep 17 10:39:22 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15409 for ; Wed, 17 Sep 2003 10:39:22 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00B9EF26@cherry.ease.lsoft.com>; Wed, 17 Sep 2003 10:39:28 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55188412 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 17 Sep 2003 10:39:26 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 17 Sep 2003 10:39:26 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id BF6167E9F22 for ; Wed, 17 Sep 2003 07:39:25 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030917142416.98604.qmail@web20705.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F6872B3.5020108@redback.com> Date: Wed, 17 Sep 2003 10:41:55 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: ospfv3 MIB - ospfv3NbrTable To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20030917142416.98604.qmail@web20705.mail.yahoo.com> Precedence: list Content-Transfer-Encoding: 7bit vj cadman wrote: > Regarding the ospfv3NbrIfIndex defined in the ospfv3NbrTable for ospfv3 > MIB, is it the neighbor's interface ID specified in the neighbor's hello > packet? Hi Viva, Nope - it is your own interface ID. ospfv3NbrIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "The local link ID of the link over which the ~~~~~~~~~~~~~ neighbor can be reached." ::= { ospfv3NbrEntry 1 } > > Thanks, > Viva > > ------------------------------------------------------------------------ > Do you Yahoo!? > Yahoo! SiteBuilder > - Free, > easy-to-use web site design software -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed Sep 17 20:02:06 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07056 for ; Wed, 17 Sep 2003 20:02:05 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00BA2EA6@cherry.ease.lsoft.com>; Wed, 17 Sep 2003 20:02:09 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55237449 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 17 Sep 2003 20:01:39 -0400 Received: from 207.217.120.120 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 17 Sep 2003 20:01:38 -0400 Received: from user-2ivfmo8.dialup.mindspring.com ([165.247.219.8] helo=earthlink.net) by albatross.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19zmEs-0004VQ-00 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 17 Sep 2003 17:01:38 -0700 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <20030917142416.98604.qmail@web20705.mail.yahoo.com> <3F6872B3.5020108@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3F68F3E3.BA0D0820@earthlink.net> Date: Wed, 17 Sep 2003 16:53:08 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: draft-ietf-ospf-cap-00.txt : Inconsistency Questions To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, I think I am dense because I have a couple of questions that doesn't seem to be resolved in this "work-in-progress". :) 1) If we look at just one capability specified in this draft: Stub router support via bit 6. This is RFC 3137 from June 2001. I will make the assumption that some routers support this RFC, but don't yet support the capability "work-in-progress". In this case, the absense of this RI Opaque LSA doesn't reflect the absense of this capability or in a more general sense, the absense of support for any of the capabilities of the specified bits. 2) Once this draft becomes a RFC and future drafts add more capability bits, then how should one determine that missing capibility bits means no capability versus not yet specified capability in the IR LSA. If the LSA field were incremented from a "4" to a "5" then we could make the distinction. A "4" would mean that it may have (0 - 3) and/or 10-31 capabilities, and a "5" with capabilites not yet, means no capabilities. 3) Can the LSA be specified as a DNA (Do not age) LSA? Mitchell Erblich From owner-ospf@PEACH.EASE.LSOFT.COM Wed Sep 17 20:13:13 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07288 for ; Wed, 17 Sep 2003 20:13:13 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00BA2D50@cherry.ease.lsoft.com>; Wed, 17 Sep 2003 20:13:19 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55238138 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 17 Sep 2003 20:13:17 -0400 Received: from 207.217.120.120 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 17 Sep 2003 20:13:17 -0400 Received: from user-2ivfmo8.dialup.mindspring.com ([165.247.219.8] helo=earthlink.net) by albatross.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19zmQ8-0007ZN-00 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 17 Sep 2003 17:13:17 -0700 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <20030917142416.98604.qmail@web20705.mail.yahoo.com> <3F6872B3.5020108@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3F68F69D.399329FD@earthlink.net> Date: Wed, 17 Sep 2003 17:04:45 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Stupid checksum and next LSA begining question To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, When given a "update packet with say 5 LSAs", and the 1st LSA in this packet has a checksum error, should the rest of the LSAs in the update be attempted to be processed? Note: If we have a checksum error, this means that the length and the start of the next LSA COULD be wrong. We could assume that checking the type of the next LSA could be within a valid LSA type range, and still not have the correct begining of the 2nd or 3rd ... LSAs. Is this behaviour specified anywhere? Mitchell Erblich Sr Software Engineer -------------------- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Sep 17 22:00:22 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09477 for ; Wed, 17 Sep 2003 22:00:21 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00BA41D7@cherry.ease.lsoft.com>; Wed, 17 Sep 2003 22:00:27 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55248200 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 17 Sep 2003 21:52:41 -0400 Received: from 61.144.161.40 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 17 Sep 2003 21:52:40 -0400 Received: from liuyu18957n (huawei.com [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HLD007KUZKFG5@mta1.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 18 Sep 2003 09:45:52 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Mailer: Microsoft Outlook Express 5.50.4927.1200 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <20030910101325.2920.qmail@webmail35.rediffmail.com> <000401c37b37$852de0e0$938a6e0a@HUAWEI.COM> <3F6760CF.9070705@redback.com> Message-ID: <003a01c37d87$62c80b00$938a6e0a@liuyu18957n> Date: Thu, 18 Sep 2003 09:51:31 +0800 Reply-To: Mailing List Sender: Mailing List From: Liu Yu Subject: Re: Inter-area routes reachable via multiple areas To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: base64 ICAgIEFjZWUgOg0KDQpQbGVhc2UgcmVhZCB0aGUgZm9sbG93aW5nIDoNCg0KUkZDIDIzMjg6IE9T UEYgDQoNClNlY3Rpb24gMTYuOCBFcXVhbC1jb3N0IG11bHRpcGF0aA0KIg0KRWFjaCBvbmUgb2Yg dGhlIG11bHRpcGxlIHJvdXRlcyB3aWxsIGJlCW9mIHRoZSBzYW1lIHR5cGUNCgkoaW50cmEtYXJl YSwgaW50ZXItYXJlYSwgdHlwZSAxCWV4dGVybmFsIG9yIHR5cGUgMiBleHRlcm5hbCksDQoJY29z dCwgYW5kIHdpbGwgaGF2ZSB0aGUgc2FtZSBhc3NvY2lhdGVkCWFyZWEuICBIb3dldmVyLCBlYWNo DQoJcm91dGUgbWF5IHNwZWNpZnkgYSBzZXBhcmF0ZSBuZXh0IGhvcCBhbmQgQWR2ZXJ0aXNpbmcg cm91dGVyLiINCg0KVGhhbmtzIQ0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJv bTogIkFjZWUgTGluZGVtIiA8YWNlZUBSRURCQUNLLkNPTT4NClRvOiA8T1NQRkBQRUFDSC5FQVNF LkxTT0ZULkNPTT4NClNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDE3LCAyMDAzIDM6MTMgQU0N ClN1YmplY3Q6IFJlOiBJbnRlci1hcmVhIHJvdXRlcyByZWFjaGFibGUgdmlhIG11bHRpcGxlIGFy ZWFzDQoNCg0KPiBMaXV5dSB3cm90ZToNCj4gPiBJIGhhdmUgcmVhZCBSRkMgMzUwOTpBbHRlcm5h dGl2ZSBJbXBsZW1lbnRhdGlvbnMgb2YgT1NQRiBBcmVhIEJvcmRlciBSb3V0ZXJzDQo+ID4NCj4g PiBCdXQgaXQgc3RpbGwgZG9lcyBub3QgZXhwbGljaXRseSBzdGF0ZSBob3cgdG8gIGNob29zZSBh IGludGVyLWFyZWEgcm91dGUgZnJvbSBtdWx0aSBhc3NvY2lhdGVkIGFyZWFzLg0KPiA+DQo+ID4g Rm9yIGV4YW1wbGU6DQo+ID4gUjMgYXR0YWNoZXMgdG8gQXJlYSAyIGFuZCBBcmVhIDEsIGJ1dCBp dCBpcyBub3QgYSBBQlIgYWNycm9kaW5nIHRvIFJGQyAzNTA5Lg0KPiA+IFdoZW4gUjMgY2FjdWxh dGUgdGhlIHJvdXRlIHRvIGludGVyLWFyZWEgcm91dGUgTmV0IEssIGl0IHdpbGwgZmluZCBvbmUg d2l0aCBuZXh0IGhvcCB0byBSMg0KPiA+IHdpdGggbWV0cmljIGVxdWFsIHRvIDQgaW4gQXJlYSAx IGFuZCB0aGUgb3RoZXIgb25lIHdpdGggbmV4dCBob3Agc2V0IHRvIFI0IHdpdGggdGhlIHNhbWUg bWV0cmljLg0KPiA+DQo+ID4gSG93IHdpbGwgUjMgaW5zdGFsbCB0aGUgaW50ZXItYXJlYSByb3V0 ZSBOZXQgSyBpbiBpdHMgcm91dGluZyB0YWJsZT8gIEh1YXdlaSdzIFZSUCB3aWxsIGNob29zZSB0 aGUgbGF0ZXN0DQo+ID4gY2FjdWxhdGVkIHJvdXRlLg0KPiA+DQo+ID4gQXMgeW91IGtvbncgLCB0 aGUgRUNNUCBpbiBPU1BGIG11c3QgIGJlIHRoZSBzYW1lIHR5cGUgYW5kIGluIHRoZSBzYW1lIGFy ZWEuDQo+IA0KPiBOb3RlIHRoYXQgUkZDIDM1MDkgaXMgYW4gaW5mb3JtYXRpb25hbCBSRkMgYW5k IG5vdCBhIHN0YW5kYXJkLiBUaGVyZWZvcmUsIHlvdQ0KPiBzaG91bGRuJ3QgdHJlYXQgaXQgYXMg c3VjaC4gSW4gdGhpcyBzaXR1YXRpb24sIEkgc2VlIG5vIHJlYXNvbiB3aHkgeW91IGNvdWxkbid0 DQo+IGluc3RhbGwgYW4gRUNNUCByb3V0ZS4NCj4gDQo+IA0KPiA+DQo+ID4gVGhhbmtzIGEgbG90 IQ0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICAgICAgIC4gICAgICAgIEJhY2tib25lICAgICAg ICAgLg0KPiA+ICAgICAgICAgICAgICAgICAgICAgIC4gICAgICAgICAgIE5ldCBLICAgICAgICAg ICAuDQo+ID4gICAgICAgICAgICAgICAgICAgICAgLiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLSAg IC4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgLiAgIHwxICAgICAgICAgICAgICAgMXwgICAu DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAuListLSsuLi4uLi4uLi4uLi4uKy0tKy4uDQo+ ID4gICAgICAgICAgICAgICAgICAgICAgICAuLnxSMXwuLi4uLiAgICAuLi4ufFI0fC4uDQo+ID4g ICAgICAgICAgICAgICAgICAgICAgIC4gICstLSsgICAgIC4gIC4gICAgKy0tKyAgLg0KPiA+ICAg ICAgICAgICAgICAgICAgICAgICAuICAgMXwgICAgICAuICAuICAgICAvNCAgIC4NCj4gPiAgICAg ICAgICAgICAgICAgICAgICAgLiAgICB8ICAgIDIgKy0tKyA0ICAvICAgICAuDQo+ID4gICAgICAg ICAgICAgICAgICAgICAgIC4gICAgfCAgICArLXxSM3wtLS0rICAgICAgLg0KPiA+ICAgICAgICAg ICAgICAgICAgICAgICAuICAgMXwgICAvICArLS0rXDQgICAgICAgIC4NCj4gPiAgICAgICAgICAg ICAgICAgICAgICAgLiAgKy0tKyAvICAgLiAgLiBcIDQgKy0tKyAuDQo+ID4gICAgICAgICAgICAg ICAgICAgICAgIC4gIHxSMnwvMiAgIC4gIC4gICstLXxSNXwgLg0KPiA+ICAgICAgICAgICAgICAg ICAgICAgICAuICArLS0rICAgICAuICAuICAgICArLS0rIC4NCj4gPiAgICAgICAgICAgICAgICAg ICAgICAgLiAgIHwgICAgICAgLiAgLiAgICAgICB8ICAuDQo+ID4gICAgICAgICAgICAgICAgICAg ICAgIC4gLS0tLS0tLS0tIC4gIC4gLS0tLS0tLS0gLg0KPiA+ICAgICAgICAgICAgICAgICAgICAg ICAuICAgbmV0IE4gICAuICAuICBuZXQgTSAgIC4NCj4gPiAgICAgICAgICAgICAgICAgICAgICAg LiAgICAgICAgICAgLiAgLiAgICAgICAgICAuDQo+ID4gICAgICAgICAgICAgICAgICAgICAgIC4g IEFyZWEgMSAgIC4gIC4gIEFyZWEgMiAgLg0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgLi4u Li4uLi4uLi4gICAgLi4uLi4uLi4uLg0KPiA+DQo+ID4NCj4gPiAtLS0tLSBPcmlnaW5hbCBNZXNz YWdlIC0tLS0tDQo+ID4gRnJvbTogIlZpdmVrIER1YmV5IiA8dml2ZWtfb3NwZkBSRURJRkZNQUlM LkNPTT4NCj4gPiBUbzogPE9TUEZAUEVBQ0guRUFTRS5MU09GVC5DT00+DQo+ID4gU2VudDogV2Vk bmVzZGF5LCBTZXB0ZW1iZXIgMTAsIDIwMDMgNjoxMyBQTQ0KPiA+IFN1YmplY3Q6IFJlOiBJbnRl ci1hcmVhIHJvdXRlcyByZWFjaGFibGUgdmlhIG11bHRpcGxlIGFyZWFzDQo+ID4NCj4gPg0KPiA+ IFRoZSBjYXNlIHNob3VsZCBub3Qgb2NjdXIgaW4gY2FzZSBvZiBzdGFuZGFyZCBBQlIgaW1wbGVt ZW50YXRpb25zIGZvciBpbnRlci1hcmVhIHJvdXRlIGNhbGN1bGF0aW9ucy4NCj4gPiBDSVNDTy9J Qk0gQUJSIGltcGxlbWVudGF0aW9ucyBtaWdodCBsZWFkIHRvIHN1Y2ggc2NlbmFyaW8uDQo+ID4N Cj4gPiBWaXZlaw0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gT24gV2VkLCAxMCBTZXAgMjAwMyBM aXUgWXUgd3JvdGUgOg0KPiA+DQo+ID4+SGkhIGFsbA0KPiA+Pg0KPiA+Pkkgbm90aWNlIHRoYXQg dGhlIGNsYXVzZSBpbiAgUkZDIDIzMjggMTYuNCAoMykgaXMganVzdCBmb3IgZXh0ZXJuYWwgcm91 dGUuDQo+ID4+SG93IGFib3V0ICJpbnRlci1hcmVhIHJvdXRlcyLvvFkgUkZDIDIzMjggZG9lcyBu b3QgZXhwbGljaXRseSBzdGF0ZSB0aGlzDQo+ID4+b25lISBKdXN0IGNob29zZSB0aGUgInRoZSBw YXRoIHdob3NlIGFzc29jaWF0ZWQgYXJlYSBoYXMgdGhlDQo+ID4+bGFyZ2VzdCBPU1BGIEFyZWEg SUQgIu+8We+8WSBNYXliZSBldmVyeSBvbmUgaGFzIGhpcyBvd24gaW1wbGVudGF0aW9uLg0KPiA+ Pg0KPiA+Pg0KPiA+PnRoYW5rcyENCj4gPj4NCj4gPj4NCj4gPj4tLS0tLSBPcmlnaW5hbCBNZXNz YWdlIC0tLS0tDQo+ID4+RnJvbTogIkFjZWUgTGluZGVtIiA8YWNlZUBSRURCQUNLLkNPTT4NCj4g Pj5UbzogPE9TUEZAUEVBQ0guRUFTRS5MU09GVC5DT00+DQo+ID4+U2VudDogRnJpZGF5LCBBdWd1 c3QgMDEsIDIwMDMgNTo0NiBBTQ0KPiA+PlN1YmplY3Q6IFJlOiBBU0JSIHJlYWNoYWJsZSB2aWEg bXVsdGlwbGUgYXJlYXMNCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4+Um9iLA0KPiA+Pj4NCj4gPj4+ WW91IGFyZSBjb3JyZWN0IC0gSSBtaXNzZWQgdGhhdCBjbGF1c2UgaW4gMTYuNCAoMykgd2hlbg0K PiA+Pj5yZS1yZWFkaW5nLiBJIHNob3VsZCBoYXZlIGNoZWNrZWQgbXkgaW1wbGVtZW50YXRpb24g YmVmb3JlDQo+ID4+PnJlcGx5aW5nLiBJIGNhbid0IGVudmlzaW9uIHdoeSBpbnN0YWxsaW5nIGFu IGVxdWFsLWNvc3RzDQo+ID4+PnJvdXRlcyB0aHJvdWdoIG11bHRpcGxlIGFyZWFzIHVzaW5nIHRo ZSBzYW1lIDE2LjQuMSBzZWxlY3Rpb24NCj4gPj4+cnVsZXMgY291bGQgY2F1c2UgYSByb3V0aW5n IGxvb3Agb3Igb3RoZXIgcHJvYmxlbS4NCj4gPj4+DQo+ID4+PlRoYW5rcywNCj4gPj4+QWNlZQ0K PiA+Pj4NCj4gPj4+Uk9CIFBBVEggd3JvdGU6DQo+ID4+Pg0KPiA+Pj4+LS0tIEFjZWUgTGluZGVt IDxhY2VlQFJFREJBQ0suQ09NPiB3cm90ZToNCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4+SWdvciBN aXJvc2huaWsgd3JvdGU6DQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+PkFsbCwNCj4gPj4+Pj4+ DQo+ID4+Pj4+PiAgUkZDIDE1ODMgc3RhdGVzOiAiQVMgYm91bmRhcnkgcm91dGVyJ3Mgcm91dGlu Zw0KPiA+Pj4+Pg0KPiA+Pj4+PnRhYmxlIGVudHJ5IG11c3QgaW5kaWNhdGUgYSBzZXQgb2YgcGF0 aHMgd2hpY2gNCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4+dXRpbGl6ZSBhIHNpbmdsZSBhcmVh LiIgKDE2LjEpDQo+ID4+Pj4+PiAgV2h5IG5vdCB1dGlsaXplIGFsbCBlcXVhbC1jb3N0IHBhdGhz IHRocm91Z2gNCj4gPj4+Pj4NCj4gPj4+Pj5kaWZmZXJlbnQgYXJlYXM/DQo+ID4+Pj4+DQo+ID4+ Pj4+SGkgSWdvciwNCj4gPj4+Pj4NCj4gPj4+Pj5JIGJlbGlldmUgeW91IGNhbiBjYWxjdWxhdGUg ZXF1YWwgY29zdCBwYXRocyB0aHJvdWdoDQo+ID4+Pj4+bXVsdGlwbGUNCj4gPj4+Pj5hcmVhcyAt IHJlYWQgc2VjdGlvbiAxNi40IGFuZCAxNi40LjEgaW4gUkZDIDIzMjgNCj4gPj4+Pj4od2hpY2gN Cj4gPj4+Pj5vYnNvbGV0ZXMgUkZDIDIxNzggd2hpY2ggb2Jzb2xldGVzIFJGQyAxNTgzKS4NCj4g Pj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj5UaGUgc2VjdGlvbiAxNi40IGlu IFJGQyAyMzI4IGRvZXMgbm90IGV4cGxpY2l0bHkgc3RhdGUNCj4gPj4+PnRoYXQgZXF1YWwgY29z dCBwYXRocyB0aHJvdWdoIG11bHRpcGxlIGFyZWFzIGNvdWxkIGJlDQo+ID4+Pj51dGlsaXplZCAo c2F5IGZvciBsb2FkIGJhbGFuY2luZyBwdXJwb3NlcykuDQo+ID4+Pj4NCj4gPj4+Pkl0IHJhdGhl ciBzdGF0ZXMgdGhhdCB3aGVuIHRoZXJlIGFyZSBtdWx0aXBsZQ0KPiA+Pj4+bGVhc3QgY29zdCBw YXRocyBhdmFpbGFibGUgaW4gdGhlIHJvdXRpbmcNCj4gPj4+PnRhYmxlLCB0aGUgcGF0aCB3aG9z ZSBhc3NvY2lhdGVkIGFyZWEgaGFzIHRoZQ0KPiA+Pj4+bGFyZ2VzdCBPU1BGIEFyZWEgSUQgaXMg Y2hvc2VuLg0KPiA+Pj4+DQo+ID4+Pj5BbHNvIHNlY3Rpb24gMTYuNC4xIHJlZmVycyB0byBzZWN0 aW9uIDE2LjQgZm9yDQo+ID4+Pj5jaG9vc2luZyBhIHBhdGggYmFzZWQgb24gY29zdCwgd2hlbiB0 aGVyZSBhcmUNCj4gPj4+Pm11bHRpcGxlIHBhdGhzIG9mIGVxdWFsIGhpZ2hlc3QgcHJlZmVyZW5j ZXMuDQo+ID4+Pj4NCj4gPj4+PlNvIGl0IGVzc2VudGlhbGx5IG1lYW5zIHRoYXQgbXVsdGlwbGUg ZXF1YWwgY29zdA0KPiA+Pj4+aW50ZXItYXJlYSBwYXRocyBhcmUgbm90IHV0aWxpemVkLg0KPiA+ Pj4+DQo+ID4+Pj5UaGFua3MsDQo+ID4+Pj4gICAgUm9iLg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+ Pg0KPiA+Pj4+DQo+ID4+Pj4+PiAgVGhhbmtzLA0KPiA+Pj4+Pj4gIElnb3INCj4gPj4+Pj4+DQo+ ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+LS0NCj4gPj4+Pj5BY2VlDQo+ID4+Pj4NCj4gPj4+Pg0K PiA+Pj4+DQo+ID4+Pj49PT09PQ0KPiA+Pj4+Um9iIFBhdGgNCj4gPj4+PkUtTWFpbCA6IHJvYl9w YXRoQHlhaG9vLmNvbQ0KPiA+Pj4+DQo+ID4+Pj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ID4+Pj5EbyB5b3UgWWFob28hPw0KPiA+Pj4+WWFob28hIFNpdGVCdWlsZGVyIC0g RnJlZSwgZWFzeS10by11c2Ugd2ViIHNpdGUgZGVzaWduIHNvZnR3YXJlDQo+ID4+Pj5odHRwOi8v c2l0ZWJ1aWxkZXIueWFob28uY29tDQo+ID4+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4tLQ0KPiA+ Pj5BY2VlDQo+ID4+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPiBNZWRpY2luZSBtZWV0cyBNYXJrZXRpbmc7IERyLiBTd2F0 aSBXZWRzIEpheWFyYW0uDQo+ID4gUmVkaWZmIE1hdGNobWFrZXIgc3RyaWtlcyBhbm90aGVyIGlu dGVyZXN0aW5nIG1hdGNoICEhDQo+ID4gVmlzaXQgaHR0cDovL3JlZGlmZi5jb20vbWF0Y2htYWtl cj8yDQo+IA0KPiAtLQ0KPiBBY2VlDQo= From owner-ospf@PEACH.EASE.LSOFT.COM Wed Sep 17 23:00:36 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11092 for ; Wed, 17 Sep 2003 23:00:35 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00BA4846@cherry.ease.lsoft.com>; Wed, 17 Sep 2003 23:00:40 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55254732 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 17 Sep 2003 22:59:12 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 17 Sep 2003 22:59:12 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id BB363692C44 for ; Wed, 17 Sep 2003 19:59:10 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030910101325.2920.qmail@webmail35.rediffmail.com> <000401c37b37$852de0e0$938a6e0a@HUAWEI.COM> <3F6760CF.9070705@redback.com> <003a01c37d87$62c80b00$938a6e0a@liuyu18957n> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Message-ID: <3F69200D.10405@redback.com> Date: Wed, 17 Sep 2003 23:01:33 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Inter-area routes reachable via multiple areas To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <003a01c37d87$62c80b00$938a6e0a@liuyu18957n> Precedence: list Content-Transfer-Encoding: 8bit Liu Yu wrote: > Acee : > > Please read the following : Liu : Then don't implement RFC 3509 since by definition it deviates from RFC 2338. > > RFC 2328: OSPF > > Section 16.8 Equal-cost multipath > " > Each one of the multiple routes will be of the same type > (intra-area, inter-area, type 1 external or type 2 external), > cost, and will have the same associated area. However, each > route may specify a separate next hop and Advertising router." > > Thanks! > > ----- Original Message ----- > From: "Acee Lindem" > To: > Sent: Wednesday, September 17, 2003 3:13 AM > Subject: Re: Inter-area routes reachable via multiple areas > > > >>Liuyu wrote: >> >>>I have read RFC 3509:Alternative Implementations of OSPF Area Border Routers >>> >>>But it still does not explicitly state how to choose a inter-area route from multi associated areas. >>> >>>For example: >>>R3 attaches to Area 2 and Area 1, but it is not a ABR acrroding to RFC 3509. >>>When R3 caculate the route to inter-area route Net K, it will find one with next hop to R2 >>>with metric equal to 4 in Area 1 and the other one with next hop set to R4 with the same metric. >>> >>>How will R3 install the inter-area route Net K in its routing table? Huawei's VRP will choose the latest >>>caculated route. >>> >>>As you konw , the ECMP in OSPF must be the same type and in the same area. >> >>Note that RFC 3509 is an informational RFC and not a standard. Therefore, you >>shouldn't treat it as such. In this situation, I see no reason why you couldn't >>install an ECMP route. >> >> >> >>>Thanks a lot! >>> >>> . Backbone . >>> . Net K . >>> . --------------------- . >>> . |1 1| . >>> ..+--+.............+--+.. >>> ..|R1|..... ....|R4|.. >>> . +--+ . . +--+ . >>> . 1| . . /4 . >>> . | 2 +--+ 4 / . >>> . | +-|R3|---+ . >>> . 1| / +--+\4 . >>> . +--+ / . . \ 4 +--+ . >>> . |R2|/2 . . +--|R5| . >>> . +--+ . . +--+ . >>> . | . . | . >>> . --------- . . -------- . >>> . net N . . net M . >>> . . . . >>> . Area 1 . . Area 2 . >>> ........... .......... >>> >>> >>>----- Original Message ----- >>>From: "Vivek Dubey" >>>To: >>>Sent: Wednesday, September 10, 2003 6:13 PM >>>Subject: Re: Inter-area routes reachable via multiple areas >>> >>> >>>The case should not occur in case of standard ABR implementations for inter-area route calculations. >>>CISCO/IBM ABR implementations might lead to such scenario. >>> >>>Vivek >>> >>> >>> >>> >>>On Wed, 10 Sep 2003 Liu Yu wrote : >>> >>> >>>>Hi! all >>>> >>>>I notice that the clause in RFC 2328 16.4 (3) is just for external route. >>>>How about "inter-area routes"ï¼Y RFC 2328 does not explicitly state this >>>>one! Just choose the "the path whose associated area has the >>>>largest OSPF Area ID "ï¼Yï¼Y Maybe every one has his own implentation. >>>> >>>> >>>>thanks! >>>> >>>> >>>>----- Original Message ----- >>>>From: "Acee Lindem" >>>>To: >>>>Sent: Friday, August 01, 2003 5:46 AM >>>>Subject: Re: ASBR reachable via multiple areas >>>> >>>> >>>> >>>> >>>>>Rob, >>>>> >>>>>You are correct - I missed that clause in 16.4 (3) when >>>>>re-reading. I should have checked my implementation before >>>>>replying. I can't envision why installing an equal-costs >>>>>routes through multiple areas using the same 16.4.1 selection >>>>>rules could cause a routing loop or other problem. >>>>> >>>>>Thanks, >>>>>Acee >>>>> >>>>>ROB PATH wrote: >>>>> >>>>> >>>>>>--- Acee Lindem wrote: >>>>>> >>>>>> >>>>>> >>>>>>>Igor Miroshnik wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>>All, >>>>>>>> >>>>>>>> RFC 1583 states: "AS boundary router's routing >>>>>>> >>>>>>>table entry must indicate a set of paths which >>>>>>> >>>>>>> >>>>>>> >>>>>>>>utilize a single area." (16.1) >>>>>>>> Why not utilize all equal-cost paths through >>>>>>> >>>>>>>different areas? >>>>>>> >>>>>>>Hi Igor, >>>>>>> >>>>>>>I believe you can calculate equal cost paths through >>>>>>>multiple >>>>>>>areas - read section 16.4 and 16.4.1 in RFC 2328 >>>>>>>(which >>>>>>>obsoletes RFC 2178 which obsoletes RFC 1583). >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>>The section 16.4 in RFC 2328 does not explicitly state >>>>>>that equal cost paths through multiple areas could be >>>>>>utilized (say for load balancing purposes). >>>>>> >>>>>>It rather states that when there are multiple >>>>>>least cost paths available in the routing >>>>>>table, the path whose associated area has the >>>>>>largest OSPF Area ID is chosen. >>>>>> >>>>>>Also section 16.4.1 refers to section 16.4 for >>>>>>choosing a path based on cost, when there are >>>>>>multiple paths of equal highest preferences. >>>>>> >>>>>>So it essentially means that multiple equal cost >>>>>>inter-area paths are not utilized. >>>>>> >>>>>>Thanks, >>>>>> Rob. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> Thanks, >>>>>>>> Igor >>>>>>>> >>>>>>> >>>>>>> >>>>>>>-- >>>>>>>Acee >>>>>> >>>>>> >>>>>> >>>>>>===== >>>>>>Rob Path >>>>>>E-Mail : rob_path@yahoo.com >>>>>> >>>>>>__________________________________ >>>>>>Do you Yahoo!? >>>>>>Yahoo! SiteBuilder - Free, easy-to-use web site design software >>>>>>http://sitebuilder.yahoo.com >>>>>> >>>>> >>>>> >>>>>-- >>>>>Acee >>>> >>>___________________________________________________ >>>Medicine meets Marketing; Dr. Swati Weds Jayaram. >>>Rediff Matchmaker strikes another interesting match !! >>>Visit http://rediff.com/matchmaker?2 >> >>-- >>Acee -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Thu Sep 18 11:07:44 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16762 for ; Thu, 18 Sep 2003 11:07:44 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00BA90B1@cherry.ease.lsoft.com>; Thu, 18 Sep 2003 11:07:48 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55323903 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 18 Sep 2003 11:07:46 -0400 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 18 Sep 2003 11:07:45 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA10947 for ; Thu, 18 Sep 2003 11:07:44 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA11139 for ; Thu, 18 Sep 2003 11:07:44 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Sep 2003 11:07:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC55FB704A@vie-msgusr-01.dc.fore.com> Date: Thu, 18 Sep 2003 11:07:43 -0400 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: Stupid checksum and next LSA begining question To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Erblich, -> When given a "update packet with say 5 LSAs", and the -> 1st LSA in this packet has a checksum error, should -> the rest of the LSAs in the update be attempted to be -> processed? 1. If you are talking about LSA checksum (which is Fletcher checksum). RFC 2328 page 142 section 13 says: . . . (1) Validate the LSA's LS checksum. If the checksum turns out to be invalid, discard the LSA and get the next one from the Link State Update packet. . . . 2. If you are talking about OSPF packet checksum RFC 2328 page 61 section 8.2 says: . . . The authentication procedure may also verify the checksum field in the OSPF packet header (which, when used, is set to the standard IP 16-bit one's complement checksum of the OSPF packet's contents after excluding the 64-bit authentication field). If the authentication procedure fails, the packet should be discarded. . . . -> Note: If we have a checksum error, this means that the -> length and the start of the next LSA COULD be wrong. -> -> We could assume that checking the type of the next LSA -> could be within a valid LSA type range, and still not -> have the correct begining of the 2nd or 3rd ... LSAs. In such a case, OSPF packet checksum could be wrong. So, the whole OSPF packet will be discarded. Venkata. From owner-ospf@PEACH.EASE.LSOFT.COM Thu Sep 18 11:21:05 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17828 for ; Thu, 18 Sep 2003 11:21:02 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00BA9157@cherry.ease.lsoft.com>; Thu, 18 Sep 2003 11:21:07 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55324778 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 18 Sep 2003 11:20:28 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 18 Sep 2003 11:20:28 -0400 Received: from redback.com (pptp-6-146.redback.com [155.53.6.146]) by prattle.redback.com (Postfix) with ESMTP id 5D9AB7460C1 for ; Thu, 18 Sep 2003 08:20:28 -0700 (PDT) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <39469E08BD83D411A3D900204840EC55FB704A@vie-msgusr-01.dc.fore.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F69CD39.9050903@redback.com> Date: Thu, 18 Sep 2003 11:20:25 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Stupid checksum and next LSA begining question To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <39469E08BD83D411A3D900204840EC55FB704A@vie-msgusr-01.dc.fore.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Venkata, Agree with you. One more point. Naidu, Venkata wrote: >Erblich, > >-> When given a "update packet with say 5 LSAs", and the >-> 1st LSA in this packet has a checksum error, should >-> the rest of the LSAs in the update be attempted to be >-> processed? > > 1. If you are talking about LSA checksum (which is Fletcher > checksum). > > RFC 2328 page 142 section 13 says: > . . . > (1) Validate the LSA's LS checksum. If the checksum turns out > to be invalid, discard the LSA and get the next one from > the Link State Update packet. > As Mitchell points out, the LSA length may be wrong. However, this is no reason to discard the whole packet since there is also a good possibility that the LSA length is correct and subsequent LSAs may be processed. In any case, an implementation should assure that you don't parse beyond the end of your received packet (irrespective of LSA checksum errors). > . . . > > 2. If you are talking about OSPF packet checksum > > RFC 2328 page 61 section 8.2 says: > . . . > The authentication procedure may also > verify the checksum field in the OSPF packet header (which, > when used, is set to the standard IP 16-bit one's complement > checksum of the OSPF packet's contents after excluding the > 64-bit authentication field). If the authentication > procedure fails, the packet should be discarded. > . . . > >-> Note: If we have a checksum error, this means that the >-> length and the start of the next LSA COULD be wrong. >-> >-> We could assume that checking the type of the next LSA >-> could be within a valid LSA type range, and still not >-> have the correct begining of the 2nd or 3rd ... LSAs. > > In such a case, OSPF packet checksum could be wrong. So, the > whole OSPF packet will be discarded. > >Venkata. > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Sep 18 11:22:51 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17908 for ; Thu, 18 Sep 2003 11:22:51 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00BA9291@cherry.ease.lsoft.com>; Thu, 18 Sep 2003 11:22:51 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55324942 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 18 Sep 2003 11:22:26 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 18 Sep 2003 11:22:26 -0400 Received: from redback.com (pptp-6-146.redback.com [155.53.6.146]) by prattle.redback.com (Postfix) with ESMTP id 998777460C0 for ; Thu, 18 Sep 2003 08:22:25 -0700 (PDT) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030917142416.98604.qmail@web20705.mail.yahoo.com> <3F6872B3.5020108@redback.com> <3F68F3E3.BA0D0820@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F69CDAF.5040001@redback.com> Date: Thu, 18 Sep 2003 11:22:23 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-ietf-ospf-cap-00.txt : Inconsistency Questions To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3F68F3E3.BA0D0820@earthlink.net> Precedence: list Content-Transfer-Encoding: 7bit Hi Mitchell, Erblichs wrote: >Group, > > I think I am dense because I have a couple of questions that > doesn't seem to be resolved in this "work-in-progress". :) > > 1) If we look at just one capability specified in this > draft: Stub router support via bit 6. This is RFC 3137 > from June 2001. > > I will make the assumption that some routers support this > RFC, but don't yet support the capability "work-in-progress". > In this case, the absense of this RI Opaque LSA doesn't reflect > the absense of this capability or in a more general sense, the > absense of support for any of the capabilities of the specified > bits. > TRUE. > > 2) Once this draft becomes a RFC and future drafts add more > capability bits, then how should one determine that > missing capibility bits means no capability versus not > yet specified capability in the IR LSA. > > If the LSA field were incremented from a "4" to a "5" then > we could make the distinction. A "4" would mean that it > may have (0 - 3) and/or 10-31 capabilities, and a "5" > with capabilites not yet, means no capabilities. > The smoothest transition path would be for the new functions to include specification of a capability bit. However, we could take your suggestion into consideration. > > 3) Can the LSA be specified as a DNA (Do not age) LSA? > Sure. Keep in mind that DoNotAge only afffects LSAs that are unchanged. > > Mitchell Erblich > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Sep 18 11:58:26 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19558 for ; Thu, 18 Sep 2003 11:58:26 -0400 (EDT) Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00BA9813@cherry.ease.lsoft.com>; Thu, 18 Sep 2003 11:58:32 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 55327209 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 18 Sep 2003 11:58:30 -0400 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 18 Sep 2003 11:58:30 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA12980 for ; Thu, 18 Sep 2003 11:58:29 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA18957 for ; Thu, 18 Sep 2003 11:58:29 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Sep 2003 11:58:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC55FB704B@vie-msgusr-01.dc.fore.com> Date: Thu, 18 Sep 2003 11:58:27 -0400 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: Stupid checksum and next LSA begining question To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi Acee, -> As Mitchell points out, the LSA length may be wrong. -> However, this is no -> reason to discard the -> whole packet since there is also a good possibility that the -> LSA length is correct There is a good *probability* that the subsequent LSAs are correct. Take for example, a bit in an LSA length field is flipped then the Fletcher checksum calculation fails. But that LSA length field might have been wrong because of the flip. Before going ahead processing the OSPF packet, we first authenticate the packet. The probability that an OSPF packet getting valid even after some bit-errors in an LSA is very very less. I agree that OSPF packet checksum is not a strong checksum. For example, if any two 16-bit words are swapped then the checksum will be still valid. Unfortunately, there is no mechanisms defined in routing protocols for simple "error corrections" (we worry about "error detections" only). This is a good research area. But, still, the reason we don't do that is because the corruption may not necessarily be on the wire. It could be flooding router's database storage may be corrupted. That said, It is not just the problem with OSPF. Historically, many protocols suffer from this. For example, IPv6 header doesn't carry checksum any more. IPv6 trusts lower layer (L2) checksum on hop-by-hop packet integrity and higher layer (transport protocol) checksum on end-to-end integrity. If a bit is flipped in IPv6 destination address, can you think what is going to happen ? The packet is going to end up some (unwanted) destination. Of course, IPsec is mandated in IPv6...etc etc. But, what is going to happen if some bit-errors occur in IPv6 Next Header. How is IPv6 going to process options correctly ? Venkata.