From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 01 03:23:02 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4DGY-0003ce-Nd for ospf-archive@megatron.ietf.org; Wed, 01 Feb 2006 03:23:02 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21284 for ; Wed, 1 Feb 2006 03:21:17 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <6.0001F5F0@wildebeest.ease.lsoft.com>; Wed, 1 Feb 2006 3:22:21 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98209109 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 1 Feb 2006 03:22:11 -0500 Received: from 207.69.195.66 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 1 Feb 2006 03:22:10 -0500 Received: from h-68-164-91-137.snvacaid.dynamic.covad.net ([68.164.91.137] helo=earthlink.net) by pop-canoe.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1F4DFh-0003lP-00 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 01 Feb 2006 03:22:09 -0500 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43E06D08.94415E2C@earthlink.net> Date: Wed, 1 Feb 2006 00:10:48 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: draft-ietf-ospf-ospfv3-update-07.txt : part 2: instance To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Group, Three questions/comments dealing with Multiple instances with one or more in Standby state. Last few are NITs. 1))))) 2.4 Explicit support for multiple instances per link "In OSPF for IPv4 this was supported in a haphazard fashion using the authentication fields in the OSPF for IPv4 header." IMO, this generally was done by having two OSPF processes share the same interface whereby each process generated their own set of adjs, by xmit/recving hello packetts, xmit/recving all the OSPF control packets. To make it as efficient as possible, a "1 to many multiplexor" was sometimes used for recieving, and reverse for transmiting. So, two or more processes were ACTIVE simulteneously on the same interface. To allow this a simple reference count was sometimes used to identify whether the interface was active. So, if we do this or 2.4 Explicit support for multiple instances per link "to have a single link belong to two or more OSPF areas." Requires BOTH processes's to be ACTIVE on the same interface (we are referring to V2 haphazard support). Howevever, I am confused with the two following sections for v3 which seems to contradict this.. 3.9 Multiple interfaces to a single link In OSPF for IPv6, a router may have multiple interfaces to a single link. All interfaces are involved in the reception and transmission of data traffic, but only a single interface sends and receives OSPF control traffic. "only a single interface sends and receives OSPF control traffic." How do both instances have full sets of adjs, LSA exchange, etc? 3.9.1 Standby Interface State In this state, the interface is one of multiple interfaces to a link and this interface is designated Standby and is not sending or receiving control packets. "this interface is designated Standby and is not sending or receiving control packets." How does the Standby interface/process recv/xmit LSAs?? MultipleInterfacesToLink An interfaces on the router has received a hello packet from another interface on the same router. One of the interfaces is designated as the Active Interface, and the other interface is designated as a Standby Interface. The Standby Interface transitions to the Standby state. ------ So, I am reading that one of my instances has the active interface and the others a Standby state. But "only a single interface sends and receives OSPF control traffic." So, how do I sync my LSDB via DBD packets, and refresh if my standby interface from one of my other instances can not send or recieve control packets????? Are you implicitly stating that all processes with all control packets will use the same Active interface???? 2nd question)))) 3.9.1 Standby Interface State If I believed that you need a Standby state, which I am not 100% sure because of the above section, Why transistion to down, when the ActiveDies? When you have the Event: MultipleInterfacesToLink with Standby new State, why don't you stay in this state "AS LONG AS a Standby is available? Simply elect new ActiveInterface as long as a Standby Exists? Why? In the RFC's state machine Standby's go Down, versus being promoted MultipleInterfacesToLink in my suggestion So again when a Interface is in the Standby state, why isn't one of them promoted to MultipleInterfaces ToLink, if the reference count is 2 or more. When a Standby transitions to down, the Reference count should be decremented. If the reference count is 1, then DOWN is acceptable. 3))))) Grammar : should be plural :^) unless we limit 2 interfaces on the same link. MultipleInterfacesToLink An interfaces on the router has received a hello packet from another interface on the same router. One of the interfaces is designated as the Active Interface, and the other interface is designated as a Standby Interface. The Standby Interface transitions to the Standby state. interface is > interfaces are and the other interfaces are designated as a Standby Interface. 4)))) I think Moy's address bounces.. 5) A.4 LSA formats This memo defines eight distinct types of LSAs. >>>> nine listed 1 0x2001 Router-LSA 2 0x2002 Network-LSA 3 0x2003 Inter-Area-Prefix-LSA 4 0x2004 Inter-Area-Router-LSA 5 0x4005 AS-external-LSA 6 0x2006 Group-membership-LSA 7 0x2007 NSSA-LSA 8 0x0008 Link-LSA 9 0x2009 Intra-Area-Prefix-LSA Mitchell Erblich ------------------ From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 01 04:09:50 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Dzq-0002gG-8V for ospf-archive@megatron.ietf.org; Wed, 01 Feb 2006 04:09:50 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24286 for ; Wed, 1 Feb 2006 04:08:08 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <2.0001F5F9@wildebeest.ease.lsoft.com>; Wed, 1 Feb 2006 4:09:13 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98210477 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 1 Feb 2006 04:09:13 -0500 Received: from 209.119.0.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 1 Feb 2006 03:59:13 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by LIME.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00093B3E@LIME.ease.lsoft.com>; Wed, 1 Feb 2006 3:58:12 -0500 Message-ID: Date: Wed, 1 Feb 2006 03:58:54 -0500 Reply-To: Mailing List Sender: Mailing List From: Nitin Kakkar Subject: Re: ospfv3 mib / traps To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Sorry for the delayed reply on this thread. Ideally we should have a single ospfv3 mib which should include traps. I support merging trap's to other mib. Regards Nitin From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 01 15:29:00 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Oay-00063s-Nr for ospf-archive@megatron.ietf.org; Wed, 01 Feb 2006 15:29:00 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02979 for ; Wed, 1 Feb 2006 15:27:05 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <9.0001F7B6@wildebeest.ease.lsoft.com>; Wed, 1 Feb 2006 15:28:05 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98267814 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 1 Feb 2006 15:28:05 -0500 Received: from 207.69.195.69 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 1 Feb 2006 15:28:05 -0500 Received: from h-68-164-152-195.snvacaid.dynamic.covad.net ([68.164.152.195] helo=earthlink.net) by pop-savannah.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1F4OaC-00074y-00 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 01 Feb 2006 15:28:04 -0500 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <43DFFB6D.66131696@earthlink.net> <43DFFD2A.6D8E8428@earthlink.net> <43E0136E.6090706@cisco.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43E11D99.55CBD4DE@earthlink.net> Date: Wed, 1 Feb 2006 12:44:09 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: draft-ietf-ospf-ospfv3-update-07.txt : Constants To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Acee, et al, Two additional notes on this thread. 1) The IETF BFD draft is a sledgehammer to OSPF for subsecond liveness. Implementations may consume months of development and excess of a 1000 lines of code. Yes, the WG is appying it to every protocol. Fast hellos have been around for years and require less than a afternoons worth of work, with maybe 50 lines of code. It also achieves 90+% of what is needed in OSPF and is used by the majors. However, their is no mention of its existance in any IETF doc that I know of.. So, when the v3 spec is re-drafted, I decided to try to get the hello protocol's second granularity mentioned configurables at least updated in a arch dependent manner. 2) There are many documents dealing with scalability, faster convergence, etc that alludes to TUNING these FIXED/architectural constants. Any enterprise level OSPF implementation is not going to leave these unchanged and documenting that they are no longer constant in many implementations IMO would be prudent. Mitchell Erblich Acee Lindem wrote: > > Hi Mitchell, > > Erblichs wrote: > > >Group, > > > > Actually, I want to make one minor change to the > > 2nd suggestion. Hands faster than the mind :^) > > > > Mitchell Erblich > > ------------------ > > > >Erblichs wrote: > > > > > >>Group, > >> > >> 1) Appendix B. Architectural Constants > >> > >> I know of very few original "Architectural Constants" > >> that were originally specified in the OSPFv2 spec, > >> that currently remain as their specified default. > >> > >> IMO, this spec could acknowledge that fact by > >> stating: > >> > >> Although these items are identified as Architectural > >> Constants; scalability, reliability, convergence > >> considerations, etc. have dictated some flexibility in > >> their values. Thus, when not explicitly modified, > >> these original values SHOULD be considered defaults. > >> > >> > I don't agree with this suggestion. First of all, I'm not going to > allude to what some > implementions have done without an IETF document precisely describing > it. Second, in the > instances where these value may be modified by an implementation, an > IETF document > isn't necessary for interoperability (give or take a retransmission now > and then :^). > > >> 2) Appendix C. Configurable Constants > >> > >> "Similarly, all routers attached to a network must > >> agree on that network's HelloInterval and RouterDeadInterval." > >> > >> In most enterprise and other implementations, the default > >> hello protocol specified in the V2 doc has been supplimented > >> with "fast hello" implementations for subsecond aliveness. > >> > >> The standard "fast hello" Hello Interval is set to 0 on > >> transmit and IGNORED on reception, thus I suggest the > >> following change. > >> > >> Similarly, all routers attached to a network must > >> agree on that network's HelloInterval and RouterDeadInterval > >> if the original hello protocol is followed, but > >> > >> > > > > the HelloInterval > > > > is no > > > > > >> longer a requirement for neighbor acceptance in many > >> implementations. > >> > >> > This isn't true. However, it doesn't matter since fast hellos are not > described in an IETF > document. And, before anyone looking for their 15 minutes of fame > submits a draft, > note the BFD is the IETF agreed upon mechanism for sub-second liveliness > detection (Dave > will probably correct me here). > > Thanks, > Acee > > >> Mitchell Erblich > >> > >> > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 01 19:00:46 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Ru2-00076O-LX for ospf-archive@megatron.ietf.org; Wed, 01 Feb 2006 19:00:46 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29796 for ; Wed, 1 Feb 2006 18:59:03 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <0.0001F820@wildebeest.ease.lsoft.com>; Wed, 1 Feb 2006 19:00:08 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98280219 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 1 Feb 2006 19:00:08 -0500 Received: from 132.151.6.50 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 1 Feb 2006 18:50:08 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F4Rjd-0006CY-Ud; Wed, 01 Feb 2006 18:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-ID: Date: Wed, 1 Feb 2006 18:50:01 -0500 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-mt-06.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: --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 : Multi-Topology (MT) Routing in OSPF Author(s) : P. Psenak, et al. Filename : draft-ietf-ospf-mt-06.txt Pages : 23 Date : 2006-2-1 This draft describes an extension to OSPF in order to define independent IP topologies called Multi-Topologies (MTs). The MT extension can be used for computing different paths for unicast traffic, multicast traffic, different classes of service based on flexible criteria, or an in-band network management topology. [M-ISIS] describes a similar mechanism for ISIS. An optional extension to exclude selected links from the default topology is also described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-mt-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-mt-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-mt-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: <2006-2-1163134.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-mt-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-mt-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-1163134.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Feb 02 11:57:38 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4hm6-0006pA-23 for ospf-archive@megatron.ietf.org; Thu, 02 Feb 2006 11:57:38 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20298 for ; Thu, 2 Feb 2006 11:55:59 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <12.0001F9A2@wildebeest.ease.lsoft.com>; Thu, 2 Feb 2006 11:57:03 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98335990 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 2 Feb 2006 11:57:03 -0500 Received: from 171.71.176.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 2 Feb 2006 11:57:03 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 02 Feb 2006 08:57:03 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k12Gv2KT016632 for ; Thu, 2 Feb 2006 08:57:02 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Feb 2006 11:57:01 -0500 Received: from [10.82.216.81] ([10.82.216.81]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 2 Feb 2006 11:57:01 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <43DFFB6D.66131696@earthlink.net> <43DFFD2A.6D8E8428@earthlink.net> <43E0136E.6090706@cisco.com> <43E11D99.55CBD4DE@earthlink.net> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Feb 2006 16:57:01.0728 (UTC) FILETIME=[AFEA0200:01C62819] Message-ID: <43E239DD.5040608@cisco.com> Date: Thu, 2 Feb 2006 11:57:01 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-ietf-ospf-ospfv3-update-07.txt : Constants To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43E11D99.55CBD4DE@earthlink.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Hi Mitchell, Erblichs wrote: >Acee, et al, > > Two additional notes on this thread. > > 1) The IETF BFD draft is a sledgehammer to OSPF > for subsecond liveness. Implementations may > consume months of development and excess of > a 1000 lines of code. Yes, the WG is appying > it to every protocol. > > Fast hellos have been around for years and > require less than a afternoons worth of work, > with maybe 50 lines of code. It also achieves > 90+% of what is needed in OSPF and is used by > the majors. > The majors?? IMHO, fast hellos may be good for a trade show demo but in practice they're too fragile (especially the 50 LOC variety).. Anyway, that isn't the debate here. Fast hellos don't belong in the base specification - the details of it haven't been documented or accepted by the OSPF WG. > However, their is no mention of > its existance in any IETF doc that I know of.. > > So, when the v3 spec is re-drafted, I decided to > try to get the hello protocol's second > granularity mentioned configurables > at least updated in a arch dependent manner. > > 2) There are many documents dealing with scalability, > faster convergence, etc that alludes to TUNING these > FIXED/architectural constants. > > Which documents - Same answer as above. Thanks, Acee > Any enterprise level OSPF implementation is not going > to leave these unchanged and documenting that they are > no longer constant in many implementations IMO would > be prudent. > > Mitchell Erblich > > > > > > > > >Acee Lindem wrote: > > >>Hi Mitchell, >> >>Erblichs wrote: >> >> >> >>>Group, >>> >>> Actually, I want to make one minor change to the >>> 2nd suggestion. Hands faster than the mind :^) >>> >>> Mitchell Erblich >>> ------------------ >>> >>>Erblichs wrote: >>> >>> >>> >>> >>>>Group, >>>> >>>> 1) Appendix B. Architectural Constants >>>> >>>> I know of very few original "Architectural Constants" >>>> that were originally specified in the OSPFv2 spec, >>>> that currently remain as their specified default. >>>> >>>> IMO, this spec could acknowledge that fact by >>>> stating: >>>> >>>> Although these items are identified as Architectural >>>> Constants; scalability, reliability, convergence >>>> considerations, etc. have dictated some flexibility in >>>> their values. Thus, when not explicitly modified, >>>> these original values SHOULD be considered defaults. >>>> >>>> >>>> >>>> >>I don't agree with this suggestion. First of all, I'm not going to >>allude to what some >>implementions have done without an IETF document precisely describing >>it. Second, in the >>instances where these value may be modified by an implementation, an >>IETF document >>isn't necessary for interoperability (give or take a retransmission now >>and then :^). >> >> >> >>>> 2) Appendix C. Configurable Constants >>>> >>>> "Similarly, all routers attached to a network must >>>> agree on that network's HelloInterval and RouterDeadInterval." >>>> >>>> In most enterprise and other implementations, the default >>>> hello protocol specified in the V2 doc has been supplimented >>>> with "fast hello" implementations for subsecond aliveness. >>>> >>>> The standard "fast hello" Hello Interval is set to 0 on >>>> transmit and IGNORED on reception, thus I suggest the >>>> following change. >>>> >>>> Similarly, all routers attached to a network must >>>> agree on that network's HelloInterval and RouterDeadInterval >>>> if the original hello protocol is followed, but >>>> >>>> >>>> >>>> >>> the HelloInterval >>> >>> is no >>> >>> >>> >>> >>>> longer a requirement for neighbor acceptance in many >>>> implementations. >>>> >>>> >>>> >>>> >>This isn't true. However, it doesn't matter since fast hellos are not >>described in an IETF >>document. And, before anyone looking for their 15 minutes of fame >>submits a draft, >>note the BFD is the IETF agreed upon mechanism for sub-second liveliness >>detection (Dave >>will probably correct me here). >> >>Thanks, >>Acee >> >> >> >>>> Mitchell Erblich >>>> >>>> >>>> >>>> >>> >>> >>> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 03 03:45:57 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4wZp-0007Fj-Bp for ospf-archive@megatron.ietf.org; Fri, 03 Feb 2006 03:45:57 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05991 for ; Fri, 3 Feb 2006 03:44:19 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <6.0001FC37@wildebeest.ease.lsoft.com>; Fri, 3 Feb 2006 3:45:17 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98395467 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 3 Feb 2006 03:45:17 -0500 Received: from 207.69.195.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 3 Feb 2006 03:45:17 -0500 Received: from h-68-164-152-195.snvacaid.dynamic.covad.net ([68.164.152.195] helo=earthlink.net) by pop-borzoi.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1F4wZB-0004Sb-00 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 03 Feb 2006 03:45:17 -0500 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <43DFFB6D.66131696@earthlink.net> <43DFFD2A.6D8E8428@earthlink.net> <43E0136E.6090706@cisco.com> <43E11D99.55CBD4DE@earthlink.net> <43E239DD.5040608@cisco.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43E31159.F8635726@earthlink.net> Date: Fri, 3 Feb 2006 00:16:25 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: draft-ietf-ospf-ospfv3-update-07.txt : Constants To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Acee, > >>>> Similarly, all routers attached to a network must > >>>> agree on that network's HelloInterval and RouterDeadInterval > >>>> if the original hello protocol is followed, but > >>>> > >>>> > >>>> > >>>> > >>> the HelloInterval > >>> > >>> is no > >>> > >>> > >>> > >>> > >>>> longer a requirement for neighbor acceptance in many > >>>> implementations. This original statement does not mention "fast hellos". It only tries to limit the mandatory original meaning of HelloInterval. It could also be simplified to cut it before the ", but....". Group, the fast hello feature was only being used to enforce the meaning of why HelloInterval should be dropped. Another one could be the BFD draft. As to fragility, I would hope that is an implementation issue and not a arch issue. :^) Mitchell Erblich ----------------- Acee Lindem wrote: > > Hi Mitchell, > > Erblichs wrote: > > >Acee, et al, > > > > Two additional notes on this thread. > > > > 1) The IETF BFD draft is a sledgehammer to OSPF > > for subsecond liveness. Implementations may > > consume months of development and excess of > > a 1000 lines of code. Yes, the WG is appying > > it to every protocol. > > > > Fast hellos have been around for years and > > require less than a afternoons worth of work, > > with maybe 50 lines of code. It also achieves > > 90+% of what is needed in OSPF and is used by > > the majors. > > > The majors?? IMHO, fast hellos may be good for a trade show demo but in > practice they're > too fragile (especially the 50 LOC variety).. Anyway, that isn't the > debate here. Fast > hellos don't belong in the base specification - the details of it > haven't been documented > or accepted by the OSPF WG. > I am not really suggesting > > However, their is no mention of > > its existance in any IETF doc that I know of.. > > > > So, when the v3 spec is re-drafted, I decided to > > try to get the hello protocol's second > > granularity mentioned configurables > > at least updated in a arch dependent manner. > > > > 2) There are many documents dealing with scalability, > > faster convergence, etc that alludes to TUNING these > > FIXED/architectural constants. > > > > > Which documents - Same answer as above. > > Thanks, > Acee > > > Any enterprise level OSPF implementation is not going > > to leave these unchanged and documenting that they are > > no longer constant in many implementations IMO would > > be prudent. > > > > Mitchell Erblich > > > > > > > > > > > > > > > > > >Acee Lindem wrote: > > > > > >>Hi Mitchell, > >> > >>Erblichs wrote: > >> > >> > >> > >>>Group, > >>> > >>> Actually, I want to make one minor change to the > >>> 2nd suggestion. Hands faster than the mind :^) > >>> > >>> Mitchell Erblich > >>> ------------------ > >>> > >>>Erblichs wrote: > >>> > >>> > >>> > >>> > >>>>Group, > >>>> > >>>> 1) Appendix B. Architectural Constants > >>>> > >>>> I know of very few original "Architectural Constants" > >>>> that were originally specified in the OSPFv2 spec, > >>>> that currently remain as their specified default. > >>>> > >>>> IMO, this spec could acknowledge that fact by > >>>> stating: > >>>> > >>>> Although these items are identified as Architectural > >>>> Constants; scalability, reliability, convergence > >>>> considerations, etc. have dictated some flexibility in > >>>> their values. Thus, when not explicitly modified, > >>>> these original values SHOULD be considered defaults. > >>>> > >>>> > >>>> > >>>> > >>I don't agree with this suggestion. First of all, I'm not going to > >>allude to what some > >>implementions have done without an IETF document precisely describing > >>it. Second, in the > >>instances where these value may be modified by an implementation, an > >>IETF document > >>isn't necessary for interoperability (give or take a retransmission now > >>and then :^). > >> > >> > >> > >>>> 2) Appendix C. Configurable Constants > >>>> > >>>> "Similarly, all routers attached to a network must > >>>> agree on that network's HelloInterval and RouterDeadInterval." > >>>> > >>>> In most enterprise and other implementations, the default > >>>> hello protocol specified in the V2 doc has been supplimented > >>>> with "fast hello" implementations for subsecond aliveness. > >>>> > >>>> The standard "fast hello" Hello Interval is set to 0 on > >>>> transmit and IGNORED on reception, thus I suggest the > >>>> following change. > >>>> > >>>> Similarly, all routers attached to a network must > >>>> agree on that network's HelloInterval and RouterDeadInterval > >>>> if the original hello protocol is followed, but > >>>> > >>>> > >>>> > >>>> > >>> the HelloInterval > >>> > >>> is no > >>> > >>> > >>> > >>> > >>>> longer a requirement for neighbor acceptance in many > >>>> implementations. > >>>> > >>>> > >>>> > >>>> > >>This isn't true. However, it doesn't matter since fast hellos are not > >>described in an IETF > >>document. And, before anyone looking for their 15 minutes of fame > >>submits a draft, > >>note the BFD is the IETF agreed upon mechanism for sub-second liveliness > >>detection (Dave > >>will probably correct me here). > >> > >>Thanks, > >>Acee > >> > >> > >> > >>>> Mitchell Erblich > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 03 05:36:27 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4yIl-0005Sv-Md for ospf-archive@megatron.ietf.org; Fri, 03 Feb 2006 05:36:27 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14084 for ; Fri, 3 Feb 2006 05:34:41 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <10.0001FC42@wildebeest.ease.lsoft.com>; Fri, 3 Feb 2006 5:35:48 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98400301 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 3 Feb 2006 05:35:48 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 3 Feb 2006 05:35:48 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 03 Feb 2006 02:35:48 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,83,1139212800"; d="scan'208"; a="21118810:sNHT25973168" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k13AZj6H008695 for ; Fri, 3 Feb 2006 05:35:46 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Feb 2006 05:35:45 -0500 Received: from [10.82.216.81] ([10.82.216.81]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Feb 2006 05:35:44 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <43DFFB6D.66131696@earthlink.net> <43DFFD2A.6D8E8428@earthlink.net> <43E0136E.6090706@cisco.com> <43E11D99.55CBD4DE@earthlink.net> <43E239DD.5040608@cisco.com> <43E31159.F8635726@earthlink.net> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Feb 2006 10:35:44.0404 (UTC) FILETIME=[96612540:01C628AD] Message-ID: <43E33200.2050109@cisco.com> Date: Fri, 3 Feb 2006 05:35:44 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-ietf-ospf-ospfv3-update-07.txt : Constants To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43E31159.F8635726@earthlink.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Erblichs wrote: >Acee, > > > >>>> Similarly, all routers attached to a network must > > >>>>>> agree on that network's HelloInterval and RouterDeadInterval >>>>>> if the original hello protocol is followed, but >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> the HelloInterval >>>>> >>>>> is no >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> longer a requirement for neighbor acceptance in many >>>>>> implementations. >>>>>> >>>>>> > > > This original statement does not mention "fast hellos". > It only tries to limit the mandatory original meaning of > HelloInterval. > > As Dave noted, this doesn't change for fast hellos. HelloInterval is advertised as 0 and DeadInterval is advertised as 1. Thanks, Acee > It could also be simplified to cut it before the ", but....". > > Group, the fast hello feature was only being used to enforce > the meaning of why HelloInterval should be dropped. Another > one could be the BFD draft. > > As to fragility, I would hope that is an implementation > issue and not a arch issue. :^) > > Mitchell Erblich > ----------------- >Acee Lindem wrote: > > >>Hi Mitchell, >> >>Erblichs wrote: >> >> >> >>>Acee, et al, >>> >>> Two additional notes on this thread. >>> >>> 1) The IETF BFD draft is a sledgehammer to OSPF >>> for subsecond liveness. Implementations may >>> consume months of development and excess of >>> a 1000 lines of code. Yes, the WG is appying >>> it to every protocol. >>> >>> Fast hellos have been around for years and >>> require less than a afternoons worth of work, >>> with maybe 50 lines of code. It also achieves >>> 90+% of what is needed in OSPF and is used by >>> the majors. >>> >>> >>> >>The majors?? IMHO, fast hellos may be good for a trade show demo but in >>practice they're >>too fragile (especially the 50 LOC variety).. Anyway, that isn't the >>debate here. Fast >>hellos don't belong in the base specification - the details of it >>haven't been documented >>or accepted by the OSPF WG. >> >> >> > I am not really suggesting > > >>>However, their is no mention of >>> its existance in any IETF doc that I know of.. >>> >>> So, when the v3 spec is re-drafted, I decided to >>> try to get the hello protocol's second >>> granularity mentioned configurables >>> at least updated in a arch dependent manner. >>> >>> 2) There are many documents dealing with scalability, >>> faster convergence, etc that alludes to TUNING these >>> FIXED/architectural constants. >>> >>> >>> >>> >>Which documents - Same answer as above. >> >>Thanks, >>Acee >> >> >> >>> Any enterprise level OSPF implementation is not going >>> to leave these unchanged and documenting that they are >>> no longer constant in many implementations IMO would >>> be prudent. >>> >>> Mitchell Erblich >>> >>> >>> >>> >>> >>> >>> >>> >>>Acee Lindem wrote: >>> >>> >>> >>> >>>>Hi Mitchell, >>>> >>>>Erblichs wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Group, >>>>> >>>>> Actually, I want to make one minor change to the >>>>> 2nd suggestion. Hands faster than the mind :^) >>>>> >>>>> Mitchell Erblich >>>>> ------------------ >>>>> >>>>>Erblichs wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Group, >>>>>> >>>>>> 1) Appendix B. Architectural Constants >>>>>> >>>>>> I know of very few original "Architectural Constants" >>>>>> that were originally specified in the OSPFv2 spec, >>>>>> that currently remain as their specified default. >>>>>> >>>>>> IMO, this spec could acknowledge that fact by >>>>>> stating: >>>>>> >>>>>> Although these items are identified as Architectural >>>>>> Constants; scalability, reliability, convergence >>>>>> considerations, etc. have dictated some flexibility in >>>>>> their values. Thus, when not explicitly modified, >>>>>> these original values SHOULD be considered defaults. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>I don't agree with this suggestion. First of all, I'm not going to >>>>allude to what some >>>>implementions have done without an IETF document precisely describing >>>>it. Second, in the >>>>instances where these value may be modified by an implementation, an >>>>IETF document >>>>isn't necessary for interoperability (give or take a retransmission now >>>>and then :^). >>>> >>>> >>>> >>>> >>>> >>>>>> 2) Appendix C. Configurable Constants >>>>>> >>>>>> "Similarly, all routers attached to a network must >>>>>> agree on that network's HelloInterval and RouterDeadInterval." >>>>>> >>>>>> In most enterprise and other implementations, the default >>>>>> hello protocol specified in the V2 doc has been supplimented >>>>>> with "fast hello" implementations for subsecond aliveness. >>>>>> >>>>>> The standard "fast hello" Hello Interval is set to 0 on >>>>>> transmit and IGNORED on reception, thus I suggest the >>>>>> following change. >>>>>> >>>>>> Similarly, all routers attached to a network must >>>>>> agree on that network's HelloInterval and RouterDeadInterval >>>>>> if the original hello protocol is followed, but >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> the HelloInterval >>>>> >>>>> is no >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> longer a requirement for neighbor acceptance in many >>>>>> implementations. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>This isn't true. However, it doesn't matter since fast hellos are not >>>>described in an IETF >>>>document. And, before anyone looking for their 15 minutes of fame >>>>submits a draft, >>>>note the BFD is the IETF agreed upon mechanism for sub-second liveliness >>>>detection (Dave >>>>will probably correct me here). >>>> >>>>Thanks, >>>>Acee >>>> >>>> >>>> >>>> >>>> >>>>>> Mitchell Erblich >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>> >>> >>> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 03 15:08:35 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F57ER-0005dJ-Cp for ospf-archive@megatron.ietf.org; Fri, 03 Feb 2006 15:08:35 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05847 for ; Fri, 3 Feb 2006 15:06:49 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <13.0001FDF5@wildebeest.ease.lsoft.com>; Fri, 3 Feb 2006 15:07:55 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98446622 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 3 Feb 2006 15:07:55 -0500 Received: from 171.68.10.86 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 3 Feb 2006 15:07:54 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 03 Feb 2006 12:07:54 -0800 X-IronPort-AV: i="4.02,85,1139212800"; d="scan'208"; a="1773263779:sNHT31331372" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k13K7rQJ012465 for ; Fri, 3 Feb 2006 12:07:53 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Feb 2006 15:07:52 -0500 Received: from [10.82.216.81] ([10.82.216.81]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Feb 2006 15:07:52 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) 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 X-OriginalArrivalTime: 03 Feb 2006 20:07:52.0359 (UTC) FILETIME=[836F6370:01C628FD] Message-ID: <43E3B817.3070908@cisco.com> Date: Fri, 3 Feb 2006 15:07:51 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: I-D ACTION:draft-ietf-ospf-mt-06.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit This version only includes a single change from the 05 version. Since there is currently no checking of options inOSPF Database Description packets, we don't want to add it just for the new MT option. Thanks to David Kushi for pointing this out. Thanks, Acee Internet-Drafts@IETF.ORG wrote: >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 : Multi-Topology (MT) Routing in OSPF > Author(s) : P. Psenak, et al. > Filename : draft-ietf-ospf-mt-06.txt > Pages : 23 > Date : 2006-2-1 > >This draft describes an extension to OSPF in order to define > independent IP topologies called Multi-Topologies (MTs). The MT > extension can be used for computing different paths for unicast > traffic, multicast traffic, different classes of service based on > flexible criteria, or an in-band network management topology. > > [M-ISIS] describes a similar mechanism for ISIS. > > An optional extension to exclude selected links from the default > topology is also described. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ospf-mt-06.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >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-mt-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-mt-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 Fri Feb 03 22:04:35 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5Dj0-0000kw-FC for ospf-archive@megatron.ietf.org; Fri, 03 Feb 2006 22:04:35 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25566 for ; Fri, 3 Feb 2006 22:02:56 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <8.000200D9@wildebeest.ease.lsoft.com>; Fri, 3 Feb 2006 22:04:03 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98467600 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 3 Feb 2006 22:04:03 -0500 Received: from 207.69.195.66 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 3 Feb 2006 22:04:03 -0500 Received: from h-68-164-152-195.snvacaid.dynamic.covad.net ([68.164.152.195] helo=earthlink.net) by pop-canoe.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1F5DiU-0006f4-00 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 03 Feb 2006 22:04:02 -0500 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43E41C5D.8505F3E0@earthlink.net> Date: Fri, 3 Feb 2006 19:15:41 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: DC RFC 1793: Nbr changing DC bit To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Group, 1) If a P2P nbr enables the DC bit, after full adj, SHOULD hello suppression occur, if that were the only item preventing hello suppression? IMO, This is a grey area because the nbr state machine on the nbr transition to full state is really the only place where we need to check the value of what the nbr specified for the hello option. Versus a need to check each hello for the setting of this bit, since in this 2nd case we make the assumption that the value is volitile. Mitchell Erblich From owner-ospf@PEACH.EASE.LSOFT.COM Sat Feb 04 00:42:46 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5GC2-0004p6-7e for ospf-archive@megatron.ietf.org; Sat, 04 Feb 2006 00:42:46 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07279 for ; Sat, 4 Feb 2006 00:40:54 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <5.0002012C@wildebeest.ease.lsoft.com>; Sat, 4 Feb 2006 0:42:02 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98477137 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 4 Feb 2006 00:42:02 -0500 Received: from 209.119.0.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 4 Feb 2006 00:42:02 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by LIME.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00097F38@LIME.ease.lsoft.com>; Sat, 4 Feb 2006 0:41:00 -0500 Message-ID: Date: Sat, 4 Feb 2006 00:42:01 -0500 Reply-To: Mailing List Sender: Mailing List From: Ramesh Kandula Subject: Originating LSAs during OSPF graceful restart To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Hi All, Should the restarting routing summarize it's own lsas (self-originated) during adjaceny establishment? This can happen in the following scenario. Suppose there are 3 OSPF routers on a broadcast network and the DR restarts. When it establishes adjacency with the first neighbor, it will get its own lsas from it. Now while forming adjaceny with the second neighbor, should it summarize it's own lsas? If yes, then the neighbor will request for them and the restarting router will send these lsas. So does the RFC 3623 mean that the restarting router should not originate "newer" instances of lsas of type 1,5 or 7? Thanks in advance ramesh From owner-ospf@PEACH.EASE.LSOFT.COM Sat Feb 04 07:35:09 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5MdA-0003hJ-Uz for ospf-archive@megatron.ietf.org; Sat, 04 Feb 2006 07:35:09 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02827 for ; Sat, 4 Feb 2006 07:33:26 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <1.0002016C@wildebeest.ease.lsoft.com>; Sat, 4 Feb 2006 7:34:18 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98495095 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 4 Feb 2006 07:34:18 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 4 Feb 2006 07:34:18 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 04 Feb 2006 07:34:18 -0500 X-IronPort-AV: i="4.02,88,1139202000"; d="scan'208"; a="81703487:sNHT30245012" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k14CYF6H008859 for ; Sat, 4 Feb 2006 07:34:16 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 4 Feb 2006 07:34:15 -0500 Received: from [10.82.216.81] ([10.82.216.81]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 4 Feb 2006 07:34:15 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) 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 X-OriginalArrivalTime: 04 Feb 2006 12:34:15.0195 (UTC) FILETIME=[4F277EB0:01C62987] Message-ID: <43E49F46.8090108@cisco.com> Date: Sat, 4 Feb 2006 07:34:14 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Originating LSAs during OSPF graceful restart To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Hi Ramesh, Ramesh Kandula wrote: >Hi All, > >Should the restarting routing summarize it's own lsas (self-originated) >during adjaceny establishment? This can happen in the following scenario. > >Suppose there are 3 OSPF routers on a broadcast network and the DR >restarts. When it establishes adjacency with the first neighbor, it will >get its own lsas from it. Now while forming adjaceny with the second >neighbor, should it summarize it's own lsas? > > No. >If yes, then the neighbor will request for them and the restarting router >will send these lsas. So does the RFC 3623 mean that the restarting router >should not originate "newer" instances of lsas of type 1,5 or 7? > > If the neighbor doesn't already have them (and normally it will), the restarting router will send its pre-restart LSAs. Don't confuse origination with sending an LSA during the database exchange process. Hope this helps, Acee >Thanks in advance >ramesh > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 06 15:33:22 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6D34-00032E-H0 for ospf-archive@megatron.ietf.org; Mon, 06 Feb 2006 15:33:22 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20662 for ; Mon, 6 Feb 2006 15:31:40 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <6.00020858@wildebeest.ease.lsoft.com>; Mon, 6 Feb 2006 15:32:46 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98705969 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 6 Feb 2006 15:32:46 -0500 Received: from 66.91.145.219 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 6 Feb 2006 15:32:45 -0500 Received: by apollo.adtech-inc.com with Internet Mail Service (5.5.2653.19) id <1HT4FLLP>; Mon, 6 Feb 2006 10:33:21 -1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <3D7BA5153B91EB4EBCF4CEDFE6263EA20513835A@apollo.adtech-inc.com> Date: Mon, 6 Feb 2006 10:33:20 -1000 Reply-To: Mailing List Sender: Mailing List From: "Kandula, Ramesh" Subject: Re: Originating LSAs during OSPF graceful restart To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Hi Acee, Thanks for the reply. Are you saying that the restarting router should not summarize self-originated lsas (I mean pre-restart self originated lsas) during database exchange with a neighbor? If so, why is this required? I don't find any statement in RFC3623 which implies this? Also, you said if a neighbor doesn't have a pre-restart lsa, the restarting router will send it. If there was an adjacency before restart with this neighbor, isn't the restarting router supposed to quit restart mode? thanks ramesh -----Original Message----- From: Acee Lindem [mailto:acee@CISCO.COM] Sent: Saturday, February 04, 2006 2:34 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Originating LSAs during OSPF graceful restart Hi Ramesh, Ramesh Kandula wrote: >Hi All, > >Should the restarting routing summarize it's own lsas (self-originated) >during adjaceny establishment? This can happen in the following scenario. > >Suppose there are 3 OSPF routers on a broadcast network and the DR >restarts. When it establishes adjacency with the first neighbor, it will >get its own lsas from it. Now while forming adjaceny with the second >neighbor, should it summarize it's own lsas? > > No. >If yes, then the neighbor will request for them and the restarting router >will send these lsas. So does the RFC 3623 mean that the restarting router >should not originate "newer" instances of lsas of type 1,5 or 7? > > If the neighbor doesn't already have them (and normally it will), the restarting router will send its pre-restart LSAs. Don't confuse origination with sending an LSA during the database exchange process. Hope this helps, Acee >Thanks in advance >ramesh > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 06 15:47:15 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6DGV-0006rZ-Or for ospf-archive@megatron.ietf.org; Mon, 06 Feb 2006 15:47:15 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22142 for ; Mon, 6 Feb 2006 15:45:33 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <7.00020846@wildebeest.ease.lsoft.com>; Mon, 6 Feb 2006 15:46:42 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98706561 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 6 Feb 2006 15:46:42 -0500 Received: from 171.68.10.86 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 6 Feb 2006 15:46:42 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 06 Feb 2006 12:46:41 -0800 X-IronPort-AV: i="4.02,92,1139212800"; d="scan'208"; a="1773864163:sNHT31177788" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k16Kkdjv021856 for ; Mon, 6 Feb 2006 12:46:40 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Feb 2006 15:46:39 -0500 Received: from [10.82.216.81] ([10.82.216.81]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Feb 2006 15:46:39 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3D7BA5153B91EB4EBCF4CEDFE6263EA20513835A@apollo.adtech-inc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Feb 2006 20:46:39.0439 (UTC) FILETIME=[6DB8DDF0:01C62B5E] Message-ID: <43E7B5AE.6060403@cisco.com> Date: Mon, 6 Feb 2006 15:46:38 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Originating LSAs during OSPF graceful restart To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3D7BA5153B91EB4EBCF4CEDFE6263EA20513835A@apollo.adtech-inc.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Hi Ramesh, Kandula, Ramesh wrote: >Hi Acee, > >Thanks for the reply. > >Are you saying that the restarting router should not summarize >self-originated lsas (I mean pre-restart self originated lsas) during >database exchange with a neighbor? > No. I'm saying the restarting router will not originate new LSAs until exiting graceful restart. >If so, why is this required? I don't find >any statement in RFC3623 which implies this? > >Also, you said if a neighbor doesn't have a pre-restart lsa, the restarting >router will send it. If there was an adjacency before restart with this >neighbor, isn't the restarting router supposed to quit restart mode? > > No. In fact, a router won't act as a helper router unless it previously had an adjacency with the restarting router. Thanks, Acee >thanks >ramesh > >-----Original Message----- >From: Acee Lindem [mailto:acee@CISCO.COM] >Sent: Saturday, February 04, 2006 2:34 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: Originating LSAs during OSPF graceful restart > > >Hi Ramesh, > >Ramesh Kandula wrote: > > > >>Hi All, >> >>Should the restarting routing summarize it's own lsas (self-originated) >>during adjaceny establishment? This can happen in the following scenario. >> >>Suppose there are 3 OSPF routers on a broadcast network and the DR >>restarts. When it establishes adjacency with the first neighbor, it will >>get its own lsas from it. Now while forming adjaceny with the second >>neighbor, should it summarize it's own lsas? >> >> >> >> >No. > > > >>If yes, then the neighbor will request for them and the restarting router >>will send these lsas. So does the RFC 3623 mean that the restarting router >>should not originate "newer" instances of lsas of type 1,5 or 7? >> >> >> >> >If the neighbor doesn't already have them (and normally it will), the >restarting router will send its >pre-restart LSAs. Don't confuse origination with sending an LSA during >the database exchange >process. > >Hope this helps, >Acee > > > >>Thanks in advance >>ramesh >> >> >> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 06 16:09:18 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Dbq-0005OJ-CW for ospf-archive@megatron.ietf.org; Mon, 06 Feb 2006 16:09:18 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26929 for ; Mon, 6 Feb 2006 16:07:28 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <7.0002085D@wildebeest.ease.lsoft.com>; Mon, 6 Feb 2006 16:08:36 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98707683 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 6 Feb 2006 16:08:36 -0500 Received: from 66.91.145.219 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 6 Feb 2006 16:08:35 -0500 Received: by apollo.adtech-inc.com with Internet Mail Service (5.5.2653.19) id <1HT4FLMF>; Mon, 6 Feb 2006 11:09:11 -1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <3D7BA5153B91EB4EBCF4CEDFE6263EA20513835C@apollo.adtech-inc.com> Date: Mon, 6 Feb 2006 11:09:11 -1000 Reply-To: Mailing List Sender: Mailing List From: "Kandula, Ramesh" Subject: Re: Originating LSAs during OSPF graceful restart To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Hi Acee I agree with what you said, but it didn't help me completely so let me put my question simple and straight-forward. 1. What is the restarting router supposed to summarize during database exchange while forming an adjacency with a neighbor (helper or otherwise)? 2. Is the behavior here any different when compared to normal OSPF bring up? Thanks again Ramesh -----Original Message----- From: Acee Lindem [mailto:acee@CISCO.COM] Sent: Monday, February 06, 2006 10:47 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Originating LSAs during OSPF graceful restart Hi Ramesh, Kandula, Ramesh wrote: >Hi Acee, > >Thanks for the reply. > >Are you saying that the restarting router should not summarize >self-originated lsas (I mean pre-restart self originated lsas) during >database exchange with a neighbor? > No. I'm saying the restarting router will not originate new LSAs until exiting graceful restart. >If so, why is this required? I don't find >any statement in RFC3623 which implies this? > >Also, you said if a neighbor doesn't have a pre-restart lsa, the restarting >router will send it. If there was an adjacency before restart with this >neighbor, isn't the restarting router supposed to quit restart mode? > > No. In fact, a router won't act as a helper router unless it previously had an adjacency with the restarting router. Thanks, Acee >thanks >ramesh > >-----Original Message----- >From: Acee Lindem [mailto:acee@CISCO.COM] >Sent: Saturday, February 04, 2006 2:34 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: Originating LSAs during OSPF graceful restart > > >Hi Ramesh, > >Ramesh Kandula wrote: > > > >>Hi All, >> >>Should the restarting routing summarize it's own lsas (self-originated) >>during adjaceny establishment? This can happen in the following scenario. >> >>Suppose there are 3 OSPF routers on a broadcast network and the DR >>restarts. When it establishes adjacency with the first neighbor, it will >>get its own lsas from it. Now while forming adjaceny with the second >>neighbor, should it summarize it's own lsas? >> >> >> >> >No. > > > >>If yes, then the neighbor will request for them and the restarting router >>will send these lsas. So does the RFC 3623 mean that the restarting router >>should not originate "newer" instances of lsas of type 1,5 or 7? >> >> >> >> >If the neighbor doesn't already have them (and normally it will), the >restarting router will send its >pre-restart LSAs. Don't confuse origination with sending an LSA during >the database exchange >process. > >Hope this helps, >Acee > > > >>Thanks in advance >>ramesh >> >> >> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 06 16:35:06 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6E0o-00010q-F7 for ospf-archive@megatron.ietf.org; Mon, 06 Feb 2006 16:35:06 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05305 for ; Mon, 6 Feb 2006 16:33:24 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <13.0002084C@wildebeest.ease.lsoft.com>; Mon, 6 Feb 2006 16:34:33 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98708750 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 6 Feb 2006 16:34:33 -0500 Received: from 171.68.10.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 6 Feb 2006 16:34:33 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 06 Feb 2006 13:34:31 -0800 X-IronPort-AV: i="4.02,92,1139212800"; d="scan'208"; a="253812784:sNHT1067379462" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k16LYPQf022685 for ; Mon, 6 Feb 2006 13:34:30 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Feb 2006 16:34:03 -0500 Received: from [10.82.216.81] ([10.82.216.81]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 6 Feb 2006 16:34:03 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3D7BA5153B91EB4EBCF4CEDFE6263EA20513835C@apollo.adtech-inc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Feb 2006 21:34:03.0515 (UTC) FILETIME=[0CEC6CB0:01C62B65] Message-ID: <43E7C0CA.4020501@cisco.com> Date: Mon, 6 Feb 2006 16:34:02 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Originating LSAs during OSPF graceful restart To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3D7BA5153B91EB4EBCF4CEDFE6263EA20513835C@apollo.adtech-inc.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Hi Ramesh, Kandula, Ramesh wrote: >Hi Acee > >I agree with what you said, but it didn't help me completely so let me put >my question simple and straight-forward. > >1. What is the restarting router supposed to summarize during database >exchange while forming an adjacency with a neighbor (helper or otherwise)? > > What is currently in its link state database. >2. Is the behavior here any different when compared to normal OSPF bring up? > > No. Hope this helps, Acee >Thanks again >Ramesh > >-----Original Message----- >From: Acee Lindem [mailto:acee@CISCO.COM] >Sent: Monday, February 06, 2006 10:47 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: Originating LSAs during OSPF graceful restart > > >Hi Ramesh, > >Kandula, Ramesh wrote: > > > >>Hi Acee, >> >>Thanks for the reply. >> >>Are you saying that the restarting router should not summarize >>self-originated lsas (I mean pre-restart self originated lsas) during >>database exchange with a neighbor? >> >> >> >No. I'm saying the restarting router will not originate new LSAs until >exiting >graceful restart. > > > >>If so, why is this required? I don't find >>any statement in RFC3623 which implies this? >> >>Also, you said if a neighbor doesn't have a pre-restart lsa, the restarting >>router will send it. If there was an adjacency before restart with this >>neighbor, isn't the restarting router supposed to quit restart mode? >> >> >> >> >No. In fact, a router won't act as a helper router unless it previously >had an adjacency with >the restarting router. > >Thanks, >Acee > > > >>thanks >>ramesh >> >>-----Original Message----- >>From: Acee Lindem [mailto:acee@CISCO.COM] >>Sent: Saturday, February 04, 2006 2:34 AM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Re: Originating LSAs during OSPF graceful restart >> >> >>Hi Ramesh, >> >>Ramesh Kandula wrote: >> >> >> >> >> >>>Hi All, >>> >>>Should the restarting routing summarize it's own lsas (self-originated) >>>during adjaceny establishment? This can happen in the following scenario. >>> >>>Suppose there are 3 OSPF routers on a broadcast network and the DR >>>restarts. When it establishes adjacency with the first neighbor, it will >>>get its own lsas from it. Now while forming adjaceny with the second >>>neighbor, should it summarize it's own lsas? >>> >>> >>> >>> >>> >>> >>No. >> >> >> >> >> >>>If yes, then the neighbor will request for them and the restarting router >>>will send these lsas. So does the RFC 3623 mean that the restarting router >>> >>> > > > >>>should not originate "newer" instances of lsas of type 1,5 or 7? >>> >>> >>> >>> >>> >>> >>If the neighbor doesn't already have them (and normally it will), the >>restarting router will send its >>pre-restart LSAs. Don't confuse origination with sending an LSA during >>the database exchange >>process. >> >>Hope this helps, >>Acee >> >> >> >> >> >>>Thanks in advance >>>ramesh >>> >>> >>> >>> >>> >>> >>> >> >> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 06 17:13:12 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Ebg-0003KD-68 for ospf-archive@megatron.ietf.org; Mon, 06 Feb 2006 17:13:12 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10649 for ; Mon, 6 Feb 2006 17:11:24 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <9.000208C8@wildebeest.ease.lsoft.com>; Mon, 6 Feb 2006 17:12:33 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98710764 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 6 Feb 2006 17:12:33 -0500 Received: from 66.91.145.219 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 6 Feb 2006 17:12:32 -0500 Received: by apollo.adtech-inc.com with Internet Mail Service (5.5.2653.19) id <1HT4FLN7>; Mon, 6 Feb 2006 12:13:08 -1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <3D7BA5153B91EB4EBCF4CEDFE6263EA20513835F@apollo.adtech-inc.com> Date: Mon, 6 Feb 2006 12:13:07 -1000 Reply-To: Mailing List Sender: Mailing List From: "Kandula, Ramesh" Subject: Re: Originating LSAs during OSPF graceful restart To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Hi Acee, If there are more than two routers on the broadcast network, and the DR restarts then it will have some LSDB to summarize for helper routers other than the first helper router with whom adjcency is formed (they are supposed to have the same LSDB anyway). Your answer to No for the second question clears eveything. Thanks a lot for your help. Ramesh -----Original Message----- From: Acee Lindem [mailto:acee@CISCO.COM] Sent: Monday, February 06, 2006 11:34 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Originating LSAs during OSPF graceful restart Hi Ramesh, Kandula, Ramesh wrote: >Hi Acee > >I agree with what you said, but it didn't help me completely so let me put >my question simple and straight-forward. > >1. What is the restarting router supposed to summarize during database >exchange while forming an adjacency with a neighbor (helper or otherwise)? > > What is currently in its link state database. >2. Is the behavior here any different when compared to normal OSPF bring up? > > No. Hope this helps, Acee >Thanks again >Ramesh > >-----Original Message----- >From: Acee Lindem [mailto:acee@CISCO.COM] >Sent: Monday, February 06, 2006 10:47 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: Originating LSAs during OSPF graceful restart > > >Hi Ramesh, > >Kandula, Ramesh wrote: > > > >>Hi Acee, >> >>Thanks for the reply. >> >>Are you saying that the restarting router should not summarize >>self-originated lsas (I mean pre-restart self originated lsas) during >>database exchange with a neighbor? >> >> >> >No. I'm saying the restarting router will not originate new LSAs until >exiting >graceful restart. > > > >>If so, why is this required? I don't find >>any statement in RFC3623 which implies this? >> >>Also, you said if a neighbor doesn't have a pre-restart lsa, the restarting >>router will send it. If there was an adjacency before restart with this >>neighbor, isn't the restarting router supposed to quit restart mode? >> >> >> >> >No. In fact, a router won't act as a helper router unless it previously >had an adjacency with >the restarting router. > >Thanks, >Acee > > > >>thanks >>ramesh >> >>-----Original Message----- >>From: Acee Lindem [mailto:acee@CISCO.COM] >>Sent: Saturday, February 04, 2006 2:34 AM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Re: Originating LSAs during OSPF graceful restart >> >> >>Hi Ramesh, >> >>Ramesh Kandula wrote: >> >> >> >> >> >>>Hi All, >>> >>>Should the restarting routing summarize it's own lsas (self-originated) >>>during adjaceny establishment? This can happen in the following scenario. >>> >>>Suppose there are 3 OSPF routers on a broadcast network and the DR >>>restarts. When it establishes adjacency with the first neighbor, it will >>>get its own lsas from it. Now while forming adjaceny with the second >>>neighbor, should it summarize it's own lsas? >>> >>> >>> >>> >>> >>> >>No. >> >> >> >> >> >>>If yes, then the neighbor will request for them and the restarting router >>>will send these lsas. So does the RFC 3623 mean that the restarting router >>> >>> > > > >>>should not originate "newer" instances of lsas of type 1,5 or 7? >>> >>> >>> >>> >>> >>> >>If the neighbor doesn't already have them (and normally it will), the >>restarting router will send its >>pre-restart LSAs. Don't confuse origination with sending an LSA during >>the database exchange >>process. >> >>Hope this helps, >>Acee >> >> >> >> >> >>>Thanks in advance >>>ramesh >>> >>> >>> >>> >>> >>> >>> >> >> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 08 02:07:47 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6jQZ-0004JH-JZ for ospf-archive@megatron.ietf.org; Wed, 08 Feb 2006 02:07:47 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22423 for ; Wed, 8 Feb 2006 02:06:06 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <3.00020C7A@wildebeest.ease.lsoft.com>; Wed, 8 Feb 2006 2:07:09 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98838202 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 8 Feb 2006 02:07:09 -0500 Received: from 67.15.60.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 8 Feb 2006 01:57:08 -0500 Received: (qmail 25300 invoked by uid 510); 8 Feb 2006 01:11:35 -0600 Received: from bhartendu.maheshwari@aftek.com by plain.ev1servers.net by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.75.1. perlscan: 1.25-st-qms. Clear:RC:0(59.95.8.251):SA:0(-102.6/1.7):. Processed in 1.3127 secs); 08 Feb 2006 07:11:35 -0000 X-Spam-Status: No, hits=-102.6 required=1.7 X-Antivirus-MYDOMAIN-Mail-From: bhartendu.maheshwari@aftek.com via plain.ev1servers.net X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:0(59.95.8.251):SA:0(-102.6/1.7):. Processed in 1.3127 secs Process 25292) Received: from unknown (HELO bhartendum) (bhartendu.maheshwari@aftek.com@59.95.8.251) by mail.aftek.com with SMTP; 8 Feb 2006 01:11:34 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: Date: Wed, 8 Feb 2006 12:27:23 +0530 Reply-To: Mailing List Sender: Mailing List From: Bhartendu M Subject: Highest IP Address To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Hi All, I am curious to know the logic behind - Why always HIGHEST IP Address is selected for a tie break like in 1. DR election process in OSPF 2. Default router-id in OSPF Is there any advantage using highest IP address over lowest IP address? Is this a covention or any logic behind this? Thanks & Regards Bhartendu M. From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 08 04:41:07 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6lot-0007eH-8q for ospf-archive@megatron.ietf.org; Wed, 08 Feb 2006 04:41:07 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04209 for ; Wed, 8 Feb 2006 04:39:20 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <15.00020C86@wildebeest.ease.lsoft.com>; Wed, 8 Feb 2006 4:40:29 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98844567 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 8 Feb 2006 04:40:29 -0500 Received: from 194.149.124.180 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 8 Feb 2006 04:30:29 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: Cost calculating in the OSPF area Thread-Index: AcYskkBF+zFCxltfSf6phRpfXOFRgQ== Message-ID: <6639BA20B265594590E97DD72A8EE035421D7A@exosw.osw.ori.local> Date: Wed, 8 Feb 2006 10:30:28 +0100 Reply-To: Mailing List Sender: Mailing List From: "Jevos, Peter" Subject: Cost calculating in the OSPF area To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable Hello all, I have one questions about ospf metric. I designed a big network with at least one hundred routers with ospf. I'd like to know if exists some utility, tool, program, software, excel sheet or whatever, which simulate or calculate ospf cost. My problem is following. When I add one or more router into this system, traffic could change because of lower value of added links and it could affect almost entire traffic. Thanks a lot=20 Pet From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 08 09:03:35 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6pux-0006r2-FH for ospf-archive@megatron.ietf.org; Wed, 08 Feb 2006 09:03:35 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24789 for ; Wed, 8 Feb 2006 09:01:53 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <13.00020C7F@wildebeest.ease.lsoft.com>; Wed, 8 Feb 2006 9:03:04 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98860183 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 8 Feb 2006 09:03:04 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 8 Feb 2006 09:03:04 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 08 Feb 2006 06:03:03 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,98,1139212800"; d="scan'208"; a="21430285:sNHT23290216" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k18E2K6t003620; Wed, 8 Feb 2006 09:03:01 -0500 (EST) Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Feb 2006 09:02:38 -0500 Received: from [10.25.187.130] ([10.25.187.130]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Feb 2006 09:02:37 -0500 User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) 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 X-OriginalArrivalTime: 08 Feb 2006 14:02:38.0014 (UTC) FILETIME=[518875E0:01C62CB8] Message-ID: <43E9F9FB.5030608@cisco.com> Date: Wed, 8 Feb 2006 08:02:35 -0600 Reply-To: Mailing List Sender: Mailing List From: Paul Wells Subject: Re: Highest IP Address Comments: To: bhartendu.maheshwari@AFTEK.COM To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Hi Bhartendu, For DR election I believe the choice was arbitrary. There just had to be a rule that all implementations would apply consistently. The same logic applies to other cases like choosing the highest router ID as the NSSA translator. Choosing a default value for the router ID (or not) is an implementation issue, not part of the protocol. Different vendors are free to use other methods. The important thing is that the router IDs are unique. Regards, Paul Bhartendu M wrote: > Hi All, > > I am curious to know the logic behind - > > Why always HIGHEST IP Address is selected for a tie break like in > 1. DR election process in OSPF > 2. Default router-id in OSPF > > Is there any advantage using highest IP address over lowest IP address? > Is this a covention or any logic behind this? > > Thanks & Regards > Bhartendu M. From owner-ospf*ospf-archive**LISTS*-IETF*-ORG@PEACH.EASE.LSOFT.COM Wed Feb 08 18:17:17 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6yYn-0002Lt-3j for ospf-archive@megatron.ietf.org; Wed, 08 Feb 2006 18:17:17 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15556 for ; Wed, 8 Feb 2006 18:15:33 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <11.00021031@wildebeest.ease.lsoft.com>; Wed, 8 Feb 2006 18:16:44 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98914457 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 8 Feb 2006 18:16:44 -0500 Received: from 207.69.195.68 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 8 Feb 2006 18:16:44 -0500 Received: from h-68-164-152-195.snvacaid.dynamic.covad.net ([68.164.152.195] helo=earthlink.net) by pop-cowbird.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1F6yYG-0000rH-00 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 08 Feb 2006 18:16:44 -0500 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <6639BA20B265594590E97DD72A8EE035421D7A@exosw.osw.ori.local> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43EA7FB5.1ED8BC2F@earthlink.net> Date: Wed, 8 Feb 2006 15:33:09 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Cost calculating in the OSPF area To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Pet, First, it doesn't matter what the costs are if their is only one path from each source to each destination. Second, if their is only one BB ABR (some ABRs don't have a BB area), paths to the BB will transit the BB ABR and again, it doesn't make a diff as to the cost of those paths. Third, if you admin set the priority so that more than 1 router can be a DR, then output costs come into play, else the output cost of the DR is irrevalent. So, all we need to determine the say X routes that each have alternate paths. The preferred paths should have a lowest summed costs, how much lower is irrelevent. The key is that primary paths SHOULD use as one or more key values as to bandwidth capacity of the line, delays introduced, costs thru a link, etc. But again this only makes a diff for the paths that have alternates. Thus Peter, if this doesn't simplify what you are asking, because you have a large number of alternate possible paths and all routers can be DR/BRS, and you have multiple BB ABRs, then you need a consultant. Mitchell Erblich ------------------- "Jevos, Peter" wrote: > > Hello all, > > I have one questions about ospf metric. I designed a big network with at > least one hundred routers with ospf. I'd like to know if exists some > utility, tool, program, software, excel sheet or whatever, which > simulate or calculate ospf cost. > My problem is following. When I add one or more router into this system, > traffic could change because of lower value of added links and it could > affect almost entire traffic. > Thanks a lot > Pet From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 08 23:55:13 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F73pp-0002oe-9q for ospf-archive@megatron.ietf.org; Wed, 08 Feb 2006 23:55:13 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15043 for ; Wed, 8 Feb 2006 23:53:28 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <6.00021136@wildebeest.ease.lsoft.com>; Wed, 8 Feb 2006 23:54:39 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98939516 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 8 Feb 2006 23:54:39 -0500 Received: from 61.144.161.53 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 8 Feb 2006 22:35:46 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUE003VVIC9D2@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 09 Feb 2006 11:43:21 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUE002OBI98QS@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 09 Feb 2006 11:43:21 +0800 (CST) Received: from k49110 ([10.111.12.97]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IUE00D50IKEUR@szxml01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 09 Feb 2006 11:48:14 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=iso-8859-2 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <43E41C5D.8505F3E0@earthlink.net> Message-ID: <00ae01c62d29$79953b10$610c6f0a@china.huawei.com> Date: Thu, 9 Feb 2006 11:32:37 +0800 Reply-To: Mailing List Sender: Mailing List From: Zengjie Kou Subject: Re: DC RFC 1793: Nbr changing DC bit To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT hi,Mitchell The idea is good, but not necessary. Before nbr state machine reaches "Full", the check is not needed. Thanks Kou. ----- Original Message ----- From: "Erblichs" To: Sent: Saturday, February 04, 2006 11:15 AM Subject: DC RFC 1793: Nbr changing DC bit > Group, > > 1) If a P2P nbr enables the DC bit, > after full adj, SHOULD hello suppression occur, if > that were the only item preventing hello suppression? > > IMO, This is a grey area because the nbr state > machine on the nbr transition to full state is really > the only place where we need to check the > value of what the nbr specified for the hello option. > > Versus a need to check each hello for the setting of > this bit, since in this 2nd case we make the assumption > that the value is volitile. > > Mitchell Erblich From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 08 23:59:28 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F73tw-0004nY-LY for ospf-archive@megatron.ietf.org; Wed, 08 Feb 2006 23:59:28 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15162 for ; Wed, 8 Feb 2006 23:57:37 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <5.00021150@wildebeest.ease.lsoft.com>; Wed, 8 Feb 2006 23:58:49 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98942753 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 8 Feb 2006 23:58:49 -0500 Received: from 61.144.161.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 8 Feb 2006 23:13:49 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUE003A4KB40F@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 09 Feb 2006 12:25:52 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUE00KOMKAXHL@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 09 Feb 2006 12:25:52 +0800 (CST) Received: from k49110 ([10.111.12.97]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IUE00JTQKAVBA@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 09 Feb 2006 12:25:43 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <43E9F9FB.5030608@cisco.com> Message-ID: <00f101c62d2f$35229710$610c6f0a@china.huawei.com> Date: Thu, 9 Feb 2006 12:13:40 +0800 Reply-To: Mailing List Sender: Mailing List From: Zengjie Kou Subject: Re: Highest IP Address To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT Hi, Bhartendu, I agree your opinion. DR election requires a role for a tie break. OSPF adopts the "highest" IP address. The mechanism is similar to other protocols(i.e. IEEE-STP). For "router ID" is special qualification exception unique. if you have good ideas about the router ID, you will solve Aniket's question about "Selection of router id. And behaviour with IPv4 address removal". Thanks Kou. ----- Original Message ----- From: "Paul Wells" To: Sent: Wednesday, February 08, 2006 10:02 PM Subject: Re: Highest IP Address > Hi Bhartendu, > > For DR election I believe the choice was arbitrary. There just had to > be a rule that all implementations would apply consistently. The same > logic applies to other cases like choosing the highest router ID as the > NSSA translator. > > Choosing a default value for the router ID (or not) is an implementation > issue, not part of the protocol. Different vendors are free to use > other methods. The important thing is that the router IDs are unique. > > Regards, > Paul > > Bhartendu M wrote: >> Hi All, >> >> I am curious to know the logic behind - >> >> Why always HIGHEST IP Address is selected for a tie break like in >> 1. DR election process in OSPF >> 2. Default router-id in OSPF >> >> Is there any advantage using highest IP address over lowest IP address? >> Is this a covention or any logic behind this? >> >> Thanks & Regards >> Bhartendu M. From owner-ospf@PEACH.EASE.LSOFT.COM Thu Feb 09 01:30:10 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F75Ji-0005F0-N7 for ospf-archive@megatron.ietf.org; Thu, 09 Feb 2006 01:30:10 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20414 for ; Thu, 9 Feb 2006 01:28:28 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <8.00021177@wildebeest.ease.lsoft.com>; Thu, 9 Feb 2006 1:29:36 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98953199 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 9 Feb 2006 01:29:36 -0500 Received: from 207.17.137.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 9 Feb 2006 01:29:36 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k196TZ1Z094873 for ; Wed, 8 Feb 2006 22:29:35 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.13] (nimbus-sc.juniper.net [172.16.12.13]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k196TZ528563 for ; Wed, 8 Feb 2006 22:29:35 -0800 (PST) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v746.2) References: <6639BA20B265594590E97DD72A8EE035421D7A@exosw.osw.ori.local> <43EA7FB5.1ED8BC2F@earthlink.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.746.2) Message-ID: <3164C74A-C208-4480-A302-C64B14A2DF7C@juniper.net> Date: Wed, 8 Feb 2006 22:29:34 -0800 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: Cost calculating in the OSPF area To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43EA7FB5.1ED8BC2F@earthlink.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit The short version is that OSPF is a lousy mechanism for doing traffic engineering. You can influence path selection by the use of areas and/or link costs, but at the end of the day it will do what it does. If you really need engineered paths, there are more appropriate mechanisms than OSPF. --Dave On Feb 8, 2006, at 3:33 PM, Erblichs wrote: > Pet, > > First, it doesn't matter what the costs are if their > is only one path from each source to each destination. > > Second, if their is only one BB ABR (some ABRs don't have > a BB area), paths to the BB will transit the BB ABR and > again, it doesn't make a diff as to the cost of those paths. > > Third, if you admin set the priority so that more than 1 > router can be a DR, then output costs come into play, > else the output cost of the DR is irrevalent. > > So, all we need to determine the say X routes that > each have alternate paths. > > The preferred paths should have a lowest summed costs, how much > lower is irrelevent. > > The key is that primary paths SHOULD use as one or more > key values as to bandwidth capacity of the line, delays > introduced, costs thru a link, etc. But again this only > makes a diff for the paths that have alternates. > > Thus Peter, if this doesn't simplify what you are asking, > because you have a large number of alternate possible paths > and all routers can be DR/BRS, and you have multiple BB ABRs, > then you need a consultant. > > Mitchell Erblich > ------------------- > > > > > "Jevos, Peter" wrote: >> >> Hello all, >> >> I have one questions about ospf metric. I designed a big network >> with at >> least one hundred routers with ospf. I'd like to know if exists some >> utility, tool, program, software, excel sheet or whatever, which >> simulate or calculate ospf cost. >> My problem is following. When I add one or more router into this >> system, >> traffic could change because of lower value of added links and it >> could >> affect almost entire traffic. >> Thanks a lot >> Pet > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Feb 09 04:56:23 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F78XG-00073J-6u for ospf-archive@megatron.ietf.org; Thu, 09 Feb 2006 04:56:22 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04581 for ; Thu, 9 Feb 2006 04:54:39 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <6.000211AE@wildebeest.ease.lsoft.com>; Thu, 9 Feb 2006 4:55:50 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98962320 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 9 Feb 2006 04:55:50 -0500 Received: from 194.149.124.180 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 9 Feb 2006 04:55:49 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Topic: Cost calculating in the OSPF area Thread-Index: AcYtQjPVT5glvfeORVKPVMpKAcw+7gAG90iQ Message-ID: <6639BA20B265594590E97DD72A8EE035421D88@exosw.osw.ori.local> Date: Thu, 9 Feb 2006 10:55:41 +0100 Reply-To: Mailing List Sender: Mailing List From: "Jevos, Peter" Subject: Re: Cost calculating in the OSPF area To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable Thanks for your answers, I think I was wrong when I specified my question. I'm looking for some tool or program , which calculate shortest path. Every cost on the links is defined but I'd like to know if something happened (changed ) when I add a new router into system. I know it is matter of Dijsktra's algorithm, all I'm asking if somenone's using some program to calulate the shortest path Thanks=20 Pet =20 -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Dave Katz Sent: Thursday, February 09, 2006 7:30 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Cost calculating in the OSPF area The short version is that OSPF is a lousy mechanism for doing traffic engineering. You can influence path selection by the use of areas and/or link costs, but at the end of the day it will do what it does. If you really need engineered paths, there are more appropriate mechanisms than OSPF. --Dave On Feb 8, 2006, at 3:33 PM, Erblichs wrote: > Pet, > > First, it doesn't matter what the costs are if their > is only one path from each source to each destination. > =09 > Second, if their is only one BB ABR (some ABRs don't have > a BB area), paths to the BB will transit the BB ABR and > again, it doesn't make a diff as to the cost of those paths. > > Third, if you admin set the priority so that more than 1 > router can be a DR, then output costs come into play, > else the output cost of the DR is irrevalent. > > So, all we need to determine the say X routes that > each have alternate paths. > > The preferred paths should have a lowest summed costs, how much > lower is irrelevent. > > The key is that primary paths SHOULD use as one or more > key values as to bandwidth capacity of the line, delays > introduced, costs thru a link, etc. But again this only > makes a diff for the paths that have alternates. > > Thus Peter, if this doesn't simplify what you are asking, > because you have a large number of alternate possible paths > and all routers can be DR/BRS, and you have multiple BB ABRs, > then you need a consultant. > > Mitchell Erblich > ------------------- > > =09 > > =09 > "Jevos, Peter" wrote: >> >> Hello all, >> >> I have one questions about ospf metric. I designed a big network with >> at least one hundred routers with ospf. I'd like to know if exists=20 >> some utility, tool, program, software, excel sheet or whatever, which >> simulate or calculate ospf cost. >> My problem is following. When I add one or more router into this=20 >> system, traffic could change because of lower value of added links=20 >> and it could affect almost entire traffic. >> Thanks a lot >> Pet > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Feb 09 05:55:50 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F79So-0005U0-NF for ospf-archive@megatron.ietf.org; Thu, 09 Feb 2006 05:55:50 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08936 for ; Thu, 9 Feb 2006 05:54:07 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <8.000211BC@wildebeest.ease.lsoft.com>; Thu, 9 Feb 2006 5:55:19 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98964527 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 9 Feb 2006 05:55:19 -0500 Received: from 203.199.83.147 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 9 Feb 2006 05:55:18 -0500 Received: (qmail 15762 invoked by uid 510); 9 Feb 2006 10:54:53 -0000 Received: from unknown (203.126.136.220) by rediffmail.com via HTTP; 09 feb 2006 10:54:53 -0000 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="Next_1139482493---0-203.199.83.147-15755" Message-ID: <20060209105453.15761.qmail@webmail25.rediffmail.com> Date: Thu, 9 Feb 2006 10:54:53 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: Ospfv2 MIB To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: This is a multipart mime message --Next_1139482493---0-203.199.83.147-15755 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable ospfHostCfgAreaID OBJECT-TYPE =0A SYNTAX AreaID =0A M= AX-ACCESS read-create =0A STATUS current =0A DESCRI= PTION =0A "Allows the configuration of the Area the Host Entry i= s =0A to be found within." =0A=0A Does that mean, this c= onfiguration results in the creation of "Ospf Area Entry" if one does not e= xist. =A0=0AIf so, why such a behaviour?=0A=0AThanks=0AVivek=0A --Next_1139482493---0-203.199.83.147-15755 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0AospfHostCfgAreaID OBJECT-TYPE
=0A        SYN= TAX      AreaID
=0A        MAX-ACC= ESS  read-create
=0A        STATUS  &nb= sp;   current
=0A        DESCRIPTION
=0A=             "Allows the configuration of= the Area the Host Entry is
=0A           = ; to be found within."
=0A
=0A<Vivek> Does that mean, th= is configuration results in the creation of "Ospf Area Entry" if = one does not exist. 
=0AIf so, why such a behaviour?
=0A
=0A= Thanks
=0AVivek
=0A=0A

=0A

=0A=0A --Next_1139482493---0-203.199.83.147-15755-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Feb 09 07:57:30 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7BMY-0007m6-Ap for ospf-archive@megatron.ietf.org; Thu, 09 Feb 2006 07:57:30 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17500 for ; Thu, 9 Feb 2006 07:55:39 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <14.000211BE@wildebeest.ease.lsoft.com>; Thu, 9 Feb 2006 7:56:47 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98979152 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 9 Feb 2006 07:56:47 -0500 Received: from 64.233.184.203 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 9 Feb 2006 07:56:06 -0500 Received: by wproxy.gmail.com with SMTP id 71so109892wri for ; Thu, 09 Feb 2006 04:56:06 -0800 (PST) Received: by 10.54.69.12 with SMTP id r12mr3161486wra; Thu, 09 Feb 2006 04:56:06 -0800 (PST) Received: by 10.54.116.5 with HTTP; Thu, 9 Feb 2006 04:56:06 -0800 (PST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8303_27980053.1139489766287" References: <20060209105453.15761.qmail@webmail25.rediffmail.com> Message-ID: Date: Thu, 9 Feb 2006 18:26:06 +0530 Reply-To: Mailing List Sender: Mailing List From: Santosh Esale Subject: Re: Ospfv2 MIB To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: ------=_Part_8303_27980053.1139489766287 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi All, Want to know the solutions for below problem: Consider the below topology from RFC 3906 and all ospf link cost as 10 and two TE-tunnels T1: (RTA-RTD) and T2: (RTA to RTE via rtrC) rtrA -- rtrB -- rtrC | | rtrD -- rtrE In OSPF, after calcualting SPT till rtrB, suppose we choose rtrD from candidate list to put into SPT, we first modify rtrD routers nexthop to T1 with cost 1 which is a fixed cost assigned to all TE-Tunnel by MPLS in my algorthim.Then we choose rtrE(cost 11, compare to rtrC with cost 20) from candidate list and modify the nexthop to T2 with cost of 1. Now, to reach rtrC, the cost from rtrE to rtrC is 11 because of TE-tunnel T2, while from rtrB is 20, hence we modify rtrC's nexthop to TE tunnel T2. This is wrong as all traffic going to rtrC, will go to rtrE via tunnel T2 (via rtrC), then routed back to rtrC. i though of checking with the help of mpls, while modifying nexthop of rtrC to tunnel T2, whether any of RTC's address is present in nexthop list of T= E Tunnel T2, basically avoiding a loop, but in some cases mpls will not have nexthop list(no RROs), hence stuck ? so can anyone think of any other solutions ? Regards Santosh ------=_Part_8303_27980053.1139489766287 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
Hi=20 All,
 
     &n= bsp;  Want to know=20 the solutions for below problem:

Consider the below top= ology from RFC=20 3906 and all ospf link cost as 10 and two TE-tunnels T1: (RTA-RTD= ) and T2: (RTA=20 to RTE via rtrC)

     rtrA -- rtrB --= rtrC

        =
;       |      =
 |

         =
;     rtrD -- rtrE

  In OSPF, after=20 calcualting SPT till rtrB, suppose we choose rtrD from candidate list to pu= t=20 into SPT, we first modify rtrD routers nexthop to T1 with cost 1 which= is a=20 fixed cost assigned to all TE-Tunnel by MPLS in my algorthim.Then we choose= =20 rtrE(cost 11, compare to rtrC with cost 20) from candidate list and mo= dify the=20 nexthop to T2 with cost of 1.

Now, to reach = rtrC, the=20 cost from rtrE to rtrC is 11 because of TE-tunnel T2, while from rtrB is 20= ,=20 hence we modify rtrC's nexthop to TE tunnel T2.

=

This is wrong = as all=20 traffic going to rtrC, will go to rtrE via tunnel T2 (via rtrC), then route= d=20 back to rtrC.

i though of checking with the help o= f mpls,=20 while modifying nexthop of rtrC to tunnel T2, whether any of RTC's address = is=20 present in nexthop list of  TE Tunnel T2, basically avoiding a loop, b= ut in some=20 cases mpls will not have nexthop list(no RROs), hence stuck=20 ?

so can anyone think of any other=20 solutions ?

Regards

Santosh

 

=  

 <= /font>

------=_Part_8303_27980053.1139489766287-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Feb 09 07:57:32 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7BMY-0007mC-Hn for ospf-archive@megatron.ietf.org; Thu, 09 Feb 2006 07:57:31 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17502 for ; Thu, 9 Feb 2006 07:55:40 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <8.000211D2@wildebeest.ease.lsoft.com>; Thu, 9 Feb 2006 7:57:15 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98979197 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 9 Feb 2006 07:57:14 -0500 Received: from 64.233.184.193 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 9 Feb 2006 07:57:14 -0500 Received: by wproxy.gmail.com with SMTP id 71so110126wri for ; Thu, 09 Feb 2006 04:57:14 -0800 (PST) Received: by 10.54.72.17 with SMTP id u17mr745083wra; Thu, 09 Feb 2006 04:57:14 -0800 (PST) Received: by 10.54.116.5 with HTTP; Thu, 9 Feb 2006 04:57:14 -0800 (PST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8311_26119162.1139489834242" Message-ID: Date: Thu, 9 Feb 2006 18:27:14 +0530 Reply-To: Mailing List Sender: Mailing List From: Santosh Esale Subject: IGP shortcut in OSPF To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: ------=_Part_8311_26119162.1139489834242 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi All, Want to know the solutions for below problem: Consider the below topology from RFC 3906 and all ospf link cost as 10 and two TE-tunnels T1: (RTA-RTD) and T2: (RTA to RTE via rtrC) rtrA -- rtrB -- rtrC | | rtrD -- rtrE In OSPF, after calcualting SPT till rtrB, suppose we choose rtrD from candidate list to put into SPT, we first modify rtrD routers nexthop to T1 with cost 1 which is a fixed cost assigned to all TE-Tunnel by MPLS in my algorthim.Then we choose rtrE(cost 11, compare to rtrC with cost 20) from candidate list and modify the nexthop to T2 with cost of 1. Now, to reach rtrC, the cost from rtrE to rtrC is 11 because of TE-tunnel T2, while from rtrB is 20, hence we modify rtrC's nexthop to TE tunnel T2. This is wrong as all traffic going to rtrC, will go to rtrE via tunnel T2 (via rtrC), then routed back to rtrC. i though of checking with the help of mpls, while modifying nexthop of rtrC to tunnel T2, whether any of RTC's address is present in nexthop list of T= E Tunnel T2, basically avoiding a loop, but in some cases mpls will not have nexthop list(no RROs), hence stuck ? so can anyone think of any other solutions ? Regards Santosh ------=_Part_8311_26119162.1139489834242 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
Hi=20 All,
 
     &n= bsp;  Want to know=20 the solutions for below problem:

Consider the below topology from RFC=20 3906 and all ospf link cost as 10 and two TE-tunnels T1: (RTA-RTD= ) and T2: (RTA=20 to RTE via rtrC)

&= nbsp;    rtrA -- rtrB -- rt= rC

        &n=
bsp;      |       |

        &n=
bsp;     rtrD -- rtrE

  In OSPF, after=20 calcualting SPT till rtrB, suppose we choose rtrD from candidate list to pu= t=20 into SPT, we first modify rtrD routers nexthop to T1 with cost 1 which= is a=20 fixed cost assigned to all TE-Tunnel by MPLS in my algorthim.Then we choose= =20 rtrE(cost 11, compare to rtrC with cost 20) from candidate list and mo= dify the=20 nexthop to T2 with cost of 1.

Now, to reach rtrC, the=20 cost from rtrE to rtrC is 11 because of TE-tunnel T2, while from rtrB is 20= ,=20 hence we modify rtrC's nexthop to TE tunnel T2.

This is wrong as all=20 traffic going to rtrC, will go to rtrE via tunnel T2 (via rtrC), then route= d=20 back to rtrC.

i though of checking with the help of mpls,=20 while modifying nexthop of rtrC to tunnel T2, whether any of RTC's address = is=20 present in nexthop list of  TE Tunnel T2, basically avoiding a loop, b= ut in some=20 cases mpls will not have nexthop list(no RROs), hence stuck=20 ?

so can anyone think of any other=20 solutions ?

Regards

Santosh

 

 

 

------=_Part_8311_26119162.1139489834242-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Feb 09 09:50:07 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7D7X-0007TC-7B for ospf-archive@megatron.ietf.org; Thu, 09 Feb 2006 09:50:07 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27469 for ; Thu, 9 Feb 2006 09:48:19 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <15.000211F2@wildebeest.ease.lsoft.com>; Thu, 9 Feb 2006 9:49:29 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98984856 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 9 Feb 2006 09:49:29 -0500 Received: from 192.75.23.74 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 9 Feb 2006 09:49:29 -0500 Received: from [138.120.52.67] (need.ca.alcatel.com [138.120.52.67]) by smtp2.ca.alcatel.com (ALCANET) with ESMTP id k19EnQ43014778; Thu, 9 Feb 2006 08:49:26 -0600 User-Agent: Mozilla Thunderbird 1.0.6-1.4.1 (X11/20050719) 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 X-Scanned-By: MIMEDefang 2.51 on 138.120.252.79 Message-ID: <43EB5676.1030905@alcatel.com> Date: Thu, 9 Feb 2006 09:49:26 -0500 Reply-To: Mailing List Sender: Mailing List From: Ehsan Rezaaifar Subject: Re: IGP shortcut in OSPF Comments: To: s.esale@GMAIL.COM To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Hi, Well one way is to keep the cost of the routes the same as IGP metric of the native IP. My understanding of the RFC is that if you choose to change the cost of the route, you should only modify it when it's added to the routing table (or as the RFC calls it the Private IGP RIB). I am not quite sure how to implement this, but I think what it means is that the IGP SCs would not affect how the SPT looks like, (SPT is built based on the IGP metrics), but when the routes are added to the "private IGP RIB" the load balancing is done based on the cost of the IGP SCs. Basically when we are adding the routes to the Routing RIB, we compare the ECMPs based on their IGP SC cost. So in your case it should not affect the toute to the rtrC, (still through rtrB). Take care, Ehsan Santosh Esale wrote: > > Hi All, > > Want to know the solutions for below problem: > > Consider the below topology from RFC 3906 and all ospf link cost as 10 > and two TE-tunnels T1: (RTA-RTD) and T2: (RTA to RTE via rtrC) > > rtrA -- rtrB -- rtrC > > | | > > > rtrD -- rtrE > > In OSPF, after calcualting SPT till rtrB, suppose we choose rtrD > from candidate list to put into SPT, we first modify rtrD routers > nexthop to T1 with cost 1 which is a fixed cost assigned to all > TE-Tunnel by MPLS in my algorthim.Then we choose rtrE(cost 11, compare > to rtrC with cost 20) from candidate list and modify the nexthop to T2 > with cost of 1. > > Now, to reach rtrC, the cost from rtrE to rtrC is 11 because of > TE-tunnel T2, while from rtrB is 20, hence we modify rtrC's nexthop to > TE tunnel T2. > > This is wrong as all traffic going to rtrC, will go to rtrE via tunnel > T2 (via rtrC), then routed back to rtrC. > > i though of checking with the help of mpls, while modifying nexthop of > rtrC to tunnel T2, whether any of RTC's address is present in nexthop > list of TE Tunnel T2, basically avoiding a loop, but in some cases > mpls will not have nexthop list(no RROs), hence stuck ? > > so can anyone think of any other solutions ? > > Regards > > Santosh > > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Feb 09 10:47:38 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7E1C-0001lJ-4x for ospf-archive@megatron.ietf.org; Thu, 09 Feb 2006 10:47:38 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03060 for ; Thu, 9 Feb 2006 10:45:46 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <1.0002123D@wildebeest.ease.lsoft.com>; Thu, 9 Feb 2006 10:46:53 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98988662 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 9 Feb 2006 10:46:53 -0500 Received: from 171.71.176.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 9 Feb 2006 10:46:53 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 09 Feb 2006 07:46:52 -0800 X-IronPort-AV: i="4.02,100,1139212800"; d="scan'208"; a="402876695:sNHT31969824" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k19FkpKT014695 for ; Thu, 9 Feb 2006 07:46:52 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Feb 2006 10:46:51 -0500 Received: from [10.82.216.81] ([10.82.216.81]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Feb 2006 10:46:51 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20060209105453.15761.qmail@webmail25.rediffmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Feb 2006 15:46:51.0371 (UTC) FILETIME=[0B3CC3B0:01C62D90] Message-ID: <43EB63EA.3080506@cisco.com> Date: Thu, 9 Feb 2006 10:46:50 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Ospfv2 MIB To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20060209105453.15761.qmail@webmail25.rediffmail.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Vivek Dubey wrote: >ospfHostCfgAreaID OBJECT-TYPE > SYNTAX AreaID > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Allows the configuration of the Area the Host Entry is > to be found within." > > Does that mean, this configuration results in the creation of "Ospf Area Entry" if one does not exist. >If so, why such a behaviour? > > Hi Vivek, My interpretation is that this should not create an area if the specified area doesn't exist. It is analogous to ospfIfAreaId for interfaces. I think trying to specify all the validation for read-create objects is a slippery slope. Thanks, Acee >Thanks >Vivek > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Feb 09 14:15:39 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7HGU-000541-Tj for ospf-archive@megatron.ietf.org; Thu, 09 Feb 2006 14:15:38 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21965 for ; Thu, 9 Feb 2006 14:13:53 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <2.000212DE@wildebeest.ease.lsoft.com>; Thu, 9 Feb 2006 14:14:59 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99004083 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 9 Feb 2006 14:14:59 -0500 Received: from 171.71.176.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 9 Feb 2006 14:14:59 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 09 Feb 2006 11:14:56 -0800 X-IronPort-AV: i="4.02,101,1139212800"; d="scan'208"; a="402977234:sNHT56563976" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k19JErWH014564 for ; Thu, 9 Feb 2006 11:14:56 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Feb 2006 14:14:51 -0500 Received: from [10.82.216.81] ([10.82.216.81]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Feb 2006 14:14:51 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <43E00A1C.70669007@earthlink.net> <43E016EC.10401@cisco.com> <43E03BA3.FC683596@earthlink.net> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Feb 2006 19:14:51.0664 (UTC) FILETIME=[1A125900:01C62DAD] Message-ID: <43EB94AB.6020802@cisco.com> Date: Thu, 9 Feb 2006 14:14:51 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-ietf-ospf-ospfv3-update-07.txt : instance To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43E03BA3.FC683596@earthlink.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Hi Mitchell, Erblichs wrote: >Acee, > > Yes, I was just using PDB as a > well-known reference global data struct > that contains areas which contains links/interfaces, > which contain neighbors.. I felt that I could use the name > since the vendor published the name and decript > in a public doc. > > I don't expect it to be used in a IETF arch doc. > > So, WHERE does one find in this RFC, that an instance > is succintly below what you just stated and not just s > something specific to links / interfaces. > > I was trying to just re-word what was existing. > > But, I like your below statement , IMO, it still needs just a > bit more. That each instance is a fully functioning OSPF process > that periodicly run a SPF algor. And that each LSDB within > each instance can be completely different! > > > >>a separate instance of OSPF >>with its own >>separate set of protocol data structures, state machines, and processes. >> >> > > What about? An instance is a fully functioning OSPF protocol > with its own separate set of protocol data structures (areas, > interfaces, nbrs, LSDB, etc), state machines, and processes > that include SPF calculations. > > I'll add a definition to the terminolgy section. > Which what I read in this doc only refers to links and misses > the mention of areas, or the groupings of areas, which has to > be called something. I called it a process!! > > And this process, where do I find in this RFC reference to > SPF calcs per instance? > > As to a separate routing domain, if diff instances do not exchange > routing information LSAs, I don't see how they can be combined. > And they don't DIRECTLY exchange because they have different > instance-ids in their packets. > > While the circumstances are unique, you could have multiple OSPF instances in the same routing domain (in other words they share a common IP address space and operate on the same routing table). Thanks, Acee > Mitchell Erblich > PS: I will send part 2 of this instance set of suggestions/ > questions.. > And for people who can follow my logic, instance-ids can > also split areas with two identical area-ids numbers but > different instances and different ABRs. > ------------ > > > >Acee Lindem wrote: > > >>Hi Mitchell, >>I'm afraid I don't agree with this suggestion either. See inline. >> >>Erblichs wrote: >> >> >> >>>Group, >>> >>> This is vastly more complicated, so these suggestions >>> have been separated from my previous email. >>> >>> 2.4 Explicit support for multiple instances per link >>> >>> "Support for multiple protocol instances on a link is accomplished via >>> an "Instance ID" contained in the OSPF packet header and OSPF >>> interface data structures. Instance ID solely affects the reception >>> of OSPF packets and applies to normal OSPF interfaces and virtual >>> links." >>> >>> I like this for brevity, but ... >>> >>> >>> Summary >>> ------- >>> The major question is do we consider a instance equal >>> to a underlying PDB? >>> >>> >>> >>> >>I know for a fact that not all OSPF implementations have underlying PDBs >>:^). >> >> >> >>> Verbose >>> -------- >>> It is my understanding is if we want to separate adj's >>> based on instance ID that is contained within OSPF >>> control packets then we must: >>> >>> FYI: this list is not complete >>> >>> * For each set of links on different routers that have >>> matching Instance-ID, we must KEEP the adj's LSAs separate >>> from other Instance-IDs LSAs. >>> >>> * We must be able to group one or more links with >>> a area-id and though two area-ids may be equal, they must >>> be kept separate because they below to different instances. >>> >>> * We must be able to group like Instance-ID areas with >>> each other, which I will term a process. >>> >>> * Then each instance has one or more areas with one or >>> more links, and that can be separately configured as >>> a single independent OSPF process, >>> >>> * So, each process, must run separately to keep its LSAs >>> separate and must each have full OSPF functionality. >>> >>> * This generates a separate routing domain per instance. >>> >>> >>> >>> >>Nope. A "protocol instance" is just that - a separate instance of OSPF >>with its own >>separate set of protocol data structures, state machines, and processes. >>It usually but doesn't >>necessarily imply a separate routing domain. I could add "Protocol >>Instance" to >>section 1.2 if there is any confusion. >> >>Thanks, >>Acee >> >> >> >>> THEN...... if this is true... My first ROUGH suggested >>> change on this subject is... >>> >>> Support for multiple protocol instances within the OSPFv3 >>> protocol has a 2 part approach. One part is that the >>> "Instance ID" is contained in the OSPFv3 packet header. >>> The second part is that each Instance has one or more >>> links that can be shared by other instances. Each >>> set of interfaces are grouped together into a area and >>> the set of areas are grouped for normal OSPF functionality. >>> >>> Thus, the full set of LSAs recieved per instance are run >>> within separate SPF algorithms and each has their own >>> set of routing / forwarding tables. >>> >>> And each provider can be allocated an instance / separate >>> OSPF process on a single router that will support the >>> provider's requirements. >>> >>> Mitchell Erblich >>> >>> >>> >>> >>> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Feb 09 14:26:15 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7HQl-0003bJ-AV for ospf-archive@megatron.ietf.org; Thu, 09 Feb 2006 14:26:15 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22759 for ; Thu, 9 Feb 2006 14:24:32 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <7.000212CE@wildebeest.ease.lsoft.com>; Thu, 9 Feb 2006 14:25:40 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99004752 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 9 Feb 2006 14:25:40 -0500 Received: from 171.71.176.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 9 Feb 2006 14:25:40 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 09 Feb 2006 11:25:40 -0800 X-IronPort-AV: i="4.02,101,1139212800"; d="scan'208"; a="402982076:sNHT33133926" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k19JPWKj022065 for ; Thu, 9 Feb 2006 11:25:40 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Feb 2006 14:25:16 -0500 Received: from [10.82.216.81] ([10.82.216.81]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Feb 2006 14:25:16 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <43E06D08.94415E2C@earthlink.net> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Feb 2006 19:25:16.0537 (UTC) FILETIME=[8E866690:01C62DAE] Message-ID: <43EB971C.1060109@cisco.com> Date: Thu, 9 Feb 2006 14:25:16 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-ietf-ospf-ospfv3-update-07.txt : part 2: instance To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43E06D08.94415E2C@earthlink.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Hi Mitchell, Erblichs wrote: >Group, > > Three questions/comments dealing with Multiple instances > with one or more in Standby state. Last few are NITs. > >1))))) 2.4 Explicit support for multiple instances per link > >"In OSPF for IPv4 this was supported in a haphazard fashion using the > authentication fields in the OSPF for IPv4 header." > >IMO, this generally was done by having two OSPF processes share >the same interface whereby each process generated their own >set of adjs, by xmit/recving hello packetts, xmit/recving all >the OSPF control packets. > >To make it as efficient as possible, a "1 to many multiplexor" >was sometimes used for recieving, and reverse for transmiting. So, two >or more processes were ACTIVE simulteneously on the same interface. >To allow this a simple reference count was sometimes used to identify >whether the interface was active. > > You still need authentication or some other mechanism to de-multiplex packets when the interface is configured in two separate areas or OSPF instances. Anyway, I don't want to delve too deeping in how it was done is OSPFv2. >So, if we do this or > >2.4 Explicit support for multiple instances per link > >"to have a single link belong to two or more OSPF areas." > >Requires BOTH processes's to be ACTIVE on the same interface (we are >referring to V2 haphazard support). Howevever, I am confused with the >two following sections for v3 which seems to contradict this.. > > The section below pertains to multiple interface on single link with the same interface instance ID. I'll assure this clear. Based on this, I think most of the other questions are out of context. >3.9 Multiple interfaces to a single link > > In OSPF for IPv6, a router may have multiple interfaces to a single > link. All interfaces are involved in the reception and transmission > of data traffic, but only a single interface sends and receives OSPF > control traffic. > > "only a single interface sends and receives OSPF control traffic." > How do both instances have full sets of adjs, LSA exchange, etc? > >3.9.1 Standby Interface State > > In this state, the interface is one of multiple interfaces to a link > and this interface is designated Standby and is not sending or > receiving control packets. > > "this interface is designated Standby and is not sending or receiving >control packets." > How does the Standby interface/process recv/xmit LSAs?? > > It doesn't. > >MultipleInterfacesToLink > An interfaces on the router has received a hello packet from > another interface on the same router. One of the interfaces is > designated as the Active Interface, and the other interface is > designated as a Standby Interface. The Standby Interface > transitions to the Standby state. > >------ > >So, I am reading that one of my instances has the active interface and >the others a Standby state. But "only a single interface sends and >receives OSPF > control traffic." > >So, how do I sync my LSDB via DBD packets, and refresh >if my standby interface from one of my other instances >can not send or recieve control packets????? > >Are you implicitly stating that all processes with all control packets >will use the same Active interface???? > > No - I'm implying that all interfaces pretain to the same OSPF instance and area. > >2nd question)))) 3.9.1 Standby Interface State > >If I believed that you need a Standby state, which I am not 100% sure >because of the above section, Why transistion to down, when the >ActiveDies? > >When you have the Event: MultipleInterfacesToLink with Standby new >State, >why don't you stay in this state "AS LONG AS a Standby is available? >Simply >elect new ActiveInterface as long as a Standby Exists? > >Why? In the RFC's state machine Standby's go Down, versus >being promoted MultipleInterfacesToLink in my suggestion > >So again when a Interface is in the Standby state, why isn't one of >them promoted to MultipleInterfaces ToLink, if the reference count >is 2 or more. When a Standby transitions to down, the Reference count >should be decremented. If the reference count is 1, then DOWN is >acceptable. > >3))))) Grammar : should be plural :^) unless we limit 2 interfaces > on the same link. > > Ok. >MultipleInterfacesToLink > An interfaces on the router has received a hello packet from > another interface on the same router. One of the interfaces is > designated as the Active Interface, and the other interface is > designated as a Standby Interface. The Standby Interface > transitions to the Standby state. > >interface is > interfaces are >and the other interfaces are designated as a Standby Interface. > >4)))) I think Moy's address bounces.. > > Do you have an updated one :^)? >5) A.4 LSA formats > > This memo defines eight distinct types of LSAs. >>>> nine listed > > 1 0x2001 Router-LSA > 2 0x2002 Network-LSA > 3 0x2003 Inter-Area-Prefix-LSA > 4 0x2004 Inter-Area-Router-LSA > 5 0x4005 AS-external-LSA > 6 0x2006 Group-membership-LSA > 7 0x2007 NSSA-LSA > 8 0x0008 Link-LSA > 9 0x2009 Intra-Area-Prefix-LSA > > Ok - I'll clarify. Thanks, Acee > > > >Mitchell Erblich >------------------ > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Feb 09 15:06:32 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7I3k-0002SI-ID for ospf-archive@megatron.ietf.org; Thu, 09 Feb 2006 15:06:32 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25610 for ; Thu, 9 Feb 2006 15:04:41 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <4.00021324@wildebeest.ease.lsoft.com>; Thu, 9 Feb 2006 15:05:47 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99006973 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 9 Feb 2006 15:05:47 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 9 Feb 2006 15:05:47 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 09 Feb 2006 12:05:48 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,101,1139212800"; d="scan'208"; a="21556783:sNHT25742400" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k19K5gPO018634 for ; Thu, 9 Feb 2006 15:05:45 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Feb 2006 15:05:42 -0500 Received: from [10.82.216.81] ([10.82.216.81]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Feb 2006 15:05:42 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <43E06D08.94415E2C@earthlink.net> <43EB971C.1060109@cisco.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Feb 2006 20:05:42.0324 (UTC) FILETIME=[34681F40:01C62DB4] Message-ID: <43EBA095.2040302@cisco.com> Date: Thu, 9 Feb 2006 15:05:41 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-ietf-ospf-ospfv3-update-07.txt : part 2: instance To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43EB971C.1060109@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Mitchell, Acee Lindem wrote: > Hi Mitchell, > > Erblichs wrote: > >> Group, >> >> Three questions/comments dealing with Multiple instances >> with one or more in Standby state. Last few are NITs. >> >> 1))))) 2.4 Explicit support for multiple instances per link >> >> "In OSPF for IPv4 this was supported in a haphazard fashion using the >> authentication fields in the OSPF for IPv4 header." >> >> IMO, this generally was done by having two OSPF processes share >> the same interface whereby each process generated their own >> set of adjs, by xmit/recving hello packetts, xmit/recving all >> the OSPF control packets. >> >> To make it as efficient as possible, a "1 to many multiplexor" >> was sometimes used for recieving, and reverse for transmiting. So, two >> or more processes were ACTIVE simulteneously on the same interface. >> To allow this a simple reference count was sometimes used to identify >> whether the interface was active. >> >> > You still need authentication or some other mechanism to de-multiplex > packets when the > interface is configured in two separate areas or OSPF instances. > Anyway, I don't want > to delve too deeping in how it was done is OSPFv2. > >> So, if we do this or >> >> 2.4 Explicit support for multiple instances per link >> >> "to have a single link belong to two or more OSPF areas." >> >> Requires BOTH processes's to be ACTIVE on the same interface (we are >> referring to V2 haphazard support). Howevever, I am confused with the >> two following sections for v3 which seems to contradict this.. >> >> > The section below pertains to multiple interface on single link with > the same interface instance ID. > I'll assure this clear. Based on this, I think most of the other > questions are out of context. This is already adequately explained in bullet. > >> 3.9 Multiple interfaces to a single link >> >> In OSPF for IPv6, a router may have multiple interfaces to a single >> link. All interfaces are involved in the reception and transmission >> of data traffic, but only a single interface sends and receives OSPF >> control traffic. >> >> "only a single interface sends and receives OSPF control traffic." >> How do both instances have full sets of adjs, LSA exchange, etc? >> >> 3.9.1 Standby Interface State >> >> In this state, the interface is one of multiple interfaces to a link >> and this interface is designated Standby and is not sending or >> receiving control packets. >> >> "this interface is designated Standby and is not sending or >> receiving >> control packets." >> How does the Standby interface/process recv/xmit LSAs?? >> >> > It doesn't. > >> >> MultipleInterfacesToLink >> An interfaces on the router has received a hello packet from >> another interface on the same router. One of the interfaces is >> designated as the Active Interface, and the other interface is >> designated as a Standby Interface. The Standby Interface >> transitions to the Standby state. >> >> ------ >> >> So, I am reading that one of my instances has the active interface and >> the others a Standby state. But "only a single interface sends and >> receives OSPF >> control traffic." >> So, how do I sync my LSDB via DBD packets, and refresh >> if my standby interface from one of my other instances >> can not send or recieve control packets????? >> >> Are you implicitly stating that all processes with all control packets >> will use the same Active interface???? >> >> > No - I'm implying that all interfaces pretain to the same OSPF > instance and area. > >> >> 2nd question)))) 3.9.1 Standby Interface State >> >> If I believed that you need a Standby state, which I am not 100% sure >> because of the above section, Why transistion to down, when the >> ActiveDies? >> >> When you have the Event: MultipleInterfacesToLink with Standby new >> State, >> why don't you stay in this state "AS LONG AS a Standby is available? >> Simply >> elect new ActiveInterface as long as a Standby Exists? >> >> Why? In the RFC's state machine Standby's go Down, versus >> being promoted MultipleInterfacesToLink in my suggestion >> >> So again when a Interface is in the Standby state, why isn't one of >> them promoted to MultipleInterfaces ToLink, if the reference count >> is 2 or more. When a Standby transitions to down, the Reference count >> should be decremented. If the reference count is 1, then DOWN is >> acceptable. >> >> 3))))) Grammar : should be plural :^) unless we limit 2 interfaces >> on the same link. >> >> > Ok. Precisely where do you think it is wrong. > >> MultipleInterfacesToLink >> An interfaces on the router has received a hello packet from >> another interface on the same router. One of the interfaces is >> designated as the Active Interface, and the other interface is >> designated as a Standby Interface. The Standby Interface >> transitions to the Standby state. >> >> interface is > interfaces are >> and the other interfaces are designated as a Standby Interface. >> 4)))) I think Moy's address bounces.. >> >> > Do you have an updated one :^)? > >> 5) A.4 LSA formats >> >> This memo defines eight distinct types of LSAs. >>>> nine listed >> >> 1 0x2001 Router-LSA >> 2 0x2002 Network-LSA >> 3 0x2003 Inter-Area-Prefix-LSA >> 4 0x2004 Inter-Area-Router-LSA >> 5 0x4005 AS-external-LSA >> 6 0x2006 Group-membership-LSA >> 7 0x2007 NSSA-LSA >> 8 0x0008 Link-LSA >> 9 0x2009 Intra-Area-Prefix-LSA > Please DO NOT cut'n paste pieces from different parts of the document out of context. It is clear in the context of the document, which LSAs are defined and which LSA function codes are reserved. Thanks, Acee >> >> > Ok - I'll clarify. > > Thanks, > Acee > >> >> >> >> Mitchell Erblich >> ------------------ >> >> >> > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 10 00:31:29 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7QsT-0004hM-4s for ospf-archive@megatron.ietf.org; Fri, 10 Feb 2006 00:31:29 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14417 for ; Fri, 10 Feb 2006 00:29:37 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <8.0002146A@wildebeest.ease.lsoft.com>; Fri, 10 Feb 2006 0:30:48 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99045096 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 10 Feb 2006 00:30:48 -0500 Received: from 209.119.0.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 10 Feb 2006 00:30:48 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by LIME.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00076AA8@LIME.ease.lsoft.com>; Fri, 10 Feb 2006 0:29:42 -0500 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Message-ID: Date: Fri, 10 Feb 2006 00:30:25 -0500 Reply-To: Mailing List Sender: Mailing List From: Ramesh Kandula Subject: DROther/BDR graceful restart question To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable Hi All, Suppose a DROther router restarts gracefully on a broadcast network.=20 Before restart it has adjacencies with DR and BDR. According to clause in= =20 2.2.1 (RFC 3623), it is supposed to wait till it forms adjacencies with=20= BDR and DR before exiting restart mode. However there is no way for it to determine who the BDR was before restar= t=20 using the pre-restart router lsa (and/or pre-restart network lsa). Or am = I=20 missing something? Actually why is it necessary to wait (i.e for exiting=20= restart mode) till it forms an adjaceny with BDR? Isn't it enough for it=20= wait till it forms an adjacency with DR? A similar issue arises with BDR restart as well. According to the same=20= clause it is supposed to wait till it forms adjacencies with all the=20 routers on the network. However it has no way of determining that it was=20= the BDR using just the pre-restart lsas. Thanks, Ramesh From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 10 00:48:52 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7R9F-0001s6-Jn for ospf-archive@megatron.ietf.org; Fri, 10 Feb 2006 00:48:52 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15434 for ; Fri, 10 Feb 2006 00:46:56 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <13.0002141C@wildebeest.ease.lsoft.com>; Fri, 10 Feb 2006 0:48:08 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99046294 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 10 Feb 2006 00:48:07 -0500 Received: from 203.199.83.133 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 10 Feb 2006 00:48:07 -0500 Received: (qmail 5132 invoked by uid 510); 10 Feb 2006 05:47:41 -0000 Received: from unknown (203.126.136.220) by rediffmail.com via HTTP; 10 feb 2006 05:47:41 -0000 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="Next_1139550461---0-203.199.83.133-5124" Message-ID: <20060210054741.5131.qmail@webmail43.rediffmail.com> Date: Fri, 10 Feb 2006 05:47:41 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: Re: Ospfv2 MIB To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: This is a multipart mime message --Next_1139550461---0-203.199.83.133-5124 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Acee,=0ATwo things:=0A1) If "ospfHostCfgAreaID" does not intends that behav= iour (i.e =0A creation of Area Entry) why was it brought into existence i= n =0A draft "draft-ietf-ospf-mib-update-07". Existing "ospfHostAreaID" = =0A was serving the purpose.=0A=0A2) But if it intends to allow "creatio= n of Area Entry", why is it so? =0A As you have pointed out it is analogo= us to ospfIfAreaId.=0A=0AThanks=0AVivek=0A=0A=0A=0A=0A=0A=0A=0A=0AOn Thu, 0= 9 Feb 2006 Acee Lindem wrote :=0A>Vivek Dubey wrote:=0A>=0A>>ospfHostCfgAre= aID OBJECT-TYPE SYNTAX AreaID MAX-ACCESS read-creat= e STATUS current DESCRIPTION "Allows the c= onfiguration of the Area the Host Entry is to be found within."= =0A>> Does that mean, this configuration results in the creation of= "Ospf Area Entry" if one does not exist. If so, why such a behaviour?=0A>= > =0A>Hi Vivek,=0A>My interpretation is that this should not create an are= a if the specified area doesn't exist.=0A>It is analogous to ospfIfAreaId f= or interfaces. I think trying to specify=0A>all the validation for read-cre= ate objects is a slippery slope.=0A>=0A>Thanks,=0A>Acee=0A>=0A>>Thanks=0A>>= Vivek=0A>>=0A>> =0A --Next_1139550461---0-203.199.83.133-5124 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0AAcee,
=0ATwo things:
=0A1) If "ospfHostCfgAreaID" doe= s not intends that behaviour (i.e
=0A  creation of Area Entry) wh= y was it brought into existence in 
=0A  draft  "d= raft-ietf-ospf-mib-update-07". Existing "ospfHostAreaID"&nbs= p;
=0A  was serving the purpose.
=0A
=0A2) But if it intend= s to allow "creation of Area Entry", why is it so?
=0A  = As you have pointed out it is analogous to ospfIfAreaId.
=0A
=0AThan= ks
=0AVivek
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
= =0AOn Thu, 09 Feb 2006 Acee Lindem wrote :
=0A>Vivek Dubey wrote:
= =0A>
=0A>>ospfHostCfgAreaID OBJECT-TYPE      &nb= sp; SYNTAX      AreaID        MAX-ACC= ESS  read-create        STATUS    &nbs= p; current        DESCRIPTION      &nb= sp;     "Allows the configuration of the Area the Host Entry= is            to be found within." =0A>><Vivek> Does that mean, this configuration results in the= creation of "Ospf Area Entry" if one does not exist.  If so= , why such a behaviour?
=0A>> 
=0A>Hi Vivek,
=0A>= ;My interpretation is that this should not create an area if the specified = area doesn't exist.
=0A>It is analogous to ospfIfAreaId for interface= s. I think trying to specify
=0A>all the validation for read-create o= bjects is a slippery slope.
=0A>
=0A>Thanks,
=0A>Acee
= =0A>
=0A>>Thanks
=0A>>Vivek
=0A>>
=0A>&= gt; 
=0A=0A

=0A

=0A=0A --Next_1139550461---0-203.199.83.133-5124-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 10 01:10:30 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7RUE-0002Bw-5P for ospf-archive@megatron.ietf.org; Fri, 10 Feb 2006 01:10:30 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16763 for ; Fri, 10 Feb 2006 01:08:46 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <9.00021480@wildebeest.ease.lsoft.com>; Fri, 10 Feb 2006 1:09:59 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99048363 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 10 Feb 2006 01:09:59 -0500 Received: from 61.144.161.53 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 10 Feb 2006 01:09:58 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUG00LUEJM1GV@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 10 Feb 2006 14:06:01 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUG00CA9JL8B6@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 10 Feb 2006 14:06:01 +0800 (CST) Received: from [10.18.4.125] by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IUG00345JNWYY@szxml01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 10 Feb 2006 14:07:09 +0800 (CST) MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) References: Message-ID: <43EC29E1.6050006@huawei.com> Date: Fri, 10 Feb 2006 11:21:29 +0530 Reply-To: Mailing List Sender: Mailing List From: Ashok Chandrashekar Holla Subject: Re: DROther/BDR graceful restart question To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT Hi Ramesh, For the first part: When a DROther comes up after restart, there is no need for it to 'remember' that it was DROther before restart. The restarting router learns the DR and BDR using the usual hello mechanism. This behavior is no different from a non graceful restart. When it runs the election algorithm, it will determine that it is currently DROther. Once this is done, it will complete forming adjacencies with DR and BDR of the network and then exit GR. From the perspective of learning the pre-restart topology, there is no need for a DROther to wait until it completes adj formation with both DR and BDR. However it is inevitable that this be done, since a helper router (DR and BDR) in some scenarios, will declare a 'Peer down' in their LSA if they see a flushed grace lsa before adjacency formation is complete (basic protocol behavior). For the second part: When a BDR undergoes GR, it will almost certainly lose its BDR status since BDR status is not maintained across GRs. So, when it comes up, it will run fresh election and the behavior is as per election algorithm (it may become a DROther). Hope it helps. - Ashok Ramesh Kandula wrote: >Hi All, > >Suppose a DROther router restarts gracefully on a broadcast network. >Before restart it has adjacencies with DR and BDR. According to clause in > >2.2.1 (RFC 3623), it is supposed to wait till it forms adjacencies with > >BDR and DR before exiting restart mode. > >However there is no way for it to determine who the BDR was before restar >t >using the pre-restart router lsa (and/or pre-restart network lsa). Or am >I >missing something? Actually why is it necessary to wait (i.e for exiting > >restart mode) till it forms an adjaceny with BDR? Isn't it enough for it > >wait till it forms an adjacency with DR? > >A similar issue arises with BDR restart as well. According to the same > >clause it is supposed to wait till it forms adjacencies with all the >routers on the network. However it has no way of determining that it was > >the BDR using just the pre-restart lsas. > >Thanks, >Ramesh > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 10 01:27:52 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Rky-0008Jn-9n for ospf-archive@megatron.ietf.org; Fri, 10 Feb 2006 01:27:52 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17667 for ; Fri, 10 Feb 2006 01:25:56 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <15.00021456@wildebeest.ease.lsoft.com>; Fri, 10 Feb 2006 1:27:09 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99048909 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 10 Feb 2006 01:27:09 -0500 Received: from 12.178.35.128 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 10 Feb 2006 01:27:09 -0500 Received: from mailblr1.engineering.netscaler.com ([10.102.1.9]) by mailsj.engineering.netscaler.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Feb 2006 22:23:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: DROther/BDR graceful restart question Thread-Index: AcYuCKY9LukwXNfKRA+4sQqNUxDQ6wAAkHAg X-OriginalArrivalTime: 10 Feb 2006 06:23:25.0027 (UTC) FILETIME=[7F7FCB30:01C62E0A] Message-ID: <6D975E431022374F9F7A298A511427B61936D5@mailblr1.engineering.netscaler.com> Date: Fri, 10 Feb 2006 11:57:01 +0530 Reply-To: Mailing List Sender: Mailing List From: Nitin Kakkar Subject: Re: DROther/BDR graceful restart question To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable Ashok> For the second part: When a BDR undergoes GR, it will almost certainly lose its BDR status since BDR status is not maintained across GRs. So, when it comes up, it will run fresh election and the behavior is as per election algorithm (it may become a DROther). >> Doesn't this defy the whole purpose of GR? Nitin -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Ashok Chandrashekar Holla Sent: Friday, February 10, 2006 11:21 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: DROther/BDR graceful restart question Hi Ramesh, For the first part: When a DROther comes up after restart, there is no need for it to=20 'remember' that it was DROther before restart. The restarting router=20 learns the DR and BDR using the usual hello mechanism. This behavior is no different from a non graceful restart. When it runs the election algorithm, it will determine that it is=20 currently DROther. Once this is done, it will complete forming=20 adjacencies with DR and BDR of the network and then exit GR. From the perspective of learning the pre-restart topology, there is no=20 need for a DROther to wait until it completes adj formation with both DR and BDR. However it is inevitable that this be done, since a helper=20 router (DR and BDR) in some scenarios, will declare a 'Peer down' in=20 their LSA if they see a flushed grace lsa before adjacency formation is=20 complete (basic protocol behavior). For the second part: When a BDR undergoes GR, it will almost certainly lose its BDR status=20 since BDR status is not maintained across GRs. So, when it comes up, it=20 will run fresh election and the behavior is as per election algorithm=20 (it may become a DROther). Hope it helps. - Ashok Ramesh Kandula wrote: >Hi All, > >Suppose a DROther router restarts gracefully on a broadcast network.=20 >Before restart it has adjacencies with DR and BDR. According to clause in >=20 >2.2.1 (RFC 3623), it is supposed to wait till it forms adjacencies with > >BDR and DR before exiting restart mode. > >However there is no way for it to determine who the BDR was before restar >t=20 >using the pre-restart router lsa (and/or pre-restart network lsa). Or am=20 >I=20 >missing something? Actually why is it necessary to wait (i.e for exiting=20 > >restart mode) till it forms an adjaceny with BDR? Isn't it enough for it=20 > >wait till it forms an adjacency with DR? > >A similar issue arises with BDR restart as well. According to the same=20 > >clause it is supposed to wait till it forms adjacencies with all the=20 >routers on the network. However it has no way of determining that it was=20 > >the BDR using just the pre-restart lsas. > >Thanks, >Ramesh > > =20 > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 10 01:40:38 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7RxO-0003RU-8k for ospf-archive@megatron.ietf.org; Fri, 10 Feb 2006 01:40:38 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18290 for ; Fri, 10 Feb 2006 01:38:55 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <7.00021456@wildebeest.ease.lsoft.com>; Fri, 10 Feb 2006 1:40:05 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99049321 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 10 Feb 2006 01:40:04 -0500 Received: from 61.144.161.55 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 10 Feb 2006 01:40:00 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUG00C8QLHT7O@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 10 Feb 2006 14:46:42 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUG00GJDLHT7X@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 10 Feb 2006 14:46:41 +0800 (CST) Received: from [10.18.4.125] by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IUG003KGLWIYY@szxml01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 10 Feb 2006 14:55:31 +0800 (CST) MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) References: <6D975E431022374F9F7A298A511427B61936D5@mailblr1.engineering.netscaler.com> Message-ID: <43EC3537.5020904@huawei.com> Date: Fri, 10 Feb 2006 12:09:51 +0530 Reply-To: Mailing List Sender: Mailing List From: Ashok Chandrashekar Holla Subject: Re: DROther/BDR graceful restart question To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <6D975E431022374F9F7A298A511427B61936D5@mailblr1.engineering.netscaler.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT Hi Nitin, Although a modification was suggested in http://www.ietf.org/internet-drafts/draft-holla-ospf-update-graceful-restart-00.txt , after the discussions in this forum, I now feel that the existing mechanism need not be changed :). Retaining BDR status is not necessary and provides little value addition (only the avoidance of the linear time bound election algorithm overhead). - Ashok Nitin Kakkar wrote: >Ashok> For the second part: >When a BDR undergoes GR, it will almost certainly lose its BDR status >since BDR status is not maintained across GRs. So, when it comes up, it >will run fresh election and the behavior is as per election algorithm >(it may become a DROther). > > > >>>Doesn't this defy the whole purpose of GR? >>> >>> >Nitin > > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Ashok >Chandrashekar Holla >Sent: Friday, February 10, 2006 11:21 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: DROther/BDR graceful restart question > >Hi Ramesh, > >For the first part: >When a DROther comes up after restart, there is no need for it to >'remember' that it was DROther before restart. The restarting router >learns the DR and BDR using the usual hello mechanism. This behavior is > >no different from a non graceful restart. >When it runs the election algorithm, it will determine that it is >currently DROther. Once this is done, it will complete forming >adjacencies with DR and BDR of the network and then exit GR. > > From the perspective of learning the pre-restart topology, there is no >need for a DROther to wait until it completes adj formation with both DR > >and BDR. However it is inevitable that this be done, since a helper >router (DR and BDR) in some scenarios, will declare a 'Peer down' in >their LSA if they see a flushed grace lsa before adjacency formation is >complete (basic protocol behavior). > >For the second part: >When a BDR undergoes GR, it will almost certainly lose its BDR status >since BDR status is not maintained across GRs. So, when it comes up, it >will run fresh election and the behavior is as per election algorithm >(it may become a DROther). > >Hope it helps. >- Ashok > > >Ramesh Kandula wrote: > > > >>Hi All, >> >>Suppose a DROther router restarts gracefully on a broadcast network. >>Before restart it has adjacencies with DR and BDR. According to clause >> >> >in > > >>2.2.1 (RFC 3623), it is supposed to wait till it forms adjacencies with >> >> > > > >>BDR and DR before exiting restart mode. >> >>However there is no way for it to determine who the BDR was before >> >> >restar > > >>t >>using the pre-restart router lsa (and/or pre-restart network lsa). Or >> >> >am > > >>I >>missing something? Actually why is it necessary to wait (i.e for >> >> >exiting > > >>restart mode) till it forms an adjaceny with BDR? Isn't it enough for >> >> >it > > >>wait till it forms an adjacency with DR? >> >>A similar issue arises with BDR restart as well. According to the same >> >>clause it is supposed to wait till it forms adjacencies with all the >>routers on the network. However it has no way of determining that it >> >> >was > > >>the BDR using just the pre-restart lsas. >> >>Thanks, >>Ramesh >> >> >> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 10 07:34:11 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7XTX-0001Hg-3l for ospf-archive@megatron.ietf.org; Fri, 10 Feb 2006 07:34:11 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15372 for ; Fri, 10 Feb 2006 07:32:26 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <9.00021625@wildebeest.ease.lsoft.com>; Fri, 10 Feb 2006 7:33:25 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99065945 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 10 Feb 2006 07:33:24 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 10 Feb 2006 07:33:24 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 10 Feb 2006 04:33:24 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,103,1139212800"; d="scan'208"; a="21598186:sNHT25185800" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1ACXIPO025119; Fri, 10 Feb 2006 07:33:21 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Feb 2006 07:33:18 -0500 Received: from [10.82.216.81] ([10.82.216.81]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Feb 2006 07:33:18 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20060210054741.5131.qmail@webmail43.rediffmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Feb 2006 12:33:18.0364 (UTC) FILETIME=[2BC245C0:01C62E3E] Message-ID: <43EC880D.7090509@cisco.com> Date: Fri, 10 Feb 2006 07:33:17 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Ospfv2 MIB Comments: To: Dan Joyal , Piotr Galecki To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20060210054741.5131.qmail@webmail43.rediffmail.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Vivek Dubey wrote: >Acee, >Two things: >1) If "ospfHostCfgAreaID" does not intends that behaviour (i.e > creation of Area Entry) why was it brought into existence in > draft "draft-ietf-ospf-mib-update-07". Existing "ospfHostAreaID" > was serving the purpose. > >2) But if it intends to allow "creation of Area Entry", why is it so? > As you have pointed out it is analogous to ospfIfAreaId. > > Vivek, It is definitely analogous to ospfIfAreaId so it will exhibit the same behavior. I'll defer to the MIB authors. Thanks, Acee >Thanks >Vivek > > > > > > > > >On Thu, 09 Feb 2006 Acee Lindem wrote : > > >>Vivek Dubey wrote: >> >> >> >>>ospfHostCfgAreaID OBJECT-TYPE SYNTAX AreaID MAX-ACCESS read-create STATUS current DESCRIPTION "Allows the configuration of the Area the Host Entry is to be found within." >>> Does that mean, this configuration results in the creation of "Ospf Area Entry" if one does not exist. If so, why such a behaviour? >>> >>> >>> >>Hi Vivek, >>My interpretation is that this should not create an area if the specified area doesn't exist. >>It is analogous to ospfIfAreaId for interfaces. I think trying to specify >>all the validation for read-create objects is a slippery slope. >> >>Thanks, >>Acee >> >> >> >>>Thanks >>>Vivek >>> >>> >>> >>> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 10 09:59:41 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7ZkL-00029X-7z for ospf-archive@megatron.ietf.org; Fri, 10 Feb 2006 09:59:41 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25682 for ; Fri, 10 Feb 2006 09:57:57 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <13.000217CC@wildebeest.ease.lsoft.com>; Fri, 10 Feb 2006 9:59:07 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99073657 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 10 Feb 2006 09:59:07 -0500 Received: from 47.140.192.55 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 10 Feb 2006 09:59:07 -0500 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k1AEx5E28311 for ; Fri, 10 Feb 2006 09:59:05 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: Ospfv2 MIB Thread-Index: AcYuPjhEkBPmc1YFTR61WitkPL00VAAEa/fQ Message-ID: <4B7DAC3FEFD35D4A96BDD0116990501403365D34@zrtphxm1.corp.nortel.com> Date: Fri, 10 Feb 2006 09:58:50 -0500 Reply-To: Mailing List Sender: Mailing List From: Daniel Joyal Subject: Re: Ospfv2 MIB To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable See RFC 2328, section C.7. The existing ospfHostAreaID object was read-only. The OSPFv2 RFC calls for it to be configurable. Backwards compatibility rules prevented the syntax of ospfHostAreaID to be changed to read-create so ospfHostCfgAreaID was added. This change was originally requested by John Moy. -Dan > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On=20 > Behalf Of Acee Lindem > Sent: Friday, February 10, 2006 7:33 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Ospfv2 MIB >=20 >=20 > Vivek Dubey wrote: >=20 > >Acee, > >Two things: > >1) If "ospfHostCfgAreaID" does not intends that behaviour (i.e=20 > > creation of Area Entry) why was it brought into existence in =20 > > draft "draft-ietf-ospf-mib-update-07". Existing=20 > "ospfHostAreaID" =20 > > was serving the purpose. > > > >2) But if it intends to allow "creation of Area Entry", why=20 > is it so?=20 > > As you have pointed out it is analogous to ospfIfAreaId. > > =20 > > > Vivek, > It is definitely analogous to ospfIfAreaId so it will exhibit=20 > the same=20 > behavior. I'll defer to the > MIB authors. >=20 > Thanks, > Acee >=20 > >Thanks > >Vivek > > > > > > > > > > > > > > > > > >On Thu, 09 Feb 2006 Acee Lindem wrote : > > =20 > > > >>Vivek Dubey wrote: > >> > >> =20 > >> > >>>ospfHostCfgAreaID OBJECT-TYPE SYNTAX AreaID =20 > MAX-ACCESS read-create STATUS current =20 > DESCRIPTION "Allows the configuration of=20 > the Area the Host Entry is to be found within."=20 > >>> Does that mean, this configuration results in the=20 > creation of=20 > >>>"Ospf Area Entry" if one does not exist. If so, why such=20 > a behaviour? > >>>=20 > >>> =20 > >>> > >>Hi Vivek, > >>My interpretation is that this should not create an area if the=20 > >>specified area doesn't exist. It is analogous to ospfIfAreaId for=20 > >>interfaces. I think trying to specify all the validation for=20 > >>read-create objects is a slippery slope. > >> > >>Thanks, > >>Acee > >> > >> =20 > >> > >>>Thanks > >>>Vivek > >>> > >>>=20 > >>> =20 > >>> > > > > =20 > > >=20 >=20 From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 10 18:03:31 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7hIZ-0006Dc-Qx for ospf-archive@megatron.ietf.org; Fri, 10 Feb 2006 18:03:31 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09544 for ; Fri, 10 Feb 2006 18:01:39 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <14.00021F43@wildebeest.ease.lsoft.com>; Fri, 10 Feb 2006 18:03:21 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99078070 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 10 Feb 2006 11:38:42 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 10 Feb 2006 11:38:42 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 10 Feb 2006 08:38:42 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,103,1139212800"; d="scan'208"; a="21616372:sNHT22889224" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k1AGc56n016628 for ; Fri, 10 Feb 2006 11:38:40 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Feb 2006 11:38:36 -0500 Received: from [10.82.216.81] ([10.82.216.81]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Feb 2006 11:38:35 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) 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 X-OriginalArrivalTime: 10 Feb 2006 16:38:35.0909 (UTC) FILETIME=[70196B50:01C62E60] Message-ID: <43ECC18B.4030606@cisco.com> Date: Fri, 10 Feb 2006 11:38:35 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: DROther/BDR graceful restart question To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Hi Ramesh, Ramesh Kandula wrote: >Hi All, > >Suppose a DROther router restarts gracefully on a broadcast network. >Before restart it has adjacencies with DR and BDR. According to clause in > >2.2.1 (RFC 3623), it is supposed to wait till it forms adjacencies with > >BDR and DR before exiting restart mode. > >However there is no way for it to determine who the BDR was before restar >t >using the pre-restart router lsa (and/or pre-restart network lsa). Or am >I >missing something? Actually why is it necessary to wait (i.e for exiting > >restart mode) till it forms an adjaceny with BDR? Isn't it enough for it > >wait till it forms an adjacency with DR? > > You are correct. Only the DR adjacency needs to be reformed. We'll clarify if we ever respin this RFC. The key point is that your pre-restart LSAs must match your current state prior to existing graceful restart normally. Thanks, Acee >A similar issue arises with BDR restart as well. According to the same > >clause it is supposed to wait till it forms adjacencies with all the >routers on the network. However it has no way of determining that it was > >the BDR using just the pre-restart lsas. > >Thanks, >Ramesh > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 10 18:03:31 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7hIZ-0006Da-QM for ospf-archive@megatron.ietf.org; Fri, 10 Feb 2006 18:03:31 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09542 for ; Fri, 10 Feb 2006 18:01:38 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <8.00021E07@wildebeest.ease.lsoft.com>; Fri, 10 Feb 2006 18:02:41 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99074815 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 10 Feb 2006 10:17:47 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 10 Feb 2006 10:17:47 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 10 Feb 2006 10:16:48 -0500 X-IronPort-AV: i="4.02,103,1139202000"; d="scan'208"; a="82125899:sNHT31727216" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k1AFGI6l001076 for ; Fri, 10 Feb 2006 10:16:45 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Feb 2006 10:16:44 -0500 Received: from [10.82.216.81] ([10.82.216.81]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Feb 2006 10:16:44 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <4B7DAC3FEFD35D4A96BDD0116990501403365D34@zrtphxm1.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Feb 2006 15:16:44.0305 (UTC) FILETIME=[008E2010:01C62E55] Message-ID: <43ECAE5B.3040205@cisco.com> Date: Fri, 10 Feb 2006 10:16:43 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Ospfv2 MIB To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <4B7DAC3FEFD35D4A96BDD0116990501403365D34@zrtphxm1.corp.nortel.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Daniel Joyal wrote: >See RFC 2328, section C.7. The existing ospfHostAreaID >object was read-only. The OSPFv2 RFC calls for it to >be configurable. Backwards compatibility rules prevented >the syntax of ospfHostAreaID to be changed to read-create >so ospfHostCfgAreaID was added. This change was originally >requested by John Moy. > > Dan, That's what I figured. So, in summary, it is read-create to allow its configuration but is not meant to create an area if the specified one doesn't exist. Correct? Thanks, Acee >-Dan > > > >>-----Original Message----- >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On >>Behalf Of Acee Lindem >>Sent: Friday, February 10, 2006 7:33 AM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Re: Ospfv2 MIB >> >> >>Vivek Dubey wrote: >> >> >> >>>Acee, >>>Two things: >>>1) If "ospfHostCfgAreaID" does not intends that behaviour (i.e >>> creation of Area Entry) why was it brought into existence in >>> draft "draft-ietf-ospf-mib-update-07". Existing >>> >>> >>"ospfHostAreaID" >> >> >>> was serving the purpose. >>> >>>2) But if it intends to allow "creation of Area Entry", why >>> >>> >>is it so? >> >> >>> As you have pointed out it is analogous to ospfIfAreaId. >>> >>> >>> >>> >>Vivek, >>It is definitely analogous to ospfIfAreaId so it will exhibit >>the same >>behavior. I'll defer to the >>MIB authors. >> >>Thanks, >>Acee >> >> >> >>>Thanks >>>Vivek >>> >>> >>> >>> >>> >>> >>> >>> >>>On Thu, 09 Feb 2006 Acee Lindem wrote : >>> >>> >>> >>> >>>>Vivek Dubey wrote: >>>> >>>> >>>> >>>> >>>> >>>>>ospfHostCfgAreaID OBJECT-TYPE SYNTAX AreaID >>>>> >>>>> >> MAX-ACCESS read-create STATUS current >> DESCRIPTION "Allows the configuration of >>the Area the Host Entry is to be found within." >> >> >>>>> Does that mean, this configuration results in the >>>>> >>>>> >>creation of >> >> >>>>>"Ospf Area Entry" if one does not exist. If so, why such >>>>> >>>>> >>a behaviour? >> >> >>>>> >>>>> >>>>> >>>>> >>>>Hi Vivek, >>>>My interpretation is that this should not create an area if the >>>>specified area doesn't exist. It is analogous to ospfIfAreaId for >>>>interfaces. I think trying to specify all the validation for >>>>read-create objects is a slippery slope. >>>> >>>>Thanks, >>>>Acee >>>> >>>> >>>> >>>> >>>> >>>>>Thanks >>>>>Vivek >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> >>> >>> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 10 18:05:04 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7hK3-0006Z6-KS for ospf-archive@megatron.ietf.org; Fri, 10 Feb 2006 18:05:04 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09629 for ; Fri, 10 Feb 2006 18:03:18 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <9.00021F68@wildebeest.ease.lsoft.com>; Fri, 10 Feb 2006 18:04:00 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99085184 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 10 Feb 2006 14:25:42 -0500 Received: from 209.119.1.41 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 10 Feb 2006 14:25:42 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by LIME.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.000775DB@LIME.ease.lsoft.com>; Fri, 10 Feb 2006 14:24:36 -0500 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Message-ID: Date: Fri, 10 Feb 2006 14:25:41 -0500 Reply-To: Mailing List Sender: Mailing List From: vishnuvardhan B Subject: Re: Idea behind DR copying the list of prefixes in the Link-LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable Hi, I am not able to understand the idea behind DR copying the list of=20 prefixes in the Link-LSA=20 RFC2740 sec 3.4.3.7: 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.=20 Since anyway all the routers describe about the prefixes in their own=20 intra-area prefix LSA's. So what is the advantage in advertising all the=20= prefixes in the link-lsa's by DR. Any replies will be most helpful. Reagards, Vishnu=20=20 From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 10 18:05:06 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7hK6-0006Zs-O9 for ospf-archive@megatron.ietf.org; Fri, 10 Feb 2006 18:05:06 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09631 for ; Fri, 10 Feb 2006 18:03:19 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <11.00021F8D@wildebeest.ease.lsoft.com>; Fri, 10 Feb 2006 18:04:21 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99091773 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 10 Feb 2006 16:51:34 -0500 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 10 Feb 2006 16:51:15 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k1ALpEgL024797 for ; Fri, 10 Feb 2006 16:51:15 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA21478 for ; Fri, 10 Feb 2006 16:51:15 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Fri, 10 Feb 2006 16:51:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <5551AD75D2C0BC459A85A2CEFAE4F80050C9C4@usvissfp01.win.marconi.com> Date: Fri, 10 Feb 2006 16:51:03 -0500 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: Cost calculating in the OSPF area To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: -> I think I was wrong when I specified my question. I'm -> looking for some tool or program , which calculate shortest path. -> Every cost on the links is defined but I'd like to know if -> something happened (changed ) when I add a new router into system. Yes, there are programs to compute the difference in SPT for a single change in topology (like an edge metric change, adding a new node etc.) -> I know it is matter of Dijsktra's algorithm, all I'm asking if This is called Dynamic Shortest Paths in algorithms literature. You could also do Static Dijkstra from scratch with the change in topology and compare new SPT vs old SPT. But that is lot of work. -> somenone's using some program to calulate the shortest path For a simulation and evaluation of different dynamic shortest path algorithms: http://www.dis.uniroma1.it/~demetres/experim/dsp/ Original version of Ramalingam/Rep's algorithm is called, "An incremental algorithm for a generalization of the shortest path problem". http://citeseer.ist.psu.edu/ramalingam92incremental.html Hope this helps, Venkata. From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 10 18:05:07 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7hK7-0006aD-9B for ospf-archive@megatron.ietf.org; Fri, 10 Feb 2006 18:05:07 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09636 for ; Fri, 10 Feb 2006 18:03:22 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <1.00021F1E@wildebeest.ease.lsoft.com>; Fri, 10 Feb 2006 18:04:27 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99093765 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 10 Feb 2006 17:44:57 -0500 Received: from 171.68.10.86 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 10 Feb 2006 17:44:56 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 10 Feb 2006 14:44:37 -0800 X-IronPort-AV: i="4.02,103,1139212800"; d="scan'208"; a="1775405438:sNHT1439021050" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1AMiYjt002567; Fri, 10 Feb 2006 14:44:34 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Feb 2006 17:44:33 -0500 Received: from [10.82.216.81] ([10.82.216.81]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Feb 2006 17:44:33 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Feb 2006 22:44:33.0398 (UTC) FILETIME=[8FC85960:01C62E93] Message-ID: <43ED1750.8000607@cisco.com> Date: Fri, 10 Feb 2006 17:44:32 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Call for Volunteers to Review BMWG Documents Comments: cc: Al Morton , Kevin Dubray To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit The Benchmarking WG has requested that we review a set of drafts defining measurement of IGP Data Plane Convergence. They have completed their review and are looking for our input. Please let me know if you would have time to review the 3 as a package and pass on comments to the OSPF and BMWG lists. You probably should subscribe to the bmwg list (bmwg@ietf.org) for at least the duration of the review. The drafts are: Benchmarking Methodology for IGP Data Plane Route Convergence http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-bmwg-igp-dataplane-conv-meth-09.txt Terminology for Benchmarking IGP Data Plane Route Convergence http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-bmwg-igp-dataplane-conv-term-09.txt Benchmarking Applicability for IGP Data Plane Route Convergence http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-bmwg-igp-dataplane-conv-app-09.txt Thanks, Acee From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 10 21:57:59 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7kxS-0005Db-UI for ospf-archive@megatron.ietf.org; Fri, 10 Feb 2006 21:57:58 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02060 for ; Fri, 10 Feb 2006 21:56:07 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <8.000221B7@wildebeest.ease.lsoft.com>; Fri, 10 Feb 2006 21:57:17 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99112598 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 10 Feb 2006 21:57:17 -0500 Received: from 171.68.10.86 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 10 Feb 2006 21:57:17 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 10 Feb 2006 18:57:18 -0800 X-IronPort-AV: i="4.02,104,1139212800"; d="scan'208"; a="1775458629:sNHT30012752" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k1B2vGc1019548 for ; Fri, 10 Feb 2006 18:57:16 -0800 (PST) Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Feb 2006 21:57:15 -0500 Received: from [10.25.187.130] ([10.25.187.130]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Feb 2006 21:57:15 -0500 User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) 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 X-OriginalArrivalTime: 11 Feb 2006 02:57:15.0422 (UTC) FILETIME=[DD0D9BE0:01C62EB6] Message-ID: <43ED5289.5000009@cisco.com> Date: Fri, 10 Feb 2006 20:57:13 -0600 Reply-To: Mailing List Sender: Mailing List From: Paul Wells Subject: Re: Idea behind DR copying the list of prefixes in the Link-LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Hi Vishnu, Only prefixes associated with the router itself (e.g. loopback interfaces) and attached stub (non-transit) network segments are advertised in the intra-area prefix LSAs associated with the router LSAs. Prefixes associated with transit network segments are advertised in the intra-area prefix LSAs originated by the DR and associated with the type-2 LSA for that segment. The way the DR finds out about the transit link prefixes is by looking at the link LSAs. Regards, Paul vishnuvardhan B wrote: > Hi, > I am not able to understand the idea behind DR copying the list of > prefixes in the Link-LSA > RFC2740 sec 3.4.3.7: > 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. > Since anyway all the routers describe about the prefixes in their own > intra-area prefix LSA's. So what is the advantage in advertising all the > > prefixes in the link-lsa's by DR. Any replies will be most helpful. > Reagards, > Vishnu From owner-ospf@PEACH.EASE.LSOFT.COM Sat Feb 11 01:11:52 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7nz6-0008GJ-Fy for ospf-archive@megatron.ietf.org; Sat, 11 Feb 2006 01:11:52 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12206 for ; Sat, 11 Feb 2006 01:10:07 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <0.00022570@wildebeest.ease.lsoft.com>; Sat, 11 Feb 2006 1:11:18 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99122279 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 11 Feb 2006 01:11:18 -0500 Received: from 203.199.83.146 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 11 Feb 2006 01:11:16 -0500 Received: (qmail 22317 invoked by uid 510); 11 Feb 2006 06:10:51 -0000 Received: from unknown (203.126.136.220) by rediffmail.com via HTTP; 11 feb 2006 06:10:51 -0000 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="Next_1139638251---0-203.199.83.146-22313" Message-ID: <20060211061051.22316.qmail@webmail24.rediffmail.com> Date: Sat, 11 Feb 2006 06:10:51 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: Re: Ospfv2 MIB To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: This is a multipart mime message --Next_1139638251---0-203.199.83.146-22313 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dan,=0AThanks for the input.=0ADraft history created the confusion:=0Ahttp:= //tools.ietf.org/wg/ospf/draft-ietf-ospf-mib-update/draft-ietf-ospf-mib-upd= ate-07-from-06.diff.html=0A=0AFurther, could we rephrase the description of= ospfHostCfgAreaID from:=0A=0A"Allows the configuration of the Area the Hos= t Entry is =0Ato be found within." =0A=0ATO=0A=0A"The OSPF area to which t= he host belongs" as described in RFC 2328.=0A=0A Current description= helps in creating the impression that=0A it "intends to configure t= he Area"=0A=0A-Vivek=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0AOn Fri, 10 Feb 2= 006 Acee Lindem wrote :=0A>Daniel Joyal wrote:=0A>=0A>>See RFC 2328, sectio= n C.7. The existing ospfHostAreaID=0A>>object was read-only. The OSPFv2 RFC= calls for it to=0A>>be configurable. Backwards compatibility rules prevent= ed=0A>>the syntax of ospfHostAreaID to be changed to read-create=0A>>so osp= fHostCfgAreaID was added. This change was originally=0A>>requested by John = Moy.=0A>> =0A>Dan,=0A>That's what I figured. So, in summary, it is read-c= reate to allow its configuration=0A>but is not meant to create an area if t= he specified one doesn't exist. Correct?=0A>Thanks,=0A>Acee=0A>=0A>>-Dan=0A= >>=0A>> =0A>>>-----Original Message-----=0A>>> From: Mailing List [mailto:= OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee Lindem=0A>>>Sent: Friday, Febr= uary 10, 2006 7:33 AM=0A>>>To: OSPF@PEACH.EASE.LSOFT.COM=0A>>>Subject: Re: = Ospfv2 MIB=0A>>>=0A>>>=0A>>>Vivek Dubey wrote:=0A>>>=0A>>> =0A>>>>Acee,= =0A>>>>Two things:=0A>>>>1) If "ospfHostCfgAreaID" does not intends that be= haviour (i.e creation of Area Entry) why was it brought into existence in = draft "draft-ietf-ospf-mib-update-07". Existing =0A>>>"ospfHostArea= ID" =0A>>>> was serving the purpose.=0A>>>>=0A>>>>2) But if it intends= to allow "creation of Area Entry", why =0A>>>is it so? =0A>>>> As= you have pointed out it is analogous to ospfIfAreaId.=0A>>>>=0A>>>>=0A>>>>= =0A>>>Vivek,=0A>>>It is definitely analogous to ospfIfAreaId so it wi= ll exhibit the same behavior. I'll defer to the=0A>>>MIB authors.=0A>>>=0A>= >>Thanks,=0A>>>Acee=0A>>>=0A>>> =0A>>>>Thanks=0A>>>>Vivek=0A>>>>=0A>>>>= =0A>>>>=0A>>>>=0A>>>>=0A>>>>=0A>>>>=0A>>>>=0A>>>>On Thu, 09 Feb 2006 Acee L= indem wrote :=0A>>>>=0A>>>>=0A>>>> =0A>>>>>Vivek Dubey wrote:=0A>>>>>= =0A>>>>> =0A>>>>> =0A>>>>>>ospfHostCfgAreaID OBJECT-TYPE S= YNTAX AreaID =0A>>> MAX-ACCESS read-create = STATUS current DESCRIPTION "Allows the configuratio= n of the Area the Host Entry is to be found within." =0A>>>>= >> Does that mean, this configuration results in the =0A>>>= creation of =0A>>>>>>"Ospf Area Entry" if one does not exist. If so, wh= y such =0A>>>a behaviour?=0A>>> =0A>>>>>> =0A>>>>>> = =0A>>>>>Hi Vivek,=0A>>>>>My interpretation is that this should not create= an area if the specified area doesn't exist. It is analogous to ospfIfArea= Id for interfaces. I think trying to specify all the validation for read-cr= eate objects is a slippery slope.=0A>>>>>=0A>>>>>Thanks,=0A>>>>>Acee=0A>>>>= >=0A>>>>> =0A>>>>> =0A>>>>>>Thanks=0A>>>>>>Vivek=0A>>>>>>=0A>>>>>>= =0A>>>>>> =0A>>>>>> =0A>>>>=0A>>>>=0A>>>> =0A>>> =0A>>= =0A>> =0A --Next_1139638251---0-203.199.83.146-22313 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0ADan,
=0AThanks for the input.
=0ADraft history created the conf= usion:
=0Ahttp://tools.ietf.org/wg/ospf/draft-ietf-ospf-mib-update/draft= -ietf-ospf-mib-update-07-from-06.diff.html
=0A
=0AFurther, could we r= ephrase the description of ospfHostCfgAreaID from:
=0A
=0A"Allow= s the configuration of the Area the Host Entry is 
=0Ato be found = within."
=0A
=0ATO
=0A
=0A"The OSPF area to which th= e host belongs" as described in RFC 2328.
=0A
=0A<vivek> C= urrent description helps in creating the impression that
=0A   = ;     it "intends to configure the Area"
=0A
=0A-= Vivek
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A
=0A=
=0A
=0A
=0AOn Fri, 10 Feb 2006 Acee Lindem wrote :
=0A>Dani= el Joyal wrote:
=0A>
=0A>>See RFC 2328, section C.7. The exi= sting ospfHostAreaID
=0A>>object was read-only. The OSPFv2 RFC cal= ls for it to
=0A>>be configurable. Backwards compatibility rules p= revented
=0A>>the syntax of ospfHostAreaID to be changed to read-c= reate
=0A>>so ospfHostCfgAreaID was added. This change was origina= lly
=0A>>requested by John Moy.
=0A>> 
=0A>Da= n,
=0A>That's what I figured.  So, in summary, it is read-create= to allow its configuration
=0A>but is not meant to create an area if= the specified one doesn't exist. Correct?
=0A>Thanks,
=0A>Acee=
=0A>
=0A>>-Dan
=0A>>
=0A>> 
=0A&= gt;>>-----Original Message-----
=0A>>> From: Mailing List= [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee Lindem
=0A>>= >Sent: Friday, February 10, 2006 7:33 AM
=0A>>>To: OSPF@PEAC= H.EASE.LSOFT.COM
=0A>>>Subject: Re: Ospfv2 MIB
=0A>>&g= t;
=0A>>>
=0A>>>Vivek Dubey wrote:
=0A>>&g= t;
=0A>>>   
=0A>>>>Acee,
=0A>&= gt;>>Two things:
=0A>>>>1) If "ospfHostCfgAreaID&= quot; does not intends that behaviour (i.e  creation of Area Entry) wh= y was it brought into existence in  draft  "draft-ietf-ospf= -mib-update-07". Existing     
=0A>>>"= ;ospfHostAreaID"   
=0A>>>>  was servi= ng the purpose.
=0A>>>>
=0A>>>>2) But if it i= ntends to allow "creation of Area Entry", why     =
=0A>>>is it so?   
=0A>>>>  As= you have pointed out it is analogous to ospfIfAreaId.
=0A>>>&g= t;
=0A>>>>
=0A>>>>     
= =0A>>>Vivek,
=0A>>>It is definitely analogous to ospfI= fAreaId so it will exhibit the same behavior. I'll defer to the
=0A>&= gt;>MIB authors.
=0A>>>
=0A>>>Thanks,
=0A>= >>Acee
=0A>>>
=0A>>>   
=0A>= >>>Thanks
=0A>>>>Vivek
=0A>>>>
= =0A>>>>
=0A>>>>
=0A>>>>
=0A>= ;>>>
=0A>>>>
=0A>>>>
=0A>>&= gt;>
=0A>>>>On Thu, 09 Feb 2006 Acee Lindem wrote :
= =0A>>>>
=0A>>>>
=0A>>>>  &nb= sp;  
=0A>>>>>Vivek Dubey wrote:
=0A>>>= >>
=0A>>>>> 
=0A>>>>> = ;      
=0A>>>>>>ospfHostCfgAreaID OBJ= ECT-TYPE        SYNTAX      AreaID&nbs= p;        
=0A>>>      MA= X-ACCESS  read-create        STATUS   =   current        DESCRIPTION     =       "Allows the configuration of the Area the Host E= ntry is            to be found within."=    
=0A>>>>>><Vivek> Does that mean, = this configuration results in the         
=0A= >>>creation of   
=0A>>>>>>"O= spf Area Entry" if one does not exist.  If so, why such  &nb= sp;      
=0A>>>a behaviour?
=0A>>>=    
=0A>>>>>>   
=0A>>= >>>>         
=0A>>>>&= gt;Hi Vivek,
=0A>>>>>My interpretation is that this shoul= d not create an area if the specified area doesn't exist. It is analogous t= o ospfIfAreaId for interfaces. I think trying to specify all the validation= for read-create objects is a slippery slope.
=0A>>>>>=0A>>>>>Thanks,
=0A>>>>>Acee
=0A>&g= t;>>>
=0A>>>>> 
=0A>>>>>= ;       
=0A>>>>>>Thanks
=0A&g= t;>>>>>Vivek
=0A>>>>>>
=0A>>&g= t;>>>
=0A>>>>>>   
=0A>>= >>>>         
=0A>>>><= BR>=0A>>>>
=0A>>>>     
=0A&g= t;>>   
=0A>>
=0A>> 
=0A=0A

= =0A

=0A=0A --Next_1139638251---0-203.199.83.146-22313-- From owner-ospf@PEACH.EASE.LSOFT.COM Sat Feb 11 17:50:55 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F83Zu-0001R9-UJ for ospf-archive@megatron.ietf.org; Sat, 11 Feb 2006 17:50:54 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04405 for ; Sat, 11 Feb 2006 17:49:10 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <4.000231FB@wildebeest.ease.lsoft.com>; Sat, 11 Feb 2006 17:50:20 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99163174 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 11 Feb 2006 17:50:20 -0500 Received: from 64.233.162.202 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 11 Feb 2006 17:50:20 -0500 Received: by zproxy.gmail.com with SMTP id f1so703089nzc for ; Sat, 11 Feb 2006 14:50:20 -0800 (PST) Received: by 10.37.12.45 with SMTP id p45mr1042294nzi; Sat, 11 Feb 2006 14:50:19 -0800 (PST) Received: by 10.36.141.11 with HTTP; Sat, 11 Feb 2006 14:50:19 -0800 (PST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1580_17908079.1139698219704" Message-ID: <45f8514d0602111450h416a3c82v4f589130308f59b3@mail.gmail.com> Date: Sat, 11 Feb 2006 14:50:19 -0800 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: OSPF WG Meeting in Dallas (IETF 65) To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: ------=_Part_1580_17908079.1139698219704 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Howdy Folks, The IETF meeting is coming up. If you have drafts that you would like to present at the OSPF session, please unicast Acee and me. Best Regards, --rohit. ------=_Part_1580_17908079.1139698219704 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Howdy Folks,

The IETF meeting is coming up. If you have drafts that = you would like to present at the OSPF session, please unicast Acee and me.<= br>
Best Regards,
--rohit.
------=_Part_1580_17908079.1139698219704-- From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 13 10:50:38 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8fyF-0004Uq-Rc for ospf-archive@megatron.ietf.org; Mon, 13 Feb 2006 10:50:38 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02310 for ; Mon, 13 Feb 2006 10:48:50 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <10.0002523E@wildebeest.ease.lsoft.com>; Mon, 13 Feb 2006 10:50:04 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99302315 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 13 Feb 2006 10:50:03 -0500 Received: from 47.129.242.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 13 Feb 2006 10:50:03 -0500 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k1DFo0r17778 for ; Mon, 13 Feb 2006 10:50:01 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: Ospfv2 MIB Thread-Index: AcYuliNkZ3uYqvpKT5G22GZ09bv4oACHrJFg Message-ID: <4B7DAC3FEFD35D4A96BDD0116990501403365D38@zrtphxm1.corp.nortel.com> Date: Mon, 13 Feb 2006 10:49:48 -0500 Reply-To: Mailing List Sender: Mailing List From: Daniel Joyal Subject: Re: Ospfv2 MIB To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On=20 > Behalf Of Acee Lindem > Sent: Friday, February 10, 2006 10:17 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Ospfv2 MIB >=20 >=20 > Daniel Joyal wrote: >=20 > >See RFC 2328, section C.7. The existing ospfHostAreaID > >object was read-only. The OSPFv2 RFC calls for it to > >be configurable. Backwards compatibility rules prevented > >the syntax of ospfHostAreaID to be changed to read-create > >so ospfHostCfgAreaID was added. This change was originally=20 > requested by=20 > >John Moy. > > =20 > > > Dan, > That's what I figured. So, in summary, it is read-create to=20 > allow its=20 > configuration > but is not meant to create an area if the specified one=20 > doesn't exist.=20 > Correct? Yes, that's correct. -Dan > Thanks, > Acee >=20 > >-Dan > > > > =20 > > > >>-----Original Message----- > >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On > >>Behalf Of Acee Lindem > >>Sent: Friday, February 10, 2006 7:33 AM > >>To: OSPF@PEACH.EASE.LSOFT.COM > >>Subject: Re: Ospfv2 MIB > >> > >> > >>Vivek Dubey wrote: > >> > >> =20 > >> > >>>Acee, > >>>Two things: > >>>1) If "ospfHostCfgAreaID" does not intends that behaviour (i.e > >>> creation of Area Entry) why was it brought into existence in =20 > >>> draft "draft-ietf-ospf-mib-update-07". Existing=20 > >>> =20 > >>> > >>"ospfHostAreaID" > >> =20 > >> > >>> was serving the purpose. > >>> > >>>2) But if it intends to allow "creation of Area Entry", why > >>> =20 > >>> > >>is it so? > >> =20 > >> > >>> As you have pointed out it is analogous to ospfIfAreaId. > >>>=20 > >>> > >>> =20 > >>> > >>Vivek, > >>It is definitely analogous to ospfIfAreaId so it will exhibit > >>the same=20 > >>behavior. I'll defer to the > >>MIB authors. > >> > >>Thanks, > >>Acee > >> > >> =20 > >> > >>>Thanks > >>>Vivek > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>On Thu, 09 Feb 2006 Acee Lindem wrote : > >>>=20 > >>> > >>> =20 > >>> > >>>>Vivek Dubey wrote: > >>>> > >>>> =20 > >>>> > >>>> =20 > >>>> > >>>>>ospfHostCfgAreaID OBJECT-TYPE SYNTAX AreaID =20 > >>>>> =20 > >>>>> > >> MAX-ACCESS read-create STATUS current =20 > >> DESCRIPTION "Allows the configuration of=20 > >>the Area the Host Entry is to be found within."=20 > >> =20 > >> > >>>>> Does that mean, this configuration results in the > >>>>> =20 > >>>>> > >>creation of > >> =20 > >> > >>>>>"Ospf Area Entry" if one does not exist. If so, why such > >>>>> =20 > >>>>> > >>a behaviour? > >> =20 > >> > >>>>> =20 > >>>>> > >>>>> =20 > >>>>> > >>>>Hi Vivek, > >>>>My interpretation is that this should not create an area if the > >>>>specified area doesn't exist. It is analogous to ospfIfAreaId for=20 > >>>>interfaces. I think trying to specify all the validation for=20 > >>>>read-create objects is a slippery slope. > >>>> > >>>>Thanks, > >>>>Acee > >>>> > >>>> =20 > >>>> > >>>> =20 > >>>> > >>>>>Thanks > >>>>>Vivek > >>>>> > >>>>> > >>>>> =20 > >>>>> > >>>>> =20 > >>>>> > >>>=20 > >>> > >>> =20 > >>> > >> =20 > >> > > > > =20 > > >=20 >=20 From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 13 15:19:10 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8kAA-0005Sv-3B for ospf-archive@megatron.ietf.org; Mon, 13 Feb 2006 15:19:10 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20398 for ; Mon, 13 Feb 2006 15:17:23 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <14.00025668@wildebeest.ease.lsoft.com>; Mon, 13 Feb 2006 15:18:38 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99323110 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 13 Feb 2006 15:18:38 -0500 Received: from 209.119.0.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 13 Feb 2006 15:18:38 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by LIME.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.000B6AB9@LIME.ease.lsoft.com>; Mon, 13 Feb 2006 15:17:31 -0500 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Message-ID: Date: Mon, 13 Feb 2006 15:18:08 -0500 Reply-To: Mailing List Sender: Mailing List From: SUBSCRIBE OSPF vishnuvardhan B Subject: Re: Idea behind DR copying the list of prefixes in the Link-LSA Comments: To: pauwells@CISCO.COM To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable Hi Pauwell, Thanks for the response. So if i need to set the next hop for any of the=20= prefixes on the transit networks the next hop will be the DR link local=20= address? is this deviation from the OSPFV2? Regards, Vishnu From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 13 15:39:44 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8kU4-0004Up-8K for ospf-archive@megatron.ietf.org; Mon, 13 Feb 2006 15:39:44 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21375 for ; Mon, 13 Feb 2006 15:37:59 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <9.000256C4@wildebeest.ease.lsoft.com>; Mon, 13 Feb 2006 15:39:13 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99324044 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 13 Feb 2006 15:39:13 -0500 Received: from 207.69.195.67 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 13 Feb 2006 15:39:13 -0500 Received: from h-68-164-81-122.snvacaid.dynamic.covad.net ([68.164.81.122] helo=earthlink.net) by pop-tawny.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1F8kTX-0004ir-00 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 13 Feb 2006 15:39:11 -0500 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <003701c62565$c41f0650$ce04120a@china.huawei.com> <0488B500-E096-42FD-B69B-DB52CD3C26CF@juniper.net> <43DDC0A5.CB67424F@earthlink.net> <7C48929A-88C1-458C-9E82-F8B82953779B@juniper.net> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43F0F252.E246DC8E@earthlink.net> Date: Mon, 13 Feb 2006 12:55:46 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Selection of router id. And behaviour with IPv4 address removal. To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Group, I just wanted to add something to this 1/2 old month thread. There are a few implementations that take into account the number of LSAs in a database against a configurable limit. Even though flushing old LSAs is not architectually specified, here is one case where it is prudent. Old LSAs, aka stale LSAs consume memory and CPU cycles to at least age them (exception of the DNA 0x8000 bit). Due to downward memory scalability, stale LSAs may consume memory for up to 1 hr. However, to prevent a LSDB from consuming all of a router's memory, some implementations support a "max-lsa" type CLI command that limits this amount of memory and depending on the freq of hitting this limit, a router may be suspended until another CLI command is manually entered. Thus, if router is aware of his environment and stale LSAs may be a issue, it is prudent IMO, to re-originate LSAs one's own LSAs that they are to be flushed. In addition,, one needs to be able to actively flush nbrs LSAs for stale LSAs if this limit is set and reached (or close to being reached). Or accept that this limit has prevented from synchronizing the LSDB, and suspend oneself. Mitchell Erblich -------------------- Dave Katz wrote: > > My point was only that flushing the LSAs is not necessary for > correctness, as the protocol must be robust against this sort of > thing. Whether or not it is a good idea, or easy, or hard, is an > issue for the implementer. There are certainly some cases where it > is not possible or at least not reasonable (the router ID changing > during a reboot, which can happen for secondary reasons.) > > On Jan 29, 2006, at 11:30 PM, Erblichs wrote: > > > > > > > So the bottom line, IMO, if we broke the suggested 30 min > > re-originate interval and do it every 50 mins, and 48 mins > > have passed, I would elect to allow "independent flushing" > > to occur in 12 mins. > > I "broke" this in 1997; the 30 minute refresh interval is stupid. I > did turn up really egregious bugs in a couple of other > implementations this way, so whether I was also stupid is open for > debate. > > > > > And if we are close to a group determined LSDB Overload, > > and 55 mins is due to the LSA being aged out, I would elect > > to do "demand MAXAGE flushing". Yes, DNA LSAs also fit here. > > > > Anywhere in between is dependent on whether we are in > > a stub area and memory is IMPORTANT or.. > > > > In between, I tend to lean towards "demand MAXAGE flushing" > > to remove unnecessary periodic work. > > > > We're free to implement this as we wish, as it is not and cannot be > subject to standardization. There is also a cost to complexity > (bloat and bugs) and being squeaky clean about these things need to > be weighed against the obvious and more subtle costs of doing so. > > Let's put it this way--if your implementation can withstand the > occasional (and seemingly inevitable, based on history) > misconfiguration when full routing gets dumped into OSPF, the > negligible loads of aging extra LSAs will not make you break a sweat. From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 13 15:48:03 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8kc5-0006L6-Df for ospf-archive@megatron.ietf.org; Mon, 13 Feb 2006 15:48:03 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21899 for ; Mon, 13 Feb 2006 15:46:16 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <3.0002569E@wildebeest.ease.lsoft.com>; Mon, 13 Feb 2006 15:47:30 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99324547 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 13 Feb 2006 15:47:30 -0500 Received: from 66.91.145.219 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 13 Feb 2006 15:47:30 -0500 Received: by apollo.adtech-inc.com with Internet Mail Service (5.5.2653.19) id <1HT4F3YV>; Mon, 13 Feb 2006 10:48:08 -1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <3D7BA5153B91EB4EBCF4CEDFE6263EA205138368@apollo.adtech-inc.com> Date: Mon, 13 Feb 2006 10:48:01 -1000 Reply-To: Mailing List Sender: Mailing List From: "Kandula, Ramesh" Subject: Re: DROther/BDR graceful restart question To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Hi Acee/Ashok, That makes more sense. Thanks for clarifying this. thanks ramesh -----Original Message----- From: Acee Lindem [mailto:acee@CISCO.COM] Sent: Friday, February 10, 2006 6:39 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: DROther/BDR graceful restart question Hi Ramesh, Ramesh Kandula wrote: >Hi All, > >Suppose a DROther router restarts gracefully on a broadcast network. >Before restart it has adjacencies with DR and BDR. According to clause in > >2.2.1 (RFC 3623), it is supposed to wait till it forms adjacencies with > >BDR and DR before exiting restart mode. > >However there is no way for it to determine who the BDR was before restar >t >using the pre-restart router lsa (and/or pre-restart network lsa). Or am >I >missing something? Actually why is it necessary to wait (i.e for exiting > >restart mode) till it forms an adjaceny with BDR? Isn't it enough for it > >wait till it forms an adjacency with DR? > > You are correct. Only the DR adjacency needs to be reformed. We'll clarify if we ever respin this RFC. The key point is that your pre-restart LSAs must match your current state prior to existing graceful restart normally. Thanks, Acee >A similar issue arises with BDR restart as well. According to the same > >clause it is supposed to wait till it forms adjacencies with all the >routers on the network. However it has no way of determining that it was > >the BDR using just the pre-restart lsas. > >Thanks, >Ramesh > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 13 16:13:37 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8l0r-0007nQ-4x for ospf-archive@megatron.ietf.org; Mon, 13 Feb 2006 16:13:37 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24054 for ; Mon, 13 Feb 2006 16:11:52 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <11.00025752@wildebeest.ease.lsoft.com>; Mon, 13 Feb 2006 16:13:06 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99325964 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 13 Feb 2006 16:13:06 -0500 Received: from 207.17.137.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 13 Feb 2006 16:13:05 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k1DLD5X38131 for ; Mon, 13 Feb 2006 13:13:05 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.13] (nimbus-sc.juniper.net [172.16.12.13]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k1DLCu508870 for ; Mon, 13 Feb 2006 13:13:00 -0800 (PST) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v746.2) References: <003701c62565$c41f0650$ce04120a@china.huawei.com> <0488B500-E096-42FD-B69B-DB52CD3C26CF@juniper.net> <43DDC0A5.CB67424F@earthlink.net> <7C48929A-88C1-458C-9E82-F8B82953779B@juniper.net> <43F0F252.E246DC8E@earthlink.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.746.2) Message-ID: <75F97408-F230-4F07-96B7-1C06A4E5BCA0@juniper.net> Date: Mon, 13 Feb 2006 13:12:53 -0800 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: Selection of router id. And behaviour with IPv4 address removal. To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43F0F252.E246DC8E@earthlink.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit On Feb 13, 2006, at 12:55 PM, Erblichs wrote: > Group, > > I just wanted to add something to this 1/2 old month > thread. > > There are a few implementations that take into account > the number of LSAs in a database against a configurable > limit. Even though flushing old LSAs is not architectually > specified, here is one case where it is prudent. This is reasonable if you're trying to protect against the all- Internet-routes-dumped-into-OSPF misconfiguration case, but if your limit is not significantly larger (some multiple) than the steady- state LSA load, you've already lost. If your network can break because you've changed a router ID and the LSAs weren't flushed, you probably shouldn't be running a network. > > Old LSAs, aka stale LSAs consume memory and CPU cycles > to at least age them (exception of the DNA 0x8000 bit). It is unnecessary to use any CPU at all to age LSAs (except when they finally expire), but that's an implementation nit. > > Due to downward memory scalability, stale LSAs may > consume memory for up to 1 hr. However, to prevent a > LSDB from consuming all of a router's memory, some > implementations support a "max-lsa" type CLI command > that limits this amount of memory and depending on the > freq of hitting this limit, a router may be suspended > until another CLI command is manually entered. > > Thus, if router is aware of his environment and stale > LSAs may be a issue, it is prudent IMO, to re-originate > LSAs one's own LSAs that they are to be flushed. Like I said, you can't rely on this. It may be helpful and friendly, but you can't rely on it. > > In addition,, one needs to be able to actively flush > nbrs LSAs for stale LSAs if this limit is set > and reached (or close to being reached). This is wildly dangerous and is a seriously bad idea. It requires a definition of "stale" that cannot be satisfied in a distributed system, particularly one that is unstable (which is probably why you're trying to do this in the first place.) --Dave From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 13 16:45:08 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8lVM-0001U1-4I for ospf-archive@megatron.ietf.org; Mon, 13 Feb 2006 16:45:08 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25672 for ; Mon, 13 Feb 2006 16:43:22 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <2.0002569C@wildebeest.ease.lsoft.com>; Mon, 13 Feb 2006 16:44:36 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99327380 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 13 Feb 2006 16:44:36 -0500 Received: from 171.71.176.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 13 Feb 2006 16:44:36 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 13 Feb 2006 13:44:36 -0800 X-IronPort-AV: i="4.02,109,1139212800"; d="scan'208"; a="404496329:sNHT29290404" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1DLiZjt002842 for ; Mon, 13 Feb 2006 13:44:35 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Feb 2006 16:44:35 -0500 Received: from [10.82.240.109] ([10.82.240.109]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Feb 2006 16:44:35 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) 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 X-OriginalArrivalTime: 13 Feb 2006 21:44:35.0205 (UTC) FILETIME=[AE54EB50:01C630E6] Message-ID: <43F0FDC2.3040904@cisco.com> Date: Mon, 13 Feb 2006 16:44:34 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Idea behind DR copying the list of prefixes in the Link-LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit vishnuvardhan B wrote: >Hi Pauwell, >Thanks for the response. So if i need to set the next hop for any of the > >prefixes on the transit networks the next hop will be the DR link local > >address? is this deviation from the OSPFV2? > > Hi Vishnu, No - Read section 16.1.1 in RFC 2328. "If the destination is a directly connected network, or a router which connectes to the calculating router via a point-to-point interface, no next hop IP address is required." Hope this helps, Acee P.S. Please remove "SUBSCRIBE" from your E-mail alias name. It causes the IETF mailers to think replies are subscribe messages being sent to the general list. >Regards, >Vishnu > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 13 23:03:49 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8rPp-0002Ni-4b for ospf-archive@megatron.ietf.org; Mon, 13 Feb 2006 23:03:49 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23571 for ; Mon, 13 Feb 2006 23:02:03 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <3.00025C5F@wildebeest.ease.lsoft.com>; Mon, 13 Feb 2006 23:03:16 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99330788 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 13 Feb 2006 23:03:16 -0500 Received: from 207.69.195.68 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 13 Feb 2006 23:03:08 -0500 Received: from h-68-164-81-122.snvacaid.dynamic.covad.net ([68.164.81.122] helo=earthlink.net) by pop-cowbird.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1F8lqP-0000NZ-00 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 13 Feb 2006 17:06:53 -0500 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <003701c62565$c41f0650$ce04120a@china.huawei.com> <0488B500-E096-42FD-B69B-DB52CD3C26CF@juniper.net> <43DDC0A5.CB67424F@earthlink.net> <7C48929A-88C1-458C-9E82-F8B82953779B@juniper.net> <43F0F252.E246DC8E@earthlink.net> <75F97408-F230-4F07-96B7-1C06A4E5BCA0@juniper.net> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43F106D1.9D37CAA8@earthlink.net> Date: Mon, 13 Feb 2006 14:23:13 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Selection of router id. And behaviour with IPv4 address removal. To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit One item, First, some routers have memory limitations! wow. Are you telling me that you can't identify link/local or area scope routers that have dropped out AND their associated LSAs? It is deduceable. Yes, we need to be aware of XYZ.. Sorry, group I am not going to give you all the nity grity details of how to do this. Yes, this doesn't keep the router up and functioning if the dump was a massive external LSA dump and the router is still active. My hope is that the router that did the LSA dump becomes aware of this issue first and solves this problem. It should see huge rexmit lists, etc. However, it does solve the problem if the cause is based on stale LSAs. Active flushing is only suggested WHEN passive/age flushing has either not kept track or.. Either way, we either reduce our current number of LSAs in our LSDB or suspend. I would rather reduce if possible. since these are stale LSAs they have no effect on our routing and if nbr returns, it will re-originate its LSAs. As to an unstable .. that should be a different thread. Mitchell Erblich ----------------- > > In addition,, one needs to be able to actively flush > > nbrs LSAs for stale LSAs if this limit is set > > and reached (or close to being reached). > > This is wildly dangerous and is a seriously bad idea. It requires a > definition of "stale" that cannot be satisfied in a distributed > system, particularly one that is unstable (which is probably why > you're trying to do this in the first place.) > Dave Katz wrote: > > On Feb 13, 2006, at 12:55 PM, Erblichs wrote: > > > Group, > > > > I just wanted to add something to this 1/2 old month > > thread. > > > > There are a few implementations that take into account > > the number of LSAs in a database against a configurable > > limit. Even though flushing old LSAs is not architectually > > specified, here is one case where it is prudent. > > This is reasonable if you're trying to protect against the all- > Internet-routes-dumped-into-OSPF misconfiguration case, but if your > limit is not significantly larger (some multiple) than the steady- > state LSA load, you've already lost. If your network can break > because you've changed a router ID and the LSAs weren't flushed, you > probably shouldn't be running a network. > > > > > Old LSAs, aka stale LSAs consume memory and CPU cycles > > to at least age them (exception of the DNA 0x8000 bit). > > It is unnecessary to use any CPU at all to age LSAs (except when they > finally expire), but that's an implementation nit. > > > > > Due to downward memory scalability, stale LSAs may > > consume memory for up to 1 hr. However, to prevent a > > LSDB from consuming all of a router's memory, some > > implementations support a "max-lsa" type CLI command > > that limits this amount of memory and depending on the > > freq of hitting this limit, a router may be suspended > > until another CLI command is manually entered. > > > > Thus, if router is aware of his environment and stale > > LSAs may be a issue, it is prudent IMO, to re-originate > > LSAs one's own LSAs that they are to be flushed. > > Like I said, you can't rely on this. It may be helpful and friendly, > but you can't rely on it. > > > > > In addition,, one needs to be able to actively flush > > nbrs LSAs for stale LSAs if this limit is set > > and reached (or close to being reached). > > This is wildly dangerous and is a seriously bad idea. It requires a > definition of "stale" that cannot be satisfied in a distributed > system, particularly one that is unstable (which is probably why > you're trying to do this in the first place.) > > --Dave From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 14 15:44:45 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F972S-0000DR-Ko for ospf-archive@megatron.ietf.org; Tue, 14 Feb 2006 15:44:44 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25496 for ; Tue, 14 Feb 2006 15:42:57 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <2.00026A8E@wildebeest.ease.lsoft.com>; Tue, 14 Feb 2006 15:44:13 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99404305 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 14 Feb 2006 15:44:12 -0500 Received: from 63.94.127.69 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 14 Feb 2006 15:44:12 -0500 Received: from postit.laurelnetworks.com (postit.laurelnetworks.com [63.94.127.21]) by paperclip.laurelnetworks.com (Laurel/Laurel) with ESMTP id k1EKiBaZ025319 for ; Tue, 14 Feb 2006 15:44:11 -0500 Received: from sherlock.pit.laurelnetworks.com (washer.pit.laurelnetworks.com [10.0.0.46]) by postit.laurelnetworks.com (Laurel/Laurel) with ESMTP id k1EKiBwe004166 for ; Tue, 14 Feb 2006 15:44:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: Section 16.2 of RFC2328 and ABR's behaviour thread-index: AcYw4knHqpJY8oqPRBm4DoH6FgWz6wAwzrpg Message-ID: Date: Tue, 14 Feb 2006 15:44:10 -0500 Reply-To: Mailing List Sender: Mailing List From: Srinivas Goli Subject: Section 16.2 of RFC2328 and ABR's behaviour To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable Folks, Section 16.2 states the following 16.2. Calculating the inter-area routes The inter-area routes are calculated by examining summary-LSAs. If the router has active attachments to multiple areas, only backbone summary-LSAs are examined. Routers attached to a single area examine that area's summary-LSAs. In either case, the summary-LSAs examined below are all part of a single area's link state database (call it Area A). From this it is clear that the an ABR will only examine the summary LSAs from the backbone area. This is done to avoid the counting to infinity problem since exchanging routes between areas is done using Distance Vector mechanisms. Now some of vendors seems to skip this check i.e examining summary LSAs from all attached areas. Can any one explain why this would be considered useful, assuming this is done intentionally. Regards, From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 14 17:18:10 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F98Us-0003ym-2n for ospf-archive@megatron.ietf.org; Tue, 14 Feb 2006 17:18:10 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07777 for ; Tue, 14 Feb 2006 17:16:24 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <15.00026C8E@wildebeest.ease.lsoft.com>; Tue, 14 Feb 2006 17:17:38 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99417814 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 14 Feb 2006 17:17:38 -0500 Received: from 171.68.10.86 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 14 Feb 2006 17:17:38 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 14 Feb 2006 14:17:39 -0800 X-IronPort-AV: i="4.02,115,1139212800"; d="scan'208"; a="1776417011:sNHT34959456" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k1EMHaQN016608 for ; Tue, 14 Feb 2006 14:17:37 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Feb 2006 17:17:36 -0500 Received: from [10.82.240.109] ([10.82.240.109]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Feb 2006 17:17:36 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) 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 X-OriginalArrivalTime: 14 Feb 2006 22:17:36.0139 (UTC) FILETIME=[757935B0:01C631B4] Message-ID: <43F256FF.6020706@cisco.com> Date: Tue, 14 Feb 2006 17:17:35 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Section 16.2 of RFC2328 and ABR's behaviour To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Srinivas Goli wrote: >Folks, > >Section 16.2 states the following > > 16.2. Calculating the inter-area routes > > The inter-area routes are calculated by examining summary-LSAs. > If the router has active attachments to multiple areas, only > backbone summary-LSAs are examined. Routers attached to a > single area examine that area's summary-LSAs. In either case, > the summary-LSAs examined below are all part of a single area's > link state database (call it Area A). > >>From this it is clear that the an ABR will only examine the summary LSAs >from the backbone area. This is done to avoid the counting to infinity >problem since exchanging routes between areas is done using Distance >Vector mechanisms. > >Now some of vendors seems to skip this check i.e examining summary LSAs >from all attached areas. Can any one explain why this would be >considered useful, assuming this is done intentionally. > > Hi Srinivas, See RFC 3509. Thanks, Acee >Regards, > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 14 17:51:31 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9919-0000Zc-9J for ospf-archive@megatron.ietf.org; Tue, 14 Feb 2006 17:51:31 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09624 for ; Tue, 14 Feb 2006 17:49:45 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <9.00026E47@wildebeest.ease.lsoft.com>; Tue, 14 Feb 2006 17:51:00 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99419643 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 14 Feb 2006 17:51:00 -0500 Received: from 209.119.0.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 14 Feb 2006 17:51:00 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by LIME.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0007D896@LIME.ease.lsoft.com>; Tue, 14 Feb 2006 17:49:52 -0500 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Message-ID: Date: Tue, 14 Feb 2006 17:50:59 -0500 Reply-To: Mailing List Sender: Mailing List From: vishnuvardhan B Subject: Re: Idea behind DR copying the list of prefixes in the Link-LSA Comments: To: Acee Lindem To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable Hi Acee, Thanks for the response. Sorry for not being clear in the question, what = i=20 meant by "transit networks" is transit links i.e the links on the brodcas= t=20 networks. which lsa's i need to consider is it DR's type-9 or each router= s=20 link-lsa's? Regards, Vishnu From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 14 18:01:05 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F99AP-000591-SX for ospf-archive@megatron.ietf.org; Tue, 14 Feb 2006 18:01:05 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10140 for ; Tue, 14 Feb 2006 17:59:19 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <10.00026E61@wildebeest.ease.lsoft.com>; Tue, 14 Feb 2006 18:00:35 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99420436 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 14 Feb 2006 18:00:35 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 14 Feb 2006 18:00:24 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 14 Feb 2006 15:00:25 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,115,1139212800"; d="scan'208"; a="21889492:sNHT21754920" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1EMxbPq004972; Tue, 14 Feb 2006 18:00:22 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Feb 2006 18:00:04 -0500 Received: from [10.82.240.109] ([10.82.240.109]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Feb 2006 18:00:03 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) 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 X-OriginalArrivalTime: 14 Feb 2006 23:00:03.0919 (UTC) FILETIME=[641195F0:01C631BA] Message-ID: <43F260F3.90806@cisco.com> Date: Tue, 14 Feb 2006 18:00:03 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Idea behind DR copying the list of prefixes in the Link-LSA Comments: To: vishnuvardhan B To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit vishnuvardhan B wrote: >Hi Acee, >Thanks for the response. Sorry for not being clear in the question, what >i >meant by "transit networks" is transit links i.e the links on the brodcas >t >networks. which lsa's i need to consider is it DR's type-9 or each router >s >link-lsa's? > > Vishnu, Section 3.8.2 in draft-ietf-ospf-ospfv3-update-07.txt applies to all link types. Do you think this is unclear? Thanks, Acee >Regards, >Vishnu > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 14 18:52:24 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F99y4-0007X8-5N for ospf-archive@megatron.ietf.org; Tue, 14 Feb 2006 18:52:24 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12959 for ; Tue, 14 Feb 2006 18:50:37 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <12.00026F1C@wildebeest.ease.lsoft.com>; Tue, 14 Feb 2006 18:51:52 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99424156 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 14 Feb 2006 18:51:51 -0500 Received: from 209.119.1.41 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 14 Feb 2006 18:51:51 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by LIME.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0007D9A3@LIME.ease.lsoft.com>; Tue, 14 Feb 2006 18:50:43 -0500 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Message-ID: Date: Tue, 14 Feb 2006 18:51:44 -0500 Reply-To: Mailing List Sender: Mailing List From: SUBSCRIBE OSPF vishnuvardhan B Subject: Re: Idea behind DR copying the list of prefixes in the Link-LSA Comments: To: Acee Lindem To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable Hi Acee, Thanks for the response, i am little bit worried about the spf calculatio= n=20 on broadcast networks. Let me explain my problem with the help of diagram= Assume R1,R2,R3,R4 are on broadcast medium. R1(DR) R2 R3 R4=20 | | | | ----------------------------------------- During SPF suppose R4 is root, when i extend from R4 i reach R1(since R= 1=20 is DR), so i copy all the prefixes from type-9 ref-network LSA genereated= =20 by DR. so i need to set for all the prefixes nexthop as R1?[Is this the=20= correct way?]=20 OR should i use each routers link-lsa's to copy the global prefixes on the=20= link and set the next hops as the individual link-local addresses?=20=20=20= If i follow the second approach where should i use the prefixes copied by= =20 the DR into type-9 LSA? From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 14 19:05:03 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9AAJ-0002pa-5Z for ospf-archive@megatron.ietf.org; Tue, 14 Feb 2006 19:05:03 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15326 for ; Tue, 14 Feb 2006 19:03:16 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <4.00026F99@wildebeest.ease.lsoft.com>; Tue, 14 Feb 2006 19:04:31 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99425053 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 14 Feb 2006 19:04:31 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 14 Feb 2006 19:04:30 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 14 Feb 2006 16:04:31 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,115,1139212800"; d="scan'208"; a="21892855:sNHT25335476" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1F04MPS014794 for ; Tue, 14 Feb 2006 19:04:29 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Feb 2006 19:04:28 -0500 Received: from [10.82.240.109] ([10.82.240.109]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 14 Feb 2006 19:04:28 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) 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 X-OriginalArrivalTime: 15 Feb 2006 00:04:28.0598 (UTC) FILETIME=[6398CD60:01C631C3] Message-ID: <43F2700C.3000906@cisco.com> Date: Tue, 14 Feb 2006 19:04:28 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Idea behind DR copying the list of prefixes in the Link-LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Vishnu, Please remove SUBSCRIBE OSPF from your mail alias for this list. Also, sending a single copy to this list is sufficient (I'm subscribed :^). Anyway, in answer to your question, there are 2 cases: 1) You are directly connected to the network referenced by the intra-area prefix LSA. In this case, this excerpt from RFC 2328, section 16.1.1 applies. If the destination is a directly connected network, or a router which connects to the calculating router via a point-to-point interface, no next hop IP address is required. 2) You are one or more hops away. Then this cause from RFC 2328 applies. If there is at least one intervening router in the current shortest path between the destination and the root, the destination simply inherits the set of next hops from the parent. Hope this helps, Acee vishnuvardhan B wrote: >Hi Acee, >Thanks for the response, i am little bit worried about the spf calculatio >n >on broadcast networks. Let me explain my problem with the help of diagram > > >Assume R1,R2,R3,R4 are on broadcast medium. > > R1(DR) R2 R3 R4 > | | | | > ----------------------------------------- > > During SPF suppose R4 is root, when i extend from R4 i reach R1(since R >1 >is DR), so i copy all the prefixes from type-9 ref-network LSA genereated > >by DR. so i need to set for all the prefixes nexthop as R1?[Is this the > >correct way?] > OR >should i use each routers link-lsa's to copy the global prefixes on the > >link and set the next hops as the individual link-local addresses? > > >If i follow the second approach where should i use the prefixes copied by > >the DR into type-9 LSA? > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 15 11:16:11 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9PK7-0004d3-Le for ospf-archive@megatron.ietf.org; Wed, 15 Feb 2006 11:16:11 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27685 for ; Wed, 15 Feb 2006 11:14:23 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <2.00027E8F@wildebeest.ease.lsoft.com>; Wed, 15 Feb 2006 11:15:34 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99478036 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 15 Feb 2006 11:15:32 -0500 Received: from 63.94.127.69 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 15 Feb 2006 11:15:22 -0500 Received: from postit.laurelnetworks.com (postit.laurelnetworks.com [63.94.127.21]) by paperclip.laurelnetworks.com (Laurel/Laurel) with ESMTP id k1FGFMrF000954 for ; Wed, 15 Feb 2006 11:15:22 -0500 Received: from sherlock.pit.laurelnetworks.com (washer.pit.laurelnetworks.com [10.0.0.46]) by postit.laurelnetworks.com (Laurel/Laurel) with ESMTP id k1FGFMPf017631 for ; Wed, 15 Feb 2006 11:15:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: Section 16.2 of RFC2328 and ABR's behaviour thread-index: AcYxtHpXpHAAnrH1TUCR4NZEp4U8vwAk8SVA Message-ID: Date: Wed, 15 Feb 2006 11:15:21 -0500 Reply-To: Mailing List Sender: Mailing List From: Srinivas Goli Subject: Re: Section 16.2 of RFC2328 and ABR's behaviour To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable =20 > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On=20 > Behalf Of Acee Lindem > Sent: Tuesday, February 14, 2006 5:18 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Section 16.2 of RFC2328 and ABR's behaviour >=20 > Srinivas Goli wrote: >=20 > >Folks, > > > >Section 16.2 states the following > > > > 16.2. Calculating the inter-area routes > > > > The inter-area routes are calculated by examining=20 > summary-LSAs. > > If the router has active attachments to multiple areas, only > > backbone summary-LSAs are examined. Routers attached to a > > single area examine that area's summary-LSAs. In=20 > either case, > > the summary-LSAs examined below are all part of a=20 > single area's > > link state database (call it Area A). > > > >>From this it is clear that the an ABR will only examine the summary=20 > >>LSAs > >from the backbone area. This is done to avoid the counting=20 > to infinity=20 > >problem since exchanging routes between areas is done using Distance=20 > >Vector mechanisms. > > > >Now some of vendors seems to skip this check i.e examining=20 > summary LSAs=20 > >from all attached areas. Can any one explain why this would be=20 > >considered useful, assuming this is done intentionally. > > =20 > > > Hi Srinivas, > See RFC 3509. > Thanks, > Acee >=20 Hi Acee, I had looked at RFC3509 as possible explanation of what I saw but the particular case I am looking at is a router with two actively attached areas both of which are non backbone areas. The router would identify itself as ABR by setting B bit in the router-lsa. The router also re-advertises the summary LSAs in one area into the other areas.=20 Thanks,=20 =20 > >Regards, > > > > =20 > > >=20 >=20 From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 15 12:09:19 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Q9X-0005b5-Ai for ospf-archive@megatron.ietf.org; Wed, 15 Feb 2006 12:09:19 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12664 for ; Wed, 15 Feb 2006 12:07:32 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <3.000280A1@wildebeest.ease.lsoft.com>; Wed, 15 Feb 2006 12:08:48 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99482095 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 15 Feb 2006 12:08:47 -0500 Received: from 171.71.176.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 15 Feb 2006 12:08:47 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 15 Feb 2006 09:08:47 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k1FH8iQP024489 for ; Wed, 15 Feb 2006 09:08:46 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Feb 2006 12:08:45 -0500 Received: from [10.82.240.109] ([10.82.240.109]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Feb 2006 12:08:45 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) 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 X-OriginalArrivalTime: 15 Feb 2006 17:08:45.0498 (UTC) FILETIME=[7AC389A0:01C63252] Message-ID: <43F3601C.2060202@cisco.com> Date: Wed, 15 Feb 2006 12:08:44 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Section 16.2 of RFC2328 and ABR's behaviour To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Srinivas Goli wrote: > > > > >>-----Original Message----- >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On >>Behalf Of Acee Lindem >>Sent: Tuesday, February 14, 2006 5:18 PM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Re: Section 16.2 of RFC2328 and ABR's behaviour >> >>Srinivas Goli wrote: >> >> >> >>>Folks, >>> >>>Section 16.2 states the following >>> >>> 16.2. Calculating the inter-area routes >>> >>> The inter-area routes are calculated by examining >>> >>> >>summary-LSAs. >> >> >>> If the router has active attachments to multiple areas, only >>> backbone summary-LSAs are examined. Routers attached to a >>> single area examine that area's summary-LSAs. In >>> >>> >>either case, >> >> >>> the summary-LSAs examined below are all part of a >>> >>> >>single area's >> >> >>> link state database (call it Area A). >>> >>>>From this it is clear that the an ABR will only examine the summary >>> >>> >>>>LSAs >>>> >>>> >>>from the backbone area. This is done to avoid the counting >>to infinity >> >> >>>problem since exchanging routes between areas is done using Distance >>>Vector mechanisms. >>> >>>Now some of vendors seems to skip this check i.e examining >>> >>> >>summary LSAs >>>from all attached areas. Can any one explain why this would be >> >> >>>considered useful, assuming this is done intentionally. >>> >>> >>> >>> >>Hi Srinivas, >>See RFC 3509. >>Thanks, >>Acee >> >> >> >Hi Acee, > >I had looked at RFC3509 as possible explanation of what I saw but the >particular case I am looking at is a router with two actively attached >areas both of which are non backbone areas. The router would identify >itself as ABR by setting B bit in the router-lsa. The router also >re-advertises the summary LSAs in one area into the other areas. > > Hi Srinivas, Note that RFC 2328 considers any router "attached" to multiple areas an ABR. While I can't find a precise definition in the RFC, "attached" is generally considered to mean one or more UP interfaces. Area border routers A router that attaches to multiple areas. Area border routers run multiple copies of the basic algorithm, one copy for each attached area. Area border routers condense the topological information of their attached areas for distribution to the backbone. The backbone in turn distributes the information to the other areas. So, the router is not misbehaving. What is wrong is that the backbone is not contiguous (if the router doesn't have any backbone interfaces). This ABR definition has been debated over the years and was the primary motivation for the RFC 3509 functionality. Thanks, Acee >Thanks, > > > > >>>Regards, >>> >>> >>> >>> >>> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 17 06:13:02 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA3Xq-0003cA-9f for ospf-archive@megatron.ietf.org; Fri, 17 Feb 2006 06:13:02 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20192 for ; Fri, 17 Feb 2006 06:11:14 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <6.0002A645@wildebeest.ease.lsoft.com>; Fri, 17 Feb 2006 1:11:51 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99635466 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 17 Feb 2006 01:11:51 -0500 Received: from 61.144.161.55 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 17 Feb 2006 00:24:53 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUT00LYYGOKQJ@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 17 Feb 2006 13:31:32 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUT009D9GOKMV@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 17 Feb 2006 13:31:32 +0800 (CST) Received: from anup ([10.18.4.206]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IUT00KRCH3CEV@szxml01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 17 Feb 2006 13:40:26 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: multipart/alternative; boundary="Boundary_(ID_qt+veRan7jdoPuxERlK0Yg)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <000001c63382$709b2a60$ce04120a@china.huawei.com> Date: Fri, 17 Feb 2006 10:54:33 +0530 Reply-To: Mailing List Sender: Mailing List From: anup Subject: should the ASBR path preference rules be applied while comparing type-5 and type-7 route paths To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: This is a multi-part message in MIME format. --Boundary_(ID_qt+veRan7jdoPuxERlK0Yg) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi Group, ASBR 1 | Area 1 | Area 0 | R ------------------------ ASBR 2 Area 3 Suppose that ASBR 1 and ASBR 2 are equi-distant from R. Suppose that ASBR 1 and ASBR 2 advertise route to a destination N with same cost & type (say type 1). As per RFC 2328, R chooses the intra-area path through Area 3 to ASBR2. (ASBR path preference rules - RFC 2328, Sec 16.4.1) My questions: 1. If Area 3 is NSSA, should the ASBR path preference rules be applied while comparing type-5 and type-7 route paths? 2. RFC 1587 says "When a type-5 LSA and a type-7 LSA are found to have the same type and an equal distance, tie breaking rules are used". Is the ASBR path preference check implicit in the above statement? RFC 1587, section 3.5, step 5: "Otherwise, compare the cost of this new AS external path to the ones present in the table. Note that type-5 and type-7 routes are directly comparable. Type-1 external paths are always shorter than Type-2 external paths. Type-1 external paths are compared by looking at the sum of the distance to the forwarding address/ASBR and the advertised Type-1 paths (X+Y). Type-2 external paths are compared by looking at the advertised Type-2 metrics, and then if necessary, the distance to the forwarding address/ASBR. When a type-5 LSA and a type-7 LSA are found to have the same type and an equal distance, the following priorities apply (listed from highest to lowest) for breaking the tie. a. Any type 5 LSA. b. A type-7 LSA with the P-bit set and the forwarding address non-zero. c. Any other type-7 LSA. If the new path is shorter, it replaces the present paths in the routing table entry. If the new path is the same cost, it is added to the routing table entry's list of paths." Thanks, Anup --Boundary_(ID_qt+veRan7jdoPuxERlK0Yg) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

Hi Group,

 

        ASBR 1

            |

          Area 1

            |

         Area 0

            |

           R  ------------------------  ASBR 2

                     Area 3

 

Suppose that ASBR 1 and ASBR 2 are equi-distant from R.

 

Suppose that ASBR 1 and ASBR 2 advertise route to a destination N with same cost & type (say type 1).

 

As per RFC 2328, R chooses the intra-area path through Area 3 to ASBR2. (ASBR path preference rules – RFC 2328, Sec 16.4.1)

 

 

My questions:

    

1. If Area 3 is NSSA, should the ASBR path preference rules be applied while comparing type-5 and type-7 route paths?

 

2. RFC 1587 says “When a type-5 LSA and a type-7 LSA are found to have the same type and an equal distance, tie breaking rules are used”. Is the ASBR path preference check implicit in the above statement?

 

 

RFC 1587, section 3.5, step 5:

 

                 “Otherwise, compare the cost of this new AS external path
         to the ones present in the table. Note that type-5 and
         type-7 routes are directly comparable. Type-1 external
         paths are always shorter than Type-2 external paths.
         Type-1 external paths are compared by looking at the sum
         of the distance to the forwarding address/ASBR and the
         advertised Type-1 paths (X+Y). Type-2 external paths are
         compared by looking at the advertised Type-2 metrics,
         and then if necessary, the distance to the forwarding
         address/ASBR.
 
         When a type-5 LSA and a type-7 LSA are found to have the
         same type and an equal distance, the following priorities
         apply (listed from highest to lowest) for breaking the tie.
 
                 a. Any type 5 LSA.
                 b. A type-7 LSA with the P-bit set and the forwarding
                    address non-zero.
                 c. Any other type-7 LSA.
 
         If the new path is shorter, it replaces the present paths
         in the routing table entry. If the new path is the same
         cost, it is added to the routing table entry's list of
         paths.”

 

 

Thanks,

Anup

--Boundary_(ID_qt+veRan7jdoPuxERlK0Yg)-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 17 12:32:39 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA9TD-0006jg-KT for ospf-archive@megatron.ietf.org; Fri, 17 Feb 2006 12:32:39 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14315 for ; Fri, 17 Feb 2006 12:30:52 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <15.0002B056@wildebeest.ease.lsoft.com>; Fri, 17 Feb 2006 12:32:08 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99686727 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 17 Feb 2006 12:32:08 -0500 Received: from 130.118.4.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 17 Feb 2006 12:32:07 -0500 Received: from omega7.wr.usgs.gov by omega7.wr.usgs.gov (PMDF V6.0-23 #41392) id <01LZ2JBDVY8G000F3G@omega7.wr.usgs.gov> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 17 Feb 2006 09:31:04 -0700 (PDT) X-VMS-To: OSPF@PEACH.EASE.LSOFT.COM X-VMS-Cc: PMURPHY,anupkumart@HUAWEI.COM MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Message-ID: <01LZ2JBDVZ6A000F3G@omega7.wr.usgs.gov> Date: Fri, 17 Feb 2006 09:31:04 -0700 Reply-To: Mailing List Sender: Mailing List From: "Pat Murphy - (650)329-4044" Subject: Re: should the ASBR path preference rules be applied while comparing type-5 and type-7 route paths Comments: cc: ANUPKUMART@HUAWEI.COM To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Anup, >1. If Area 3 is NSSA, should the ASBR path preference rules >be applied while comparing type-5 and type-7 route paths? Yes, but RFC 1587 was written before RFC 2328. RFC 1587 have been obsoleted by RFC 3101. >2. RFC 1587 says "When a type-5 LSA and a type-7 LSA are found to have the >same type and an equal distance, tie breaking rules are used". Is the ASBR >path preference check implicit in the above statement? No. The external calculation of RFC 1587 is broken. Implementations should use the refined calculation defined in RFC 3101, Section 2.5, where the path preference check is explicitly described. Note RFC 3101, Section 2.5 needs a minor correction which I hope to get to soon. It was found by someone on this list some time back. Pat From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 17 12:43:55 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA9e6-0001IM-SH for ospf-archive@megatron.ietf.org; Fri, 17 Feb 2006 12:43:55 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15657 for ; Fri, 17 Feb 2006 12:42:07 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <3.0002B172@wildebeest.ease.lsoft.com>; Fri, 17 Feb 2006 12:43:24 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99689158 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 17 Feb 2006 12:43:24 -0500 Received: from 207.17.137.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 17 Feb 2006 12:43:24 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k1HHhN1Z092985 for ; Fri, 17 Feb 2006 09:43:23 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.13] (nimbus-sc.juniper.net [172.16.12.13]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k1HHhM555622 for ; Fri, 17 Feb 2006 09:43:22 -0800 (PST) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v746.2) References: <003701c62565$c41f0650$ce04120a@china.huawei.com> <0488B500-E096-42FD-B69B-DB52CD3C26CF@juniper.net> <43DDC0A5.CB67424F@earthlink.net> <7C48929A-88C1-458C-9E82-F8B82953779B@juniper.net> <43F0F252.E246DC8E@earthlink.net> <75F97408-F230-4F07-96B7-1C06A4E5BCA0@juniper.net> <43F106D1.9D37CAA8@earthlink.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.746.2) Message-ID: Date: Fri, 17 Feb 2006 09:43:21 -0800 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: Selection of router id. And behaviour with IPv4 address removal. To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43F106D1.9D37CAA8@earthlink.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit I'll bloviate one more time and then let this drop. On Feb 13, 2006, at 2:23 PM, Erblichs wrote: > One item, > > First, some routers have memory limitations! Certainly. But as I said, if they don't have a significant margin for LSA storage (well beyond what would be needed for the odd extra LSA) then they have already failed. If nothing else, there are far more memory-intensive dynamic things in a router (a single installed route typically has much more overhead than an LSA.) They are going to be hosed when you add a few more routers or a few more subnets. Routers that are *that* limited have no place in a production network. If you accept this, then by definition the only time the memory situation should become critical is when something goes badly wrong (like dumping BGP into OSPF), which makes this optimization pointless. > > wow. Are you telling me that you can't identify link/local > or area scope routers that have dropped out AND their > associated LSAs? It is deduceable. Wow. They cannot be positively identified. The safety of a guess goes up with the time constant over which the absence is integrated, but then the purported value of doing so goes down. You certainly can't just purge LSAs for router IDs to which nobody happens to be advertising adjacency at a particular instant (imagine the fun if the adjacency is flapping as you get into flooding wars with the real owner of the LSA.) You can create heuristics to decide how long enough a router has to be missing (or on the other side of a partition) in order to clean up after it, but this is not for the faint of heart, and will have very ugly consequences if not done well. It's not for nothing that the OSPF spec specifically bars premature aging of LSAs other than one's own. Further, the complexity and risk is simply not worth it for the purported benefits, which I claim are essentially nonexistent in the real world. Way too many years of scars have taught me that the failure modes in these protocols are endlessly fascinating and often surprising. The early Cisco OSPF implementation had a bug (among many, and for the record, not written by me) in which it sent acknowledgements for received LSAs that were older than what was in the database rather than just dropping them. The side effects are quite spectacular, but are not obvious (and certainly surprised me at the time.) > > Yes, we need to be aware of XYZ.. Sorry, group I am not > going to give you all the nity grity details of how to > do this. > > Yes, this doesn't keep the router up and functioning if > the dump was a massive external LSA dump and the router > is still active. > > My hope is that the router that did the LSA dump becomes > aware of this issue first and solves this problem. It > should see huge rexmit lists, etc. Hoping doesn't help. There is an existence proof (roughly annually, starting with "AOL down for 19 hours" back in 1995) that this *does* happen and that the originating router *doesn't* care. Most implementations have fail-safe code that will cause something reasonable to happen if too many LSAs are in the process of being originated, but this is difficult to have enabled by default, and is not always set by the operators. Any implementation that expects to survive *must* expect that it will share the network with implementations that may not be well-mannered in many random ways. > > However, it does solve the problem if the cause is based > on stale LSAs. Active flushing is only suggested WHEN > passive/age flushing has either not kept track or.. See above. A few stale LSAs are *not* a "problem." They may be a "nuisance" but are probably just "distasteful." If they are a "problem" then the network has much larger Problems. > > Either way, we either reduce our current number of LSAs in > our LSDB or suspend. I would rather reduce if possible. I would rather be stable if possible. Imagine the fun when each of 2000 routers in the area decides simultaneously that the LSAs are stale and simultaneously flood MaxAge LSAs, and then the originating router reappears from its partition because of a flapping link, ad nauseum. In the case where the database uses up all available memory (which one way or another is a human-induced disaster) suspending (and shutting up rather than adding to the disaster) is the only reasonable course. Purging other routers' LSAs is just a bad idea. This was learned early in the deployment of IS-IS. The original IS- IS spec said to purge an LSP if it was received with a broken Fletcher checksum (in the theory that this could only occur if said LSP was corrupted in memory, since the links were error protected.) A very nice correctness mechanism, as it gets rid of the corrupted LSP. Unfortunately, in about 1996, a link in UUnet started delivering corrupted packets with valid datalink checksums. This led to another fascinating, spectacular, and mildly surprising at the time (though not so in hindsight) event. > > since these are stale LSAs they have no effect on our > routing and if nbr returns, it will re-originate its > LSAs. > > As to an unstable .. that should be a different thread. No, it should not. If you are not thinking "unstable" in *every* suggested change to the protocol, then you're making a large mistake. Everything is easy in a stable network. To quote Mike O'Dell (albeit out of context), "If you're not scared, you're just not paying attention." Stability is the Prime Directive. Making essentially useless changes that are demonstrably destabilizing (not to mention in conflict with the spec, which was written that way for a good reason) is not good engineering. It's tinkering for tinkering's sake. Pointless optimization is a bad addiction (aptly demonstrated by other parts of the OSPF spec) that inevitably leads to tears and recrimination. --Dave From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 17 16:18:41 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FACzx-0005F1-K5 for ospf-archive@megatron.ietf.org; Fri, 17 Feb 2006 16:18:41 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12059 for ; Fri, 17 Feb 2006 16:16:52 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <15.0002B462@wildebeest.ease.lsoft.com>; Fri, 17 Feb 2006 16:18:10 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99702795 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 17 Feb 2006 16:18:10 -0500 Received: from 171.71.176.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 17 Feb 2006 16:18:00 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 17 Feb 2006 13:17:57 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1HLHuKT029155 for ; Fri, 17 Feb 2006 13:17:57 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 17 Feb 2006 16:17:43 -0500 Received: from [10.82.240.109] ([10.82.240.109]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 17 Feb 2006 16:17:42 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Feb 2006 21:17:42.0735 (UTC) FILETIME=[96E085F0:01C63407] Message-ID: <43F63D76.4030009@cisco.com> Date: Fri, 17 Feb 2006 16:17:42 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: draft-kou-ospf-immediately-replying-hello-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Hi Zengjie, Under what situations does having the router who changed to/from DR/BDR improve convergence (section 6.2)? Since DR/BDR election is a distributed algorithm dependent on the calculating routers state, it seems this won't help in all that many cases. Thanks, Acee From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 17 17:26:20 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAE3P-0006Df-VN for ospf-archive@megatron.ietf.org; Fri, 17 Feb 2006 17:26:20 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19815 for ; Fri, 17 Feb 2006 17:24:30 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <4.0002B6C7@wildebeest.ease.lsoft.com>; Fri, 17 Feb 2006 17:25:49 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99706981 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 17 Feb 2006 17:25:48 -0500 Received: from 207.69.195.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 17 Feb 2006 17:25:48 -0500 Received: from h-68-164-155-88.snvacaid.dynamic.covad.net ([68.164.155.88] helo=earthlink.net) by pop-sarus.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1FAE1W-00018n-00 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 17 Feb 2006 17:24:22 -0500 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <003701c62565$c41f0650$ce04120a@china.huawei.com> <0488B500-E096-42FD-B69B-DB52CD3C26CF@juniper.net> <43DDC0A5.CB67424F@earthlink.net> <7C48929A-88C1-458C-9E82-F8B82953779B@juniper.net> <43F0F252.E246DC8E@earthlink.net> <75F97408-F230-4F07-96B7-1C06A4E5BCA0@juniper.net> <43F106D1.9D37CAA8@earthlink.net> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43F650FF.B48AC399@earthlink.net> Date: Fri, 17 Feb 2006 14:41:03 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Selection of router id. And behaviour with IPv4 address removal. To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Group, summary; This discussion has been offlined and I agree that routers must behave correctly, without assuming that its nbrs will also do so. Some questions from the edu folks will be reviewed if clarifications are wanted. The .com folks can research and resolve the issues themselves. Lastly, I don't believe one should purge other's LSAS by MAX-AGING them and flooding. I never said that. Mitchell Erblich ------------------ Dave Katz wrote: > > I'll bloviate one more time and then let this drop. > > On Feb 13, 2006, at 2:23 PM, Erblichs wrote: > > > One item, > > > > First, some routers have memory limitations! > > Certainly. But as I said, if they don't have a significant margin > for LSA storage (well beyond what would be needed for the odd extra > LSA) then they have already failed. If nothing else, there are far > more memory-intensive dynamic things in a router (a single installed > route typically has much more overhead than an LSA.) They are going > to be hosed when you add a few more routers or a few more subnets. > Routers that are *that* limited have no place in a production network. > > If you accept this, then by definition the only time the memory > situation should become critical is when something goes badly wrong > (like dumping BGP into OSPF), which makes this optimization pointless. > > > > > wow. Are you telling me that you can't identify link/local > > or area scope routers that have dropped out AND their > > associated LSAs? It is deduceable. > > Wow. They cannot be positively identified. The safety of a guess > goes up with the time constant over which the absence is integrated, > but then the purported value of doing so goes down. You certainly > can't just purge LSAs for router IDs to which nobody happens to be > advertising adjacency at a particular instant (imagine the fun if the > adjacency is flapping as you get into flooding wars with the real > owner of the LSA.) > > You can create heuristics to decide how long enough a router has to > be missing (or on the other side of a partition) in order to clean up > after it, but this is not for the faint of heart, and will have very > ugly consequences if not done well. It's not for nothing that the > OSPF spec specifically bars premature aging of LSAs other than one's > own. > > Further, the complexity and risk is simply not worth it for the > purported benefits, which I claim are essentially nonexistent in the > real world. > > Way too many years of scars have taught me that the failure modes in > these protocols are endlessly fascinating and often surprising. The > early Cisco OSPF implementation had a bug (among many, and for the > record, not written by me) in which it sent acknowledgements for > received LSAs that were older than what was in the database rather > than just dropping them. The side effects are quite spectacular, but > are not obvious (and certainly surprised me at the time.) > > > > > Yes, we need to be aware of XYZ.. Sorry, group I am not > > going to give you all the nity grity details of how to > > do this. > > > > Yes, this doesn't keep the router up and functioning if > > the dump was a massive external LSA dump and the router > > is still active. > > > > My hope is that the router that did the LSA dump becomes > > aware of this issue first and solves this problem. It > > should see huge rexmit lists, etc. > > Hoping doesn't help. There is an existence proof (roughly annually, > starting with "AOL down for 19 hours" back in 1995) that this *does* > happen and that the originating router *doesn't* care. Most > implementations have fail-safe code that will cause something > reasonable to happen if too many LSAs are in the process of being > originated, but this is difficult to have enabled by default, and is > not always set by the operators. > > Any implementation that expects to survive *must* expect that it will > share the network with implementations that may not be well-mannered > in many random ways. > > > > > However, it does solve the problem if the cause is based > > on stale LSAs. Active flushing is only suggested WHEN > > passive/age flushing has either not kept track or.. > > See above. A few stale LSAs are *not* a "problem." They may be a > "nuisance" but are probably just "distasteful." If they are a > "problem" then the network has much larger Problems. > > > > > Either way, we either reduce our current number of LSAs in > > our LSDB or suspend. I would rather reduce if possible. > > I would rather be stable if possible. Imagine the fun when each of > 2000 routers in the area decides simultaneously that the LSAs are > stale and simultaneously flood MaxAge LSAs, and then the originating > router reappears from its partition because of a flapping link, ad > nauseum. In the case where the database uses up all available memory > (which one way or another is a human-induced disaster) suspending > (and shutting up rather than adding to the disaster) is the only > reasonable course. > > Purging other routers' LSAs is just a bad idea. > > This was learned early in the deployment of IS-IS. The original IS- > IS spec said to purge an LSP if it was received with a broken > Fletcher checksum (in the theory that this could only occur if said > LSP was corrupted in memory, since the links were error protected.) > A very nice correctness mechanism, as it gets rid of the corrupted > LSP. Unfortunately, in about 1996, a link in UUnet started > delivering corrupted packets with valid datalink checksums. This led > to another fascinating, spectacular, and mildly surprising at the > time (though not so in hindsight) event. > > > > > since these are stale LSAs they have no effect on our > > routing and if nbr returns, it will re-originate its > > LSAs. > > > > As to an unstable .. that should be a different thread. > > No, it should not. If you are not thinking "unstable" in *every* > suggested change to the protocol, then you're making a large > mistake. Everything is easy in a stable network. To quote Mike > O'Dell (albeit out of context), "If you're not scared, you're just > not paying attention." > > Stability is the Prime Directive. Making essentially useless changes > that are demonstrably destabilizing (not to mention in conflict with > the spec, which was written that way for a good reason) is not good > engineering. It's tinkering for tinkering's sake. > > Pointless optimization is a bad addiction (aptly demonstrated by > other parts of the OSPF spec) that inevitably leads to tears and > recrimination. > > --Dave From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 17 21:35:31 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAHwZ-0007ZH-G3 for ospf-archive@megatron.ietf.org; Fri, 17 Feb 2006 21:35:31 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13085 for ; Fri, 17 Feb 2006 21:33:42 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <6.0002BA7D@wildebeest.ease.lsoft.com>; Fri, 17 Feb 2006 21:35:00 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99717741 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 17 Feb 2006 21:35:00 -0500 Received: from 209.119.1.41 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 17 Feb 2006 21:24:59 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by LIME.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00083574@LIME.ease.lsoft.com>; Fri, 17 Feb 2006 21:23:49 -0500 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Message-ID: Date: Fri, 17 Feb 2006 21:24:59 -0500 Reply-To: Mailing List Sender: Mailing List From: Sunil Patro Subject: Detecting router id change in p2p-over-lan connection To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable Hi everyone, According to section 4.5 in draft draft-ietf-isis-igp-p2p-over-lan-05.txt= , "If the circuit is configured as point-to-point type and receives LAN hello packets, the router MUST discard the incoming packets; If the circuit is a LAN type and receive point-to-point hello packets, it MUST discard the incoming packets. If the system ID or the router ID of incoming hello packet does not match the system ID or the router ID of already established adjacency over this p2p-over-lan circuit, it MUST discard the packet. The implementation should offer logging and debugging information of the above events.", My question is how does one detect a router-id change in this scenario th= en? thanks, Sunil From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 17 22:33:08 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAIqJ-0007pp-Ty for ospf-archive@megatron.ietf.org; Fri, 17 Feb 2006 22:33:08 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16078 for ; Fri, 17 Feb 2006 22:31:18 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <10.0002BB6E@wildebeest.ease.lsoft.com>; Fri, 17 Feb 2006 22:32:37 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99720469 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 17 Feb 2006 22:32:37 -0500 Received: from 207.69.195.65 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 17 Feb 2006 22:32:37 -0500 Received: from h-68-164-155-88.snvacaid.dynamic.covad.net ([68.164.155.88] helo=earthlink.net) by pop-scotia.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1FAIpn-0004rS-00; Fri, 17 Feb 2006 22:32:36 -0500 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43F6975C.12E2933B@earthlink.net> Date: Fri, 17 Feb 2006 19:41:16 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Detecting router id change in p2p-over-lan connection Comments: To: Sunil Patro To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Sunil, The doc that you refer to is a IS-IS RFC draft and you sent the question to a OSPF mail alias? Mitchell Erblich -------------------- Sunil Patro wrote: > > Hi everyone, > > According to section 4.5 in draft draft-ietf-isis-igp-p2p-over-lan-05.txt, > > "If the circuit is configured as point-to-point type and receives > LAN hello packets, the router MUST discard the incoming packets; If > the circuit is a LAN type and receive point-to-point hello packets, > it MUST discard the incoming packets. If the system ID or the > router ID of incoming hello packet does not match the system ID or > the router ID of already established adjacency over this p2p-over-lan > circuit, it MUST discard the packet. The implementation should offer > logging and debugging information of the above events.", > > My question is how does one detect a router-id change in this scenario then? > > thanks, > Sunil From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 17 22:36:21 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAItR-0000rN-LG for ospf-archive@megatron.ietf.org; Fri, 17 Feb 2006 22:36:21 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16222 for ; Fri, 17 Feb 2006 22:34:32 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <6.0002BB70@wildebeest.ease.lsoft.com>; Fri, 17 Feb 2006 22:35:50 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99721054 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 17 Feb 2006 22:35:51 -0500 Received: from 207.17.137.119 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 17 Feb 2006 22:35:51 -0500 Received: from unknown (HELO gamma.jnpr.net) ([172.24.245.25]) by borg.juniper.net with ESMTP; 17 Feb 2006 19:35:50 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,126,1139212800"; d="scan'208"; a="530714842:sNHT23348256" Received: from hadron.jnpr.net ([172.24.15.25]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Feb 2006 19:35:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: Detecting router id change in p2p-over-lan connection Thread-Index: AcY0PAA33xP/yfZ3TQeIo7da/JEu9gAAEAaQ X-OriginalArrivalTime: 18 Feb 2006 03:35:49.0618 (UTC) FILETIME=[69502520:01C6343C] Message-ID: Date: Fri, 17 Feb 2006 19:35:49 -0800 Reply-To: Mailing List Sender: Mailing List From: Sunil Patro Subject: Re: Detecting router id change in p2p-over-lan connection To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable The same draft talks about ospf in sec 4.2. I guess they don't have a draft named separately for ospf. Thanks, Sunil > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > Erblichs > Sent: Friday, February 17, 2006 7:41 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Detecting router id change in p2p-over-lan connection >=20 > Sunil, >=20 > The doc that you refer to is a IS-IS RFC draft and > you sent the question to a OSPF mail alias? >=20 > Mitchell Erblich > -------------------- >=20 > Sunil Patro wrote: > > > > Hi everyone, > > > > According to section 4.5 in draft draft-ietf-isis-igp-p2p-over-lan- > 05.txt, > > > > "If the circuit is configured as point-to-point type and receives > > LAN hello packets, the router MUST discard the incoming packets; If > > the circuit is a LAN type and receive point-to-point hello packets, > > it MUST discard the incoming packets. If the system ID or the > > router ID of incoming hello packet does not match the system ID or > > the router ID of already established adjacency over this p2p-over-lan > > circuit, it MUST discard the packet. The implementation should offer > > logging and debugging information of the above events.", > > > > My question is how does one detect a router-id change in this scenario > then? > > > > thanks, > > Sunil From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 17 23:03:25 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAJJc-0005N8-Sc for ospf-archive@megatron.ietf.org; Fri, 17 Feb 2006 23:03:25 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17713 for ; Fri, 17 Feb 2006 23:01:35 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <8.0002BACD@wildebeest.ease.lsoft.com>; Fri, 17 Feb 2006 23:02:54 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99723168 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 17 Feb 2006 23:02:54 -0500 Received: from 207.69.195.65 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 17 Feb 2006 23:02:54 -0500 Received: from h-68-164-155-88.snvacaid.dynamic.covad.net ([68.164.155.88] helo=earthlink.net) by pop-scotia.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1FAJJ7-0003fO-00 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 17 Feb 2006 23:02:53 -0500 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43F69DEE.17841EA6@earthlink.net> Date: Fri, 17 Feb 2006 20:09:18 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Detecting router id change in p2p-over-lan connection To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Not reading the draft. :^) The 4.5 section only deals with matching hello types and circuit types for established adjacencies. The section does not include that L1 AND L2 need separate hellos. Their is no mention about changing router-ids. However, if I remember my IS-IS correctly, (yes, I have also coded for the IS-IS / ES-ISL3 protocol) then the MAC value would be the same even with a different system-id. There is a presumed single MAC per interface per router versus normally a single MAC value for an entire host system. The same would be true for OSPF, that the interface should have the same MAC value even though the router-id might have changed. However this does not hold true if a vendor has also switched interfaces or circuits that is forming the adj as these other interfaces would have a different MAC value. Thus, you can tell if a router has changed router-ids. However, this still presumes that you have kept dead nbrs/peers history and that you have made a check against matching died nbr/peers. Normally if one changes a router-id, then they don't expect that the former/old adjacency will be used with the new router-id. Mitchell Erblich ------------- Sunil Patro wrote: > > The same draft talks about ospf in sec 4.2. > I guess they don't have a draft named separately for ospf. > > Thanks, > Sunil > > > -----Original Message----- > > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > > Erblichs > > Sent: Friday, February 17, 2006 7:41 PM > > To: OSPF@PEACH.EASE.LSOFT.COM > > Subject: Re: Detecting router id change in p2p-over-lan connection > > > > Sunil, > > > > The doc that you refer to is a IS-IS RFC draft and > > you sent the question to a OSPF mail alias? > > > > Mitchell Erblich > > -------------------- > > > > Sunil Patro wrote: > > > > > > Hi everyone, > > > > > > According to section 4.5 in draft draft-ietf-isis-igp-p2p-over-lan- > > 05.txt, > > > > > > "If the circuit is configured as point-to-point type and receives > > > LAN hello packets, the router MUST discard the incoming packets; > If > > > the circuit is a LAN type and receive point-to-point hello > packets, > > > it MUST discard the incoming packets. If the system ID or the > > > router ID of incoming hello packet does not match the system ID > or > > > the router ID of already established adjacency over this > p2p-over-lan > > > circuit, it MUST discard the packet. The implementation should > offer > > > logging and debugging information of the above events.", > > > > > > My question is how does one detect a router-id change in this > scenario > > then? > > > > > > thanks, > > > Sunil From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 17 23:30:21 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAJjh-00016I-3g for ospf-archive@megatron.ietf.org; Fri, 17 Feb 2006 23:30:21 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19105 for ; Fri, 17 Feb 2006 23:28:31 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <12.0002BC10@wildebeest.ease.lsoft.com>; Fri, 17 Feb 2006 23:29:50 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99724605 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 17 Feb 2006 23:29:50 -0500 Received: from 207.17.137.120 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 17 Feb 2006 23:29:50 -0500 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by kremlin.juniper.net with ESMTP; 17 Feb 2006 20:29:50 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,126,1139212800"; d="scan'208"; a="528485062:sNHT25048260" Received: from hadron.jnpr.net ([172.24.15.25]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Feb 2006 20:29:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: Detecting router id change in p2p-over-lan connection Thread-Index: AcY0QDueIqHXqXiCQh+ipiZZj6gsZAAAhyvA X-OriginalArrivalTime: 18 Feb 2006 04:29:46.0298 (UTC) FILETIME=[F28651A0:01C63443] Message-ID: Date: Fri, 17 Feb 2006 20:29:45 -0800 Reply-To: Mailing List Sender: Mailing List From: Sunil Patro Subject: Re: Detecting router id change in p2p-over-lan connection To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable Mitchell, I guess we can compare the IP src address of the neighbor to find out if the new router-id is coming from the same neighbor or a different neighbor. Btw, I am unclear about your reference to L1 and L2 needing separate hellos. Quoting your last line -=20 " Normally if one changes a router-id, then they don't expect that the former/old adjacency will be used with the new router-id." I am guessing you mean that anytime there is a router-id change in the neighbor, the neighboring router should tear down the adjacency by sending appropriate hello with the old router-id (by not including our router id in the neighbor list) and then sending a new hello with a new router-id. In any case, can we say that section 4.5 is unclear about handling router-id change? And it is left to the implementor to find the best way to handle the router-id change? Thanks, Sunil > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > Erblichs > Sent: Friday, February 17, 2006 8:09 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Detecting router id change in p2p-over-lan connection >=20 > Not reading the draft. :^) >=20 > The 4.5 section only deals with matching hello types > and circuit types for established adjacencies. The section > does not include that L1 AND L2 need separate hellos. >=20 > Their is no mention about changing router-ids. However, > if I remember my IS-IS correctly, (yes, I have also coded > for the IS-IS / ES-ISL3 protocol) then the MAC value > would be the same even with a different system-id. There > is a presumed single MAC per interface per router versus > normally a single MAC value for an entire host system. >=20 > The same would be true for OSPF, that the interface > should have the same MAC value even though the router-id > might have changed. However this does not hold true > if a vendor has also switched interfaces or circuits > that is forming the adj as these other interfaces would > have a different MAC value. >=20 > Thus, you can tell if a router has changed router-ids. > However, this still presumes that you have kept dead > nbrs/peers history and that you have made a check against > matching died nbr/peers. >=20 > Normally if one changes a router-id, then they don't expect that > the former/old adjacency will be used with the new router-id. >=20 > Mitchell Erblich > ------------- >=20 > Sunil Patro wrote: > > > > The same draft talks about ospf in sec 4.2. > > I guess they don't have a draft named separately for ospf. > > > > Thanks, > > Sunil > > > > > -----Original Message----- > > > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > > > Erblichs > > > Sent: Friday, February 17, 2006 7:41 PM > > > To: OSPF@PEACH.EASE.LSOFT.COM > > > Subject: Re: Detecting router id change in p2p-over-lan connection > > > > > > Sunil, > > > > > > The doc that you refer to is a IS-IS RFC draft and > > > you sent the question to a OSPF mail alias? > > > > > > Mitchell Erblich > > > -------------------- > > > > > > Sunil Patro wrote: > > > > > > > > Hi everyone, > > > > > > > > According to section 4.5 in draft draft-ietf-isis-igp-p2p-over-lan- > > > 05.txt, > > > > > > > > "If the circuit is configured as point-to-point type and receives > > > > LAN hello packets, the router MUST discard the incoming packets; > > If > > > > the circuit is a LAN type and receive point-to-point hello > > packets, > > > > it MUST discard the incoming packets. If the system ID or the > > > > router ID of incoming hello packet does not match the system ID > > or > > > > the router ID of already established adjacency over this > > p2p-over-lan > > > > circuit, it MUST discard the packet. The implementation should > > offer > > > > logging and debugging information of the above events.", > > > > > > > > My question is how does one detect a router-id change in this > > scenario > > > then? > > > > > > > > thanks, > > > > Sunil From owner-ospf@PEACH.EASE.LSOFT.COM Sun Feb 19 22:20:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB1bC-0007c9-J4 for ospf-archive@LISTS.IETF.ORG; Sun, 19 Feb 2006 22:20:30 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FB1bB-0007OJ-Cr for ospf-archive@LISTS.IETF.ORG; Sun, 19 Feb 2006 22:20:30 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <4.0002E800@wildebeest.ease.lsoft.com>; 19 Feb 2006 22:20:26 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99861986 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 19 Feb 2006 22:20:26 -0500 Received: from 57.66.76.5 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 19 Feb 2006 22:20:26 -0500 Received: from huawei.com ([172.24.2.9]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUY0099MTN68U@lhrga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Mon, 20 Feb 2006 02:59:30 +0000 (GMT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUY00LGCUOBKQ@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Mon, 20 Feb 2006 11:21:48 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IUY00IFPUOB5Z@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Mon, 20 Feb 2006 11:21:47 +0800 (CST) Received: from k49110 ([10.111.12.97]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IUY003LVUX7WP@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Mon, 20 Feb 2006 11:27:08 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <43F63D76.4030009@cisco.com> Message-ID: <000b01c635cb$cddcca30$610c6f0a@china.huawei.com> Date: Mon, 20 Feb 2006 11:14:47 +0800 Reply-To: Mailing List Sender: Mailing List From: Zengjie Kou Subject: Re: draft-kou-ospf-immediately-replying-hello-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Hi,Acee, If a router interface whose role is changed(e.g.DR goes down), the router will notify all routers about the change by immediate hello. After all router get the change, election will be reprocessed. In contrast to normal hello, immediate hello avoid the backupSeen. Namely, improving convergence. Thanks a lot, Zengjie ----- Original Message ----- From: "Acee Lindem" To: Sent: Saturday, February 18, 2006 5:17 AM Subject: draft-kou-ospf-immediately-replying-hello-00.txt > Hi Zengjie, > > Under what situations does having the router who changed to/from > DR/BDR improve convergence (section 6.2)? Since DR/BDR election > is a distributed algorithm dependent on the calculating routers state, it > seems this won't help in all that many cases. > > Thanks, > Acee From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 20 00:33:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB3fb-0004eG-69 for ospf-archive@LISTS.IETF.ORG; Mon, 20 Feb 2006 00:33:11 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FB3fa-0002a2-Tc for ospf-archive@LISTS.IETF.ORG; Mon, 20 Feb 2006 00:33:11 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <10.0002E9DC@wildebeest.ease.lsoft.com>; Mon, 20 Feb 2006 0:33:10 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99869930 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 20 Feb 2006 00:33:09 -0500 Received: from 12.178.35.128 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 20 Feb 2006 00:33:09 -0500 Received: from mailblr1.engineering.netscaler.com ([10.102.1.9]) by mailsj.engineering.netscaler.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 19 Feb 2006 21:29:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Detecting router id change in p2p-over-lan connection Thread-Index: AcY0QDueIqHXqXiCQh+ipiZZj6gsZAAAhyvAAGblSMA= X-OriginalArrivalTime: 20 Feb 2006 05:29:01.0040 (UTC) FILETIME=[8E246700:01C635DE] Message-ID: <6D975E431022374F9F7A298A511427B61936EA@mailblr1.engineering.netscaler.com> Date: Mon, 20 Feb 2006 11:02:58 +0530 Reply-To: Mailing List Sender: Mailing List From: Nitin Kakkar Subject: Re: Detecting router id change in p2p-over-lan connection To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Sunil, Why do you want to detect router-id change on P2P link ? I have seen some major implementations which can support multiple simultaneous adjacencies on P2P link. So what is the meaning of router-id change? Nitin -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Sunil Patro Sent: Saturday, February 18, 2006 10:00 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Detecting router id change in p2p-over-lan connection Mitchell, I guess we can compare the IP src address of the neighbor to find out if the new router-id is coming from the same neighbor or a different neighbor. Btw, I am unclear about your reference to L1 and L2 needing separate hellos. Quoting your last line -=20 " Normally if one changes a router-id, then they don't expect that the former/old adjacency will be used with the new router-id." I am guessing you mean that anytime there is a router-id change in the neighbor, the neighboring router should tear down the adjacency by sending appropriate hello with the old router-id (by not including our router id in the neighbor list) and then sending a new hello with a new router-id. In any case, can we say that section 4.5 is unclear about handling router-id change? And it is left to the implementor to find the best way to handle the router-id change? Thanks, Sunil > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > Erblichs > Sent: Friday, February 17, 2006 8:09 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Detecting router id change in p2p-over-lan connection >=20 > Not reading the draft. :^) >=20 > The 4.5 section only deals with matching hello types > and circuit types for established adjacencies. The section > does not include that L1 AND L2 need separate hellos. >=20 > Their is no mention about changing router-ids. However, > if I remember my IS-IS correctly, (yes, I have also coded > for the IS-IS / ES-ISL3 protocol) then the MAC value > would be the same even with a different system-id. There > is a presumed single MAC per interface per router versus > normally a single MAC value for an entire host system. >=20 > The same would be true for OSPF, that the interface > should have the same MAC value even though the router-id > might have changed. However this does not hold true > if a vendor has also switched interfaces or circuits > that is forming the adj as these other interfaces would > have a different MAC value. >=20 > Thus, you can tell if a router has changed router-ids. > However, this still presumes that you have kept dead > nbrs/peers history and that you have made a check against > matching died nbr/peers. >=20 > Normally if one changes a router-id, then they don't expect that > the former/old adjacency will be used with the new router-id. >=20 > Mitchell Erblich > ------------- >=20 > Sunil Patro wrote: > > > > The same draft talks about ospf in sec 4.2. > > I guess they don't have a draft named separately for ospf. > > > > Thanks, > > Sunil > > > > > -----Original Message----- > > > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > > > Erblichs > > > Sent: Friday, February 17, 2006 7:41 PM > > > To: OSPF@PEACH.EASE.LSOFT.COM > > > Subject: Re: Detecting router id change in p2p-over-lan connection > > > > > > Sunil, > > > > > > The doc that you refer to is a IS-IS RFC draft and > > > you sent the question to a OSPF mail alias? > > > > > > Mitchell Erblich > > > -------------------- > > > > > > Sunil Patro wrote: > > > > > > > > Hi everyone, > > > > > > > > According to section 4.5 in draft draft-ietf-isis-igp-p2p-over-lan- > > > 05.txt, > > > > > > > > "If the circuit is configured as point-to-point type and receives > > > > LAN hello packets, the router MUST discard the incoming packets; > > If > > > > the circuit is a LAN type and receive point-to-point hello > > packets, > > > > it MUST discard the incoming packets. If the system ID or the > > > > router ID of incoming hello packet does not match the system ID > > or > > > > the router ID of already established adjacency over this > > p2p-over-lan > > > > circuit, it MUST discard the packet. The implementation should > > offer > > > > logging and debugging information of the above events.", > > > > > > > > My question is how does one detect a router-id change in this > > scenario > > > then? > > > > > > > > thanks, > > > > Sunil From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 20 01:11:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB4Gd-0005f6-VC for ospf-archive@LISTS.IETF.ORG; Mon, 20 Feb 2006 01:11:28 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FB4Gd-00032J-PR for ospf-archive@LISTS.IETF.ORG; Mon, 20 Feb 2006 01:11:27 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <2.0002E98E@wildebeest.ease.lsoft.com>; Mon, 20 Feb 2006 1:11:27 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99872018 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 20 Feb 2006 01:11:27 -0500 Received: from 207.17.137.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 20 Feb 2006 01:11:26 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k1K6BQ1Z038632 for ; Sun, 19 Feb 2006 22:11:26 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.13] (nimbus-sc.juniper.net [172.16.12.13]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k1K6BP503899 for ; Sun, 19 Feb 2006 22:11:26 -0800 (PST) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v746.2) References: <6D975E431022374F9F7A298A511427B61936EA@mailblr1.engineering.netscaler.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.746.2) Message-ID: <326454E7-1B73-4C4C-870D-77AC2B676819@juniper.net> Date: Sun, 19 Feb 2006 22:11:25 -0800 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: Detecting router id change in p2p-over-lan connection To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <6D975E431022374F9F7A298A511427B61936EA@mailblr1.engineering.netscaler.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On Feb 19, 2006, at 9:32 PM, Nitin Kakkar wrote: > Sunil, > Why do you want to detect router-id change on P2P link ? > I have seen some major implementations which can support multiple > simultaneous adjacencies on P2P link. So what is the meaning of > router-id change? Such implementations are out of spec, not to mention that it is not at all clear how one would address multiple devices on a point-to- point link. By definition a point-to-point link connects exactly two devices; if there are more than two then it is by definition multipoint. Unless you are referring to multiple adjacencies between the same pair of routers, which is a whole separate can of worms. Detecting router ID changes is important in order to detect cable moves, or a router ID change, or some kind of system hot swap (such as APS) among other things. --Dave From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 20 01:50:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB4sn-0006UY-UZ for ospf-archive@LISTS.IETF.ORG; Mon, 20 Feb 2006 01:50:53 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FB4sn-0004B8-OG for ospf-archive@LISTS.IETF.ORG; Mon, 20 Feb 2006 01:50:53 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <5.0002EB34@wildebeest.ease.lsoft.com>; Mon, 20 Feb 2006 1:50:53 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99873254 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 20 Feb 2006 01:50:52 -0500 Received: from 12.178.35.128 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 20 Feb 2006 01:50:52 -0500 Received: from mailblr1.engineering.netscaler.com ([10.102.1.9]) by mailsj.engineering.netscaler.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 19 Feb 2006 22:46:50 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Detecting router id change in p2p-over-lan connection Thread-Index: AcY15IJGFfCXU1OVTFe52OI7R1oFvgAA9QFQ X-OriginalArrivalTime: 20 Feb 2006 06:46:50.0599 (UTC) FILETIME=[6D6A8F70:01C635E9] Message-ID: <6D975E431022374F9F7A298A511427B61936EE@mailblr1.engineering.netscaler.com> Date: Mon, 20 Feb 2006 12:20:48 +0530 Reply-To: Mailing List Sender: Mailing List From: Nitin Kakkar Subject: Re: Detecting router id change in p2p-over-lan connection To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa IMHO OSPF spec does not say that P2P adjacencies should be restricted to only one peer. (But I haven't read rfc for long time so if does say that some where please let me know) How this is possible, Well have two routers with OSPF adjacency and large dead interval. Change router-id on one of them. ( Note that some implementations do send one way hello for router-id change they will behave differently but again ospf spec does not mention that either) but others will show 2 adjacencies till one of the peer ages out. IMHO On P2P cable move should trigger Loss of signal->link-down/link-up events which inturn is IFSM_DOWN-> KILL NBR. In this case there won't be any Nbr history. But if there is a L2 device in between peer then yes there wont be any link down event. --Nitin -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Dave Katz Sent: Monday, February 20, 2006 11:41 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Detecting router id change in p2p-over-lan connection On Feb 19, 2006, at 9:32 PM, Nitin Kakkar wrote: > Sunil, > Why do you want to detect router-id change on P2P link ? > I have seen some major implementations which can support multiple > simultaneous adjacencies on P2P link. So what is the meaning of > router-id change? Such implementations are out of spec, not to mention that it is not =20 at all clear how one would address multiple devices on a point-to-=20 point link. By definition a point-to-point link connects exactly two devices; if =20 there are more than two then it is by definition multipoint. Unless you are referring to multiple adjacencies between the same =20 pair of routers, which is a whole separate can of worms. Detecting router ID changes is important in order to detect cable =20 moves, or a router ID change, or some kind of system hot swap (such =20 as APS) among other things. --Dave From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 20 09:28:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBC21-00039o-1z for ospf-archive@LISTS.IETF.ORG; Mon, 20 Feb 2006 09:28:53 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBC20-0000RH-N0 for ospf-archive@LISTS.IETF.ORG; Mon, 20 Feb 2006 09:28:53 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <8.0002F19A@wildebeest.ease.lsoft.com>; Mon, 20 Feb 2006 9:28:52 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99913922 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 20 Feb 2006 09:28:51 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 20 Feb 2006 09:28:39 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 20 Feb 2006 06:28:40 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,130,1139212800"; d="scan'208"; a="22253100:sNHT27540880" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k1KESbLN025823 for ; Mon, 20 Feb 2006 09:28:37 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Feb 2006 09:28:29 -0500 Received: from [10.82.240.109] ([10.82.240.109]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Feb 2006 09:28:28 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) 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 X-OriginalArrivalTime: 20 Feb 2006 14:28:28.0803 (UTC) FILETIME=[EAD51530:01C63629] Message-ID: <43F9D20C.6000405@cisco.com> Date: Mon, 20 Feb 2006 09:28:28 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Detecting router id change in p2p-over-lan connection To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Hi Sunil, Nitin, and Mitchell, As Dave points out, a point-to-point network is explicitly defined as a connection between a single pair of routers. Also, RFC 2328 dictates that router-id be used to identify neighbors on point-to-point links. Hence, what draft-ietf-isis-igp-p2p-over-lan-05.txt is recommending is to take the path of least resistance and handle router-id changes by letting the current adjacency time out before forming a new one. Another option for point-to-point links would be to force the neighbor down when a router-id change is detected. If you do something more clever like using the source address as a hint to determine if the router-id has changed or maintaining more than one adjacency, there is no guarantee that other implementations will do the same. IMHO, we shouldn't try and optimize for the router-id change case nor should we try and specify precisely how implementations should handle router-id changes at this point in the OSPF protocol evolution. I'll discuss this with the authors of draft-ietf-isis-igp-p2p-over-lan-05.txt. Thanks, Acee Sunil Patro wrote: >Mitchell, > >I guess we can compare the IP src address of the neighbor to find out if > >the new router-id is coming from the same neighbor or a different >neighbor. > >Btw, I am unclear about your reference to L1 and L2 needing separate >hellos. > >Quoting your last line - >" Normally if one changes a router-id, then they don't expect that > the former/old adjacency will be used with the new router-id." > >I am guessing you mean that anytime there is a router-id change in the >neighbor, the neighboring router should tear down the adjacency by >sending appropriate hello with the old router-id (by not including our >router id in the neighbor list) and then sending a new hello with a new >router-id. > >In any case, can we say that section 4.5 is unclear about handling >router-id change? And it is left to the implementor to find the best way >to handle the router-id change? > >Thanks, >Sunil > > > >>-----Original Message----- >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >>Erblichs >>Sent: Friday, February 17, 2006 8:09 PM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Re: Detecting router id change in p2p-over-lan connection >> >> Not reading the draft. :^) >> >> The 4.5 section only deals with matching hello types >> and circuit types for established adjacencies. The section >> does not include that L1 AND L2 need separate hellos. >> >> Their is no mention about changing router-ids. However, >> if I remember my IS-IS correctly, (yes, I have also coded >> for the IS-IS / ES-ISL3 protocol) then the MAC value >> would be the same even with a different system-id. There >> is a presumed single MAC per interface per router versus >> normally a single MAC value for an entire host system. >> >> The same would be true for OSPF, that the interface >> should have the same MAC value even though the router-id >> might have changed. However this does not hold true >> if a vendor has also switched interfaces or circuits >> that is forming the adj as these other interfaces would >> have a different MAC value. >> >> Thus, you can tell if a router has changed router-ids. >> However, this still presumes that you have kept dead >> nbrs/peers history and that you have made a check against >> matching died nbr/peers. >> >> Normally if one changes a router-id, then they don't expect >> >> >that > > >> the former/old adjacency will be used with the new router-id. >> >> Mitchell Erblich >> ------------- >> >>Sunil Patro wrote: >> >> >>>The same draft talks about ospf in sec 4.2. >>>I guess they don't have a draft named separately for ospf. >>> >>>Thanks, >>>Sunil >>> >>> >>> >>>>-----Original Message----- >>>>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >>>>Erblichs >>>>Sent: Friday, February 17, 2006 7:41 PM >>>>To: OSPF@PEACH.EASE.LSOFT.COM >>>>Subject: Re: Detecting router id change in p2p-over-lan connection >>>> >>>>Sunil, >>>> >>>> The doc that you refer to is a IS-IS RFC draft and >>>> you sent the question to a OSPF mail alias? >>>> >>>> Mitchell Erblich >>>> -------------------- >>>> >>>>Sunil Patro wrote: >>>> >>>> >>>>>Hi everyone, >>>>> >>>>>According to section 4.5 in draft >>>>> >>>>> >draft-ietf-isis-igp-p2p-over-lan- > > >>>>05.txt, >>>> >>>> >>>>> "If the circuit is configured as point-to-point type and >>>>> >>>>> >receives > > >>>>> LAN hello packets, the router MUST discard the incoming >>>>> >>>>> >packets; > > >>>If >>> >>> >>>>> the circuit is a LAN type and receive point-to-point hello >>>>> >>>>> >>>packets, >>> >>> >>>>> it MUST discard the incoming packets. If the system ID or the >>>>> router ID of incoming hello packet does not match the system >>>>> >>>>> >ID > > >>>or >>> >>> >>>>> the router ID of already established adjacency over this >>>>> >>>>> >>>p2p-over-lan >>> >>> >>>>> circuit, it MUST discard the packet. The implementation >>>>> >>>>> >should > > >>>offer >>> >>> >>>>> logging and debugging information of the above events.", >>>>> >>>>>My question is how does one detect a router-id change in this >>>>> >>>>> >>>scenario >>> >>> >>>>then? >>>> >>>> >>>>>thanks, >>>>>Sunil >>>>> >>>>> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 20 10:15:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBClE-0004tD-HZ for ospf-archive@LISTS.IETF.ORG; Mon, 20 Feb 2006 10:15:36 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBClC-0001hx-9Y for ospf-archive@LISTS.IETF.ORG; Mon, 20 Feb 2006 10:15:36 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <10.0002F383@wildebeest.ease.lsoft.com>; Mon, 20 Feb 2006 10:15:33 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99921552 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 20 Feb 2006 10:15:33 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 20 Feb 2006 10:15:33 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 20 Feb 2006 10:15:34 -0500 X-IronPort-AV: i="4.02,130,1139202000"; d="scan'208"; a="82772207:sNHT31055280" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k1KFFCLf003399 for ; Mon, 20 Feb 2006 10:15:31 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Feb 2006 10:15:29 -0500 Received: from [10.82.240.109] ([10.82.240.109]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Feb 2006 10:15:28 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <43F63D76.4030009@cisco.com> <000b01c635cb$cddcca30$610c6f0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Feb 2006 15:15:28.0926 (UTC) FILETIME=[7BC1B3E0:01C63630] Message-ID: <43F9DD10.8040305@cisco.com> Date: Mon, 20 Feb 2006 10:15:28 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-kou-ospf-immediately-replying-hello-00.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000b01c635cb$cddcca30$610c6f0a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Hi Zengjie, Zengjie Kou wrote: >Hi,Acee, > If a router interface whose role is changed(e.g.DR goes down), the router will notify all routers about the change by immediate hello. > > This is only when the DR/BDR knows that it is going down or the case where the router priority is set to 0. For a router becoming DR/BDR, all the routers should elect the same DR/BDR so I don't see how it helps. Thanks, Acee > After all router get the change, election will be reprocessed. In contrast to normal hello, immediate hello avoid the backupSeen. > Namely, improving convergence. > >Thanks a lot, >Zengjie > >----- Original Message ----- >From: "Acee Lindem" >To: >Sent: Saturday, February 18, 2006 5:17 AM >Subject: draft-kou-ospf-immediately-replying-hello-00.txt > > > > >>Hi Zengjie, >> >>Under what situations does having the router who changed to/from >>DR/BDR improve convergence (section 6.2)? Since DR/BDR election >>is a distributed algorithm dependent on the calculating routers state, it >>seems this won't help in all that many cases. >> >>Thanks, >>Acee >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 20 14:57:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBHAG-0007zf-HC for ospf-archive@LISTS.IETF.ORG; Mon, 20 Feb 2006 14:57:44 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBHAF-0003Ec-BG for ospf-archive@LISTS.IETF.ORG; Mon, 20 Feb 2006 14:57:44 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <9.0002F810@wildebeest.ease.lsoft.com>; Mon, 20 Feb 2006 14:57:42 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99941422 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 20 Feb 2006 14:57:42 -0500 Received: from 207.17.137.119 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 20 Feb 2006 14:57:42 -0500 Received: from unknown (HELO alpha.jnpr.net) ([172.24.18.126]) by borg.juniper.net with ESMTP; 20 Feb 2006 11:57:41 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,131,1139212800"; d="scan'208"; a="531289044:sNHT21969208" Received: from antineutrino.jnpr.net ([172.24.247.81]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Feb 2006 11:57:40 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Detecting router id change in p2p-over-lan connection Thread-Index: AcY2KgJ2vuW4H79SSYm90PwrzPiSkgALZrWg X-OriginalArrivalTime: 20 Feb 2006 19:57:40.0809 (UTC) FILETIME=[E7F20390:01C63657] Message-ID: <35D1C36F7A7EE440AC7AB6779451DD0104E5BC@antineutrino.jnpr.net> Date: Mon, 20 Feb 2006 11:57:40 -0800 Reply-To: Mailing List Sender: Mailing List From: Kalyan Bade Subject: Re: Detecting router id change in p2p-over-lan connection To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Hi Acee, > As Dave points out, a point-to-point network is explicitly defined as a > connection between > a single pair of routers. Also, RFC 2328 dictates that router-id be used > to identify neighbors > on point-to-point links. Hence, what > draft-ietf-isis-igp-p2p-over-lan-05.txt is recommending > is to take the path of least resistance and handle router-id changes by > letting the current > adjacency time out before forming a new one.=20 This might not work if the interface is defined as demand circuit. Thanks, Kalyan. From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 20 16:49:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBIuX-00069r-TA for ospf-archive@LISTS.IETF.ORG; Mon, 20 Feb 2006 16:49:37 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBIuW-0007Hm-Ly for ospf-archive@LISTS.IETF.ORG; Mon, 20 Feb 2006 16:49:37 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <14.0002FA11@wildebeest.ease.lsoft.com>; Mon, 20 Feb 2006 16:49:36 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99947791 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 20 Feb 2006 16:49:36 -0500 Received: from 171.71.176.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 20 Feb 2006 16:49:35 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 20 Feb 2006 13:49:16 -0800 X-IronPort-AV: i="4.02,131,1139212800"; d="scan'208"; a="407799067:sNHT1168739046" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k1KLmZh6024930 for ; Mon, 20 Feb 2006 13:49:14 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Feb 2006 16:49:10 -0500 Received: from [10.82.240.109] ([10.82.240.109]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Feb 2006 16:49:09 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <35D1C36F7A7EE440AC7AB6779451DD0104E5BC@antineutrino.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Feb 2006 21:49:09.0959 (UTC) FILETIME=[7AFD4D70:01C63667] Message-ID: <43FA3955.3000202@cisco.com> Date: Mon, 20 Feb 2006 16:49:09 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Detecting router id change in p2p-over-lan connection To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <35D1C36F7A7EE440AC7AB6779451DD0104E5BC@antineutrino.jnpr.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Hi Kalyan, Kalyan Bade wrote: >Hi Acee, > > > >>As Dave points out, a point-to-point network is explicitly defined as >> >> >a > > >>connection between >>a single pair of routers. Also, RFC 2328 dictates that router-id be >> >> >used > > >>to identify neighbors >>on point-to-point links. Hence, what >>draft-ietf-isis-igp-p2p-over-lan-05.txt is recommending >>is to take the path of least resistance and handle router-id changes >> >> >by > > >>letting the current >>adjacency time out before forming a new one. >> >> > >This might not work if the interface is defined as demand circuit. > > Good point - We're in the process of discussing whether this behavior should be in the draft. Possibly, handling detection of a router-id change on a P2P over LAN link differently than a normal P2P link may be a bad idea. Thanks, Acee >Thanks, >Kalyan. > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 20 17:39:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBJgX-0007M2-Qy for ospf-archive@LISTS.IETF.ORG; Mon, 20 Feb 2006 17:39:13 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBJgW-0000Nr-Kk for ospf-archive@LISTS.IETF.ORG; Mon, 20 Feb 2006 17:39:13 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <14.0002FB01@wildebeest.ease.lsoft.com>; Mon, 20 Feb 2006 17:39:10 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99950269 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 20 Feb 2006 17:39:10 -0500 Received: from 207.17.137.119 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 20 Feb 2006 17:39:10 -0500 Received: from unknown (HELO gamma.jnpr.net) ([172.24.245.25]) by borg.juniper.net with ESMTP; 20 Feb 2006 14:39:09 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,132,1139212800"; d="scan'208"; a="531316406:sNHT22787758" Received: from antineutrino.jnpr.net ([172.24.247.81]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Feb 2006 14:39:08 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Detecting router id change in p2p-over-lan connection Thread-Index: AcY2Z5PJLe9UyL/cTpatqtCj207wqQABYgGA X-OriginalArrivalTime: 20 Feb 2006 22:39:08.0936 (UTC) FILETIME=[7684E080:01C6366E] Message-ID: <35D1C36F7A7EE440AC7AB6779451DD0104E5BD@antineutrino.jnpr.net> Date: Mon, 20 Feb 2006 14:39:08 -0800 Reply-To: Mailing List Sender: Mailing List From: Kalyan Bade Subject: Re: Detecting router id change in p2p-over-lan connection To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Acee, > >This might not work if the interface is defined as demand circuit. > > > > > Good point - We're in the process of discussing whether this behavior > should be in the > draft. Possibly, handling detection of a router-id change on a P2P over > LAN link > differently than a normal P2P link may be a bad idea. How about bringing down the neighbor (rather than ignoring) when a third neighbor on a P2P over LAN sends a new hello? This creates unnecessary flaps, but again having more than 2 routers on a p2p LAN is a misconfig. Atleast, the processing will be similar to a regular p2p interface. Thanks, Kalyan. From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 20 18:26:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBKPo-0008Qo-Dz for ospf-archive@LISTS.IETF.ORG; Mon, 20 Feb 2006 18:26:00 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBKPo-0001p4-7F for ospf-archive@LISTS.IETF.ORG; Mon, 20 Feb 2006 18:26:00 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <13.0002FB5D@wildebeest.ease.lsoft.com>; Mon, 20 Feb 2006 18:25:59 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99953985 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 20 Feb 2006 18:25:59 -0500 Received: from 171.71.176.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 20 Feb 2006 18:25:54 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 20 Feb 2006 15:25:54 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1KNPkgi014887 for ; Mon, 20 Feb 2006 15:25:51 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Feb 2006 18:25:50 -0500 Received: from [10.82.240.109] ([10.82.240.109]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Feb 2006 18:25:50 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <35D1C36F7A7EE440AC7AB6779451DD0104E5BD@antineutrino.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Feb 2006 23:25:50.0901 (UTC) FILETIME=[FC9ECE50:01C63674] Message-ID: <43FA4FFE.1070908@cisco.com> Date: Mon, 20 Feb 2006 18:25:50 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Detecting router id change in p2p-over-lan connection To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <35D1C36F7A7EE440AC7AB6779451DD0104E5BD@antineutrino.jnpr.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Kalyan Bade wrote: >Acee, > > > >>>This might not work if the interface is defined as demand circuit. >>> >>> >>> >>> >>Good point - We're in the process of discussing whether this behavior >>should be in the >>draft. Possibly, handling detection of a router-id change on a P2P >> >> >over > > >>LAN link >>differently than a normal P2P link may be a bad idea. >> >> > >How about bringing down the neighbor (rather than ignoring) when a third >neighbor on a P2P over LAN sends a new hello? This creates unnecessary >flaps, but again having more than 2 routers on a p2p LAN is a misconfig. >Atleast, the processing will be similar to a regular p2p interface. > > That would be fine and consistent with what most routers do on normal P2P links. I think the P2P over LAN specific router-ID change processing should be removed from the draft. Thanks, Acee >Thanks, >Kalyan. > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 20 22:41:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBOP2-0005o2-3N for ospf-archive@LISTS.IETF.ORG; Mon, 20 Feb 2006 22:41:28 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBOP1-0008KP-Oj for ospf-archive@LISTS.IETF.ORG; Mon, 20 Feb 2006 22:41:28 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <3.0003003F@wildebeest.ease.lsoft.com>; Mon, 20 Feb 2006 22:37:43 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99966295 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 20 Feb 2006 22:37:42 -0500 Received: from 207.17.137.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 20 Feb 2006 22:05:50 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k1L35eX89505 for ; Mon, 20 Feb 2006 19:05:40 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.53] ([172.16.12.53]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k1L35Y597687 for ; Mon, 20 Feb 2006 19:05:34 -0800 (PST) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v746.2) References: <6D975E431022374F9F7A298A511427B61936EE@mailblr1.engineering.netscaler.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.746.2) Message-ID: <29E43652-5AF0-4219-B8D7-2CE0090A72F1@juniper.net> Date: Mon, 20 Feb 2006 19:05:31 -0800 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: Detecting router id change in p2p-over-lan connection To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <6D975E431022374F9F7A298A511427B61936EE@mailblr1.engineering.netscaler.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 On Feb 19, 2006, at 10:50 PM, Nitin Kakkar wrote: > IMHO OSPF spec does not say that P2P adjacencies should be > restricted to > only one peer. (But I haven't read rfc for long time so if does say > that > some where please let me know) From the spec: Point-to-point networks A network that joins a single pair of routers. A 56Kb serial line is an example of a point-to-point network. The vertices of the graph consist of routers and networks. A graph edge connects two routers when they are attached via a physical point-to-point network. Lines between routers indicate point-to-point networks. Etc. It is completely fundamental to the way the protocol works. > > How this is possible, Well have two routers with OSPF adjacency and > large dead interval. Change router-id on one of them. ( Note that some > implementations do send one way hello for router-id change they will > behave differently but again ospf spec does not mention that > either) but > others will show 2 adjacencies till one of the peer ages out. Ah, OK, I thought you were saying that you could have adjacencies to two different systems. Having said that, there is still a fundamental assumption here, namely that the new system supercedes the old at the time when the new adjacency comes up (the local router must not advertise adjacency to the old router ID.) The local router can *not* make the assumption that the new adjacency is to the same system, and in fact the local router has no way of ever knowing, or there are all kinds of really ugly black hole scenarios. There is effectively only one adjacency, regardless of what the "show" command says. > > IMHO On P2P cable move should trigger Loss of signal->link-down/ > link-up > events which inturn is IFSM_DOWN-> KILL NBR. In this case there > won't be > any Nbr history. But if there is a L2 device in between peer then yes > there wont be any link down event. You cannot assume that there will be a link down event. It obviously helps speed things along (BFD serves a similar purpose.) Particularly in the LAN environment, the odds of a link down event are slim. --Dave From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 20 23:53:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBPWR-0007HH-OD for ospf-archive@LISTS.IETF.ORG; Mon, 20 Feb 2006 23:53:11 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBPWR-0001az-GR for ospf-archive@LISTS.IETF.ORG; Mon, 20 Feb 2006 23:53:11 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <10.00030193@wildebeest.ease.lsoft.com>; Mon, 20 Feb 2006 23:53:10 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99972631 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 20 Feb 2006 23:53:10 -0500 Received: from 207.17.137.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 20 Feb 2006 23:53:09 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k1L4r81Z060970 for ; Mon, 20 Feb 2006 20:53:08 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.53] ([172.16.12.53]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k1L4r8512714 for ; Mon, 20 Feb 2006 20:53:08 -0800 (PST) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v746.2) References: <35D1C36F7A7EE440AC7AB6779451DD0104E5BD@antineutrino.jnpr.net> <43FA4FFE.1070908@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.746.2) Message-ID: Date: Mon, 20 Feb 2006 20:53:01 -0800 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: Detecting router id change in p2p-over-lan connection To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43FA4FFE.1070908@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 RFC2328 is silent on what to do if you see a different router ID on a P2P link; if you take it literally, you will create two adjacencies (temporarily), advertise both in your router LSA, and your network will most likely black hole traffic until one of them times out. On real P2P links, this will suffice (if you don't mind a network outage for the dead time of the old adjacency) and things will eventually stabilize since it is "impossible" (cough) two get two neighbors in 2Way. The fact that it is underspecified doesn't matter that much. In the P2P-over-LAN case, there needs to be a mechanism to try to do something useful if there turn out to be more than two routers on the link. I don't think it's reasonable to say "gee it's misconfigured, we don't care what happens to the network." It seems to me that there are two possible cases, namely, use the old adjacency until it times out (effectively ignoring the hellos from the new guy) or to form an adjacency with the new guy (and blow away or otherwise ignore the old guy.) The first case has the advantage of stability and simplicity--the third router that shows up for the party will be ignored by both parties. There is a potential for a circle of one-way adjacencies to stabilize, but this will still be stable (there won't be a usable adjacency across the subnetwork.) The second case has the advantage that it adapts more quickly when something changes. Some implementations already do this for the pure P2P case. However, it is destabilizing in the misconfiguration case, as the router will flap its router LSA each time another Hello is received. Probably the only reasonable way out would be to detect the flap and then choose one neighbor and stick to it, ignoring the other (which degenerates into the first case.) Given all of this, I'd propose that the right thing to do is the first case, and suffer through the dead time (or use BFD and suffer through the detection time.) (A third possible case would be to actually bring up the adjacency and end up running full-mesh multipoint, which would probably even work, but would be butt ugly.) --Dave On Feb 20, 2006, at 3:25 PM, Acee Lindem wrote: > Kalyan Bade wrote: > >> Acee, >> >> >>>> This might not work if the interface is defined as demand circuit. >>>> >>>> >>>> >>> Good point - We're in the process of discussing whether this >>> behavior >>> should be in the >>> draft. Possibly, handling detection of a router-id change on a P2P >>> >> over >> >>> LAN link >>> differently than a normal P2P link may be a bad idea. >>> >> >> How about bringing down the neighbor (rather than ignoring) when a >> third >> neighbor on a P2P over LAN sends a new hello? This creates >> unnecessary >> flaps, but again having more than 2 routers on a p2p LAN is a >> misconfig. >> Atleast, the processing will be similar to a regular p2p interface. >> > That would be fine and consistent with what most routers do on > normal P2P links. I think the > P2P over LAN specific router-ID change processing should be removed > from the draft. > > Thanks, > Acee > >> Thanks, >> Kalyan. >> >> > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 21 00:39:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBQFC-0008Ng-7V for ospf-archive@LISTS.IETF.ORG; Tue, 21 Feb 2006 00:39:26 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBQFB-0003SI-Uy for ospf-archive@LISTS.IETF.ORG; Tue, 21 Feb 2006 00:39:26 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <12.0003023D@wildebeest.ease.lsoft.com>; Tue, 21 Feb 2006 0:39:25 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99976172 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 21 Feb 2006 00:39:25 -0500 Received: from 171.68.10.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 21 Feb 2006 00:39:25 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 20 Feb 2006 21:39:26 -0800 X-IronPort-AV: i="4.02,133,1139212800"; d="scan'208"; a="256685194:sNHT31851688" Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k1L5dMub028057 for ; Mon, 20 Feb 2006 21:39:22 -0800 (PST) User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <35D1C36F7A7EE440AC7AB6779451DD0104E5BD@antineutrino.jnpr.net> <43FA4FFE.1070908@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <43FAA799.2000705@cisco.com> Date: Mon, 20 Feb 2006 21:39:37 -0800 Reply-To: Mailing List Sender: Mailing List From: Naiming Shen Subject: Re: Detecting router id change in p2p-over-lan connection To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Agree with Dave's argument, and this is the same idea as in the current draft of p2p-over-lan (section 4.5): ... If the system ID or the router ID of incoming hello packet does not match the system ID or the router ID of already established adjacency over this p2p-over-lan circuit, it MUST discard the packet. The implementation should offer logging and debugging information of the above events. Do we need to change anything here? thanks. - Naiming Dave Katz said the following on 02/20/2006 08:53 PM: > RFC2328 is silent on what to do if you see a different router ID on a > P2P link; if you take it literally, you will create two adjacencies > (temporarily), advertise both in your router LSA, and your network will > most likely black hole traffic until one of them times out. > > On real P2P links, this will suffice (if you don't mind a network > outage for the dead time of the old adjacency) and things will > eventually stabilize since it is "impossible" (cough) two get two > neighbors in 2Way. The fact that it is underspecified doesn't matter > that much. > > In the P2P-over-LAN case, there needs to be a mechanism to try to do > something useful if there turn out to be more than two routers on the > link. I don't think it's reasonable to say "gee it's misconfigured, we > don't care what happens to the network." > > > It seems to me that there are two possible cases, namely, use the old > adjacency until it times out (effectively ignoring the hellos from the > new guy) or to form an adjacency with the new guy (and blow away or > otherwise ignore the old guy.) > > The first case has the advantage of stability and simplicity--the third > router that shows up for the party will be ignored by both parties. > There is a potential for a circle of one-way adjacencies to stabilize, > but this will still be stable (there won't be a usable adjacency across > the subnetwork.) > > The second case has the advantage that it adapts more quickly when > something changes. Some implementations already do this for the pure > P2P case. However, it is destabilizing in the misconfiguration case, > as the router will flap its router LSA each time another Hello is > received. Probably the only reasonable way out would be to detect the > flap and then choose one neighbor and stick to it, ignoring the other > (which degenerates into the first case.) > > Given all of this, I'd propose that the right thing to do is the first > case, and suffer through the dead time (or use BFD and suffer through > the detection time.) > > (A third possible case would be to actually bring up the adjacency and > end up running full-mesh multipoint, which would probably even work, > but would be butt ugly.) > > --Dave > > > On Feb 20, 2006, at 3:25 PM, Acee Lindem wrote: > >> Kalyan Bade wrote: >> >>> Acee, >>> >>> >>>>> This might not work if the interface is defined as demand circuit. >>>>> >>>>> >>>>> >>>> Good point - We're in the process of discussing whether this behavior >>>> should be in the >>>> draft. Possibly, handling detection of a router-id change on a P2P >>>> >>> over >>> >>>> LAN link >>>> differently than a normal P2P link may be a bad idea. >>>> >>> >>> How about bringing down the neighbor (rather than ignoring) when a >>> third >>> neighbor on a P2P over LAN sends a new hello? This creates unnecessary >>> flaps, but again having more than 2 routers on a p2p LAN is a >>> misconfig. >>> Atleast, the processing will be similar to a regular p2p interface. >>> >> That would be fine and consistent with what most routers do on normal >> P2P links. I think the >> P2P over LAN specific router-ID change processing should be removed >> from the draft. >> >> Thanks, >> Acee >> >>> Thanks, >>> Kalyan. >>> >>> >> From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 21 02:05:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBRaT-000342-Qc for ospf-archive@LISTS.IETF.ORG; Tue, 21 Feb 2006 02:05:29 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBRaS-0005nQ-KA for ospf-archive@LISTS.IETF.ORG; Tue, 21 Feb 2006 02:05:29 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <1.00030366@wildebeest.ease.lsoft.com>; Tue, 21 Feb 2006 2:05:26 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99979415 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 21 Feb 2006 02:05:25 -0500 Received: from 12.178.35.128 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 21 Feb 2006 02:05:25 -0500 Received: from mailblr1.engineering.netscaler.com ([10.102.1.9]) by mailsj.engineering.netscaler.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Feb 2006 23:01:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Detecting router id change in p2p-over-lan connection Thread-Index: AcY2dQZfFR52D5Q9TkmuNhpsN5PKAgAP8ZDQ X-OriginalArrivalTime: 21 Feb 2006 07:01:20.0442 (UTC) FILETIME=[9E4BD1A0:01C636B4] Message-ID: <6D975E431022374F9F7A298A511427B61936F1@mailblr1.engineering.netscaler.com> Date: Tue, 21 Feb 2006 12:35:20 +0530 Reply-To: Mailing List Sender: Mailing List From: Nitin Kakkar Subject: Re: Detecting router id change in p2p-over-lan connection To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 HI Acee, Personal message just for FYI. Cisco support multiple ospf adjacencies on P2P. The reason being I vaguely remember some patents by "Alex Zini" which uses a backup routerid to retrieve data from peer.=20 Regards Nitin -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee Lindem Sent: Tuesday, February 21, 2006 4:56 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Detecting router id change in p2p-over-lan connection Kalyan Bade wrote: >Acee, > > =20 > >>>This might not work if the interface is defined as demand circuit. >>> >>> >>> =20 >>> >>Good point - We're in the process of discussing whether this behavior >>should be in the >>draft. Possibly, handling detection of a router-id change on a P2P >> =20 >> >over > =20 > >>LAN link >>differently than a normal P2P link may be a bad idea. >> =20 >> > >How about bringing down the neighbor (rather than ignoring) when a third >neighbor on a P2P over LAN sends a new hello? This creates unnecessary >flaps, but again having more than 2 routers on a p2p LAN is a misconfig. >Atleast, the processing will be similar to a regular p2p interface. > =20 > That would be fine and consistent with what most routers do on normal=20 P2P links. I think the P2P over LAN specific router-ID change processing should be removed from the draft. Thanks, Acee >Thanks, >Kalyan. > > =20 > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 21 06:25:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBVeL-0008To-Ge for ospf-archive@LISTS.IETF.ORG; Tue, 21 Feb 2006 06:25:45 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBVeL-0006YZ-87 for ospf-archive@LISTS.IETF.ORG; Tue, 21 Feb 2006 06:25:45 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <8.0003066D@wildebeest.ease.lsoft.com>; Tue, 21 Feb 2006 6:25:44 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 99998702 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 21 Feb 2006 06:25:44 -0500 Received: from 12.178.35.128 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 21 Feb 2006 06:25:44 -0500 Received: from mailblr1.engineering.netscaler.com ([10.102.1.9]) by mailsj.engineering.netscaler.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Feb 2006 03:21:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Detecting router id change in p2p-over-lan connection Thread-Index: AcY2qTQaXRxZwFZTRo2iOd+uZlhAnwAL6d4g X-OriginalArrivalTime: 21 Feb 2006 11:21:38.0708 (UTC) FILETIME=[FB821540:01C636D8] Message-ID: <6D975E431022374F9F7A298A511427B61936F6@mailblr1.engineering.netscaler.com> Date: Tue, 21 Feb 2006 16:55:37 +0530 Reply-To: Mailing List Sender: Mailing List From: Nitin Kakkar Subject: Re: Detecting router id change in p2p-over-lan connection To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d In the event of router id change, Wouldn't this delay new adjacency by at least dead interval? To prevent that may be we can explicitly mention that whenever router-id is administratively removed, ospf should explicitly teardown adjacency Nitin -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Naiming Shen Sent: Tuesday, February 21, 2006 11:10 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Detecting router id change in p2p-over-lan connection Agree with Dave's argument, and this is the same idea as in the current draft of p2p-over-lan (section 4.5): ... If the system ID or the router ID of incoming hello packet does not match the system ID or the router ID of already established adjacency over this p2p-over-lan circuit, it MUST discard the packet. The implementation should offer logging and debugging information of the above events. Do we need to change anything here? thanks. - Naiming Dave Katz said the following on 02/20/2006 08:53 PM: > RFC2328 is silent on what to do if you see a different router ID on a > P2P link; if you take it literally, you will create two adjacencies =20 > (temporarily), advertise both in your router LSA, and your network will=20 > most likely black hole traffic until one of them times out. >=20 > On real P2P links, this will suffice (if you don't mind a network =20 > outage for the dead time of the old adjacency) and things will =20 > eventually stabilize since it is "impossible" (cough) two get two =20 > neighbors in 2Way. The fact that it is underspecified doesn't matter > that much. >=20 > In the P2P-over-LAN case, there needs to be a mechanism to try to do =20 > something useful if there turn out to be more than two routers on the > link. I don't think it's reasonable to say "gee it's misconfigured, we=20 > don't care what happens to the network." >=20 >=20 > It seems to me that there are two possible cases, namely, use the old > adjacency until it times out (effectively ignoring the hellos from the=20 > new guy) or to form an adjacency with the new guy (and blow away or=20 > otherwise ignore the old guy.) >=20 > The first case has the advantage of stability and simplicity--the third=20 > router that shows up for the party will be ignored by both parties. =20 > There is a potential for a circle of one-way adjacencies to stabilize,=20 > but this will still be stable (there won't be a usable adjacency across=20 > the subnetwork.) >=20 > The second case has the advantage that it adapts more quickly when =20 > something changes. Some implementations already do this for the pure > P2P case. However, it is destabilizing in the misconfiguration case, > as the router will flap its router LSA each time another Hello is =20 > received. Probably the only reasonable way out would be to detect the=20 > flap and then choose one neighbor and stick to it, ignoring the other > (which degenerates into the first case.) >=20 > Given all of this, I'd propose that the right thing to do is the first=20 > case, and suffer through the dead time (or use BFD and suffer through > the detection time.) >=20 > (A third possible case would be to actually bring up the adjacency and=20 > end up running full-mesh multipoint, which would probably even work,=20 > but would be butt ugly.) >=20 > --Dave >=20 >=20 > On Feb 20, 2006, at 3:25 PM, Acee Lindem wrote: >=20 >> Kalyan Bade wrote: >> >>> Acee, >>> >>> >>>>> This might not work if the interface is defined as demand circuit. >>>>> >>>>> >>>>> >>>> Good point - We're in the process of discussing whether this behavior >>>> should be in the >>>> draft. Possibly, handling detection of a router-id change on a P2P >>>> >>> over >>> >>>> LAN link >>>> differently than a normal P2P link may be a bad idea. >>>> >>> >>> How about bringing down the neighbor (rather than ignoring) when a =20 >>> third >>> neighbor on a P2P over LAN sends a new hello? This creates unnecessary >>> flaps, but again having more than 2 routers on a p2p LAN is a =20 >>> misconfig. >>> Atleast, the processing will be similar to a regular p2p interface. >>> >> That would be fine and consistent with what most routers do on normal=20 >> P2P links. I think the >> P2P over LAN specific router-ID change processing should be removed =20 >> from the draft. >> >> Thanks, >> Acee >> >>> Thanks, >>> Kalyan. >>> >>> >> From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 21 07:55:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBX2s-0003TL-3t for ospf-archive@LISTS.IETF.ORG; Tue, 21 Feb 2006 07:55:10 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBX2o-00014q-SS for ospf-archive@LISTS.IETF.ORG; Tue, 21 Feb 2006 07:55:10 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <11.00030901@wildebeest.ease.lsoft.com>; Tue, 21 Feb 2006 7:55:06 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100003118 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 21 Feb 2006 07:55:06 -0500 Received: from 12.129.211.51 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 21 Feb 2006 07:55:06 -0500 Received: from huawei.com ([172.24.2.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV100AT0F6ORH@usaga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 21 Feb 2006 04:40:00 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV100MYBFWTK5@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 21 Feb 2006 20:55:41 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV100JO2FWS1E@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 21 Feb 2006 20:55:40 +0800 (CST) Received: from k49110 ([10.111.12.97]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IV100MCSFWKPL@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 21 Feb 2006 20:55:32 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <43F63D76.4030009@cisco.com> <000b01c635cb$cddcca30$610c6f0a@china.huawei.com> <43F9DD10.8040305@cisco.com> Message-ID: <001601c636e4$5ea03980$610c6f0a@china.huawei.com> Date: Tue, 21 Feb 2006 20:43:09 +0800 Reply-To: Mailing List Sender: Mailing List From: Zengjie Kou Subject: Re: draft-kou-ospf-immediately-replying-hello-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Hi, Acee, You are right, immediate hello does not provide the mechanism of detecting link down fast. But, immediate hello improve to discover neighbors when interface goes down then up. In practice, the requirement is needed. Thanks, Zengjie ----- Original Message ----- From: "Acee Lindem" To: Sent: Monday, February 20, 2006 11:15 PM Subject: Re: draft-kou-ospf-immediately-replying-hello-00.txt > Hi Zengjie, > > Zengjie Kou wrote: > >>Hi,Acee, >> If a router interface whose role is changed(e.g.DR goes down), the router will notify all routers about the change by immediate hello. >> >> > This is only when the DR/BDR knows that it is going down or the case > where the router > priority is set to 0. > > For a router becoming DR/BDR, all the routers should elect the same DR/BDR > so I don't see how it helps. > > Thanks, > Acee > >> After all router get the change, election will be reprocessed. In contrast to normal hello, immediate hello avoid the backupSeen. >> Namely, improving convergence. >> >>Thanks a lot, >>Zengjie >> >>----- Original Message ----- >>From: "Acee Lindem" >>To: >>Sent: Saturday, February 18, 2006 5:17 AM >>Subject: draft-kou-ospf-immediately-replying-hello-00.txt >> >> >> >> >>>Hi Zengjie, >>> >>>Under what situations does having the router who changed to/from >>>DR/BDR improve convergence (section 6.2)? Since DR/BDR election >>>is a distributed algorithm dependent on the calculating routers state, it >>>seems this won't help in all that many cases. >>> >>>Thanks, >>>Acee >>> >>> >> >> >> From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 21 09:05:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBY8X-0007zV-5d for ospf-archive@LISTS.IETF.ORG; Tue, 21 Feb 2006 09:05:05 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBY8W-0003eY-Pb for ospf-archive@LISTS.IETF.ORG; Tue, 21 Feb 2006 09:05:05 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <5.00030A2B@wildebeest.ease.lsoft.com>; Tue, 21 Feb 2006 9:05:04 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100006879 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 21 Feb 2006 09:05:04 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 21 Feb 2006 09:05:04 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 21 Feb 2006 06:05:04 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,134,1139212800"; d="scan'208"; a="22317130:sNHT25006256" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1LE4lPW016792 for ; Tue, 21 Feb 2006 09:05:01 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Feb 2006 09:04:57 -0500 Received: from [10.82.216.55] ([10.82.216.55]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Feb 2006 09:04:57 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <35D1C36F7A7EE440AC7AB6779451DD0104E5BD@antineutrino.jnpr.net> <43FA4FFE.1070908@cisco.com> <43FAA799.2000705@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Feb 2006 14:04:57.0142 (UTC) FILETIME=[CBD47560:01C636EF] Message-ID: <43FB1E08.9000009@cisco.com> Date: Tue, 21 Feb 2006 09:04:56 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Detecting router id change in p2p-over-lan connection To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43FAA799.2000705@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Naiming Shen wrote: > Agree with Dave's argument, and this is the same idea as in the > current draft of p2p-over-lan (section 4.5): > > ... If the system ID or the > router ID of incoming hello packet does not match the system ID or > the router ID of already established adjacency over this p2p-over-lan > circuit, it MUST discard the packet. The implementation should offer > logging and debugging information of the above events. > > Do we need to change anything here? Hi Naiming, Given that this situation can happen in the case of misconfiguration or router-ID change, I wouldn't optimize for the former. Especially considering Kalyan's point that if hello's are suppressed, the router-id change will either not be recognized or require additional logic. I'd vote to either leave it unspecified (consistent with RFC 2328's omission of router-id change P2P link handling) or discard the old neighbor and bring up an adjacency with the new (which is what at least one implementation does today). Thanks, Acee Thanks, Acee > > thanks. > - Naiming > > Dave Katz said the following on 02/20/2006 08:53 PM: > >> RFC2328 is silent on what to do if you see a different router ID on >> a P2P link; if you take it literally, you will create two >> adjacencies (temporarily), advertise both in your router LSA, and >> your network will most likely black hole traffic until one of them >> times out. >> >> On real P2P links, this will suffice (if you don't mind a network >> outage for the dead time of the old adjacency) and things will >> eventually stabilize since it is "impossible" (cough) two get two >> neighbors in 2Way. The fact that it is underspecified doesn't >> matter that much. >> >> In the P2P-over-LAN case, there needs to be a mechanism to try to do >> something useful if there turn out to be more than two routers on >> the link. I don't think it's reasonable to say "gee it's >> misconfigured, we don't care what happens to the network." >> >> >> It seems to me that there are two possible cases, namely, use the >> old adjacency until it times out (effectively ignoring the hellos >> from the new guy) or to form an adjacency with the new guy (and blow >> away or otherwise ignore the old guy.) >> >> The first case has the advantage of stability and simplicity--the >> third router that shows up for the party will be ignored by both >> parties. There is a potential for a circle of one-way adjacencies >> to stabilize, but this will still be stable (there won't be a >> usable adjacency across the subnetwork.) >> >> The second case has the advantage that it adapts more quickly when >> something changes. Some implementations already do this for the >> pure P2P case. However, it is destabilizing in the misconfiguration >> case, as the router will flap its router LSA each time another Hello >> is received. Probably the only reasonable way out would be to >> detect the flap and then choose one neighbor and stick to it, >> ignoring the other (which degenerates into the first case.) >> >> Given all of this, I'd propose that the right thing to do is the >> first case, and suffer through the dead time (or use BFD and suffer >> through the detection time.) >> >> (A third possible case would be to actually bring up the adjacency >> and end up running full-mesh multipoint, which would probably even >> work, but would be butt ugly.) >> >> --Dave >> >> >> On Feb 20, 2006, at 3:25 PM, Acee Lindem wrote: >> >>> Kalyan Bade wrote: >>> >>>> Acee, >>>> >>>> >>>>>> This might not work if the interface is defined as demand circuit. >>>>>> >>>>>> >>>>>> >>>>> Good point - We're in the process of discussing whether this >>>>> behavior >>>>> should be in the >>>>> draft. Possibly, handling detection of a router-id change on a P2P >>>>> >>>> over >>>> >>>>> LAN link >>>>> differently than a normal P2P link may be a bad idea. >>>>> >>>> >>>> How about bringing down the neighbor (rather than ignoring) when a >>>> third >>>> neighbor on a P2P over LAN sends a new hello? This creates >>>> unnecessary >>>> flaps, but again having more than 2 routers on a p2p LAN is a >>>> misconfig. >>>> Atleast, the processing will be similar to a regular p2p interface. >>>> >>> That would be fine and consistent with what most routers do on >>> normal P2P links. I think the >>> P2P over LAN specific router-ID change processing should be removed >>> from the draft. >>> >>> Thanks, >>> Acee >>> >>>> Thanks, >>>> Kalyan. >>>> >>>> >>> > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 21 11:13:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBa8z-0001EZ-EC for ospf-archive@LISTS.IETF.ORG; Tue, 21 Feb 2006 11:13:41 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBa8z-0002MZ-4c for ospf-archive@LISTS.IETF.ORG; Tue, 21 Feb 2006 11:13:41 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <12.00030C04@wildebeest.ease.lsoft.com>; Tue, 21 Feb 2006 11:13:40 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100016852 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 21 Feb 2006 11:13:40 -0500 Received: from 207.17.137.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 21 Feb 2006 11:13:39 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k1LGDcX17947 for ; Tue, 21 Feb 2006 08:13:38 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.53] ([172.16.12.53]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k1LGDX562812 for ; Tue, 21 Feb 2006 08:13:33 -0800 (PST) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v746.2) References: <35D1C36F7A7EE440AC7AB6779451DD0104E5BD@antineutrino.jnpr.net> <43FA4FFE.1070908@cisco.com> <43FAA799.2000705@cisco.com> <43FB1E08.9000009@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.746.2) Message-ID: <97F5C5F3-1933-46F6-A2E6-1484D3032CB5@juniper.net> Date: Tue, 21 Feb 2006 08:13:19 -0800 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: Detecting router id change in p2p-over-lan connection To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43FB1E08.9000009@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 On Feb 21, 2006, at 6:04 AM, Acee Lindem wrote: > Naiming Shen wrote: > >> Agree with Dave's argument, and this is the same idea as in the >> current draft of p2p-over-lan (section 4.5): >> >> ... If the system ID or the >> router ID of incoming hello packet does not match the system ID or >> the router ID of already established adjacency over this p2p- >> over-lan >> circuit, it MUST discard the packet. The implementation should >> offer >> logging and debugging information of the above events. >> >> Do we need to change anything here? > > Hi Naiming, > > Given that this situation can happen in the case of > misconfiguration or > router-ID change, I wouldn't optimize for the former. Especially > considering Kalyan's point that if hello's are suppressed, the > router-id change > will either not be recognized or require additional logic. I'd vote > to either > leave it unspecified (consistent with RFC 2328's omission of router-id > change P2P link handling) or discard the old neighbor and bring up > an adjacency with the new (which is what at least one > implementation does > today). My libertarian streak says to leave anything unspecified that does not impact interoperability (a philosophy absent from the OSPF spec, which has normative text for all kinds of unnecessary things.) Indeed, the handling of this case is not an interoperability issue. Given the failure modes caused by misconfiguration, however, I would campaign for having a SHOULD on detecting the misconfiguration, which will otherwise look like mysterious adjacency flapping, or the inability for adjacencies to come up, or something. It should be pretty trivial to detect the fact that you're actively receiving Hellos from multiple systems on what is supposedly a point-to-point medium. --Dave > > Thanks, > Acee > > Thanks, > Acee > >> >> thanks. >> - Naiming >> >> Dave Katz said the following on 02/20/2006 08:53 PM: >> >>> RFC2328 is silent on what to do if you see a different router ID >>> on a P2P link; if you take it literally, you will create two >>> adjacencies (temporarily), advertise both in your router LSA, >>> and your network will most likely black hole traffic until one >>> of them times out. >>> >>> On real P2P links, this will suffice (if you don't mind a >>> network outage for the dead time of the old adjacency) and >>> things will eventually stabilize since it is >>> "impossible" (cough) two get two neighbors in 2Way. The fact >>> that it is underspecified doesn't matter that much. >>> >>> In the P2P-over-LAN case, there needs to be a mechanism to try to >>> do something useful if there turn out to be more than two >>> routers on the link. I don't think it's reasonable to say "gee >>> it's misconfigured, we don't care what happens to the network." >>> >>> >>> It seems to me that there are two possible cases, namely, use the >>> old adjacency until it times out (effectively ignoring the >>> hellos from the new guy) or to form an adjacency with the new >>> guy (and blow away or otherwise ignore the old guy.) >>> >>> The first case has the advantage of stability and simplicity-- >>> the third router that shows up for the party will be ignored by >>> both parties. There is a potential for a circle of one-way >>> adjacencies to stabilize, but this will still be stable (there >>> won't be a usable adjacency across the subnetwork.) >>> >>> The second case has the advantage that it adapts more quickly >>> when something changes. Some implementations already do this >>> for the pure P2P case. However, it is destabilizing in the >>> misconfiguration case, as the router will flap its router LSA >>> each time another Hello is received. Probably the only >>> reasonable way out would be to detect the flap and then choose >>> one neighbor and stick to it, ignoring the other (which >>> degenerates into the first case.) >>> >>> Given all of this, I'd propose that the right thing to do is the >>> first case, and suffer through the dead time (or use BFD and >>> suffer through the detection time.) >>> >>> (A third possible case would be to actually bring up the >>> adjacency and end up running full-mesh multipoint, which would >>> probably even work, but would be butt ugly.) >>> >>> --Dave >>> >>> >>> On Feb 20, 2006, at 3:25 PM, Acee Lindem wrote: >>> >>>> Kalyan Bade wrote: >>>> >>>>> Acee, >>>>> >>>>> >>>>>>> This might not work if the interface is defined as demand >>>>>>> circuit. >>>>>>> >>>>>>> >>>>>>> >>>>>> Good point - We're in the process of discussing whether this >>>>>> behavior >>>>>> should be in the >>>>>> draft. Possibly, handling detection of a router-id change on a >>>>>> P2P >>>>>> >>>>> over >>>>> >>>>>> LAN link >>>>>> differently than a normal P2P link may be a bad idea. >>>>>> >>>>> >>>>> How about bringing down the neighbor (rather than ignoring) >>>>> when a third >>>>> neighbor on a P2P over LAN sends a new hello? This creates >>>>> unnecessary >>>>> flaps, but again having more than 2 routers on a p2p LAN is a >>>>> misconfig. >>>>> Atleast, the processing will be similar to a regular p2p >>>>> interface. >>>>> >>>> That would be fine and consistent with what most routers do on >>>> normal P2P links. I think the >>>> P2P over LAN specific router-ID change processing should be >>>> removed from the draft. >>>> >>>> Thanks, >>>> Acee >>>> >>>>> Thanks, >>>>> Kalyan. >>>>> >>>>> >>>> >> > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 21 15:09:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBdpJ-00069P-5S for ospf-archive@LISTS.IETF.ORG; Tue, 21 Feb 2006 15:09:37 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBdpI-0005ZB-Qq for ospf-archive@LISTS.IETF.ORG; Tue, 21 Feb 2006 15:09:37 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <5.00031084@wildebeest.ease.lsoft.com>; Tue, 21 Feb 2006 15:09:36 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100031236 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 21 Feb 2006 15:09:35 -0500 Received: from 171.68.10.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 21 Feb 2006 15:09:35 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 21 Feb 2006 12:09:35 -0800 X-IronPort-AV: i="4.02,135,1139212800"; d="scan'208"; a="256853483:sNHT33823420" Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k1LK9VZC028823 for ; Tue, 21 Feb 2006 12:09:32 -0800 (PST) User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <35D1C36F7A7EE440AC7AB6779451DD0104E5BD@antineutrino.jnpr.net> <43FA4FFE.1070908@cisco.com> <43FAA799.2000705@cisco.com> <43FB1E08.9000009@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <43FB738B.3000001@cisco.com> Date: Tue, 21 Feb 2006 12:09:47 -0800 Reply-To: Mailing List Sender: Mailing List From: Naiming Shen Subject: Re: Detecting router id change in p2p-over-lan connection To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43FB1E08.9000009@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Acee Lindem said the following on 02/21/2006 06:04 AM: > Naiming Shen wrote: > >> Agree with Dave's argument, and this is the same idea as in the >> current draft of p2p-over-lan (section 4.5): >> >> ... If the system ID or the >> router ID of incoming hello packet does not match the system ID or >> the router ID of already established adjacency over this p2p-over-lan >> circuit, it MUST discard the packet. The implementation should offer >> logging and debugging information of the above events. >> >> Do we need to change anything here? > > > Hi Naiming, > > Given that this situation can happen in the case of misconfiguration or > router-ID change, I wouldn't optimize for the former. Especially > considering Kalyan's point that if hello's are suppressed, the router-id > change > will either not be recognized or require additional logic. I'd vote to > either > leave it unspecified (consistent with RFC 2328's omission of router-id > change P2P link handling) or discard the old neighbor and bring up > an adjacency with the new (which is what at least one implementation does > today). Hello Acee, The original idea in the draft was to prevent multiple routers joinning onto the same LAN rather than handing the router-ID change from the same router. Even through there is a side effect to it. For the router-ID change issue. If one is willing to change router-ID or system-ID during normal operation, there are more things broken and there is nothing wrong to wait until the current adjacent timeout. If the hello is suppressed over the link, then the behaviour is not bounded by this paragraph since it does not say the purpose is to detect neighbor router-id change. Also there is little reason to suppress a hello over p2p-over-lan links. Thus I don't think router-id is an issue with this sentence. Since p2p-over-lan is different from normal p2p circuit that multiple routers can easily join the same LAN unintentionally. If we ignore the new station to join, then we can prevent the adjacency constant flapping(this does not happen to normal p2p link), the worst it can happen is slow to handle router-id change as mentioned above, which is a non issue. Thus I think it's a good thing to ignore the extra adjacency joinning. This sentence does not govern the normal p2p link behaviour so the implementation is ok(even prefered) to reset the existing adjacency on a normal p2p link. Thus I don't think we should say we must reset the current adjacency for p2p-over-lan. My preference of this sentence in the draft is with this order: - leave it as is - change the MUST to SHOULD - remove the router-id related sentence thanks. - Naiming > > Thanks, > Acee > > Thanks, > Acee > >> >> thanks. >> - Naiming >> >> Dave Katz said the following on 02/20/2006 08:53 PM: >> >>> RFC2328 is silent on what to do if you see a different router ID on >>> a P2P link; if you take it literally, you will create two >>> adjacencies (temporarily), advertise both in your router LSA, and >>> your network will most likely black hole traffic until one of them >>> times out. >>> >>> On real P2P links, this will suffice (if you don't mind a network >>> outage for the dead time of the old adjacency) and things will >>> eventually stabilize since it is "impossible" (cough) two get two >>> neighbors in 2Way. The fact that it is underspecified doesn't >>> matter that much. >>> >>> In the P2P-over-LAN case, there needs to be a mechanism to try to do >>> something useful if there turn out to be more than two routers on >>> the link. I don't think it's reasonable to say "gee it's >>> misconfigured, we don't care what happens to the network." >>> >>> >>> It seems to me that there are two possible cases, namely, use the >>> old adjacency until it times out (effectively ignoring the hellos >>> from the new guy) or to form an adjacency with the new guy (and blow >>> away or otherwise ignore the old guy.) >>> >>> The first case has the advantage of stability and simplicity--the >>> third router that shows up for the party will be ignored by both >>> parties. There is a potential for a circle of one-way adjacencies >>> to stabilize, but this will still be stable (there won't be a >>> usable adjacency across the subnetwork.) >>> >>> The second case has the advantage that it adapts more quickly when >>> something changes. Some implementations already do this for the >>> pure P2P case. However, it is destabilizing in the misconfiguration >>> case, as the router will flap its router LSA each time another Hello >>> is received. Probably the only reasonable way out would be to >>> detect the flap and then choose one neighbor and stick to it, >>> ignoring the other (which degenerates into the first case.) >>> >>> Given all of this, I'd propose that the right thing to do is the >>> first case, and suffer through the dead time (or use BFD and suffer >>> through the detection time.) >>> >>> (A third possible case would be to actually bring up the adjacency >>> and end up running full-mesh multipoint, which would probably even >>> work, but would be butt ugly.) >>> >>> --Dave >>> >>> >>> On Feb 20, 2006, at 3:25 PM, Acee Lindem wrote: >>> >>>> Kalyan Bade wrote: >>>> >>>>> Acee, >>>>> >>>>> >>>>>>> This might not work if the interface is defined as demand circuit. >>>>>>> >>>>>>> >>>>>>> >>>>>> Good point - We're in the process of discussing whether this >>>>>> behavior >>>>>> should be in the >>>>>> draft. Possibly, handling detection of a router-id change on a P2P >>>>>> >>>>> over >>>>> >>>>>> LAN link >>>>>> differently than a normal P2P link may be a bad idea. >>>>>> >>>>> >>>>> How about bringing down the neighbor (rather than ignoring) when a >>>>> third >>>>> neighbor on a P2P over LAN sends a new hello? This creates >>>>> unnecessary >>>>> flaps, but again having more than 2 routers on a p2p LAN is a >>>>> misconfig. >>>>> Atleast, the processing will be similar to a regular p2p interface. >>>>> >>>> That would be fine and consistent with what most routers do on >>>> normal P2P links. I think the >>>> P2P over LAN specific router-ID change processing should be removed >>>> from the draft. >>>> >>>> Thanks, >>>> Acee >>>> >>>>> Thanks, >>>>> Kalyan. >>>>> >>>>> >>>> >> From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 21 18:50:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBgS2-0000wx-LO for ospf-archive@LISTS.IETF.ORG; Tue, 21 Feb 2006 17:57:46 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBgHM-0007IG-Rm for ospf-archive@LISTS.IETF.ORG; Tue, 21 Feb 2006 17:46:45 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <7.00031317@wildebeest.ease.lsoft.com>; Tue, 21 Feb 2006 17:46:44 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100040341 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 21 Feb 2006 17:46:44 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 21 Feb 2006 17:46:44 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 21 Feb 2006 14:46:44 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,135,1139212800"; d="scan'208"; a="22362266:sNHT25729604" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1LMkJPa017473 for ; Tue, 21 Feb 2006 17:46:42 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Feb 2006 17:46:20 -0500 Received: from [10.82.216.55] ([10.82.216.55]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Feb 2006 17:46:19 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <35D1C36F7A7EE440AC7AB6779451DD0104E5BD@antineutrino.jnpr.net> <43FA4FFE.1070908@cisco.com> <43FAA799.2000705@cisco.com> <43FB1E08.9000009@cisco.com> <97F5C5F3-1933-46F6-A2E6-1484D3032CB5@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Feb 2006 22:46:19.0921 (UTC) FILETIME=[A1D1B810:01C63738] Message-ID: <43FB983B.3000504@cisco.com> Date: Tue, 21 Feb 2006 17:46:19 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Detecting router id change in p2p-over-lan connection To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <97F5C5F3-1933-46F6-A2E6-1484D3032CB5@juniper.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Hi Dave, Dave Katz wrote: > On Feb 21, 2006, at 6:04 AM, Acee Lindem wrote: > >> Naiming Shen wrote: >> >>> Agree with Dave's argument, and this is the same idea as in the >>> current draft of p2p-over-lan (section 4.5): >>> >>> ... If the system ID or the >>> router ID of incoming hello packet does not match the system ID or >>> the router ID of already established adjacency over this p2p- >>> over-lan >>> circuit, it MUST discard the packet. The implementation should >>> offer >>> logging and debugging information of the above events. >>> >>> Do we need to change anything here? >> >> >> Hi Naiming, >> >> Given that this situation can happen in the case of misconfiguration or >> router-ID change, I wouldn't optimize for the former. Especially >> considering Kalyan's point that if hello's are suppressed, the >> router-id change >> will either not be recognized or require additional logic. I'd vote >> to either >> leave it unspecified (consistent with RFC 2328's omission of router-id >> change P2P link handling) or discard the old neighbor and bring up >> an adjacency with the new (which is what at least one implementation >> does >> today). > > > My libertarian streak says to leave anything unspecified that does > not impact interoperability (a philosophy absent from the OSPF spec, > which has normative text for all kinds of unnecessary things.) > Indeed, the handling of this case is not an interoperability issue. > > Given the failure modes caused by misconfiguration, however, I would > campaign for having a SHOULD on detecting the misconfiguration, which > will otherwise look like mysterious adjacency flapping, or the > inability for adjacencies to come up, or something. It should be > pretty trivial to detect the fact that you're actively receiving > Hellos from multiple systems on what is supposedly a point-to-point > medium. I agree that the likelihood of misconfiguration is much greater and should be detected, Thanks, Acee > > --Dave > >> >> Thanks, >> Acee >> >> Thanks, >> Acee >> >>> >>> thanks. >>> - Naiming >>> >>> Dave Katz said the following on 02/20/2006 08:53 PM: >>> >>>> RFC2328 is silent on what to do if you see a different router ID >>>> on a P2P link; if you take it literally, you will create two >>>> adjacencies (temporarily), advertise both in your router LSA, and >>>> your network will most likely black hole traffic until one of >>>> them times out. >>>> >>>> On real P2P links, this will suffice (if you don't mind a network >>>> outage for the dead time of the old adjacency) and things will >>>> eventually stabilize since it is "impossible" (cough) two get two >>>> neighbors in 2Way. The fact that it is underspecified doesn't >>>> matter that much. >>>> >>>> In the P2P-over-LAN case, there needs to be a mechanism to try to >>>> do something useful if there turn out to be more than two routers >>>> on the link. I don't think it's reasonable to say "gee it's >>>> misconfigured, we don't care what happens to the network." >>>> >>>> >>>> It seems to me that there are two possible cases, namely, use the >>>> old adjacency until it times out (effectively ignoring the hellos >>>> from the new guy) or to form an adjacency with the new guy (and >>>> blow away or otherwise ignore the old guy.) >>>> >>>> The first case has the advantage of stability and simplicity-- the >>>> third router that shows up for the party will be ignored by both >>>> parties. There is a potential for a circle of one-way adjacencies >>>> to stabilize, but this will still be stable (there won't be a >>>> usable adjacency across the subnetwork.) >>>> >>>> The second case has the advantage that it adapts more quickly >>>> when something changes. Some implementations already do this for >>>> the pure P2P case. However, it is destabilizing in the >>>> misconfiguration case, as the router will flap its router LSA >>>> each time another Hello is received. Probably the only >>>> reasonable way out would be to detect the flap and then choose >>>> one neighbor and stick to it, ignoring the other (which >>>> degenerates into the first case.) >>>> >>>> Given all of this, I'd propose that the right thing to do is the >>>> first case, and suffer through the dead time (or use BFD and >>>> suffer through the detection time.) >>>> >>>> (A third possible case would be to actually bring up the >>>> adjacency and end up running full-mesh multipoint, which would >>>> probably even work, but would be butt ugly.) >>>> >>>> --Dave >>>> >>>> >>>> On Feb 20, 2006, at 3:25 PM, Acee Lindem wrote: >>>> >>>>> Kalyan Bade wrote: >>>>> >>>>>> Acee, >>>>>> >>>>>> >>>>>>>> This might not work if the interface is defined as demand >>>>>>>> circuit. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Good point - We're in the process of discussing whether this >>>>>>> behavior >>>>>>> should be in the >>>>>>> draft. Possibly, handling detection of a router-id change on a P2P >>>>>>> >>>>>> over >>>>>> >>>>>>> LAN link >>>>>>> differently than a normal P2P link may be a bad idea. >>>>>>> >>>>>> >>>>>> How about bringing down the neighbor (rather than ignoring) when >>>>>> a third >>>>>> neighbor on a P2P over LAN sends a new hello? This creates >>>>>> unnecessary >>>>>> flaps, but again having more than 2 routers on a p2p LAN is a >>>>>> misconfig. >>>>>> Atleast, the processing will be similar to a regular p2p interface. >>>>>> >>>>> That would be fine and consistent with what most routers do on >>>>> normal P2P links. I think the >>>>> P2P over LAN specific router-ID change processing should be >>>>> removed from the draft. >>>>> >>>>> Thanks, >>>>> Acee >>>>> >>>>>> Thanks, >>>>>> Kalyan. >>>>>> >>>>>> >>>>> >>> >> > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 21 20:13:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBgS2-0000wx-Du for ospf-archive@LISTS.IETF.ORG; Tue, 21 Feb 2006 17:57:46 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBgIG-0007J1-OY for ospf-archive@LISTS.IETF.ORG; Tue, 21 Feb 2006 17:47:41 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <5.0003135D@wildebeest.ease.lsoft.com>; Tue, 21 Feb 2006 17:47:40 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100040375 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 21 Feb 2006 17:47:41 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 21 Feb 2006 17:47:40 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 21 Feb 2006 14:47:40 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,135,1139212800"; d="scan'208"; a="22362331:sNHT26975602" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k1LMlLLd007482 for ; Tue, 21 Feb 2006 17:47:38 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Feb 2006 17:47:34 -0500 Received: from [10.82.216.55] ([10.82.216.55]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Feb 2006 17:47:34 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <35D1C36F7A7EE440AC7AB6779451DD0104E5BD@antineutrino.jnpr.net> <43FA4FFE.1070908@cisco.com> <43FAA799.2000705@cisco.com> <43FB1E08.9000009@cisco.com> <43FB738B.3000001@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Feb 2006 22:47:34.0469 (UTC) FILETIME=[CE40D750:01C63738] Message-ID: <43FB9886.8090002@cisco.com> Date: Tue, 21 Feb 2006 17:47:34 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Detecting router id change in p2p-over-lan connection To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43FB738B.3000001@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Hello Naiming, Naiming Shen wrote: > Acee Lindem said the following on 02/21/2006 06:04 AM: > >> Naiming Shen wrote: >> >>> Agree with Dave's argument, and this is the same idea as in the >>> current draft of p2p-over-lan (section 4.5): >>> >>> ... If the system ID or the >>> router ID of incoming hello packet does not match the system ID or >>> the router ID of already established adjacency over this >>> p2p-over-lan >>> circuit, it MUST discard the packet. The implementation should offer >>> logging and debugging information of the above events. >>> >>> Do we need to change anything here? >> >> >> >> Hi Naiming, >> >> Given that this situation can happen in the case of misconfiguration or >> router-ID change, I wouldn't optimize for the former. Especially >> considering Kalyan's point that if hello's are suppressed, the >> router-id change >> will either not be recognized or require additional logic. I'd vote >> to either >> leave it unspecified (consistent with RFC 2328's omission of router-id >> change P2P link handling) or discard the old neighbor and bring up >> an adjacency with the new (which is what at least one implementation >> does >> today). > > > Hello Acee, > > The original idea in the draft was to prevent multiple routers joinning > onto the same LAN rather than handing the router-ID change from the > same router. Even through there is a side effect to it. > > For the router-ID change issue. If one is willing to change router-ID > or system-ID during normal operation, there are more things broken > and there is nothing wrong to wait until the current adjacent timeout. Agreed. > If the hello is suppressed over the link, then the behaviour is not > bounded by this paragraph since it does not say the purpose is to > detect neighbor router-id change. I disagree here. It says "MUST discard packet". That sounds pretty bounding to me :^). > Also there is little reason to > suppress a hello over p2p-over-lan links. Thus I don't think > router-id is an issue with this sentence. I agree - but there is nothing in this draft or RFC 1793 that precludes it. > > Since p2p-over-lan is different from normal p2p circuit that multiple > routers can easily join the same LAN unintentionally. If we ignore > the new station to join, then we can prevent the adjacency constant > flapping(this does not happen to normal p2p link), the worst it can > happen is slow to handle router-id change as mentioned above, which > is a non issue. Thus I think it's a good thing to ignore the extra > adjacency joinning. This sentence does not govern the normal p2p link > behaviour so the implementation is ok(even prefered) to reset the > existing adjacency on a normal p2p link. Thus I don't think we > should say we must reset the current adjacency for p2p-over-lan. > > My preference of this sentence in the draft is with this order: > > - leave it as is > - change the MUST to SHOULD > - remove the router-id related sentence How about leave it "almost" as is: If the system ID or the router ID in an incoming hello packet doesn't match the the system ID or router ID for an established adjacency over a p2p-over-lan circuit, the packet MUST be discarded. Futhermore, if OSPF hello suppression as described in [DEMAND] is active for the adjacency, it MUST be terminated and renegotiated. [DEMAND] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995. Thanks, Acee > thanks. > - Naiming > >> >> Thanks, >> Acee >> >> Thanks, >> Acee >> >>> >>> thanks. >>> - Naiming >>> >>> Dave Katz said the following on 02/20/2006 08:53 PM: >>> >>>> RFC2328 is silent on what to do if you see a different router ID on >>>> a P2P link; if you take it literally, you will create two >>>> adjacencies (temporarily), advertise both in your router LSA, and >>>> your network will most likely black hole traffic until one of them >>>> times out. >>>> >>>> On real P2P links, this will suffice (if you don't mind a network >>>> outage for the dead time of the old adjacency) and things will >>>> eventually stabilize since it is "impossible" (cough) two get two >>>> neighbors in 2Way. The fact that it is underspecified doesn't >>>> matter that much. >>>> >>>> In the P2P-over-LAN case, there needs to be a mechanism to try to >>>> do something useful if there turn out to be more than two routers >>>> on the link. I don't think it's reasonable to say "gee it's >>>> misconfigured, we don't care what happens to the network." >>>> >>>> >>>> It seems to me that there are two possible cases, namely, use the >>>> old adjacency until it times out (effectively ignoring the hellos >>>> from the new guy) or to form an adjacency with the new guy (and >>>> blow away or otherwise ignore the old guy.) >>>> >>>> The first case has the advantage of stability and simplicity--the >>>> third router that shows up for the party will be ignored by both >>>> parties. There is a potential for a circle of one-way adjacencies >>>> to stabilize, but this will still be stable (there won't be a >>>> usable adjacency across the subnetwork.) >>>> >>>> The second case has the advantage that it adapts more quickly when >>>> something changes. Some implementations already do this for the >>>> pure P2P case. However, it is destabilizing in the >>>> misconfiguration case, as the router will flap its router LSA each >>>> time another Hello is received. Probably the only reasonable way >>>> out would be to detect the flap and then choose one neighbor and >>>> stick to it, ignoring the other (which degenerates into the first >>>> case.) >>>> >>>> Given all of this, I'd propose that the right thing to do is the >>>> first case, and suffer through the dead time (or use BFD and >>>> suffer through the detection time.) >>>> >>>> (A third possible case would be to actually bring up the adjacency >>>> and end up running full-mesh multipoint, which would probably even >>>> work, but would be butt ugly.) >>>> >>>> --Dave >>>> >>>> >>>> On Feb 20, 2006, at 3:25 PM, Acee Lindem wrote: >>>> >>>>> Kalyan Bade wrote: >>>>> >>>>>> Acee, >>>>>> >>>>>> >>>>>>>> This might not work if the interface is defined as demand circuit. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Good point - We're in the process of discussing whether this >>>>>>> behavior >>>>>>> should be in the >>>>>>> draft. Possibly, handling detection of a router-id change on a P2P >>>>>>> >>>>>> over >>>>>> >>>>>>> LAN link >>>>>>> differently than a normal P2P link may be a bad idea. >>>>>>> >>>>>> >>>>>> How about bringing down the neighbor (rather than ignoring) when >>>>>> a third >>>>>> neighbor on a P2P over LAN sends a new hello? This creates >>>>>> unnecessary >>>>>> flaps, but again having more than 2 routers on a p2p LAN is a >>>>>> misconfig. >>>>>> Atleast, the processing will be similar to a regular p2p interface. >>>>>> >>>>> That would be fine and consistent with what most routers do on >>>>> normal P2P links. I think the >>>>> P2P over LAN specific router-ID change processing should be >>>>> removed from the draft. >>>>> >>>>> Thanks, >>>>> Acee >>>>> >>>>>> Thanks, >>>>>> Kalyan. >>>>>> >>>>>> >>>>> >>> > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 22 00:43:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBmmM-0002Wt-5A for ospf-archive@LISTS.IETF.ORG; Wed, 22 Feb 2006 00:43:10 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBmmL-0008Nr-PF for ospf-archive@LISTS.IETF.ORG; Wed, 22 Feb 2006 00:43:10 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <9.000319EA@wildebeest.ease.lsoft.com>; Wed, 22 Feb 2006 0:43:08 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100067979 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 22 Feb 2006 00:43:09 -0500 Received: from 171.68.10.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 22 Feb 2006 00:43:08 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 21 Feb 2006 21:43:09 -0800 X-IronPort-AV: i="4.02,135,1139212800"; d="scan'208"; a="256972207:sNHT34241862" Received: from [127.0.0.1] (ssh-sjc-1.cisco.com [171.68.225.134]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k1M5h5ub000968 for ; Tue, 21 Feb 2006 21:43:05 -0800 (PST) User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <35D1C36F7A7EE440AC7AB6779451DD0104E5BD@antineutrino.jnpr.net> <43FA4FFE.1070908@cisco.com> <43FAA799.2000705@cisco.com> <43FB1E08.9000009@cisco.com> <43FB738B.3000001@cisco.com> <43FB9886.8090002@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <43FBF9F9.4040509@cisco.com> Date: Tue, 21 Feb 2006 21:43:21 -0800 Reply-To: Mailing List Sender: Mailing List From: Naiming Shen Subject: Re: Detecting router id change in p2p-over-lan connection To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43FB9886.8090002@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Hello Acee, Your suggested paragraph looks fine with me. Even though this sentence assumes there is really a router-id change from a DC neighbor. A router probably should send a 'neighbor probing' [RFC 3883], if no response, then reset the adjacency and start the renegotiation; otherwise it should still ignore the new join on the p2p-over-lan link. But I would consider router-id change over a demand circuit over a p2p-over-lan on OSPF link a 'misconfiguration';-) so it does not matter too much. Your version is fine. thanks. - Naiming Acee Lindem said the following on 02/21/2006 02:47 PM: > Hello Naiming, > > Naiming Shen wrote: > >> Acee Lindem said the following on 02/21/2006 06:04 AM: >> >>> Naiming Shen wrote: >>> >>>> Agree with Dave's argument, and this is the same idea as in the >>>> current draft of p2p-over-lan (section 4.5): >>>> >>>> ... If the system ID or the >>>> router ID of incoming hello packet does not match the system ID or >>>> the router ID of already established adjacency over this >>>> p2p-over-lan >>>> circuit, it MUST discard the packet. The implementation should offer >>>> logging and debugging information of the above events. >>>> >>>> Do we need to change anything here? >>> >>> >>> >>> >>> Hi Naiming, >>> >>> Given that this situation can happen in the case of misconfiguration or >>> router-ID change, I wouldn't optimize for the former. Especially >>> considering Kalyan's point that if hello's are suppressed, the >>> router-id change >>> will either not be recognized or require additional logic. I'd vote >>> to either >>> leave it unspecified (consistent with RFC 2328's omission of router-id >>> change P2P link handling) or discard the old neighbor and bring up >>> an adjacency with the new (which is what at least one implementation >>> does >>> today). >> >> >> >> Hello Acee, >> >> The original idea in the draft was to prevent multiple routers joinning >> onto the same LAN rather than handing the router-ID change from the >> same router. Even through there is a side effect to it. >> >> For the router-ID change issue. If one is willing to change router-ID >> or system-ID during normal operation, there are more things broken >> and there is nothing wrong to wait until the current adjacent timeout. > > > Agreed. > >> If the hello is suppressed over the link, then the behaviour is not >> bounded by this paragraph since it does not say the purpose is to >> detect neighbor router-id change. > > > I disagree here. It says "MUST discard packet". That sounds pretty > bounding to me :^). > >> Also there is little reason to >> suppress a hello over p2p-over-lan links. Thus I don't think >> router-id is an issue with this sentence. > > > I agree - but there is nothing in this draft or RFC 1793 that precludes it. > >> >> Since p2p-over-lan is different from normal p2p circuit that multiple >> routers can easily join the same LAN unintentionally. If we ignore >> the new station to join, then we can prevent the adjacency constant >> flapping(this does not happen to normal p2p link), the worst it can >> happen is slow to handle router-id change as mentioned above, which >> is a non issue. Thus I think it's a good thing to ignore the extra >> adjacency joinning. This sentence does not govern the normal p2p link >> behaviour so the implementation is ok(even prefered) to reset the >> existing adjacency on a normal p2p link. Thus I don't think we >> should say we must reset the current adjacency for p2p-over-lan. >> >> My preference of this sentence in the draft is with this order: >> >> - leave it as is >> - change the MUST to SHOULD >> - remove the router-id related sentence > > > How about leave it "almost" as is: > > If the system ID or the router ID in an incoming hello packet doesn't > match the the system ID or router ID for an established adjacency over > a p2p-over-lan circuit, the packet MUST be discarded. Futhermore, > if OSPF hello suppression as described in [DEMAND] is active for the > adjacency, it MUST be terminated and renegotiated. > > [DEMAND] Moy, J., "Extending OSPF to Support Demand Circuits", > RFC 1793, April 1995. > > Thanks, > Acee > >> thanks. >> - Naiming >> >>> >>> Thanks, >>> Acee >>> >>> Thanks, >>> Acee >>> >>>> >>>> thanks. >>>> - Naiming >>>> >>>> Dave Katz said the following on 02/20/2006 08:53 PM: >>>> >>>>> RFC2328 is silent on what to do if you see a different router ID on >>>>> a P2P link; if you take it literally, you will create two >>>>> adjacencies (temporarily), advertise both in your router LSA, and >>>>> your network will most likely black hole traffic until one of them >>>>> times out. >>>>> >>>>> On real P2P links, this will suffice (if you don't mind a network >>>>> outage for the dead time of the old adjacency) and things will >>>>> eventually stabilize since it is "impossible" (cough) two get two >>>>> neighbors in 2Way. The fact that it is underspecified doesn't >>>>> matter that much. >>>>> >>>>> In the P2P-over-LAN case, there needs to be a mechanism to try to >>>>> do something useful if there turn out to be more than two routers >>>>> on the link. I don't think it's reasonable to say "gee it's >>>>> misconfigured, we don't care what happens to the network." >>>>> >>>>> >>>>> It seems to me that there are two possible cases, namely, use the >>>>> old adjacency until it times out (effectively ignoring the hellos >>>>> from the new guy) or to form an adjacency with the new guy (and >>>>> blow away or otherwise ignore the old guy.) >>>>> >>>>> The first case has the advantage of stability and simplicity--the >>>>> third router that shows up for the party will be ignored by both >>>>> parties. There is a potential for a circle of one-way adjacencies >>>>> to stabilize, but this will still be stable (there won't be a >>>>> usable adjacency across the subnetwork.) >>>>> >>>>> The second case has the advantage that it adapts more quickly when >>>>> something changes. Some implementations already do this for the >>>>> pure P2P case. However, it is destabilizing in the >>>>> misconfiguration case, as the router will flap its router LSA each >>>>> time another Hello is received. Probably the only reasonable way >>>>> out would be to detect the flap and then choose one neighbor and >>>>> stick to it, ignoring the other (which degenerates into the first >>>>> case.) >>>>> >>>>> Given all of this, I'd propose that the right thing to do is the >>>>> first case, and suffer through the dead time (or use BFD and >>>>> suffer through the detection time.) >>>>> >>>>> (A third possible case would be to actually bring up the adjacency >>>>> and end up running full-mesh multipoint, which would probably even >>>>> work, but would be butt ugly.) >>>>> >>>>> --Dave >>>>> >>>>> >>>>> On Feb 20, 2006, at 3:25 PM, Acee Lindem wrote: >>>>> >>>>>> Kalyan Bade wrote: >>>>>> >>>>>>> Acee, >>>>>>> >>>>>>> >>>>>>>>> This might not work if the interface is defined as demand circuit. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Good point - We're in the process of discussing whether this >>>>>>>> behavior >>>>>>>> should be in the >>>>>>>> draft. Possibly, handling detection of a router-id change on a P2P >>>>>>>> >>>>>>> over >>>>>>> >>>>>>>> LAN link >>>>>>>> differently than a normal P2P link may be a bad idea. >>>>>>>> >>>>>>> >>>>>>> How about bringing down the neighbor (rather than ignoring) when >>>>>>> a third >>>>>>> neighbor on a P2P over LAN sends a new hello? This creates >>>>>>> unnecessary >>>>>>> flaps, but again having more than 2 routers on a p2p LAN is a >>>>>>> misconfig. >>>>>>> Atleast, the processing will be similar to a regular p2p interface. >>>>>>> >>>>>> That would be fine and consistent with what most routers do on >>>>>> normal P2P links. I think the >>>>>> P2P over LAN specific router-ID change processing should be >>>>>> removed from the draft. >>>>>> >>>>>> Thanks, >>>>>> Acee >>>>>> >>>>>>> Thanks, >>>>>>> Kalyan. >>>>>>> >>>>>>> >>>>>> >>>> >> From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 22 04:50:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBqdk-00085k-C6 for ospf-archive@LISTS.IETF.ORG; Wed, 22 Feb 2006 04:50:32 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBqdk-00028Y-2I for ospf-archive@LISTS.IETF.ORG; Wed, 22 Feb 2006 04:50:32 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <9.00031D96@wildebeest.ease.lsoft.com>; Wed, 22 Feb 2006 4:50:31 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100076542 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 22 Feb 2006 04:50:30 -0500 Received: from 12.178.35.128 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 22 Feb 2006 04:40:30 -0500 Received: from mailblr1.engineering.netscaler.com ([10.102.1.9]) by mailsj.engineering.netscaler.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Feb 2006 01:36:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63793.FF5DD2DF" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reg: DDOS prevention in OSPF Thread-Index: AcY3k/9aIR3kCJgSSrC8Jw9IOyj3AQ== X-OriginalArrivalTime: 22 Feb 2006 09:36:21.0495 (UTC) FILETIME=[7091A070:01C63793] Message-ID: <6D975E431022374F9F7A298A511427B60D5C15@mailblr1.engineering.netscaler.com> Date: Wed, 22 Feb 2006 15:10:21 +0530 Reply-To: Mailing List Sender: Mailing List From: "Nanda Kishore S." Subject: Reg: DDOS prevention in OSPF To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: 6b519fb0ef66258f34533f52ff46aedf This is a multi-part message in MIME format. ------_=_NextPart_001_01C63793.FF5DD2DF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 In quite some places we mention that Authentication is=20 a must to provide DDOS protection for OSPF.=20 =20 But as simple password is not so useful we will be using MD5 authentication and even if is enabled, wont' the socket buffers become full and drop genuine adjacencies when DDOS attack happens.=20 =20 I was wondering if any implementations are there where=20 authentication is done before queuing the packet at socket/packet=20 buffer layer.=20 =20 My idea is implementing MD5 authentication at socket level at greater speeds (DDOS attack's speed) is not feasible or won't give such performance so, why not have a cascaded authentication=20 mechanism like (Simple password + MD5) so, that before queuing of packets we can do simple password at greater efficiency and MD5 for better security later.=20 =20 (Assuming that it won't be that easy to get the simple password as knowing just the IP addresses of OSPF routers).=20 =20 Any comments? =20 -Nanda Kishore =20 --------------------------- Nanda Kishore, Sr. Software Engineer, Citrix - ANG, Bangalore. =20 Tel: 51341000 Ext: 416 Cell: 9880720721 =20 ------_=_NextPart_001_01C63793.FF5DD2DF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

         =    In quite some places we mention that Authentication is =

a must to provide DDOS protection for OSPF. =

 

         =    But as simple password is not so useful we will be = using

MD5 authentication and even if is enabled, = wont’ the socket buffers

become full and drop genuine adjacencies when DDOS = attack happens.

 

         =    I was wondering if any implementations are there where =

authentication is done before queuing the packet at socket/packet

buffer layer.

 

         =    My idea is implementing MD5 authentication at = socket

level at greater speeds (DDOS attack’s speed) = is not feasible or won’t

give such performance so, why not have a cascaded authentication

mechanism like (Simple password + MD5) so, that = before queuing of

packets we can do simple password at greater = efficiency and MD5 for

better security later.

 

         =    (Assuming that it won’t be that easy to get the simple = password

as knowing just the IP addresses of OSPF routers). =

 

Any comments?

 

-Nanda Kishore

 

---------------------------

Nanda = Kishore,

Sr. Software = Engineer,

Citrix – ANG, = Bangalore.

 

Tel: 51341000 Ext: = 416

Cell: = 9880720721

 

------_=_NextPart_001_01C63793.FF5DD2DF-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 22 08:16:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBtqi-0002ga-8T for ospf-archive@LISTS.IETF.ORG; Wed, 22 Feb 2006 08:16:08 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBtqh-0001xX-24 for ospf-archive@LISTS.IETF.ORG; Wed, 22 Feb 2006 08:16:08 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <8.00031FBE@wildebeest.ease.lsoft.com>; Wed, 22 Feb 2006 8:15:44 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100094161 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 22 Feb 2006 08:15:44 -0500 Received: from 171.71.176.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 22 Feb 2006 08:15:44 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 22 Feb 2006 05:15:43 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k1MDFZgY021975 for ; Wed, 22 Feb 2006 05:15:41 -0800 (PST) Received: from [10.32.244.221] (stealth-10-32-244-221.cisco.com [10.32.244.221]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k1MDIC4o025191 for ; Wed, 22 Feb 2006 05:18:17 -0800 Mime-Version: 1.0 (Apple Message framework v746.2) References: <6D975E431022374F9F7A298A511427B60D5C15@mailblr1.engineering.netscaler.com> Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=829; t=1140614297; x=1141046497; c=relaxed/simple; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding:Mime-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20Reg=3A=20DDOS=20prevention=20in=20OSPF |To:Mailing=20List=20; X=v=3Dmtcc.com=3B=20h=3DAPwbwhpBZHI7kwPI/9RDGmY1P78=3D; b=Oq9FBmwjI5RITr8Ezul7MDL2+a9BVwzduDdr81j48aEWHlJG8WXDQV/dgx3UG3by///E3eJK YTx9tHP8O13wA5eqb8IknK2XgS08yPhOzsDpQlT0GCMqxnwm5lZIcM89Em9nUPwKZ1pTiEMzOdT 1D6DH8a88clswRz4GDTGLiCY=; Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); Message-ID: <746580AC-F9E4-45AB-BC51-F13DCCE6EC51@cisco.com> Date: Wed, 22 Feb 2006 05:15:22 -0800 Reply-To: Mailing List Sender: Mailing List From: Fred Baker Subject: Re: Reg: DDOS prevention in OSPF To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <6D975E431022374F9F7A298A511427B60D5C15@mailblr1.engineering.netscaler.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Dumb question: why no use IPsec, which (unless I am mistaken) =20 accomplishes the same thing? Historically, the reason we built MD5 authentication into OSPF was =20 because IPsec couldn't produce a result to save its soul. This =20 authentication mechanism is basically borrowed more or less directly =20 from the IPsec AH drafts of the time. IPsec produced a result... On Feb 22, 2006, at 1:40 AM, Nanda Kishore S. wrote: > My idea is implementing MD5 authentication at socket level at =20 > greater speeds (DDOS attack=92s speed) is not feasible or won=92t give = =20 > such performance so, why not have a cascaded authentication =20 > mechanism like (Simple password + MD5) so, that before queuing of =20 > packets we can do simple password at greater efficiency and MD5 for =20= > better security later. From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 22 09:12:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBuin-0006Mb-Bd for ospf-archive@LISTS.IETF.ORG; Wed, 22 Feb 2006 09:12:01 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBuin-0004xO-4W for ospf-archive@LISTS.IETF.ORG; Wed, 22 Feb 2006 09:12:01 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <8.00032087@wildebeest.ease.lsoft.com>; Wed, 22 Feb 2006 9:12:00 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100098680 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 22 Feb 2006 09:12:01 -0500 Received: from 198.137.194.222 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 22 Feb 2006 09:12:01 -0500 Received: (qmail 26889 invoked by uid 211); 22 Feb 2006 14:12:00 -0000 Received: from challah.msrl.com (HELO ?127.0.0.1?) (vgill@198.137.194.222) by challah.msrl.com with RC4-MD5 encrypted SMTP; 22 Feb 2006 14:12:00 -0000 User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 References: <6D975E431022374F9F7A298A511427B60D5C15@mailblr1.engineering.netscaler.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Message-ID: <43FC712C.4070005@vijaygill.com> Date: Wed, 22 Feb 2006 09:11:56 -0500 Reply-To: Mailing List Sender: Mailing List From: vijay gill Organization: vgill global logistics Subject: Re: Reg: DDOS prevention in OSPF To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <6D975E431022374F9F7A298A511427B60D5C15@mailblr1.engineering.netscaler.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Nanda Kishore S. wrote: > Hi, > > > > In quite some places we mention that Authentication is > > a must to provide DDOS protection for OSPF. Unless you can do distributed authentication checks at the point of ingress of traffic (i.e. at the line card, right after the framer, at wirespeed), authentication is almost a win for DDOS, because what happens is you get a bunch of packets with auth on them, you send them to the CPU, CPU sits there, decoding and discarding and well, box keels over and dies. This is the same result we saw when the MD5 auth was turned on for BGP. Most router vendors actually had worse performance when subject to DDOS attacks with MD5 than without, because now instead of just discarding junk, they had to decode and then discard. > > > > But as simple password is not so useful we will be using > > MD5 authentication and even if is enabled, wont’ the socket buffers > > become full and drop genuine adjacencies when DDOS attack happens. This is correct. > > > > I was wondering if any implementations are there where > > authentication is done before queuing the packet at socket/packet > > buffer layer. > > > > My idea is implementing MD5 authentication at socket > > level at greater speeds (DDOS attack’s speed) is not feasible or won’t > > give such performance so, why not have a cascaded authentication > > mechanism like (Simple password + MD5) so, that before queuing of > > packets we can do simple password at greater efficiency and MD5 for > > better security later. > > > > (Assuming that it won’t be that easy to get the simple password > > as knowing just the IP addresses of OSPF routers). > > > > Any comments? > This is the right way. See also GTSM where for some protocols, we used TTL as a fast key to disambiguate junk from non-junk. http://www.ietf.org/rfc/rfc3682.txt /vijay > > > -Nanda Kishore > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 22 10:43:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBw9E-0001lA-T7 for ospf-archive@LISTS.IETF.ORG; Wed, 22 Feb 2006 10:43:24 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBw9E-0000gg-IJ for ospf-archive@LISTS.IETF.ORG; Wed, 22 Feb 2006 10:43:24 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <3.00032309@wildebeest.ease.lsoft.com>; Wed, 22 Feb 2006 10:43:24 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100104913 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 22 Feb 2006 10:43:24 -0500 Received: from 66.249.82.207 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 22 Feb 2006 10:33:24 -0500 Received: by xproxy.gmail.com with SMTP id s6so1083066wxc for ; Wed, 22 Feb 2006 07:33:22 -0800 (PST) Received: by 10.70.82.1 with SMTP id f1mr809128wxb; Wed, 22 Feb 2006 07:33:21 -0800 (PST) Received: by 10.70.7.13 with HTTP; Wed, 22 Feb 2006 07:33:21 -0800 (PST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_15786_26390690.1140622401049" References: <6D975E431022374F9F7A298A511427B60D5C15@mailblr1.engineering.netscaler.com> <43FC712C.4070005@vijaygill.com> Message-ID: <77ead0ec0602220733h68942dc8wd7113a1b05a546b3@mail.gmail.com> Date: Wed, 22 Feb 2006 07:33:21 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: Reg: DDOS prevention in OSPF To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43FC712C.4070005@vijaygill.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 ------=_Part_15786_26390690.1140622401049 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, > This is the right way. See also GTSM where for some protocols, we > used TTL as a fast key to disambiguate junk from non-junk. GTSM is certainly a good way to clear the chaff to prevent a DDOS due to flooding of junk packets which use authentication mechanisms, however it ma= y not be of much use for packets received over virtual links. Thanks, Vishwas On 2/22/06, vijay gill wrote: > > Nanda Kishore S. wrote: > > Hi, > > > > > > > > In quite some places we mention that Authentication is > > > > a must to provide DDOS protection for OSPF. > > Unless you can do distributed authentication checks at the point of > ingress of traffic (i.e. at the line card, right after the framer, at > wirespeed), authentication is almost a win for DDOS, because what > happens is you get a bunch of packets with auth on them, you send them > to the CPU, CPU sits there, decoding and discarding and well, box keels > over and dies. This is the same result we saw when the MD5 auth was > turned on for BGP. Most router vendors actually had worse performance > when subject to DDOS attacks with MD5 than without, because now instead > of just discarding junk, they had to decode and then discard. > > > > > > > > > > But as simple password is not so useful we will be using > > > > MD5 authentication and even if is enabled, wont' the socket buffers > > > > become full and drop genuine adjacencies when DDOS attack happens. > > This is correct. > > > > > > > > > I was wondering if any implementations are there where > > > > authentication is done before queuing the packet at socket/packet > > > > buffer layer. > > > > > > > > My idea is implementing MD5 authentication at socket > > > > level at greater speeds (DDOS attack's speed) is not feasible or won't > > > > give such performance so, why not have a cascaded authentication > > > > mechanism like (Simple password + MD5) so, that before queuing of > > > > packets we can do simple password at greater efficiency and MD5 for > > > > better security later. > > > > > > > > (Assuming that it won't be that easy to get the simple > password > > > > as knowing just the IP addresses of OSPF routers). > > > > > > > > Any comments? > > > > This is the right way. See also GTSM where for some protocols, we used > TTL as a fast key to disambiguate junk from non-junk. > > http://www.ietf.org/rfc/rfc3682.txt > > /vijay > > > > > > > -Nanda Kishore > > > > > > > ------=_Part_15786_26390690.1140622401049 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi,
 

> This is the right way. See also GTSM where for some protocols= , we
> used TTL as a fast key to disambiguate junk from non-junk.
GTSM is certainly a good way to clear the chaff to prevent a DDOS due = to flooding of junk packets which use authentication mechanisms, however it= may not be of much use for packets received over virtual links.
 
Thanks,
Vishwas
 
On 2/22/06, = vijay gill <vgill@vijaygill.c= om> wrote:
Nanda Kishore S. wrote:
> = Hi,
>
>
>
>      &nbs= p;      In quite some places we mention that Authe= ntication is
>
> a must to provide DDOS protection for OSPF.

Unless = you can do distributed authentication checks at the point of
ingress of = traffic (i.e. at the line card, right after the framer, at
wirespeed), a= uthentication is almost a win for DDOS, because what
happens is you get a bunch of packets with auth on them, you send them<= br>to the CPU, CPU sits there, decoding and discarding and well, box keels<= br>over and dies. This is the same result we saw when the MD5 auth was
turned on for BGP. Most router vendors actually had worse performance
wh= en subject to DDOS attacks with MD5 than without, because now instead
of= just discarding junk, they had to decode and then discard.


>
>
>
>        = ;     But as simple password is not so useful we will b= e using
>
> MD5 authentication and even if is enabled, wont' th= e socket buffers
>
> become full and drop genuine adjacencies w= hen DDOS attack happens.

This is correct.

>
>
>
>  &nb= sp;          I was wondering i= f any implementations are there where
>
> authentication is don= e before queuing the packet at socket/packet
>
> buffer layer.
>
>
>
>    &= nbsp;        My idea is implementing MD5= authentication at socket
>
> level at greater speeds (DDOS att= ack's speed) is not feasible or won't
>
> give such performance= so, why not have a cascaded authentication
>
> mechanism like (Simple password + MD5) so, that before que= uing of
>
> packets we can do simple password at greater effici= ency and MD5 for
>
> better security later.
>
>
>
>          = ;   (Assuming that it won't be that easy to get the simple passwo= rd
>
> as knowing just the IP addresses of OSPF routers).
&g= t;
>
>
> Any comments?
>

This is the right way. See also GTSM where for some protocols, we used
T= TL as a fast key to disambiguate junk from non-junk.

http://www.ietf.org/rfc/rfc3682.txt
/vijay

>
>
> -Nanda Kishore
>
>
&g= t;

------=_Part_15786_26390690.1140622401049-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 22 10:51:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBwHO-00027S-Df for ospf-archive@LISTS.IETF.ORG; Wed, 22 Feb 2006 10:51:50 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBwHO-0000zR-1c for ospf-archive@LISTS.IETF.ORG; Wed, 22 Feb 2006 10:51:50 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <5.00032377@wildebeest.ease.lsoft.com>; Wed, 22 Feb 2006 10:51:49 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100105331 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 22 Feb 2006 10:51:50 -0500 Received: from 66.249.82.207 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 22 Feb 2006 10:41:50 -0500 Received: by xproxy.gmail.com with SMTP id h27so1080464wxd for ; Wed, 22 Feb 2006 07:41:48 -0800 (PST) Received: by 10.70.34.12 with SMTP id h12mr5971074wxh; Wed, 22 Feb 2006 07:41:46 -0800 (PST) Received: by 10.70.7.13 with HTTP; Wed, 22 Feb 2006 07:41:46 -0800 (PST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_16018_24555900.1140622906361" References: <6D975E431022374F9F7A298A511427B60D5C15@mailblr1.engineering.netscaler.com> <43FC712C.4070005@vijaygill.com> <77ead0ec0602220733h68942dc8wd7113a1b05a546b3@mail.gmail.com> Message-ID: <77ead0ec0602220741l55a0bbcrc03c24d87cf13b59@mail.gmail.com> Date: Wed, 22 Feb 2006 07:41:46 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: Reg: DDOS prevention in OSPF To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <77ead0ec0602220733h68942dc8wd7113a1b05a546b3@mail.gmail.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 ------=_Part_16018_24555900.1140622906361 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Vijay, Besides for GTSM to work, all current implementations should have their TTL= / Hop Limit programmable for all IP packets containing the OSPF payload.Bydefault the IP TTL valie of 64 is used. Thanks, Vishwas On 2/22/06, Vishwas Manral wrote: > > Hi, > > > > This is the right way. See also GTSM where for some protocols, we > > used TTL as a fast key to disambiguate junk from non-junk. > GTSM is certainly a good way to clear the chaff to prevent a DDOS due to > flooding of junk packets which use authentication mechanisms, however it = may > not be of much use for packets received over virtual links. > > Thanks, > Vishwas > > On 2/22/06, vijay gill wrote: > > > > Nanda Kishore S. wrote: > > > Hi, > > > > > > > > > > > > In quite some places we mention that Authentication is > > > > > > a must to provide DDOS protection for OSPF. > > > > Unless you can do distributed authentication checks at the point of > > ingress of traffic (i.e. at the line card, right after the framer, at > > wirespeed), authentication is almost a win for DDOS, because what > > happens is you get a bunch of packets with auth on them, you send them > > to the CPU, CPU sits there, decoding and discarding and well, box keels > > over and dies. This is the same result we saw when the MD5 auth was > > turned on for BGP. Most router vendors actually had worse performance > > when subject to DDOS attacks with MD5 than without, because now instead > > of just discarding junk, they had to decode and then discard. > > > > > > > > > > > > > > > > But as simple password is not so useful we will be using > > > > > > MD5 authentication and even if is enabled, wont' the socket buffers > > > > > > become full and drop genuine adjacencies when DDOS attack happens. > > > > This is correct. > > > > > > > > > > > > > > I was wondering if any implementations are there where > > > > > > authentication is done before queuing the packet at socket/packet > > > > > > buffer layer. > > > > > > > > > > > > My idea is implementing MD5 authentication at socket > > > > > > level at greater speeds (DDOS attack's speed) is not feasible or won'= t > > > > > > give such performance so, why not have a cascaded authentication > > > > > > mechanism like (Simple password + MD5) so, that before queuing of > > > > > > packets we can do simple password at greater efficiency and MD5 for > > > > > > better security later. > > > > > > > > > > > > (Assuming that it won't be that easy to get the simple > > password > > > > > > as knowing just the IP addresses of OSPF routers). > > > > > > > > > > > > Any comments? > > > > > > > This is the right way. See also GTSM where for some protocols, we used > > TTL as a fast key to disambiguate junk from non-junk. > > > > http://www.ietf.org/rfc/rfc3682.txt > > > > /vijay > > > > > > > > > > > -Nanda Kishore > > > > > > > > > > > > > ------=_Part_16018_24555900.1140622906361 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Vijay,
 
Besides for GTSM to work, all current implementations should have thei= r TTL/ Hop Limit programmable for all IP packets containing the OSPF p= ayload.By default the IP TTL valie of 64 is used.
 
Thanks,
Vishwas
 
On 2/22/06, = Vishwas Manral <vishwas.ie= tf@gmail.com> wrote:
Hi,
 

> This is the right way. See also GTSM where for some protocols= , we
> used TTL as a fast key to disambiguate junk from non-junk.
<= /span>
GTSM is certainly a good way to clear the chaff to prevent a DDOS due = to flooding of junk packets which use authentication mechanisms, however it= may not be of much use for packets received over virtual links.
 
Thanks,
Vishwas
 
On 2/22/06, = vijay gill <vgill@vijaygill.c= om > wrote:=20
Nanda Kishore S. wrote:
> = Hi,
>
>
>
>      &nbs= p;      In quite some places we mention that Authe= ntication is=20
>
> a must to provide DDOS protection for OSPF.

Unless = you can do distributed authentication checks at the point of
ingress of = traffic (i.e. at the line card, right after the framer, at
wirespeed), a= uthentication is almost a win for DDOS, because what=20
happens is you get a bunch of packets with auth on them, you send them<= br>to the CPU, CPU sits there, decoding and discarding and well, box keels<= br>over and dies. This is the same result we saw when the MD5 auth was
turned on for BGP. Most router vendors actually had worse performance
wh= en subject to DDOS attacks with MD5 than without, because now instead
of= just discarding junk, they had to decode and then discard.


>
>
>
>        = ;     But as simple password is not so useful we will b= e using
>
> MD5 authentication and even if is enabled, wont' th= e socket buffers
>
> become full and drop genuine adjacencies w= hen DDOS attack happens.=20

This is correct.

>
>
>
>  &nb= sp;          I was wondering i= f any implementations are there where
>
> authentication is don= e before queuing the packet at socket/packet
>
> buffer layer.
>
>
>
>    &= nbsp;        My idea is implementing MD5= authentication at socket
>
> level at greater speeds (DDOS att= ack's speed) is not feasible or won't
>
> give such performance= so, why not have a cascaded authentication=20
>
> mechanism like (Simple password + MD5) so, that before que= uing of
>
> packets we can do simple password at greater effici= ency and MD5 for
>
> better security later.
>
>=20
>
>          = ;   (Assuming that it won't be that easy to get the simple passwo= rd
>
> as knowing just the IP addresses of OSPF routers).
&g= t;
>
>
> Any comments?
>

This is the right way. See also GTSM where for some protocols, we used
T= TL as a fast key to disambiguate junk from non-junk.

http://www.ietf.org/rfc/rfc3682.txt

/vijay

>
>> -Nanda Kishore
>
>
>


------=_Part_16018_24555900.1140622906361-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 22 13:18:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FByZ4-0005wk-NL for ospf-archive@LISTS.IETF.ORG; Wed, 22 Feb 2006 13:18:14 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FByZ4-0007Od-A9 for ospf-archive@LISTS.IETF.ORG; Wed, 22 Feb 2006 13:18:14 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <7.000325D6@wildebeest.ease.lsoft.com>; Wed, 22 Feb 2006 13:18:13 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100120103 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 22 Feb 2006 13:18:12 -0500 Received: from 171.71.176.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 22 Feb 2006 13:18:02 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 22 Feb 2006 10:18:02 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1MIHTgR015356 for ; Wed, 22 Feb 2006 10:18:00 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Feb 2006 13:17:59 -0500 Received: from [10.82.216.55] ([10.82.216.55]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Feb 2006 13:17:59 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <35D1C36F7A7EE440AC7AB6779451DD0104E5BD@antineutrino.jnpr.net> <43FA4FFE.1070908@cisco.com> <43FAA799.2000705@cisco.com> <43FB1E08.9000009@cisco.com> <43FB738B.3000001@cisco.com> <43FB9886.8090002@cisco.com> <43FBF9F9.4040509@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Feb 2006 18:17:59.0088 (UTC) FILETIME=[4F635300:01C637DC] Message-ID: <43FCAAD6.1040001@cisco.com> Date: Wed, 22 Feb 2006 13:17:58 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Detecting router id change in p2p-over-lan connection To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43FBF9F9.4040509@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Naiming Shen wrote: > Hello Acee, > > Your suggested paragraph looks fine with me. > > Even though this sentence assumes there is really a > router-id change from a DC neighbor. A router probably > should send a 'neighbor probing' [RFC 3883], if no > response, then reset the adjacency and start > the renegotiation; otherwise it should still ignore > the new join on the p2p-over-lan link. > > But I would consider router-id change over a demand > circuit over a p2p-over-lan on OSPF link a > 'misconfiguration';-) so it does not matter too much. Hi Naiming, If we wanted to limit it, we could say that demand circuit configuration is not allowed on p2p-over-lan interfaces as an alternative. However, if we leave the question unanswered you can best believe it will come back during one of the last calls. Between the 2 alternatives, I like the alternative that allows hello suppression to be tested on p2p-over-lan (even if it isn't practical). Thanks, Acee > Your version is fine. > > thanks. > - Naiming > > Acee Lindem said the following on 02/21/2006 02:47 PM: > >> Hello Naiming, >> >> Naiming Shen wrote: >> >>> Acee Lindem said the following on 02/21/2006 06:04 AM: >>> >>>> Naiming Shen wrote: >>>> >>>>> Agree with Dave's argument, and this is the same idea as in the >>>>> current draft of p2p-over-lan (section 4.5): >>>>> >>>>> ... If the system ID or the >>>>> router ID of incoming hello packet does not match the system ID or >>>>> the router ID of already established adjacency over this >>>>> p2p-over-lan >>>>> circuit, it MUST discard the packet. The implementation should >>>>> offer >>>>> logging and debugging information of the above events. >>>>> >>>>> Do we need to change anything here? >>>> >>>> >>>> >>>> >>>> >>>> Hi Naiming, >>>> >>>> Given that this situation can happen in the case of >>>> misconfiguration or >>>> router-ID change, I wouldn't optimize for the former. Especially >>>> considering Kalyan's point that if hello's are suppressed, the >>>> router-id change >>>> will either not be recognized or require additional logic. I'd vote >>>> to either >>>> leave it unspecified (consistent with RFC 2328's omission of router-id >>>> change P2P link handling) or discard the old neighbor and bring up >>>> an adjacency with the new (which is what at least one >>>> implementation does >>>> today). >>> >>> >>> >>> >>> Hello Acee, >>> >>> The original idea in the draft was to prevent multiple routers joinning >>> onto the same LAN rather than handing the router-ID change from the >>> same router. Even through there is a side effect to it. >>> >>> For the router-ID change issue. If one is willing to change router-ID >>> or system-ID during normal operation, there are more things broken >>> and there is nothing wrong to wait until the current adjacent timeout. >> >> >> >> Agreed. >> >>> If the hello is suppressed over the link, then the behaviour is not >>> bounded by this paragraph since it does not say the purpose is to >>> detect neighbor router-id change. >> >> >> >> I disagree here. It says "MUST discard packet". That sounds pretty >> bounding to me :^). >> >>> Also there is little reason to >>> suppress a hello over p2p-over-lan links. Thus I don't think >>> router-id is an issue with this sentence. >> >> >> >> I agree - but there is nothing in this draft or RFC 1793 that >> precludes it. >> >>> >>> Since p2p-over-lan is different from normal p2p circuit that multiple >>> routers can easily join the same LAN unintentionally. If we ignore >>> the new station to join, then we can prevent the adjacency constant >>> flapping(this does not happen to normal p2p link), the worst it can >>> happen is slow to handle router-id change as mentioned above, which >>> is a non issue. Thus I think it's a good thing to ignore the extra >>> adjacency joinning. This sentence does not govern the normal p2p link >>> behaviour so the implementation is ok(even prefered) to reset the >>> existing adjacency on a normal p2p link. Thus I don't think we >>> should say we must reset the current adjacency for p2p-over-lan. >>> >>> My preference of this sentence in the draft is with this order: >>> >>> - leave it as is >>> - change the MUST to SHOULD >>> - remove the router-id related sentence >> >> >> >> How about leave it "almost" as is: >> >> If the system ID or the router ID in an incoming hello packet >> doesn't >> match the the system ID or router ID for an established adjacency >> over >> a p2p-over-lan circuit, the packet MUST be discarded. Futhermore, >> if OSPF hello suppression as described in [DEMAND] is active for the >> adjacency, it MUST be terminated and renegotiated. >> >> [DEMAND] Moy, J., "Extending OSPF to Support Demand Circuits", >> RFC 1793, April 1995. >> >> Thanks, >> Acee >> >>> thanks. >>> - Naiming >>> >>>> >>>> Thanks, >>>> Acee >>>> >>>> Thanks, >>>> Acee >>>> >>>>> >>>>> thanks. >>>>> - Naiming >>>>> >>>>> Dave Katz said the following on 02/20/2006 08:53 PM: >>>>> >>>>>> RFC2328 is silent on what to do if you see a different router ID >>>>>> on a P2P link; if you take it literally, you will create two >>>>>> adjacencies (temporarily), advertise both in your router LSA, >>>>>> and your network will most likely black hole traffic until one >>>>>> of them times out. >>>>>> >>>>>> On real P2P links, this will suffice (if you don't mind a >>>>>> network outage for the dead time of the old adjacency) and >>>>>> things will eventually stabilize since it is "impossible" >>>>>> (cough) two get two neighbors in 2Way. The fact that it is >>>>>> underspecified doesn't matter that much. >>>>>> >>>>>> In the P2P-over-LAN case, there needs to be a mechanism to try to >>>>>> do something useful if there turn out to be more than two >>>>>> routers on the link. I don't think it's reasonable to say "gee >>>>>> it's misconfigured, we don't care what happens to the network." >>>>>> >>>>>> >>>>>> It seems to me that there are two possible cases, namely, use the >>>>>> old adjacency until it times out (effectively ignoring the >>>>>> hellos from the new guy) or to form an adjacency with the new >>>>>> guy (and blow away or otherwise ignore the old guy.) >>>>>> >>>>>> The first case has the advantage of stability and >>>>>> simplicity--the third router that shows up for the party will be >>>>>> ignored by both parties. There is a potential for a circle of >>>>>> one-way adjacencies to stabilize, but this will still be stable >>>>>> (there won't be a usable adjacency across the subnetwork.) >>>>>> >>>>>> The second case has the advantage that it adapts more quickly >>>>>> when something changes. Some implementations already do this >>>>>> for the pure P2P case. However, it is destabilizing in the >>>>>> misconfiguration case, as the router will flap its router LSA >>>>>> each time another Hello is received. Probably the only >>>>>> reasonable way out would be to detect the flap and then choose >>>>>> one neighbor and stick to it, ignoring the other (which >>>>>> degenerates into the first case.) >>>>>> >>>>>> Given all of this, I'd propose that the right thing to do is the >>>>>> first case, and suffer through the dead time (or use BFD and >>>>>> suffer through the detection time.) >>>>>> >>>>>> (A third possible case would be to actually bring up the >>>>>> adjacency and end up running full-mesh multipoint, which would >>>>>> probably even work, but would be butt ugly.) >>>>>> >>>>>> --Dave >>>>>> >>>>>> >>>>>> On Feb 20, 2006, at 3:25 PM, Acee Lindem wrote: >>>>>> >>>>>>> Kalyan Bade wrote: >>>>>>> >>>>>>>> Acee, >>>>>>>> >>>>>>>> >>>>>>>>>> This might not work if the interface is defined as demand >>>>>>>>>> circuit. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Good point - We're in the process of discussing whether this >>>>>>>>> behavior >>>>>>>>> should be in the >>>>>>>>> draft. Possibly, handling detection of a router-id change on a >>>>>>>>> P2P >>>>>>>>> >>>>>>>> over >>>>>>>> >>>>>>>>> LAN link >>>>>>>>> differently than a normal P2P link may be a bad idea. >>>>>>>>> >>>>>>>> >>>>>>>> How about bringing down the neighbor (rather than ignoring) >>>>>>>> when a third >>>>>>>> neighbor on a P2P over LAN sends a new hello? This creates >>>>>>>> unnecessary >>>>>>>> flaps, but again having more than 2 routers on a p2p LAN is a >>>>>>>> misconfig. >>>>>>>> Atleast, the processing will be similar to a regular p2p >>>>>>>> interface. >>>>>>>> >>>>>>> That would be fine and consistent with what most routers do on >>>>>>> normal P2P links. I think the >>>>>>> P2P over LAN specific router-ID change processing should be >>>>>>> removed from the draft. >>>>>>> >>>>>>> Thanks, >>>>>>> Acee >>>>>>> >>>>>>>> Thanks, >>>>>>>> Kalyan. >>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 22 14:12:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBzPp-0000oR-KR for ospf-archive@LISTS.IETF.ORG; Wed, 22 Feb 2006 14:12:45 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBzPp-0001Qz-Cn for ospf-archive@LISTS.IETF.ORG; Wed, 22 Feb 2006 14:12:45 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <10.000326D9@wildebeest.ease.lsoft.com>; Wed, 22 Feb 2006 14:12:45 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100124458 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 22 Feb 2006 14:12:43 -0500 Received: from 198.137.194.222 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 22 Feb 2006 14:12:41 -0500 Received: (qmail 14459 invoked by uid 211); 22 Feb 2006 19:12:40 -0000 Received: from challah.msrl.com (HELO ?127.0.0.1?) (vgill@198.137.194.222) by challah.msrl.com with RC4-MD5 encrypted SMTP; 22 Feb 2006 19:12:40 -0000 User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 References: <6D975E431022374F9F7A298A511427B60D5C15@mailblr1.engineering.netscaler.com> <43FC712C.4070005@vijaygill.com> <77ead0ec0602220733h68942dc8wd7113a1b05a546b3@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <43FCB7A5.50509@vijaygill.com> Date: Wed, 22 Feb 2006 14:12:37 -0500 Reply-To: Mailing List Sender: Mailing List From: vijay gill Subject: Re: Reg: DDOS prevention in OSPF To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <77ead0ec0602220733h68942dc8wd7113a1b05a546b3@mail.gmail.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Vishwas Manral wrote: > Hi, > > > > This is the right way. See also GTSM where for some protocols, we > > used TTL as a fast key to disambiguate junk from non-junk. > GTSM is certainly a good way to clear the chaff to prevent a DDOS due to > flooding of junk packets which use authentication mechanisms, however it > may not be of much use for packets received over virtual links. > Of course, gtsm is not a catch-all. I just used it as an illustration of something that used something fast and easy to parse quickly, (eg. was in a fixed offset) so you didn't have to go through and decode the entire packet for validity, considering there may not be enough cycles/silicon to do that on the line card. In fact, I am considering the merits of having a fixed offset after the ip packet for a 32 bit field that holds a cookie that is agreed upon when an adjacency is formed, just for the purposes of quick disambiguation. /vijay > Thanks, > Vishwas > > On 2/22/06, *vijay gill* > wrote: > > Nanda Kishore S. wrote: > > Hi, > > > > > > > > In quite some places we mention that Authentication is > > > > a must to provide DDOS protection for OSPF. > > Unless you can do distributed authentication checks at the point of > ingress of traffic (i.e. at the line card, right after the framer, at > wirespeed), authentication is almost a win for DDOS, because what > happens is you get a bunch of packets with auth on them, you send them > to the CPU, CPU sits there, decoding and discarding and well, box keels > over and dies. This is the same result we saw when the MD5 auth was > turned on for BGP. Most router vendors actually had worse performance > when subject to DDOS attacks with MD5 than without, because now instead > of just discarding junk, they had to decode and then discard. > > > > > > > > > > But as simple password is not so useful we will be using > > > > MD5 authentication and even if is enabled, wont' the socket buffers > > > > become full and drop genuine adjacencies when DDOS attack happens. > > This is correct. > > > > > > > > > I was wondering if any implementations are there where > > > > authentication is done before queuing the packet at socket/packet > > > > buffer layer. > > > > > > > > My idea is implementing MD5 authentication at socket > > > > level at greater speeds (DDOS attack's speed) is not feasible or > won't > > > > give such performance so, why not have a cascaded authentication > > > > mechanism like (Simple password + MD5) so, that before queuing of > > > > packets we can do simple password at greater efficiency and MD5 for > > > > better security later. > > > > > > > > (Assuming that it won't be that easy to get the > simple password > > > > as knowing just the IP addresses of OSPF routers). > > > > > > > > Any comments? > > > > This is the right way. See also GTSM where for some protocols, we used > TTL as a fast key to disambiguate junk from non-junk. > > http://www.ietf.org/rfc/rfc3682.txt > > /vijay > > > > > > > -Nanda Kishore > > > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 22 14:27:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBzdx-0003kD-Ek for ospf-archive@LISTS.IETF.ORG; Wed, 22 Feb 2006 14:27:21 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBzdx-0002BJ-0D for ospf-archive@LISTS.IETF.ORG; Wed, 22 Feb 2006 14:27:21 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <5.00032745@wildebeest.ease.lsoft.com>; Wed, 22 Feb 2006 14:27:20 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100125710 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 22 Feb 2006 14:27:19 -0500 Received: from 66.249.82.198 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 22 Feb 2006 14:27:19 -0500 Received: by xproxy.gmail.com with SMTP id s16so1123363wxc for ; Wed, 22 Feb 2006 11:27:19 -0800 (PST) Received: by 10.70.35.3 with SMTP id i3mr6344173wxi; Wed, 22 Feb 2006 11:27:19 -0800 (PST) Received: by 10.70.7.13 with HTTP; Wed, 22 Feb 2006 11:27:19 -0800 (PST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1057_3614682.1140636439486" References: <6D975E431022374F9F7A298A511427B60D5C15@mailblr1.engineering.netscaler.com> <43FC712C.4070005@vijaygill.com> <77ead0ec0602220733h68942dc8wd7113a1b05a546b3@mail.gmail.com> <43FCB7A5.50509@vijaygill.com> Message-ID: <77ead0ec0602221127r2cf67c19h3b1f4575512d5e9e@mail.gmail.com> Date: Wed, 22 Feb 2006 11:27:19 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: Reg: DDOS prevention in OSPF To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43FCB7A5.50509@vijaygill.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: be922d419820e291bde1362184dc32fd ------=_Part_1057_3614682.1140636439486 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Vijay, The cookie mechanism is of more use in cases where either the replay of a previous session is not required or no security mechanism is used. It is more like an anti-spoofing cookie to prevent against off path attacks. Note= : It does not prevent on-path attacks at all. The cookie idea is good and is heavily used in IKE case for DDoS prevention when too many resources are being used. So if a new adjacency is to be formed and we feel we may be heavily loaded (and may be under DDoS attack) caused by sending a lot of initial request packets, we could ask the other end to send in their hellos cookies, or reflect the cookie we have sent to it, we only accept packets with the cookies. It is of course another level of removing the "junk from the non-junk" in the MD5 case and prevent off-path attacks, but not on-path attacls. Thanks, Vishwas On 2/22/06, vijay gill wrote: > > Vishwas Manral wrote: > > Hi, > > > > > > > This is the right way. See also GTSM where for some protocols, we > > > used TTL as a fast key to disambiguate junk from non-junk. > > GTSM is certainly a good way to clear the chaff to prevent a DDOS due t= o > > flooding of junk packets which use authentication mechanisms, however i= t > > may not be of much use for packets received over virtual links. > > > > Of course, gtsm is not a catch-all. I just used it as an illustration of > something that used something fast and easy to parse quickly, (eg. was > in a fixed offset) so you didn't have to go through and decode the > entire packet for validity, considering there may not be enough > cycles/silicon to do that on the line card. > > In fact, I am considering the merits of having a fixed offset after the > ip packet for a 32 bit field that holds a cookie that is agreed upon > when an adjacency is formed, just for the purposes of quick > disambiguation. > > /vijay > > > > > Thanks, > > Vishwas > > > > On 2/22/06, *vijay gill* > > wrote: > > > > Nanda Kishore S. wrote: > > > Hi, > > > > > > > > > > > > In quite some places we mention that Authentication > is > > > > > > a must to provide DDOS protection for OSPF. > > > > Unless you can do distributed authentication checks at the point of > > ingress of traffic (i.e. at the line card, right after the framer, > at > > wirespeed), authentication is almost a win for DDOS, because what > > happens is you get a bunch of packets with auth on them, you send > them > > to the CPU, CPU sits there, decoding and discarding and well, box > keels > > over and dies. This is the same result we saw when the MD5 auth was > > turned on for BGP. Most router vendors actually had worse > performance > > when subject to DDOS attacks with MD5 than without, because now > instead > > of just discarding junk, they had to decode and then discard. > > > > > > > > > > > > > > > > But as simple password is not so useful we will be > using > > > > > > MD5 authentication and even if is enabled, wont' the socket > buffers > > > > > > become full and drop genuine adjacencies when DDOS attack > happens. > > > > This is correct. > > > > > > > > > > > > > > I was wondering if any implementations are there > where > > > > > > authentication is done before queuing the packet at socket/packe= t > > > > > > buffer layer. > > > > > > > > > > > > My idea is implementing MD5 authentication at socket > > > > > > level at greater speeds (DDOS attack's speed) is not feasible or > > won't > > > > > > give such performance so, why not have a cascaded authentication > > > > > > mechanism like (Simple password + MD5) so, that before queuing o= f > > > > > > packets we can do simple password at greater efficiency and MD5 > for > > > > > > better security later. > > > > > > > > > > > > (Assuming that it won't be that easy to get the > > simple password > > > > > > as knowing just the IP addresses of OSPF routers). > > > > > > > > > > > > Any comments? > > > > > > > This is the right way. See also GTSM where for some protocols, we > used > > TTL as a fast key to disambiguate junk from non-junk. > > > > http://www.ietf.org/rfc/rfc3682.txt > > > > /vijay > > > > > > > > > > > -Nanda Kishore > > > > > > > > > > > > > > ------=_Part_1057_3614682.1140636439486 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Vijay,

The cookie mechanism is of more use in cases where either the replay of a previous session is not required or no security mechanism is used. It is more like an anti-spoofing cookie to prevent against off path attacks. Note: It does not prevent on-path attacks at all.

The cookie idea is good and is heavily used in IKE case for DDoS prevention when too many resources are being used. So if a new adjacency is to be formed and we feel we may be heavily loaded (and may be under DDoS attack) caused by sending a lot of initial request packets, we could ask the other end to send in their hellos cookies, or reflect the cookie we have sent to it, we only accept packets with the cookies.

It is of course another level of removing the "junk from the non-junk&= quot; in the MD5 case and prevent off-path attacks, but not on-path attacls.

Thanks,
Vishwas

On 2/22/06, vijay gill <vg= ill@vijaygill.com> wrote:
Vishwas Manral wrote:
> Hi,
>
>
>  > T= his is the right way. See also GTSM where for some protocols, we
>&nb= sp; > used TTL as a fast key to disambiguate junk from non-junk.> GTSM is certainly a good way to clear the chaff to prevent a DDOS due= to
> flooding of junk packets which use authentication mechanisms, howe= ver it
> may not be of much use for packets received over virtual lin= ks.
>

Of course, gtsm is not a catch-all. I just used it as an= illustration of
something that used something fast and easy to parse quickly, (eg. was<= br>in a fixed offset) so you didn't have to go through and decode the
en= tire packet for validity, considering there may not be enough
cycles/sil= icon to do that on the line card.

In fact, I am considering the merits of having a fixed offset after= the
ip packet for a 32 bit field that holds a cookie that is agreed upo= n
when an adjacency is formed, just for the purposes of quick disambigua= tion.

/vijay



> Thanks,
> Vishwas
>
> = On 2/22/06, *vijay gill* <vgill@v= ijaygill.com
> <mailto: vgill@vijaygill.com>> wrote:
>
>   &nb= sp; Nanda Kishore S. wrote:
>      >= Hi,
>      >
>  &nb= sp;   >
>      >>      >     = ;        In quite some places we mention that Authentication is
>  &= nbsp;   >
>      >= a must to provide DDOS protection for OSPF.
>
>  &nb= sp;  Unless you can do distributed authentication checks at the point = of
>     ingress of traffic (i.e. at the line card,= right after the framer, at
>     wirespeed), aut= hentication is almost a win for DDOS, because what
>   = ;  happens is you get a bunch of packets with auth on them, you send t= hem
>     to the CPU, CPU sits there, decoding and d= iscarding and well, box keels
>     over and dies= . This is the same result we saw when the MD5 auth was
>  &= nbsp;  turned on for BGP. Most router vendors actually had worse perfo= rmance
>     when subject to DDOS attacks with MD5 than= without, because now instead
>     of just disca= rding junk, they had to decode and then discard.
>
>
>&nb= sp;     >
>     =  >
>      >
>      >    &nb= sp;        But as simple password is not so useful we will be using
>  = ;    >
>      &g= t; MD5 authentication and even if is enabled, wont' the socket buffers
&= gt;      >
>    =   > become full and drop genuine adjacencies when DDOS attack = happens.
>
>     This is correct.
>
>&n= bsp;     >
>     = ; >
>      >
> &n= bsp;    >       &= nbsp;     I was wondering if any implementations are there where
>  &= nbsp;   >
>      >= authentication is done before queuing the packet at socket/packet
>&= nbsp;     >
>    &nbs= p; > buffer layer.
>      >
>      >
>   &= nbsp;  >
>      > =             My idea is implementing MD5 authentication at socket
>  &nb= sp;   >
>      > l= evel at greater speeds (DDOS attack's speed) is not feasible or
>&nbs= p;    won't
>      ><= br>>      > give such performance so, w= hy not have a cascaded authentication
>      >
>   &= nbsp;  > mechanism like (Simple password + MD5) so, that befor= e queuing of
>      >
> &= nbsp;    > packets we can do simple password at grea= ter efficiency and MD5 for
>      >
>      > better security later.
= >      >
>    = ;  >
>      >
>&n= bsp;     >      &= nbsp;      (Assuming that it won't be that easy to get the
>   &n= bsp; simple password
>      >
>= ;      > as knowing just the IP addresses = of OSPF routers).
>      >
>&n= bsp;     >
>     = ; >
>      > Any comments?
> &nb= sp;    >
>
>     Thi= s is the right way. See also GTSM where for some protocols, we used
>=      TTL as a fast key to disambiguate junk from non-ju= nk.
>
>    =20 http://www.ietf.org/rfc/rfc= 3682.txt
>
>     /vijay
>
>=       >
>    &nb= sp; >
>      > -Nanda Kishor= e
>      >
>   =    >
>      >
>
>

------=_Part_1057_3614682.1140636439486-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 22 15:52:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC0yQ-0008Nc-8i for ospf-archive@LISTS.IETF.ORG; Wed, 22 Feb 2006 15:52:34 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC0yP-0007Y1-Nu for ospf-archive@LISTS.IETF.ORG; Wed, 22 Feb 2006 15:52:34 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <9.0003287B@wildebeest.ease.lsoft.com>; Wed, 22 Feb 2006 15:52:33 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100130387 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 22 Feb 2006 15:52:32 -0500 Received: from 207.69.195.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 22 Feb 2006 15:52:32 -0500 Received: from h-68-164-155-88.snvacaid.dynamic.covad.net ([68.164.155.88] helo=earthlink.net) by pop-borzoi.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1FC0yN-0000BV-00 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 22 Feb 2006 15:52:31 -0500 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <6D975E431022374F9F7A298A511427B60D5C15@mailblr1.engineering.netscaler.com> <43FC712C.4070005@vijaygill.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit Message-ID: <43FCD2F3.F0C9207D@earthlink.net> Date: Wed, 22 Feb 2006 13:09:07 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Reg: DDOS prevention in OSPF To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Group, Shouldn't their be a way to implement a simple lightweight mechanism that can mechanism that can match src IP address with router-id? The DOS attacker(s) must know router id's that we accept control pkts from. This removes the new hellos from router's as exception cases. Thus, we only need to do a minimal pre-check iff we are failing a percentage of OSPF auths. If the auth failures are occuring at a single intf if it feasible that one could also implement some QoS type process that sets the processing of those pkts at a lower priority best effort basis. The logic of doing a minimal pre-check is with the assumption that the burst of packets per sec (pps) is short enough in duration that the buffer will not overflow/tail drop. If an attack or a LSA flooding storm is present, a simple RED on a combined input queue that drops the identifyied OSPF pkt type (if identified) other than hello SHOULD not cause an adj to be dropped. However, with OSPF we should have excess capacity with recving Update pkts / flooding to handle flooding bursts and even if we drop some recv'd updates, they should be resent anyways. If the AREA is somewhat stable, 99+% of these LSAs are just age refreshes and will not effect routing if not immedaitely handled. The other 0.9% are new LSAs that would result in newer routes that no application will use in the near future. The last 0.1% of LSAs are the important ones. So, unless the router is totally stuck in processing bad LSAs the router SHOULD still operate normally in a normally stable area. And I would think a more effective DOS attack would be a wirespeed of pings to the router from a number of attackers. These pkts would force some type of tail or RED at the input buffer of the router AND would be a system wide attack. This would force recption and many echo replies. Mitchell Erblich ----------------- vijay gill wrote: > > Nanda Kishore S. wrote: > > Hi, > > > > > > > > In quite some places we mention that Authentication is > > > > a must to provide DDOS protection for OSPF. > > Unless you can do distributed authentication checks at the point of > ingress of traffic (i.e. at the line card, right after the framer, at > wirespeed), authentication is almost a win for DDOS, because what > happens is you get a bunch of packets with auth on them, you send them > to the CPU, CPU sits there, decoding and discarding and well, box keels > over and dies. This is the same result we saw when the MD5 auth was > turned on for BGP. Most router vendors actually had worse performance > when subject to DDOS attacks with MD5 than without, because now instead > of just discarding junk, they had to decode and then discard. > > > > > > > > > But as simple password is not so useful we will be using > > > > MD5 authentication and even if is enabled, wont’ the socket buffers > > > > become full and drop genuine adjacencies when DDOS attack happens. > > This is correct. > > > > > > > > > I was wondering if any implementations are there where > > > > authentication is done before queuing the packet at socket/packet > > > > buffer layer. > > > > > > > > My idea is implementing MD5 authentication at socket > > > > level at greater speeds (DDOS attack’s speed) is not feasible or won’t > > > > give such performance so, why not have a cascaded authentication > > > > mechanism like (Simple password + MD5) so, that before queuing of > > > > packets we can do simple password at greater efficiency and MD5 for > > > > better security later. > > > > > > > > (Assuming that it won’t be that easy to get the simple password > > > > as knowing just the IP addresses of OSPF routers). > > > > > > > > Any comments? > > > > This is the right way. See also GTSM where for some protocols, we used > TTL as a fast key to disambiguate junk from non-junk. > > http://www.ietf.org/rfc/rfc3682.txt > > /vijay > > > > > > > -Nanda Kishore > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 22 16:41:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC1k6-0003Nl-TN for ospf-archive@LISTS.IETF.ORG; Wed, 22 Feb 2006 16:41:51 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC1k6-0004Vo-LF for ospf-archive@LISTS.IETF.ORG; Wed, 22 Feb 2006 16:41:50 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <4.00032A17@wildebeest.ease.lsoft.com>; Wed, 22 Feb 2006 16:41:49 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100133769 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 22 Feb 2006 16:41:49 -0500 Received: from 171.71.176.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 22 Feb 2006 16:41:49 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 22 Feb 2006 13:41:49 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1MLfmVb007317 for ; Wed, 22 Feb 2006 13:41:48 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Feb 2006 16:41:47 -0500 Received: from [10.82.216.55] ([10.82.216.55]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Feb 2006 16:41:47 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <43F63D76.4030009@cisco.com> <000b01c635cb$cddcca30$610c6f0a@china.huawei.com> <43F9DD10.8040305@cisco.com> <001601c636e4$5ea03980$610c6f0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Feb 2006 21:41:47.0635 (UTC) FILETIME=[C82B8430:01C637F8] Message-ID: <43FCDA9B.9050307@cisco.com> Date: Wed, 22 Feb 2006 16:41:47 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-kou-ospf-immediately-replying-hello-00.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <001601c636e4$5ea03980$610c6f0a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Zengjie Kou wrote: >Hi, Acee, > You are right, immediate hello does not provide the mechanism of detecting link down fast. But, immediate hello improve to discover neighbors when interface goes down then up. In practice, the requirement is needed. > > Hi Zengjie, Speaking strictly in terms of state machines, it seems the interface would lose it's DR/BDR state when it goes down (and cannot send a hello). Wouldn't this scenario be better handled by the empty hello many OSPF implementations send when an interface first comes up? Thanks, Acee >Thanks, >Zengjie > >----- Original Message ----- >From: "Acee Lindem" >To: >Sent: Monday, February 20, 2006 11:15 PM >Subject: Re: draft-kou-ospf-immediately-replying-hello-00.txt > > > > >>Hi Zengjie, >> >>Zengjie Kou wrote: >> >> >> >>>Hi,Acee, >>> If a router interface whose role is changed(e.g.DR goes down), the router will notify all routers about the change by immediate hello. >>> >>> >>> >>> >>This is only when the DR/BDR knows that it is going down or the case >>where the router >>priority is set to 0. >> >>For a router becoming DR/BDR, all the routers should elect the same DR/BDR >>so I don't see how it helps. >> >>Thanks, >>Acee >> >> >> >>>After all router get the change, election will be reprocessed. In contrast to normal hello, immediate hello avoid the backupSeen. >>>Namely, improving convergence. >>> >>>Thanks a lot, >>>Zengjie >>> >>>----- Original Message ----- >>>From: "Acee Lindem" >>>To: >>>Sent: Saturday, February 18, 2006 5:17 AM >>>Subject: draft-kou-ospf-immediately-replying-hello-00.txt >>> >>> >>> >>> >>> >>> >>>>Hi Zengjie, >>>> >>>>Under what situations does having the router who changed to/from >>>>DR/BDR improve convergence (section 6.2)? Since DR/BDR election >>>>is a distributed algorithm dependent on the calculating routers state, it >>>>seems this won't help in all that many cases. >>>> >>>>Thanks, >>>>Acee >>>> >>>> >>>> >>>> >>> >>> >>> >>> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 22 16:53:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC1vh-0004Ua-E2 for ospf-archive@LISTS.IETF.ORG; Wed, 22 Feb 2006 16:53:49 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC1vh-0004tC-1B for ospf-archive@LISTS.IETF.ORG; Wed, 22 Feb 2006 16:53:49 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <15.000328FA@wildebeest.ease.lsoft.com>; Wed, 22 Feb 2006 16:53:48 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100134465 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 22 Feb 2006 16:53:48 -0500 Received: from 207.17.137.120 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 22 Feb 2006 16:53:48 -0500 Received: from unknown (HELO beta.jnpr.net) ([172.24.18.109]) by kremlin.juniper.net with ESMTP; 22 Feb 2006 13:53:47 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,137,1139212800"; d="scan'208"; a="529495704:sNHT29310384" Received: from hadron.jnpr.net ([172.24.15.25]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Feb 2006 13:53:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Detecting router id change in p2p-over-lan connection Thread-Index: AcY3cufUyCwC4LWXRdKNKhxXb0QEcQAhuZ+w X-OriginalArrivalTime: 22 Feb 2006 21:53:46.0618 (UTC) FILETIME=[74B79DA0:01C637FA] Message-ID: Date: Wed, 22 Feb 2006 13:53:45 -0800 Reply-To: Mailing List Sender: Mailing List From: Sunil Patro Subject: Re: Detecting router id change in p2p-over-lan connection To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 Hi Everyone, Thanks for all the feedback.=20 Can I safely assume that the final behavior is what Acee's recommended paragraph says below?=20 "If the system ID or the router ID in an incoming hello packet doesn't match the the system ID or router ID for an established adjacency over a p2p-over-lan circuit, the packet MUST be discarded. Futhermore, if OSPF hello suppression as described in [DEMAND] is active for the adjacency, it MUST be terminated and renegotiated." Thanks, Sunil > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Naiming > Shen > Sent: Tuesday, February 21, 2006 9:43 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Detecting router id change in p2p-over-lan connection >=20 > Hello Acee, >=20 > Your suggested paragraph looks fine with me. >=20 > Even though this sentence assumes there is really a > router-id change from a DC neighbor. A router probably > should send a 'neighbor probing' [RFC 3883], if no > response, then reset the adjacency and start > the renegotiation; otherwise it should still ignore > the new join on the p2p-over-lan link. >=20 > But I would consider router-id change over a demand > circuit over a p2p-over-lan on OSPF link a > 'misconfiguration';-) so it does not matter too much. > Your version is fine. >=20 > thanks. > - Naiming >=20 > Acee Lindem said the following on 02/21/2006 02:47 PM: > > Hello Naiming, > > > > Naiming Shen wrote: > > > >> Acee Lindem said the following on 02/21/2006 06:04 AM: > >> > >>> Naiming Shen wrote: > >>> > >>>> Agree with Dave's argument, and this is the same idea as in the > >>>> current draft of p2p-over-lan (section 4.5): > >>>> > >>>> ... If the system ID or the > >>>> router ID of incoming hello packet does not match the system ID or > >>>> the router ID of already established adjacency over this > >>>> p2p-over-lan > >>>> circuit, it MUST discard the packet. The implementation should > offer > >>>> logging and debugging information of the above events. > >>>> > >>>> Do we need to change anything here? > >>> > >>> > >>> > >>> > >>> Hi Naiming, > >>> > >>> Given that this situation can happen in the case of misconfiguration > or > >>> router-ID change, I wouldn't optimize for the former. Especially > >>> considering Kalyan's point that if hello's are suppressed, the > >>> router-id change > >>> will either not be recognized or require additional logic. I'd vote > >>> to either > >>> leave it unspecified (consistent with RFC 2328's omission of router-id > >>> change P2P link handling) or discard the old neighbor and bring up > >>> an adjacency with the new (which is what at least one implementation > >>> does > >>> today). > >> > >> > >> > >> Hello Acee, > >> > >> The original idea in the draft was to prevent multiple routers joinning > >> onto the same LAN rather than handing the router-ID change from the > >> same router. Even through there is a side effect to it. > >> > >> For the router-ID change issue. If one is willing to change router-ID > >> or system-ID during normal operation, there are more things broken > >> and there is nothing wrong to wait until the current adjacent timeout. > > > > > > Agreed. > > > >> If the hello is suppressed over the link, then the behaviour is not > >> bounded by this paragraph since it does not say the purpose is to > >> detect neighbor router-id change. > > > > > > I disagree here. It says "MUST discard packet". That sounds pretty > > bounding to me :^). > > > >> Also there is little reason to > >> suppress a hello over p2p-over-lan links. Thus I don't think > >> router-id is an issue with this sentence. > > > > > > I agree - but there is nothing in this draft or RFC 1793 that precludes > it. > > > >> > >> Since p2p-over-lan is different from normal p2p circuit that multiple > >> routers can easily join the same LAN unintentionally. If we ignore > >> the new station to join, then we can prevent the adjacency constant > >> flapping(this does not happen to normal p2p link), the worst it can > >> happen is slow to handle router-id change as mentioned above, which > >> is a non issue. Thus I think it's a good thing to ignore the extra > >> adjacency joinning. This sentence does not govern the normal p2p link > >> behaviour so the implementation is ok(even prefered) to reset the > >> existing adjacency on a normal p2p link. Thus I don't think we > >> should say we must reset the current adjacency for p2p-over-lan. > >> > >> My preference of this sentence in the draft is with this order: > >> > >> - leave it as is > >> - change the MUST to SHOULD > >> - remove the router-id related sentence > > > > > > How about leave it "almost" as is: > > > > If the system ID or the router ID in an incoming hello packet > doesn't > > match the the system ID or router ID for an established adjacency > over > > a p2p-over-lan circuit, the packet MUST be discarded. Futhermore, > > if OSPF hello suppression as described in [DEMAND] is active for the > > adjacency, it MUST be terminated and renegotiated. > > > > [DEMAND] Moy, J., "Extending OSPF to Support Demand Circuits", > > RFC 1793, April 1995. > > > > Thanks, > > Acee > > > >> thanks. > >> - Naiming > >> > >>> > >>> Thanks, > >>> Acee > >>> > >>> Thanks, > >>> Acee > >>> > >>>> > >>>> thanks. > >>>> - Naiming > >>>> > >>>> Dave Katz said the following on 02/20/2006 08:53 PM: > >>>> > >>>>> RFC2328 is silent on what to do if you see a different router ID on > >>>>> a P2P link; if you take it literally, you will create two > >>>>> adjacencies (temporarily), advertise both in your router LSA, and > >>>>> your network will most likely black hole traffic until one of them > >>>>> times out. > >>>>> > >>>>> On real P2P links, this will suffice (if you don't mind a network > >>>>> outage for the dead time of the old adjacency) and things will > >>>>> eventually stabilize since it is "impossible" (cough) two get two > >>>>> neighbors in 2Way. The fact that it is underspecified doesn't > >>>>> matter that much. > >>>>> > >>>>> In the P2P-over-LAN case, there needs to be a mechanism to try to > >>>>> do something useful if there turn out to be more than two routers > >>>>> on the link. I don't think it's reasonable to say "gee it's > >>>>> misconfigured, we don't care what happens to the network." > >>>>> > >>>>> > >>>>> It seems to me that there are two possible cases, namely, use the > >>>>> old adjacency until it times out (effectively ignoring the hellos > >>>>> from the new guy) or to form an adjacency with the new guy (and > >>>>> blow away or otherwise ignore the old guy.) > >>>>> > >>>>> The first case has the advantage of stability and simplicity--the > >>>>> third router that shows up for the party will be ignored by both > >>>>> parties. There is a potential for a circle of one-way adjacencies > >>>>> to stabilize, but this will still be stable (there won't be a > >>>>> usable adjacency across the subnetwork.) > >>>>> > >>>>> The second case has the advantage that it adapts more quickly when > >>>>> something changes. Some implementations already do this for the > >>>>> pure P2P case. However, it is destabilizing in the > >>>>> misconfiguration case, as the router will flap its router LSA each > >>>>> time another Hello is received. Probably the only reasonable way > >>>>> out would be to detect the flap and then choose one neighbor and > >>>>> stick to it, ignoring the other (which degenerates into the first > >>>>> case.) > >>>>> > >>>>> Given all of this, I'd propose that the right thing to do is the > >>>>> first case, and suffer through the dead time (or use BFD and > >>>>> suffer through the detection time.) > >>>>> > >>>>> (A third possible case would be to actually bring up the adjacency > >>>>> and end up running full-mesh multipoint, which would probably even > >>>>> work, but would be butt ugly.) > >>>>> > >>>>> --Dave > >>>>> > >>>>> > >>>>> On Feb 20, 2006, at 3:25 PM, Acee Lindem wrote: > >>>>> > >>>>>> Kalyan Bade wrote: > >>>>>> > >>>>>>> Acee, > >>>>>>> > >>>>>>> > >>>>>>>>> This might not work if the interface is defined as demand > circuit. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> Good point - We're in the process of discussing whether this > >>>>>>>> behavior > >>>>>>>> should be in the > >>>>>>>> draft. Possibly, handling detection of a router-id change on a > P2P > >>>>>>>> > >>>>>>> over > >>>>>>> > >>>>>>>> LAN link > >>>>>>>> differently than a normal P2P link may be a bad idea. > >>>>>>>> > >>>>>>> > >>>>>>> How about bringing down the neighbor (rather than ignoring) when > >>>>>>> a third > >>>>>>> neighbor on a P2P over LAN sends a new hello? This creates > >>>>>>> unnecessary > >>>>>>> flaps, but again having more than 2 routers on a p2p LAN is a > >>>>>>> misconfig. > >>>>>>> Atleast, the processing will be similar to a regular p2p > interface. > >>>>>>> > >>>>>> That would be fine and consistent with what most routers do on > >>>>>> normal P2P links. I think the > >>>>>> P2P over LAN specific router-ID change processing should be > >>>>>> removed from the draft. > >>>>>> > >>>>>> Thanks, > >>>>>> Acee > >>>>>> > >>>>>>> Thanks, > >>>>>>> Kalyan. > >>>>>>> > >>>>>>> > >>>>>> > >>>> > >> From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 22 17:06:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC27c-00064C-Qv for ospf-archive@LISTS.IETF.ORG; Wed, 22 Feb 2006 17:06:08 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC27b-000599-Kh for ospf-archive@LISTS.IETF.ORG; Wed, 22 Feb 2006 17:06:08 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <12.00032A1B@wildebeest.ease.lsoft.com>; Wed, 22 Feb 2006 17:06:07 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100135331 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 22 Feb 2006 17:06:06 -0500 Received: from 207.17.137.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 22 Feb 2006 17:04:30 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k1MM4TX54886 for ; Wed, 22 Feb 2006 14:04:30 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.13] (nimbus-sc.juniper.net [172.16.12.13]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k1MM4O519949 for ; Wed, 22 Feb 2006 14:04:24 -0800 (PST) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v746.2) References: <6D975E431022374F9F7A298A511427B60D5C15@mailblr1.engineering.netscaler.com> <43FC712C.4070005@vijaygill.com> <43FCD2F3.F0C9207D@earthlink.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.746.2) Message-ID: <3B587DB1-176D-4202-B9C4-0116CE6B0699@juniper.net> Date: Wed, 22 Feb 2006 14:04:23 -0800 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: Reg: DDOS prevention in OSPF To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43FCD2F3.F0C9207D@earthlink.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a On Feb 22, 2006, at 1:09 PM, Erblichs wrote: > Group, > > Shouldn't their be a way to implement a simple > lightweight mechanism that can mechanism that > can match src IP address with router-id? > > The DOS attacker(s) must know router id's that > we accept control pkts from. > If the attacker has access to the LSDB, this is a trivial thing to figure out. If the network is properly secured (tossing all OSPF packets at the edge), the most likely attack of this type is going to be from inside (topologically) in which case the LSDB is going to potentially be accessible. Realistically I think OSPF authentication needs to be viewed as a last-resort mechanism to try to protect the infrastructure as best as can be done if all other defenses have been penetrated. OSPF MD5 authentication is unlikely to get the kind of hardware assist necessary to do this well, since it's one-off and kind of gross. As Fred mentioned, running inside IPsec makes a lot more sense (since hardware assist is generally available.) This also makes eavesdropping much more difficult for no extra charge. --Dave From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 22 17:12:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC2Dd-0006jx-E8 for ospf-archive@LISTS.IETF.ORG; Wed, 22 Feb 2006 17:12:21 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC2Dd-0005Pp-5X for ospf-archive@LISTS.IETF.ORG; Wed, 22 Feb 2006 17:12:21 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <7.00032A43@wildebeest.ease.lsoft.com>; Wed, 22 Feb 2006 17:12:20 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100136519 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 22 Feb 2006 17:12:20 -0500 Received: from 66.249.82.195 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 22 Feb 2006 17:12:20 -0500 Received: by xproxy.gmail.com with SMTP id t10so1160618wxc for ; Wed, 22 Feb 2006 14:12:20 -0800 (PST) Received: by 10.70.21.19 with SMTP id 19mr6498092wxu; Wed, 22 Feb 2006 14:12:20 -0800 (PST) Received: by 10.70.7.13 with HTTP; Wed, 22 Feb 2006 14:12:20 -0800 (PST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2862_31770149.1140646340185" References: <6D975E431022374F9F7A298A511427B60D5C15@mailblr1.engineering.netscaler.com> <43FC712C.4070005@vijaygill.com> <43FCD2F3.F0C9207D@earthlink.net> <3B587DB1-176D-4202-B9C4-0116CE6B0699@juniper.net> Message-ID: <77ead0ec0602221412n671022caj4eee34ee5cfc508c@mail.gmail.com> Date: Wed, 22 Feb 2006 14:12:20 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: Reg: DDOS prevention in OSPF To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <3B587DB1-176D-4202-B9C4-0116CE6B0699@juniper.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.5 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 ------=_Part_2862_31770149.1140646340185 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Dave, Good points there about IPsec being a better solution than a patch solution= s we are talking about. With automatic key generation mechanisms we can get over most of the problems encountered. However other issues like verifying identity (eg. PKI) and related topics come into picture. Besides I would like to add, there are quite a few security coprocessors ou= t there, to which we feed the data, give the key and the algorithm name and w= e get the message digest. Thanks, Vishwas On 2/22/06, Dave Katz wrote: > > On Feb 22, 2006, at 1:09 PM, Erblichs wrote: > > > Group, > > > > Shouldn't their be a way to implement a simple > > lightweight mechanism that can mechanism that > > can match src IP address with router-id? > > > > The DOS attacker(s) must know router id's that > > we accept control pkts from. > > > > If the attacker has access to the LSDB, this is a trivial thing to > figure out. > > If the network is properly secured (tossing all OSPF packets at the > edge), the most likely attack of this type is going to be from inside > (topologically) in which case the LSDB is going to potentially be > accessible. > > Realistically I think OSPF authentication needs to be viewed as a > last-resort mechanism to try to protect the infrastructure as best as > can be done if all other defenses have been penetrated. OSPF MD5 > authentication is unlikely to get the kind of hardware assist > necessary to do this well, since it's one-off and kind of gross. As > Fred mentioned, running inside IPsec makes a lot more sense (since > hardware assist is generally available.) This also makes > eavesdropping much more difficult for no extra charge. > > --Dave > ------=_Part_2862_31770149.1140646340185 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Dave,

Good points there about IPsec being a better solution than a patch solutions we are talking about. With automatic key generation mechanisms we can get over most of the problems encountered. However other issues like verifying identity (eg. PKI) and related topics come into picture.

Besides I would like to add, there are quite a few security coprocessors out there, to which we feed the data, give the key and the algorithm name and we get the message digest.

Thanks,
Vishwas

On 2/22/06, Dave Katz <dkatz@juniper.ne= t> wrote:
On Feb 22, 2006, at 1:09 PM, Erblichs wrote:

> Group,
>
= >       Shouldn't their be a way to implem= ent a simple
>       lightweight mechan= ism that can mechanism that
>       can= match src IP address with router-id?
>
>       The DOS attacker(s) mu= st know router id's that
>       we acc= ept control pkts from.
>

If the attacker has access to the LSD= B, this is a trivial thing to
figure out.

If the network is prope= rly secured (tossing all OSPF packets at the
edge), the most likely attack of this type is going to be from inside(topologically) in which case the LSDB is going to potentially be
acce= ssible.

Realistically I think OSPF authentication needs to be viewed= as a
last-resort mechanism to try to protect the infrastructure as best ascan be done if all other defenses have been penetrated.  OSPF M= D5
authentication is unlikely to get the kind of hardware assist
nece= ssary to do this well, since it's one-off and kind of gross.  As
Fred mentioned, running inside IPsec makes a lot more sense (since
h= ardware assist is generally available.)  This also makes
eaves= dropping much more difficult for no extra charge.

--Dave

------=_Part_2862_31770149.1140646340185-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 22 17:39:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC2dk-0002kX-4y for ospf-archive@LISTS.IETF.ORG; Wed, 22 Feb 2006 17:39:20 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC2di-0007fJ-Rj for ospf-archive@LISTS.IETF.ORG; Wed, 22 Feb 2006 17:39:20 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <0.00032AF4@wildebeest.ease.lsoft.com>; Wed, 22 Feb 2006 17:39:18 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100137607 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 22 Feb 2006 17:39:17 -0500 Received: from 207.69.195.68 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 22 Feb 2006 17:39:17 -0500 Received: from h-68-164-155-88.snvacaid.dynamic.covad.net ([68.164.155.88] helo=earthlink.net) by pop-cowbird.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1FC2dg-0007YJ-00 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 22 Feb 2006 17:39:16 -0500 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <6D975E431022374F9F7A298A511427B60D5C15@mailblr1.engineering.netscaler.com> <43FC712C.4070005@vijaygill.com> <43FCD2F3.F0C9207D@earthlink.net> <3B587DB1-176D-4202-B9C4-0116CE6B0699@juniper.net> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43FCEB8B.8F628FF7@earthlink.net> Date: Wed, 22 Feb 2006 14:54:03 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Reg: DDOS prevention in OSPF To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Dave Katz wrote: > > On Feb 22, 2006, at 1:09 PM, Erblichs wrote: > > > Group, > > > > Shouldn't their be a way to implement a simple > > lightweight mechanism that can mechanism that > > can match src IP address with router-id? > > > > The DOS attacker(s) must know router id's that > > we accept control pkts from. > > > > If the attacker has access to the LSDB, this is a trivial thing to > figure out. > > If the network is properly secured (tossing all OSPF packets at the > edge), the most likely attack of this type is going to be from inside > (topologically) in which case the LSDB is going to potentially be > accessible. Yes, but I assume that 99% of the attacks will not be physically within the AREA. Not being in the area, SHOULD prevent LSA flooding or hellos reaching the attacker(s). If it were within the area, the attack would be more successful because the AREA/AS was no longer consisting of TRUSTED entities. But it should be easier to isolate the attackers and then the routing domain is in control of the admins. then Again the more generic intf isolation/QoS change in the case that auth failures indicated a possible attack COULD also be used. Lastly, if it were within the area, a more sucessful attack is one which is subtle by flooding invalid/bad LSAs that result in poor routing. Mitchell Erblich ------------------------ > > Realistically I think OSPF authentication needs to be viewed as a > last-resort mechanism to try to protect the infrastructure as best as > can be done if all other defenses have been penetrated. OSPF MD5 > authentication is unlikely to get the kind of hardware assist > necessary to do this well, since it's one-off and kind of gross. As > Fred mentioned, running inside IPsec makes a lot more sense (since > hardware assist is generally available.) This also makes > eavesdropping much more difficult for no extra charge. > > --Dave From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 22 18:33:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC3UG-0007uh-Dn for ospf-archive@LISTS.IETF.ORG; Wed, 22 Feb 2006 18:33:36 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC3UD-0001ja-VQ for ospf-archive@LISTS.IETF.ORG; Wed, 22 Feb 2006 18:33:36 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <11.00032BCB@wildebeest.ease.lsoft.com>; Wed, 22 Feb 2006 18:33:33 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100140386 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 22 Feb 2006 18:33:32 -0500 Received: from 207.69.195.67 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 22 Feb 2006 18:33:31 -0500 Received: from h-68-164-155-88.snvacaid.dynamic.covad.net ([68.164.155.88] helo=earthlink.net) by pop-tawny.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1FC2E2-0007mM-00 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 22 Feb 2006 17:12:46 -0500 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43FCE57C.F3939448@earthlink.net> Date: Wed, 22 Feb 2006 14:28:12 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Detecting router id change in p2p-over-lan connection To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b Sunil, "MUST be terminated and renegotiated." wouldn't a empty hello MUST be sent that will terminate the adj and then renegotiated. be a more complete behavior. Else, what would it mean to terminate the adj? Mitchell Erblich --------------------- Sunil Patro wrote: > > Hi Everyone, > > Thanks for all the feedback. > > Can I safely assume that the final behavior is what Acee's recommended > paragraph says below? > > "If the system ID or the router ID in an incoming hello packet > doesn't match the the system ID or router ID for an established > adjacency > over a p2p-over-lan circuit, the packet MUST be discarded. Futhermore, > if OSPF hello suppression as described in [DEMAND] is active for the > adjacency, it MUST be terminated and renegotiated." > > Thanks, > Sunil > > > -----Original Message----- > > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > Naiming > > Shen > > Sent: Tuesday, February 21, 2006 9:43 PM > > To: OSPF@PEACH.EASE.LSOFT.COM > > Subject: Re: Detecting router id change in p2p-over-lan connection > > > > Hello Acee, > > > > Your suggested paragraph looks fine with me. > > > > Even though this sentence assumes there is really a > > router-id change from a DC neighbor. A router probably > > should send a 'neighbor probing' [RFC 3883], if no > > response, then reset the adjacency and start > > the renegotiation; otherwise it should still ignore > > the new join on the p2p-over-lan link. > > > > But I would consider router-id change over a demand > > circuit over a p2p-over-lan on OSPF link a > > 'misconfiguration';-) so it does not matter too much. > > Your version is fine. > > > > thanks. > > - Naiming > > > > Acee Lindem said the following on 02/21/2006 02:47 PM: > > > Hello Naiming, > > > > > > Naiming Shen wrote: > > > > > >> Acee Lindem said the following on 02/21/2006 06:04 AM: > > >> > > >>> Naiming Shen wrote: > > >>> > > >>>> Agree with Dave's argument, and this is the same idea as in the > > >>>> current draft of p2p-over-lan (section 4.5): > > >>>> > > >>>> ... If the system ID or the > > >>>> router ID of incoming hello packet does not match the system > ID or > > >>>> the router ID of already established adjacency over this > > >>>> p2p-over-lan > > >>>> circuit, it MUST discard the packet. The implementation should > > offer > > >>>> logging and debugging information of the above events. > > >>>> > > >>>> Do we need to change anything here? > > >>> > > >>> > > >>> > > >>> > > >>> Hi Naiming, > > >>> > > >>> Given that this situation can happen in the case of > misconfiguration > > or > > >>> router-ID change, I wouldn't optimize for the former. Especially > > >>> considering Kalyan's point that if hello's are suppressed, the > > >>> router-id change > > >>> will either not be recognized or require additional logic. I'd > vote > > >>> to either > > >>> leave it unspecified (consistent with RFC 2328's omission of > router-id > > >>> change P2P link handling) or discard the old neighbor and bring up > > >>> an adjacency with the new (which is what at least one > implementation > > >>> does > > >>> today). > > >> > > >> > > >> > > >> Hello Acee, > > >> > > >> The original idea in the draft was to prevent multiple routers > joinning > > >> onto the same LAN rather than handing the router-ID change from the > > >> same router. Even through there is a side effect to it. > > >> > > >> For the router-ID change issue. If one is willing to change > router-ID > > >> or system-ID during normal operation, there are more things broken > > >> and there is nothing wrong to wait until the current adjacent > timeout. > > > > > > > > > Agreed. > > > > > >> If the hello is suppressed over the link, then the behaviour is not > > >> bounded by this paragraph since it does not say the purpose is to > > >> detect neighbor router-id change. > > > > > > > > > I disagree here. It says "MUST discard packet". That sounds pretty > > > bounding to me :^). > > > > > >> Also there is little reason to > > >> suppress a hello over p2p-over-lan links. Thus I don't think > > >> router-id is an issue with this sentence. > > > > > > > > > I agree - but there is nothing in this draft or RFC 1793 that > precludes > > it. > > > > > >> > > >> Since p2p-over-lan is different from normal p2p circuit that > multiple > > >> routers can easily join the same LAN unintentionally. If we ignore > > >> the new station to join, then we can prevent the adjacency constant > > >> flapping(this does not happen to normal p2p link), the worst it can > > >> happen is slow to handle router-id change as mentioned above, which > > >> is a non issue. Thus I think it's a good thing to ignore the extra > > >> adjacency joinning. This sentence does not govern the normal p2p > link > > >> behaviour so the implementation is ok(even prefered) to reset the > > >> existing adjacency on a normal p2p link. Thus I don't think we > > >> should say we must reset the current adjacency for p2p-over-lan. > > >> > > >> My preference of this sentence in the draft is with this order: > > >> > > >> - leave it as is > > >> - change the MUST to SHOULD > > >> - remove the router-id related sentence > > > > > > > > > How about leave it "almost" as is: > > > > > > If the system ID or the router ID in an incoming hello packet > > doesn't > > > match the the system ID or router ID for an established > adjacency > > over > > > a p2p-over-lan circuit, the packet MUST be discarded. > Futhermore, > > > if OSPF hello suppression as described in [DEMAND] is active for > the > > > adjacency, it MUST be terminated and renegotiated. > > > > > > [DEMAND] Moy, J., "Extending OSPF to Support Demand Circuits", > > > RFC 1793, April 1995. > > > > > > Thanks, > > > Acee > > > > > >> thanks. > > >> - Naiming > > >> > > >>> > > >>> Thanks, > > >>> Acee > > >>> > > >>> Thanks, > > >>> Acee > > >>> > > >>>> > > >>>> thanks. > > >>>> - Naiming > > >>>> > > >>>> Dave Katz said the following on 02/20/2006 08:53 PM: > > >>>> > > >>>>> RFC2328 is silent on what to do if you see a different router ID > on > > >>>>> a P2P link; if you take it literally, you will create two > > >>>>> adjacencies (temporarily), advertise both in your router LSA, > and > > >>>>> your network will most likely black hole traffic until one of > them > > >>>>> times out. > > >>>>> > > >>>>> On real P2P links, this will suffice (if you don't mind a > network > > >>>>> outage for the dead time of the old adjacency) and things will > > >>>>> eventually stabilize since it is "impossible" (cough) two get > two > > >>>>> neighbors in 2Way. The fact that it is underspecified doesn't > > >>>>> matter that much. > > >>>>> > > >>>>> In the P2P-over-LAN case, there needs to be a mechanism to try > to > > >>>>> do something useful if there turn out to be more than two > routers > > >>>>> on the link. I don't think it's reasonable to say "gee it's > > >>>>> misconfigured, we don't care what happens to the network." > > >>>>> > > >>>>> > > >>>>> It seems to me that there are two possible cases, namely, use > the > > >>>>> old adjacency until it times out (effectively ignoring the > hellos > > >>>>> from the new guy) or to form an adjacency with the new guy (and > > >>>>> blow away or otherwise ignore the old guy.) > > >>>>> > > >>>>> The first case has the advantage of stability and > simplicity--the > > >>>>> third router that shows up for the party will be ignored by both > > >>>>> parties. There is a potential for a circle of one-way > adjacencies > > >>>>> to stabilize, but this will still be stable (there won't be a > > >>>>> usable adjacency across the subnetwork.) > > >>>>> > > >>>>> The second case has the advantage that it adapts more quickly > when > > >>>>> something changes. Some implementations already do this for the > > >>>>> pure P2P case. However, it is destabilizing in the > > >>>>> misconfiguration case, as the router will flap its router LSA > each > > >>>>> time another Hello is received. Probably the only reasonable > way > > >>>>> out would be to detect the flap and then choose one neighbor > and > > >>>>> stick to it, ignoring the other (which degenerates into the > first > > >>>>> case.) > > >>>>> > > >>>>> Given all of this, I'd propose that the right thing to do is the > > >>>>> first case, and suffer through the dead time (or use BFD and > > >>>>> suffer through the detection time.) > > >>>>> > > >>>>> (A third possible case would be to actually bring up the > adjacency > > >>>>> and end up running full-mesh multipoint, which would probably > even > > >>>>> work, but would be butt ugly.) > > >>>>> > > >>>>> --Dave > > >>>>> > > >>>>> > > >>>>> On Feb 20, 2006, at 3:25 PM, Acee Lindem wrote: > > >>>>> > > >>>>>> Kalyan Bade wrote: > > >>>>>> > > >>>>>>> Acee, > > >>>>>>> > > >>>>>>> > > >>>>>>>>> This might not work if the interface is defined as demand > > circuit. > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>> Good point - We're in the process of discussing whether this > > >>>>>>>> behavior > > >>>>>>>> should be in the > > >>>>>>>> draft. Possibly, handling detection of a router-id change on > a > > P2P > > >>>>>>>> > > >>>>>>> over > > >>>>>>> > > >>>>>>>> LAN link > > >>>>>>>> differently than a normal P2P link may be a bad idea. > > >>>>>>>> > > >>>>>>> > > >>>>>>> How about bringing down the neighbor (rather than ignoring) > when > > >>>>>>> a third > > >>>>>>> neighbor on a P2P over LAN sends a new hello? This creates > > >>>>>>> unnecessary > > >>>>>>> flaps, but again having more than 2 routers on a p2p LAN is a > > >>>>>>> misconfig. > > >>>>>>> Atleast, the processing will be similar to a regular p2p > > interface. > > >>>>>>> > > >>>>>> That would be fine and consistent with what most routers do on > > >>>>>> normal P2P links. I think the > > >>>>>> P2P over LAN specific router-ID change processing should be > > >>>>>> removed from the draft. > > >>>>>> > > >>>>>> Thanks, > > >>>>>> Acee > > >>>>>> > > >>>>>>> Thanks, > > >>>>>>> Kalyan. > > >>>>>>> > > >>>>>>> > > >>>>>> > > >>>> > > >> From owner-ospf@PEACH.EASE.LSOFT.COM Wed Feb 22 23:51:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC8S0-0005Mo-Ct for ospf-archive@LISTS.IETF.ORG; Wed, 22 Feb 2006 23:51:36 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC8Rx-0005ru-5U for ospf-archive@LISTS.IETF.ORG; Wed, 22 Feb 2006 23:51:36 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <5.000330EB@wildebeest.ease.lsoft.com>; Wed, 22 Feb 2006 23:51:32 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100157572 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 22 Feb 2006 23:51:31 -0500 Received: from 12.178.35.128 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 22 Feb 2006 23:28:18 -0500 Received: from mailblr1.engineering.netscaler.com ([10.102.1.9]) by mailsj.engineering.netscaler.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Feb 2006 20:24:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reg: DDOS prevention in OSPF Thread-Index: AcY3si9i6aIB3433Rouj8D/2W75/uwAfqGDg X-OriginalArrivalTime: 23 Feb 2006 04:24:00.0528 (UTC) FILETIME=[F87EC100:01C63830] Message-ID: <6D975E431022374F9F7A298A511427B60D5C17@mailblr1.engineering.netscaler.com> Date: Thu, 23 Feb 2006 09:58:02 +0530 Reply-To: Mailing List Sender: Mailing List From: "Nanda Kishore S." Subject: Re: Reg: DDOS prevention in OSPF To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Ofcourse IPSec does the same, but how many are deploying it that way ?? And certainly when we are writing MD5 authentication why not improve it and have it in place for ease of configuration and administration=20 with some improvement for DDOS. =20 -Nanda -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Fred Baker Sent: Wednesday, February 22, 2006 6:45 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Reg: DDOS prevention in OSPF Dumb question: why no use IPsec, which (unless I am mistaken) =20 accomplishes the same thing? Historically, the reason we built MD5 authentication into OSPF was =20 because IPsec couldn't produce a result to save its soul. This =20 authentication mechanism is basically borrowed more or less directly =20 from the IPsec AH drafts of the time. IPsec produced a result... On Feb 22, 2006, at 1:40 AM, Nanda Kishore S. wrote: > My idea is implementing MD5 authentication at socket level at =20 > greater speeds (DDOS attack's speed) is not feasible or won't give =20 > such performance so, why not have a cascaded authentication =20 > mechanism like (Simple password + MD5) so, that before queuing of =20 > packets we can do simple password at greater efficiency and MD5 for =20 > better security later. From owner-ospf@PEACH.EASE.LSOFT.COM Thu Feb 23 18:52:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCQGC-0001i7-F5 for ospf-archive@LISTS.IETF.ORG; Thu, 23 Feb 2006 18:52:36 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCQGC-00036w-8A for ospf-archive@LISTS.IETF.ORG; Thu, 23 Feb 2006 18:52:36 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <13.000342F3@wildebeest.ease.lsoft.com>; Thu, 23 Feb 2006 18:52:34 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100237783 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 23 Feb 2006 18:52:33 -0500 Received: from 209.119.0.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 23 Feb 2006 18:42:33 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by LIME.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.000C2A2F@LIME.ease.lsoft.com>; Thu, 23 Feb 2006 18:41:24 -0500 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Message-ID: Date: Thu, 23 Feb 2006 18:42:25 -0500 Reply-To: Mailing List Sender: Mailing List From: Sushma Venkatesh Subject: Question about routing table update To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 As per section 13.2 in RFC 2328, receipt of a router or network LSA with = changed contents leads to recalculation of entire routing table. As per section 16 in RFC 2328, the routing table calculation involves: (1)Dijkstra calculation for each attached area considering only the links= between routers and transit networks. (2)Stub networks are incorporated into the area trees by going through th= e router LSA of each reachable router again. (3)All the summary LSAs are examined to calculate inter-area routes. (4) All AS-external LSAs are examined to calculate routes to external destinations. Questions for the group: (1)Clearly, depending on the number of summary and ASE LSAs, the routing = table update may take much longer than simple dijkstra calculations of all atta= ched areas. There exist some studies (Shaikh 2001, Basu 2001) that attribute t= imes of the order of tens of milliseconds to dijkstra calculations based on th= e number of routers in the area. Are you aware of any studies that experimentally measure or model the time spent in doing routing table upd= ates? Are their any studies or rules of thumb to estimate the time spent examin= ing the summary and ASE LSAs? Is it reasonable to assume that the time spent examining the summary/ASE LSAs is linear in terms of the number of such L= SAs? (2)Is it reasonable to assume that modern routers perform the complete ro= uting table update following the receipt of a changed router/network LSA as ONE= activity WITHOUT PREEMPTION? Or are they likely to split the complete rou= ting table update process in multiple parts and perform them as time permits? From owner-ospf@PEACH.EASE.LSOFT.COM Thu Feb 23 22:40:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCToG-0003PJ-Vg for ospf-archive@LISTS.IETF.ORG; Thu, 23 Feb 2006 22:40:00 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCToG-0001oH-GF for ospf-archive@LISTS.IETF.ORG; Thu, 23 Feb 2006 22:40:00 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <15.000345E9@wildebeest.ease.lsoft.com>; Thu, 23 Feb 2006 22:39:59 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100248233 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 23 Feb 2006 22:39:58 -0500 Received: from 171.71.176.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 23 Feb 2006 22:39:58 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 23 Feb 2006 19:39:58 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k1O3dvVd015241 for ; Thu, 23 Feb 2006 19:39:58 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 23 Feb 2006 22:39:57 -0500 Received: from [10.82.216.60] ([10.82.216.60]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 23 Feb 2006 22:39:57 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) 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 X-OriginalArrivalTime: 24 Feb 2006 03:39:57.0188 (UTC) FILETIME=[FB5AD440:01C638F3] Message-ID: <43FE800B.5010505@cisco.com> Date: Thu, 23 Feb 2006 22:39:55 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Detecting router id change in p2p-over-lan connection To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 439b8e44c906b144bce6744ebb966e60 Hi Sunil, Sunil Patro wrote: >Hi Everyone, > >Thanks for all the feedback. > >Can I safely assume that the final behavior is what Acee's recommended >paragraph says below? > > I believe that is the consensus and barring a very compelling argument otherwise, this will be the final text. Thanks, Acee >"If the system ID or the router ID in an incoming hello packet >doesn't match the the system ID or router ID for an established >adjacency >over a p2p-over-lan circuit, the packet MUST be discarded. Futhermore, >if OSPF hello suppression as described in [DEMAND] is active for the >adjacency, it MUST be terminated and renegotiated." > >Thanks, >Sunil > > > >>-----Original Message----- >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >> >> >Naiming > > >>Shen >>Sent: Tuesday, February 21, 2006 9:43 PM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Re: Detecting router id change in p2p-over-lan connection >> >>Hello Acee, >> >>Your suggested paragraph looks fine with me. >> >>Even though this sentence assumes there is really a >>router-id change from a DC neighbor. A router probably >>should send a 'neighbor probing' [RFC 3883], if no >>response, then reset the adjacency and start >>the renegotiation; otherwise it should still ignore >>the new join on the p2p-over-lan link. >> >>But I would consider router-id change over a demand >>circuit over a p2p-over-lan on OSPF link a >>'misconfiguration';-) so it does not matter too much. >>Your version is fine. >> >>thanks. >>- Naiming >> >>Acee Lindem said the following on 02/21/2006 02:47 PM: >> >> >>>Hello Naiming, >>> >>>Naiming Shen wrote: >>> >>> >>> >>>>Acee Lindem said the following on 02/21/2006 06:04 AM: >>>> >>>> >>>> >>>>>Naiming Shen wrote: >>>>> >>>>> >>>>> >>>>>>Agree with Dave's argument, and this is the same idea as in the >>>>>>current draft of p2p-over-lan (section 4.5): >>>>>> >>>>>> ... If the system ID or the >>>>>> router ID of incoming hello packet does not match the system >>>>>> >>>>>> >ID or > > >>>>>> the router ID of already established adjacency over this >>>>>>p2p-over-lan >>>>>> circuit, it MUST discard the packet. The implementation should >>>>>> >>>>>> >>offer >> >> >>>>>> logging and debugging information of the above events. >>>>>> >>>>>>Do we need to change anything here? >>>>>> >>>>>> >>>>> >>>>> >>>>>Hi Naiming, >>>>> >>>>>Given that this situation can happen in the case of >>>>> >>>>> >misconfiguration > > >>or >> >> >>>>>router-ID change, I wouldn't optimize for the former. Especially >>>>>considering Kalyan's point that if hello's are suppressed, the >>>>>router-id change >>>>>will either not be recognized or require additional logic. I'd >>>>> >>>>> >vote > > >>>>>to either >>>>>leave it unspecified (consistent with RFC 2328's omission of >>>>> >>>>> >router-id > > >>>>>change P2P link handling) or discard the old neighbor and bring up >>>>>an adjacency with the new (which is what at least one >>>>> >>>>> >implementation > > >>>>>does >>>>>today). >>>>> >>>>> >>>> >>>>Hello Acee, >>>> >>>>The original idea in the draft was to prevent multiple routers >>>> >>>> >joinning > > >>>>onto the same LAN rather than handing the router-ID change from the >>>>same router. Even through there is a side effect to it. >>>> >>>>For the router-ID change issue. If one is willing to change >>>> >>>> >router-ID > > >>>>or system-ID during normal operation, there are more things broken >>>>and there is nothing wrong to wait until the current adjacent >>>> >>>> >timeout. > > >>>Agreed. >>> >>> >>> >>>>If the hello is suppressed over the link, then the behaviour is not >>>>bounded by this paragraph since it does not say the purpose is to >>>>detect neighbor router-id change. >>>> >>>> >>>I disagree here. It says "MUST discard packet". That sounds pretty >>>bounding to me :^). >>> >>> >>> >>>>Also there is little reason to >>>>suppress a hello over p2p-over-lan links. Thus I don't think >>>>router-id is an issue with this sentence. >>>> >>>> >>>I agree - but there is nothing in this draft or RFC 1793 that >>> >>> >precludes > > >>it. >> >> >>>>Since p2p-over-lan is different from normal p2p circuit that >>>> >>>> >multiple > > >>>>routers can easily join the same LAN unintentionally. If we ignore >>>>the new station to join, then we can prevent the adjacency constant >>>>flapping(this does not happen to normal p2p link), the worst it can >>>>happen is slow to handle router-id change as mentioned above, which >>>>is a non issue. Thus I think it's a good thing to ignore the extra >>>>adjacency joinning. This sentence does not govern the normal p2p >>>> >>>> >link > > >>>>behaviour so the implementation is ok(even prefered) to reset the >>>>existing adjacency on a normal p2p link. Thus I don't think we >>>>should say we must reset the current adjacency for p2p-over-lan. >>>> >>>>My preference of this sentence in the draft is with this order: >>>> >>>> - leave it as is >>>> - change the MUST to SHOULD >>>> - remove the router-id related sentence >>>> >>>> >>>How about leave it "almost" as is: >>> >>> If the system ID or the router ID in an incoming hello packet >>> >>> >>doesn't >> >> >>> match the the system ID or router ID for an established >>> >>> >adjacency > > >>over >> >> >>> a p2p-over-lan circuit, the packet MUST be discarded. >>> >>> >Futhermore, > > >>> if OSPF hello suppression as described in [DEMAND] is active for >>> >>> >the > > >>> adjacency, it MUST be terminated and renegotiated. >>> >>>[DEMAND] Moy, J., "Extending OSPF to Support Demand Circuits", >>> RFC 1793, April 1995. >>> >>>Thanks, >>>Acee >>> >>> >>> >>>>thanks. >>>>- Naiming >>>> >>>> >>>> >>>>>Thanks, >>>>>Acee >>>>> >>>>>Thanks, >>>>>Acee >>>>> >>>>> >>>>> >>>>>>thanks. >>>>>>- Naiming >>>>>> >>>>>>Dave Katz said the following on 02/20/2006 08:53 PM: >>>>>> >>>>>> >>>>>> >>>>>>>RFC2328 is silent on what to do if you see a different router ID >>>>>>> >>>>>>> >on > > >>>>>>>a P2P link; if you take it literally, you will create two >>>>>>>adjacencies (temporarily), advertise both in your router LSA, >>>>>>> >>>>>>> >and > > >>>>>>>your network will most likely black hole traffic until one of >>>>>>> >>>>>>> >them > > >>>>>>>times out. >>>>>>> >>>>>>>On real P2P links, this will suffice (if you don't mind a >>>>>>> >>>>>>> >network > > >>>>>>>outage for the dead time of the old adjacency) and things will >>>>>>>eventually stabilize since it is "impossible" (cough) two get >>>>>>> >>>>>>> >two > > >>>>>>>neighbors in 2Way. The fact that it is underspecified doesn't >>>>>>>matter that much. >>>>>>> >>>>>>>In the P2P-over-LAN case, there needs to be a mechanism to try >>>>>>> >>>>>>> >to > > >>>>>>>do something useful if there turn out to be more than two >>>>>>> >>>>>>> >routers > > >>>>>>>on the link. I don't think it's reasonable to say "gee it's >>>>>>>misconfigured, we don't care what happens to the network." >>>>>>> >>>>>>> >>>>>>>It seems to me that there are two possible cases, namely, use >>>>>>> >>>>>>> >the > > >>>>>>>old adjacency until it times out (effectively ignoring the >>>>>>> >>>>>>> >hellos > > >>>>>>>from the new guy) or to form an adjacency with the new guy (and >>>>>>>blow away or otherwise ignore the old guy.) >>>>>>> >>>>>>>The first case has the advantage of stability and >>>>>>> >>>>>>> >simplicity--the > > >>>>>>>third router that shows up for the party will be ignored by both >>>>>>>parties. There is a potential for a circle of one-way >>>>>>> >>>>>>> >adjacencies > > >>>>>>>to stabilize, but this will still be stable (there won't be a >>>>>>>usable adjacency across the subnetwork.) >>>>>>> >>>>>>>The second case has the advantage that it adapts more quickly >>>>>>> >>>>>>> >when > > >>>>>>>something changes. Some implementations already do this for the >>>>>>>pure P2P case. However, it is destabilizing in the >>>>>>>misconfiguration case, as the router will flap its router LSA >>>>>>> >>>>>>> >each > > >>>>>>>time another Hello is received. Probably the only reasonable >>>>>>> >>>>>>> >way > > >>>>>>>out would be to detect the flap and then choose one neighbor >>>>>>> >>>>>>> >and > > >>>>>>>stick to it, ignoring the other (which degenerates into the >>>>>>> >>>>>>> >first > > >>>>>>>case.) >>>>>>> >>>>>>>Given all of this, I'd propose that the right thing to do is the >>>>>>>first case, and suffer through the dead time (or use BFD and >>>>>>>suffer through the detection time.) >>>>>>> >>>>>>>(A third possible case would be to actually bring up the >>>>>>> >>>>>>> >adjacency > > >>>>>>>and end up running full-mesh multipoint, which would probably >>>>>>> >>>>>>> >even > > >>>>>>>work, but would be butt ugly.) >>>>>>> >>>>>>>--Dave >>>>>>> >>>>>>> >>>>>>>On Feb 20, 2006, at 3:25 PM, Acee Lindem wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Kalyan Bade wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>Acee, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>This might not work if the interface is defined as demand >>>>>>>>>>> >>>>>>>>>>> >>circuit. >> >> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>Good point - We're in the process of discussing whether this >>>>>>>>>>behavior >>>>>>>>>>should be in the >>>>>>>>>>draft. Possibly, handling detection of a router-id change on >>>>>>>>>> >>>>>>>>>> >a > > >>P2P >> >> >>>>>>>>>over >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>LAN link >>>>>>>>>>differently than a normal P2P link may be a bad idea. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>How about bringing down the neighbor (rather than ignoring) >>>>>>>>> >>>>>>>>> >when > > >>>>>>>>>a third >>>>>>>>>neighbor on a P2P over LAN sends a new hello? This creates >>>>>>>>>unnecessary >>>>>>>>>flaps, but again having more than 2 routers on a p2p LAN is a >>>>>>>>>misconfig. >>>>>>>>>Atleast, the processing will be similar to a regular p2p >>>>>>>>> >>>>>>>>> >>interface. >> >> >>>>>>>>That would be fine and consistent with what most routers do on >>>>>>>>normal P2P links. I think the >>>>>>>>P2P over LAN specific router-ID change processing should be >>>>>>>>removed from the draft. >>>>>>>> >>>>>>>>Thanks, >>>>>>>>Acee >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>Thanks, >>>>>>>>>Kalyan. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Feb 23 23:31:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCUc3-0007At-BN for ospf-archive@LISTS.IETF.ORG; Thu, 23 Feb 2006 23:31:27 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCUc2-0003OR-St for ospf-archive@LISTS.IETF.ORG; Thu, 23 Feb 2006 23:31:27 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <15.000346BC@wildebeest.ease.lsoft.com>; Thu, 23 Feb 2006 23:31:26 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100252147 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 23 Feb 2006 23:31:25 -0500 Received: from 207.69.195.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 23 Feb 2006 23:31:25 -0500 Received: from h-68-164-155-88.snvacaid.dynamic.covad.net ([68.164.155.88] helo=earthlink.net) by pop-knobcone.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1FCUc1-0002XK-00 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 23 Feb 2006 23:31:25 -0500 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <43FE800B.5010505@cisco.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43FE8B94.3605713F@earthlink.net> Date: Thu, 23 Feb 2006 20:29:08 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Detecting router id change in p2p-over-lan connection To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: 3d48d865303330c98a6e90d450cf2ff2 Acee, What does "MUST be terminated and renegotiated." mean? Does "terminated" mean to move into the DOWN nbr state OR IS IT the Init state????? Will a empty hello get us there? Doesn't it just get us to the Init state? Is that what is intended? Mitchell Erblich --------------------- Acee Lindem wrote: > > Hi Sunil, > > Sunil Patro wrote: > > >Hi Everyone, > > > >Thanks for all the feedback. > > > >Can I safely assume that the final behavior is what Acee's recommended > >paragraph says below? > > > > > I believe that is the consensus and barring a very compelling argument > otherwise, this will be > the final text. > > Thanks, > Acee > > >"If the system ID or the router ID in an incoming hello packet > >doesn't match the the system ID or router ID for an established > >adjacency > >over a p2p-over-lan circuit, the packet MUST be discarded. Futhermore, > >if OSPF hello suppression as described in [DEMAND] is active for the > >adjacency, it MUST be terminated and renegotiated." > > > >Thanks, > >Sunil > > > > > > > >>-----Original Message----- > >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > >> > >> > >Naiming > > > > > >>Shen > >>Sent: Tuesday, February 21, 2006 9:43 PM > >>To: OSPF@PEACH.EASE.LSOFT.COM > >>Subject: Re: Detecting router id change in p2p-over-lan connection > >> > >>Hello Acee, > >> > >>Your suggested paragraph looks fine with me. > >> > >>Even though this sentence assumes there is really a > >>router-id change from a DC neighbor. A router probably > >>should send a 'neighbor probing' [RFC 3883], if no > >>response, then reset the adjacency and start > >>the renegotiation; otherwise it should still ignore > >>the new join on the p2p-over-lan link. > >> > >>But I would consider router-id change over a demand > >>circuit over a p2p-over-lan on OSPF link a > >>'misconfiguration';-) so it does not matter too much. > >>Your version is fine. > >> > >>thanks. > >>- Naiming > >> > >>Acee Lindem said the following on 02/21/2006 02:47 PM: > >> > >> > >>>Hello Naiming, > >>> > >>>Naiming Shen wrote: > >>> > >>> > >>> > >>>>Acee Lindem said the following on 02/21/2006 06:04 AM: > >>>> > >>>> > >>>> > >>>>>Naiming Shen wrote: > >>>>> > >>>>> > >>>>> > >>>>>>Agree with Dave's argument, and this is the same idea as in the > >>>>>>current draft of p2p-over-lan (section 4.5): > >>>>>> > >>>>>> ... If the system ID or the > >>>>>> router ID of incoming hello packet does not match the system > >>>>>> > >>>>>> > >ID or > > > > > >>>>>> the router ID of already established adjacency over this > >>>>>>p2p-over-lan > >>>>>> circuit, it MUST discard the packet. The implementation should > >>>>>> > >>>>>> > >>offer > >> > >> > >>>>>> logging and debugging information of the above events. > >>>>>> > >>>>>>Do we need to change anything here? > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>>Hi Naiming, > >>>>> > >>>>>Given that this situation can happen in the case of > >>>>> > >>>>> > >misconfiguration > > > > > >>or > >> > >> > >>>>>router-ID change, I wouldn't optimize for the former. Especially > >>>>>considering Kalyan's point that if hello's are suppressed, the > >>>>>router-id change > >>>>>will either not be recognized or require additional logic. I'd > >>>>> > >>>>> > >vote > > > > > >>>>>to either > >>>>>leave it unspecified (consistent with RFC 2328's omission of > >>>>> > >>>>> > >router-id > > > > > >>>>>change P2P link handling) or discard the old neighbor and bring up > >>>>>an adjacency with the new (which is what at least one > >>>>> > >>>>> > >implementation > > > > > >>>>>does > >>>>>today). > >>>>> > >>>>> > >>>> > >>>>Hello Acee, > >>>> > >>>>The original idea in the draft was to prevent multiple routers > >>>> > >>>> > >joinning > > > > > >>>>onto the same LAN rather than handing the router-ID change from the > >>>>same router. Even through there is a side effect to it. > >>>> > >>>>For the router-ID change issue. If one is willing to change > >>>> > >>>> > >router-ID > > > > > >>>>or system-ID during normal operation, there are more things broken > >>>>and there is nothing wrong to wait until the current adjacent > >>>> > >>>> > >timeout. > > > > > >>>Agreed. > >>> > >>> > >>> > >>>>If the hello is suppressed over the link, then the behaviour is not > >>>>bounded by this paragraph since it does not say the purpose is to > >>>>detect neighbor router-id change. > >>>> > >>>> > >>>I disagree here. It says "MUST discard packet". That sounds pretty > >>>bounding to me :^). > >>> > >>> > >>> > >>>>Also there is little reason to > >>>>suppress a hello over p2p-over-lan links. Thus I don't think > >>>>router-id is an issue with this sentence. > >>>> > >>>> > >>>I agree - but there is nothing in this draft or RFC 1793 that > >>> > >>> > >precludes > > > > > >>it. > >> > >> > >>>>Since p2p-over-lan is different from normal p2p circuit that > >>>> > >>>> > >multiple > > > > > >>>>routers can easily join the same LAN unintentionally. If we ignore > >>>>the new station to join, then we can prevent the adjacency constant > >>>>flapping(this does not happen to normal p2p link), the worst it can > >>>>happen is slow to handle router-id change as mentioned above, which > >>>>is a non issue. Thus I think it's a good thing to ignore the extra > >>>>adjacency joinning. This sentence does not govern the normal p2p > >>>> > >>>> > >link > > > > > >>>>behaviour so the implementation is ok(even prefered) to reset the > >>>>existing adjacency on a normal p2p link. Thus I don't think we > >>>>should say we must reset the current adjacency for p2p-over-lan. > >>>> > >>>>My preference of this sentence in the draft is with this order: > >>>> > >>>> - leave it as is > >>>> - change the MUST to SHOULD > >>>> - remove the router-id related sentence > >>>> > >>>> > >>>How about leave it "almost" as is: > >>> > >>> If the system ID or the router ID in an incoming hello packet > >>> > >>> > >>doesn't > >> > >> > >>> match the the system ID or router ID for an established > >>> > >>> > >adjacency > > > > > >>over > >> > >> > >>> a p2p-over-lan circuit, the packet MUST be discarded. > >>> > >>> > >Futhermore, > > > > > >>> if OSPF hello suppression as described in [DEMAND] is active for > >>> > >>> > >the > > > > > >>> adjacency, it MUST be terminated and renegotiated. > >>> > >>>[DEMAND] Moy, J., "Extending OSPF to Support Demand Circuits", > >>> RFC 1793, April 1995. > >>> > >>>Thanks, > >>>Acee > >>> > >>> > >>> > >>>>thanks. > >>>>- Naiming > >>>> > >>>> > >>>> > >>>>>Thanks, > >>>>>Acee > >>>>> > >>>>>Thanks, > >>>>>Acee > >>>>> > >>>>> > >>>>> > >>>>>>thanks. > >>>>>>- Naiming > >>>>>> > >>>>>>Dave Katz said the following on 02/20/2006 08:53 PM: > >>>>>> > >>>>>> > >>>>>> > >>>>>>>RFC2328 is silent on what to do if you see a different router ID > >>>>>>> > >>>>>>> > >on > > > > > >>>>>>>a P2P link; if you take it literally, you will create two > >>>>>>>adjacencies (temporarily), advertise both in your router LSA, > >>>>>>> > >>>>>>> > >and > > > > > >>>>>>>your network will most likely black hole traffic until one of > >>>>>>> > >>>>>>> > >them > > > > > >>>>>>>times out. > >>>>>>> > >>>>>>>On real P2P links, this will suffice (if you don't mind a > >>>>>>> > >>>>>>> > >network > > > > > >>>>>>>outage for the dead time of the old adjacency) and things will > >>>>>>>eventually stabilize since it is "impossible" (cough) two get > >>>>>>> > >>>>>>> > >two > > > > > >>>>>>>neighbors in 2Way. The fact that it is underspecified doesn't > >>>>>>>matter that much. > >>>>>>> > >>>>>>>In the P2P-over-LAN case, there needs to be a mechanism to try > >>>>>>> > >>>>>>> > >to > > > > > >>>>>>>do something useful if there turn out to be more than two > >>>>>>> > >>>>>>> > >routers > > > > > >>>>>>>on the link. I don't think it's reasonable to say "gee it's > >>>>>>>misconfigured, we don't care what happens to the network." > >>>>>>> > >>>>>>> > >>>>>>>It seems to me that there are two possible cases, namely, use > >>>>>>> > >>>>>>> > >the > > > > > >>>>>>>old adjacency until it times out (effectively ignoring the > >>>>>>> > >>>>>>> > >hellos > > > > > >>>>>>>from the new guy) or to form an adjacency with the new guy (and > >>>>>>>blow away or otherwise ignore the old guy.) > >>>>>>> > >>>>>>>The first case has the advantage of stability and > >>>>>>> > >>>>>>> > >simplicity--the > > > > > >>>>>>>third router that shows up for the party will be ignored by both > >>>>>>>parties. There is a potential for a circle of one-way > >>>>>>> > >>>>>>> > >adjacencies > > > > > >>>>>>>to stabilize, but this will still be stable (there won't be a > >>>>>>>usable adjacency across the subnetwork.) > >>>>>>> > >>>>>>>The second case has the advantage that it adapts more quickly > >>>>>>> > >>>>>>> > >when > > > > > >>>>>>>something changes. Some implementations already do this for the > >>>>>>>pure P2P case. However, it is destabilizing in the > >>>>>>>misconfiguration case, as the router will flap its router LSA > >>>>>>> > >>>>>>> > >each > > > > > >>>>>>>time another Hello is received. Probably the only reasonable > >>>>>>> > >>>>>>> > >way > > > > > >>>>>>>out would be to detect the flap and then choose one neighbor > >>>>>>> > >>>>>>> > >and > > > > > >>>>>>>stick to it, ignoring the other (which degenerates into the > >>>>>>> > >>>>>>> > >first > > > > > >>>>>>>case.) > >>>>>>> > >>>>>>>Given all of this, I'd propose that the right thing to do is the > >>>>>>>first case, and suffer through the dead time (or use BFD and > >>>>>>>suffer through the detection time.) > >>>>>>> > >>>>>>>(A third possible case would be to actually bring up the > >>>>>>> > >>>>>>> > >adjacency > > > > > >>>>>>>and end up running full-mesh multipoint, which would probably > >>>>>>> > >>>>>>> > >even > > > > > >>>>>>>work, but would be butt ugly.) > >>>>>>> > >>>>>>>--Dave > >>>>>>> > >>>>>>> > >>>>>>>On Feb 20, 2006, at 3:25 PM, Acee Lindem wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>Kalyan Bade wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>Acee, > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>>This might not work if the interface is defined as demand > >>>>>>>>>>> > >>>>>>>>>>> > >>circuit. > >> > >> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>Good point - We're in the process of discussing whether this > >>>>>>>>>>behavior > >>>>>>>>>>should be in the > >>>>>>>>>>draft. Possibly, handling detection of a router-id change on > >>>>>>>>>> > >>>>>>>>>> > >a > > > > > >>P2P > >> > >> > >>>>>>>>>over > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>LAN link > >>>>>>>>>>differently than a normal P2P link may be a bad idea. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>How about bringing down the neighbor (rather than ignoring) > >>>>>>>>> > >>>>>>>>> > >when > > > > > >>>>>>>>>a third > >>>>>>>>>neighbor on a P2P over LAN sends a new hello? This creates > >>>>>>>>>unnecessary > >>>>>>>>>flaps, but again having more than 2 routers on a p2p LAN is a > >>>>>>>>>misconfig. > >>>>>>>>>Atleast, the processing will be similar to a regular p2p > >>>>>>>>> > >>>>>>>>> > >>interface. > >> > >> > >>>>>>>>That would be fine and consistent with what most routers do on > >>>>>>>>normal P2P links. I think the > >>>>>>>>P2P over LAN specific router-ID change processing should be > >>>>>>>>removed from the draft. > >>>>>>>> > >>>>>>>>Thanks, > >>>>>>>>Acee > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>Thanks, > >>>>>>>>>Kalyan. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 24 00:27:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCVU3-0003Bd-8Y for ospf-archive@LISTS.IETF.ORG; Fri, 24 Feb 2006 00:27:15 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCVU2-0005Z6-Rx for ospf-archive@LISTS.IETF.ORG; Fri, 24 Feb 2006 00:27:15 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <6.000348B2@wildebeest.ease.lsoft.com>; Fri, 24 Feb 2006 0:27:13 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100255462 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 24 Feb 2006 00:27:14 -0500 Received: from 12.178.35.128 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 24 Feb 2006 00:27:13 -0500 Received: from mailblr1.engineering.netscaler.com ([10.102.1.9]) by mailsj.engineering.netscaler.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 23 Feb 2006 21:23:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Detecting router id change in p2p-over-lan connection Thread-Index: AcY3cufUyCwC4LWXRdKNKhxXb0QEcQAhuZ+wAEIdaVA= X-OriginalArrivalTime: 24 Feb 2006 05:23:03.0487 (UTC) FILETIME=[62AD24F0:01C63902] Message-ID: <6D975E431022374F9F7A298A511427B6193701@mailblr1.engineering.netscaler.com> Date: Fri, 24 Feb 2006 10:57:04 +0530 Reply-To: Mailing List Sender: Mailing List From: Nitin Kakkar Subject: Re: Detecting router id change in p2p-over-lan connection To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: e16ce0269ccb2f59707d16700199d13b Can someone please explain me the rational behind terminating adjacency in " if OSPF hello suppression as described in [DEMAND] is active for the adjacency, it MUST be terminated and renegotiated" Why do we want a stray hello to terminate existing adjacency?=20 Thanks & Regards Nitin -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Sunil Patro Sent: Thursday, February 23, 2006 3:24 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Detecting router id change in p2p-over-lan connection Hi Everyone, Thanks for all the feedback.=20 Can I safely assume that the final behavior is what Acee's recommended paragraph says below?=20 "If the system ID or the router ID in an incoming hello packet doesn't match the the system ID or router ID for an established adjacency over a p2p-over-lan circuit, the packet MUST be discarded. Futhermore, if OSPF hello suppression as described in [DEMAND] is active for the adjacency, it MUST be terminated and renegotiated." Thanks, Sunil > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Naiming > Shen > Sent: Tuesday, February 21, 2006 9:43 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: Detecting router id change in p2p-over-lan connection >=20 > Hello Acee, >=20 > Your suggested paragraph looks fine with me. >=20 > Even though this sentence assumes there is really a > router-id change from a DC neighbor. A router probably > should send a 'neighbor probing' [RFC 3883], if no > response, then reset the adjacency and start > the renegotiation; otherwise it should still ignore > the new join on the p2p-over-lan link. >=20 > But I would consider router-id change over a demand > circuit over a p2p-over-lan on OSPF link a > 'misconfiguration';-) so it does not matter too much. > Your version is fine. >=20 > thanks. > - Naiming >=20 > Acee Lindem said the following on 02/21/2006 02:47 PM: > > Hello Naiming, > > > > Naiming Shen wrote: > > > >> Acee Lindem said the following on 02/21/2006 06:04 AM: > >> > >>> Naiming Shen wrote: > >>> > >>>> Agree with Dave's argument, and this is the same idea as in the > >>>> current draft of p2p-over-lan (section 4.5): > >>>> > >>>> ... If the system ID or the > >>>> router ID of incoming hello packet does not match the system ID or > >>>> the router ID of already established adjacency over this > >>>> p2p-over-lan > >>>> circuit, it MUST discard the packet. The implementation should > offer > >>>> logging and debugging information of the above events. > >>>> > >>>> Do we need to change anything here? > >>> > >>> > >>> > >>> > >>> Hi Naiming, > >>> > >>> Given that this situation can happen in the case of misconfiguration > or > >>> router-ID change, I wouldn't optimize for the former. Especially > >>> considering Kalyan's point that if hello's are suppressed, the > >>> router-id change > >>> will either not be recognized or require additional logic. I'd vote > >>> to either > >>> leave it unspecified (consistent with RFC 2328's omission of router-id > >>> change P2P link handling) or discard the old neighbor and bring up > >>> an adjacency with the new (which is what at least one implementation > >>> does > >>> today). > >> > >> > >> > >> Hello Acee, > >> > >> The original idea in the draft was to prevent multiple routers joinning > >> onto the same LAN rather than handing the router-ID change from the > >> same router. Even through there is a side effect to it. > >> > >> For the router-ID change issue. If one is willing to change router-ID > >> or system-ID during normal operation, there are more things broken > >> and there is nothing wrong to wait until the current adjacent timeout. > > > > > > Agreed. > > > >> If the hello is suppressed over the link, then the behaviour is not > >> bounded by this paragraph since it does not say the purpose is to > >> detect neighbor router-id change. > > > > > > I disagree here. It says "MUST discard packet". That sounds pretty > > bounding to me :^). > > > >> Also there is little reason to > >> suppress a hello over p2p-over-lan links. Thus I don't think > >> router-id is an issue with this sentence. > > > > > > I agree - but there is nothing in this draft or RFC 1793 that precludes > it. > > > >> > >> Since p2p-over-lan is different from normal p2p circuit that multiple > >> routers can easily join the same LAN unintentionally. If we ignore > >> the new station to join, then we can prevent the adjacency constant > >> flapping(this does not happen to normal p2p link), the worst it can > >> happen is slow to handle router-id change as mentioned above, which > >> is a non issue. Thus I think it's a good thing to ignore the extra > >> adjacency joinning. This sentence does not govern the normal p2p link > >> behaviour so the implementation is ok(even prefered) to reset the > >> existing adjacency on a normal p2p link. Thus I don't think we > >> should say we must reset the current adjacency for p2p-over-lan. > >> > >> My preference of this sentence in the draft is with this order: > >> > >> - leave it as is > >> - change the MUST to SHOULD > >> - remove the router-id related sentence > > > > > > How about leave it "almost" as is: > > > > If the system ID or the router ID in an incoming hello packet > doesn't > > match the the system ID or router ID for an established adjacency > over > > a p2p-over-lan circuit, the packet MUST be discarded. Futhermore, > > if OSPF hello suppression as described in [DEMAND] is active for the > > adjacency, it MUST be terminated and renegotiated. > > > > [DEMAND] Moy, J., "Extending OSPF to Support Demand Circuits", > > RFC 1793, April 1995. > > > > Thanks, > > Acee > > > >> thanks. > >> - Naiming > >> > >>> > >>> Thanks, > >>> Acee > >>> > >>> Thanks, > >>> Acee > >>> > >>>> > >>>> thanks. > >>>> - Naiming > >>>> > >>>> Dave Katz said the following on 02/20/2006 08:53 PM: > >>>> > >>>>> RFC2328 is silent on what to do if you see a different router ID on > >>>>> a P2P link; if you take it literally, you will create two > >>>>> adjacencies (temporarily), advertise both in your router LSA, and > >>>>> your network will most likely black hole traffic until one of them > >>>>> times out. > >>>>> > >>>>> On real P2P links, this will suffice (if you don't mind a network > >>>>> outage for the dead time of the old adjacency) and things will > >>>>> eventually stabilize since it is "impossible" (cough) two get two > >>>>> neighbors in 2Way. The fact that it is underspecified doesn't > >>>>> matter that much. > >>>>> > >>>>> In the P2P-over-LAN case, there needs to be a mechanism to try to > >>>>> do something useful if there turn out to be more than two routers > >>>>> on the link. I don't think it's reasonable to say "gee it's > >>>>> misconfigured, we don't care what happens to the network." > >>>>> > >>>>> > >>>>> It seems to me that there are two possible cases, namely, use the > >>>>> old adjacency until it times out (effectively ignoring the hellos > >>>>> from the new guy) or to form an adjacency with the new guy (and > >>>>> blow away or otherwise ignore the old guy.) > >>>>> > >>>>> The first case has the advantage of stability and simplicity--the > >>>>> third router that shows up for the party will be ignored by both > >>>>> parties. There is a potential for a circle of one-way adjacencies > >>>>> to stabilize, but this will still be stable (there won't be a > >>>>> usable adjacency across the subnetwork.) > >>>>> > >>>>> The second case has the advantage that it adapts more quickly when > >>>>> something changes. Some implementations already do this for the > >>>>> pure P2P case. However, it is destabilizing in the > >>>>> misconfiguration case, as the router will flap its router LSA each > >>>>> time another Hello is received. Probably the only reasonable way > >>>>> out would be to detect the flap and then choose one neighbor and > >>>>> stick to it, ignoring the other (which degenerates into the first > >>>>> case.) > >>>>> > >>>>> Given all of this, I'd propose that the right thing to do is the > >>>>> first case, and suffer through the dead time (or use BFD and > >>>>> suffer through the detection time.) > >>>>> > >>>>> (A third possible case would be to actually bring up the adjacency > >>>>> and end up running full-mesh multipoint, which would probably even > >>>>> work, but would be butt ugly.) > >>>>> > >>>>> --Dave > >>>>> > >>>>> > >>>>> On Feb 20, 2006, at 3:25 PM, Acee Lindem wrote: > >>>>> > >>>>>> Kalyan Bade wrote: > >>>>>> > >>>>>>> Acee, > >>>>>>> > >>>>>>> > >>>>>>>>> This might not work if the interface is defined as demand > circuit. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> Good point - We're in the process of discussing whether this > >>>>>>>> behavior > >>>>>>>> should be in the > >>>>>>>> draft. Possibly, handling detection of a router-id change on a > P2P > >>>>>>>> > >>>>>>> over > >>>>>>> > >>>>>>>> LAN link > >>>>>>>> differently than a normal P2P link may be a bad idea. > >>>>>>>> > >>>>>>> > >>>>>>> How about bringing down the neighbor (rather than ignoring) when > >>>>>>> a third > >>>>>>> neighbor on a P2P over LAN sends a new hello? This creates > >>>>>>> unnecessary > >>>>>>> flaps, but again having more than 2 routers on a p2p LAN is a > >>>>>>> misconfig. > >>>>>>> Atleast, the processing will be similar to a regular p2p > interface. > >>>>>>> > >>>>>> That would be fine and consistent with what most routers do on > >>>>>> normal P2P links. I think the > >>>>>> P2P over LAN specific router-ID change processing should be > >>>>>> removed from the draft. > >>>>>> > >>>>>> Thanks, > >>>>>> Acee > >>>>>> > >>>>>>> Thanks, > >>>>>>> Kalyan. > >>>>>>> > >>>>>>> > >>>>>> > >>>> > >> From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 24 05:05:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCZph-0000Z7-Lf for ospf-archive@LISTS.IETF.ORG; Fri, 24 Feb 2006 05:05:53 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCZph-0005Ar-E5 for ospf-archive@LISTS.IETF.ORG; Fri, 24 Feb 2006 05:05:53 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <1.00034CEE@wildebeest.ease.lsoft.com>; Fri, 24 Feb 2006 5:05:52 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100269956 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 24 Feb 2006 05:05:52 -0500 Received: from 57.66.76.5 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 24 Feb 2006 05:05:52 -0500 Received: from huawei.com ([172.24.2.9]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV600MJSQWXFY@lhrga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 24 Feb 2006 09:41:22 +0000 (GMT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV600IWWRY4Z3@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 24 Feb 2006 18:03:40 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IV600DUSRY4N3@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 24 Feb 2006 18:03:40 +0800 (CST) Received: from k49110 ([10.111.12.97]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IV600M73S73GA@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 24 Feb 2006 18:09:04 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <43F63D76.4030009@cisco.com> <000b01c635cb$cddcca30$610c6f0a@china.huawei.com> <43F9DD10.8040305@cisco.com> <001601c636e4$5ea03980$610c6f0a@china.huawei.com> <43FCDA9B.9050307@cisco.com> Message-ID: <000701c63928$9908e590$610c6f0a@china.huawei.com> Date: Fri, 24 Feb 2006 17:56:35 +0800 Reply-To: Mailing List Sender: Mailing List From: Zengjie Kou Subject: Re: draft-kou-ospf-immediately-replying-hello-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Hi, Acee The empty hello mechanism that you refered is adopted by most OSPF implementations indeed when an interface first comes up. I agree this. However, when an normal interface whose state is up goes down then up, immediate hello is effective by avoiding helloInterval or backupSeen. Thanks, Zengjie ----- Original Message ----- From: "Acee Lindem" To: Sent: Thursday, February 23, 2006 5:41 AM Subject: Re: draft-kou-ospf-immediately-replying-hello-00.txt > Zengjie Kou wrote: > >>Hi, Acee, >> You are right, immediate hello does not provide the mechanism of detecting link down fast. But, immediate hello improve to discover neighbors when interface goes down then up. In practice, the requirement is needed. >> >> > Hi Zengjie, > > Speaking strictly in terms of state machines, it seems the interface > would lose it's DR/BDR state > when it goes down (and cannot send a hello). Wouldn't this scenario be > better handled > by the empty hello many OSPF implementations send when an interface > first comes up? > > Thanks, > Acee > >>Thanks, >>Zengjie >> >>----- Original Message ----- >>From: "Acee Lindem" >>To: >>Sent: Monday, February 20, 2006 11:15 PM >>Subject: Re: draft-kou-ospf-immediately-replying-hello-00.txt >> >> >> >> >>>Hi Zengjie, >>> >>>Zengjie Kou wrote: >>> >>> >>> >>>>Hi,Acee, >>>> If a router interface whose role is changed(e.g.DR goes down), the router will notify all routers about the change by immediate hello. >>>> >>>> >>>> >>>> >>>This is only when the DR/BDR knows that it is going down or the case >>>where the router >>>priority is set to 0. >>> >>>For a router becoming DR/BDR, all the routers should elect the same DR/BDR >>>so I don't see how it helps. >>> >>>Thanks, >>>Acee >>> >>> >>> >>>>After all router get the change, election will be reprocessed. In contrast to normal hello, immediate hello avoid the backupSeen. >>>>Namely, improving convergence. >>>> >>>>Thanks a lot, >>>>Zengjie >>>> >>>>----- Original Message ----- >>>>From: "Acee Lindem" >>>>To: >>>>Sent: Saturday, February 18, 2006 5:17 AM >>>>Subject: draft-kou-ospf-immediately-replying-hello-00.txt >>>> >>>> >>>> >>>> >>>> >>>> >>>>>Hi Zengjie, >>>>> >>>>>Under what situations does having the router who changed to/from >>>>>DR/BDR improve convergence (section 6.2)? Since DR/BDR election >>>>>is a distributed algorithm dependent on the calculating routers state, it >>>>>seems this won't help in all that many cases. >>>>> >>>>>Thanks, >>>>>Acee >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >> >> >> From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 24 08:17:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCcoe-0002Mg-RU for ospf-archive@LISTS.IETF.ORG; Fri, 24 Feb 2006 08:17:00 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCcoc-0002Km-AT for ospf-archive@LISTS.IETF.ORG; Fri, 24 Feb 2006 08:17:00 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <10.0003500C@wildebeest.ease.lsoft.com>; Fri, 24 Feb 2006 8:16:57 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100281646 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 24 Feb 2006 08:16:57 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 24 Feb 2006 08:16:57 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 24 Feb 2006 08:16:58 -0500 X-IronPort-AV: i="4.02,143,1139202000"; d="scan'208"; a="83049779:sNHT38279924" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1ODGuqM020925 for ; Fri, 24 Feb 2006 08:16:56 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Feb 2006 08:16:56 -0500 Received: from [10.82.216.60] ([10.82.216.60]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Feb 2006 08:16:56 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <43FE800B.5010505@cisco.com> <43FE8B94.3605713F@earthlink.net> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Feb 2006 13:16:56.0108 (UTC) FILETIME=[95D6CEC0:01C63944] Message-ID: <43FF0747.7010102@cisco.com> Date: Fri, 24 Feb 2006 08:16:55 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Detecting router id change in p2p-over-lan connection To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43FE8B94.3605713F@earthlink.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 54e0221cc855af1be978f9387027a2cf Erblichs wrote: >Acee, > > What does "MUST be terminated and renegotiated." mean? > > Mitchell, If you read the entire sentense rather than cut'n pasting a piece of it, it is clear that hello suppression is what is being terminated. Don't read anything else into this - we're not taking down the adjacency. Thanks, Acee > Does "terminated" mean to move into the DOWN nbr state > OR IS IT the Init state????? > > Will a empty hello get us there? > > Doesn't it just get us to the Init state? > Is that what is intended? > > > Mitchell Erblich > --------------------- > >Acee Lindem wrote: > > >>Hi Sunil, >> >>Sunil Patro wrote: >> >> >> >>>Hi Everyone, >>> >>>Thanks for all the feedback. >>> >>>Can I safely assume that the final behavior is what Acee's recommended >>>paragraph says below? >>> >>> >>> >>> >>I believe that is the consensus and barring a very compelling argument >>otherwise, this will be >>the final text. >> >>Thanks, >>Acee >> >> >> >>>"If the system ID or the router ID in an incoming hello packet >>>doesn't match the the system ID or router ID for an established >>>adjacency >>>over a p2p-over-lan circuit, the packet MUST be discarded. Futhermore, >>>if OSPF hello suppression as described in [DEMAND] is active for the >>>adjacency, it MUST be terminated and renegotiated." >>> >>>Thanks, >>>Sunil >>> >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >>>> >>>> >>>> >>>> >>>Naiming >>> >>> >>> >>> >>>>Shen >>>>Sent: Tuesday, February 21, 2006 9:43 PM >>>>To: OSPF@PEACH.EASE.LSOFT.COM >>>>Subject: Re: Detecting router id change in p2p-over-lan connection >>>> >>>>Hello Acee, >>>> >>>>Your suggested paragraph looks fine with me. >>>> >>>>Even though this sentence assumes there is really a >>>>router-id change from a DC neighbor. A router probably >>>>should send a 'neighbor probing' [RFC 3883], if no >>>>response, then reset the adjacency and start >>>>the renegotiation; otherwise it should still ignore >>>>the new join on the p2p-over-lan link. >>>> >>>>But I would consider router-id change over a demand >>>>circuit over a p2p-over-lan on OSPF link a >>>>'misconfiguration';-) so it does not matter too much. >>>>Your version is fine. >>>> >>>>thanks. >>>>- Naiming >>>> >>>>Acee Lindem said the following on 02/21/2006 02:47 PM: >>>> >>>> >>>> >>>> >>>>>Hello Naiming, >>>>> >>>>>Naiming Shen wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Acee Lindem said the following on 02/21/2006 06:04 AM: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Naiming Shen wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Agree with Dave's argument, and this is the same idea as in the >>>>>>>>current draft of p2p-over-lan (section 4.5): >>>>>>>> >>>>>>>> ... If the system ID or the >>>>>>>> router ID of incoming hello packet does not match the system >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>ID or >>> >>> >>> >>> >>>>>>>> the router ID of already established adjacency over this >>>>>>>>p2p-over-lan >>>>>>>> circuit, it MUST discard the packet. The implementation should >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>offer >>>> >>>> >>>> >>>> >>>>>>>> logging and debugging information of the above events. >>>>>>>> >>>>>>>>Do we need to change anything here? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>Hi Naiming, >>>>>>> >>>>>>>Given that this situation can happen in the case of >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>misconfiguration >>> >>> >>> >>> >>>>or >>>> >>>> >>>> >>>> >>>>>>>router-ID change, I wouldn't optimize for the former. Especially >>>>>>>considering Kalyan's point that if hello's are suppressed, the >>>>>>>router-id change >>>>>>>will either not be recognized or require additional logic. I'd >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>vote >>> >>> >>> >>> >>>>>>>to either >>>>>>>leave it unspecified (consistent with RFC 2328's omission of >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>router-id >>> >>> >>> >>> >>>>>>>change P2P link handling) or discard the old neighbor and bring up >>>>>>>an adjacency with the new (which is what at least one >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>implementation >>> >>> >>> >>> >>>>>>>does >>>>>>>today). >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>Hello Acee, >>>>>> >>>>>>The original idea in the draft was to prevent multiple routers >>>>>> >>>>>> >>>>>> >>>>>> >>>joinning >>> >>> >>> >>> >>>>>>onto the same LAN rather than handing the router-ID change from the >>>>>>same router. Even through there is a side effect to it. >>>>>> >>>>>>For the router-ID change issue. If one is willing to change >>>>>> >>>>>> >>>>>> >>>>>> >>>router-ID >>> >>> >>> >>> >>>>>>or system-ID during normal operation, there are more things broken >>>>>>and there is nothing wrong to wait until the current adjacent >>>>>> >>>>>> >>>>>> >>>>>> >>>timeout. >>> >>> >>> >>> >>>>>Agreed. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>If the hello is suppressed over the link, then the behaviour is not >>>>>>bounded by this paragraph since it does not say the purpose is to >>>>>>detect neighbor router-id change. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>I disagree here. It says "MUST discard packet". That sounds pretty >>>>>bounding to me :^). >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Also there is little reason to >>>>>>suppress a hello over p2p-over-lan links. Thus I don't think >>>>>>router-id is an issue with this sentence. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>I agree - but there is nothing in this draft or RFC 1793 that >>>>> >>>>> >>>>> >>>>> >>>precludes >>> >>> >>> >>> >>>>it. >>>> >>>> >>>> >>>> >>>>>>Since p2p-over-lan is different from normal p2p circuit that >>>>>> >>>>>> >>>>>> >>>>>> >>>multiple >>> >>> >>> >>> >>>>>>routers can easily join the same LAN unintentionally. If we ignore >>>>>>the new station to join, then we can prevent the adjacency constant >>>>>>flapping(this does not happen to normal p2p link), the worst it can >>>>>>happen is slow to handle router-id change as mentioned above, which >>>>>>is a non issue. Thus I think it's a good thing to ignore the extra >>>>>>adjacency joinning. This sentence does not govern the normal p2p >>>>>> >>>>>> >>>>>> >>>>>> >>>link >>> >>> >>> >>> >>>>>>behaviour so the implementation is ok(even prefered) to reset the >>>>>>existing adjacency on a normal p2p link. Thus I don't think we >>>>>>should say we must reset the current adjacency for p2p-over-lan. >>>>>> >>>>>>My preference of this sentence in the draft is with this order: >>>>>> >>>>>>- leave it as is >>>>>>- change the MUST to SHOULD >>>>>>- remove the router-id related sentence >>>>>> >>>>>> >>>>>> >>>>>> >>>>>How about leave it "almost" as is: >>>>> >>>>> If the system ID or the router ID in an incoming hello packet >>>>> >>>>> >>>>> >>>>> >>>>doesn't >>>> >>>> >>>> >>>> >>>>> match the the system ID or router ID for an established >>>>> >>>>> >>>>> >>>>> >>>adjacency >>> >>> >>> >>> >>>>over >>>> >>>> >>>> >>>> >>>>> a p2p-over-lan circuit, the packet MUST be discarded. >>>>> >>>>> >>>>> >>>>> >>>Futhermore, >>> >>> >>> >>> >>>>> if OSPF hello suppression as described in [DEMAND] is active for >>>>> >>>>> >>>>> >>>>> >>>the >>> >>> >>> >>> >>>>> adjacency, it MUST be terminated and renegotiated. >>>>> >>>>>[DEMAND] Moy, J., "Extending OSPF to Support Demand Circuits", >>>>> RFC 1793, April 1995. >>>>> >>>>>Thanks, >>>>>Acee >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>thanks. >>>>>>- Naiming >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Thanks, >>>>>>>Acee >>>>>>> >>>>>>>Thanks, >>>>>>>Acee >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>thanks. >>>>>>>>- Naiming >>>>>>>> >>>>>>>>Dave Katz said the following on 02/20/2006 08:53 PM: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>RFC2328 is silent on what to do if you see a different router ID >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>on >>> >>> >>> >>> >>>>>>>>>a P2P link; if you take it literally, you will create two >>>>>>>>>adjacencies (temporarily), advertise both in your router LSA, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>and >>> >>> >>> >>> >>>>>>>>>your network will most likely black hole traffic until one of >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>them >>> >>> >>> >>> >>>>>>>>>times out. >>>>>>>>> >>>>>>>>>On real P2P links, this will suffice (if you don't mind a >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>network >>> >>> >>> >>> >>>>>>>>>outage for the dead time of the old adjacency) and things will >>>>>>>>>eventually stabilize since it is "impossible" (cough) two get >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>two >>> >>> >>> >>> >>>>>>>>>neighbors in 2Way. The fact that it is underspecified doesn't >>>>>>>>>matter that much. >>>>>>>>> >>>>>>>>>In the P2P-over-LAN case, there needs to be a mechanism to try >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>to >>> >>> >>> >>> >>>>>>>>>do something useful if there turn out to be more than two >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>routers >>> >>> >>> >>> >>>>>>>>>on the link. I don't think it's reasonable to say "gee it's >>>>>>>>>misconfigured, we don't care what happens to the network." >>>>>>>>> >>>>>>>>> >>>>>>>>>It seems to me that there are two possible cases, namely, use >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>the >>> >>> >>> >>> >>>>>>>>>old adjacency until it times out (effectively ignoring the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>hellos >>> >>> >>> >>> >>>>>>>>>from the new guy) or to form an adjacency with the new guy (and >>>>>>>> >>>>>>>> >>>>>>>>>blow away or otherwise ignore the old guy.) >>>>>>>>> >>>>>>>>>The first case has the advantage of stability and >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>simplicity--the >>> >>> >>> >>> >>>>>>>>>third router that shows up for the party will be ignored by both >>>>>>>>>parties. There is a potential for a circle of one-way >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>adjacencies >>> >>> >>> >>> >>>>>>>>>to stabilize, but this will still be stable (there won't be a >>>>>>>>>usable adjacency across the subnetwork.) >>>>>>>>> >>>>>>>>>The second case has the advantage that it adapts more quickly >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>when >>> >>> >>> >>> >>>>>>>>>something changes. Some implementations already do this for the >>>>>>>>>pure P2P case. However, it is destabilizing in the >>>>>>>>>misconfiguration case, as the router will flap its router LSA >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>each >>> >>> >>> >>> >>>>>>>>>time another Hello is received. Probably the only reasonable >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>way >>> >>> >>> >>> >>>>>>>>>out would be to detect the flap and then choose one neighbor >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>and >>> >>> >>> >>> >>>>>>>>>stick to it, ignoring the other (which degenerates into the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>first >>> >>> >>> >>> >>>>>>>>>case.) >>>>>>>>> >>>>>>>>>Given all of this, I'd propose that the right thing to do is the >>>>>>>>>first case, and suffer through the dead time (or use BFD and >>>>>>>>>suffer through the detection time.) >>>>>>>>> >>>>>>>>>(A third possible case would be to actually bring up the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>adjacency >>> >>> >>> >>> >>>>>>>>>and end up running full-mesh multipoint, which would probably >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>even >>> >>> >>> >>> >>>>>>>>>work, but would be butt ugly.) >>>>>>>>> >>>>>>>>>--Dave >>>>>>>>> >>>>>>>>> >>>>>>>>>On Feb 20, 2006, at 3:25 PM, Acee Lindem wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>Kalyan Bade wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>Acee, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>This might not work if the interface is defined as demand >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>circuit. >>>> >>>> >>>> >>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>Good point - We're in the process of discussing whether this >>>>>>>>>>>>behavior >>>>>>>>>>>>should be in the >>>>>>>>>>>>draft. Possibly, handling detection of a router-id change on >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>a >>> >>> >>> >>> >>>>P2P >>>> >>>> >>>> >>>> >>>>>>>>>>>over >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>LAN link >>>>>>>>>>>>differently than a normal P2P link may be a bad idea. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>How about bringing down the neighbor (rather than ignoring) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>when >>> >>> >>> >>> >>>>>>>>>>>a third >>>>>>>>>>>neighbor on a P2P over LAN sends a new hello? This creates >>>>>>>>>>>unnecessary >>>>>>>>>>>flaps, but again having more than 2 routers on a p2p LAN is a >>>>>>>>>>>misconfig. >>>>>>>>>>>Atleast, the processing will be similar to a regular p2p >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>interface. >>>> >>>> >>>> >>>> >>>>>>>>>>That would be fine and consistent with what most routers do on >>>>>>>>>>normal P2P links. I think the >>>>>>>>>>P2P over LAN specific router-ID change processing should be >>>>>>>>>>removed from the draft. >>>>>>>>>> >>>>>>>>>>Thanks, >>>>>>>>>>Acee >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>Thanks, >>>>>>>>>>>Kalyan. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>> >>> >>> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 24 08:21:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCcsq-0005Ew-IZ for ospf-archive@LISTS.IETF.ORG; Fri, 24 Feb 2006 08:21:20 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCcsq-0002Xp-2Q for ospf-archive@LISTS.IETF.ORG; Fri, 24 Feb 2006 08:21:20 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <6.00035013@wildebeest.ease.lsoft.com>; Fri, 24 Feb 2006 8:21:19 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100281857 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 24 Feb 2006 08:21:19 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 24 Feb 2006 08:21:19 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 24 Feb 2006 05:21:19 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,143,1139212800"; d="scan'208"; a="22530663:sNHT29370006" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1ODLIqM022226 for ; Fri, 24 Feb 2006 08:21:18 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Feb 2006 08:21:18 -0500 Received: from [10.82.216.60] ([10.82.216.60]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Feb 2006 08:21:17 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <6D975E431022374F9F7A298A511427B6193701@mailblr1.engineering.netscaler.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Feb 2006 13:21:17.0845 (UTC) FILETIME=[31D8B450:01C63945] Message-ID: <43FF084D.8070302@cisco.com> Date: Fri, 24 Feb 2006 08:21:17 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Detecting router id change in p2p-over-lan connection To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <6D975E431022374F9F7A298A511427B6193701@mailblr1.engineering.netscaler.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3da7e5d5ca82d58872786934e4963616 Nitin Kakkar wrote: >Can someone please explain me the rational behind terminating adjacency >in " if OSPF hello suppression as described in [DEMAND] is active for >the >adjacency, it MUST be terminated and renegotiated" > >Why do we want a stray hello to terminate existing adjacency? > > Perhaps "it" should be replaced with "hello suppression" or perhaps you were lead astray by prevoius poss. Terminating "hello suppresssion" doesn't bring down the adjacency, it merely implies that the dead interval is enforced and hello are sent. The reason for this is to handle router-id changes. Without this clause, the old adjacency would persist indefinitely. Thanks, Acee >Thanks & Regards >Nitin >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Sunil >Patro >Sent: Thursday, February 23, 2006 3:24 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: Detecting router id change in p2p-over-lan connection > >Hi Everyone, > >Thanks for all the feedback. > >Can I safely assume that the final behavior is what Acee's recommended >paragraph says below? > >"If the system ID or the router ID in an incoming hello packet >doesn't match the the system ID or router ID for an established >adjacency >over a p2p-over-lan circuit, the packet MUST be discarded. Futhermore, >if OSPF hello suppression as described in [DEMAND] is active for the >adjacency, it MUST be terminated and renegotiated." > >Thanks, >Sunil > > > >>-----Original Message----- >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >> >> >Naiming > > >>Shen >>Sent: Tuesday, February 21, 2006 9:43 PM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Re: Detecting router id change in p2p-over-lan connection >> >>Hello Acee, >> >>Your suggested paragraph looks fine with me. >> >>Even though this sentence assumes there is really a >>router-id change from a DC neighbor. A router probably >>should send a 'neighbor probing' [RFC 3883], if no >>response, then reset the adjacency and start >>the renegotiation; otherwise it should still ignore >>the new join on the p2p-over-lan link. >> >>But I would consider router-id change over a demand >>circuit over a p2p-over-lan on OSPF link a >>'misconfiguration';-) so it does not matter too much. >>Your version is fine. >> >>thanks. >>- Naiming >> >>Acee Lindem said the following on 02/21/2006 02:47 PM: >> >> >>>Hello Naiming, >>> >>>Naiming Shen wrote: >>> >>> >>> >>>>Acee Lindem said the following on 02/21/2006 06:04 AM: >>>> >>>> >>>> >>>>>Naiming Shen wrote: >>>>> >>>>> >>>>> >>>>>>Agree with Dave's argument, and this is the same idea as in the >>>>>>current draft of p2p-over-lan (section 4.5): >>>>>> >>>>>> ... If the system ID or the >>>>>> router ID of incoming hello packet does not match the system >>>>>> >>>>>> >ID or > > >>>>>> the router ID of already established adjacency over this >>>>>>p2p-over-lan >>>>>> circuit, it MUST discard the packet. The implementation should >>>>>> >>>>>> >>offer >> >> >>>>>> logging and debugging information of the above events. >>>>>> >>>>>>Do we need to change anything here? >>>>>> >>>>>> >>>>> >>>>> >>>>>Hi Naiming, >>>>> >>>>>Given that this situation can happen in the case of >>>>> >>>>> >misconfiguration > > >>or >> >> >>>>>router-ID change, I wouldn't optimize for the former. Especially >>>>>considering Kalyan's point that if hello's are suppressed, the >>>>>router-id change >>>>>will either not be recognized or require additional logic. I'd >>>>> >>>>> >vote > > >>>>>to either >>>>>leave it unspecified (consistent with RFC 2328's omission of >>>>> >>>>> >router-id > > >>>>>change P2P link handling) or discard the old neighbor and bring up >>>>>an adjacency with the new (which is what at least one >>>>> >>>>> >implementation > > >>>>>does >>>>>today). >>>>> >>>>> >>>> >>>>Hello Acee, >>>> >>>>The original idea in the draft was to prevent multiple routers >>>> >>>> >joinning > > >>>>onto the same LAN rather than handing the router-ID change from the >>>>same router. Even through there is a side effect to it. >>>> >>>>For the router-ID change issue. If one is willing to change >>>> >>>> >router-ID > > >>>>or system-ID during normal operation, there are more things broken >>>>and there is nothing wrong to wait until the current adjacent >>>> >>>> >timeout. > > >>>Agreed. >>> >>> >>> >>>>If the hello is suppressed over the link, then the behaviour is not >>>>bounded by this paragraph since it does not say the purpose is to >>>>detect neighbor router-id change. >>>> >>>> >>>I disagree here. It says "MUST discard packet". That sounds pretty >>>bounding to me :^). >>> >>> >>> >>>>Also there is little reason to >>>>suppress a hello over p2p-over-lan links. Thus I don't think >>>>router-id is an issue with this sentence. >>>> >>>> >>>I agree - but there is nothing in this draft or RFC 1793 that >>> >>> >precludes > > >>it. >> >> >>>>Since p2p-over-lan is different from normal p2p circuit that >>>> >>>> >multiple > > >>>>routers can easily join the same LAN unintentionally. If we ignore >>>>the new station to join, then we can prevent the adjacency constant >>>>flapping(this does not happen to normal p2p link), the worst it can >>>>happen is slow to handle router-id change as mentioned above, which >>>>is a non issue. Thus I think it's a good thing to ignore the extra >>>>adjacency joinning. This sentence does not govern the normal p2p >>>> >>>> >link > > >>>>behaviour so the implementation is ok(even prefered) to reset the >>>>existing adjacency on a normal p2p link. Thus I don't think we >>>>should say we must reset the current adjacency for p2p-over-lan. >>>> >>>>My preference of this sentence in the draft is with this order: >>>> >>>> - leave it as is >>>> - change the MUST to SHOULD >>>> - remove the router-id related sentence >>>> >>>> >>>How about leave it "almost" as is: >>> >>> If the system ID or the router ID in an incoming hello packet >>> >>> >>doesn't >> >> >>> match the the system ID or router ID for an established >>> >>> >adjacency > > >>over >> >> >>> a p2p-over-lan circuit, the packet MUST be discarded. >>> >>> >Futhermore, > > >>> if OSPF hello suppression as described in [DEMAND] is active for >>> >>> >the > > >>> adjacency, it MUST be terminated and renegotiated. >>> >>>[DEMAND] Moy, J., "Extending OSPF to Support Demand Circuits", >>> RFC 1793, April 1995. >>> >>>Thanks, >>>Acee >>> >>> >>> >>>>thanks. >>>>- Naiming >>>> >>>> >>>> >>>>>Thanks, >>>>>Acee >>>>> >>>>>Thanks, >>>>>Acee >>>>> >>>>> >>>>> >>>>>>thanks. >>>>>>- Naiming >>>>>> >>>>>>Dave Katz said the following on 02/20/2006 08:53 PM: >>>>>> >>>>>> >>>>>> >>>>>>>RFC2328 is silent on what to do if you see a different router ID >>>>>>> >>>>>>> >on > > >>>>>>>a P2P link; if you take it literally, you will create two >>>>>>>adjacencies (temporarily), advertise both in your router LSA, >>>>>>> >>>>>>> >and > > >>>>>>>your network will most likely black hole traffic until one of >>>>>>> >>>>>>> >them > > >>>>>>>times out. >>>>>>> >>>>>>>On real P2P links, this will suffice (if you don't mind a >>>>>>> >>>>>>> >network > > >>>>>>>outage for the dead time of the old adjacency) and things will >>>>>>>eventually stabilize since it is "impossible" (cough) two get >>>>>>> >>>>>>> >two > > >>>>>>>neighbors in 2Way. The fact that it is underspecified doesn't >>>>>>>matter that much. >>>>>>> >>>>>>>In the P2P-over-LAN case, there needs to be a mechanism to try >>>>>>> >>>>>>> >to > > >>>>>>>do something useful if there turn out to be more than two >>>>>>> >>>>>>> >routers > > >>>>>>>on the link. I don't think it's reasonable to say "gee it's >>>>>>>misconfigured, we don't care what happens to the network." >>>>>>> >>>>>>> >>>>>>>It seems to me that there are two possible cases, namely, use >>>>>>> >>>>>>> >the > > >>>>>>>old adjacency until it times out (effectively ignoring the >>>>>>> >>>>>>> >hellos > > >>>>>>>from the new guy) or to form an adjacency with the new guy (and >>>>>>>blow away or otherwise ignore the old guy.) >>>>>>> >>>>>>>The first case has the advantage of stability and >>>>>>> >>>>>>> >simplicity--the > > >>>>>>>third router that shows up for the party will be ignored by both >>>>>>>parties. There is a potential for a circle of one-way >>>>>>> >>>>>>> >adjacencies > > >>>>>>>to stabilize, but this will still be stable (there won't be a >>>>>>>usable adjacency across the subnetwork.) >>>>>>> >>>>>>>The second case has the advantage that it adapts more quickly >>>>>>> >>>>>>> >when > > >>>>>>>something changes. Some implementations already do this for the >>>>>>>pure P2P case. However, it is destabilizing in the >>>>>>>misconfiguration case, as the router will flap its router LSA >>>>>>> >>>>>>> >each > > >>>>>>>time another Hello is received. Probably the only reasonable >>>>>>> >>>>>>> >way > > >>>>>>>out would be to detect the flap and then choose one neighbor >>>>>>> >>>>>>> >and > > >>>>>>>stick to it, ignoring the other (which degenerates into the >>>>>>> >>>>>>> >first > > >>>>>>>case.) >>>>>>> >>>>>>>Given all of this, I'd propose that the right thing to do is the >>>>>>>first case, and suffer through the dead time (or use BFD and >>>>>>>suffer through the detection time.) >>>>>>> >>>>>>>(A third possible case would be to actually bring up the >>>>>>> >>>>>>> >adjacency > > >>>>>>>and end up running full-mesh multipoint, which would probably >>>>>>> >>>>>>> >even > > >>>>>>>work, but would be butt ugly.) >>>>>>> >>>>>>>--Dave >>>>>>> >>>>>>> >>>>>>>On Feb 20, 2006, at 3:25 PM, Acee Lindem wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Kalyan Bade wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>Acee, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>>This might not work if the interface is defined as demand >>>>>>>>>>> >>>>>>>>>>> >>circuit. >> >> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>Good point - We're in the process of discussing whether this >>>>>>>>>>behavior >>>>>>>>>>should be in the >>>>>>>>>>draft. Possibly, handling detection of a router-id change on >>>>>>>>>> >>>>>>>>>> >a > > >>P2P >> >> >>>>>>>>>over >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>LAN link >>>>>>>>>>differently than a normal P2P link may be a bad idea. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>How about bringing down the neighbor (rather than ignoring) >>>>>>>>> >>>>>>>>> >when > > >>>>>>>>>a third >>>>>>>>>neighbor on a P2P over LAN sends a new hello? This creates >>>>>>>>>unnecessary >>>>>>>>>flaps, but again having more than 2 routers on a p2p LAN is a >>>>>>>>>misconfig. >>>>>>>>>Atleast, the processing will be similar to a regular p2p >>>>>>>>> >>>>>>>>> >>interface. >> >> >>>>>>>>That would be fine and consistent with what most routers do on >>>>>>>>normal P2P links. I think the >>>>>>>>P2P over LAN specific router-ID change processing should be >>>>>>>>removed from the draft. >>>>>>>> >>>>>>>>Thanks, >>>>>>>>Acee >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>Thanks, >>>>>>>>>Kalyan. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 24 09:10:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCde6-0001B7-1V for ospf-archive@LISTS.IETF.ORG; Fri, 24 Feb 2006 09:10:10 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCde5-0003wn-P8 for ospf-archive@LISTS.IETF.ORG; Fri, 24 Feb 2006 09:10:10 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <9.0003513C@wildebeest.ease.lsoft.com>; Fri, 24 Feb 2006 9:10:09 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100289746 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 24 Feb 2006 09:10:09 -0500 Received: from 171.71.176.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 24 Feb 2006 09:10:09 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 24 Feb 2006 06:10:08 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1OEA3Hh019434 for ; Fri, 24 Feb 2006 06:10:04 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Feb 2006 09:10:04 -0500 Received: from [10.82.216.60] ([10.82.216.60]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Feb 2006 09:10:04 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <43F63D76.4030009@cisco.com> <000b01c635cb$cddcca30$610c6f0a@china.huawei.com> <43F9DD10.8040305@cisco.com> <001601c636e4$5ea03980$610c6f0a@china.huawei.com> <43FCDA9B.9050307@cisco.com> <000701c63928$9908e590$610c6f0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Feb 2006 14:10:04.0301 (UTC) FILETIME=[022673D0:01C6394C] Message-ID: <43FF13BB.9030903@cisco.com> Date: Fri, 24 Feb 2006 09:10:03 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-kou-ospf-immediately-replying-hello-00.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000701c63928$9908e590$610c6f0a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Zengjie Kou wrote: >Hi, Acee > The empty hello mechanism that you refered is adopted by most OSPF implementations indeed when an interface first comes up. >I agree this. However, when an normal interface whose state is up goes down then up, immediate hello is effective by avoiding >helloInterval or backupSeen. > > Hi Zengjie, I don't think there should be a distinction between first coming or coming back up. Thanks, Acee >Thanks, >Zengjie > >----- Original Message ----- >From: "Acee Lindem" >To: >Sent: Thursday, February 23, 2006 5:41 AM >Subject: Re: draft-kou-ospf-immediately-replying-hello-00.txt > > > > >>Zengjie Kou wrote: >> >> >> >>>Hi, Acee, >>> You are right, immediate hello does not provide the mechanism of detecting link down fast. But, immediate hello improve to discover neighbors when interface goes down then up. In practice, the requirement is needed. >>> >>> >>> >>> >>Hi Zengjie, >> >>Speaking strictly in terms of state machines, it seems the interface >>would lose it's DR/BDR state >>when it goes down (and cannot send a hello). Wouldn't this scenario be >>better handled >>by the empty hello many OSPF implementations send when an interface >>first comes up? >> >>Thanks, >>Acee >> >> >> >>>Thanks, >>>Zengjie >>> >>>----- Original Message ----- >>>From: "Acee Lindem" >>>To: >>>Sent: Monday, February 20, 2006 11:15 PM >>>Subject: Re: draft-kou-ospf-immediately-replying-hello-00.txt >>> >>> >>> >>> >>> >>> >>>>Hi Zengjie, >>>> >>>>Zengjie Kou wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Hi,Acee, >>>>> If a router interface whose role is changed(e.g.DR goes down), the router will notify all routers about the change by immediate hello. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>This is only when the DR/BDR knows that it is going down or the case >>>>where the router >>>>priority is set to 0. >>>> >>>>For a router becoming DR/BDR, all the routers should elect the same DR/BDR >>>>so I don't see how it helps. >>>> >>>>Thanks, >>>>Acee >>>> >>>> >>>> >>>> >>>> >>>>>After all router get the change, election will be reprocessed. In contrast to normal hello, immediate hello avoid the backupSeen. >>>>>Namely, improving convergence. >>>>> >>>>>Thanks a lot, >>>>>Zengjie >>>>> >>>>>----- Original Message ----- >>>>>From: "Acee Lindem" >>>>>To: >>>>>Sent: Saturday, February 18, 2006 5:17 AM >>>>>Subject: draft-kou-ospf-immediately-replying-hello-00.txt >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Hi Zengjie, >>>>>> >>>>>>Under what situations does having the router who changed to/from >>>>>>DR/BDR improve convergence (section 6.2)? Since DR/BDR election >>>>>>is a distributed algorithm dependent on the calculating routers state, it >>>>>>seems this won't help in all that many cases. >>>>>> >>>>>>Thanks, >>>>>>Acee >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> >>> >>> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Feb 24 20:56:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCofm-0008FE-NW for ospf-archive@LISTS.IETF.ORG; Fri, 24 Feb 2006 20:56:38 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCofm-0005Zm-62 for ospf-archive@LISTS.IETF.ORG; Fri, 24 Feb 2006 20:56:38 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <0.00035D90@wildebeest.ease.lsoft.com>; Fri, 24 Feb 2006 20:56:34 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100312723 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 24 Feb 2006 20:56:33 -0500 Received: from 207.69.195.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 24 Feb 2006 20:56:33 -0500 Received: from h-68-164-155-88.snvacaid.dynamic.covad.net ([68.164.155.88] helo=earthlink.net) by pop-borzoi.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1FCofh-0004l8-00 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 24 Feb 2006 20:56:33 -0500 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <6D975E431022374F9F7A298A511427B6193701@mailblr1.engineering.netscaler.com> <43FF084D.8070302@cisco.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43FFB884.F22E9607@earthlink.net> Date: Fri, 24 Feb 2006 17:53:08 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Detecting router id change in p2p-over-lan connection To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8d68e55b48f2ff3cebd1a6416d9536 Group, There are two thing going on here.. here is my full blown dictionary interpretation of what is done and justify the empty hello for hello suppression change and/or router-id changes. 1) hello suppression and revoke of hello suppression ------- If only a hello suppression is revoked, I can almost scizophrenicly see that one could send a hello with a nbr listed. In theory. Actively revoking can be done with a hello listing or not listing the nbr. HOWEVER, The RFC specifies that upon a link change state that hello suppression can be done. RFC 1793 section 3.2.1 "The router will then automatically attempt to renegotiate Hello suppression whenever the link goes down and comes back up." This is bi-directional to me.. This "implicitly" disaproves of checking the hello bit after the nbr has formed the adj. I didn't write this. :) So in theory a flag gets set when the nbr is seen and we compare whether we both want to suppress hellos. After we complete the adj formation, we check the flag and if se, we suppress hellos. Realize that we were also sending DNA LSAs out at initial DBD exhange time based on this flag setting. Thus, we need to reset the nbr state if we want to later re-enable suppression and re-originate LSAs with/without the DNA bit set. In addition, if we supress the D/C behaviour, I read that the DNA bit should no longer be set. To reset this bit, one needs to re-originate the LSAs. The only simple way is via a new adj and yes with a empty hello. 2) router-id change... However, if one also changes a router-id, sorry, I can not see how the adj can be re-uesed for the LSAs. With the empty nbr hello... The protocol states that we ONLY send a nbr listed within the hello if we have seen a hello within our dead-router time. With the suppression of hellos we surely haven't met that criteria.... each originated LSA is tagged with the router-id and a new router-id requires new LSAs................... Yes, I am ALSO assuming for consistency that if a router-id changed then the SAME BEHAVIOUR without regard to interface type SHOULD be followed. Without a P2P interface (say a BMA interface type or a P2MP, changing the router-id leads to uncertaincy. Even with P2P, we may not have communicated with this nbr for up to 1 hr. If the D/C nbr has not quietly gone away: * the empty hello re-inits (nbt = init state) an exiting adj, * ALL LSAs are tagged with the router-id, unless one goes out and searches for existing LSAs with the old router-id, then the LSAs need to be reflooded, * The adj went to the init state, (we are re-initializing at least the hello), * we should get a response within the hello interval, * changing one's own router-id SHOULD be an infrequent router change... * the LSAs should be fairly consistent and achieving full adj should be a minimal task, * this is a guranteed way to recieve a hello if the nbr is just suppressing hellos, Thus, is the justification for empty hellos to reset nbr state if hello suppression and/or router-id is changed. Mitchell Erblich ----------------- Acee Lindem wrote: > > Nitin Kakkar wrote: > > >Can someone please explain me the rational behind terminating adjacency > >in " if OSPF hello suppression as described in [DEMAND] is active for > >the > >adjacency, it MUST be terminated and renegotiated" > > > >Why do we want a stray hello to terminate existing adjacency? > > > > > Perhaps "it" should be replaced with "hello suppression" or perhaps you > were lead astray by > prevoius poss. Terminating "hello suppresssion" doesn't bring down the > adjacency, it merely > implies that the dead interval is enforced and hello are sent. The > reason for this is to handle > router-id changes. Without this clause, the old adjacency would persist > indefinitely. > > Thanks, > Acee > > >Thanks & Regards > >Nitin > >-----Original Message----- > >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Sunil > >Patro > >Sent: Thursday, February 23, 2006 3:24 AM > >To: OSPF@PEACH.EASE.LSOFT.COM > >Subject: Re: Detecting router id change in p2p-over-lan connection > > > >Hi Everyone, > > > >Thanks for all the feedback. > > > >Can I safely assume that the final behavior is what Acee's recommended > >paragraph says below? > > > >"If the system ID or the router ID in an incoming hello packet > >doesn't match the the system ID or router ID for an established > >adjacency > >over a p2p-over-lan circuit, the packet MUST be discarded. Futhermore, > >if OSPF hello suppression as described in [DEMAND] is active for the > >adjacency, it MUST be terminated and renegotiated." > > > >Thanks, > >Sunil > > > > > > > >>-----Original Message----- > >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > >> > >> > >Naiming > > > > > >>Shen > >>Sent: Tuesday, February 21, 2006 9:43 PM > >>To: OSPF@PEACH.EASE.LSOFT.COM > >>Subject: Re: Detecting router id change in p2p-over-lan connection > >> > >>Hello Acee, > >> > >>Your suggested paragraph looks fine with me. > >> > >>Even though this sentence assumes there is really a > >>router-id change from a DC neighbor. A router probably > >>should send a 'neighbor probing' [RFC 3883], if no > >>response, then reset the adjacency and start > >>the renegotiation; otherwise it should still ignore > >>the new join on the p2p-over-lan link. > >> > >>But I would consider router-id change over a demand > >>circuit over a p2p-over-lan on OSPF link a > >>'misconfiguration';-) so it does not matter too much. > >>Your version is fine. > >> > >>thanks. > >>- Naiming > >> > >>Acee Lindem said the following on 02/21/2006 02:47 PM: > >> > >> > >>>Hello Naiming, > >>> > >>>Naiming Shen wrote: > >>> > >>> > >>> > >>>>Acee Lindem said the following on 02/21/2006 06:04 AM: > >>>> > >>>> > >>>> > >>>>>Naiming Shen wrote: > >>>>> > >>>>> > >>>>> > >>>>>>Agree with Dave's argument, and this is the same idea as in the > >>>>>>current draft of p2p-over-lan (section 4.5): > >>>>>> > >>>>>> ... If the system ID or the > >>>>>> router ID of incoming hello packet does not match the system > >>>>>> > >>>>>> > >ID or > > > > > >>>>>> the router ID of already established adjacency over this > >>>>>>p2p-over-lan > >>>>>> circuit, it MUST discard the packet. The implementation should > >>>>>> > >>>>>> > >>offer > >> > >> > >>>>>> logging and debugging information of the above events. > >>>>>> > >>>>>>Do we need to change anything here? > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>>Hi Naiming, > >>>>> > >>>>>Given that this situation can happen in the case of > >>>>> > >>>>> > >misconfiguration > > > > > >>or > >> > >> > >>>>>router-ID change, I wouldn't optimize for the former. Especially > >>>>>considering Kalyan's point that if hello's are suppressed, the > >>>>>router-id change > >>>>>will either not be recognized or require additional logic. I'd > >>>>> > >>>>> > >vote > > > > > >>>>>to either > >>>>>leave it unspecified (consistent with RFC 2328's omission of > >>>>> > >>>>> > >router-id > > > > > >>>>>change P2P link handling) or discard the old neighbor and bring up > >>>>>an adjacency with the new (which is what at least one > >>>>> > >>>>> > >implementation > > > > > >>>>>does > >>>>>today). > >>>>> > >>>>> > >>>> > >>>>Hello Acee, > >>>> > >>>>The original idea in the draft was to prevent multiple routers > >>>> > >>>> > >joinning > > > > > >>>>onto the same LAN rather than handing the router-ID change from the > >>>>same router. Even through there is a side effect to it. > >>>> > >>>>For the router-ID change issue. If one is willing to change > >>>> > >>>> > >router-ID > > > > > >>>>or system-ID during normal operation, there are more things broken > >>>>and there is nothing wrong to wait until the current adjacent > >>>> > >>>> > >timeout. > > > > > >>>Agreed. > >>> > >>> > >>> > >>>>If the hello is suppressed over the link, then the behaviour is not > >>>>bounded by this paragraph since it does not say the purpose is to > >>>>detect neighbor router-id change. > >>>> > >>>> > >>>I disagree here. It says "MUST discard packet". That sounds pretty > >>>bounding to me :^). > >>> > >>> > >>> > >>>>Also there is little reason to > >>>>suppress a hello over p2p-over-lan links. Thus I don't think > >>>>router-id is an issue with this sentence. > >>>> > >>>> > >>>I agree - but there is nothing in this draft or RFC 1793 that > >>> > >>> > >precludes > > > > > >>it. > >> > >> > >>>>Since p2p-over-lan is different from normal p2p circuit that > >>>> > >>>> > >multiple > > > > > >>>>routers can easily join the same LAN unintentionally. If we ignore > >>>>the new station to join, then we can prevent the adjacency constant > >>>>flapping(this does not happen to normal p2p link), the worst it can > >>>>happen is slow to handle router-id change as mentioned above, which > >>>>is a non issue. Thus I think it's a good thing to ignore the extra > >>>>adjacency joinning. This sentence does not govern the normal p2p > >>>> > >>>> > >link > > > > > >>>>behaviour so the implementation is ok(even prefered) to reset the > >>>>existing adjacency on a normal p2p link. Thus I don't think we > >>>>should say we must reset the current adjacency for p2p-over-lan. > >>>> > >>>>My preference of this sentence in the draft is with this order: > >>>> > >>>> - leave it as is > >>>> - change the MUST to SHOULD > >>>> - remove the router-id related sentence > >>>> > >>>> > >>>How about leave it "almost" as is: > >>> > >>> If the system ID or the router ID in an incoming hello packet > >>> > >>> > >>doesn't > >> > >> > >>> match the the system ID or router ID for an established > >>> > >>> > >adjacency > > > > > >>over > >> > >> > >>> a p2p-over-lan circuit, the packet MUST be discarded. > >>> > >>> > >Futhermore, > > > > > >>> if OSPF hello suppression as described in [DEMAND] is active for > >>> > >>> > >the > > > > > >>> adjacency, it MUST be terminated and renegotiated. > >>> > >>>[DEMAND] Moy, J., "Extending OSPF to Support Demand Circuits", > >>> RFC 1793, April 1995. > >>> > >>>Thanks, > >>>Acee > >>> > >>> > >>> > >>>>thanks. > >>>>- Naiming > >>>> > >>>> > >>>> > >>>>>Thanks, > >>>>>Acee > >>>>> > >>>>>Thanks, > >>>>>Acee > >>>>> > >>>>> > >>>>> > >>>>>>thanks. > >>>>>>- Naiming > >>>>>> > >>>>>>Dave Katz said the following on 02/20/2006 08:53 PM: > >>>>>> > >>>>>> > >>>>>> > >>>>>>>RFC2328 is silent on what to do if you see a different router ID > >>>>>>> > >>>>>>> > >on > > > > > >>>>>>>a P2P link; if you take it literally, you will create two > >>>>>>>adjacencies (temporarily), advertise both in your router LSA, > >>>>>>> > >>>>>>> > >and > > > > > >>>>>>>your network will most likely black hole traffic until one of > >>>>>>> > >>>>>>> > >them > > > > > >>>>>>>times out. > >>>>>>> > >>>>>>>On real P2P links, this will suffice (if you don't mind a > >>>>>>> > >>>>>>> > >network > > > > > >>>>>>>outage for the dead time of the old adjacency) and things will > >>>>>>>eventually stabilize since it is "impossible" (cough) two get > >>>>>>> > >>>>>>> > >two > > > > > >>>>>>>neighbors in 2Way. The fact that it is underspecified doesn't > >>>>>>>matter that much. > >>>>>>> > >>>>>>>In the P2P-over-LAN case, there needs to be a mechanism to try > >>>>>>> > >>>>>>> > >to > > > > > >>>>>>>do something useful if there turn out to be more than two > >>>>>>> > >>>>>>> > >routers > > > > > >>>>>>>on the link. I don't think it's reasonable to say "gee it's > >>>>>>>misconfigured, we don't care what happens to the network." > >>>>>>> > >>>>>>> > >>>>>>>It seems to me that there are two possible cases, namely, use > >>>>>>> > >>>>>>> > >the > > > > > >>>>>>>old adjacency until it times out (effectively ignoring the > >>>>>>> > >>>>>>> > >hellos > > > > > >>>>>>>from the new guy) or to form an adjacency with the new guy (and > >>>>>>>blow away or otherwise ignore the old guy.) > >>>>>>> > >>>>>>>The first case has the advantage of stability and > >>>>>>> > >>>>>>> > >simplicity--the > > > > > >>>>>>>third router that shows up for the party will be ignored by both > >>>>>>>parties. There is a potential for a circle of one-way > >>>>>>> > >>>>>>> > >adjacencies > > > > > >>>>>>>to stabilize, but this will still be stable (there won't be a > >>>>>>>usable adjacency across the subnetwork.) > >>>>>>> > >>>>>>>The second case has the advantage that it adapts more quickly > >>>>>>> > >>>>>>> > >when > > > > > >>>>>>>something changes. Some implementations already do this for the > >>>>>>>pure P2P case. However, it is destabilizing in the > >>>>>>>misconfiguration case, as the router will flap its router LSA > >>>>>>> > >>>>>>> > >each > > > > > >>>>>>>time another Hello is received. Probably the only reasonable > >>>>>>> > >>>>>>> > >way > > > > > >>>>>>>out would be to detect the flap and then choose one neighbor > >>>>>>> > >>>>>>> > >and > > > > > >>>>>>>stick to it, ignoring the other (which degenerates into the > >>>>>>> > >>>>>>> > >first > > > > > >>>>>>>case.) > >>>>>>> > >>>>>>>Given all of this, I'd propose that the right thing to do is the > >>>>>>>first case, and suffer through the dead time (or use BFD and > >>>>>>>suffer through the detection time.) > >>>>>>> > >>>>>>>(A third possible case would be to actually bring up the > >>>>>>> > >>>>>>> > >adjacency > > > > > >>>>>>>and end up running full-mesh multipoint, which would probably > >>>>>>> > >>>>>>> > >even > > > > > >>>>>>>work, but would be butt ugly.) > >>>>>>> > >>>>>>>--Dave > >>>>>>> > >>>>>>> > >>>>>>>On Feb 20, 2006, at 3:25 PM, Acee Lindem wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>Kalyan Bade wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>Acee, > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>>This might not work if the interface is defined as demand > >>>>>>>>>>> > >>>>>>>>>>> > >>circuit. > >> > >> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>Good point - We're in the process of discussing whether this > >>>>>>>>>>behavior > >>>>>>>>>>should be in the > >>>>>>>>>>draft. Possibly, handling detection of a router-id change on > >>>>>>>>>> > >>>>>>>>>> > >a > > > > > >>P2P > >> > >> > >>>>>>>>>over > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>LAN link > >>>>>>>>>>differently than a normal P2P link may be a bad idea. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>How about bringing down the neighbor (rather than ignoring) > >>>>>>>>> > >>>>>>>>> > >when > > > > > >>>>>>>>>a third > >>>>>>>>>neighbor on a P2P over LAN sends a new hello? This creates > >>>>>>>>>unnecessary > >>>>>>>>>flaps, but again having more than 2 routers on a p2p LAN is a > >>>>>>>>>misconfig. > >>>>>>>>>Atleast, the processing will be similar to a regular p2p > >>>>>>>>> > >>>>>>>>> > >>interface. > >> > >> > >>>>>>>>That would be fine and consistent with what most routers do on > >>>>>>>>normal P2P links. I think the > >>>>>>>>P2P over LAN specific router-ID change processing should be > >>>>>>>>removed from the draft. > >>>>>>>> > >>>>>>>>Thanks, > >>>>>>>>Acee > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>Thanks, > >>>>>>>>>Kalyan. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 27 05:51:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDfyY-0005aw-Tg for ospf-archive@LISTS.IETF.ORG; Mon, 27 Feb 2006 05:51:34 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDfyY-00059e-J6 for ospf-archive@LISTS.IETF.ORG; Mon, 27 Feb 2006 05:51:34 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <1.0003762C@wildebeest.ease.lsoft.com>; Mon, 27 Feb 2006 5:51:32 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100474767 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 27 Feb 2006 05:51:31 -0500 Received: from 64.233.184.192 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 27 Feb 2006 05:51:31 -0500 Received: by wproxy.gmail.com with SMTP id i31so805725wra for ; Mon, 27 Feb 2006 02:51:31 -0800 (PST) Received: by 10.54.71.15 with SMTP id t15mr4133533wra; Mon, 27 Feb 2006 02:51:30 -0800 (PST) Received: by 10.54.116.7 with HTTP; Mon, 27 Feb 2006 02:51:30 -0800 (PST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1058_15640779.1141037490944" References: Message-ID: Date: Mon, 27 Feb 2006 16:21:30 +0530 Reply-To: Mailing List Sender: Mailing List From: Santosh Esale Subject: Re: Question about routing table update To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.5 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb ------=_Part_1058_15640779.1141037490944 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Sushma, see inline. Thanks Santosh On 2/24/06, Sushma Venkatesh wrote: > > As per section 13.2 in RFC 2328, receipt of a router or network LSA with > changed > contents leads to recalculation of entire routing table. > > As per section 16 in RFC 2328, the routing table calculation involves: > > (1)Dijkstra calculation for each attached area considering only the links > > between routers and transit networks. > (2)Stub networks are incorporated into the area trees by going through th > e > router LSA of each reachable router again. > (3)All the summary LSAs are examined to calculate inter-area routes. > (4) All AS-external LSAs are examined to calculate routes to external > destinations. > > Questions for the group: > (1)Clearly, depending on the number of summary and ASE LSAs, the routing > table > update may take much longer than simple dijkstra calculations of all atta > ched > areas. There exist some studies (Shaikh 2001, Basu 2001) that attribute t > imes > of the order of tens of milliseconds to dijkstra calculations based on th > e > number of routers in the area. Are you aware of any studies that > experimentally measure or model the time spent in doing routing table upd > ates? > Are their any studies or rules of thumb to estimate the time spent examin > ing > the summary and ASE LSAs? Is it reasonable to assume that the time spent > examining the summary/ASE LSAs is linear in terms of the number of such L > SAs? San>> a) The time spent examining the summary LSAs depends upon the type of OSPF router. OSPF ABR calculates routes for backbone summary LSAs as well generates summary LSA for these routes to be flooded into other non backbon= e areas. OSPF router internal to any area will only calculate the routes for these LSAs.So it takes linear time in terms of number of LSAs on a particular type of OSPF router. b) External LSA will take linear time in terms of number of LSAs. Thuogh i never measured in terms of time this calculation. > (2)Is it reasonable to assume that modern routers perform the complete ro > uting > table update following the receipt of a changed router/network LSA as ONE > > activity WITHOUT PREEMPTION? Or are they likely to split the complete rou > ting > table update process in multiple parts and perform them as time permits? > San>> i know atleast one implementation where its splits the routing table calculations into three parts: 1. Intra-area calculations(Dijkstra calculation ) for all areas and starts = a timer for inter-area calculation. << preemption can occur here >> 2. Inter-area calculations and it will start a timer of external-route calculations << preemption can occur here>> 3. External route calculations ------=_Part_1058_15640779.1141037490944 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Sushma,
           &nbs= p;     see inline.
Thanks
Santosh

 
On 2/24/06, = Sushma Venkatesh <sushma@uwm.edu> wrote:
As per section 13.2 in RFC 2328,= receipt of a router or network LSA with
changed
contents leads to re= calculation of entire routing table.

As per section 16 in RFC 2328, the routing table calculation involv= es:

(1)Dijkstra calculation for each attached area considering only = the links

between routers and transit networks.
(2)Stub networks = are incorporated into the area trees by going through th
e
router LSA of each reachable router again.
(3)All the summary L= SAs are examined to calculate inter-area routes.
(4) All AS-external LSA= s are examined to calculate routes to external
destinations.

Questions for the group:
(1)Clearly, depending on the number of summary = and ASE LSAs, the routing
table
update may take much longer than simp= le dijkstra calculations of all atta
ched
areas. There exist some stu= dies (Shaikh 2001, Basu 2001) that attribute t
imes
of the order of tens of milliseconds to dijkstra calculations b= ased on th
e
number of routers in the area.  Are you aware = of any studies that
experimentally measure or model the time spent in do= ing routing table upd
ates?
Are their any studies or rules of thumb to estimate the time s= pent examin
ing
the summary and ASE LSAs? Is it reasonable to assume = that the time spent
examining the summary/ASE LSAs is linear in terms of= the number of such L
SAs?
 
San>>
a) The time spent examining the summary LSAs depends upon the typ= e of OSPF router. OSPF ABR calculates routes for backbone summary LSAs as w= ell generates summary LSA for these routes to be flooded into other no= n backbone areas. OSPF router internal to any area will only calculate the = routes for these=20 LSAs.So it takes linear time in terms of number of LSAs on a particular typ= e of OSPF router.
b) External LSA will take linear time in terms of number of LSAs.
Thuogh i never measured in terms of time this calculation.

 
(2)Is it reasonable to assume th= at modern routers perform the complete ro
uting
table update followin= g the receipt of a changed router/network LSA as ONE

activity WITHOUT PREEMPTION? Or are they likely to split the comple= te rou
ting
table update process in multiple parts and perform them a= s time permits?
San>>
i know atleast one implementation where its splits the routing table c= alculations into three parts:
1. Intra-area calculations(Dijkstra calculation ) for all areas and st= arts a timer for inter-area calculation.
<< preemption can occur here >>
2. Inter-area calculations and it will start a timer of external-route= calculations
<< preemption can occur here>>
3. External route calculations
 
------=_Part_1058_15640779.1141037490944-- From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 27 09:21:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDjFI-0001zm-D5 for ospf-archive@LISTS.IETF.ORG; Mon, 27 Feb 2006 09:21:04 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDjFF-0003ju-UE for ospf-archive@LISTS.IETF.ORG; Mon, 27 Feb 2006 09:21:04 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <14.00037693@wildebeest.ease.lsoft.com>; Mon, 27 Feb 2006 9:21:01 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100490709 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 27 Feb 2006 09:21:01 -0500 Received: from 192.93.2.39 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 27 Feb 2006 09:11:00 -0500 Received: from [192.168.112.240] (sphinx.lix.polytechnique.fr [129.104.11.1]) (authenticated bits=0) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k1REAssc030233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Feb 2006 15:10:55 +0100 User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------070100040105010504080803" X-j-chkmail-Score: MSGID : 4403086E.000 on concorde : j-chkmail score : X : 0/20 1 X-Miltered: at concorde with ID 4403086E.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! Message-ID: <440307DE.2020205@inria.fr> Date: Mon, 27 Feb 2006 15:08:30 +0100 Reply-To: Mailing List Sender: Mailing List From: Emmanuel Baccelli Subject: OSPF extension for MANETs Comments: To: ospf-manet@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4a955ed4836bdb04ff716e03eb01a065 This is a multi-part message in MIME format. --------------070100040105010504080803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, as discussed, here is a contribution to OSPF extension for MANETs, incorporating MPR mechanisms for flooding overhead reduction and adjacency reduction. Emmanuel --------------070100040105010504080803 Content-Type: text/plain; name="draft-baccelli-ospf-mpr-ext.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-baccelli-ospf-mpr-ext.txt" Open Shortest Path (OSPF) E. Baccelli Internet-Draft HITACHI Labs Europe Expires: August 31, 2006 T. Clausen LIX, Ecole Polytechnique, France P. Jacquet Project Hipercom, INRIA February 27, 2006 OSPF MPR Extension for Ad Hoc Networks draft-baccelli-ospf-mpr-ext-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 31, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This draft describes an OSPF extension taylored for MANETs. This extension leverages the techniques that were developed by the IETF MANET working group. No currently existing OSPF interface type corresponds to MANET characteristics, therefore this extension consists in the design of an OSPF interface type, called the OSPF Baccelli, et al. Expires August 31, 2006 [Page 1] Internet-Draft OSPF MPR Extension for MANET February 2006 wireless interface. OSPF's functionning over the wireless interface is inspired from its functionning on broadcast interfaces, which, combined with MPR mechanisms from the MANET working group, provides for OSPF efficient operation over MANETs. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 8 5.1 MPR Selection over OSPF Wireless Interfaces . . . . . . . 8 5.1.1 MPR Selection Heuristics . . . . . . . . . . . . . . . 9 5.1.2 MPR Selection Signalling . . . . . . . . . . . . . . . 10 5.1.3 MPR Selection Information Repositories . . . . . . . . 11 5.2 Adjacencies over OSPF Wireless Interfaces . . . . . . . . 12 5.3 Flooding Operation over OSPF Wireless Interfaces . . . . . 12 5.4 Acknowledging over OSPF Wireless Interface . . . . . . . . 14 6. Interaction with Other OSPF Interface Types . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 A. Usage of Link Local Signaling . . . . . . . . . . . . . . . . 20 A.1 MPR Selection Signalling with LLS . . . . . . . . . . . . 21 B. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 C. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . 25 Baccelli, et al. Expires August 31, 2006 [Page 2] Internet-Draft OSPF MPR Extension for MANET February 2006 1. Introduction Mobile Ad hoc Networks (MANETs [3]) have attracted considerable attention over the last decade, both in academic and industrial envi- ronments. MANETs were initially designed as networks isolated from the Internet (at most, MANETs would be connected via a gateway), and the main challenge was that of providing efficient routing within these networks, as the new characterics (such as the dynamic topol- ogy) implied by ad hoc connectivity made traditional solutions inap- propriate. MANET routing solutions have been the subject of intensive attention from the IETF in the recent years, and have been exten- sively experimented in various scenarii including actual deployments. In order to integrate MANET routing with other Internet routing, this document specifies a wireless extension for OSPFv3 enabling router ad hoc mobility. In order to guarantee full compatibility with legacy OSPF, a natural solution is to base this extension the proactive MANET routing approach, since OSPF is itself proactive. This draft therefore introduces a wireless extension for OSPF inspired from the proactive MANET routing protocol OLSR [1] [2]. This document speci- fies a new OSPF interface, taylored for wireless ad hoc networks: the OSPF wireless interface type. Baccelli, et al. Expires August 31, 2006 [Page 3] Internet-Draft OSPF MPR Extension for MANET February 2006 2. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. Additionally, this document uses the following terminology: o Node: a device, capable of routing. o Wireless Interface: the OSPF interface type for MANETs, speci- fied in this document. o Wireless Node: a node which has only wireless interface(s). o Wired Node: a node which has only traditional OSPF inter- face(s). o Hybrid Node: a node which has both traditional and wireless interfaces. o Wireless Neighbor: a neighbor, reachable through a wireless interface. o Symmetric Neighbor: a neighbor, in a state greater than or equal to ExStart or 2-Way. o Neighborhood of a Node: the set formed by the nodes to which this node has a link. o 2-Hop Neighborhood of a Node: the set formed by the union of the neighborhoods of the neighbors of this node (excluding this node itself, and its neighborhood). o Synch Node: a node which brings up adjacencies with all its wireless neighbors. Baccelli, et al. Expires August 31, 2006 [Page 4] Internet-Draft OSPF MPR Extension for MANET February 2006 3. Applicability Statement This draft describes an extension of the OSPFv3 routing protocol for ad hoc networks. An interface type is designed, adapted to this spe- cific network type. While this extension enables OSPF to function efficiently on MANETs, it does not change in any way the functionning of OSPF on other types of interfaces or networks. The OSPF wireless interface type enables OSPF operation over mobile wireless networks, that may partition of merge depending on the dynamic topology of routers. Baccelli, et al. Expires August 31, 2006 [Page 5] Internet-Draft OSPF MPR Extension for MANET February 2006 4. Protocol Overview and Functioning This section describes an extension to OSPFv3 for MANETs, inspired by techniques from OLSR [1] [2]. The wireless interface type, described in this document captures the specific characteristics of MANETs, sporting "half-broadcast" capabilities (i.e. a node that makes a transmission on a MANET can only assume that a subset of the nodes attached to the MANET will hear this transmission). The OSPF wireless interface's functionning is inspired from how OSPF functions on broadcast interfaces, which, combined with MPR mecha- nisms, provides for OSPF operation over MANETs. OSPF operation on wireless interace pursues the same goals as on broadcast interfaces: reduce the number of superflueous adjacencies, and reduce the number of superfluous retransmission of routing packets. However, these goals are reached using modified mechanisms with regards to flooding, adjacency formation and acknowledging opera- tions. These modifications are effective only in wireless ad hoc parts of the OSPF network and does not impact in any way other parts of the OSPF network. OSPF operation remains thus unaltered over other types of OSPF interfaces, whether there are OSPF wireless interfaces in the network, or not. Similarly to OSPF functionning on broadcast networks, nodes will only form adjacencies with a subset of its wireless neighbors. However, no Designated Router or Backup Designated Router are elected on an OSPF MANET. Instead, adjacencies are simply formed between MPR and MPR Selectors, and only some select nodes (called Synch nodes) bring up adjacencies with all their wireless neighbors. Doing this greatly reduces the amount of control traffic needed for OSPF to function, while keeping OSPF's traditional properties: robust routing and opti- mal paths using synchronized adjacencies. Wireless and hybrid nodes periodically generate and flood Router-LSAs describing their adjacencies with their wireless neighbors. Wireless adjacencies are advertized as point-to-point links to (current) wire- less neighbors. Wireless interfaces also enforce efficient flooding. The goal is the same as on broadcast interfaces: to reduce the number of superfluous retransmissions. However the implementation of this semantic on OSPF wireless interfaces differs from that on OSPF broadcast interfaces: over wireless interfaces, MPR flooding is enforced, i.e. only some wireless neighbors (those selected as MPR) are responsible for retransmitting a routing packet flooded over a wireless interface. MPR flooding is an essential feature for OSPF to function correctly in a wireless ad hoc environment. This technique provides a natural Baccelli, et al. Expires August 31, 2006 [Page 6] Internet-Draft OSPF MPR Extension for MANET February 2006 high resilience to transmission errors (inherent to the use of wire- less links), and obsolete two-hop neighbor information (frequently caused by the mobility of the nodes). Finally, in order to further reduce the number of transmissions over wireless interfaces, LSA acknowledgements are sent via multicast over these interfaces, and retransmissions over the same interfaces are considered as implicit acknowledgements. Intelligent jitter manage- ment delaying packets' (re)transmissions may be used to increase the chance to bundle several packets in a single transmission, or to avoid superfluous retransmissions. The following sections detail these specific mechanisms. Baccelli, et al. Expires August 31, 2006 [Page 7] Internet-Draft OSPF MPR Extension for MANET February 2006 5. Protocol Details Each hybrid or wireless node MUST select a subset of its wireless neighbors as MPR, and MUST signal MPR selection to its wireless neighbors. Section 5.1 describes MPR selection and signalling in details. MPR selection is used to determine wether or not to become adjacent with a 2-Way neighbor. MPR selection is also used to determine wether or not to retransmit a neighbor node's broadcasts. This technique, inherited from the proactive MANET routing protocol OLSR [1], drasti- cally reduces control traffic overhead. Adjacency formation is detailed in Section 5.2, before Section 5.3 details LSA flooding over wireless interfaces, and Section 5.4 describes how LSA acknowledgement is managed over wireless inter- faces. 5.1 MPR Selection over OSPF Wireless Interfaces The objective of MPR selection is for a node to select a subset of its neighbors such that a packet, retransmitted by these selected neighbors, will be received by all nodes 2 hops away. This property is called the MPR coverage criterion. The MPR set of a node is com- puted such that, for each interface, it satisfies this criterion. The information required to perform this calculation (i.e. link sensing and neighborhood information) is acquired through the periodic exchange of OSPF HELLO packets. MPRs are computed per wireless interface, by each wireless or hybrid node. The union of the MPR sets of each wireless interface of a node make up the MPR set for this node. While it is not essential that the MPR set is minimal, it is essen- tial that all 2-hop neighbors can be reached through the selected MPR nodes. A node SHOULD select an MPR set such that any 2-hop neighbor is covered by at least one MPR node. Keeping the MPR set small ensures that the overhead of the protocol is kept at a minimum. However, the MPR set can coincide with the entire neighbor set. MPR selection priority may be given to neighbor nodes in descending order of their willingness to be forwarding traffic on behalf of other nodes. Baccelli, et al. Expires August 31, 2006 [Page 8] Internet-Draft OSPF MPR Extension for MANET February 2006 5.1.1 MPR Selection Heuristics The following specifies a proposed heuristic for selection of MPRs. It constructs an MPR-set that enables a node to reach nodes in the 2-hop neighborhood through relaying by one MPR node. The heuristic should be applied per interface, I. The MPR set for a node is the union of the MPR sets found for each interface. The following termi- nology will be used in describing the heuristics: Neighbor of an interface: A node is a "neighbor of an interface" if the interface (on the local node) has a link to any one interface of the neighbor node. N: N is the set of symmetric neighbors of the node (i.e. neighbors in a state greater than or equal to ExStart or 2-Way), which are neighbor of the interface I. N2: The set symmetric neighbors of nodes in N (i.e. 2-hop neighbors), excluding: (i) the node performing the computation (ii) all the nodes in N. MPR set of an interface I: A (sub)set of the neighbors selected such that through these selected nodes, all the 2-hop neighbors (that are in N2 for interface I) are reachable. D(y): The degree of a 1-hop neighbor node y (where y is a member of N), is defined as the number of neighbors of node y, EXCLUDING all the members of N and EXCLUDING the node performing the computation. The proposed heuristic can then be described as follows, for each wireless interface: Baccelli, et al. Expires August 31, 2006 [Page 9] Internet-Draft OSPF MPR Extension for MANET February 2006 1 Calculate D(y), where y is a member of N, for all nodes in N. 2 Add to the MPR set those nodes in N, which are the *only* nodes to provide reachability to a node in N2. For example, if node b in N2 can be reached only through a node a in N, then add node a to the MPR set. Remove the nodes from N2 which are now covered by a node in the MPR set. 3 While there exist nodes in N2 which are not covered by at least one node in the MPR set: 3.1 For each node in N, calculate the reachability, i.e. the number of nodes in N2 which are not yet covered by at least one node in the MPR set, and which are through this 1-hop neighbor; 3.2 Select as a MPR the neighbor with highest willingness among the nodes in N with non-zero reachability. In case of a tie among nodes with same willingness the node which provides reachability to the maximum number of nodes in N2. In case of another tie between nodes also providing the same amount of reachability, select as MPR the node whose D(y) is greater. Remove the nodes from N2 which are now covered by a node in the MPR set. 4 A node's MPR set is generated from the union of the MPR sets for each interface. As an optimization, process each node, y, in the MPR set in increasing order of willingness. If all nodes in N2 are still covered by at least one node in the MPR set excluding node y, then node y MAY be removed from the MPR set. Other algorithms, as well as improvements over this algorithm, are possible. Different nodes may use different algorithms independently. The only requirement is that the algorithm used by a given node MUST provide the node with an MPR set that fulfills the MPR coverage cri- terion. 5.1.2 MPR Selection Signalling A node that has selected MPRs among its neighbors MUST signal this selection through appending LLS information at the end of its HELLO packets as described in Appendix A. This information signals the list of neighbors the node has selected as MPR, and the willingness Baccelli, et al. Expires August 31, 2006 [Page 10] Internet-Draft OSPF MPR Extension for MANET February 2006 of the node to be forwarding traffic on behalf of other nodes. Moreover, neighbors listed in the HELLO packets sent over wireless interfaces MUST be listed in a specific order: symmetric neighbors (i.e. in a state greater than or equal to ExStart or 2-Way) MUST be listed first. The number of symmetric neighbors is also signalled in the LLS information appended to the HELLO packet, as described in Appendix A. Any neighbor that is not symmetric (i.e. in a state lower than ExStart or 2-Way) MUST be listed after ALL symmetric neighbors. 5.1.3 MPR Selection Information Repositories Each wireless or hybrid node also maintains a set called the "Wire- less 2-Hop Neighbors Set". This set keeps information about a node's symmetric neighbors two hops away. The set lists tuples (2_HOP_SYM_addr, 1_HOP_SYM_addr, LOCAL_if, 2_HOP_SYM_time). 2_HOP_SYM_addr is the address of a symmetric neighbor 2-hops away. 1_HOP_SYM_addr is the address of the symmetric neighbor through which the 2-hop neighbor can be reached. LOCAL_if is the address of the local interface of the node, through which the 1-hop neighbor can be reached. 2_HOP_SYM_time specifies the time at which the tuple expires and *MUST* be removed from the set. Each wireless or hybrid node maintains a set called the "Wireless Neighbors Set". This set keeps information about a node's symmetric neighbors two hops away. The set lists tuples (1_HOP_SYM_addr, LOCAL_if, 1_HOP_SYM_time). 1_HOP_SYM_addr is the address of a symmet- ric neighbor of the node. LOCAL_if is the address of the local inter- face of the node, through which the neighbor can be reached. 1_HOP_SYM_time specifies the time at which the tuple expires and *MUST* be removed from the set. The wireless neighbors and 2-hop neighbors sets are updated when received HELLO packets signal changes in the neighborhood. In addition, each wireless or hybrid node maintains a set called the "MPR Set". This set lists the addresses of the neighbors selected as MPR by the node. The MPR set is updated by the algorithm described in Section 5.1.1, which is used as soon as the node detects a change in its wireless neighbors, or 2-hop neighbors sets. At the end of this procedure new MPRs may be added to the set, and formerly selected nodes are removed from the set. Similarly, each wireless or hybrid node also maintains a set called the "MPR Selector Set". This set lists tuples (MPRS_addr, MPRS_time), describing the neighbors which have selected this node as a MPR. MPRS_addr is the address of a neighbor, which has selected Baccelli, et al. Expires August 31, 2006 [Page 11] Internet-Draft OSPF MPR Extension for MANET February 2006 this node as MPR. MPRS_time specifies the time at which the tuple expires and *MUST* be removed from the set. The MPR set is updated upon receipt of LLS information in which the recipient is listed as MPR by the originator of the LLS information. 5.2 Adjacencies over OSPF Wireless Interfaces In order to reduce the control traffic overhead on the wireless medium, nodes do not bring up adjacencies with all their wireless neighbors. This is similar to broadcast interfaces, over which a node forms adjacencies only with the Designated Router and the Backup Designated Router. Over a wireless interface, a node brings up adjacencies only with the neighbors it has included in its MPR set and its MPR Selector set. However, some nodes (called synch nodes) bring up adjacencies with all their wireless neighbors. This ensures that the adjacencies over the whole OSPF network contain the shortest paths, even with not all adjacencies being formed (see [8] [10]). A node decides it is a synch node if and only if: o the node is a hybrid node, OR o the node is a wireless node that has the highest willingness in its neighborhood (in case of ties, the node that also has the greatest Router ID is elected). When a node does not form an adjacency with a wireless neighbor, the state of this neighbor will be 2-Way (instead of FULL, for an adja- cent neighbor). Contrary to other types of interfaces, over a wire- less interface routing packets may also be sent over 2-Way links. Therefore, any routing packet received from a wireless neighbor in a state greater than or equal to ExStart or 2-Way MUST be processed. Similarly to the broadcast interface, the next hop in the forwarding table may be a neighbor that is not adjacent. However, when a packet is further than its first hop, the MPR selection process guarantees that the next hop in the SPT will be over an adjacency. 5.3 Flooding Operation over OSPF Wireless Interfaces Flooding operation is modified over wireless interfaces. However, note that flooding runs unaltered over all other types of OSPF inter- faces. If an LSU was received on an interface of a type other than wireless, its processing and the flooding procedure go on as speci- fied in [4] and [6], over every interface (wireless or not). If an LSU was received on a wireless interface, it is processed as follows, with regards to flooded LSAs. Baccelli, et al. Expires August 31, 2006 [Page 12] Internet-Draft OSPF MPR Extension for MANET February 2006 Note that, as specified in [4] and [6], consistency checks have been made on the received packet before being handed to the modified flooding procedure described in the following, and the Link State Update packet has thus been associated with a particular neighbor and a particular area. The principle is that a node A will consider flooding retransmission of an LSA it has received on a wireless interface from a neighbor B only if node B has signalled an MPR set including node A. If this is not the case, node A will suppress its wireless retransmission of LSAs flooded by node B (since its retransmissions are superfluous). The following details the exact changes to the usual OSPFv3 specifi- cations (i.e. section 13.3 of [4] and section 3.5 of [6]) for flood- ing decisions on wireless interfaces. If the LSU was not received from a neighbor in a state greater than or equal to ExStart or 2-Way, the LSU MUST be discarded without fur- ther processing. Else, for each LSA contained in LSUs received on wireless interfaces, the following steps replace steps 1 to 5 of sec- tion 13.3 of [4]. 1 If there exists an LSA in the Link State Database, with the same Link State ID, LS Type and Advertizing Router values, and the LSA is not newer (see section 13.1 of [4]) then the LSA MUST not be processed EXCEPT for acknowledgement as described in section 5.4. 2 Otherwise, the LSA MUST be forwarded according to the scope of the LSA type (see section 3.5 of [6]). 3 Flooding scope condition: 3.1 If the scope of the LSA is link local or reserved, the LSA MUST not be forwarded on any interface. 3.2 Otherwise: 3.2.1 If the scope of the LSA is the area, the LSA MUST be forwarded on all the interfaces of the node in that area according to the default forwarding algorithm described below. 3.2.2 Otherwise, the LSA MUST be forwarded on all the interfaces of the node according to the default forwarding algorithm described below. Baccelli, et al. Expires August 31, 2006 [Page 13] Internet-Draft OSPF MPR Extension for MANET February 2006 The default forwarding algorithm is then the following: 1 The LSA MUST be installed in the Link State Database. 2 The Age of the LSA is increased by InfTransDelay. 3 The LSA is flooded over all non-wireless interfaces. 4 If the sender interface address is an interface address of an MPR selector of this node, the LSA MUST also be retransmitted out all wireless interfaces concerned by the scope, with the multicast address all_SPF_Routers. Note that MinLSArrival should be set to a value that is appropriate to MANET dynamic topologies: LSA updating may need to be more fre- quent in MANET parts of the OSPF network than in traditional parts of the OSPF network. 5.4 Acknowledging over OSPF Wireless Interface When a node receives an LSA on a wireless interface, the node MUST proceed to acknowledge the LSA as follows Baccelli, et al. Expires August 31, 2006 [Page 14] Internet-Draft OSPF MPR Extension for MANET February 2006 1 If the LSA is already in the database (i.e. the LSA has already been received) and it is received from a non-adjacent neighbor, the node MUST NOT acknowledge it. 2 If the LSA is already in the database (i.e. the LSA has already been received) and it is received from an adjacent neighbor, the node MUST send an acknowledgement for this LSA on all wireless interfaces, to the multicast address all_SPF_Routers. 3 If the LSA is not already in the database (i.e. the LSA has not already been received) and it decides to retransmit it (as part of the flooding procedure), the node MUST NOT acknowledge it, as this retransmission will be considered as an implicit acknowledgement. 4 If the LSA is not already in the database (i.e. the LSA has not already been received) and it decides to not retransmit it (as part of the flooding procedure), the node MUST send an acknowledgement for this LSA on all wireless interfaces, to the multicast address all_SPF_Routers. If a node sends an LSA on a wireless interface, it expects acknowledgements (explicit or implicit) from each adjacent neighbors. In the case where the node did not originate the LSA (i.e. relays the LSA), the node MUST only expect acknowledgements (explicit or implicit) from adjacent neighbors that have not previously acknowledged this LSA. If a node detects that some adjacent neighbor has not acknowledged the LSA, the node retransmits the LSA. If, due to efficient flooding procedure decision, a node decides to not relay an LSA, the node MUST still expect acknowledgements of that LSA (explicit or implicit) from adjacent neighbors that have not previously acknowledged this LSA. If a node detects that some adjacent neighbor has not aclnowledged the LSA, the node retransmits the LSA. Note that it may be beneficial to aggregate several acknowledgements in the same transmission (taking advantage of the multicasting). A timer wait MAY thus be used before any acknowledgement transmission in order to to avoid superfluous retransmissions. Baccelli, et al. Expires August 31, 2006 [Page 15] Internet-Draft OSPF MPR Extension for MANET February 2006 Additional jitter delay in packet (re)transmission may be used in order to increase the opportunities to bundle several packets together per transmission (which provides a reduction in the number of overall transmissions, and therefore the number of collisions over the wireless media). Baccelli, et al. Expires August 31, 2006 [Page 16] Internet-Draft OSPF MPR Extension for MANET February 2006 6. Interaction with Other OSPF Interface Types OSPF operation remains unaltered over other types of OSPF interfaces, wether there are OSPF wireless interfaces in the network, or not. The difference in flooding, adjacency formation and acknowledging opera- tions described above is effective only in wireless ad hoc parts of the OSPF network and does not impact in any way on other parts of the OSPF network. In wireless ad hoc parts of the OSPF network, routing is performed over synchronized adjacencies, as in usual OSPF. This way, the same properties of robusteness (shortest and loop-free paths) are still garanteed throughout the whole OSPF network wether there are OSPF wireless interfaces in the network, or not. Baccelli, et al. Expires August 31, 2006 [Page 17] Internet-Draft OSPF MPR Extension for MANET February 2006 7. Security Considerations This document does currently not specify security considerations. Baccelli, et al. Expires August 31, 2006 [Page 18] Internet-Draft OSPF MPR Extension for MANET February 2006 8. IANA Considerations This document does currently not specify IANA considerations. Authors' Addresses Emmanuel Baccelli HITACHI Labs Europe Phone: +33 1 69 33 55 11 Email: baccelli@eurecom.fr Thomas Heide Clausen LIX, Ecole Polytechnique, France Phone: +33 6 6058 9349 Email: T.Clausen@computer.org URI: http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/ Philippe Jacquet Project Hipercom, INRIA Phone: +33 1 3963 5263 Email: Philippe.Jacquet@inria.fr Baccelli, et al. Expires August 31, 2006 [Page 19] Internet-Draft OSPF MPR Extension for MANET February 2006 Appendix A. Usage of Link Local Signaling Nodes may set a flag, called L (L for LLS), in the OSPFv3 packets Options field (see [6]) which indicates that the packet contains LLS data block (see [14]). With LLS, nodes may append a data block containing arbitrary informa- tion at the end of OSPFv3 packets. The length of the data block is not included in the OSPFv3 packet length field, but is included in the IP packet length, as shown below. +---------------------+ -- ^ | IPv6 Header | ^ | | Length = X+Y+Z | | Z = IPv6 Header Length | | | v | +---------------------+ -- | | OSPFv3 Header | ^ | | Length = X | | IP | |.....................| | X = OSPF Packet Length Packet | | | | | | OSPFv3 Data | | | | | v | +---------------------+ -- | | | ^ | | LLS Data Block | | Y = LLS Data Block Length V | | v +---------------------+ Fig. 1 : OSPFv3 and LLS data block in an IPv6 Packet In order to provision for different uses of the LLS, the type length value (TLV) format is used for the LLS datablock, as shown below in Fig. 2 and Fig. 3. An LLS header (checksum and length of the LLS dat- ablock) is followed by a number of TLV blocks. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | LLS Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | TLV Blocks | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Baccelli, et al. Expires August 31, 2006 [Page 20] Internet-Draft OSPF MPR Extension for MANET February 2006 Fig. 2 : LLS datablock header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig. 3 : TLV Block format Appendix A.1 MPR Selection Signalling with LLS The Hello packets sent over an OSPF wireless interface have the L bit set. An LLS datablock containing MPR selection information is appended to these Hello messages. The TLV of Type 0 is defined as the MPR selection TLV type shown in Fig. 4. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Willingness | # Sym. Neigh. | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : : | Addresses of Neighbors Selected as MPR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig. 4 : MPR selection TLV Baccelli, et al. Expires August 31, 2006 [Page 21] Internet-Draft OSPF MPR Extension for MANET February 2006 Willingness: This field specifies the willingness of a node to carry and forward traffic for other nodes. It can be set to any integer value from 1 to 6. By default, a node SHOULD advertise a willingness of WILL_DEFAULT = 3. # Sym. Neigh. : Number of symmetric neighbors, i.e. the number of neighbors, listed first in the HELLO packet, that are in a state greater than or equal to ExStart or 2-Way. These neighbors are then considered in MPR selection mechanisms. Reserved: This field must be set to "000000000000000000000" to be in compliance with this specification. Addresses of Neighbors Selected as MPR: Concatenation of successive IPv6 addresses of neighbors selected as MPR by the node. Baccelli, et al. Expires August 31, 2006 [Page 22] Internet-Draft OSPF MPR Extension for MANET February 2006 Appendix B. References [1] T. Clausen, P. Jacquet, RFC 3626: Optimized Link State Routing Pro- tocol. 2003. [2] OLSRv2 Design Team, Optimized Link State Routing Protocol version 2, Internet Draft draft-ietf-manet-olsrv2-00, July 2005. [3] S. Corson, J. Macker, RFC 2501: Mobile Ad hoc Networking (MANET), Routing Protocol Performance Issues and Evaluation Considerations, 1999. [4] J. Moy, RFC 2328: OSPF version 2, 1998. [5] J. Moy, OSPF, Anatomy of an Internet Routing Protocol, Addison-Wes- ley, 1998. [6] R. Coltun, D. Ferguson, J. Moy, RFC 2740: OSPF for IPv6, 1999. [7] E. Baccelli, T. Clausen, P. Jacquet, Ad-hoc and Internet Conver- gence: Adapting OSPF-style Database Exchanges for Ad-hoc Networks, Proceedings of the Conference on Performance Modelling and Evalua- tion of Heterogeneous Networks (HET-NETs), Oct. 2004. [8] A. Qayyum, L. Viennot, A. Laouiti, Multipoint Relaying: An Efficient Technique for Flooding in Mobile Wireless Networks, INRIA Research Report RR-3898, March 2000. [9] C. Adjih, P. Jacquet, L. Viennot, Computing Connected Dominating Sets with Multipoint Relays, INRIA Research Report RR-4597, 2002. [10] P. Jacquet, A. Laouiti, P. Minet, L. Viennot, Performance Evalua- tion of Multipoint Relaying in Mobile Ad Hoc Networks, Proceedings of the Networking International Conference, 2002. [11] J. Ahrenholz, E. Baccelli, T. Clausen, T. Henderson, P. Jacquet, P. Spagnolo, OSPFv2 Wireless Interface Type, Internet Draft draft- spagnolo-manet-ospf-wireless-interface-01.txt, May 2004. [12] R. Ogier, MANET Extension of OSPF using CDS Flooding, Internet Draft draft-ogier-manet-ospf-extension-05, 2005. [13] M. Chandra et al. Extensions to OSPF to Support Mobile Ad Hoc Net- working, Internet Draft draft-chandra-ospf-manet-ext-03, 2005. [14] A. Zinin, B. Friedman, A. Roy, L. Nguyen, D. Yeung, OSPF Link Local Signaling, Internet Draft draft-nguyen-ospf-lls-04, 2004. Baccelli, et al. Expires August 31, 2006 [Page 23] Internet-Draft OSPF MPR Extension for MANET February 2006 Appendix C. Contributors Cedric Adjih, Project HIPERCOM, INRIA Rocquencourt, BP 105, 78153 Le Chesnay Cedex, France, Phone: +33 1 3963 5263, Email: Cedric.Adjih@inria.fr Laurent Viennot, Project Gyroweb, INRIA Rocquencourt, BP 105, 78153 Le Chesnay Cedex, France, Phone: +33 1 3963 5263, Email: Laurent.Viennot@inria.fr Baccelli, et al. Expires August 31, 2006 [Page 24] Internet-Draft OSPF MPR Extension for MANET February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Baccelli, et al. Expires August 31, 2006 [Page 25] --------------070100040105010504080803-- From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 27 11:07:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDkuG-00031y-CM for ospf-archive@LISTS.IETF.ORG; Mon, 27 Feb 2006 11:07:28 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDkuG-0000Fm-08 for ospf-archive@LISTS.IETF.ORG; Mon, 27 Feb 2006 11:07:28 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <15.000376BA@wildebeest.ease.lsoft.com>; Mon, 27 Feb 2006 11:00:45 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100493424 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 27 Feb 2006 11:00:45 -0500 Received: from 207.17.137.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 27 Feb 2006 11:00:41 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k1RG0dX85675 for ; Mon, 27 Feb 2006 08:00:39 -0800 (PST) (envelope-from dkatz@juniper.net) Received: from [172.16.12.53] ([172.16.12.53]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k1RG0W561470 for ; Mon, 27 Feb 2006 08:00:33 -0800 (PST) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v746.2) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.746.2) Message-ID: <64C806B8-3EEA-4CD2-A5EB-0D52933209A7@juniper.net> Date: Mon, 27 Feb 2006 08:00:30 -0800 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: Question about routing table update To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe On Feb 23, 2006, at 3:42 PM, Sushma Venkatesh wrote: > > (1)Clearly, depending on the number of summary and ASE LSAs, the > routing > table > update may take much longer than simple dijkstra calculations of > all atta > ched > areas. There exist some studies (Shaikh 2001, Basu 2001) that > attribute t > imes > of the order of tens of milliseconds to dijkstra calculations based > on th > e > number of routers in the area. Are you aware of any studies that > experimentally measure or model the time spent in doing routing > table upd > ates? > Are their any studies or rules of thumb to estimate the time spent > examin > ing > the summary and ASE LSAs? Is it reasonable to assume that the time > spent > examining the summary/ASE LSAs is linear in terms of the number of > such L > SAs? The reality in many networks is much larger than this. In transit networks, OSPF is basically calculating next hops for hundreds of thousands of BGP routes. The actual OSPF part of the process is in the noise; a single route change can result in a next hop change for a gazillion routes. This is where the real work happens. In practice, SPF calculations take inconsequential time for practical networks, even very large ones, and all of the work in partial Dijkstras and such is pretty much just academic. Networks large enough for the SPF calculation to take a significant amount of time (more than milliseconds) tend to be impractical for other reasons. > (2)Is it reasonable to assume that modern routers perform the > complete ro > uting > table update following the receipt of a changed router/network LSA > as ONE > > activity WITHOUT PREEMPTION? Or are they likely to split the > complete rou > ting > table update process in multiple parts and perform them as time > permits? There are many ways of going about it. Obviously a completely nonpreemptive environment can cause trouble if Hellos aren't being sent while the box is off calculating routes (as many implementors found out as networks started to grow.) The only architectural requirement is that the LSDB remains consistent while the SPF is being calculated, which means some fancy footwork if you're going to continue to send and receive anything other than Hello packets. (And Hellos have to go out as scheduled.) --Dave From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 27 15:45:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDpFL-0003RA-NF for ospf-archive@LISTS.IETF.ORG; Mon, 27 Feb 2006 15:45:31 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDpFK-0001Nu-Fg for ospf-archive@LISTS.IETF.ORG; Mon, 27 Feb 2006 15:45:31 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <13.00037A88@wildebeest.ease.lsoft.com>; Mon, 27 Feb 2006 15:45:29 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100528620 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 27 Feb 2006 15:45:27 -0500 Received: from 207.69.195.67 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 27 Feb 2006 15:45:26 -0500 Received: from h-68-164-155-88.snvacaid.dynamic.covad.net ([68.164.155.88] helo=earthlink.net) by pop-tawny.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1FDpFF-00053H-00 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 27 Feb 2006 15:45:25 -0500 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <44036872.5D0F7F61@earthlink.net> Date: Mon, 27 Feb 2006 13:00:34 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Question about routing table update To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Sushma Venkatesh, Alot of questions.. Let me give you some common sense answers. If a changed network LSA is larger than the previous instance then we should be also expecting new router LSAs. Would it make sense to process the network or the router LSA separately wrt the SPF calc? Also if most LSAs recieved are just refreshes, then pre-empting the SPF calc should not be an issue. The reason for doing this COULD be to process incoming refresh LSAs so you can simply prevent tail drops wrt the in buffer for OSPF control pkts. The amount of time for the SPF calc that also includes routing table updates is dependent on too many factors to estimate. Mitchell Erblich ------------------ Sushma Venkatesh wrote: > > As per section 13.2 in RFC 2328, receipt of a router or network LSA with changed > contents leads to recalculation of entire routing table. > > As per section 16 in RFC 2328, the routing table calculation involves: > > (1)Dijkstra calculation for each attached area considering only the links > between routers and transit networks. > (2)Stub networks are incorporated into the area trees by going through the > router LSA of each reachable router again. > (3)All the summary LSAs are examined to calculate inter-area routes. > (4) All AS-external LSAs are examined to calculate routes to external > destinations. > > Questions for the group: > (1)Clearly, depending on the number of summary and ASE LSAs, the routing table > update may take much longer than simple dijkstra calculations of all attached > areas. There exist some studies (Shaikh 2001, Basu 2001) that attribute times > of the order of tens of milliseconds to dijkstra calculations based on the > number of routers in the area. Are you aware of any studies that > experimentally measure or model the time spent in doing routing table updates? > Are their any studies or rules of thumb to estimate the time spent examining > the summary and ASE LSAs? Is it reasonable to assume that the time spent > examining the summary/ASE LSAs is linear in terms of the number of such LSAs? > (2)Is it reasonable to assume that modern routers perform the complete routing > table update following the receipt of a changed router/network LSA as ONE > activity WITHOUT PREEMPTION? Or are they likely to split the complete routing > table update process in multiple parts and perform them as time permits? From owner-ospf@PEACH.EASE.LSOFT.COM Mon Feb 27 22:55:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDvxr-00018z-Rh for ospf-archive@LISTS.IETF.ORG; Mon, 27 Feb 2006 22:55:55 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDvxr-0002xj-Ix for ospf-archive@LISTS.IETF.ORG; Mon, 27 Feb 2006 22:55:55 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <4.00038226@wildebeest.ease.lsoft.com>; Mon, 27 Feb 2006 22:55:55 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100556809 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 27 Feb 2006 22:55:55 -0500 Received: from 57.66.76.5 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 27 Feb 2006 22:55:54 -0500 Received: from huawei.com ([172.24.2.3]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IVD006KIOBR6N@lhrga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 28 Feb 2006 03:28:40 +0000 (GMT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IVD007BGPIH8M@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 28 Feb 2006 11:54:17 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IVD0059OPIHSB@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 28 Feb 2006 11:54:17 +0800 (CST) Received: from k49110 ([10.111.12.97]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IVD006HNPM2PW@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 28 Feb 2006 11:56:27 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <43F63D76.4030009@cisco.com> <000b01c635cb$cddcca30$610c6f0a@china.huawei.com> <43F9DD10.8040305@cisco.com> <001601c636e4$5ea03980$610c6f0a@china.huawei.com> <43FCDA9B.9050307@cisco.com> <000701c63928$9908e590$610c6f0a@china.huawei.com> <43FF13BB.9030903@cisco.com> Message-ID: <000801c63c19$3121b760$610c6f0a@china.huawei.com> Date: Tue, 28 Feb 2006 11:43:51 +0800 Reply-To: Mailing List Sender: Mailing List From: Zengjie Kou Subject: Re: draft-kou-ospf-immediately-replying-hello-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Hi, Acee On p2p networks, there is no distinction between first coming or coming back up. The immediate hello is efficient in discover neighbors and convergence. On broadcast networks, when an interface first coming, DR election need to wait wait-time. However, when an interface coming back up, DR election need not to wait wait-time(if BDR exists or the down interface is not DR). Here, only HelloInterval or BackupSeen is needed to discover neighbor or convergence. Immediate hello avoids the HelloInterval or backupSeen on the case. Thanks, Zengjie ----- Original Message ----- From: "Acee Lindem" To: Sent: Friday, February 24, 2006 10:10 PM Subject: Re: draft-kou-ospf-immediately-replying-hello-00.txt > Zengjie Kou wrote: > >>Hi, Acee >> The empty hello mechanism that you refered is adopted by most OSPF implementations indeed when an interface first comes up. >>I agree this. However, when an normal interface whose state is up goes down then up, immediate hello is effective by avoiding >>helloInterval or backupSeen. >> >> > Hi Zengjie, > > I don't think there should be a distinction between first coming or > coming back up. > > Thanks, > Acee > >>Thanks, >>Zengjie >> >>----- Original Message ----- >>From: "Acee Lindem" >>To: >>Sent: Thursday, February 23, 2006 5:41 AM >>Subject: Re: draft-kou-ospf-immediately-replying-hello-00.txt >> >> >> >> >>>Zengjie Kou wrote: >>> >>> >>> >>>>Hi, Acee, >>>> You are right, immediate hello does not provide the mechanism of detecting link down fast. But, immediate hello improve to discover neighbors when interface goes down then up. In practice, the requirement is needed. >>>> >>>> >>>> >>>> >>>Hi Zengjie, >>> >>>Speaking strictly in terms of state machines, it seems the interface >>>would lose it's DR/BDR state >>>when it goes down (and cannot send a hello). Wouldn't this scenario be >>>better handled >>>by the empty hello many OSPF implementations send when an interface >>>first comes up? >>> >>>Thanks, >>>Acee >>> >>> >>> >>>>Thanks, >>>>Zengjie >>>> >>>>----- Original Message ----- >>>>From: "Acee Lindem" >>>>To: >>>>Sent: Monday, February 20, 2006 11:15 PM >>>>Subject: Re: draft-kou-ospf-immediately-replying-hello-00.txt >>>> >>>> >>>> >>>> >>>> >>>> >>>>>Hi Zengjie, >>>>> >>>>>Zengjie Kou wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Hi,Acee, >>>>>> If a router interface whose role is changed(e.g.DR goes down), the router will notify all routers about the change by immediate hello. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>This is only when the DR/BDR knows that it is going down or the case >>>>>where the router >>>>>priority is set to 0. >>>>> >>>>>For a router becoming DR/BDR, all the routers should elect the same DR/BDR >>>>>so I don't see how it helps. >>>>> >>>>>Thanks, >>>>>Acee >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>After all router get the change, election will be reprocessed. In contrast to normal hello, immediate hello avoid the backupSeen. >>>>>>Namely, improving convergence. >>>>>> >>>>>>Thanks a lot, >>>>>>Zengjie >>>>>> >>>>>>----- Original Message ----- >>>>>>From: "Acee Lindem" >>>>>>To: >>>>>>Sent: Saturday, February 18, 2006 5:17 AM >>>>>>Subject: draft-kou-ospf-immediately-replying-hello-00.txt >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Hi Zengjie, >>>>>>> >>>>>>>Under what situations does having the router who changed to/from >>>>>>>DR/BDR improve convergence (section 6.2)? Since DR/BDR election >>>>>>>is a distributed algorithm dependent on the calculating routers state, it >>>>>>>seems this won't help in all that many cases. >>>>>>> >>>>>>>Thanks, >>>>>>>Acee >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>>> >> >> >> From owner-ospf@PEACH.EASE.LSOFT.COM Tue Feb 28 07:34:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FE441-0002u7-Gv for ospf-archive@LISTS.IETF.ORG; Tue, 28 Feb 2006 07:34:49 -0500 Received: from wildebeest.ease.lsoft.com ([209.119.0.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FE441-0001G4-67 for ospf-archive@LISTS.IETF.ORG; Tue, 28 Feb 2006 07:34:49 -0500 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <7.00038998@wildebeest.ease.lsoft.com>; Tue, 28 Feb 2006 7:34:46 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 100595038 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 28 Feb 2006 07:34:46 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 28 Feb 2006 07:34:46 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 28 Feb 2006 07:34:45 -0500 X-IronPort-AV: i="4.02,152,1139202000"; d="scan'208"; a="83233447:sNHT34642456" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k1SCYjqM012532 for ; Tue, 28 Feb 2006 07:34:45 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Feb 2006 07:34:45 -0500 Received: from [10.82.240.144] ([10.82.240.144]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Feb 2006 07:34:45 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <43F63D76.4030009@cisco.com> <000b01c635cb$cddcca30$610c6f0a@china.huawei.com> <43F9DD10.8040305@cisco.com> <001601c636e4$5ea03980$610c6f0a@china.huawei.com> <43FCDA9B.9050307@cisco.com> <000701c63928$9908e590$610c6f0a@china.huawei.com> <43FF13BB.9030903@cisco.com> <000801c63c19$3121b760$610c6f0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Feb 2006 12:34:45.0070 (UTC) FILETIME=[5AE00EE0:01C63C63] Message-ID: <44044364.30701@cisco.com> Date: Tue, 28 Feb 2006 07:34:44 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-kou-ospf-immediately-replying-hello-00.txt To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000801c63c19$3121b760$610c6f0a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Zengjie Kou wrote: >Hi, Acee > On p2p networks, there is no distinction between first coming or coming back up. The immediate hello is efficient in discover neighbors and convergence. > On broadcast networks, when an interface first coming, DR election need to wait wait-time. However, when an interface coming back up, DR election need not to wait wait-time(if BDR exists or the down interface is not DR). Here, only HelloInterval or BackupSeen is needed to discover neighbor or convergence. Immediate hello avoids the HelloInterval or backupSeen on the case. > > Hi Zengjie, I think you're saying the hello when the DR/BDR interface state changes is solely for the case when the BDR's interface flaps. Correct? BDR Interface goes down Ex-BDR Interface comes back up Ex-BDR send initial hello ----------------------------> Other Routers on LAN Ex-BDR goes to 2-way <---------------------------- Other Routers Immediate reply New DR/BDR election Triggers election on Ex-BDR <---------------------- New DR/BDR send hello Why not just process the neighbor change event before sending the immediate reply? In other words, perform the new DR/BDR election before the immediate reply hello? Thanks, Acee >Thanks, >Zengjie > > >----- Original Message ----- >From: "Acee Lindem" >To: >Sent: Friday, February 24, 2006 10:10 PM >Subject: Re: draft-kou-ospf-immediately-replying-hello-00.txt > > > > >>Zengjie Kou wrote: >> >> >> >>>Hi, Acee >>> The empty hello mechanism that you refered is adopted by most OSPF implementations indeed when an interface first comes up. >>>I agree this. However, when an normal interface whose state is up goes down then up, immediate hello is effective by avoiding >>>helloInterval or backupSeen. >>> >>> >>> >>> >>Hi Zengjie, >> >>I don't think there should be a distinction between first coming or >>coming back up. >> >>Thanks, >>Acee >> >> >> >>>Thanks, >>>Zengjie >>> >>>----- Original Message ----- >>>From: "Acee Lindem" >>>To: >>>Sent: Thursday, February 23, 2006 5:41 AM >>>Subject: Re: draft-kou-ospf-immediately-replying-hello-00.txt >>> >>> >>> >>> >>> >>> >>>>Zengjie Kou wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Hi, Acee, >>>>> You are right, immediate hello does not provide the mechanism of detecting link down fast. But, immediate hello improve to discover neighbors when interface goes down then up. In practice, the requirement is needed. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>Hi Zengjie, >>>> >>>>Speaking strictly in terms of state machines, it seems the interface >>>>would lose it's DR/BDR state >>>>when it goes down (and cannot send a hello). Wouldn't this scenario be >>>>better handled >>>>by the empty hello many OSPF implementations send when an interface >>>>first comes up? >>>> >>>>Thanks, >>>>Acee >>>> >>>> >>>> >>>> >>>> >>>>>Thanks, >>>>>Zengjie >>>>> >>>>>----- Original Message ----- >>>>>From: "Acee Lindem" >>>>>To: >>>>>Sent: Monday, February 20, 2006 11:15 PM >>>>>Subject: Re: draft-kou-ospf-immediately-replying-hello-00.txt >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Hi Zengjie, >>>>>> >>>>>>Zengjie Kou wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Hi,Acee, >>>>>>> If a router interface whose role is changed(e.g.DR goes down), the router will notify all routers about the change by immediate hello. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>This is only when the DR/BDR knows that it is going down or the case >>>>>>where the router >>>>>>priority is set to 0. >>>>>> >>>>>>For a router becoming DR/BDR, all the routers should elect the same DR/BDR >>>>>>so I don't see how it helps. >>>>>> >>>>>>Thanks, >>>>>>Acee >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>After all router get the change, election will be reprocessed. In contrast to normal hello, immediate hello avoid the backupSeen. >>>>>>>Namely, improving convergence. >>>>>>> >>>>>>>Thanks a lot, >>>>>>>Zengjie >>>>>>> >>>>>>>----- Original Message ----- >>>>>>>From: "Acee Lindem" >>>>>>>To: >>>>>>>Sent: Saturday, February 18, 2006 5:17 AM >>>>>>>Subject: draft-kou-ospf-immediately-replying-hello-00.txt >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Hi Zengjie, >>>>>>>> >>>>>>>>Under what situations does having the router who changed to/from >>>>>>>>DR/BDR improve convergence (section 6.2)? Since DR/BDR election >>>>>>>>is a distributed algorithm dependent on the calculating routers state, it >>>>>>>>seems this won't help in all that many cases. >>>>>>>> >>>>>>>>Thanks, >>>>>>>>Acee >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> >>> >>> > > >