From owner-ospf@PEACH.EASE.LSOFT.COM Sat Aug 2 10:14: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 KAA14849 for ; Sat, 2 Aug 2003 10:14:14 -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.00AB56BF@cherry.ease.lsoft.com>; Sat, 2 Aug 2003 10:14:11 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 50095756 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 2 Aug 2003 10:14:09 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 2 Aug 2003 10:14:09 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id DEC477A3F42 for ; Sat, 2 Aug 2003 07:14:07 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <005501c34cbb$e98f16d0$616545ab@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F2BC6F1.9080403@redback.com> Date: Sat, 2 Aug 2003 10:13:05 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Question on originating intra-area prefix LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Sina, I pretty much agree with you. What is interesting is that if RFC 2740 is followed to the letter, global prefixes with the LA or NU bit set on a multi-access will be advertised in an intra-area-prefix LSA as long as the network isn't a transit network. However, if a neighbor comes up on the network they are not advertised by the DR. You're suggesting to modify this behavior and advertise them irrespective of whether or not there is a full neighbor (2-d) - correct? Thanks, Acee Sina Mirtorabi wrote: > Mike > > The text might be a bit confusing when you try to do a strict reading > ;-) > Here is what you would do in general > > 1) whenever there is a change to a link local prefix or global prefix > you would re-originate a new link-LSA > 2) whenever there is a change to a global prefix you would originate a > new intra-area-prefix-lsa if either of the > the following is true > > 2-a) the link type ( I should say interface type connected to the > link) is p2p /p2mp > 2-b) link type is multi-access and there is no neighbor in state FULL > 2-c) link type is multi-access and this router is DR for that link > 2-d) independently of the link type the global prefix has a prefix > options with LA or NU bit set > > > In other words you would generate a new link-LSA for any prefix change > on a link, and you would originate a new intra-area-prefix-lsa for any > change to the global prefix only when you are supposed to announce this > link's prefix in an intra-area-prefix-lsa ( 2-a or 2-b or 2-c or 2-d) > > The above means that on a p2p / p2mp link when there is a change to a > prefix you would both re-originate a new link-lsa and a new > intra-area-prefix-lsa however on a multi-access link ( with at least one > FULL neighbor) a non-DR router would only re-originate its link-lsa. > Upon reception of this new link-lsa the DR will update its > intra-area-prefix-lsa when necessary. > > > Now there could be an optimization when there is no neighbor on a link > and you could suppress your link-lsa since there is no neighbor on that > link. > > Thanks > Sina > > > > > ->-----Original Message----- > ->From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On > ->Behalf Of Mike Fox > ->Sent: Thursday, July 17, 2003 7:54 AM > ->To: OSPF@PEACH.EASE.LSOFT.COM > ->Subject: Question on originating intra-area prefix LSA > -> > -> > ->When a prefix is added to or deleted from a p2p or p2mp link, > ->when is the prefix change supposed to be advertised to the > ->rest of the area in an intra-area prefix LSA? There seems to > ->be a hole in the RFC. > -> > -> RFC 2740 says, in 3.4.3: > -> > -> o A new prefix is added to an attached link, or a prefix > ->is deleted > -> (both through configuration). This causes the router to > -> reoriginate its link-LSA for the link, or, if it is the only > -> router attached to the link, causes the router to reoriginate an > -> intra-area-prefix-LSA. > -> > ->Some observations and questions. > -> > ->Is it really link LSA *or* intra-area prefix LSA? I.e., never both? > -> > ->This paragraph also implies that on p2p and p2mp links with > ->active neighbors, no intra-area prefix LSA is sent when > ->prefixes change, since the intra-area prefix LSA is only > ->reoriginated when this is the ONLY router on > ->the link. The only other way I can see the prefix being > ->advertised for > ->p2p and p2mp is that perhaps the neighbor should advertise > ->the new prefix > ->in an intra-area prefix LSA when it receives the link LSA. > ->But the next > ->paragraph says: > -> > ->o A new link-LSA is received, causing the link's collection of > -> prefixes to change. If the router is Designated Router for the > -> link, it originates a new intra-area-prefix-LSA. > -> > ->Which implies only the DR for a multiaccess link should ever > ->send a new intra-area prefix LSA upon receiving a link LSA, > ->nothing about point to point or point to multipoint is > ->mentioned. Also, if the set of prefixes is changed on the > ->designated router, according to strict reading of this > ->paragraph then the network's intra-area prefix LSA would not > ->get reoriginated since it's on receiving (not sending) a link > ->LSA that the DR sends the new set. > -> > ->To me it boils down the phrase "if it is the only router > ->attached to the link" in the first quoted paragraph above. > ->If that phrase were replaced with "in all cases except when > ->the link is to a broadcast or multiaccess network and this > ->router is not the designated router" then it seems like all > ->the cases would be covered. > -> > ->What am I missing here? Am I just reading the text too strictly? > -> > ->Mike > ->-------------------------------------------------------------- > ->--------- > ->Enterprise Network Solutions > ->-------------------------------------------------------------- > ->--------- > ->Research Triangle Park, NC USA > -> > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Sat Aug 2 10:20:19 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 KAA15139 for ; Sat, 2 Aug 2003 10:20:19 -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.00AB57A0@cherry.ease.lsoft.com>; Sat, 2 Aug 2003 10:19:59 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 50096000 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 2 Aug 2003 10:19:58 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 2 Aug 2003 10:19:58 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 67B967A3F43 for ; Sat, 2 Aug 2003 07:19:57 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <5.1.0.14.2.20030729222048.0218a630@mailserver.opnet.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F2BC84E.7080607@redback.com> Date: Sat, 2 Aug 2003 10:18:54 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Unequal cost multi-path routing? To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Ashish Zalani wrote: > This may sound like a dumb question, but: > > Why does OSPF not support unequal cost multi-path routing, like EIGRP? > Is it because unequal cost multi-path may lead to routing loops or other similar routing problems? Yes - it complicates the basic SPF and there has never been a strong requirement. > > -Ashish. > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Sat Aug 2 12:40:37 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 MAA16828 for ; Sat, 2 Aug 2003 12:40:37 -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.00AB5A3B@cherry.ease.lsoft.com>; Sat, 2 Aug 2003 12:40:41 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 50101336 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 2 Aug 2003 12:40:39 -0400 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 2 Aug 2003 12:40:39 -0400 Received: from smirtoraw2k03 (sjc-vpn3-250.cisco.com [10.21.64.250]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h72GecO09967 for ; Sat, 2 Aug 2003 09:40:38 -0700 (PDT) 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.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Message-ID: <000001c35914$cdec4fa0$f2ce7243@amer.cisco.com> Date: Sat, 2 Aug 2003 09:40:14 -0700 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: Question on originating intra-area prefix LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3F2BC6F1.9080403@redback.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Acee, ->-----Original Message----- ->From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On ->Behalf Of Acee Lindem ->Sent: Saturday, August 02, 2003 7:13 AM ->To: OSPF@PEACH.EASE.LSOFT.COM ->Subject: Re: Question on originating intra-area prefix LSA -> -> ->Hi Sina, -> ->I pretty much agree with you. What is interesting is that if ->RFC 2740 is followed to the letter, global prefixes with the ->LA or NU bit set on a multi-access will be advertised in an ->intra-area-prefix LSA as long as the network isn't a transit ->network. However, if a neighbor comes up on the network they ->are not advertised by the DR. You're suggesting to modify ->this behavior and advertise them irrespective of whether or ->not there is a full neighbor (2-d) - correct? No, what I meant to say is that intra-area-prefix-lsa will be generated ( from origintor) irrespectively of the link type because even on multi-access with a DR, those LSA are still advertised (by the originator). So I guess the word originator was missing. Since DR does not advertise them in its intra-area-prefix-lsa, a change in the link-lsa due to LA or NU bit change should not make DR to change its intra-area-prefix-lsa. After all LA bit is a /128 prefix and belong to the originator, DR cannot advertise them as its attached prefix Sina -> ->Thanks, ->Acee -> -> ->Sina Mirtorabi wrote: ->> Mike ->> ->> The text might be a bit confusing when you try to do a ->strict reading ->> ;-) ->> Here is what you would do in general ->> ->> 1) whenever there is a change to a link local prefix or ->global prefix ->> you would re-originate a new link-LSA ->> 2) whenever there is a change to a global prefix you would ->originate a ->> new intra-area-prefix-lsa if either of the ->> the following is true ->> ->> 2-a) the link type ( I should say interface type connected to the ->> link) is p2p /p2mp ->> 2-b) link type is multi-access and there is no neighbor ->in state FULL ->> 2-c) link type is multi-access and this router is DR for ->that link ->> 2-d) independently of the link type the global prefix ->has a prefix ->> options with LA or NU bit set ->> ->> ->> In other words you would generate a new link-LSA for any ->prefix change ->> on a link, and you would originate a new ->intra-area-prefix-lsa for any ->> change to the global prefix only when you are supposed to announce ->> this link's prefix in an intra-area-prefix-lsa ( 2-a or 2-b ->or 2-c or ->> 2-d) ->> ->> The above means that on a p2p / p2mp link when there is a ->change to a ->> prefix you would both re-originate a new link-lsa and a new ->> intra-area-prefix-lsa however on a multi-access link ( with ->at least ->> one FULL neighbor) a non-DR router would only re-originate its ->> link-lsa. Upon reception of this new link-lsa the DR will ->update its ->> intra-area-prefix-lsa when necessary. ->> ->> ->> Now there could be an optimization when there is no ->neighbor on a link ->> and you could suppress your link-lsa since there is no neighbor on ->> that link. ->> ->> Thanks ->> Sina ->> ->> ->> ->> ->> ->-----Original Message----- ->> ->From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On ->Behalf Of ->> ->Mike Fox ->> ->Sent: Thursday, July 17, 2003 7:54 AM ->> ->To: OSPF@PEACH.EASE.LSOFT.COM ->> ->Subject: Question on originating intra-area prefix LSA ->> -> ->> -> ->> ->When a prefix is added to or deleted from a p2p or p2mp ->link, when ->> ->is the prefix change supposed to be advertised to the rest of the ->> ->area in an intra-area prefix LSA? There seems to be a ->hole in the ->> ->RFC. ->> -> ->> -> RFC 2740 says, in 3.4.3: ->> -> ->> -> o A new prefix is added to an attached link, or a prefix ->> ->is deleted ->> -> (both through configuration). This causes the router to ->> -> reoriginate its link-LSA for the link, or, if it is the only ->> -> router attached to the link, causes the router to ->reoriginate an ->> -> intra-area-prefix-LSA. ->> -> ->> ->Some observations and questions. ->> -> ->> ->Is it really link LSA *or* intra-area prefix LSA? I.e., ->never both? ->> -> ->> ->This paragraph also implies that on p2p and p2mp links ->with active ->> ->neighbors, no intra-area prefix LSA is sent when prefixes change, ->> ->since the intra-area prefix LSA is only reoriginated when this is ->> ->the ONLY router on ->> ->the link. The only other way I can see the prefix being ->> ->advertised for ->> ->p2p and p2mp is that perhaps the neighbor should ->advertise the new ->> ->prefix in an intra-area prefix LSA when it receives the link LSA. ->> ->But the next ->> ->paragraph says: ->> -> ->> ->o A new link-LSA is received, causing the link's collection of ->> -> prefixes to change. If the router is Designated ->Router for the ->> -> link, it originates a new intra-area-prefix-LSA. ->> -> ->> ->Which implies only the DR for a multiaccess link should ->ever send a ->> ->new intra-area prefix LSA upon receiving a link LSA, ->nothing about ->> ->point to point or point to multipoint is mentioned. Also, if the ->> ->set of prefixes is changed on the designated router, according to ->> ->strict reading of this paragraph then the network's intra-area ->> ->prefix LSA would not get reoriginated since it's on ->receiving (not ->> ->sending) a link LSA that the DR sends the new set. ->> -> ->> ->To me it boils down the phrase "if it is the only router ->attached to ->> ->the link" in the first quoted paragraph above. If that ->phrase were ->> ->replaced with "in all cases except when the link is to a ->broadcast ->> ->or multiaccess network and this router is not the ->designated router" ->> ->then it seems like all the cases would be covered. ->> -> ->> ->What am I missing here? Am I just reading the text too strictly? ->> -> ->> ->Mike ->> ->-------------------------------------------------------------- ->> ->--------- ->> ->Enterprise Network Solutions ->> ->-------------------------------------------------------------- ->> ->--------- ->> ->Research Triangle Park, NC USA ->> -> ->> -> -> ->-- ->Acee -> From owner-ospf@PEACH.EASE.LSOFT.COM Sat Aug 2 13:42:41 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 NAA17600 for ; Sat, 2 Aug 2003 13:42:41 -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.00AB5A6B@cherry.ease.lsoft.com>; Sat, 2 Aug 2003 13:42:43 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 50104194 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 2 Aug 2003 13:42:42 -0400 Received: from 165.212.11.113 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 2 Aug 2003 13:42:42 -0400 Received: from uadvg137.cms.usa.net (165.212.11.137) by cmsoutbound.mx.net with SMTP; 2 Aug 2003 17:42:40 -0000 Received: from mjbarnes [12.236.1.73] by uadvg137.cms.usa.net (ASMTP/michael_barnes@usa.net) via mtad (C8.MAIN.3.08F) with ESMTP id 156HHBRQl0197M37; Sat, 02 Aug 2003 17:42:37 GMT X-USANET-Auth: 12.236.1.73 AUTH michael_barnes@usa.net mjbarnes X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v2.37/37 Message-ID: Date: Sat, 2 Aug 2003 10:42:36 -0700 Reply-To: Mailing List Sender: Mailing List From: Michael Barnes Subject: Re: Question on originating intra-area prefix LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000001c35914$cdec4fa0$f2ce7243@amer.cisco.com> Precedence: list Sina, >No, what I meant to say is that intra-area-prefix-lsa will be generated ( >from origintor) irrespectively of the link type because even on >multi-access with a DR, those LSA are still advertised (by the >originator). So I guess the word originator was missing. Since DR does >not advertise them in its intra-area-prefix-lsa, a change in the link-lsa >due to LA or NU bit change should not make DR to change its >intra-area-prefix-lsa. >After all LA bit is a /128 prefix and belong to the originator, DR cannot >advertise them as its attached prefix We also to be clear which LSA is referenced by the intra-area prefix LSA. Regards, Michael From owner-ospf@PEACH.EASE.LSOFT.COM Sun Aug 3 00:47:27 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 AAA28241 for ; Sun, 3 Aug 2003 00:47: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 <9.00AB7FC9@cherry.ease.lsoft.com>; 3 Aug 2003 0:47:30 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 50144183 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 3 Aug 2003 00:47:26 -0400 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 3 Aug 2003 00:47:26 -0400 Received: from smirtoraw2k03 (sjc-vpn3-250.cisco.com [10.21.64.250]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h734lQO25956 for ; Sat, 2 Aug 2003 21:47:26 -0700 (PDT) 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.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Message-ID: <000001c3597a$57a0e430$f2ce7243@amer.cisco.com> Date: Sat, 2 Aug 2003 21:47:26 -0700 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: Question on originating intra-area prefix LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Mike ->>No, what I meant to say is that intra-area-prefix-lsa will ->be generated ->>( from origintor) irrespectively of the link type because even on ->>multi-access with a DR, those LSA are still advertised (by the ->>originator). So I guess the word originator was missing. ->Since DR does ->>not advertise them in its intra-area-prefix-lsa, a change in the ->>link-lsa due to LA or NU bit change should not make DR to change its ->>intra-area-prefix-lsa. After all LA bit is a /128 prefix and ->belong to ->>the originator, DR cannot advertise them as its attached prefix ->We also to be clear which LSA is referenced by the intra-area ->prefix LSA. Yes, in case of prefixes with LA / NU bit set, the intra-area-prefix-lsa is always referencing a router LSA Sina -> ->Regards, ->Michael -> From owner-ospf@PEACH.EASE.LSOFT.COM Sun Aug 3 17:10:29 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 RAA27505 for ; Sun, 3 Aug 2003 17:10:28 -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.00AB90CC@cherry.ease.lsoft.com>; 3 Aug 2003 17:10:30 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 50199610 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 3 Aug 2003 17:08:45 -0400 Received: from 216.136.175.83 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 3 Aug 2003 17:08:45 -0400 Received: from [24.60.60.33] by web13504.mail.yahoo.com via HTTP; Sun, 03 Aug 2003 14:08:44 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20030803210844.92228.qmail@web13504.mail.yahoo.com> Date: Sun, 3 Aug 2003 14:08:44 -0700 Reply-To: Mailing List Sender: Mailing List From: ROB PATH Subject: Re: Unequal cost multi-path routing? To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3F2BC84E.7080607@redback.com> Precedence: list --- Acee Lindem wrote: > Ashish Zalani wrote: > > This may sound like a dumb question, but: > > > > Why does OSPF not support unequal cost multi-path > routing, like EIGRP? > > Is it because unequal cost multi-path may lead to > routing loops or other similar routing problems? > > Yes - it complicates the basic SPF and there has > never been > a strong requirement. The default SPF based route calculation in the case of OSPF does not take into account the traffic load on any of the routes. The SPF algorithm computes the optimal routes based only on the cost metric and traffic load on the paths are not considered. So if load balancing is done over multiple unequal cost paths then it leads to non-optimal routing. E.g assume there are n paths P1, P2, ... Pn of unequal costs say, C1, C2, C3, C4, .... ... Cn and total lengths of packets transmitted over those paths are, L1, L2, ... ... Ln. Also let Cj is the cost to transmit a packet of unit length over the path Pj. Without loss of generality the unequal costs can be ordered as :- Cn > Cn-1 > ... ... C3 > C2 > C1 > 0. Then total cost of transmission using a) Unequal cost multi-path load balancing is :- C1L1+C2L2+C3L3+ ... ... CnLn b) No unequal cost multi-path load balancing (Optimal Routing) is :- C1 * (L1+L2+L3+ ... ... +Ln). Now :- C1L1+C2L2+C3L3+ ... ... CnLn > C1L1+C1L2+C1L3+...+C1Ln > C1 * (L1+L2+L3+ ...+Ln) This shows that Unequal cost multi-path routing leads to non-optimal routing. Thanks, Rob. > > > > > -Ashish. > > > > > -- > 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 From owner-ospf@PEACH.EASE.LSOFT.COM Mon Aug 4 09:20:46 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 SMTP id JAA24706 for ; Mon, 4 Aug 2003 09:20: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 <11.00ABBB7B@cherry.ease.lsoft.com>; Mon, 4 Aug 2003 9:20:46 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 50273230 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 4 Aug 2003 09:20:45 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 4 Aug 2003 09:20:45 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 5C8D77F84C0 for ; Mon, 4 Aug 2003 06:18:41 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <000001c35914$cdec4fa0$f2ce7243@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F2E5DAA.2010806@redback.com> Date: Mon, 4 Aug 2003 09:20:42 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Question on originating intra-area prefix LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Sina, Sina Mirtorabi wrote: > Hi Acee, > > ->-----Original Message----- > ->From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On > ->Behalf Of Acee Lindem > ->Sent: Saturday, August 02, 2003 7:13 AM > ->To: OSPF@PEACH.EASE.LSOFT.COM > ->Subject: Re: Question on originating intra-area prefix LSA > -> > -> > ->Hi Sina, > -> > ->I pretty much agree with you. What is interesting is that if > ->RFC 2740 is followed to the letter, global prefixes with the > ->LA or NU bit set on a multi-access will be advertised in an > ->intra-area-prefix LSA as long as the network isn't a transit > ->network. However, if a neighbor comes up on the network they > ->are not advertised by the DR. You're suggesting to modify > ->this behavior and advertise them irrespective of whether or > ->not there is a full neighbor (2-d) - correct? > > No, what I meant to say is that intra-area-prefix-lsa will be generated > ( from origintor) irrespectively of the link type because even on > multi-access with a DR, those LSA are still advertised (by the > originator). So I guess the word originator was missing. Since DR does > not advertise them in its intra-area-prefix-lsa, a change in the > link-lsa due to LA or NU bit change should not make DR to change its > intra-area-prefix-lsa. Right. If you strictly follow RFC 2740 and a prefix with the LA/NU bit is added/deleted to a transit network (i.e., a multi-access network with one or more adjacent neighbors), it will not result in any changes in intra-area-prefix-lsa originated by the owner of the address. If the LA/NU bit is changed for an existing prefix, it will result in changes to the DR's intra-area-prefix-lsa. This is where your 2-d below and RFC 2740 seems to differ. > After all LA bit is a /128 prefix and belong to the originator, DR > cannot advertise them as its attached prefix > > Sina > > -> > ->Thanks, > ->Acee > -> > -> > ->Sina Mirtorabi wrote: > ->> Mike > ->> > ->> The text might be a bit confusing when you try to do a > ->strict reading > ->> ;-) > ->> Here is what you would do in general > ->> > ->> 1) whenever there is a change to a link local prefix or > ->global prefix > ->> you would re-originate a new link-LSA > ->> 2) whenever there is a change to a global prefix you would > ->originate a > ->> new intra-area-prefix-lsa if either of the > ->> the following is true > ->> > ->> 2-a) the link type ( I should say interface type connected to the > ->> link) is p2p /p2mp > ->> 2-b) link type is multi-access and there is no neighbor > ->in state FULL > ->> 2-c) link type is multi-access and this router is DR for > ->that link > ->> 2-d) independently of the link type the global prefix > ->has a prefix > ->> options with LA or NU bit set > ->> > ->> > ->> In other words you would generate a new link-LSA for any > ->prefix change > ->> on a link, and you would originate a new > ->intra-area-prefix-lsa for any > ->> change to the global prefix only when you are supposed to announce > ->> this link's prefix in an intra-area-prefix-lsa ( 2-a or 2-b > ->or 2-c or > ->> 2-d) > ->> > ->> The above means that on a p2p / p2mp link when there is a > ->change to a > ->> prefix you would both re-originate a new link-lsa and a new > ->> intra-area-prefix-lsa however on a multi-access link ( with > ->at least > ->> one FULL neighbor) a non-DR router would only re-originate its > ->> link-lsa. Upon reception of this new link-lsa the DR will > ->update its > ->> intra-area-prefix-lsa when necessary. > ->> > ->> > ->> Now there could be an optimization when there is no > ->neighbor on a link > ->> and you could suppress your link-lsa since there is no neighbor on > ->> that link. > ->> > ->> Thanks > ->> Sina > ->> > ->> > ->> > ->> > ->> ->-----Original Message----- > ->> ->From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On > ->Behalf Of > ->> ->Mike Fox > ->> ->Sent: Thursday, July 17, 2003 7:54 AM > ->> ->To: OSPF@PEACH.EASE.LSOFT.COM > ->> ->Subject: Question on originating intra-area prefix LSA > ->> -> > ->> -> > ->> ->When a prefix is added to or deleted from a p2p or p2mp > ->link, when > ->> ->is the prefix change supposed to be advertised to the rest of the > ->> ->area in an intra-area prefix LSA? There seems to be a > ->hole in the > ->> ->RFC. > ->> -> > ->> -> RFC 2740 says, in 3.4.3: > ->> -> > ->> -> o A new prefix is added to an attached link, or a prefix > ->> ->is deleted > ->> -> (both through configuration). This causes the router to > ->> -> reoriginate its link-LSA for the link, or, if it is the only > ->> -> router attached to the link, causes the router to > ->reoriginate an > ->> -> intra-area-prefix-LSA. > ->> -> > ->> ->Some observations and questions. > ->> -> > ->> ->Is it really link LSA *or* intra-area prefix LSA? I.e., > ->never both? > ->> -> > ->> ->This paragraph also implies that on p2p and p2mp links > ->with active > ->> ->neighbors, no intra-area prefix LSA is sent when prefixes change, > ->> ->since the intra-area prefix LSA is only reoriginated when this is > ->> ->the ONLY router on > ->> ->the link. The only other way I can see the prefix being > ->> ->advertised for > ->> ->p2p and p2mp is that perhaps the neighbor should > ->advertise the new > ->> ->prefix in an intra-area prefix LSA when it receives the link LSA. > ->> ->But the next > ->> ->paragraph says: > ->> -> > ->> ->o A new link-LSA is received, causing the link's collection of > ->> -> prefixes to change. If the router is Designated > ->Router for the > ->> -> link, it originates a new intra-area-prefix-LSA. > ->> -> > ->> ->Which implies only the DR for a multiaccess link should > ->ever send a > ->> ->new intra-area prefix LSA upon receiving a link LSA, > ->nothing about > ->> ->point to point or point to multipoint is mentioned. Also, if the > ->> ->set of prefixes is changed on the designated router, according to > ->> ->strict reading of this paragraph then the network's intra-area > ->> ->prefix LSA would not get reoriginated since it's on > ->receiving (not > ->> ->sending) a link LSA that the DR sends the new set. > ->> -> > ->> ->To me it boils down the phrase "if it is the only router > ->attached to > ->> ->the link" in the first quoted paragraph above. If that > ->phrase were > ->> ->replaced with "in all cases except when the link is to a > ->broadcast > ->> ->or multiaccess network and this router is not the > ->designated router" > ->> ->then it seems like all the cases would be covered. > ->> -> > ->> ->What am I missing here? Am I just reading the text too strictly? > ->> -> > ->> ->Mike > ->> ->-------------------------------------------------------------- > ->> ->--------- > ->> ->Enterprise Network Solutions > ->> ->-------------------------------------------------------------- > ->> ->--------- > ->> ->Research Triangle Park, NC USA > ->> -> > ->> > -> > -> > ->-- > ->Acee > -> > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Mon Aug 4 10:54: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 SMTP id KAA00596 for ; Mon, 4 Aug 2003 10:54: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 <3.00ABBF68@cherry.ease.lsoft.com>; Mon, 4 Aug 2003 10:54:05 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 50281361 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 4 Aug 2003 10:54:04 -0400 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 4 Aug 2003 10:54:03 -0400 Received: from smirtoraw2k03 (sjc-vpn4-733.cisco.com [10.21.82.221]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h74Es2O13524 for ; Mon, 4 Aug 2003 07:54:02 -0700 (PDT) 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.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Message-ID: <000001c35a98$3e682f90$f2ce7243@amer.cisco.com> Date: Mon, 4 Aug 2003 07:54:01 -0700 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: Question on originating intra-area prefix LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3F2E5DAA.2010806@redback.com> Precedence: list Content-Transfer-Encoding: 7bit Acee ->Right. If you strictly follow RFC 2740 and a prefix with the ->LA/NU bit is added/deleted to a transit network (i.e., a ->multi-access network with one or more adjacent neighbors), it ->will not result in any changes in intra-area-prefix-lsa ->originated by the owner of the address. Why not ? You add or delete a prefix with LA/NU bit set, the owner of the prefix should originate a new intra-area-prefix-lsa referencing the router lsa ->If the LA/NU bit is ->changed for an existing prefix, it will result in changes to ->the DR's intra-area-prefix-lsa. Don't know what you mean by existing prefix. if the DR receives a new link-lsa due to a change in a prefix with LA/NU bit then the DR will Not change any of its intra-area-prefix-lsa (referencing network or router lsa if any) . however if a prefix with LA/NU bit is added/deleted on the DR ( prefix configured on DR) , then the DR will announce a new intra-area-prefix-lsa referencing the router-lsa -> ->This is where your 2-d below and RFC 2740 seems to differ. The above is what I meant Sina -> ->> After all LA bit is a /128 prefix and belong to the originator, DR ->> cannot advertise them as its attached prefix ->> ->> Sina ->> ->> -> ->> ->Thanks, ->> ->Acee ->> -> ->> -> ->> ->Sina Mirtorabi wrote: ->> ->> Mike ->> ->> ->> ->> The text might be a bit confusing when you try to do a ->> ->strict reading ->> ->> ;-) ->> ->> Here is what you would do in general ->> ->> ->> ->> 1) whenever there is a change to a link local prefix or ->> ->global prefix ->> ->> you would re-originate a new link-LSA ->> ->> 2) whenever there is a change to a global prefix you would ->> ->originate a ->> ->> new intra-area-prefix-lsa if either of the ->> ->> the following is true ->> ->> ->> ->> 2-a) the link type ( I should say interface type ->connected to ->> ->> the ->> ->> link) is p2p /p2mp ->> ->> 2-b) link type is multi-access and there is no neighbor ->> ->in state FULL ->> ->> 2-c) link type is multi-access and this router is DR for ->> ->that link ->> ->> 2-d) independently of the link type the global prefix ->> ->has a prefix ->> ->> options with LA or NU bit set ->> ->> ->> ->> ->> ->> In other words you would generate a new link-LSA for any ->> ->prefix change ->> ->> on a link, and you would originate a new ->> ->intra-area-prefix-lsa for any ->> ->> change to the global prefix only when you are supposed ->to announce ->> ->> this link's prefix in an intra-area-prefix-lsa ( 2-a or 2-b ->> ->or 2-c or ->> ->> 2-d) ->> ->> ->> ->> The above means that on a p2p / p2mp link when there is a ->> ->change to a ->> ->> prefix you would both re-originate a new link-lsa and a new ->> ->> intra-area-prefix-lsa however on a multi-access link ( with ->> ->at least ->> ->> one FULL neighbor) a non-DR router would only re-originate its ->> ->> link-lsa. Upon reception of this new link-lsa the DR will ->> ->update its ->> ->> intra-area-prefix-lsa when necessary. ->> ->> ->> ->> ->> ->> Now there could be an optimization when there is no ->> ->neighbor on a link ->> ->> and you could suppress your link-lsa since there is no ->neighbor on ->> ->> that link. ->> ->> ->> ->> Thanks ->> ->> Sina ->> ->> ->> ->> ->> ->> ->> ->> ->> ->> ->-----Original Message----- ->> ->> ->From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On ->> ->Behalf Of ->> ->> ->Mike Fox ->> ->> ->Sent: Thursday, July 17, 2003 7:54 AM ->> ->> ->To: OSPF@PEACH.EASE.LSOFT.COM ->> ->> ->Subject: Question on originating intra-area prefix LSA ->> ->> -> ->> ->> -> ->> ->> ->When a prefix is added to or deleted from a p2p or p2mp ->> ->link, when ->> ->> ->is the prefix change supposed to be advertised to the rest of ->> ->> ->the area in an intra-area prefix LSA? There seems to be a ->> ->hole in the ->> ->> ->RFC. ->> ->> -> ->> ->> -> RFC 2740 says, in 3.4.3: ->> ->> -> ->> ->> -> o A new prefix is added to an attached link, or a prefix ->> ->> ->is deleted ->> ->> -> (both through configuration). This causes the router to ->> ->> -> reoriginate its link-LSA for the link, or, if ->it is the only ->> ->> -> router attached to the link, causes the router to ->> ->reoriginate an ->> ->> -> intra-area-prefix-LSA. ->> ->> -> ->> ->> ->Some observations and questions. ->> ->> -> ->> ->> ->Is it really link LSA *or* intra-area prefix LSA? I.e., ->> ->never both? ->> ->> -> ->> ->> ->This paragraph also implies that on p2p and p2mp links ->> ->with active ->> ->> ->neighbors, no intra-area prefix LSA is sent when prefixes ->> ->> ->change, since the intra-area prefix LSA is only reoriginated ->> ->> ->when this is the ONLY router on ->> ->> ->the link. The only other way I can see the prefix being ->> ->> ->advertised for ->> ->> ->p2p and p2mp is that perhaps the neighbor should ->> ->advertise the new ->> ->> ->prefix in an intra-area prefix LSA when it receives the link ->> ->> ->LSA. But the next paragraph says: ->> ->> -> ->> ->> ->o A new link-LSA is received, causing the link's ->collection of ->> ->> -> prefixes to change. If the router is Designated ->> ->Router for the ->> ->> -> link, it originates a new intra-area-prefix-LSA. ->> ->> -> ->> ->> ->Which implies only the DR for a multiaccess link should ->> ->ever send a ->> ->> ->new intra-area prefix LSA upon receiving a link LSA, ->> ->nothing about ->> ->> ->point to point or point to multipoint is mentioned. Also, if ->> ->> ->the set of prefixes is changed on the designated router, ->> ->> ->according to strict reading of this paragraph then ->the network's ->> ->> ->intra-area prefix LSA would not get reoriginated since it's on ->> ->receiving (not ->> ->> ->sending) a link LSA that the DR sends the new set. ->> ->> -> ->> ->> ->To me it boils down the phrase "if it is the only router ->> ->attached to ->> ->> ->the link" in the first quoted paragraph above. If that ->> ->phrase were ->> ->> ->replaced with "in all cases except when the link is to a ->> ->broadcast ->> ->> ->or multiaccess network and this router is not the ->> ->designated router" ->> ->> ->then it seems like all the cases would be covered. ->> ->> -> ->> ->> ->What am I missing here? Am I just reading the text too ->> ->> ->strictly? ->> ->> -> ->> ->> ->Mike ->> ->> ->-------------------------------------------------------------- ->> ->> ->--------- ->> ->> ->Enterprise Network Solutions ->> ->> ->-------------------------------------------------------------- ->> ->> ->--------- ->> ->> ->Research Triangle Park, NC USA ->> ->> -> ->> ->> ->> -> ->> -> ->> ->-- ->> ->Acee ->> -> ->> -> -> ->-- ->Acee -> From owner-ospf@PEACH.EASE.LSOFT.COM Mon Aug 4 11:22: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 SMTP id LAA01344 for ; Mon, 4 Aug 2003 11:22: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.00ABC125@cherry.ease.lsoft.com>; Mon, 4 Aug 2003 11:22:10 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 50286565 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 4 Aug 2003 11:22:07 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 4 Aug 2003 11:22:07 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 41E015F8D41 for ; Mon, 4 Aug 2003 08:22:06 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <000001c35a98$3e682f90$f2ce7243@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F2E7A95.3040404@redback.com> Date: Mon, 4 Aug 2003 11:24:05 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Question on originating intra-area prefix LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Sina, The way I read RFC 2740, prefixes with the LA/NU set will not be advertised in an intra-area-prefix-lsa if the interface is connects to a transit network but will be advertised if it connects to a non-transit network. Sina Mirtorabi wrote: > Acee > > ->Right. If you strictly follow RFC 2740 and a prefix with the > ->LA/NU bit is added/deleted to a transit network (i.e., a > ->multi-access network with one or more adjacent neighbors), it > ->will not result in any changes in intra-area-prefix-lsa > ->originated by the owner of the address. > > Why not ? You add or delete a prefix with LA/NU bit set, the owner of > the prefix should originate a new intra-area-prefix-lsa referencing the > router lsa This is directly from 3.4.3.7 in RFC 2740. o Router RTX examines its list of interfaces to the area. If the interface is in state Down, its prefixes are not included. If the interface has been reported in RTX's router-LSA as a Type 2 link description (link to transit network), its prefixes are not ~~~~~~~ included (they will be included in the intra-area-prefix-LSA for ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ the link instead). If the interface type is Point-to-MultiPoint, or the interface is in state Loopback, or the interface connects to a point-to-point link which has not been assigned a prefix, then the site-local and global scope IPv6 addresses associated with the interface (if any) are copied into the intra-area- prefix-LSA, setting the LA-bit in the PrefixOptions field, and setting the PrefixLength to 128 and the Metric to 0. Otherwise, the list of site-local and global prefixes configured in RTX for the link are copied into the intra-area-prefix-LSA by specifying the PrefixLength, PrefixOptions, and Address Prefix fields. The Metric field for each of these prefixes is set to the interface's output cost. > > ->If the LA/NU bit is > ->changed for an existing prefix, it will result in changes to > ->the DR's intra-area-prefix-lsa. > > Don't know what you mean by existing prefix. if the DR receives a new > link-lsa due to a change in a prefix with LA/NU bit then the DR will Not > change any of its intra-area-prefix-lsa (referencing network or router > lsa if any) . however if a prefix with LA/NU bit is added/deleted on the > DR ( prefix configured on DR) , then the DR will announce a new > intra-area-prefix-lsa referencing the router-lsa I believe the DR ignores these. o Each Link-LSA associated with Link L is examined (these are in the Designated Router's interface structure for Link L). If the Link- LSA's Advertising Router is fully adjacent to the Designated Router, the list of prefixes in the Link-LSA is copied into the Coltun, et al. Standards Track [Page 32] ^L RFC 2740 OSPF for IPv6 December 1999 intra-area-prefix-LSA that is being built. Prefixes having the NU-bit and/or LA-bit set in their Options field should not be ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ copied, nor should link-local addresses be copied. Each prefix is ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ described by the PrefixLength, PrefixOptions, and Address Prefix fields. Multiple prefixes having the same PrefixLength and Address Prefix are considered to be duplicates; in this case their Prefix Options fields should be merged by logically OR'ing the fields together, and a single resulting prefix should be copied into the intra-area-prefix-LSA. The Metric field for all prefixes is set to 0. > > -> > ->This is where your 2-d below and RFC 2740 seems to differ. > > The above is what I meant > > Sina > > -> > ->> After all LA bit is a /128 prefix and belong to the originator, DR > ->> cannot advertise them as its attached prefix > ->> > ->> Sina > ->> > ->> -> > ->> ->Thanks, > ->> ->Acee > ->> -> > ->> -> > ->> ->Sina Mirtorabi wrote: > ->> ->> Mike > ->> ->> > ->> ->> The text might be a bit confusing when you try to do a > ->> ->strict reading > ->> ->> ;-) > ->> ->> Here is what you would do in general > ->> ->> > ->> ->> 1) whenever there is a change to a link local prefix or > ->> ->global prefix > ->> ->> you would re-originate a new link-LSA > ->> ->> 2) whenever there is a change to a global prefix you would > ->> ->originate a > ->> ->> new intra-area-prefix-lsa if either of the > ->> ->> the following is true > ->> ->> > ->> ->> 2-a) the link type ( I should say interface type > ->connected to > ->> ->> the > ->> ->> link) is p2p /p2mp > ->> ->> 2-b) link type is multi-access and there is no neighbor > ->> ->in state FULL > ->> ->> 2-c) link type is multi-access and this router is DR for > ->> ->that link > ->> ->> 2-d) independently of the link type the global prefix > ->> ->has a prefix > ->> ->> options with LA or NU bit set > ->> ->> > ->> ->> > ->> ->> In other words you would generate a new link-LSA for any > ->> ->prefix change > ->> ->> on a link, and you would originate a new > ->> ->intra-area-prefix-lsa for any > ->> ->> change to the global prefix only when you are supposed > ->to announce > ->> ->> this link's prefix in an intra-area-prefix-lsa ( 2-a or 2-b > ->> ->or 2-c or > ->> ->> 2-d) > ->> ->> > ->> ->> The above means that on a p2p / p2mp link when there is a > ->> ->change to a > ->> ->> prefix you would both re-originate a new link-lsa and a new > ->> ->> intra-area-prefix-lsa however on a multi-access link ( with > ->> ->at least > ->> ->> one FULL neighbor) a non-DR router would only re-originate its > ->> ->> link-lsa. Upon reception of this new link-lsa the DR will > ->> ->update its > ->> ->> intra-area-prefix-lsa when necessary. > ->> ->> > ->> ->> > ->> ->> Now there could be an optimization when there is no > ->> ->neighbor on a link > ->> ->> and you could suppress your link-lsa since there is no > ->neighbor on > ->> ->> that link. > ->> ->> > ->> ->> Thanks > ->> ->> Sina > ->> ->> > ->> ->> > ->> ->> > ->> ->> > ->> ->> ->-----Original Message----- > ->> ->> ->From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On > ->> ->Behalf Of > ->> ->> ->Mike Fox > ->> ->> ->Sent: Thursday, July 17, 2003 7:54 AM > ->> ->> ->To: OSPF@PEACH.EASE.LSOFT.COM > ->> ->> ->Subject: Question on originating intra-area prefix LSA > ->> ->> -> > ->> ->> -> > ->> ->> ->When a prefix is added to or deleted from a p2p or p2mp > ->> ->link, when > ->> ->> ->is the prefix change supposed to be advertised to the rest of > ->> ->> ->the area in an intra-area prefix LSA? There seems to be a > ->> ->hole in the > ->> ->> ->RFC. > ->> ->> -> > ->> ->> -> RFC 2740 says, in 3.4.3: > ->> ->> -> > ->> ->> -> o A new prefix is added to an attached link, or a prefix > ->> ->> ->is deleted > ->> ->> -> (both through configuration). This causes the router to > ->> ->> -> reoriginate its link-LSA for the link, or, if > ->it is the only > ->> ->> -> router attached to the link, causes the router to > ->> ->reoriginate an > ->> ->> -> intra-area-prefix-LSA. > ->> ->> -> > ->> ->> ->Some observations and questions. > ->> ->> -> > ->> ->> ->Is it really link LSA *or* intra-area prefix LSA? I.e., > ->> ->never both? > ->> ->> -> > ->> ->> ->This paragraph also implies that on p2p and p2mp links > ->> ->with active > ->> ->> ->neighbors, no intra-area prefix LSA is sent when prefixes > ->> ->> ->change, since the intra-area prefix LSA is only reoriginated > ->> ->> ->when this is the ONLY router on > ->> ->> ->the link. The only other way I can see the prefix being > ->> ->> ->advertised for > ->> ->> ->p2p and p2mp is that perhaps the neighbor should > ->> ->advertise the new > ->> ->> ->prefix in an intra-area prefix LSA when it receives the link > ->> ->> ->LSA. But the next paragraph says: > ->> ->> -> > ->> ->> ->o A new link-LSA is received, causing the link's > ->collection of > ->> ->> -> prefixes to change. If the router is Designated > ->> ->Router for the > ->> ->> -> link, it originates a new intra-area-prefix-LSA. > ->> ->> -> > ->> ->> ->Which implies only the DR for a multiaccess link should > ->> ->ever send a > ->> ->> ->new intra-area prefix LSA upon receiving a link LSA, > ->> ->nothing about > ->> ->> ->point to point or point to multipoint is mentioned. Also, if > ->> ->> ->the set of prefixes is changed on the designated router, > ->> ->> ->according to strict reading of this paragraph then > ->the network's > ->> ->> ->intra-area prefix LSA would not get reoriginated since it's on > ->> ->receiving (not > ->> ->> ->sending) a link LSA that the DR sends the new set. > ->> ->> -> > ->> ->> ->To me it boils down the phrase "if it is the only router > ->> ->attached to > ->> ->> ->the link" in the first quoted paragraph above. If that > ->> ->phrase were > ->> ->> ->replaced with "in all cases except when the link is to a > ->> ->broadcast > ->> ->> ->or multiaccess network and this router is not the > ->> ->designated router" > ->> ->> ->then it seems like all the cases would be covered. > ->> ->> -> > ->> ->> ->What am I missing here? Am I just reading the text too > ->> ->> ->strictly? > ->> ->> -> > ->> ->> ->Mike > ->> ->> ->-------------------------------------------------------------- > ->> ->> ->--------- > ->> ->> ->Enterprise Network Solutions > ->> ->> ->-------------------------------------------------------------- > ->> ->> ->--------- > ->> ->> ->Research Triangle Park, NC USA > ->> ->> -> > ->> ->> > ->> -> > ->> -> > ->> ->-- > ->> ->Acee > ->> -> > ->> > -> > -> > ->-- > ->Acee > -> > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Mon Aug 4 11:52:19 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 SMTP id LAA01991 for ; Mon, 4 Aug 2003 11:52:19 -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.00ABBFE4@cherry.ease.lsoft.com>; Mon, 4 Aug 2003 11:52:21 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 50288294 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 4 Aug 2003 11:52:09 -0400 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 4 Aug 2003 11:52:09 -0400 Received: from smirtoraw2k03 (dhcp-171-69-101-97.cisco.com [171.69.101.97]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h74Fq8O01855 for ; Mon, 4 Aug 2003 08:52:08 -0700 (PDT) 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.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Message-ID: <000001c35aa0$5c658490$616545ab@amer.cisco.com> Date: Mon, 4 Aug 2003 08:52:08 -0700 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: Question on originating intra-area prefix LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3F2E7A95.3040404@redback.com> Precedence: list Content-Transfer-Encoding: 7bit Acee -> ->Hi Sina, -> ->The way I read RFC 2740, prefixes with the LA/NU set will not ->be advertised in an intra-area-prefix-lsa if the interface is ->connects to a transit network but will be advertised if it ->connects to a non-transit network. Not really, if that is true you can never bring up a VL on a router that has only multi-access links to the area. This is because you don't want to advertise prefix with LA bit in intra-area-prefix-lsa ( referencing router lsa) which is required for VL ->This is directly from 3.4.3.7 in RFC 2740. -> -> o Router RTX examines its list of interfaces to the area. If the -> interface is in state Down, its prefixes are not ->included. If the -> interface has been reported in RTX's router-LSA as a ->Type 2 link -> description (link to transit network), its prefixes are not -> ~~~~~~~ -> included (they will be included in the ->intra-area-prefix-LSA for the link instead ) -> ->~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - I am afraid that the above quote is generic and does not take into account prefix with LA bit set ( /128 ) ->> Don't know what you mean by existing prefix. if the DR ->receives a new ->> link-lsa due to a change in a prefix with LA/NU bit then ->the DR will ->> Not change any of its intra-area-prefix-lsa (referencing network or ->> router lsa if any) . however if a prefix with LA/NU bit is ->> added/deleted on the DR ( prefix configured on DR) , then ->the DR will ->> announce a new intra-area-prefix-lsa referencing the router-lsa Acee> I believe the DR ignores these. Yes this is what I said above, if there is a change to the link-lsa due to a prefix with LA/NU then DR will Not generate a new intra-area-prefix-lsa referencing network lsa However if DR own LA/NU prefix is changed this needs to be updated in a intra-area-prefix-lsa referencing a router lsa and what you quote below apply to DR's intra-area-prefix-lsa referencing a network lsa -> -> o Each Link-LSA associated with Link L is examined ->(these are in the -> Designated Router's interface structure for Link L). ->If the Link- -> LSA's Advertising Router is fully adjacent to the Designated -> Router, the list of prefixes in the Link-LSA is copied into the -> intra-area-prefix-LSA that is being built. Prefixes having the -> NU-bit and/or LA-bit set in their Options field should not be -> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -> copied, nor should link-local addresses be copied. ->Each prefix is -> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ sina From owner-ospf@PEACH.EASE.LSOFT.COM Mon Aug 4 12:38: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 SMTP id MAA03647 for ; Mon, 4 Aug 2003 12:38: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 <1.00ABC2A2@cherry.ease.lsoft.com>; Mon, 4 Aug 2003 12:38:15 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 50291429 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 4 Aug 2003 12:38:14 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 4 Aug 2003 12:38:14 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 938D9A30587 for ; Mon, 4 Aug 2003 09:34:50 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <000001c35aa0$5c658490$616545ab@amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F2E8BA1.8080608@redback.com> Date: Mon, 4 Aug 2003 12:36:49 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Question on originating intra-area prefix LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Sina Mirtorabi wrote: > Acee > > -> > ->Hi Sina, > -> > ->The way I read RFC 2740, prefixes with the LA/NU set will not > ->be advertised in an intra-area-prefix-lsa if the interface is > ->connects to a transit network but will be advertised if it > ->connects to a non-transit network. > > Not really, > if that is true you can never bring up a VL on a router that has only > multi-access links to the area. This is because you don't want to > advertise prefix with LA bit in intra-area-prefix-lsa ( referencing > router lsa) which is required for VL Now you understand why I said in my original E-mail that RFC 2740 was wrong and we should change the rule so they are advertised... Hi Sina, I pretty much agree with you. What is interesting is that if RFC 2740 is followed to the letter, global prefixes with the LA or NU bit set on a multi-access will be advertised in an intra-area-prefix LSA as long as the network isn't a transit network. However, if a neighbor comes up on the network they are not advertised by the DR. You're suggesting to modify this behavior and advertise them irrespective of whether or not there is a full neighbor (2-d) - correct? I think we're agreeing that prefixes with LA bit should be advertised in the router intra-area-prefix-LSA independent of whether or not the interface is connected to a transit network. > > > ->This is directly from 3.4.3.7 in RFC 2740. > -> > -> o Router RTX examines its list of interfaces to the area. If the > -> interface is in state Down, its prefixes are not > ->included. If the > -> interface has been reported in RTX's router-LSA as a > ->Type 2 link > -> description (link to transit network), its prefixes are not > -> ~~~~~~~ > -> included (they will be included in the > ->intra-area-prefix-LSA for the link instead ) > -> > ->~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > - > > I am afraid that the above quote is generic and does not take into > account prefix with LA bit set ( /128 ) > > ->> Don't know what you mean by existing prefix. if the DR > ->receives a new > ->> link-lsa due to a change in a prefix with LA/NU bit then > ->the DR will > ->> Not change any of its intra-area-prefix-lsa (referencing network or > ->> router lsa if any) . however if a prefix with LA/NU bit is > ->> added/deleted on the DR ( prefix configured on DR) , then > ->the DR will > ->> announce a new intra-area-prefix-lsa referencing the router-lsa > > Acee> I believe the DR ignores these. > > Yes this is what I said above, if there is a change to the link-lsa due > to a prefix with LA/NU then DR will Not generate a new > intra-area-prefix-lsa referencing network lsa > > However if DR own LA/NU prefix is changed this needs to be updated in a > intra-area-prefix-lsa referencing a router lsa and what you quote below > apply to DR's intra-area-prefix-lsa referencing a network lsa > > -> > -> o Each Link-LSA associated with Link L is examined > ->(these are in the > -> Designated Router's interface structure for Link L). > ->If the Link- > -> LSA's Advertising Router is fully adjacent to the Designated > -> Router, the list of prefixes in the Link-LSA is copied into the > > -> intra-area-prefix-LSA that is being built. Prefixes having the > -> NU-bit and/or LA-bit set in their Options field should not be > -> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > -> copied, nor should link-local addresses be copied. > ->Each prefix is > -> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > sina > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Mon Aug 4 13:05: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 SMTP id NAA04433 for ; Mon, 4 Aug 2003 13:05:32 -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.00ABC3CE@cherry.ease.lsoft.com>; Mon, 4 Aug 2003 13:05:27 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 50292791 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 4 Aug 2003 13:05:22 -0400 Received: from 171.68.227.73 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 4 Aug 2003 13:05:22 -0400 Received: from smirtoraw2k03 (dhcp-171-69-101-97.cisco.com [171.69.101.97]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id h74H5LO29022 for ; Mon, 4 Aug 2003 10:05:21 -0700 (PDT) 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.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Message-ID: <001e01c35aaa$96abd690$616545ab@amer.cisco.com> Date: Mon, 4 Aug 2003 10:05:21 -0700 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: Question on originating intra-area prefix LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3F2E8BA1.8080608@redback.com> Precedence: list Content-Transfer-Encoding: 7bit Acee ->> Not really, ->> if that is true you can never bring up a VL on a router ->that has only ->> multi-access links to the area. This is because you don't want to ->> advertise prefix with LA bit in intra-area-prefix-lsa ( referencing ->> router lsa) which is required for VL -> ->Now you understand why I said in my original E-mail that RFC ->2740 was wrong and we should change the rule so they are advertised... I would not say that is wrong ( as it is not stated explicitly that prefix with LA bit set are not included for multi-access link) but the way it is stated is confusing and could be misinterpreted. The problem is that RFC 2740 tried to keep a balance to not state too much as it could be redundant with RFC 2328, yet state the diffs with 2328. This is causing some confusion in some part of the RFC ->I think we're agreeing that prefixes with LA bit should be ->advertised in the router intra-area-prefix-LSA independent of ->whether or not the interface is connected to a transit network. Yes Sina From owner-ospf@PEACH.EASE.LSOFT.COM Mon Aug 4 17:14: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 SMTP id RAA12281 for ; Mon, 4 Aug 2003 17:14: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 <9.00ABD7F3@cherry.ease.lsoft.com>; Mon, 4 Aug 2003 17:14:33 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 50309524 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 4 Aug 2003 17:14:32 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 4 Aug 2003 17:14:32 -0400 Received: from fuinar.juniper.net (fuinar.juniper.net [172.17.12.75]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h74LEVu08212 for ; Mon, 4 Aug 2003 14:14:31 -0700 (PDT) (envelope-from qv@juniper.net) Received: (from qv@localhost) by fuinar.juniper.net (8.11.6/8.9.3) id h74LEVK74523; Mon, 4 Aug 2003 14:14:31 -0700 (PDT) (envelope-from qv) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <000001c35aa0$5c658490$616545ab@amer.cisco.com> <3F2E8BA1.8080608@redback.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Message-ID: <200308042114.h74LEVK74523@fuinar.juniper.net> Date: Mon, 4 Aug 2003 14:14:31 -0700 Reply-To: Mailing List Sender: Mailing List From: Quaizar Vohra Subject: Re: Question on originating intra-area prefix LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3F2E8BA1.8080608@redback.com> Precedence: list Content-Transfer-Encoding: 7bit Acee, Sorry for barging in so late into the discussion. I might not have understood the entire discussion. But it looks to me that the change you are asking for in the rfc is already mentioned in the rfc. A later rule from the same section talks about this. o If RTX has one or more virtual links configured through the area, it includes one of its site-local or global scope IPv6 interface addresses in the LSA (if it hasn't already), setting the LA-bit in the PrefixOptions field, and setting the PrefixLength to 128 and the Metric to 0. This information will be used later in the routing calculation so that the two ends of the virtual link can discover each other's IPv6 addresses. This rule doesn't mandate that the interface address come from a non-transit interface. So you might pick it from a transit interface as well. Quaizar > Sina Mirtorabi wrote: > > Acee > > > > -> > > ->Hi Sina, > > -> > > ->The way I read RFC 2740, prefixes with the LA/NU set will not > > ->be advertised in an intra-area-prefix-lsa if the interface is > > ->connects to a transit network but will be advertised if it > > ->connects to a non-transit network. > > > > Not really, > > if that is true you can never bring up a VL on a router that has only > > multi-access links to the area. This is because you don't want to > > advertise prefix with LA bit in intra-area-prefix-lsa ( referencing > > router lsa) which is required for VL > > Now you understand why I said in my original E-mail that RFC 2740 was > wrong and we should change the rule so they are advertised... > > Hi Sina, > > I pretty much agree with you. What is interesting is that if RFC 2740 > is followed to the letter, global prefixes with the LA or NU bit set > on a multi-access will be advertised in an intra-area-prefix > LSA as long as the network isn't a transit network. However, if > a neighbor comes up on the network they are not advertised by the DR. > You're suggesting to modify this behavior and advertise them irrespective > of whether or not there is a full neighbor (2-d) - correct? > > I think we're agreeing that prefixes with LA bit should be advertised > in the router intra-area-prefix-LSA independent of whether or not > the interface is connected to a transit network. > > > > > > > ->This is directly from 3.4.3.7 in RFC 2740. > > -> > > -> o Router RTX examines its list of interfaces to the area. If the > > -> interface is in state Down, its prefixes are not > > ->included. If the > > -> interface has been reported in RTX's router-LSA as a > > ->Type 2 link > > -> description (link to transit network), its prefixes are not > > -> ~~~~~~~ > > -> included (they will be included in the > > ->intra-area-prefix-LSA for the link instead ) > > -> > > ->~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > - > > > > I am afraid that the above quote is generic and does not take into > > account prefix with LA bit set ( /128 ) > > > > ->> Don't know what you mean by existing prefix. if the DR > > ->receives a new > > ->> link-lsa due to a change in a prefix with LA/NU bit then > > ->the DR will > > ->> Not change any of its intra-area-prefix-lsa (referencing network or > > ->> router lsa if any) . however if a prefix with LA/NU bit is > > ->> added/deleted on the DR ( prefix configured on DR) , then > > ->the DR will > > ->> announce a new intra-area-prefix-lsa referencing the router-lsa > > > > Acee> I believe the DR ignores these. > > > > Yes this is what I said above, if there is a change to the link-lsa due > > to a prefix with LA/NU then DR will Not generate a new > > intra-area-prefix-lsa referencing network lsa > > > > However if DR own LA/NU prefix is changed this needs to be updated in a > > intra-area-prefix-lsa referencing a router lsa and what you quote below > > apply to DR's intra-area-prefix-lsa referencing a network lsa > > > > -> > > -> o Each Link-LSA associated with Link L is examined > > ->(these are in the > > -> Designated Router's interface structure for Link L). > > ->If the Link- > > -> LSA's Advertising Router is fully adjacent to the Designated > > -> Router, the list of prefixes in the Link-LSA is copied into the > > > > -> intra-area-prefix-LSA that is being built. Prefixes having the > > -> NU-bit and/or LA-bit set in their Options field should not be > > -> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > -> copied, nor should link-local addresses be copied. > > ->Each prefix is > > -> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > sina > > > > > -- > Acee From owner-ospf@PEACH.EASE.LSOFT.COM Tue Aug 5 06:28:52 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 SMTP id GAA06713 for ; Tue, 5 Aug 2003 06:28: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 <7.00ABF1BF@cherry.ease.lsoft.com>; Tue, 5 Aug 2003 6:28:53 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 50376651 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 5 Aug 2003 06:28:51 -0400 Received: from 198.178.8.81 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 5 Aug 2003 06:18:51 -0400 Received: from entexchimc01.broadband.att.com (localhost [127.0.0.1]) by saipal.tci.com (8.12.9/8.12.9) with ESMTP id h75AIhA9015260 for ; Tue, 5 Aug 2003 04:18:51 -0600 (MDT) Received: by entexchimc01.broadband.att.com with Internet Mail Service (5.5.2653.19) id <304FXJXZ>; Tue, 5 Aug 2003 04:18:43 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <0224526940E0444AB1D970FD35C5042302C5A4D3@entcoexch01.broadband.att.com> Date: Tue, 5 Aug 2003 04:18:38 -0600 Reply-To: Mailing List Sender: Mailing List From: "Field, Brian" Subject: unidirectional links and OSPF To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list I'm wondering if there is a way to get OSPF to work when the link is unidirectional. I'm aware of the UDLR work and that might be the right way to handle undirectional links. Just want to explore if there are options available or work in progress within OSPF to operate and establish an adjacency when the link is unidirectional. Thanks Brian From owner-ospf@PEACH.EASE.LSOFT.COM Tue Aug 5 13:13: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 NAA19467 for ; Tue, 5 Aug 2003 13:13: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 <17.00ABFAEB@cherry.ease.lsoft.com>; Tue, 5 Aug 2003 13:13:34 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 50415728 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 5 Aug 2003 13:13:32 -0400 Received: from 192.35.17.28 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 5 Aug 2003 13:13:32 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id h75HDVb29062 for ; Tue, 5 Aug 2003 19:13:31 +0200 (MEST) Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id h75HDUm06786 for ; Tue, 5 Aug 2003 19:13:30 +0200 (MEST) Received: from mchh248e.mchh.siemens.de (mchh248e.mchh.siemens.de [139.21.200.58]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id TAA02351 for ; Tue, 5 Aug 2003 19:13:30 +0200 (MET DST) Received: by mchh248e.mchh.siemens.de with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Aug 2003 19:12:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-ID: <47D260E84215734F81779E8A50BE9B37656125@mchh2a4e.mchh.siemens.de> Date: Tue, 5 Aug 2003 19:12:51 +0200 Reply-To: Mailing List Sender: Mailing List From: Schrodi Karl Subject: AW: Unequal cost multi-path routing? To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Folks, this is a subject, which may deserve a few more thoughts: 1. Obviously, whenever we leave the shortest (or least cost) path, the = overall cost function (sum of(cost * used bandwidth)) will increase. = This is what Rob shows (with the implicit assumption of equal = distribution of packets to the unequal cost paths). 2. Thus, such kind of inefficiency still holds, if we weight the packet = distribution inversely proportional to the respective cost of each = path, as (according to my knowledge) EIGRP is capable of doing, or - a = little bit more aggressive - if we would control the traffic = distribution to the different paths by individual weights, calculated = according to whatever rules. Such rules, for example, could take into = account the knowledge about certain traffic patterns in the network = (e.g. a traffic matrix) and aim at a better distribution of the traffic = in the network and thus a more efficient (dito!) usage of network = resources in case of some unbalance between available network path = capacities and traffic demand. 3. Of course, loop prevention is an issue, but not a show stopper. = OSPF-OMP as well as recent proposals (e.g. Schollmeier et al. at = HPSR=C2=B42003 in Torino) can deal with that. Todays processing power = calculates multiple routes in very short time. 4. A more severe problem may arise from packet sequence errors caused = by per packet traffic distribution on different delay paths. Hash based = per flow distribution may overcome this at least in network areas where = the flow statistics, i.e. number of simultaneous flows, are large = enough. 5. So, Acee is right, it complicates the basic SPF - but what (besides = traffic distribution) could it be good for? Multi-path routing has the inherent capability of having at least one = alternative path available, if one path fails. Thus, connectivity can = be preserved in a single node by an immediate and independent, local = only reaction without any involvement of other nodes and without any = delays due to network wide routing convergence. As soon as a failure is = detected, the faulty path can be blocked locally and all traffic is = sent to the remaining part of the multi-path group. Together with fast = failure detection mechanisms as recently presented by the plp = (Kompella) and bfd (Katz/Ward) drafts in the grow WG this could result = in excellent failure reaction times. I see several applications, where I would like that kind of behaviour: web radio, video streaming, interactive video (net meeting), gaming, = any kind of joint and interactive activities, - and, btw, I see no = reason why I wouldn=C2=B4t like it for simple web surfing. 6. So, - do we need it? Well, we may find out, that intra-AS rerouting = is (or at least can be made) fast enough for such applications (where = are we today?)- and if we arrive there and can proof it - why do = anything else? Still, at that time our network may be faced with a new = generation of more demanding applications ... Finally, everything boils down to a cost/benefit estimate - is it worth = while doing it? Who can judge? Regards Karl -----Ursprungliche Nachricht----- Von: ROB PATH [mailto:rob_path@YAHOO.COM] Gesendet: Sonntag, 3. August 2003 23:09 An: OSPF@PEACH.EASE.LSOFT.COM Betreff: Re: Unequal cost multi-path routing? --- Acee Lindem wrote: > Ashish Zalani wrote: > > This may sound like a dumb question, but: > > > > Why does OSPF not support unequal cost multi-path > routing, like EIGRP? > > Is it because unequal cost multi-path may lead to > routing loops or other similar routing problems? > > Yes - it complicates the basic SPF and there has > never been > a strong requirement. The default SPF based route calculation in the case of OSPF does not take into account the traffic load on any of the routes. The SPF algorithm computes the optimal routes based only on the cost metric and traffic load on the paths are not considered. So if load balancing is done over multiple unequal cost paths then it leads to non-optimal routing. E.g assume there are n paths P1, P2, ... Pn of unequal costs say, C1, C2, C3, C4, .... ... Cn and total lengths of packets transmitted over those paths are, L1, L2, ... ... Ln. Also let Cj is the cost to transmit a packet of unit length over the path Pj. Without loss of generality the unequal costs can be ordered as :- Cn > Cn-1 > ... ... C3 > C2 > C1 > 0. Then total cost of transmission using a) Unequal cost multi-path load balancing is :- C1L1+C2L2+C3L3+ ... ... CnLn b) No unequal cost multi-path load balancing (Optimal Routing) is :- C1 * (L1+L2+L3+ ... ... +Ln). Now :- C1L1+C2L2+C3L3+ ... ... CnLn > C1L1+C1L2+C1L3+...+C1Ln > C1 * (L1+L2+L3+ ...+Ln) This shows that Unequal cost multi-path routing leads to non-optimal routing. Thanks, Rob. > > > > > -Ashish. > > > > > -- > Acee =3D=3D=3D=3D=3D 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 From owner-ospf@PEACH.EASE.LSOFT.COM Wed Aug 6 07:07: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 HAA12073 for ; Wed, 6 Aug 2003 07:07: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 <23.00AC274C@cherry.ease.lsoft.com>; Wed, 6 Aug 2003 7:07:11 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 50365798 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 6 Aug 2003 07:07:09 -0400 Received: from 203.199.83.247 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 6 Aug 2003 07:07:09 -0400 Received: (qmail 7318 invoked by uid 510); 6 Aug 2003 11:07:06 -0000 Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 06 aug 2003 11:07:06 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20030806110706.7317.qmail@mailweb34.rediffmail.com> Date: Wed, 6 Aug 2003 11:07:06 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: RFC 2328 : Appendix E To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Conflict in description and example ?? RFC 2328:Appendix E -------------------- (2) Obtain the network mask from the body of the already existing AS-external-LSA. Call this mask NM2. There are then two cases: o NM2 is longer than NM1. In this case, change the existing LSA (having Link State ID of NA) to reference the new network [NA,NM1] by incrementing the sequence number, changing the mask in the body to NM1 and inserting the cost of the new network. Then originate a new LSA for the old network [NA,NM2], with Link State ID equal to NA or'ed together with the bits that are not set in NM2 (i.e., network [NA,NM2]'s broadcast address). As an example of the algorithm, consider its operation when the following sequence of events occurs in a single router (Router A). (1) Router A wants to originate an AS-external-LSA for [10.0.0.0,255.255.255.0]: (a) A Link State ID of 10.0.0.0 is used. (2) Router A then wants to originate an AS-external-LSA for [10.0.0.0,255.255.0.0]: (a) The LSA for [10.0.0,0,255.255.255.0] is reoriginated using a new Link State ID of 10.0.0.255. (b) A Link State ID of 10.0.0.0 is used for [10.0.0.0,255.255.0.0]. vivek>> Point (2) in e.g should be: a) Reoriginate existing LSA with 10.0.0.0 [10.0.0.0, 255.255.0.0], incrementing sequence number,changing the mask in the body, and inserting the cost of new network. b) Originate a new LSA for LsId 10.0.0.255 [10.0.0.0, 255.255.255.0] Vivek ___________________________________________________ Download the hottest & happening ringtones here! OR SMS: Top tone to 7333 Click here now: http://sms.rediff.com/cgi-bin/ringtone/ringhome.pl From owner-ospf@PEACH.EASE.LSOFT.COM Wed Aug 6 11:15: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 LAA20879 for ; Wed, 6 Aug 2003 11:15: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 <21.00AC2F4A@cherry.ease.lsoft.com>; Wed, 6 Aug 2003 11:15:36 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 50380589 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 6 Aug 2003 11:15:34 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 6 Aug 2003 11:15:34 -0400 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id 8FD059F1AE9 for ; Wed, 6 Aug 2003 08:15:32 -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: <20030806110706.7317.qmail@mailweb34.rediffmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F311C14.9040100@redback.com> Date: Wed, 6 Aug 2003 11:17:40 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: RFC 2328 : Appendix E To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20030806110706.7317.qmail@mailweb34.rediffmail.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Vivek, It might be a bit clearer as you suggest but the outcome is the same. The description is from the perspective of the LSAs while the example is from the perspective of routes which need to be advertised. Vivek Dubey wrote: > Conflict in description and example ?? > > RFC 2328:Appendix E > -------------------- > (2) > Obtain the network mask from the body of the already existing > AS-external-LSA. Call this mask NM2. There are then two cases: > > o NM2 is longer than NM1. In this case, change the existing > LSA (having Link State ID of NA) to reference the new > network [NA,NM1] by incrementing the sequence number, > changing the mask in the body to NM1 and inserting the cost > of the new network. Then originate a new LSA for the old > network [NA,NM2], with Link State ID equal to NA or'ed > together with the bits that are not set in NM2 (i.e., > network [NA,NM2]'s broadcast address). > > As an example of the algorithm, consider its operation when the > following sequence of events occurs in a single router (Router > A). > (1) Router A wants to originate an AS-external-LSA for > [10.0.0.0,255.255.255.0]: > (a) A Link State ID of 10.0.0.0 is used. > > (2) Router A then wants to originate an AS-external-LSA for > [10.0.0.0,255.255.0.0]: > > (a) The LSA for [10.0.0,0,255.255.255.0] is reoriginated > using a new Link State ID of 10.0.0.255. > > (b) A Link State ID of 10.0.0.0 is used for > [10.0.0.0,255.255.0.0]. > > vivek>> > Point (2) in e.g should be: > a) Reoriginate existing LSA with > 10.0.0.0 [10.0.0.0, 255.255.0.0], incrementing > sequence number,changing the mask in the body, and > inserting the cost of new network. > > b) Originate a new LSA for LsId > 10.0.0.255 [10.0.0.0, 255.255.255.0] > > > Vivek > > ___________________________________________________ > Download the hottest & happening ringtones here! > OR SMS: Top tone to 7333 > Click here now: > http://sms.rediff.com/cgi-bin/ringtone/ringhome.pl > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Thu Aug 7 23:33: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 XAA13903 for ; Thu, 7 Aug 2003 23:33: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 <16.00AC6941@cherry.ease.lsoft.com>; Thu, 7 Aug 2003 23:33:47 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 50528352 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 7 Aug 2003 23:33:46 -0400 Received: from 206.54.51.125 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 7 Aug 2003 23:33:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35D5D.DEAD809B" Thread-Topic: receiving self-orig Lsa Thread-Index: AcNdXd6suy3eGgU+TbWNbiRw76Cqpw== Message-ID: Date: Thu, 7 Aug 2003 20:33:44 -0700 Reply-To: Mailing List Sender: Mailing List From: Jason Chen Subject: receiving self-orig Lsa To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------_=_NextPart_001_01C35D5D.DEAD809B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi,=20 We need some clarification regarding -- "Receiving self-originated LSA" RFC section 13.4 said, ".... A self-originated LSA is detected when..... 2) the LSA is a = network- LSA and its Link State ID is equal to one of the router's own = IP interface addresses. " ".....In most cases, the router must then advance the LSA's LS sequence = number one past the received LS sequence number, and originate a new = instance of the LSA" In an OSPF network, if one router change its OSPF router-id and then it = receives self-orig Network Lsa with its old router id from its neighbor. = If the criteria (2) is met, should we treat the received LSA as = self-orig LSA ? If we treat the LSA as self-orig LSA, the router will reoriginate new = LSA (with new router-id) with sequence number one past the received = sequence number. What would be the right behavior once its neighbor = receive the new LSA ? Thanks, Jason ------_=_NextPart_001_01C35D5D.DEAD809B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable receiving self-orig Lsa

Hi,

We need some clarification regarding -- = "Receiving self-originated LSA"

RFC section 13.4 said,

".... A self-originated LSA is detected when..... 2) the = LSA is a network- LSA and its Link State ID is equal to one of the = router's own IP interface addresses. "

".....In most cases, the router = must then advance the LSA's LS sequence number one past the received LS = sequence number, and originate a new instance of the = LSA"

In an OSPF network, if one router = change its OSPF router-id and then it receives self-orig Network Lsa = with its old router id from its neighbor.  If the criteria (2) is = met, should we treat the received LSA as self-orig LSA ?

If we treat the LSA as self-orig LSA, = the router will reoriginate  new LSA (with new router-id)  = with sequence number one past the received sequence number. What would = be the right behavior once its neighbor receive the new LSA ?

Thanks,
Jason





------_=_NextPart_001_01C35D5D.DEAD809B-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Aug 7 23:52: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 XAA14360 for ; Thu, 7 Aug 2003 23:52:32 -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.00AC68CA@cherry.ease.lsoft.com>; Thu, 7 Aug 2003 23:52:36 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 50529801 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 7 Aug 2003 23:51:45 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 7 Aug 2003 23:51:45 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 8C57583D262 for ; Thu, 7 Aug 2003 20:51:43 -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: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F331EBB.8080807@redback.com> Date: Thu, 7 Aug 2003 23:53:31 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: receiving self-orig Lsa To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Hi Jason, Jason Chen wrote: > Hi, > > We need some clarification regarding -- "Receiving self-originated LSA" > > RFC section 13.4 said, > > ".... A self-originated LSA is detected when..... 2) the LSA is a > network- LSA and its Link State ID is equal to one of the router's own > IP interface addresses. " > > ".....In most cases, the router must then advance the LSA's LS sequence > number one past the received LS sequence number, and originate a new > instance of the LSA" > > In an OSPF network, if one router change its OSPF router-id and then it > receives self-orig Network Lsa with its old router id from its > neighbor. If the criteria (2) is met, should we treat the received LSA > as self-orig LSA ? Yes. > > If we treat the LSA as self-orig LSA, the router will reoriginate new > LSA (with new router-id) with sequence number one past the received > sequence number. What would be the right behavior once its neighbor > receive the new LSA ? You should flush it from the routing domain as described in the third paragraph of section 13.4, RFC 2328. ------ Acee P.S. Remember to complete your graceful restart implementation survey ;^) From owner-ospf@PEACH.EASE.LSOFT.COM Sun Aug 10 15:52: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 PAA14836 for ; Sun, 10 Aug 2003 15:52: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 <1.00ACDA7E@cherry.ease.lsoft.com>; 10 Aug 2003 15:52:27 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 50748085 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 10 Aug 2003 15:52:26 -0400 Received: from 209.119.1.39 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 10 Aug 2003 15:42:26 -0400 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <4.0037477F@grape.ease.lsoft.com>; Sun, 10 Aug 2003 15:42:26 -0400 Message-ID: Date: Sun, 10 Aug 2003 15:42:06 -0400 Reply-To: Mailing List Sender: Mailing List From: Naveen Tyagi Subject: Flooding Procedure To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi, I am new to ospf. This question has been asked earlier and replied by Mr. Moy. But I could not understand the description. I fail to understand how "RFC2328 section 13 point no 6" is en error case? Here is the response From Mr Moy. *********************************************************** Date: Fri, 23 Oct 1998 15:09:31 -0400 Reply-To: Mailing List Sender: Mailing List From: "John T. Moy" Organization: Cascade Communications Corp. Subject: Re: Flooding Procedure Comments: To: SS Pillai Content-Type: text/plain; charset=us-ascii It's an error because, if the Database Exchange procedure were working properly, the LSA on the request list should have been removed in step 5c of that same section, instead of reaching step 6. John SS Pillai wrote: > Subject: Flooding Procedure > Date: Sun, 18 Oct 1998 21:08:44 +0530 > From: SS Pillai > To: discuss@ospf.microsoft.com > > Hi, > In RFC2328 section 13 page no 145 point no 6, it is mentioned > that "if there is an instance of the LSA on sending neighbor's > Link state request list, an error has occured ...." > > while we are sending LS Request, the neighbor will respond > in LS Update packet. So there will be an request list > in our database. How it can be an error?. > > I think I not understood properly. Can any one clear my doupt? > Thanks > pillai ****************************************************************** Section 5c is about deleting LSA from retansmission list and not from the request list. Thanks, Naveen. From owner-ospf@PEACH.EASE.LSOFT.COM Mon Aug 11 01:07:46 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 BAA24170 for ; Mon, 11 Aug 2003 01:07: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 <18.00ACFBC2@cherry.ease.lsoft.com>; Mon, 11 Aug 2003 1:07:47 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 50772945 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 11 Aug 2003 01:07:46 -0400 Received: from 203.199.83.146 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 11 Aug 2003 01:07:45 -0400 Received: (qmail 31102 invoked by uid 510); 11 Aug 2003 05:07:25 -0000 Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 11 aug 2003 05:07:25 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20030811050725.31101.qmail@webmail24.rediffmail.com> Date: Mon, 11 Aug 2003 05:07:25 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: Re: Flooding Procedure To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Section 10.6 ------------- Otherwise, the router looks up the LSA in its database to see whether it also has an instance of the LSA. If it does not, or if the database copy is less recent see Section 13.1), the LSA is put on the Link state request list so that it can be requested (immediately or at some later time) in Link State Request Packets. Section 13.1 ------------- 5) Executed if no database copy present or received lsa is more recent. 6) Means there is a database copy that is either: a) Same instance as database copy OR b)Database copy is more recent Implies this LSA shouldn't be present in NBRs LRQ List. Resulting in error condition. Vivek On Mon, 11 Aug 2003 Naveen Tyagi wrote : >Hi, >I am new to ospf. >This question has been asked earlier and replied by Mr. Moy. But >I could not >understand the description. > > I fail to understand how "RFC2328 section 13 point no 6" is >en error >case? > > Here is the response From Mr Moy. >*********************************************************** > Date: Fri, 23 Oct 1998 15:09:31 -0400 >Reply-To: Mailing List >Sender: Mailing List > From: "John T. Moy" >Organization: Cascade Communications Corp. >Subject: Re: Flooding Procedure >Comments: To: SS Pillai >Content-Type: text/plain; charset=us-ascii > >It's an error because, if the Database Exchange procedure >were working properly, the LSA on the request list should >have been removed in step 5c of that same section, instead >of reaching step 6. > >John > >SS Pillai wrote: > > > Subject: Flooding Procedure > > Date: Sun, 18 Oct 1998 21:08:44 +0530 > > From: SS Pillai > > To: discuss@ospf.microsoft.com > > > > Hi, > > In RFC2328 section 13 page no 145 point no 6, it is >mentioned > > that "if there is an instance of the LSA on sending >neighbor's > > Link state request list, an error has occured ...." > > > > while we are sending LS Request, the neighbor will >respond > > in LS Update packet. So there will be an request >list > > in our database. How it can be an error?. > > > > I think I not understood properly. Can any one clear >my doupt? > > Thanks > > pillai > >****************************************************************** > > Section 5c is about deleting LSA from retansmission list and >not from the >request list. >Thanks, >Naveen. ___________________________________________________ Download the hottest & happening ringtones here! OR SMS: Top tone to 7333 Click here now: http://sms.rediff.com/cgi-bin/ringtone/ringhome.pl From owner-ospf@PEACH.EASE.LSOFT.COM Mon Aug 11 12: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 MAA22912 for ; Mon, 11 Aug 2003 12: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 <15.00AD0B2A@cherry.ease.lsoft.com>; Mon, 11 Aug 2003 12:58:28 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 50837309 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 11 Aug 2003 12:58:27 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 11 Aug 2003 12:58:27 -0400 Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h7BGwQu20103 for ; Mon, 11 Aug 2003 09:58:26 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) with ESMTP id h7BGwQB26071 for ; Mon, 11 Aug 2003 09:58:26 -0700 (PDT) (envelope-from kireeti@juniper.net) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs References: <9D42C6E086250248810DCADA39CE7EFC97268C@nimbus> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: <20030811095718.V26040@kummer.juniper.net> Date: Mon, 11 Aug 2003 09:58:26 -0700 Reply-To: Mailing List Sender: Mailing List From: Kireeti Kompella Subject: Re: GMPLS extension for OSPF To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <9D42C6E086250248810DCADA39CE7EFC97268C@nimbus> Precedence: list On Wed, 30 Jul 2003, John Drake wrote: > RFC3477 What he said. To expand slightly, section 3. The exchange is done via RSVP, not via OSPF. (Sorry for the delayed response.) Kireeti. From owner-ospf@PEACH.EASE.LSOFT.COM Tue Aug 12 07:25: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 HAA08938 for ; Tue, 12 Aug 2003 07:25:59 -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.00AD303F@cherry.ease.lsoft.com>; Tue, 12 Aug 2003 7:26:01 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 50935572 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 12 Aug 2003 07:26:00 -0400 Received: from 203.199.83.247 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 12 Aug 2003 07:26:00 -0400 Received: (qmail 31421 invoked by uid 510); 12 Aug 2003 11:25:50 -0000 Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 12 aug 2003 11:25:50 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20030812112550.31420.qmail@mailweb34.rediffmail.com> Date: Tue, 12 Aug 2003 11:25:50 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: Re: RFC 2328 : Appendix E To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi Acee, Continuing the thread: Router R1 originates AS Ext LSAs: LS1 : 10.0.0.0/8 LS2 : 10.0.255.255/16 ; Fwd Addr N1; Metric 10; Type 1 Router R2 originates AS Ext LSA: LS1 : 10.0.0.0/16 ; Fwd Addr N1; Metric 10; Type 1 1)Now are LS2(R1) and LS1(R2) functionally equivalent ?? 2)Further is there a possibility of routers, with some supporting Appendix E and others not, being present in same domain ?? Vivek On Wed, 06 Aug 2003 Acee Lindem wrote : >Hi Vivek, > >It might be a bit clearer as you suggest but the outcome >is the same. The description is from the perspective of the >LSAs while the example is from the perspective of >routes which need to be advertised. > > >Vivek Dubey wrote: >>Conflict in description and example ?? >> >>RFC 2328:Appendix E >>-------------------- >>(2) >>Obtain the network mask from the body of the already existing >>AS-external-LSA. Call this mask NM2. There are then two cases: >> >>o NM2 is longer than NM1. In this case, change the existing >> LSA (having Link State ID of NA) to reference the >>new >> network [NA,NM1] by incrementing the sequence >>number, >> changing the mask in the body to NM1 and inserting the >>cost >> of the new network. Then originate a new LSA for the >>old >> network [NA,NM2], with Link State ID equal to NA >>or'ed >> together with the bits that are not set in NM2 >>(i.e., >> network [NA,NM2]'s broadcast address). >> >>As an example of the algorithm, consider its operation when >>the >>following sequence of events occurs in a single router >>(Router >>A). >>(1) Router A wants to originate an AS-external-LSA for >> [10.0.0.0,255.255.255.0]: >> (a) A Link State ID of 10.0.0.0 is used. >> >>(2) Router A then wants to originate an AS-external-LSA for >> [10.0.0.0,255.255.0.0]: >> >> (a) The LSA for [10.0.0,0,255.255.255.0] is >>reoriginated >> using a new Link State ID of 10.0.0.255. >> >> (b) A Link State ID of 10.0.0.0 is used for >> [10.0.0.0,255.255.0.0]. >> >>vivek>> >>Point (2) in e.g should be: >> a) Reoriginate existing LSA with >> 10.0.0.0 [10.0.0.0, 255.255.0.0], incrementing >> sequence number,changing the mask in the body, and >> inserting the cost of new network. >> >> b) Originate a new LSA for LsId >> 10.0.0.255 [10.0.0.0, 255.255.255.0] >> >> >>Vivek >> >>___________________________________________________ >>Download the hottest & happening ringtones here! >>OR SMS: Top tone to 7333 >>Click here now: >>http://sms.rediff.com/cgi-bin/ringtone/ringhome.pl >> > >-- >Acee ___________________________________________________ Meet your old school or college friends from 1 Million + database... Click here to reunite www.batchmates.com/rediff.asp From owner-ospf@PEACH.EASE.LSOFT.COM Tue Aug 12 15:17: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 PAA26664 for ; Tue, 12 Aug 2003 15:17: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 <0.00AD40B5@cherry.ease.lsoft.com>; Tue, 12 Aug 2003 15:17:05 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 50968061 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 12 Aug 2003 15:17:04 -0400 Received: from 206.54.51.125 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 12 Aug 2003 15:17:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: receiving self-orig Lsa Thread-Index: AcNdYZF2D06Ac5bKTvKFb+8+ehmAWgDo4E1A Message-ID: Date: Tue, 12 Aug 2003 12:17:01 -0700 Reply-To: Mailing List Sender: Mailing List From: Jason Chen Subject: Re: receiving self-orig Lsa To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi, > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Thursday, August 07, 2003 8:54 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: receiving self-orig Lsa >=20 >=20 > Hi Jason, >=20 > Jason Chen wrote: > > Hi, > > > > We need some clarification regarding -- "Receiving=20 > self-originated LSA" > > > > RFC section 13.4 said, > > > > ".... A self-originated LSA is detected when..... 2) the LSA is a > > network- LSA and its Link State ID is equal to one of the=20 > router's own > > IP interface addresses. " > > > > ".....In most cases, the router must then advance the LSA's=20 > LS sequence > > number one past the received LS sequence number, and originate a new > > instance of the LSA" > > > > In an OSPF network, if one router change its OSPF router-id=20 > and then it > > receives self-orig Network Lsa with its old router id from its > > neighbor. If the criteria (2) is met, should we treat the=20 > received LSA > > as self-orig LSA ? >=20 > Yes. > > > > If we treat the LSA as self-orig LSA, the router will=20 > reoriginate new > > LSA (with new router-id) with sequence number one past the received > > sequence number. What would be the right behavior once its neighbor > > receive the new LSA ? >=20 > You should flush it from the routing domain as described in the > third paragraph of section 13.4, RFC 2328. >=20 Is there issue not to flush those LSA with old/unknown router id ? Will = that cause network unstable ? >=20 > ------ > Acee From owner-ospf@PEACH.EASE.LSOFT.COM Tue Aug 12 22:49:29 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 WAA07632 for ; Tue, 12 Aug 2003 22:49:29 -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 <10.00AD557A@cherry.ease.lsoft.com>; Tue, 12 Aug 2003 22:49:31 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 51008247 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 12 Aug 2003 22:49:30 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 12 Aug 2003 22:49:29 -0400 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id 6328D95F3A1 for ; Tue, 12 Aug 2003 19:49:28 -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: <20030812112550.31420.qmail@mailweb34.rediffmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F39A762.8020404@redback.com> Date: Tue, 12 Aug 2003 22:50:10 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: RFC 2328 : Appendix E To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20030812112550.31420.qmail@mailweb34.rediffmail.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Vivek, Vivek Dubey wrote: > Hi Acee, > Continuing the thread: > Router R1 originates AS Ext LSAs: > LS1 : 10.0.0.0/8 > LS2 : 10.0.255.255/16 ; Fwd Addr N1; Metric 10; Type 1 > > Router R2 originates AS Ext LSA: > LS1 : 10.0.0.0/16 ; Fwd Addr N1; Metric 10; Type 1 > > 1)Now are LS2(R1) and LS1(R2) functionally equivalent ?? No - the masks in the body of the LSA are different. > > 2)Further is there a possibility of routers, > with some supporting Appendix E and others not, > being present in same domain ?? Yes. An OSPFv2 router can't make any assumptions regarding te setting of the host bits in the Link State ID for type 3 or 5 LSA's originated by another router. Incremental SPF computations must take this fact into account. > > Vivek > > > > > > On Wed, 06 Aug 2003 Acee Lindem wrote : > >> Hi Vivek, >> >> It might be a bit clearer as you suggest but the outcome >> is the same. The description is from the perspective of the >> LSAs while the example is from the perspective of >> routes which need to be advertised. >> >> >> Vivek Dubey wrote: >> >>> Conflict in description and example ?? >>> >>> RFC 2328:Appendix E >>> -------------------- >>> (2) >>> Obtain the network mask from the body of the already existing >>> AS-external-LSA. Call this mask NM2. There are then two cases: >>> >>> o NM2 is longer than NM1. In this case, change the existing >>> LSA (having Link State ID of NA) to reference the >>> new >>> network [NA,NM1] by incrementing the sequence >>> number, >>> changing the mask in the body to NM1 and inserting the >>> cost >>> of the new network. Then originate a new LSA for the >>> old >>> network [NA,NM2], with Link State ID equal to NA >>> or'ed >>> together with the bits that are not set in NM2 >>> (i.e., >>> network [NA,NM2]'s broadcast address). >>> >>> As an example of the algorithm, consider its operation when >>> the >>> following sequence of events occurs in a single router >>> (Router >>> A). >>> (1) Router A wants to originate an AS-external-LSA for >>> [10.0.0.0,255.255.255.0]: >>> (a) A Link State ID of 10.0.0.0 is used. >>> >>> (2) Router A then wants to originate an AS-external-LSA for >>> [10.0.0.0,255.255.0.0]: >>> >>> (a) The LSA for [10.0.0,0,255.255.255.0] is >>> reoriginated >>> using a new Link State ID of 10.0.0.255. >>> >>> (b) A Link State ID of 10.0.0.0 is used for >>> [10.0.0.0,255.255.0.0]. >>> >>> vivek>> >>> Point (2) in e.g should be: >>> a) Reoriginate existing LSA with >>> 10.0.0.0 [10.0.0.0, 255.255.0.0], incrementing >>> sequence number,changing the mask in the body, and >>> inserting the cost of new network. >>> >>> b) Originate a new LSA for LsId >>> 10.0.0.255 [10.0.0.0, 255.255.255.0] >>> >>> >>> Vivek >>> >>> ___________________________________________________ >>> Download the hottest & happening ringtones here! >>> OR SMS: Top tone to 7333 >>> Click here now: >>> http://sms.rediff.com/cgi-bin/ringtone/ringhome.pl >>> >> >> -- >> Acee > > > ___________________________________________________ > Meet your old school or college friends from > 1 Million + database... > Click here to reunite www.batchmates.com/rediff.asp > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Tue Aug 12 23:06:19 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 XAA08343 for ; Tue, 12 Aug 2003 23:06:18 -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.00AD5756@cherry.ease.lsoft.com>; Tue, 12 Aug 2003 23:06:22 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 51009201 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 12 Aug 2003 23:00:45 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 12 Aug 2003 23:00:44 -0400 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id B76F795F3A1 for ; Tue, 12 Aug 2003 20:00:43 -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: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F39AA05.9030301@redback.com> Date: Tue, 12 Aug 2003 23:01:25 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Flooding Procedure To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Naveen Tyagi wrote: > Hi, > I am new to ospf. > This question has been asked earlier and replied by Mr. Moy. But I could not > understand the description. > > I fail to understand how "RFC2328 section 13 point no 6" is en error > case? Hi Naveen, Actually, I think John meant 5 (b). When the LSA is flooded out a subset of the router's interfaces the LSA will be removed from LS request lists as specified in 3.3 (1)(b). Thanks, Acee > > Here is the response From Mr Moy. > *********************************************************** > Date: Fri, 23 Oct 1998 15:09:31 -0400 > Reply-To: Mailing List > Sender: Mailing List > From: "John T. Moy" > Organization: Cascade Communications Corp. > Subject: Re: Flooding Procedure > Comments: To: SS Pillai > Content-Type: text/plain; charset=us-ascii > > It's an error because, if the Database Exchange procedure > were working properly, the LSA on the request list should > have been removed in step 5c of that same section, instead > of reaching step 6. > > John > > SS Pillai wrote: > > >>Subject: Flooding Procedure >>Date: Sun, 18 Oct 1998 21:08:44 +0530 >>From: SS Pillai >>To: discuss@ospf.microsoft.com >> >>Hi, >> In RFC2328 section 13 page no 145 point no 6, it is mentioned >> that "if there is an instance of the LSA on sending neighbor's >> Link state request list, an error has occured ...." >> >> while we are sending LS Request, the neighbor will respond >> in LS Update packet. So there will be an request list >> in our database. How it can be an error?. >> >> I think I not understood properly. Can any one clear my doupt? >>Thanks >>pillai > > > ****************************************************************** > > Section 5c is about deleting LSA from retansmission list and not from the > request list. > Thanks, > Naveen. > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed Aug 13 04:15: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 EAA12062 for ; Wed, 13 Aug 2003 04:15:59 -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.00AD6128@cherry.ease.lsoft.com>; Wed, 13 Aug 2003 4:16:00 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 51038995 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 13 Aug 2003 04:15:59 -0400 Received: from 203.199.83.246 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 13 Aug 2003 04:15:57 -0400 Received: (qmail 19731 invoked by uid 510); 13 Aug 2003 08:15:54 -0000 Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 13 aug 2003 08:15:54 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20030813081554.19730.qmail@webmail35.rediffmail.com> Date: Wed, 13 Aug 2003 08:15:54 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: Re: RFC 2328 : Appendix E To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Printing LSAs from e.g in previous mail : 1) LS2 : 10.0.255.255/16 ; Fwd Addr N1; Metric 10; Type 1; originated by R1 2) LS1 : 10.0.0.0/16 ; Fwd Addr N1; Metric 10; Type 1; originated by R2. Masks are same here and also the destination advertised (Though Link State Id at OSPF level might be different). So they should be functionally equivalent. Or i am misisng a point!!! Vivek On Wed, 13 Aug 2003 Acee Lindem wrote : >Hi Vivek, > >Vivek Dubey wrote: >>Hi Acee, >>Continuing the thread: >> Router R1 originates AS Ext LSAs: >> LS1 : 10.0.0.0/8 >> LS2 : 10.0.255.255/16 ; Fwd Addr N1; Metric 10; Type 1 >> >> Router R2 originates AS Ext LSA: >> LS1 : 10.0.0.0/16 ; Fwd Addr N1; Metric 10; Type 1 >> >>1)Now are LS2(R1) and LS1(R2) functionally equivalent ?? > >No - the masks in the body of the LSA are different. > >> >>2)Further is there a possibility of routers, >> with some supporting Appendix E and others not, >> being present in same domain ?? > >Yes. An OSPFv2 router can't make any assumptions regarding >te setting of the host bits in the Link State ID for type 3 >or 5 LSA's originated by another router. Incremental SPF >computations must take this fact into account. > >> >>Vivek >> >> >> >> >> >>On Wed, 06 Aug 2003 Acee Lindem wrote : >> >>>Hi Vivek, >>> >>>It might be a bit clearer as you suggest but the outcome >>>is the same. The description is from the perspective of the >>>LSAs while the example is from the perspective of >>>routes which need to be advertised. >>> >>> >>>Vivek Dubey wrote: >>> >>>>Conflict in description and example ?? >>>> >>>>RFC 2328:Appendix E >>>>-------------------- >>>>(2) >>>>Obtain the network mask from the body of the already >>>>existing >>>>AS-external-LSA. Call this mask NM2. There are then two >>>>cases: >>>> >>>>o NM2 is longer than NM1. In this case, change the >>>>existing >>>> LSA (having Link State ID of NA) to reference >>>>the >>>>new >>>> network [NA,NM1] by incrementing the sequence >>>>number, >>>> changing the mask in the body to NM1 and inserting the >>>>cost >>>> of the new network. Then originate a new LSA for >>>>the >>>>old >>>> network [NA,NM2], with Link State ID equal to NA >>>>or'ed >>>> together with the bits that are not set in NM2 >>>>(i.e., >>>> network [NA,NM2]'s broadcast address). >>>> >>>>As an example of the algorithm, consider its operation when >>>>the >>>>following sequence of events occurs in a single router >>>>(Router >>>>A). >>>>(1) Router A wants to originate an AS-external-LSA for >>>> [10.0.0.0,255.255.255.0]: >>>> (a) A Link State ID of 10.0.0.0 is used. >>>> >>>>(2) Router A then wants to originate an AS-external-LSA for >>>> [10.0.0.0,255.255.0.0]: >>>> >>>> (a) The LSA for [10.0.0,0,255.255.255.0] is >>>>reoriginated >>>> using a new Link State ID of 10.0.0.255. >>>> >>>> (b) A Link State ID of 10.0.0.0 is used for >>>> [10.0.0.0,255.255.0.0]. >>>> >>>>vivek>> >>>>Point (2) in e.g should be: >>>> a) Reoriginate existing LSA with >>>> 10.0.0.0 [10.0.0.0, 255.255.0.0], incrementing >>>> sequence number,changing the mask in the body, and >>>> inserting the cost of new network. >>>> >>>> b) Originate a new LSA for LsId >>>> 10.0.0.255 [10.0.0.0, 255.255.255.0] >>>> >>>> >>>>Vivek >>>> >>>>___________________________________________________ >>>>Download the hottest & happening ringtones here! >>>>OR SMS: Top tone to 7333 >>>>Click here now: >>>>http://sms.rediff.com/cgi-bin/ringtone/ringhome.pl >>>> >>> >>>-- >>>Acee >> >> >>___________________________________________________ >>Meet your old school or college friends from >>1 Million + database... >>Click here to reunite www.batchmates.com/rediff.asp >> > >-- >Acee ___________________________________________________ Meet your old school or college friends from 1 Million + database... Click here to reunite www.batchmates.com/rediff.asp From owner-ospf@PEACH.EASE.LSOFT.COM Wed Aug 13 08:08: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 IAA16706 for ; Wed, 13 Aug 2003 08:08: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 <2.00AD666D@cherry.ease.lsoft.com>; Wed, 13 Aug 2003 8:08:11 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 51065512 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 13 Aug 2003 08:06:53 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 13 Aug 2003 08:06:52 -0400 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id 04A21442123 for ; Wed, 13 Aug 2003 05:05:16 -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: <20030813081554.19730.qmail@webmail35.rediffmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F3A29A0.6090709@redback.com> Date: Wed, 13 Aug 2003 08:05:52 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: RFC 2328 : Appendix E To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20030813081554.19730.qmail@webmail35.rediffmail.com> Precedence: list Content-Transfer-Encoding: 7bit Vivek Dubey wrote: > Printing LSAs from e.g in previous mail : > > 1) LS2 : 10.0.255.255/16 ; Fwd Addr N1; Metric 10; Type 1; > originated by R1 > > 2) LS1 : 10.0.0.0/16 ; Fwd Addr N1; Metric 10; Type 1; > originated by R2. > > Masks are same here and also the destination advertised > (Though Link State Id at OSPF level might be different). > So they should be functionally equivalent. Ok - misread your E-mail. They both advertise the same destination and will both need to be considered when calculating the route to prefix 10.0.0.0/16. > > Or i am misisng a point!!! > > Vivek > > > On Wed, 13 Aug 2003 Acee Lindem wrote : > >> Hi Vivek, >> >> Vivek Dubey wrote: >> >>> Hi Acee, >>> Continuing the thread: >>> Router R1 originates AS Ext LSAs: >>> LS1 : 10.0.0.0/8 >>> LS2 : 10.0.255.255/16 ; Fwd Addr N1; Metric 10; Type 1 >>> >>> Router R2 originates AS Ext LSA: >>> LS1 : 10.0.0.0/16 ; Fwd Addr N1; Metric 10; Type 1 >>> >>> 1)Now are LS2(R1) and LS1(R2) functionally equivalent ?? >> >> >> No - the masks in the body of the LSA are different. >> >>> >>> 2)Further is there a possibility of routers, >>> with some supporting Appendix E and others not, >>> being present in same domain ?? >> >> >> Yes. An OSPFv2 router can't make any assumptions regarding >> te setting of the host bits in the Link State ID for type 3 >> or 5 LSA's originated by another router. Incremental SPF >> computations must take this fact into account. >> >>> >>> Vivek >>> >>> >>> >>> >>> >>> On Wed, 06 Aug 2003 Acee Lindem wrote : >>> >>>> Hi Vivek, >>>> >>>> It might be a bit clearer as you suggest but the outcome >>>> is the same. The description is from the perspective of the >>>> LSAs while the example is from the perspective of >>>> routes which need to be advertised. >>>> >>>> >>>> Vivek Dubey wrote: >>>> >>>>> Conflict in description and example ?? >>>>> >>>>> RFC 2328:Appendix E >>>>> -------------------- >>>>> (2) >>>>> Obtain the network mask from the body of the already >>>>> existing >>>>> AS-external-LSA. Call this mask NM2. There are then two >>>>> cases: >>>>> >>>>> o NM2 is longer than NM1. In this case, change the >>>>> existing >>>>> LSA (having Link State ID of NA) to reference >>>>> the >>>>> new >>>>> network [NA,NM1] by incrementing the sequence >>>>> number, >>>>> changing the mask in the body to NM1 and inserting the >>>>> cost >>>>> of the new network. Then originate a new LSA for >>>>> the >>>>> old >>>>> network [NA,NM2], with Link State ID equal to NA >>>>> or'ed >>>>> together with the bits that are not set in NM2 >>>>> (i.e., >>>>> network [NA,NM2]'s broadcast address). >>>>> >>>>> As an example of the algorithm, consider its operation when >>>>> the >>>>> following sequence of events occurs in a single router >>>>> (Router >>>>> A). >>>>> (1) Router A wants to originate an AS-external-LSA for >>>>> [10.0.0.0,255.255.255.0]: >>>>> (a) A Link State ID of 10.0.0.0 is used. >>>>> >>>>> (2) Router A then wants to originate an AS-external-LSA for >>>>> [10.0.0.0,255.255.0.0]: >>>>> >>>>> (a) The LSA for [10.0.0,0,255.255.255.0] is >>>>> reoriginated >>>>> using a new Link State ID of 10.0.0.255. >>>>> >>>>> (b) A Link State ID of 10.0.0.0 is used for >>>>> [10.0.0.0,255.255.0.0]. >>>>> >>>>> vivek>> >>>>> Point (2) in e.g should be: >>>>> a) Reoriginate existing LSA with >>>>> 10.0.0.0 [10.0.0.0, 255.255.0.0], incrementing >>>>> sequence number,changing the mask in the body, and >>>>> inserting the cost of new network. >>>>> >>>>> b) Originate a new LSA for LsId >>>>> 10.0.0.255 [10.0.0.0, 255.255.255.0] >>>>> >>>>> >>>>> Vivek >>>>> >>>>> ___________________________________________________ >>>>> Download the hottest & happening ringtones here! >>>>> OR SMS: Top tone to 7333 >>>>> Click here now: >>>>> http://sms.rediff.com/cgi-bin/ringtone/ringhome.pl >>>>> >>>> >>>> -- >>>> Acee >>> >>> >>> >>> ___________________________________________________ >>> Meet your old school or college friends from >>> 1 Million + database... >>> Click here to reunite www.batchmates.com/rediff.asp >>> >> >> -- >> Acee > > > ___________________________________________________ > Meet your old school or college friends from > 1 Million + database... > Click here to reunite www.batchmates.com/rediff.asp > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed Aug 13 08:40:46 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 IAA17513 for ; Wed, 13 Aug 2003 08:40: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 <5.00AD6753@cherry.ease.lsoft.com>; Wed, 13 Aug 2003 8:40:47 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 51066578 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 13 Aug 2003 08:40:46 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 13 Aug 2003 08:40:46 -0400 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id BD15A44213F for ; Wed, 13 Aug 2003 05:40:31 -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: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F3A31E3.9060609@redback.com> Date: Wed, 13 Aug 2003 08:41:07 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: receiving self-orig Lsa To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Jason Chen wrote: > Hi, > > >>-----Original Message----- >>From: Acee Lindem [mailto:acee@REDBACK.COM] >>Sent: Thursday, August 07, 2003 8:54 PM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Re: receiving self-orig Lsa >> >> >>Hi Jason, >> >>Jason Chen wrote: >> >>>Hi, >>> >>>We need some clarification regarding -- "Receiving >> >>self-originated LSA" >> >>>RFC section 13.4 said, >>> >>>".... A self-originated LSA is detected when..... 2) the LSA is a >>>network- LSA and its Link State ID is equal to one of the >> >>router's own >> >>>IP interface addresses. " >>> >>>".....In most cases, the router must then advance the LSA's >> >>LS sequence >> >>>number one past the received LS sequence number, and originate a new >>>instance of the LSA" >>> >>>In an OSPF network, if one router change its OSPF router-id >> >>and then it >> >>>receives self-orig Network Lsa with its old router id from its >>>neighbor. If the criteria (2) is met, should we treat the >> >>received LSA >> >>>as self-orig LSA ? >> >>Yes. >> >>>If we treat the LSA as self-orig LSA, the router will >> >>reoriginate new >> >>>LSA (with new router-id) with sequence number one past the received >>>sequence number. What would be the right behavior once its neighbor >>>receive the new LSA ? >> >>You should flush it from the routing domain as described in the >>third paragraph of section 13.4, RFC 2328. >> > > > Is there issue not to flush those LSA with old/unknown router id ? > Will that cause network unstable ? Since a router LSA's link to the transit network only contains the DR's IP address, the old network LSA could be used in the SPF calcuation. For routers that aren't connected to the transit network, it is difficult to determine which LSA is current. There are hacks to get around this but it is better if the originator follows the specification and purges the stale network LSA. > > >>------ >>Acee > > > -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Thu Aug 14 16:30: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 QAA25849 for ; Thu, 14 Aug 2003 16:30: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 <9.00ADB9DF@cherry.ease.lsoft.com>; Thu, 14 Aug 2003 16:30:54 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 51217998 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 14 Aug 2003 16:30:52 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 14 Aug 2003 16:30:52 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 6844C570060 for ; Thu, 14 Aug 2003 13:30:50 -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: <3F3BF18D.5080704@redback.com> Date: Thu, 14 Aug 2003 16:31:09 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: FYI - New Mailing List for BFD To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit BFD is a protocol for Bi-directional Failure Detection. In the context of OSPFv2/OSPFv3, it could be used to detect outages faster w/o decreasing the hello/router dead intervals to smaller values. -------- Original Message -------- Subject: Mailing list for BFD Date: Wed, 13 Aug 2003 17:17:55 -0700 From: Alex Zinin Reply-To: Alex Zinin To: Routing Area Mailing List CC: grow@lists.uoregon.edu Folks- In order to continue the discussion on draft-katz-ward-bfd in an organized fashion, the following mailing list has been established: List name : rtg-bfd@ietf.org List URL : https://www1.ietf.org/mailman/listinfo/rtg-bfd To subscribe : URL above or rtg-bfd-request@ietf.org Interested participants are encouraged to subscribed to the list. -- Alex http://www.psg.com/~zinin/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion -- Acee From owner-ospf@PEACH.EASE.LSOFT.COM Thu Aug 14 16:41: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 QAA26236 for ; Thu, 14 Aug 2003 16:41: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 <21.00ADBB55@cherry.ease.lsoft.com>; Thu, 14 Aug 2003 16:41:13 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 51218023 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 14 Aug 2003 16:41:00 -0400 Received: from 63.151.139.152 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 14 Aug 2003 16:31:00 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Precedence: bulk Message-ID: <10308141636.AA03224@mcgrew.net> Date: Thu, 14 Aug 2003 16:36:00 -0400 Reply-To: Mailing List Sender: Mailing List From: Kelly McGrew Subject: E-mail address To: OSPF@PEACH.EASE.LSOFT.COM E-mail address My e-mail address will be changing on 1 September 2003 to: kcm at mcgrew dot net When the Internet community get's SPAM under control I may go back to the old one. Stand-by for the change! From owner-ospf*ospf-archive**LISTS*-IETF*-ORG@PEACH.EASE.LSOFT.COM Fri Aug 15 16:10:52 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 QAA11768 for ; Fri, 15 Aug 2003 16:10:52 -0400 (EDT) Received: from PEACH.EASE.LSOFT.COM (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00ADE7CF@cherry.ease.lsoft.com>; Fri, 15 Aug 2003 16:10:44 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 51304073 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 15 Aug 2003 16:10:44 -0400 Received: from 132.151.6.40 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 15 Aug 2003 16:00:44 -0400 Received: from apache by asgard.ietf.org with local (Exim 4.14) id 19nkjU-0000ix-Nb; Fri, 15 Aug 2003 15:59:32 -0400 X-test-idtracker: no Message-ID: Date: Fri, 15 Aug 2003 15:59:32 -0400 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: The IESG Subject: Protocol Action: 'Graceful OSPF Restart' to Proposed Standard Comments: cc: Internet Architecture Board , RFC Editor To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list The IESG has approved the Internet-Draft 'Graceful OSPF Restart' as a Proposed Standard. This document is the product of the Open Shortest Path First IGP Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. Technical Summary This memo documents an enhancement to the OSPF routing protocol, whereby an OSPF router can stay on the forwarding path even as its OSPF software is restarted. This is called "graceful restart" or "non-stop forwarding". Deployment of this mechanism in the service provider networks should decrease unnecessary path recalculation and traffic rerouting. Working Group Summary The WG considered two proposals to address the graceful restart problem--the one represented in draft-nguyen-ospf-restart, and the one described in the submitted document. The main difference between the two proposals was in the mechanism for graceful restart signaling, database synchronization and determining when graceful restart had completed. At the 50th IETF in Minneapolis the WG made a decision via rough consensus to proceed with the latter approach, which since then has receive substantial technical review within the WG and passed the WG Last Call. The described mechanism has been implemented and deployed by several vendors. Protocol Quality The specification has been reviewed for the IESG by Alex Zinin. From owner-ospf@PEACH.EASE.LSOFT.COM Fri Aug 15 16:24:17 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 QAA12139 for ; Fri, 15 Aug 2003 16:24:16 -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 <10.00ADE7A7@cherry.ease.lsoft.com>; Fri, 15 Aug 2003 16:24:19 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 51306767 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 15 Aug 2003 16:24:18 -0400 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 15 Aug 2003 16:24:18 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19nl7R-0000Js-Fl for OSPF@PEACH.EASE.LSOFT.COM; Fri, 15 Aug 2003 20:24:17 +0000 X-Mailer: The Bat! (v1.62i) Personal X-Priority: 3 (Normal) References: <96615458792.20030814180213@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <1953469028.20030815132353@psg.com> Date: Fri, 15 Aug 2003 13:23:53 -0700 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Fwd: Last Call on draft-gill-gtsh-00.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <96615458792.20030814180213@psg.com> Precedence: list Content-Transfer-Encoding: 7bit FYI below. -- Alex http://www.psg.com/~zinin/ This is a forwarded message From: Alex Zinin To: routing-discussion@ietf.org Cc: Date: Thursday, August 14, 2003, 6:02:13 PM Subject: Last Call on draft-gill-gtsh-00.txt ===8<==============Original message text=============== Folks- The IESG received a request to progress draft-gill-gtsh-00.txt as an individual contribution towards the EXPERIMENTAL RFC status. The concept described in the document (as well as the original document known as draft-gill-btsh) has been widely discussed in the community, and I would like to start a 4-week Last Call on the Routing Area mailing list to encourage review and gauge the consensus on the document before taking it to the IESG. Please read the document and indicate if you support it going forward (do send a message if you support). The last call ends on September 12th, 2003. This message will be forwarded as an FYI to certain individual WGs. However, please send your comments to routing-discussion@ietf.org -- Alex Zinin IETF Routing Area Co-Director http://www.psg.com/~zinin/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion ===8<===========End of original message text=========== From owner-ospf@PEACH.EASE.LSOFT.COM Tue Aug 19 10:18: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 KAA13009 for ; Tue, 19 Aug 2003 10:18: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 <16.00AEA525@cherry.ease.lsoft.com>; Tue, 19 Aug 2003 10:18:06 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 51621121 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 19 Aug 2003 10:18:04 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 19 Aug 2003 10:08:04 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11822; Tue, 19 Aug 2003 10:08:00 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200308191408.KAA11822@ietf.org> Date: Tue, 19 Aug 2003 10:07:59 -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-ospf-ospfv3-traffic-01.txt 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 Open Shortest Path First IGP Working Group of the IETF. Title : Traffic Engineering Extensions to OSPF version 3 Author(s) : K. Ishiguro, T. Takada Filename : draft-ietf-ospf-ospfv3-traffic-01.txt Pages : 5 Date : 2003-8-19 This document describes extensions to OSPFv3 to support intra-area Traffic Engineering (TE). This document extends OSPFv2 TE to both IPv4 and IPv6 networks. A new TLV and several new sub-TLVs are defined to support IPv6 networks. The use of the new TLV and sub-TLVs is not limited to OSPFv3. They may also be used in OSPFv2. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-traffic-01.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-ospf-ospfv3-traffic-01.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-ospf-ospfv3-traffic-01.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-8-19101503.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-ospfv3-traffic-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-ospfv3-traffic-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-19101503.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Tue Aug 19 10:42: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 KAA15633 for ; Tue, 19 Aug 2003 10:42: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 <10.00AEA7F8@cherry.ease.lsoft.com>; Tue, 19 Aug 2003 10:42:56 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 51622592 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 19 Aug 2003 10:42:54 -0400 Received: from 131.137.245.203 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 19 Aug 2003 10:32:54 -0400 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 6672B206608 for ; Tue, 19 Aug 2003 10:31:20 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19p7Bc-0000KZ-PI for ietf-announce-list@asgard.ietf.org; Tue, 19 Aug 2003 10:10:12 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19p79Z-00089w-3W for all-ietf@asgard.ietf.org; Tue, 19 Aug 2003 10:08:05 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11822; Tue, 19 Aug 2003 10:08:00 -0400 (EDT) Precedence: bulk MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+255267_84792818212309_8981125214" Message-ID: <200308191408.KAA11822@ietf.org> Date: Tue, 19 Aug 2003 10:07:59 -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-ospf-ospfv3-traffic-01.txt To: OSPF@PEACH.EASE.LSOFT.COM --MIMEStream=_0+255267_84792818212309_8981125214 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Traffic Engineering Extensions to OSPF version 3 Author(s) : K. Ishiguro, T. Takada Filename : draft-ietf-ospf-ospfv3-traffic-01.txt Pages : 5 Date : 2003-8-19 This document describes extensions to OSPFv3 to support intra-area Traffic Engineering (TE). This document extends OSPFv2 TE to both IPv4 and IPv6 networks. A new TLV and several new sub-TLVs are defined to support IPv6 networks. The use of the new TLV and sub-TLVs is not limited to OSPFv3. They may also be used in OSPFv2. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-traffic-01.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-ospf-ospfv3-traffic-01.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-ospf-ospfv3-traffic-01.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. --MIMEStream=_0+255267_84792818212309_8981125214 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+93860_640998967712827_6572578596" --MIMEStream=_1+93860_640998967712827_6572578596 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-19101503.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-ospfv3-traffic-01.txt --MIMEStream=_1+93860_640998967712827_6572578596 Content-Type: Message/External-body; name="draft-ietf-ospf-ospfv3-traffic-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-19101503.I-D@ietf.org> --MIMEStream=_1+93860_640998967712827_6572578596-- --MIMEStream=_0+255267_84792818212309_8981125214-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Aug 20 05:11:42 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 FAA00231 for ; Wed, 20 Aug 2003 05:11:42 -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.00AEFDCB@cherry.ease.lsoft.com>; Wed, 20 Aug 2003 5:11:45 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 51739740 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 20 Aug 2003 05:11:43 -0400 Received: from 202.54.124.179 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 20 Aug 2003 05:11:43 -0400 Received: (qmail 9204 invoked by uid 510); 20 Aug 2003 09:10:00 -0000 Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 20 aug 2003 09:10:00 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20030820091000.9203.qmail@webmail10.rediffmail.com> Date: Wed, 20 Aug 2003 09:10:00 -0000 Reply-To: Mailing List Sender: Mailing List From: arunsy To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi all, Would someone be able to explain the following clause in RFC 2328 section 16.5 (Incremental Updates -- Summary LSAs) Case 2 (Area A is a transit area and the router is an ABR). Case 2: Area A is a transit area and the router is an area border router. In this case, the following calculations must be performed. First, if N's routing table entry presently contains one or more inter-area paths that utilize the transit area Area A, these paths should be removed. If this removes all paths from the routing table entry, the entry should be invalidated. The entry's old values should be saved for later comparisons. Next the calculation in Section 16.3 must be run again for the single destination N. If the results of this calculation have caused the cost to N to increase, the complete routing table calculation must be rerun starting with the Dijkstra algorithm specified in Section 16.1. Otherwise, if the cost/path to an AS boundary router (as would be the case for a Type 4 summary-LSA) or to any forwarding addresses has changed, all AS-external-LSAs will have to be reexamined by rerunning the calculation in Section 16.4. Otherwise, if N is now newly unreachable, the calculation in Section 16.4 must be rerun for the single destination N, in case an alternate external route to N exists. Why complete routing table calculation need to be rerun if the calculated new route has the higher cost than that of older one. And how this behaviour is different from case 1? And one more thing, how a router (ABR) knows whether the path of the route is utilizing the transit area, since all the inter-area routes in ABR are always associated with the Back Bone (even after step 16.3). Thanks and Regards, ARun SY. From owner-ospf@PEACH.EASE.LSOFT.COM Wed Aug 20 11:16: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 LAA13350 for ; Wed, 20 Aug 2003 11:16:11 -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.00AF155D@cherry.ease.lsoft.com>; Wed, 20 Aug 2003 11:16:14 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 51792439 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 20 Aug 2003 11:15:54 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 20 Aug 2003 11:05:51 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12709; Wed, 20 Aug 2003 11:05:45 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200308201505.LAA12709@ietf.org> Date: Wed, 20 Aug 2003 11:05:45 -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-ospf-scalability-06.txt 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 Open Shortest Path First IGP Working Group of the IETF. Title : Prioritized Treatment of Specific OSPF Packets and Congestion Avoidance Author(s) : G. Choudhury Filename : draft-ietf-ospf-scalability-06.txt Pages : 14 Date : 2003-8-19 This document recommends methods that are intended to improve the scalability and stability of large networks using OSPF (Open Shortest Path First) protocol. The methods include processing OSPF Hellos and LSA (Link State Advertisement) Acknowledgments at a higher priority compared to other OSPF packets, and other congestion avoidance procedures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-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-ospf-scalability-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-ospf-scalability-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-8-19161559.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-scalability-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-scalability-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-19161559.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Aug 20 11:19: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 LAA13500 for ; Wed, 20 Aug 2003 11:19: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 <3.00AF16DD@cherry.ease.lsoft.com>; Wed, 20 Aug 2003 11:19:43 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 51793463 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 20 Aug 2003 11:19:15 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 20 Aug 2003 11:09:14 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12939; Wed, 20 Aug 2003 11:09:08 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200308201509.LAA12939@ietf.org> Date: Wed, 20 Aug 2003 11:09:08 -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-ospf-ospfv3-auth-03.txt 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 Open Shortest Path First IGP Working Group of the IETF. Title : Authentication/Confidentiality for OSPFv3 Author(s) : M. Gupta, N. Melam Filename : draft-ietf-ospf-ospfv3-auth-03.txt Pages : 8 Date : 2003-8-20 This document describes means/mechanisms to provide authentication/confidentiality to OSPFv3 using IPv6 AH/ESP Extension Header. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-03.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-ospf-ospfv3-auth-03.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-ospf-ospfv3-auth-03.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-8-20112457.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-ospfv3-auth-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-ospfv3-auth-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-20112457.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Aug 20 11:51:02 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 LAA16259 for ; Wed, 20 Aug 2003 11:51: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 <11.00AF1E8A@cherry.ease.lsoft.com>; Wed, 20 Aug 2003 11:51:06 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 51798977 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 20 Aug 2003 11:51:00 -0400 Received: from 131.137.245.203 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 20 Aug 2003 11:41:00 -0400 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 87C02206607 for ; Wed, 20 Aug 2003 11:39:19 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19pUb1-0003Nb-KG for ietf-announce-list@asgard.ietf.org; Wed, 20 Aug 2003 11:09:59 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19pUaJ-0003LT-48 for all-ietf@asgard.ietf.org; Wed, 20 Aug 2003 11:09:15 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12939; Wed, 20 Aug 2003 11:09:08 -0400 (EDT) Precedence: bulk MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+257574_86754333913640_7759650192" Message-ID: <200308201509.LAA12939@ietf.org> Date: Wed, 20 Aug 2003 11:09:08 -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-ospf-ospfv3-auth-03.txt To: OSPF@PEACH.EASE.LSOFT.COM --MIMEStream=_0+257574_86754333913640_7759650192 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Authentication/Confidentiality for OSPFv3 Author(s) : M. Gupta, N. Melam Filename : draft-ietf-ospf-ospfv3-auth-03.txt Pages : 8 Date : 2003-8-20 This document describes means/mechanisms to provide authentication/confidentiality to OSPFv3 using IPv6 AH/ESP Extension Header. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-03.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-ospf-ospfv3-auth-03.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-ospf-ospfv3-auth-03.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. --MIMEStream=_0+257574_86754333913640_7759650192 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+286907_36005792723750_625127677" --MIMEStream=_1+286907_36005792723750_625127677 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-20112457.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-ospfv3-auth-03.txt --MIMEStream=_1+286907_36005792723750_625127677 Content-Type: Message/External-body; name="draft-ietf-ospf-ospfv3-auth-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-20112457.I-D@ietf.org> --MIMEStream=_1+286907_36005792723750_625127677-- --MIMEStream=_0+257574_86754333913640_7759650192-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Aug 20 13:21: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 NAA20589 for ; Wed, 20 Aug 2003 13:21: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 <0.00AF34B9@cherry.ease.lsoft.com>; Wed, 20 Aug 2003 13:21:06 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 51811208 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 20 Aug 2003 13:20:48 -0400 Received: from 63.78.179.216 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 20 Aug 2003 13:20:48 -0400 Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7KHKl121660 for ; Wed, 20 Aug 2003 12:20:47 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 20 Aug 2003 12:20:46 -0500 Received: from daebe009.NOE.Nokia.com ([172.18.242.190]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 20 Aug 2003 12:20:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: I-D ACTION:draft-ietf-ospf-ospfv3-auth-03.txt Thread-Index: AcNnL2D2bFrrAdKnQJ69w0gJqypMpwAD4FpQ X-OriginalArrivalTime: 20 Aug 2003 17:20:36.0107 (UTC) FILETIME=[5E695DB0:01C3673F] Message-ID: <8D260779A766FB4A9C1739A476F84FA476C443@daebe009.americas.nokia.com> Date: Wed, 20 Aug 2003 12:20:35 -0500 Reply-To: Mailing List Sender: Mailing List From: Mukesh.Gupta@NOKIA.COM Subject: Re: I-D ACTION:draft-ietf-ospf-ospfv3-auth-03.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable As decided in the mailing list, the selection of the source and = destination=20 addresses for virtual link end points has been changed to "first address = with LA bit set in the intra-area-prefix-LSAs". regards Mukesh > -----Original Message----- > From: ext Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Wednesday, August 20, 2003 8:09 AM > Cc: OSPF@PEACH.EASE.LSOFT.COM > Subject: I-D ACTION:draft-ietf-ospf-ospfv3-auth-03.txt >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Open Shortest Path First IGP=20 > Working Group of the IETF. >=20 > Title : Authentication/Confidentiality for OSPFv3 > Author(s) : M. Gupta, N. Melam > Filename : draft-ietf-ospf-ospfv3-auth-03.txt > Pages : 8 > Date : 2003-8-20 > =09 > This document describes means/mechanisms to provide=20 > authentication/confidentiality to OSPFv3 using IPv6 AH/ESP Extension=20 > Header. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-03.txt >=20 > To remove yourself from the IETF Announcement list, send a message to=20 > ietf-announce-request with the word unsubscribe in the body=20 > of the message. >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ospf-ospfv3-auth-03.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html=20 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ospf-ospfv3-auth-03.txt". > =09 > 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=20 > 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. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 From owner-ospf@PEACH.EASE.LSOFT.COM Wed Aug 20 15:14:46 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 PAA01660 for ; Wed, 20 Aug 2003 15:14: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 <8.00AF41F4@cherry.ease.lsoft.com>; Wed, 20 Aug 2003 15:14:48 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 51829049 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 20 Aug 2003 15:14:43 -0400 Received: from 192.128.166.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 20 Aug 2003 15:14:43 -0400 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h7KJ3XWJ002554 for ; Wed, 20 Aug 2003 15:14:43 -0400 Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.88) by attrh5i.attrh.att.com (6.5.032) id 3F307C6C003F4591 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 20 Aug 2003 15:14:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: I-D ACTION:draft-ietf-ospf-scalability-06.txt Thread-Index: AcNnLioDqS8EFXLNQC22vDNlUFs2LQAH2aGQ Message-ID: <73656AE8EE4C9C4D9FFF9DBFEAE9A00F223CA5@KCCLUST06EVS1.ugd.att.com> Date: Wed, 20 Aug 2003 14:14:43 -0500 Reply-To: Mailing List Sender: Mailing List From: "Choudhury, Gagan L, ALABS" Subject: Re: I-D ACTION:draft-ietf-ospf-scalability-06.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi All, Besides some editorial changes and rearrangement of texts in places the main changes compared to the previous version are given below. Thanks to the Routing Area Directors, OSPF WG Chairs and all others who commented on previous versions. With regards, Gagan Choudhury _____________________________________________________________________ Summary of Changes 1. Only the editor is left in the front page and info on all=20 Contributing authors is given in Section 7. 2. In Recommendation 1 of Section 2 and Recommendation 2 of Appendix C changes are made so that they are now compatible with the use of Cryptographic Authentication (AuType =3D 2). These changes are also=20 noted in the section on security considerations (Section 3). 3. In Recommendations 2 and 4 the term "AllSPFRouters" is used instead of the term "224.0.0.5". 4. Recommendation 4 has been enhanced by using an exponential backoff mechanism. 5. In Recommendation 5 no specific value of the parameter "n" is = suggested but its value is recommended to be configurable. 6. The Simulation Section (old Appendix B) is dropped and instead an=20 informative reference ([Ref12]) is made to the simulation work. 7. A new Appendix B is added that has a list of all variables used in the document and their example values if appropriate. 8. In recommendation 2 of Appendix C, reference to RFC 2474 is made. =20 -----Original Message----- From: Internet-Drafts@IETF.ORG [mailto:Internet-Drafts@IETF.ORG] Sent: Wednesday, August 20, 2003 11:06 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: I-D ACTION:draft-ietf-ospf-scalability-06.txt A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Open Shortest Path First IGP Working = Group of the IETF. Title : Prioritized Treatment of Specific OSPF Packets = and Congestion Avoidance Author(s) : G. Choudhury Filename : draft-ietf-ospf-scalability-06.txt Pages : 14 Date : 2003-8-19 This document recommends methods that are intended to improve the scalability and stability of large networks using OSPF (Open Shortest Path First) protocol. The methods include processing OSPF Hellos and LSA (Link State Advertisement) Acknowledgments at a higher priority compared to other OSPF packets, and other congestion avoidance procedures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-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-ospf-scalability-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-ospf-scalability-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. From owner-ospf@PEACH.EASE.LSOFT.COM Thu Aug 21 15:04: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 PAA22690 for ; Thu, 21 Aug 2003 15:04: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 <9.00AF84BB@cherry.ease.lsoft.com>; Thu, 21 Aug 2003 15:02:29 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 52001616 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 21 Aug 2003 15:01:49 -0400 Received: from 65.200.123.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 21 Aug 2003 15:01:48 -0400 Received: (qmail 15310 invoked from network); 21 Aug 2003 19:01:49 -0000 Received: from bigbird.nj.us.utstar.com (172.16.36.21) by lxmail.nj.us.utstar.com with SMTP; 21 Aug 2003 19:01:49 -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 PAA14415 for ; Thu, 21 Aug 2003 15:01:49 -0400 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200308211901.PAA14415@bigbird.nj.us.utstar.com> Date: Thu, 21 Aug 2003 15:01:49 -0400 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Working Group Last Call for draft-ietf-ospf-scalability-06.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list 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 Thu Aug 21 17:52: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 RAA02550 for ; Thu, 21 Aug 2003 17:52: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 <11.00AF8E6E@cherry.ease.lsoft.com>; Thu, 21 Aug 2003 17:52:46 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 52020957 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 21 Aug 2003 17:52:45 -0400 Received: from 67.106.152.115 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 21 Aug 2003 17:42:45 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3682D.273FFBAC" Thread-Topic: Initializing.... Thread-Index: AcNoLSdYkUhJ4ZfFQhSmrPK53IbBAg== Message-ID: Date: Thu, 21 Aug 2003 17:42:43 -0400 Reply-To: Mailing List Sender: Mailing List From: Sanjay Jaiman Subject: Initializing.... To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------_=_NextPart_001_01C3682D.273FFBAC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 I am just starting off trying to configure ospf on my linux host (running it in non-host mode). I am using John Moy's code from ospf.org. =20 =20 I have two linux machines configured as routers running ospfd. This is how my config file looks like on Machine A- =20 > routerid 161.20.0.1 > area 0.0.0.1 > interface 161.20.0.1 1 =20 My other linux host - Machine B (running as a router) connected directly on the 161.20.0 network is also connected to an additional "171.20.0" network. Thus this router has the following config =20 > routerid 161.20.0.2 > area 0.0.0.1 > interface 161.20.0.2 1 > interface 171.20.0.1 =20 I am not seeing the route to network 171.20.0 on Machine A appear as expected. Though I am still trying to figure this out, could someone give me any quick pointers to get me going. =20 Thanks =20 Sanjay Jaiman =20 =20 ------_=_NextPart_001_01C3682D.273FFBAC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I am just starting off trying to configure ospf on my = linux host (running it in non-host mode).

I am using John Moy’s code from ospf.org.  =

 

I have two linux machines configured as routers = running ospfd.  This is how my config file looks like on Machine = A–

 

> routerid 161.20.0.1

> area 0.0.0.1

> interface 161.20.0.1 1

 

My other linux host – Machine B (running as a = router) connected directly on the 161.20.0 network is also connected to an additional = “171.20.0” network.

Thus this router has the following = config

 

> routerid 161.20.0.2

> area 0.0.0.1

> interface 161.20.0.2 1

> interface 171.20.0.1

 

I am not seeing the route to network 171.20.0 on = Machine A appear as expected.  Though I am still trying to figure this out, = could someone give me any quick pointers to get me going.

 

Thanks

 

Sanjay = Jaiman    

 

=00 ------_=_NextPart_001_01C3682D.273FFBAC-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Aug 22 03:37: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 DAA09068 for ; Fri, 22 Aug 2003 03:37: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 <3.00AFA3E3@cherry.ease.lsoft.com>; Fri, 22 Aug 2003 3:37:59 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 52098134 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 22 Aug 2003 03:37:57 -0400 Received: from 203.199.83.146 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 22 Aug 2003 03:37:57 -0400 Received: (qmail 10202 invoked by uid 510); 22 Aug 2003 07:37:50 -0000 Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 22 aug 2003 07:37:50 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20030822073750.10201.qmail@webmail24.rediffmail.com> Date: Fri, 22 Aug 2003 07:37:50 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: Re: Initializing.... To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Not much from info given except : LSDB dump at A - Check the router LSA to see if B advertises the link to missing interface (if routers are in sync)." Vivek On Fri, 22 Aug 2003 Sanjay Jaiman wrote : >Hello, > > > >I am just starting off trying to configure ospf on my linux >host >(running it in non-host mode). > >I am using John Moy's code from ospf.org. > > > >I have two linux machines configured as routers running ospfd. >This is >how my config file looks like on Machine A- > > > > > routerid 161.20.0.1 > > > area 0.0.0.1 > > > interface 161.20.0.1 1 > > > >My other linux host - Machine B (running as a router) connected >directly >on the 161.20.0 network is also connected to an additional >"171.20.0" >network. > >Thus this router has the following config > > > > > routerid 161.20.0.2 > > > area 0.0.0.1 > > > interface 161.20.0.2 1 > > > interface 171.20.0.1 > > > >I am not seeing the route to network 171.20.0 on Machine A appear >as >expected. Though I am still trying to figure this out, could >someone >give me any quick pointers to get me going. > > > >Thanks > > > >Sanjay Jaiman > > > ___________________________________________________ Meet your old school or college friends from 1 Million + database... Click here to reunite www.batchmates.com/rediff.asp From owner-ospf@PEACH.EASE.LSOFT.COM Sat Aug 23 13:02:27 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 NAA17249 for ; Sat, 23 Aug 2003 13:02: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 <10.00AFF45E@cherry.ease.lsoft.com>; Sat, 23 Aug 2003 13:02:29 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 52305398 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 23 Aug 2003 13:02:24 -0400 Received: from 209.119.1.39 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 23 Aug 2003 13:02:24 -0400 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <11.0037A01D@grape.ease.lsoft.com>; Sat, 23 Aug 2003 13:02:25 -0400 Message-ID: Date: Sat, 23 Aug 2003 13:02:24 -0400 Reply-To: Mailing List Sender: Mailing List From: Igor Miroshnik Subject: Action on SeqNumberMismatch To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list All, RFC 2328 says: " State(s): Exchange or greater Event: SeqNumberMismatch New state: ExStart Action: The (possibly partially formed) adjacency is torn down, and then an attempt is made at reestablishment. The neighbor state first transitions to ExStart. The Link state retransmission list, Database summary list and Link state request list are cleared of LSAs. Then the router increments the DD sequence number in the neighbor data structure, declares itself master (sets the master/slave bit to master), and starts sending Database Description Packets, with the initialize (I), more (M) and master (MS) bits set. This Database Description Packet should be otherwise empty (see Section 10.8)." Questions: 1) Is the Database Description Packet sent empty? 2) If so, what is the meaning of the word "otherwise" in the end of the quotaton? Thanks, Igor From owner-ospf@PEACH.EASE.LSOFT.COM Sat Aug 23 13:22:27 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 NAA18122 for ; Sat, 23 Aug 2003 13:22: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.00AFF41B@cherry.ease.lsoft.com>; Sat, 23 Aug 2003 13:22:27 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 52307169 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 23 Aug 2003 13:22:25 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 23 Aug 2003 13:22:25 -0400 Received: from redback.com (pptp-6-148.redback.com [155.53.6.148]) by prattle.redback.com (Postfix) with ESMTP id D9AE222BE6A for ; Sat, 23 Aug 2003 10:22:24 -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: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F47A2B0.6020808@redback.com> Date: Sat, 23 Aug 2003 13:21:52 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Action on SeqNumberMismatch To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit Hi Igor, Igor Miroshnik wrote: >All, > >RFC 2328 says: > >" State(s): Exchange or greater > > Event: SeqNumberMismatch > > New state: ExStart > > Action: The (possibly partially formed) adjacency is torn > down, and then an attempt is made at > reestablishment. The neighbor state first > transitions to ExStart. The Link state > retransmission list, Database summary list and Link > state request list are cleared of LSAs. Then the > router increments the DD sequence number in the > neighbor data structure, declares itself master > (sets the master/slave bit to master), and starts > sending Database Description Packets, with the > initialize (I), more (M) and master (MS) bits set. > This Database Description Packet should be otherwise > empty (see Section 10.8)." > >Questions: > >1) Is the Database Description Packet sent empty? > Yes. >2) If so, what is the meaning of the word "otherwise" in the end of the >quotaton? > It means that the DD packet only contains the OSPF header and the fixed portion of the DD packet (i.e., interface mtu, options, DD bits, and DD sequence number). > >Thanks, >Igor > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Aug 26 11:33:46 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 LAA11360 for ; Tue, 26 Aug 2003 11:33: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 <2.00B0911C@cherry.ease.lsoft.com>; Tue, 26 Aug 2003 11:33:10 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 52668385 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 26 Aug 2003 11:33:08 -0400 Received: from 209.119.0.34 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 26 Aug 2003 11:33:08 -0400 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <13.0037B50A@grape.ease.lsoft.com>; Tue, 26 Aug 2003 11:33:09 -0400 Message-ID: Date: Tue, 26 Aug 2003 11:33:03 -0400 Reply-To: Mailing List Sender: Mailing List From: Igor Miroshnik Subject: Re: Query on implementation of SNMP TRAP ospfTxRetransmit To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Dear All, The previous discussion seems to converge at using the first LSDB entry to associate the trap with. I wonder, what one can do when retransmitting empty DB summaries. (For instanse, when the master has nothing to send but still expects something from the slave.) On Thu, 31 Oct 2002 15:49:51 +0530, Roy Jose wrote: >Hi Venkata, Acee, > >Thanks for your responses. I think, I will also use the first LSA. The NM >station doesn't always sit in the network, where congestion has happened. > >Thanks, >Roy > >> Acee, >> >> -> I haven't implemented this trap but I'd just use the first LSA in >> -> packet. >> >> My implementation uses the first LSA. >> >> -> Not speaking as WG co-chair and being completely >> -> honest, I can't imagine why anyone would enable this trap in the >> -> first place. One of the main causes of retransmissions is congestion >> -> and sending this trap would only exacerbate matters. >> >> Frankly, I used this trap to figure out some of the >> bugs in the past. Traps are sent to network manager >> and in most of the cases NM is out-of-band signaling. >> Congestion exacerbating in the data path is nothing >> to do with sending the trap. >> >> For that matter, a packet not reaching the destination >> may be because of thousands of reasons not necessarily >> because of congestion. >> >> For example, link local LSAs should go on the exact >> interface it is supposed to go (with out looking at >> the route tables) - for that we have to enable some >> of the IP socket options. If not, link local LSAs are >> keep on retransmitted but never acked back. Until >> unless admin gets a traps he/she can never figure out >> why a particular message/packet/LSA is being flapped. >> (unless he checks the error statistics/RtmsQ explicitly) >> >> -- >> Venkata. >> From owner-ospf@PEACH.EASE.LSOFT.COM Fri Aug 29 13:15:17 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 NAA15496 for ; Fri, 29 Aug 2003 13:15:16 -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.00B16FE4@cherry.ease.lsoft.com>; Fri, 29 Aug 2003 13:15:21 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 53177460 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 29 Aug 2003 13:15:18 -0400 Received: from 63.231.195.113 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 29 Aug 2003 13:15:18 -0400 Received: (qmail 41313 invoked by uid 0); 29 Aug 2003 16:37:15 -0000 Received: from mpls-pop-14.inet.qwest.net (63.231.195.14) by mpls-qmqp-02.inet.qwest.net with QMQP; 29 Aug 2003 16:37:15 -0000 Received: from 0-2pool146-97.nas9.minneapolis1.mn.us.da.qwest.net (HELO charita) (67.4.146.97) by mpls-pop-14.inet.qwest.net with SMTP; 29 Aug 2003 17:15:18 -0000 References: <3F47A2B0.6020808@redback.com> 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: <001301c36e50$d2949de0$cbc8c8c8@sdksoft.com> Date: Fri, 29 Aug 2003 12:13:10 -0500 Reply-To: Mailing List Sender: Mailing List From: Parag Deshpande Subject: DB Synchronization To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit 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. I was wondering whether this can be resolved faster. Thanks Parag From owner-ospf@PEACH.EASE.LSOFT.COM Fri Aug 29 13:57:20 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 NAA18344 for ; Fri, 29 Aug 2003 13:56: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 <23.00B172DF@cherry.ease.lsoft.com>; Fri, 29 Aug 2003 13:55:18 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 53180985 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 29 Aug 2003 13:54:46 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 29 Aug 2003 13:54:46 -0400 Received: from redback.com (montreal.redback.com [155.53.42.143]) by prattle.redback.com (Postfix) with ESMTP id 404044B2C8D for ; Fri, 29 Aug 2003 10:53:21 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.1) Gecko/20020829 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3F47A2B0.6020808@redback.com> <001301c36e50$d2949de0$cbc8c8c8@sdksoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F4F9310.7000300@redback.com> Date: Fri, 29 Aug 2003 10:53:20 -0700 Reply-To: Mailing List Sender: Mailing List From: Rikki Nguyen Subject: Re: DB Synchronization To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit 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 Fri Aug 29 14:12: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 OAA19879 for ; Fri, 29 Aug 2003 14:12:23 -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.00B171D9@cherry.ease.lsoft.com>; Fri, 29 Aug 2003 14:11:22 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 53181829 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 29 Aug 2003 14:11:18 -0400 Received: from 63.231.195.115 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 29 Aug 2003 14:10:14 -0400 Received: (qmail 31091 invoked by uid 0); 29 Aug 2003 18:09:57 -0000 Received: from mpls-pop-08.inet.qwest.net (63.231.195.8) by mpls-qmqp-04.inet.qwest.net with QMQP; 29 Aug 2003 18:09:57 -0000 Received: from 0-2pool146-97.nas9.minneapolis1.mn.us.da.qwest.net (HELO charita) (67.4.146.97) by mpls-pop-08.inet.qwest.net with SMTP; 29 Aug 2003 18:09:57 -0000 References: <3F47A2B0.6020808@redback.com> <001301c36e50$d2949de0$cbc8c8c8@sdksoft.com> <3F4F9310.7000300@redback.com> 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: <003701c36e58$747e0860$cbc8c8c8@sdksoft.com> Date: Fri, 29 Aug 2003 13:07:48 -0500 Reply-To: Mailing List Sender: Mailing List From: Parag Deshpande Subject: Re: DB Synchronization To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit 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 Fri Aug 29 14:14:56 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 OAA20102 for ; Fri, 29 Aug 2003 14:14:56 -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.00B1726B@cherry.ease.lsoft.com>; Fri, 29 Aug 2003 14:15:00 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 53182168 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 29 Aug 2003 14:14:20 -0400 Received: from 63.150.47.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 29 Aug 2003 14:14:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: DB Synchronization Thread-Index: AcNuUThbCFNFyLEcQui5kFtpiIm3hAAAxcZg Message-ID: Date: Fri, 29 Aug 2003 10:40:25 -0700 Reply-To: Mailing List Sender: Mailing List From: Shanthi Pendyala Subject: Re: DB Synchronization To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable hi, Router A will request a copy of the stale LSA from B even though it has = the more upto-date LSA. It will then immediately flood the updated LSA after increasing the seq no. so the DB exchange will complete.. shanthi kiran -----Original Message----- From: Parag Deshpande [mailto:paragdeshpande@SDKSOFT.COM] Sent: Friday, August 29, 2003 10:13 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: DB Synchronization 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 =3D N1. Then Router A goes down & comes up again & reoriginates ASExt lsa for network N1/m2 with LSID =3D N1 and then gets adjacent with Router B. **where m1 !=3D 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. I was wondering whether this can be resolved faster. Thanks Parag From owner-ospf@PEACH.EASE.LSOFT.COM Fri Aug 29 15:38:03 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 PAA28135 for ; Fri, 29 Aug 2003 15:37: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 <8.00B17865@cherry.ease.lsoft.com>; Fri, 29 Aug 2003 15:37:13 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 53190834 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 29 Aug 2003 15:37:08 -0400 Received: from 63.231.195.112 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 29 Aug 2003 15:36:44 -0400 Received: (qmail 29480 invoked by uid 0); 29 Aug 2003 19:36:31 -0000 Received: from unknown (63.231.195.1) by mpls-qmqp-01.inet.qwest.net with QMQP; 29 Aug 2003 19:36:31 -0000 Received: from 0-2pool146-97.nas9.minneapolis1.mn.us.da.qwest.net (HELO charita) (67.4.146.97) by mpls-pop-01.inet.qwest.net with SMTP; 29 Aug 2003 19:36:31 -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: <004901c36e64$8c601d40$cbc8c8c8@sdksoft.com> Date: Fri, 29 Aug 2003 14:34:19 -0500 Reply-To: Mailing List Sender: Mailing List From: Parag Deshpande Subject: Re: DB Synchronization To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I will be more clear here -- - Router A originates the LSA with seq no = 80000001 (Say mask is /8) - Router B receives it. - Now Router A goes down and comes up again. - Originates LSA (with different mask - /16 but same lsid) with Seq no. = 80000001 (This always results in same checksum assuming other parameters such as cost etc. are same!!) Now during DB exchange - Router A receives a DD packet with its own LSA listed - however when it compares DB LSA with one in DD packet the Seq number and Checksum would be same (and age difference < MAXAGE_DIFF) so it would assume that its the same LSA and not request it. - Same thing happens at Router B. - Untill Router A reoriginates the LSA Router B would still keep the Old LSA (mask = /8). As I understand this is a very rare case - but I was thinking if OSPF rfcs provide any mechanism to resolve this faster - though I didn't find any such references. Thanks Parag ----- Original Message ----- From: Shanthi Pendyala To: Sent: Friday, August 29, 2003 12:40 PM Subject: Re: DB Synchronization hi, Router A will request a copy of the stale LSA from B even though it has the more upto-date LSA. It will then immediately flood the updated LSA after increasing the seq no. so the DB exchange will complete.. shanthi kiran -----Original Message----- From: Parag Deshpande [mailto:paragdeshpande@SDKSOFT.COM] Sent: Friday, August 29, 2003 10:13 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: DB Synchronization 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. I was wondering whether this can be resolved faster. Thanks Parag From owner-ospf@PEACH.EASE.LSOFT.COM Fri Aug 29 19:00:02 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 TAA15427 for ; Fri, 29 Aug 2003 19:00:01 -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 <8.00B1882D@cherry.ease.lsoft.com>; Fri, 29 Aug 2003 19:00:00 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 53206597 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 29 Aug 2003 18:59:58 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 29 Aug 2003 18:59:58 -0400 Received: from redback.com (montreal.redback.com [155.53.42.143]) by prattle.redback.com (Postfix) with ESMTP id 05B5986C8C7 for ; Fri, 29 Aug 2003 15:59:58 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.1) Gecko/20020829 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3F4FDAED.7020504@redback.com> Date: Fri, 29 Aug 2003 15:59:57 -0700 Reply-To: Mailing List Sender: Mailing List From: Rikki Nguyen Subject: Re: DB Synchronization To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit 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 >>> >> >