From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 02 17:36:07 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtYHf-00020o-5R for ospf-archive@megatron.ietf.org; Mon, 02 Jan 2006 17:36: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 RAA23477 for ; Mon, 2 Jan 2006 17:34: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 <3.000082DF@wildebeest.ease.lsoft.com>; Mon, 2 Jan 2006 17:35:35 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95286956 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 2 Jan 2006 17:35:35 -0500 Received: from 207.69.195.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 2 Jan 2006 17:35:34 -0500 Received: from h-68-164-85-155.snvacaid.dynamic.covad.net ([68.164.85.155] helo=earthlink.net) by pop-knobcone.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1EtYH7-0001IG-00 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 02 Jan 2006 17:35: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: <20051229112742.71966.qmail@web25401.mail.ukl.yahoo.com> <006001c60cea$56c85d10$610c6f0a@china.huawei.com> <43B4B2F9.60A807AB@earthlink.net> <002301c60de4$4074d160$610c6f0a@china.huawei.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43B9AD66.CA285006@earthlink.net> Date: Mon, 2 Jan 2006 14:47:02 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Update to OSPF Hello procedure[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 Zengjie Kou, et al, First, The v2 spec sect 9.5.1 Sending hellos with NBMA networks "at other times it is sent as a response to a recieved Hello packet". It later mentions times when it should/must send hellos, with my understanding to limit hellos. Yes, this is in a time where the media bytes/sec was more limited. So, a hello response is not a new idea. Second, > Sorry, I don't know what is your question. > 1)Why is DR election interrupted? Why is DR election wrong? With two routers, one is DR, another is BDR, their hello packets include DR/BDR information. > > Thanks > Kou. OSPF specifies that once a DR and/or a BDR is elected we don't override the election if a new router comes up with a higher priority. This is done, by accepting the hello fields that specify a DR / BDR normally by the DR / BDR, so we stop the process of election. The question is when it stops. I have seen some implimentations only stop the election when a router has stated it is the DR / BDR on its first hello. This may be almost 10 secs by default after the interface comes up. Others will accept the DR / BDR on a later hello. Thus, It is the later hello or a delayed 10 sec if no hellos are lost or 30+ secs if a hello was lost that will stop the DR / BDR election. Worse case scenario... Lastly on a BMA environment, if we have a number of 9 routers (follows with immediate hello responses) that come up in a sequence in a 9 secs timeframe and the 10th router is the DR (with a standard 10 sec periodic hello) chiming in with a hello at 10 secs. Oh, we can change secs to ms and the same number of hellos would be exchanged. This is how I see it with unicast hellos.... The logic is on the initial intf up, that router sends out a hello, then every router on the intf responds. The router sees its on id on the responding hellos, but needs now to respond to the responders so they can see their own ids. This is a fast adj formation and assumes that each router is capable of becoming the DR and/or the BDR. Time 0 : 1st router comes up: Sends out a hello ; 1 (h) hello 1 : 2nd " " 1st one responds 2nd needs to respond both are now 2-way : 1prev + 3new = 4 2 : 3rd " " 1st responds 3rd responds to 1st 2nd responds 3rd responds to 2nd all three are now 2-way 4 prev + 5 new = 9 3 : 4th " " 1st responds 4th responds to 1st 2nd responds 4th responds to 2nd 3rd responds 4th responds to 3rd 9 prev + 7 : 16 hellos 4 : 5th 16 prev + 9new = 25 5 : 6th 25 prev + 11 new : 36 6: : 7th 36 prev + 13 new : 49 7 : 8th 49 prev + 15 new : 64 8 : 9th 64 prev + 17 new : 81 hellos Now the 10th pkt comes from the already up DR and all previous 9 respond. 81 prev + 1 hello from DR + 9 immediate replies= 91 hellos And even with this logic, I still am not updating each hello time period. Starting at time 2, when 3rd responded to 1st router it did not include the knowledge of router 2. Thus, in theory 3rd SHOULD send again a hello pkt back to 1st that includes the router 2 in its information. So, the number of hellos is worse with proper updates. And is fairly complex because it now needs a list of nbrs that needs hellos and which become out of sync and thus need to be resync'ed. IMO, this is ALOT of hellos... Mitchell Erblich ----------------------- Zengjie Kou wrote: > > Hi,Mitchell > > Please see inline for answers to your questions. > > ----- Original Message ----- > From: "Erblichs" > To: > Sent: Friday, December 30, 2005 12:09 PM > Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] > > > Kou, > > > > 1) A few extra hellos? You will force a matrix number > > of hellos? With 10 routers, you will need 90 hellos. > > With 100 routers, we have 9900 hellos I think, if > > we need to respond to each nbr's hello. Where we have > > 2x the number of router's hellos in the standard method > > with MC hellos (20 and 200). Oh, yours are with ms of > > each other and the standard hellos are spread along the > > hello interval. > > > 1.) Immediate Hello can be enable or disable. > 2.) On broadcast and NBMA networks, Immediate Hello expedite link recovery when a link goes down then up and does bring a few extra hellos(with 10 routers, will need 27(9*3) hellos ). > > At the moment of router booting, the Immediate Hello is not fit. So, we can disable it. > > > 2) > > I disagree, this can effect DR election. > > > > How? Assume their is a disagreement as to whom > > should be elected DR in the normal method. Now, with > > that quick hello, the faster router tells the other > > routers not just whom he choose, but who is the DR. > > > > Anytime before DR is elected, Y informs that X is the DR, > > then OSPF says X is the DR. You are saving on avg > > 1/2 hello interval time. > > > > Now, why can their be a disagreement? Simply, a late > > hello informing about a new router with a higher priority > > before the DR is elected. > > > > With the current method, we give an extra few secs, just > > to allow everyone to make up their own private decision, then > > publicise the decision, and if their is a disagreement after > > recieving the multiple public hellos, then resolve it. > > > > Yes, some implimentations ignore hellos with DR announcement > > after election has begun. But some don't. And I am refering > > to the later ones. > > > > Now, it gets complicated. Assume that 2 routers who accept > > the fast hello and the interruption of the DR process. Won't > > they form a full ADJ if one or both are the DR / BDR? Now, > > the 3rd guy heard a hello from the highest priority router > > and accepted him as the DR? Aren't you needlessly trying > > to sync the LSDBs with the wrong DR? > > > > Mitchell Erblich > > > > > > > Sorry, I don't know what is your question. > 1)Why is DR election interrupted? Why is DR election wrong? With two routers, one is DR, another is BDR, their hello packets include DR/BDR information. > > Thanks > Kou. > > > Zengjie Kou wrote: > >> > >> Hi,Manav > >> I don't find any harm except a few additional hello packets before the state reaches "ExStart". > >> > >> The Immediate Hello do not affect which router will be elected DR. It only expedite the election. > >> > >> thanks > >> kou. > >> > >> ----- Original Message ----- > >> From: "Manav Bhatia" > >> To: > >> Sent: Thursday, December 29, 2005 7:27 PM > >> Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] > >> > >> > So whats the harm in this? > >> > > >> > If you wanted a particular router to become the DR then you would have given it a higher priority. > >> > The fact that you havent done that implies that you dont really care which router becomes the DR. > >> > > >> > Manav > >> > --- Nitin Kakkar wrote: > >> > > >> >> Suppose there are n routers on a Link and all of them come up almost > >> >> simultaneously. > >> >> > >> >> Seems like the routers which were fractionally faster to send hello will be > >> >> picked for DR/BDR election !!! > >> >> > >> >> > >> >> > >> >> May be you can think of immediately replying to hello packet "Only when DR > >> >> is already elected on the link". > >> >> > >> >> > >> >> > >> >> Rgds > >> >> > >> >> Nitin > >> >> > >> >> > >> >> > >> >> -----Original Message----- > >> >> From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > >> >> Kouzengjie > >> >> Sent: Thursday, December 29, 2005 7:51 AM > >> >> To: OSPF@PEACH.EASE.LSOFT.COM > >> >> Subject: Update to OSPF Hello > >> >> procedure[draft-kou-ospf-immediately-replying-hello-00.txt] > >> >> > >> >> > >> >> > >> >> A New Internet-Draft is available from the on-line Internet-Drafts > >> >> directories. > >> >> The draft can be found here: > >> >> http://www.ietf.org/internet-drafts/draft-kou-ospf-immediately-replying-hell > >> >> o-00.txt > >> >> > >> >> > >> >> > >> >> This memo documents an extension of the OSPF protocol to reach > >> >> "ExStart" state more quickly. Currently, the OSPF behavior requires > >> >> the Hello Packet to be sent between the neighbors every > >> >> HelloInterval. This document proposes to generalize the use of > >> >> Immediately Replying Hello which could reduce the time required to > >> >> reach the OSPF "ExStart" state and expedite the routing table > >> >> convergence. > >> >> > >> >> > >> > > >> > > >> > > >> > > >> > ___________________________________________________________ > >> > NEW Yahoo! Cars - sell your car and browse thousands of new and used cars online! http://uk.cars.yahoo.com/ From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jan 03 21:00:04 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etxwa-0000cJ-5D for ospf-archive@megatron.ietf.org; Tue, 03 Jan 2006 21:00: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 UAA19720 for ; Tue, 3 Jan 2006 20:58:48 -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.00008698@wildebeest.ease.lsoft.com>; Tue, 3 Jan 2006 20:59:31 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95399850 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 3 Jan 2006 20:59:31 -0500 Received: from 61.144.161.55 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 3 Jan 2006 20:59:30 -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 <0ISJ00M8RPS1P2@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 04 Jan 2006 10:04:49 +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 <0ISJ006B8PS0JV@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 04 Jan 2006 10:04:49 +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 <0ISJ00J2FQ03OF@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 04 Jan 2006 10:09:39 +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: <017201c60c1e$8f545a20$610c6f0a@china.huawei.com> Message-ID: <000d01c610d2$61a11100$610c6f0a@china.huawei.com> Date: Wed, 4 Jan 2006 09:58:38 +0800 Reply-To: Mailing List Sender: Mailing List From: Zengjie Kou Subject: Re: Update to OSPF Hello procedure[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 ----- Original Message ----- From: "Paul Jakma" To: Sent: Sunday, January 01, 2006 12:05 AM Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] > Hi, > > On Thu, 29 Dec 2005, Kouzengjie wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> The draft can be found here: >> http://www.ietf.org/internet-drafts/draft-kou-ospf-immediately-replying-hello-00.txt > > GNU Zebra's (and hence Quagga's) ospfd has done something like this > for a long time now (a subset at least, send hello immediately if > neighbour state changes into state Init). > > One thing, might it be an idea to specify that the Immediate Hello be > /independent/ of the Hello-Interval timer? (ie dont set or reset the > interface's Hello timer because of any Immediate Hello sent). > Otherwise, there'll be strong tendency for the HelloInterval timers > across routers to latch. Not sure how much this matters. > Yes, Immediate Hello is independent of HelloInterval timer. It is in favor of compatibility. > Also, it might be an idea to add some state (e.g. a delay factor, > some arbitrary protocol constant, 100ms or somesuch) to prevent > Immediate-Hello storms if, for whatever reason, neighbour states fail > to progress pass ExStart and fall back to Init. Some types of links > are quite sensitive to L2 congestion for example. > Yes, this may be a good idea. We consider that it is a option of Immediate Hello. > 6.1.1. Is there a good reason why pre-2-Way Immediate-Hellos are to > be sent unicast? > > If you happen to process multiple neighbour state changes (e.g. > because of the delay factor on a previous immediate hello, or because > the implementation chooses to define 'immediate' as 'very small > delay'), one Immediate-Hello to AllSPFRouters can take care of all of > them - rather than having to send multiple unicast hellos to each > neighbour. > > I.e. it might be an idea to just drop the modifications proposed in > 6.1.1. > If Immediate Hello is multicast, all routers attached the ospf networks will handle all Immediate hellos,which consumes lots of cost. So, unicast is an appropriate mechanism which finishes all in the peer of sending hello. Thanks Kou. > regards, > -- > Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A > Fortune: > Earth men are real men! From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jan 03 21:35:05 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtyUT-0007Uh-SS for ospf-archive@megatron.ietf.org; Tue, 03 Jan 2006 21:35: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 VAA22891 for ; Tue, 3 Jan 2006 21:33: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 <4.000086A7@wildebeest.ease.lsoft.com>; Tue, 3 Jan 2006 21:34:34 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95402224 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 3 Jan 2006 21:34:34 -0500 Received: from 61.144.161.53 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 3 Jan 2006 21:34:19 -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 <0ISJ00HZIRJPJB@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 04 Jan 2006 10:43:01 +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 <0ISJ00MRLRJO43@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 04 Jan 2006 10:43:00 +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 <0ISJ00JY1RMVOF@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 04 Jan 2006 10:44:55 +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: <20051229112742.71966.qmail@web25401.mail.ukl.yahoo.com> <006001c60cea$56c85d10$610c6f0a@china.huawei.com> <43B4B2F9.60A807AB@earthlink.net> <002301c60de4$4074d160$610c6f0a@china.huawei.com> <43B9AD66.CA285006@earthlink.net> Message-ID: <001d01c610d7$4ec16cb0$610c6f0a@china.huawei.com> Date: Wed, 4 Jan 2006 10:33:54 +0800 Reply-To: Mailing List Sender: Mailing List From: Zengjie Kou Subject: Re: Update to OSPF Hello procedure[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,Mitchell ----- Original Message ----- From: "Erblichs" To: Sent: Tuesday, January 03, 2006 6:47 AM Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] > Zengjie Kou, et al, > > First, > > The v2 spec sect 9.5.1 Sending hellos with NBMA > networks "at other times it is sent as a response > to a recieved Hello packet". > > It later mentions times when it should/must send > hellos, with my understanding to limit hellos. Yes, > this is in a time where the media bytes/sec was > more limited. > > So, a hello response is not a new idea. > > Second, > > > Sorry, I don't know what is your question. >> 1)Why is DR election interrupted? Why is DR election wrong? With two routers, one is DR, another is BDR, their hello packets include DR/BDR information. >> >> Thanks >> Kou. > OSPF specifies that once a DR and/or a BDR is elected > we don't override the election if a new router comes > up with a higher priority. > > This is done, by accepting the hello fields that > specify a DR / BDR normally by the DR / BDR, so we > stop the process of election. > > The question is when it stops. I have seen some > implimentations only stop the election when a router > has stated it is the DR / BDR on its first hello. > This may be almost 10 secs by default after the > interface comes up. Others will accept the DR / BDR > on a later hello. > > Thus, It is the later hello or a delayed 10 sec if > no hellos are lost or 30+ secs if a hello was lost > that will stop the DR / BDR election. > > Worse case scenario... > Lastly on a BMA environment, if we have a number of 9 routers > (follows with immediate hello responses) that come up in a > sequence in a 9 secs timeframe and the 10th router is the DR > (with a standard 10 sec periodic hello) chiming in with a > hello at 10 secs. > > Oh, we can change secs to ms and the same number of hellos > would be exchanged. > > This is how I see it with unicast hellos.... The logic is > on the initial intf up, that router sends out a hello, then > every router on the intf responds. The router sees its on > id on the responding hellos, but needs now to respond to the > responders so they can see their own ids. This is a fast > adj formation and assumes that each router is capable of > becoming the DR and/or the BDR. > > Time 0 : 1st router comes up: Sends out a hello ; 1 (h) hello > > 1 : 2nd " " 1st one responds > 2nd needs to respond > both are now 2-way : > 1prev + 3new = 4 > > 2 : 3rd " " > 1st responds > 3rd responds to 1st > 2nd responds > 3rd responds to 2nd > all three are now 2-way > 4 prev + 5 new = 9 > > > > 3 : 4th " " > 1st responds > 4th responds to 1st > 2nd responds > 4th responds to 2nd > 3rd responds > 4th responds to 3rd > 9 prev + 7 : 16 hellos > > > 4 : 5th 16 prev + 9new = 25 > 5 : 6th 25 prev + 11 new : 36 > 6: : 7th 36 prev + 13 new : 49 > 7 : 8th 49 prev + 15 new : 64 > 8 : 9th 64 prev + 17 new : 81 hellos > > Now the 10th pkt comes from the already up DR and all previous > 9 respond. 81 prev + 1 hello from DR + 9 immediate replies= 91 hellos > > And even with this logic, I still am not updating each hello > time period. Starting at time 2, when 3rd responded to 1st router > it did not include the knowledge of router 2. Thus, in theory > 3rd SHOULD send again a hello pkt back to 1st that includes the > router 2 in its information. So, the number of hellos is worse > with proper updates. And is fairly complex because it now needs > a list of nbrs that needs hellos and which become out of sync > and thus need to be resync'ed. > > IMO, this is ALOT of hellos... > Again to verify: 1.) Immediate Hello can be enable or disable. 2.) On broadcast and NBMA networks, Immediate Hello expedite link recovery when a link goes down then up and does bring a few extra hellos(with 10 routers, will need 27(9*3) hellos ). At the moment of router booting, the Immediate Hello is not fit. So, we can disable it. Thanks Kou. > Mitchell Erblich > ----------------------- > > > > > Zengjie Kou wrote: >> >> Hi,Mitchell >> >> Please see inline for answers to your questions. >> >> ----- Original Message ----- >> From: "Erblichs" >> To: >> Sent: Friday, December 30, 2005 12:09 PM >> Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] >> >> > Kou, >> > >> > 1) A few extra hellos? You will force a matrix number >> > of hellos? With 10 routers, you will need 90 hellos. >> > With 100 routers, we have 9900 hellos I think, if >> > we need to respond to each nbr's hello. Where we have >> > 2x the number of router's hellos in the standard method >> > with MC hellos (20 and 200). Oh, yours are with ms of >> > each other and the standard hellos are spread along the >> > hello interval. >> > >> 1.) Immediate Hello can be enable or disable. >> 2.) On broadcast and NBMA networks, Immediate Hello expedite link recovery when a link goes down then up and does bring a few extra hellos(with 10 routers, will need 27(9*3) hellos ). >> >> At the moment of router booting, the Immediate Hello is not fit. So, we can disable it. >> >> > 2) >> > I disagree, this can effect DR election. >> > >> > How? Assume their is a disagreement as to whom >> > should be elected DR in the normal method. Now, with >> > that quick hello, the faster router tells the other >> > routers not just whom he choose, but who is the DR. >> > >> > Anytime before DR is elected, Y informs that X is the DR, >> > then OSPF says X is the DR. You are saving on avg >> > 1/2 hello interval time. >> > >> > Now, why can their be a disagreement? Simply, a late >> > hello informing about a new router with a higher priority >> > before the DR is elected. >> > >> > With the current method, we give an extra few secs, just >> > to allow everyone to make up their own private decision, then >> > publicise the decision, and if their is a disagreement after >> > recieving the multiple public hellos, then resolve it. >> > >> > Yes, some implimentations ignore hellos with DR announcement >> > after election has begun. But some don't. And I am refering >> > to the later ones. >> > >> > Now, it gets complicated. Assume that 2 routers who accept >> > the fast hello and the interruption of the DR process. Won't >> > they form a full ADJ if one or both are the DR / BDR? Now, >> > the 3rd guy heard a hello from the highest priority router >> > and accepted him as the DR? Aren't you needlessly trying >> > to sync the LSDBs with the wrong DR? >> > >> > Mitchell Erblich >> > >> > >> > >> Sorry, I don't know what is your question. >> 1)Why is DR election interrupted? Why is DR election wrong? With two routers, one is DR, another is BDR, their hello packets include DR/BDR information. >> >> Thanks >> Kou. >> >> > Zengjie Kou wrote: >> >> >> >> Hi,Manav >> >> I don't find any harm except a few additional hello packets before the state reaches "ExStart". >> >> >> >> The Immediate Hello do not affect which router will be elected DR. It only expedite the election. >> >> >> >> thanks >> >> kou. >> >> >> >> ----- Original Message ----- >> >> From: "Manav Bhatia" >> >> To: >> >> Sent: Thursday, December 29, 2005 7:27 PM >> >> Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] >> >> >> >> > So whats the harm in this? >> >> > >> >> > If you wanted a particular router to become the DR then you would have given it a higher priority. >> >> > The fact that you havent done that implies that you dont really care which router becomes the DR. >> >> > >> >> > Manav >> >> > --- Nitin Kakkar wrote: >> >> > >> >> >> Suppose there are n routers on a Link and all of them come up almost >> >> >> simultaneously. >> >> >> >> >> >> Seems like the routers which were fractionally faster to send hello will be >> >> >> picked for DR/BDR election !!! >> >> >> >> >> >> >> >> >> >> >> >> May be you can think of immediately replying to hello packet "Only when DR >> >> >> is already elected on the link". >> >> >> >> >> >> >> >> >> >> >> >> Rgds >> >> >> >> >> >> Nitin >> >> >> >> >> >> >> >> >> >> >> >> -----Original Message----- >> >> >> From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >> >> >> Kouzengjie >> >> >> Sent: Thursday, December 29, 2005 7:51 AM >> >> >> To: OSPF@PEACH.EASE.LSOFT.COM >> >> >> Subject: Update to OSPF Hello >> >> >> procedure[draft-kou-ospf-immediately-replying-hello-00.txt] >> >> >> >> >> >> >> >> >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> >> >> directories. >> >> >> The draft can be found here: >> >> >> http://www.ietf.org/internet-drafts/draft-kou-ospf-immediately-replying-hell >> >> >> o-00.txt >> >> >> >> >> >> >> >> >> >> >> >> This memo documents an extension of the OSPF protocol to reach >> >> >> "ExStart" state more quickly. Currently, the OSPF behavior requires >> >> >> the Hello Packet to be sent between the neighbors every >> >> >> HelloInterval. This document proposes to generalize the use of >> >> >> Immediately Replying Hello which could reduce the time required to >> >> >> reach the OSPF "ExStart" state and expedite the routing table >> >> >> convergence. >> >> >> >> >> >> >> >> > >> >> > >> >> > >> >> > >> >> > ___________________________________________________________ >> >> > NEW Yahoo! Cars - sell your car and browse thousands of new and used cars online! http://uk.cars.yahoo.com/ From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 04 14:24:24 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuEFE-0001AM-CQ for ospf-archive@megatron.ietf.org; Wed, 04 Jan 2006 14:24: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 OAA14223 for ; Wed, 4 Jan 2006 14:23: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 <9.0000883C@wildebeest.ease.lsoft.com>; Wed, 4 Jan 2006 14:23:51 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95463875 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 4 Jan 2006 14:23:51 -0500 Received: from 212.17.55.49 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 4 Jan 2006 14:23:48 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX19QJdzWMZqy0In7bS+29a6VFOvgkekh+Q0@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id k04JNAHk026120 for ; Wed, 4 Jan 2006 19:23:22 GMT X-X-Sender: paul@sheen.jakma.org References: <000001c60d06$206b36e0$b104120a@china.huawei.com> Mail-Copies-To: paul@hibernia.jakma.org Mail-Followup-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.87.1/1229/Wed Jan 4 15:08:11 2006 on hibernia.jakma.org X-Virus-Status: Clean Message-ID: Date: Wed, 4 Jan 2006 19:23:09 +0000 Reply-To: Mailing List Sender: Mailing List From: Paul Jakma Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: On Sat, 31 Dec 2005, Paul Jakma wrote: >> routers come up and send hello. There is no grace time for other routers to >> come up and announce themselves. > > You'll just get another DR/BDR election in that case. Oops, no. The implementation I'm most familiar with will just force another election, due to another 'quick sync' hack -> ignoring the wait-time and sending Hello immediately on start. Real OSPF of course shouldn't cause additional elections, as someone corrected me on in private. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: The abuse of greatness is when it disjoins remorse from power. -- William Shakespeare, "Julius Caesar" From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 04 14:38:52 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuETE-0004Q6-5J for ospf-archive@megatron.ietf.org; Wed, 04 Jan 2006 14:38: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 OAA15374 for ; Wed, 4 Jan 2006 14:37:36 -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.00008859@wildebeest.ease.lsoft.com>; Wed, 4 Jan 2006 14:38:21 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95465121 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 4 Jan 2006 14:38:21 -0500 Received: from 212.17.55.49 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 4 Jan 2006 14:38:16 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX1/iTyVHTr/zNipJEXOoy2e3kL4172Kx6lw@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id k04Jbn0s026249 for ; Wed, 4 Jan 2006 19:38:00 GMT X-X-Sender: paul@sheen.jakma.org References: <017201c60c1e$8f545a20$610c6f0a@china.huawei.com> <000d01c610d2$61a11100$610c6f0a@china.huawei.com> Mail-Copies-To: paul@hibernia.jakma.org Mail-Followup-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.87.1/1229/Wed Jan 4 15:08:11 2006 on hibernia.jakma.org X-Virus-Status: Clean Message-ID: Date: Wed, 4 Jan 2006 19:37:49 +0000 Reply-To: Mailing List Sender: Mailing List From: Paul Jakma Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000d01c610d2$61a11100$610c6f0a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: On Wed, 4 Jan 2006, Zengjie Kou wrote: >> /independent/ of the Hello-Interval timer? (ie dont set or reset >> the interface's Hello timer because of any Immediate Hello sent). >> Otherwise, there'll be strong tendency for the HelloInterval >> timers across routers to latch. Not sure how much this matters. > Yes, Immediate Hello is independent of HelloInterval timer. > It is in favor of compatibility. Ok, should the draft then explicitely note that Immediate-Hello ideally should not affect (e.g. reset) any hello timer? (so as to avoid the timed-interval hello synchronising). > If Immediate Hello is multicast, all routers attached the ospf > networks will handle all Immediate hellos,which consumes lots of > cost. So, unicast is an appropriate mechanism which finishes all in > the peer of sending hello. It will have a higher cost though. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: "Well hello there Charlie Brown, you blockhead." -- Lucy Van Pelt From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 04 15:09:33 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuEwv-0005yc-PG for ospf-archive@megatron.ietf.org; Wed, 04 Jan 2006 15:09:33 -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 PAA19343 for ; Wed, 4 Jan 2006 15:08:15 -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.00008890@wildebeest.ease.lsoft.com>; Wed, 4 Jan 2006 15:08:59 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95467255 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 4 Jan 2006 15:08:59 -0500 Received: from 207.69.195.63 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 4 Jan 2006 15:08:57 -0500 Received: from h-68-164-85-155.snvacaid.dynamic.covad.net ([68.164.85.155] helo=earthlink.net) by pop-satin.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1EuEwG-0004q1-00 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 04 Jan 2006 15:08:52 -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: <20051229112742.71966.qmail@web25401.mail.ukl.yahoo.com> <006001c60cea$56c85d10$610c6f0a@china.huawei.com> <43B4B2F9.60A807AB@earthlink.net> <002301c60de4$4074d160$610c6f0a@china.huawei.com> <43B9AD66.CA285006@earthlink.net> <001d01c610d7$4ec16cb0$610c6f0a@china.huawei.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43BC2ED2.27B92BE9@earthlink.net> Date: Wed, 4 Jan 2006 12:23:46 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Update to OSPF Hello procedure[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 Zengie Kou, Sorry, I am still confused. Below I gave you a scenario of a seq of generating in excess of 81 hellos when the initial hello that is sent out is a MC hello and replies are then UC. Thus,. I don't see how you do 27 hellos unless you are filtering replies based on "c" below or such. My example below did no filtering because it is in a bringup environment and is trying to expedite "full adj" formations based on your draft-rfc.. The MC hello is done when the link comes up and is currently extemely common with OSPF implimentations to expedite link formations. This I like. "recovery when a link goes down then up" I am assuming that link status is determined by xmit/recv of hellos in the below items.. a) If the this happens within the dead router timeframe, how does one determine that the link is at fault vs dropped hellos at the recv'r or non xmit'ed pkts or ???? Should we even care about replying in this ex? b) If this time frame occurs longer than the dead router time frame, won't 99+% of implimentations remove the now dead nbr? This is done mainly to shorten the nbr lookup? How would you know if the router was up in the first place without history? How long should you keep history? If history is kept, you would first need to check current nbrs and if not their, then check history and if their, promote that router. Isn't this alot of extra overhead just because a link went down? c) If this is in a BMA envir, and the hello is from/to DR-others (DR and BDR exist) OR it is not announcing itself as the (DR or BDR) should we even process the hello and form a bad false-link to a nbr that can't go full? Thus these hellos should be who cares!!! A who care hello SHOULD not be replied to, IMO!!!! d) etc... Oh, and DR/BDR re-election can be done by having a router just announce itself as a DR/BDR within a hello. This is supported by area merging. Mitchell Erblich ------------------- 2.) On broadcast and NBMA networks, Immediate Hello expedite link recovery when a link goes down then up and does bring a few extra hellos(with 10 routers, will need 27(9*3) hellos ). Zengjie Kou wrote: > > hi,Mitchell > > ----- Original Message ----- > From: "Erblichs" > To: > Sent: Tuesday, January 03, 2006 6:47 AM > Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] > > > Zengjie Kou, et al, > > > > First, > > > > The v2 spec sect 9.5.1 Sending hellos with NBMA > > networks "at other times it is sent as a response > > to a recieved Hello packet". > > > > It later mentions times when it should/must send > > hellos, with my understanding to limit hellos. Yes, > > this is in a time where the media bytes/sec was > > more limited. > > > > So, a hello response is not a new idea. > > > > Second, > > > > > Sorry, I don't know what is your question. > >> 1)Why is DR election interrupted? Why is DR election wrong? With two routers, one is DR, another is BDR, their hello packets include DR/BDR information. > >> > >> Thanks > >> Kou. > > OSPF specifies that once a DR and/or a BDR is elected > > we don't override the election if a new router comes > > up with a higher priority. > > > > This is done, by accepting the hello fields that > > specify a DR / BDR normally by the DR / BDR, so we > > stop the process of election. > > > > The question is when it stops. I have seen some > > implimentations only stop the election when a router > > has stated it is the DR / BDR on its first hello. > > This may be almost 10 secs by default after the > > interface comes up. Others will accept the DR / BDR > > on a later hello. > > > > Thus, It is the later hello or a delayed 10 sec if > > no hellos are lost or 30+ secs if a hello was lost > > that will stop the DR / BDR election. > > > > Worse case scenario... > > Lastly on a BMA environment, if we have a number of 9 routers > > (follows with immediate hello responses) that come up in a > > sequence in a 9 secs timeframe and the 10th router is the DR > > (with a standard 10 sec periodic hello) chiming in with a > > hello at 10 secs. > > > > Oh, we can change secs to ms and the same number of hellos > > would be exchanged. > > > > This is how I see it with unicast hellos.... The logic is > > on the initial intf up, that router sends out a hello, then > > every router on the intf responds. The router sees its on > > id on the responding hellos, but needs now to respond to the > > responders so they can see their own ids. This is a fast > > adj formation and assumes that each router is capable of > > becoming the DR and/or the BDR. > > > > Time 0 : 1st router comes up: Sends out a hello ; 1 (h) hello > > > > 1 : 2nd " " 1st one responds > > 2nd needs to respond > > both are now 2-way : > > 1prev + 3new = 4 > > > > 2 : 3rd " " > > 1st responds > > 3rd responds to 1st > > 2nd responds > > 3rd responds to 2nd > > all three are now 2-way > > 4 prev + 5 new = 9 > > > > > > > > 3 : 4th " " > > 1st responds > > 4th responds to 1st > > 2nd responds > > 4th responds to 2nd > > 3rd responds > > 4th responds to 3rd > > 9 prev + 7 : 16 hellos > > > > > > 4 : 5th 16 prev + 9new = 25 > > 5 : 6th 25 prev + 11 new : 36 > > 6: : 7th 36 prev + 13 new : 49 > > 7 : 8th 49 prev + 15 new : 64 > > 8 : 9th 64 prev + 17 new : 81 hellos > > > > Now the 10th pkt comes from the already up DR and all previous > > 9 respond. 81 prev + 1 hello from DR + 9 immediate replies= 91 hellos > > > > And even with this logic, I still am not updating each hello > > time period. Starting at time 2, when 3rd responded to 1st router > > it did not include the knowledge of router 2. Thus, in theory > > 3rd SHOULD send again a hello pkt back to 1st that includes the > > router 2 in its information. So, the number of hellos is worse > > with proper updates. And is fairly complex because it now needs > > a list of nbrs that needs hellos and which become out of sync > > and thus need to be resync'ed. > > > > IMO, this is ALOT of hellos... > > > Again to verify: > 1.) Immediate Hello can be enable or disable. > 2.) On broadcast and NBMA networks, Immediate Hello expedite link recovery when a link goes down then up and does bring a few extra hellos(with 10 routers, will need 27(9*3) hellos ). > > At the moment of router booting, the Immediate Hello is not fit. So, we can disable it. > > Thanks > Kou. > > > Mitchell Erblich > > ----------------------- > > > > > > > > > > Zengjie Kou wrote: > >> > >> Hi,Mitchell > >> > >> Please see inline for answers to your questions. > >> > >> ----- Original Message ----- > >> From: "Erblichs" > >> To: > >> Sent: Friday, December 30, 2005 12:09 PM > >> Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] > >> > >> > Kou, > >> > > >> > 1) A few extra hellos? You will force a matrix number > >> > of hellos? With 10 routers, you will need 90 hellos. > >> > With 100 routers, we have 9900 hellos I think, if > >> > we need to respond to each nbr's hello. Where we have > >> > 2x the number of router's hellos in the standard method > >> > with MC hellos (20 and 200). Oh, yours are with ms of > >> > each other and the standard hellos are spread along the > >> > hello interval. > >> > > >> 1.) Immediate Hello can be enable or disable. > >> 2.) On broadcast and NBMA networks, Immediate Hello expedite link recovery when a link goes down then up and does bring a few extra hellos(with 10 routers, will need 27(9*3) hellos ). > >> > >> At the moment of router booting, the Immediate Hello is not fit. So, we can disable it. > >> > >> > 2) > >> > I disagree, this can effect DR election. > >> > > >> > How? Assume their is a disagreement as to whom > >> > should be elected DR in the normal method. Now, with > >> > that quick hello, the faster router tells the other > >> > routers not just whom he choose, but who is the DR. > >> > > >> > Anytime before DR is elected, Y informs that X is the DR, > >> > then OSPF says X is the DR. You are saving on avg > >> > 1/2 hello interval time. > >> > > >> > Now, why can their be a disagreement? Simply, a late > >> > hello informing about a new router with a higher priority > >> > before the DR is elected. > >> > > >> > With the current method, we give an extra few secs, just > >> > to allow everyone to make up their own private decision, then > >> > publicise the decision, and if their is a disagreement after > >> > recieving the multiple public hellos, then resolve it. > >> > > >> > Yes, some implimentations ignore hellos with DR announcement > >> > after election has begun. But some don't. And I am refering > >> > to the later ones. > >> > > >> > Now, it gets complicated. Assume that 2 routers who accept > >> > the fast hello and the interruption of the DR process. Won't > >> > they form a full ADJ if one or both are the DR / BDR? Now, > >> > the 3rd guy heard a hello from the highest priority router > >> > and accepted him as the DR? Aren't you needlessly trying > >> > to sync the LSDBs with the wrong DR? > >> > > >> > Mitchell Erblich > >> > > >> > > >> > > >> Sorry, I don't know what is your question. > >> 1)Why is DR election interrupted? Why is DR election wrong? With two routers, one is DR, another is BDR, their hello packets include DR/BDR information. > >> > >> Thanks > >> Kou. > >> > >> > Zengjie Kou wrote: > >> >> > >> >> Hi,Manav > >> >> I don't find any harm except a few additional hello packets before the state reaches "ExStart". > >> >> > >> >> The Immediate Hello do not affect which router will be elected DR. It only expedite the election. > >> >> > >> >> thanks > >> >> kou. > >> >> > >> >> ----- Original Message ----- > >> >> From: "Manav Bhatia" > >> >> To: > >> >> Sent: Thursday, December 29, 2005 7:27 PM > >> >> Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] > >> >> > >> >> > So whats the harm in this? > >> >> > > >> >> > If you wanted a particular router to become the DR then you would have given it a higher priority. > >> >> > The fact that you havent done that implies that you dont really care which router becomes the DR. > >> >> > > >> >> > Manav > >> >> > --- Nitin Kakkar wrote: > >> >> > > >> >> >> Suppose there are n routers on a Link and all of them come up almost > >> >> >> simultaneously. > >> >> >> > >> >> >> Seems like the routers which were fractionally faster to send hello will be > >> >> >> picked for DR/BDR election !!! > >> >> >> > >> >> >> > >> >> >> > >> >> >> May be you can think of immediately replying to hello packet "Only when DR > >> >> >> is already elected on the link". > >> >> >> > >> >> >> > >> >> >> > >> >> >> Rgds > >> >> >> > >> >> >> Nitin > >> >> >> > >> >> >> > >> >> >> > >> >> >> -----Original Message----- > >> >> >> From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > >> >> >> Kouzengjie > >> >> >> Sent: Thursday, December 29, 2005 7:51 AM > >> >> >> To: OSPF@PEACH.EASE.LSOFT.COM > >> >> >> Subject: Update to OSPF Hello > >> >> >> procedure[draft-kou-ospf-immediately-replying-hello-00.txt] > >> >> >> > >> >> >> > >> >> >> > >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts > >> >> >> directories. > >> >> >> The draft can be found here: > >> >> >> http://www.ietf.org/internet-drafts/draft-kou-ospf-immediately-replying-hell > >> >> >> o-00.txt > >> >> >> > >> >> >> > >> >> >> > >> >> >> This memo documents an extension of the OSPF protocol to reach > >> >> >> "ExStart" state more quickly. Currently, the OSPF behavior requires > >> >> >> the Hello Packet to be sent between the neighbors every > >> >> >> HelloInterval. This document proposes to generalize the use of > >> >> >> Immediately Replying Hello which could reduce the time required to > >> >> >> reach the OSPF "ExStart" state and expedite the routing table > >> >> >> convergence. > >> >> >> > >> >> >> > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > ___________________________________________________________ > >> >> > NEW Yahoo! Cars - sell your car and browse thousands of new and used cars online! http://uk.cars.yahoo.com/ From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 04 16:15:49 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuFz3-0007pM-2k for ospf-archive@megatron.ietf.org; Wed, 04 Jan 2006 16:15: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 QAA03503 for ; Wed, 4 Jan 2006 16:14: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 <11.000088E2@wildebeest.ease.lsoft.com>; Wed, 4 Jan 2006 16:11:53 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95472200 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 4 Jan 2006 16:11:53 -0500 Received: from 207.69.195.63 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 4 Jan 2006 16:11:53 -0500 Received: from h-68-164-85-155.snvacaid.dynamic.covad.net ([68.164.85.155] helo=earthlink.net) by pop-satin.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1EuFvE-00062o-00 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 04 Jan 2006 16:11:52 -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: <017201c60c1e$8f545a20$610c6f0a@china.huawei.com> <000d01c610d2$61a11100$610c6f0a@china.huawei.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43BC3D74.613CF1A0@earthlink.net> Date: Wed, 4 Jan 2006 13:26:12 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Update to OSPF Hello procedure[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 Paul Jakama, et al, Paul Jakma wrote: > > On Wed, 4 Jan 2006, Zengjie Kou wrote: > > >> /independent/ of the Hello-Interval timer? (ie dont set or reset > >> the interface's Hello timer because of any Immediate Hello sent). > >> Otherwise, there'll be strong tendency for the HelloInterval > >> timers across routers to latch. Not sure how much this matters. > > > Yes, Immediate Hello is independent of HelloInterval timer. > > It is in favor of compatibility. > > Ok, should the draft then explicitely note that Immediate-Hello > ideally should not affect (e.g. reset) any hello timer? (so as to > avoid the timed-interval hello synchronising). Could I add that, independent of whether a hello is immediately sent upon link up... That the hello timer's t1 (2nd hello) pkt be randomly picked between 0 and the hello interval. Then the subsequent hellos be sent at the agreed upon interval. This should allow a group of routers to independently ramdomize their hello pkts during the agreed upon hello interval. Mitchell Erblich > > > If Immediate Hello is multicast, all routers attached the ospf > > networks will handle all Immediate hellos,which consumes lots of > > cost. So, unicast is an appropriate mechanism which finishes all in > > the peer of sending hello. > > It will have a higher cost though. > > regards, > -- > Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A > Fortune: > "Well hello there Charlie Brown, you blockhead." > -- Lucy Van Pelt From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 04 16:47:51 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuGU3-0007wM-3k for ospf-archive@megatron.ietf.org; Wed, 04 Jan 2006 16:47:51 -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 QAA07881 for ; Wed, 4 Jan 2006 16:46: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 <11.00008906@wildebeest.ease.lsoft.com>; Wed, 4 Jan 2006 16:47:18 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95476595 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 4 Jan 2006 16:47:19 -0500 Received: from 209.73.178.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 4 Jan 2006 16:37:19 -0500 Received: (qmail 85310 invoked by uid 60001); 4 Jan 2006 21:37:19 -0000 Received: from [207.47.99.2] by web60024.mail.yahoo.com via HTTP; Wed, 04 Jan 2006 13:37:19 PST MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-738913367-1136410639=:63724" Content-Transfer-Encoding: 8bit Message-ID: <20060104213719.85308.qmail@web60024.mail.yahoo.com> Date: Wed, 4 Jan 2006 13:37:19 -0800 Reply-To: Mailing List Sender: Mailing List From: Conrad Watson Subject: unsubscribe To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: --0-738913367-1136410639=:63724 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit --0-738913367-1136410639=:63724 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
 
--0-738913367-1136410639=:63724-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 04 20:52:59 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuKJG-0000zW-Uy for ospf-archive@megatron.ietf.org; Wed, 04 Jan 2006 20:52:59 -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 UAA04059 for ; Wed, 4 Jan 2006 20:51: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 <12.000089D1@wildebeest.ease.lsoft.com>; Wed, 4 Jan 2006 20:52:25 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95490975 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 4 Jan 2006 20:52:25 -0500 Received: from 207.69.195.67 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 4 Jan 2006 20:52:25 -0500 Received: from h-68-164-85-155.snvacaid.dynamic.covad.net ([68.164.85.155] helo=earthlink.net) by pop-tawny.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1EuKIe-0004Yj-00; Wed, 04 Jan 2006 20:52:20 -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: <006b01c5f0c5$02ab2000$72646e0a@china.huawei.com> <20051124.162840.128462062.yasu@sfc.wide.ad.jp> <43A88D9D.94F7E644@earthlink.net> <20051224.162014.07263228.yasu@sfc.wide.ad.jp> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43BC7CA8.45C24AB5@earthlink.net> Date: Wed, 4 Jan 2006 17:55:52 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: About OSPF route flapping Comments: To: Yasuhiro Ohara To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Group, yes, its verbose... Sorry, a week later.. Let me generalize the problem, which I think hasn't been said yet. In essense, find a cost that you can throttle some data thru that link. This is a dynamic load balancer based on path cost and only the link flap originator and the local routers next to the originator need this change.. :-) First, I see route flapping as a origination / destination sort of a problem. I believe that OSPF has a unique way of easily dealing with link unstability that should be independent on link type or anything else. This is link cost. So bear with me, why you disagree that this can't be fixed this way. My first question is the determination of a link failure? If it is due to hello broadcasts, then the router dead value should limit the amount of flapping at the other side of the link. If the route flap is identified at the origination by repeated sending of LSAs (ex:router), then only full neighbors need any type of work, IMO. If at the origination a "link" is decidely unstable, is their any disagreement that when the link comes up, the originator SHOULD advertise the link with an additionaly unstable penalty cost? It keeps the link available for no alternative routes versus doing nothing.. However, this assumes that the originator is keeping some sort of link down/up/down/up history... Based on my experiences the penalty should be multiplicative in nature, so once it has reached a level of unstability, no routing changes really take place. No alternative routing will always and can always use the unstable link. Additionally, if the nbr at the other side of the unstable link sees excessive "router" LSAs, then his return cost SHOULD also add this unstable penalty cost. Also, this nbr at the other end of the adj, could slowly form the full adj AND only after local adj formation is complete, it COULD then forward the appropriate LSA control packets. BGP and OSPF are different.. BGP has TCP handshaking that must proceed any data transfers. It also has TCP to "limit" data transfer bandwidth based on percieved link congestion. TCP will slowly increase the available bandwidth each time a connection is lost and thus will effectively already dampen the connection as each time the link is dropped the link will move back into slow start. Since BGP will broadcast its entire routing table, the freq of routing table changes should be minimized. BGP also has the abiltiy to withdraw the link, and their link flapping algorithm effectively does that. BGP does have a local preference value and I would think that could be adjusted in some instances based on link instabliity. To minimize the amount of SPF/SPT work, these unstable routes should have secondary branches that can be used when they are unstable. these should be able to generate quick calculations. Mitchell Erblich PS: Also inline comments.. -------------------------------- Yasuhiro Ohara wrote: > > Hi Erblichs, > > Here I try to respond your requests by describing my opinion > beside what manav have told already. > > Please see inline. > > From: Erblichs > Subject: Re: About OSPF route flapping > Date: Tue, 20 Dec 2005 15:02:53 -0800 > Message-ID: <43A88D9D.94F7E644@earthlink.net> > > erblichs> Yasu, > erblichs> > erblichs> I think I read this paper before and wanted to ask > erblichs> you and the group a few questions. Why are you suggesting > erblichs> black-holing routes and not suggesting a SIMPLER approach? > > We were not suggesting black-holing, we suggest to apply BGP flap > dampening also to OSPF events. Black-holing in the experiment > just happened because of time lag between result of OSPF computation > and the actual link state, and it is regarded as a bad phenomenon. > > Black-holing is bad because it keep us from using alternative routes. > We applied flap dampening so that there would be no black-holing. I still think that will be the result with no alternative routing when the link is unstable until a certain amount of time has PASSED and it has been stable for awhile. > > erblichs> My suggested simpler approach is #4. > erblichs> > erblichs> 0) Are't you effectively black-holing the route > erblichs> and the routers behind the "flapping link"? > > Please see above. Black-holing was the bad situation resulted from > the flapping route. But you can't use the link after it has become stable until some time has passed!!!! > > erblichs> 1) If a link, route is flapping and it is a low traveled > erblichs> data link (almost a demand circuit) what is the harm > erblichs> if the link is periodicly down for short periods of > erblichs> time? > erblichs> > erblichs> 2) If the link is unstable because it is a "wireless" > erblichs> type link with large packet losses, won't you > erblichs> effectively isolate the wireless links if their > erblichs> are no alternative routes? > > As manav have told, we can configure the threshold of how unstable > for the link event to be dampend, and how quickly it starts to damp. > What types of link should be dampened or not is beyond the scope > of the paper, but I agree that on demand circuit we would not want > to dampen the link event. On wireless the dampening feature might be > useful, I guess. That threshold will NEVER (IMO) be perfect for all environments or the same environment with different configs. It will be either not agressive enough and have no effect or to be too agressive and dampen out things so the link is basicly unuseable.. > > Regardless of whether it is wireless or not, it is important > if we have another alternative route to the same destination other > than the flapping route. If we don't have any alternative, then > the dampening should leave the link "up" against ordinary > dampening method which would leave the link "down". > In the paper we only investigate the case when we have a alternative > route, so the dampening is made to leave the link as down. Agreed. But where you have two link paths, you COULD have balanced some of the load by link cost. Also, you do nothing if their is no alternative route. Why do nothing? A percentage of paths will have no alternatives.. > > I think I don't understand what you've meant by "isolate", > so please tell me if I am missing your point. Isolate, means to make unreachable. I just don't see in reality where an additional router is used for reliablity and if it goes down, nothing is effected. > > erblichs> 3) If the link has random periods of instability isn't > erblichs> your dampening increasing the period that the link > erblichs> CAN'T be used? > > Hmm I don't understand 'random periods of instability' ... What model > are you mentioning precisely ? No specific model. Just random times that things fail or get overloaded and need a kick to get them restarted. > > If the duration of previous up/down state is short enough compared to > configured threshold settings, then the dampening function will > increase the period that the link can't be used. Otherwise, > when the previous down duration is long enough, and when the link event > just occured is up, the link would be used immediately (dampening function > does not effect). > > erblichs> 3b) If the link has become stable after a period of > erblichs> unstability, won't you have an extended period of > erblichs> down time? > > Yes, we will have an extended period of down time just after the > unstability. That is from the nature of dampening algorithm. > We will leave the link as down even if the link is up > until the penalty of the link decreases as time passes. > Isn't this bad. the link is up and it can't be used!!! What happens if this unstability is caused by load. Won't you create in essense a thundering heard problem. This can only be fixed by THROTTING back!!!!!!!!! > erblichs> Maybe an upcoming Informational RFC if I FIND the time.. > erblichs> 4) WHY don't you just increment the cost of the link > erblichs> during periods of instability? Maybe, a demand > erblichs> type link that doesn't have to be up 100% of the time. > erblichs> > erblichs> Yes, you have to increment the cost as the time of > erblichs> instability increases or assume an initial level of > erblichs> instability and as the link ages, decrease the link > erblichs> cost. > erblichs> > erblichs> * Shouldn't this minimize any effects and supply > erblichs> as much activeness as possible? > > I think increasing the link cost as the link's instability increases > is not a good thing, because the OSPF cost of the link have totally > different meaning in essence. > > The OSPF's link cost have different measure compared to instability > (flapping rate), so intuitively we can't explain what does it mean > to reflect flapping rate to the OSPF cost. Reflecting flapping rate > to the OSPF cost will result that, say, we will use the flapping link > if the flapping duration is longer than every 3 second. Actual flapping > rate (or duration) that we will shift to alternative route is decided > by the alternative route's total OSPF link cost. Is that making any > sense ? I don't think so. > > The only benefit we get from manipulating OSPF cost would be > in the discussion of "leave up or leave down". If we make OSPF cost > as LsInfinity, it means that the link is up but almost down. > Using LsInfinity is good, but about reflecting flapping rate to OSPF cost, > I would disagree. Ok, its okay to disagree. Link cost is a measure of link speed, ISP's willingness to handle transit traffic, link latency, etc. I am just effectively adding a penalty to a cost ONLY IF the link is causing excessive REDs, excessive LSAs, excessive SPF calcs, .. It still says that when I say the link is up, its up AND I don't have to worry if their is an alternative route because it is unstable or the type of link that it is.. Thus, link cost gets me to use the alternative link IF IT EXISTS. > > erblichs> * As a followup, if hellos are lost and no data > erblichs> is pending to be sent out (must be implimented > erblichs> on all sides of the link), delay dropping the > erblichs> adj. I am assuming that the period of hellos > erblichs> could be too short for short periods of high > erblichs> levels of traffic. > erblichs> > erblichs> * Followup, if just a few LSAs have been sent out > erblichs> this questionable link and no hellos or acks > erblichs> have been returned, identify whether their are > erblichs> any alternatives for the queued pkts. If their > erblichs> is drop the link, else delay dropping the link? > > Why do you consider hello events ? We should consider link up/down events > or route appearing/disappearing events, not hello events. > We might postpone/defer link or route events, but we will not postpone > hello events. Further, how do you detect that a Hello packet has been > lost ? "if hellos are lost" can be detected only by timer, and it > should mean the link down event. So we don't need to consider about > hello event at all. Congestion.. If a broadcast storm was just seen, the router may have delayed processing all its hello packets! Since we assume it is an infrequent event, we just want to make sure that their are no pending hellos that would have kept it open.. > > erblichs> Thus, did BGP do the right thing? It is difficult to > erblichs> make a quick decision because TCP will rexmit lost or > erblichs> non acked pkts/segments within time. And TCP will force > erblichs> an initial handshake before data can be sent. Plus > erblichs> we are on a OSPF mail alias! > erblichs> > erblichs> Mitchell Erblich > erblichs> --------------------------- > > Detecting if the packet is lost is difficult, almost impossible. > but BGP's flap dampening does not need to detect them. > It detect only receiving update or withdrawal, and only dampening > if the duration is too short or rate is too high. > TCP is not involved if the BGP packet have already been processed. > > regards, > yasu > > erblichs> > erblichs> > erblichs> > erblichs> > erblichs> Yasuhiro Ohara wrote: > erblichs> > > erblichs> > We once checked the relation between link flapping and > erblichs> > OSPF fixed timer. In the paper we solved that by applying > erblichs> > dampening function similar with BGP's. > erblichs> > > erblichs> > http://www.sfc.wide.ad.jp/~yasu/saint2003.pdf > erblichs> > > erblichs> > The experiment was done by Zebra ospf6d. > erblichs> > Unfortunately I removed the dampening code since then, > erblichs> > because there seemed no interest. > erblichs> > > erblichs> > Let me know if you want further info. > erblichs> > > erblichs> > regards, > erblichs> > yasu > erblichs> > > erblichs> > From: Kouzengjie > erblichs> > Subject: About OSPF route flapping > erblichs> > Date: Thu, 24 Nov 2005 15:02:18 +0800 > erblichs> > > erblichs> > > hi,all > erblichs> > > How does OSPF route flapping affect? > erblichs> > > Is it important? > erblichs> > > what is the method for solving it? > erblichs> > > > erblichs> > > thanks, > erblichs> > > Kou > erblichs> > > > erblichs> From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 04 21:02:39 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuKSc-0003d5-VU for ospf-archive@megatron.ietf.org; Wed, 04 Jan 2006 21:02: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 VAA04925 for ; Wed, 4 Jan 2006 21:01: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 <0.000089DA@wildebeest.ease.lsoft.com>; Wed, 4 Jan 2006 21:02:07 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95491344 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 4 Jan 2006 21:02:07 -0500 Received: from 216.194.124.237 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 4 Jan 2006 21:02:07 -0500 Received: from [162.84.74.172] (HELO JMHLap3.stevecrocker.com) by execdsl.com (CommuniGate Pro SMTP 4.2.7) with ESMTP id 12880095 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 04 Jan 2006 18:59:20 -0700 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <006b01c5f0c5$02ab2000$72646e0a@china.huawei.com> <20051124.162840.128462062.yasu@sfc.wide.ad.jp> <43A88D9D.94F7E644@earthlink.net> <20051224.162014.07263228.yasu@sfc.wide.ad.jp> <43BC7CA8.45C24AB5@earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.2.1.2.0.20060104205744.02f89f90@mail.stevecrocker.com> Date: Wed, 4 Jan 2006 21:02:03 -0500 Reply-To: Mailing List Sender: Mailing List From: "Joel M. Halpern" Subject: Re: About OSPF route flapping To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43BC7CA8.45C24AB5@earthlink.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Actually, a) this is local policy and does not need standardization b) this is not obviously the "right" thing to do. If the link is really flapping badly, the local node might well decide to advertise it as down, on the grounds that pretending it is useful is actually misleading. I could imagine an implementation offering all sorts of knobs, if people really want them (I hope not.) Given that all of the routers within a domain are presumed to have the same policy, it seems quite sensible to declare that the router local to the problem is responsible for dealing with it. There is the argument that some mechanism would allow remote routers to cope with dumber local routers. That is a complication too be avoided, as there are many ways for a local router to misbehave. Second guessing another router in the same domain is just asking for trouble. (The MANET situations i probably even more complicated, but remote flap damping does not strike me as the right answer then either.) Yours, Joel M. Halpern At 08:55 PM 1/4/2006, Erblichs wrote: > If at the origination a "link" is decidely unstable, is > their any disagreement that when the link comes up, the > originator SHOULD advertise the link with an additionaly > unstable penalty cost? It keeps the link available for > no alternative routes versus doing nothing.. From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jan 05 03:45:44 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuQki-0006vX-Lw for ospf-archive@megatron.ietf.org; Thu, 05 Jan 2006 03:45: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 DAA12689 for ; Thu, 5 Jan 2006 03:44: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.00008A65@wildebeest.ease.lsoft.com>; Thu, 5 Jan 2006 3:45:13 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95517402 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 5 Jan 2006 03:45:13 -0500 Received: from 207.69.195.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 5 Jan 2006 03:45:13 -0500 Received: from h-68-164-85-155.snvacaid.dynamic.covad.net ([68.164.85.155] helo=earthlink.net) by pop-sarus.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1EuQkC-0004uq-00 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 05 Jan 2006 03:45:12 -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: <006b01c5f0c5$02ab2000$72646e0a@china.huawei.com> <20051124.162840.128462062.yasu@sfc.wide.ad.jp> <43A88D9D.94F7E644@earthlink.net> <20051224.162014.07263228.yasu@sfc.wide.ad.jp> <43BC7CA8.45C24AB5@earthlink.net> <6.2.1.2.0.20060104205744.02f89f90@mail.stevecrocker.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43BCE01B.1FA33306@earthlink.net> Date: Thu, 5 Jan 2006 01:00:11 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: About OSPF route flapping To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Joel Halpern, et al, First, my suggestion, past experimental implimentations are local to the link. Link costs are two directional determined by the two routers on both sides of the link. Since link costs are additive (directional per hop) only those routes that potentially pass thru those links will incure those costs. Secondary issues is the freq of changing costs that will generate new SPF calcs. The below suggested link cost scenario SHOULD minimze repeated SPF calcs. Second, I know of no other ideas that in the next below example will not decrease the up time of the link if link cost is not adjusted other than to do NOTHING. Ex: Router A's link w.x.y.z comes up and stays up for about 4 minutes at a time. After that 4 minute time period, the link goes down for 1 minute. Their are routes that are only accessible via this router's interface. It then repeats with another 4 min up time. Now in this example we will know that the link is down after the dead router timer expires (30 secs) for simplicity. And immediately after the link comes up it will send a hello without any neighbors listed. So, it is down for 30 secs at the end of our up time before we are sure that it is down. We could also use router LSAs used by the originator after the fact on the flapping interface when it is back up. Or... What do we do? 0) Do nothing.. A) If we follow the BGP like implimentation and allow the non origination router or the origination router to delay link up status notification each time, then the routes that are accessible only via this "unstable" link will have less up time when it is available. It is that simple. Any threshold will increase the link's unavailability when too agressive and will lead to repeated SPF calcs when not agressive enough.Any method of route-WITH-HOLDING MUST be used by all routers unless it was done at the originator. B) IT IS Preferable having the originator increase the cost of the link to allow routes that can transit other paths, take those other routes and those that can't be forced to rexmit or be dropped when the link is down. This allows that during that 30 sec period that we aren't sure that the router's link is down to use alternative routes when available. This also allow those routes that are only accessible thru this link to have 4 minutes of up connectivity every 5 minute period. Since the originating router can't update the link cost on this link when it is down, it is prefered that some history is kept and that the next time the link comes up a cost increase is implimented. My assumption is that a multicative increase is best while we are in periods of "instability" and slowly decrease it as we become more stable over time. 1. if the other side of the link is aware of the unstability, it can boost its link cost to allow other route paths to be used for some pkts and not pushed into the router's link for the 30secs that it takes to determine that the link is down. 2) This (boost link cost) can also be done on the router's other interfaces at the time the interface is determined down. We can do this because a percentage of pkt will enter one interface and be directed out towards the dead interface. Since only the orignator's link and the nbr's link make the link cost change, this change SHOULD be completely transparent and only infrequent additional LSAs are re-originated with different link costs. Mitchell Erblich ----------------- "Joel M. Halpern" wrote: > > Actually, > a) this is local policy and does not need standardization > b) this is not obviously the "right" thing to do. If the link is really > flapping badly, the local node might well decide to advertise it as down, > on the grounds that pretending it is useful is actually misleading. I > could imagine an implementation offering all sorts of knobs, if people > really want them (I hope not.) > > Given that all of the routers within a domain are presumed to have the same > policy, it seems quite sensible to declare that the router local to the > problem is responsible for dealing with it. > There is the argument that some mechanism would allow remote routers to > cope with dumber local routers. That is a complication too be avoided, as > there are many ways for a local router to misbehave. Second guessing > another router in the same domain is just asking for trouble. > > (The MANET situations i probably even more complicated, but remote flap > damping does not strike me as the right answer then either.) > > Yours, > Joel M. Halpern > > At 08:55 PM 1/4/2006, Erblichs wrote: > > If at the origination a "link" is decidely unstable, is > > their any disagreement that when the link comes up, the > > originator SHOULD advertise the link with an additionaly > > unstable penalty cost? It keeps the link available for > > no alternative routes versus doing nothing.. From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 09 17:26:14 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew5Sw-0008C2-Qw for ospf-archive@megatron.ietf.org; Mon, 09 Jan 2006 17:26:14 -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 RAA03638 for ; Mon, 9 Jan 2006 17:24: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 <9.0000F084@wildebeest.ease.lsoft.com>; Mon, 9 Jan 2006 17:25:39 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95843937 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 9 Jan 2006 17:25:38 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 9 Jan 2006 17:25:38 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 09 Jan 2006 17:25:38 -0500 X-IronPort-AV: i="3.99,347,1131339600"; d="scan'208"; a="79863949:sNHT28298488" 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 k09MPYJf010037 for ; Mon, 9 Jan 2006 17:25:35 -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, 9 Jan 2006 17:25:46 -0500 Received: from [10.82.241.204] ([10.82.241.204]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 Jan 2006 17:25:26 -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: 09 Jan 2006 22:25:26.0554 (UTC) FILETIME=[96FDD7A0:01C6156B] Message-ID: <43C2E2D6.4080000@cisco.com> Date: Mon, 9 Jan 2006 17:25:26 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: MOSPF - Multicast OSPF To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Consideration is being given to making MOSPF (RFC 1584) historic - Any concerns? Also, has anyone implemented MOSPFv3? I'm considering deprecating the bits in the OSPFv3 updated so they could be reused if we ever ran out. Thanks, Acee From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 09 18:04:36 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew643-0004Db-U6 for ospf-archive@megatron.ietf.org; Mon, 09 Jan 2006 18:04:36 -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 SAA06292 for ; Mon, 9 Jan 2006 18: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 <14.0000F117@wildebeest.ease.lsoft.com>; Mon, 9 Jan 2006 18:04:03 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95845820 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 9 Jan 2006 18:04:03 -0500 Received: from 64.233.162.198 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 9 Jan 2006 18:04:03 -0500 Received: by zproxy.gmail.com with SMTP id i11so3731838nzh for ; Mon, 09 Jan 2006 15:04:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=f62luk1j0PQFIHxeNSZT+v+G3VzxjGzAnKeZm8RNAgFZ+R0oUR0/8fUQS8oZwiVYLFTyRa89Sk33vGha6UgIZq/wf8LjcHOCHLlkgP6l4aBIrST6W47tPJ/ik8TkCpN+/d2Wvgd5K6LYTg7brH4zB7XmLB20gga1vRHsx5kQVPI= Received: by 10.36.157.18 with SMTP id f18mr3988nze; Mon, 09 Jan 2006 15:04:03 -0800 (PST) Received: by 10.36.141.19 with HTTP; Mon, 9 Jan 2006 15:04:03 -0800 (PST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5940_29194432.1136847843112" Message-ID: <45f8514d0601091504l6de6c163u179840629a86cf63@mail.gmail.com> Date: Mon, 9 Jan 2006 15:04:03 -0800 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: ospfv3 mib / traps Comments: cc: nitink@huawei.com, djoyal@nortel.com, vishwas@sinett.com To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: ------=_Part_5940_29194432.1136847843112 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Folks, I recently noticed draft-kakkar-ospf-ospfv3-trap-mib-00.txt (individual submission). Given that we already have ongoing ospfv3 mib as an approved w= g item in draft-ietf-ospf-ospfv3-mib-10.txt, I suggest that we have a single ospv3 mib draft that incorporated all the OSPFv3 mib data that we want to manage/maintain. I don't see any merit to having two seperate drafts for this purpose. I would encourage the author of draft-kakkar-ospf-ospfv3-trap-mib-00.txt to contact the ospfv3 mib authors to explicitly discuss ospfv3 trap data. Regards, --rohit. ------=_Part_5940_29194432.1136847843112 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Folks,

I recently noticed draft-kakkar-ospf-ospfv3-trap-mib-00.txt = (individual submission). Given that we already have ongoing ospfv3 mib as a= n approved wg item in draft-ietf-ospf-ospfv3-mib-10.txt, I suggest that we = have a single ospv3 mib draft that incorporated all the OSPFv3 mib data tha= t we want to manage/maintain. I don't see any merit to having two seperate = drafts for this purpose. I would encourage the author of=20 draft-kakkar-ospf-ospfv3-trap-mib-00.txt to contact the ospfv3 mib authors = to explicitly discuss ospfv3 trap data.

Regards,
--rohit.
------=_Part_5940_29194432.1136847843112-- From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 09 20:55:58 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew8ju-00010I-NL for ospf-archive@megatron.ietf.org; Mon, 09 Jan 2006 20:55: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 UAA21021 for ; Mon, 9 Jan 2006 20:54: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 <15.0000F3DA@wildebeest.ease.lsoft.com>; Mon, 9 Jan 2006 20:55:27 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95854526 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 9 Jan 2006 20:55:27 -0500 Received: from 207.69.195.66 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 9 Jan 2006 20:55:27 -0500 Received: from h-68-164-83-132.snvacaid.dynamic.covad.net ([68.164.83.132] helo=earthlink.net) by pop-canoe.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1Ew8jO-0005CD-00 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 09 Jan 2006 20:55:26 -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: <43C2E2D6.4080000@cisco.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43C3120C.AA6EE352@earthlink.net> Date: Mon, 9 Jan 2006 17:46:52 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: MOSPF - Multicast OSPF To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Acee, Is this an early April fools joke? Can we / should we deprecate 1349's v2's TOS bits and re-use them? What about the TOS metric? IMO, There are at least four issues here. 1) Can you deprecate a publicly specified items like the bits from a newer version? 2) Can you re-use deprecated bits? 3) Did any OSPFv3 implimnetation check for MOSPF and do anything based on the check? 4) Do you want to differentiate v2 and v3 in this manner? IMO, no for #2 and yes for #1, but then the RFC change should be moot for if you can't re-use them, why remove it from the spec? You could update the RFC that this feature is no-longer expected to be used. How does all the legacy router's customers who don't specify that they have at least checked that bit, and discard or whatever based on that bit speak up? This could obsolete these routers, if that bit was used/checked and re-used. How do defunt companies speak up? Thus, sorry, but IMO, once something is publicly RFC documented as anything but informational or experimental, it should be assumed that SOMEONE is using that feature. Mitchell Erblich ------------------- Acee Lindem wrote: > > Consideration is being given to making MOSPF (RFC 1584) > historic - Any concerns? > > Also, has anyone implemented MOSPFv3? I'm considering deprecating > the bits in the OSPFv3 updated so they could be reused if we ever ran out. > > Thanks, > Acee From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 09 22:06:03 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew9pj-0004na-0F for ospf-archive@megatron.ietf.org; Mon, 09 Jan 2006 22:06: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 WAA25620 for ; Mon, 9 Jan 2006 22:04:44 -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.0000F4E9@wildebeest.ease.lsoft.com>; Mon, 9 Jan 2006 22:05:28 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95857919 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 9 Jan 2006 22:05:28 -0500 Received: from 171.71.176.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 9 Jan 2006 22:05:28 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 09 Jan 2006 19:05:27 -0800 X-IronPort-AV: i="3.99,348,1131350400"; d="scan'208"; a="389578679:sNHT32393564" 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 k0A35QQk015713 for ; Mon, 9 Jan 2006 19:05:27 -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, 9 Jan 2006 22:05:25 -0500 Received: from [10.82.241.204] ([10.82.241.204]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 Jan 2006 22:05:25 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <43C2E2D6.4080000@cisco.com> <43C3120C.AA6EE352@earthlink.net> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jan 2006 03:05:25.0476 (UTC) FILETIME=[B3EDEA40:01C61592] Message-ID: <43C32474.2050106@cisco.com> Date: Mon, 9 Jan 2006 22:05:24 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: MOSPF - Multicast OSPF To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43C3120C.AA6EE352@earthlink.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Mitchell, See inline. Erblichs wrote: >Acee, > > Is this an early April fools joke? > > Can we / should we deprecate 1349's v2's > TOS bits and re-use them? What about the TOS > metric? > > RFC 1349 is defines TOS bits in IPv4 packet headers. Interestingly enough, this RFC has been obsoleted by the DSCP definitions in RFC 2474. > IMO, There are at least four issues here. > > 1) Can you deprecate a publicly specified items > like the bits from a newer version? > > It's been done before if the function isn't used. An example from OSPFv2, would be the TOS based routing defined in RFC 1583. > 2) Can you re-use deprecated bits? > > With OSPFv2 MTR, those same RFC 1583 TOS metric encoding were revived with different semantics. You can search the archives for a protracted discussion of the differences. > 3) Did any OSPFv3 implimnetation check for > MOSPF and do anything based on the check? > > That's what I asked. I don't know of any MOSPFv3 implementation. > 4) Do you want to differentiate v2 and v3 > in this manner? > > Yes. There are existing implementations of MOSPF (based on OSPFv2). > > > IMO, no for #2 and yes for #1, but then the > RFC change should be moot for if you can't re-use > them, why remove it from the spec? You could update > the RFC that this feature is no-longer expected to > be used. > > How does all the legacy router's customers who don't > specify that they have at least checked that bit, > and discard or whatever based on that bit speak up? > This could obsolete these routers, if that bit was > used/checked and re-used. > > How do defunt companies speak up? > > Thus, sorry, but IMO, once something is publicly > RFC documented as anything but informational or experimental, > it should be assumed that SOMEONE is using that feature. > > This is simply not the case in the IETF. While each case must be considered individually, there have been numerous instances of deprecation. Thanks, Acee > Mitchell Erblich > ------------------- > > > >Acee Lindem wrote: > > >>Consideration is being given to making MOSPF (RFC 1584) >>historic - Any concerns? >> >>Also, has anyone implemented MOSPFv3? I'm considering deprecating >>the bits in the OSPFv3 updated so they could be reused if we ever ran out. >> >>Thanks, >>Acee >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 09 22:12:32 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew9w0-0007Qi-QP for ospf-archive@megatron.ietf.org; Mon, 09 Jan 2006 22:12: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 WAA26066 for ; Mon, 9 Jan 2006 22: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 <9.0000F505@wildebeest.ease.lsoft.com>; Mon, 9 Jan 2006 22:12:02 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95858443 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 9 Jan 2006 22:12:02 -0500 Received: from 63.197.255.154 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 9 Jan 2006 22:12:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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: MOSPF - Multicast OSPF Thread-Index: AcYVa6RMyLJss+XbRoei8x7Vtu8Z1AAKB9/Q Message-ID: Date: Mon, 9 Jan 2006 19:12:00 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: MOSPF - Multicast OSPF 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, I agree with both the proposals. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee Lindem Sent: Tuesday, January 10, 2006 3:55 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: MOSPF - Multicast OSPF Consideration is being given to making MOSPF (RFC 1584) historic - Any concerns? Also, has anyone implemented MOSPFv3? I'm considering deprecating the bits in the OSPFv3 updated so they could be reused if we ever ran out. Thanks, Acee From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 09 22:16:15 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew9zZ-0008Vt-NZ for ospf-archive@megatron.ietf.org; Mon, 09 Jan 2006 22:16: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 WAA26233 for ; Mon, 9 Jan 2006 22:14: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 <2.0000F516@wildebeest.ease.lsoft.com>; Mon, 9 Jan 2006 22:15:42 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95858615 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 9 Jan 2006 22:15:42 -0500 Received: from 63.197.255.154 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 9 Jan 2006 22:15:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61594.2334D877" Thread-Topic: ospfv3 mib / traps Thread-Index: AcYVcP+Sv02a4PsjTjaenRBaSvEZAQAI7USA Message-ID: Date: Mon, 9 Jan 2006 19:15:41 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: ospfv3 mib / traps Comments: To: Rohit Dube Comments: cc: nitink@huawei.com, djoyal@nortel.com 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. ------_=_NextPart_001_01C61594.2334D877 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Rohit, =20 I agree we need to have a single MIB and that the Trap MIB needs to be incorporated into the ospfv3 MIB itself (unlike OSPFv2 where we have two different MIB's).=20 =20 Thanks, Vishwas ________________________________ From: Rohit Dube [mailto:dube.rohit@gmail.com]=20 Sent: Tuesday, January 10, 2006 4:34 AM To: Mailing List Cc: nitink@huawei.com; djoyal@nortel.com; Vishwas Manral Subject: ospfv3 mib / traps =20 Folks,=20 I recently noticed draft-kakkar-ospf-ospfv3-trap-mib-00.txt (individual submission). Given that we already have ongoing ospfv3 mib as an approved wg item in draft-ietf-ospf-ospfv3-mib-10.txt, I suggest that we have a single ospv3 mib draft that incorporated all the OSPFv3 mib data that we want to manage/maintain. I don't see any merit to having two seperate drafts for this purpose. I would encourage the author of draft-kakkar-ospf-ospfv3-trap-mib-00.txt to contact the ospfv3 mib authors to explicitly discuss ospfv3 trap data. Regards, --rohit =20 ------_=_NextPart_001_01C61594.2334D877 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi = Rohit,

 

I agree we need to have a single = MIB and that the Trap MIB needs to be incorporated into the ospfv3 MIB itself = (unlike OSPFv2 where we have two different MIB’s). =

 

Thanks,

=

Vishwas

=

From: Rohit = Dube [mailto:dube.rohit@gmail.com]
Sent: Tuesday, January = 10, 2006 4:34 AM
To: Mailing List
Cc: nitink@huawei.com; djoyal@nortel.com; Vishwas Manral
Subject: ospfv3 mib / = traps

 

Folks,

I recently noticed draft-kakkar-ospf-ospfv3-trap-mib-00.txt (individual submission). Given that we already have ongoing ospfv3 mib as an = approved wg item in draft-ietf-ospf-ospfv3-mib-10.txt, I suggest that we have a = single ospv3 mib draft that incorporated all the OSPFv3 mib data that we want = to manage/maintain. I don't see any merit to having two seperate drafts for = this purpose. I would encourage the author of draft-kakkar-ospf-ospfv3-trap-mib-00.txt to contact the ospfv3 mib = authors to explicitly discuss ospfv3 trap data.

Regards,
--rohit

 

------_=_NextPart_001_01C61594.2334D877-- From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 09 23:01:45 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwAhd-0003u7-DM for ospf-archive@megatron.ietf.org; Mon, 09 Jan 2006 23:01:45 -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 XAA28777 for ; Mon, 9 Jan 2006 23:00: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 <5.0000F5D9@wildebeest.ease.lsoft.com>; Mon, 9 Jan 2006 23:01:14 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95860826 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 9 Jan 2006 23:01:14 -0500 Received: from 61.144.161.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 9 Jan 2006 23:01:09 -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 <0ISU003OSZD5I7@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 10 Jan 2006 12:05:29 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ISU00FBNZD5F3@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 10 Jan 2006 12:05:29 +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 <0ISU006QUZIR61@szxml01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 10 Jan 2006 12:08:51 +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: <43C2E2D6.4080000@cisco.com> Message-ID: <004901c61599$8403d0e0$610c6f0a@china.huawei.com> Date: Tue, 10 Jan 2006 11:54:11 +0800 Reply-To: Mailing List Sender: Mailing List From: Zengjie Kou Subject: Re: MOSPF - Multicast OSPF To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT Hi,Acee I agree with the proposals. Thanks Kou. ----- Original Message ----- From: "Acee Lindem" To: Sent: Tuesday, January 10, 2006 6:25 AM Subject: MOSPF - Multicast OSPF > Consideration is being given to making MOSPF (RFC 1584) > historic - Any concerns? > > Also, has anyone implemented MOSPFv3? I'm considering deprecating > the bits in the OSPFv3 updated so they could be reused if we ever ran out. > > Thanks, > Acee From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jan 10 03:12:00 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwEbo-00053n-8J for ospf-archive@megatron.ietf.org; Tue, 10 Jan 2006 03:12: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 DAA13378 for ; Tue, 10 Jan 2006 03:10: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 <11.0000F9B1@wildebeest.ease.lsoft.com>; Tue, 10 Jan 2006 3:11:29 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95874141 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 10 Jan 2006 03:11:29 -0500 Received: from 207.69.195.68 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 10 Jan 2006 03:11:28 -0500 Received: from h-68-164-83-132.snvacaid.dynamic.covad.net ([68.164.83.132] helo=earthlink.net) by pop-cowbird.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1EwEbI-0003ib-00 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 10 Jan 2006 03:11:28 -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: <43C2E2D6.4080000@cisco.com> <43C3120C.AA6EE352@earthlink.net> <43C32474.2050106@cisco.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43C3596C.EA881B8D@earthlink.net> Date: Mon, 9 Jan 2006 22:51:24 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: MOSPF - Multicast OSPF To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Acee, 1584 specifies v2, and I know of 4 large players who at least checked various items such as: MC options bit, W bit within the Router LSA, Group membership type 6, etc.. I know of many v2 implimentations Doing at least some checks for these items within the recvd pkts. Acee, And to quote you "to the best of my knowledge, no new implementations." Which I assume that you are speaking of just v2 doing at least some checks.... In OSPFv3.... "ignore lsa mospf" and the like is common. Thus, if the code that determines this is based on a bit and that bit is changed for re-use, this CLI will not work. If ignore is not used then the re-use will start executing MOSPF checks.. How many router companies have at least this 1 CLI line in OSPFv3 and no longer provide updates? I bet every OSPFv3 impliimentation has the above line or its equiv. Who has a line like this in their OSPFv3 CLI? Big guys please step up. Who had a line like this in their v3 CLI? What did they check or do if NOT ignored????? This is just awareness of the MOSPF functionality and doesn't need to be FULLY implimented to make routers MIS-BEHAVE. Thus, its okay to deprecate, but I VOTE NO for any re-use that may give any bit/etc two possible public meanings.. Mitchell Erblich ---------------- Acee Lindem wrote: > > Mitchell, > See inline. > > Erblichs wrote: > > >Acee, > > > > Is this an early April fools joke? > > > > Can we / should we deprecate 1349's v2's > > TOS bits and re-use them? What about the TOS > > metric? > > > > > RFC 1349 is defines TOS bits in IPv4 packet headers. Interestingly enough, > this RFC has been obsoleted by the DSCP definitions in RFC 2474. > > > IMO, There are at least four issues here. > > > > 1) Can you deprecate a publicly specified items > > like the bits from a newer version? > > > > > It's been done before if the function isn't used. An example from OSPFv2, > would be the TOS based routing defined in RFC 1583. > > > 2) Can you re-use deprecated bits? > > > > > With OSPFv2 MTR, those same RFC 1583 TOS metric encoding were revived > with different semantics. You can search the archives for a protracted > discussion > of the differences. > > > 3) Did any OSPFv3 implimnetation check for > > MOSPF and do anything based on the check? > > > > > That's what I asked. I don't know of any MOSPFv3 implementation. > > > 4) Do you want to differentiate v2 and v3 > > in this manner? > > > > > Yes. There are existing implementations of MOSPF (based on OSPFv2). > > > > > > > IMO, no for #2 and yes for #1, but then the > > RFC change should be moot for if you can't re-use > > them, why remove it from the spec? You could update > > the RFC that this feature is no-longer expected to > > be used. > > > > How does all the legacy router's customers who don't > > specify that they have at least checked that bit, > > and discard or whatever based on that bit speak up? > > This could obsolete these routers, if that bit was > > used/checked and re-used. > > > > How do defunt companies speak up? > > > > Thus, sorry, but IMO, once something is publicly > > RFC documented as anything but informational or experimental, > > it should be assumed that SOMEONE is using that feature. > > > > > This is simply not the case in the IETF. While each case must be > considered individually, there > have been numerous instances of deprecation. > > Thanks, > Acee > > > Mitchell Erblich > > ------------------- > > > > > > > >Acee Lindem wrote: > > > > > >>Consideration is being given to making MOSPF (RFC 1584) > >>historic - Any concerns? > >> > >>Also, has anyone implemented MOSPFv3? I'm considering deprecating > >>the bits in the OSPFv3 updated so they could be reused if we ever ran out. > >> > >>Thanks, > >>Acee > >> > >> > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jan 10 16:49:04 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwRMW-0003ra-DV for ospf-archive@megatron.ietf.org; Tue, 10 Jan 2006 16:49: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 QAA11618 for ; Tue, 10 Jan 2006 16:47: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 <2.00010920@wildebeest.ease.lsoft.com>; Tue, 10 Jan 2006 16:48:33 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95938342 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 10 Jan 2006 16:48:33 -0500 Received: from 171.68.10.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 10 Jan 2006 16:48:32 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 10 Jan 2006 13:48:32 -0800 X-IronPort-AV: i="3.99,351,1131350400"; d="scan'208"; a="248179929:sNHT33724832" 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 k0ALmVQJ024209 for ; Tue, 10 Jan 2006 13:48:31 -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, 10 Jan 2006 16:48:31 -0500 Received: from [10.82.241.204] ([10.82.241.204]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 Jan 2006 16:48:30 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <43C2E2D6.4080000@cisco.com> <43C3120C.AA6EE352@earthlink.net> <43C32474.2050106@cisco.com> <43C3596C.EA881B8D@earthlink.net> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jan 2006 21:48:31.0055 (UTC) FILETIME=[98DD45F0:01C6162F] Message-ID: <43C42BAB.1000408@cisco.com> Date: Tue, 10 Jan 2006 16:48:27 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: MOSPF - Multicast OSPF To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43C3596C.EA881B8D@earthlink.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Mitchell, See inline. Erblichs wrote: >Acee, > > > 1584 specifies v2, and I know of 4 large players > who at least checked various items such as: > > MC options bit, > W bit within the Router LSA, > Group membership type 6, > etc.. > > And they can continue to do that even if we make RFC 1584 historic. > I know of many v2 implimentations Doing at least some checks for > these items within the recvd pkts. > > Acee, And to quote you > "to the best of my knowledge, no new implementations." > > Which I assume that you are speaking of just v2 doing > at least some checks.... > > In OSPFv3.... > "ignore lsa mospf" and the like is common. > Thus, if the > code that determines this is based on a bit and that bit > is changed for re-use, this CLI will not work. If ignore > is not used then the re-use will start executing MOSPF > checks.. > > How many router companies have at least this 1 CLI line > in OSPFv3 and no longer provide updates? I bet every > OSPFv3 impliimentation has the above line or its equiv. > > Since support for unknown types is implicit in OSPFv3, I would argue that this configuration is completely unnecessary. > Who has a line like this in their OSPFv3 CLI? Big guys > please step up. > > Who had a line like this in their v3 CLI? > > What did they check or do if NOT ignored????? > > This is just awareness of the MOSPF functionality and > doesn't need to be FULLY implimented to make routers > MIS-BEHAVE. > > Thus, its okay to deprecate, but I VOTE NO for any re-use > that may give any bit/etc two possible public meanings.. > > I'm less worried about code to ignore MOSPF protocols constructs (bits, LSA types, etc). In fact, deprecating them since there are MOSPFv3 implementations may allow any MOSPF specific code to be removed from OSPFv3 implementations. Acee > Mitchell Erblich > ---------------- > >Acee Lindem wrote: > > >>Mitchell, >>See inline. >> >>Erblichs wrote: >> >> >> >>>Acee, >>> >>> Is this an early April fools joke? >>> >>> Can we / should we deprecate 1349's v2's >>> TOS bits and re-use them? What about the TOS >>> metric? >>> >>> >>> >>> >>RFC 1349 is defines TOS bits in IPv4 packet headers. Interestingly enough, >>this RFC has been obsoleted by the DSCP definitions in RFC 2474. >> >> >> >>> IMO, There are at least four issues here. >>> >>> 1) Can you deprecate a publicly specified items >>> like the bits from a newer version? >>> >>> >>> >>> >>It's been done before if the function isn't used. An example from OSPFv2, >>would be the TOS based routing defined in RFC 1583. >> >> >> >>> 2) Can you re-use deprecated bits? >>> >>> >>> >>> >>With OSPFv2 MTR, those same RFC 1583 TOS metric encoding were revived >>with different semantics. You can search the archives for a protracted >>discussion >>of the differences. >> >> >> >>> 3) Did any OSPFv3 implimnetation check for >>> MOSPF and do anything based on the check? >>> >>> >>> >>> >>That's what I asked. I don't know of any MOSPFv3 implementation. >> >> >> >>> 4) Do you want to differentiate v2 and v3 >>> in this manner? >>> >>> >>> >>> >>Yes. There are existing implementations of MOSPF (based on OSPFv2). >> >> >> >>> IMO, no for #2 and yes for #1, but then the >>> RFC change should be moot for if you can't re-use >>> them, why remove it from the spec? You could update >>> the RFC that this feature is no-longer expected to >>> be used. >>> >>> How does all the legacy router's customers who don't >>> specify that they have at least checked that bit, >>> and discard or whatever based on that bit speak up? >>> This could obsolete these routers, if that bit was >>> used/checked and re-used. >>> >>> How do defunt companies speak up? >>> >>> Thus, sorry, but IMO, once something is publicly >>> RFC documented as anything but informational or experimental, >>> it should be assumed that SOMEONE is using that feature. >>> >>> >>> >>> >>This is simply not the case in the IETF. While each case must be >>considered individually, there >>have been numerous instances of deprecation. >> >>Thanks, >>Acee >> >> >> >>> Mitchell Erblich >>> ------------------- >>> >>> >>> >>>Acee Lindem wrote: >>> >>> >>> >>> >>>>Consideration is being given to making MOSPF (RFC 1584) >>>>historic - Any concerns? >>>> >>>>Also, has anyone implemented MOSPFv3? I'm considering deprecating >>>>the bits in the OSPFv3 updated so they could be reused if we ever ran out. >>>> >>>>Thanks, >>>>Acee >>>> >>>> >>>> >>>> >>> >>> >>> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jan 10 17:46:35 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwSGB-0002iH-Bt for ospf-archive@megatron.ietf.org; Tue, 10 Jan 2006 17:46: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 RAA15705 for ; Tue, 10 Jan 2006 17:45:15 -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.00010A1D@wildebeest.ease.lsoft.com>; Tue, 10 Jan 2006 17:46:03 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95942187 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 10 Jan 2006 17:46:03 -0500 Received: from 207.69.195.63 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 10 Jan 2006 17:46:03 -0500 Received: from h-68-164-83-132.snvacaid.dynamic.covad.net ([68.164.83.132] helo=earthlink.net) by pop-satin.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1EwSFe-0003Mx-00 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 10 Jan 2006 17:46: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 References: <43C2E2D6.4080000@cisco.com> <43C3120C.AA6EE352@earthlink.net> <43C32474.2050106@cisco.com> <43C3596C.EA881B8D@earthlink.net> <43C42BAB.1000408@cisco.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43C43C65.2450F538@earthlink.net> Date: Tue, 10 Jan 2006 14:59:49 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: MOSPF - Multicast OSPF To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Acee, > etc). In fact, deprecating them since there are MOSPFv3 implementations > may allow > any MOSPF specific code to be removed from OSPFv3 implementations. > No. Assume that their are routers out their with no code updates possible. Assume that someone in University has distributed over the world MOSPF OSPFv3 support in Zebra, a fork of Zebra, or a fork of the Merit consortiums implimnetation, or whatever. Why wouldn't you make this assumption? Don't change the code because my assumption is that their are legacy routers out their that have NO ONE to update the code. Second, some companies won't remove "obsolete" code because the customer expects the old check and says what if everything works fine and I add a OLD router into my network, will this old router cause my NEW ones to fail? > Since support for unknown types is implicit in OSPFv3, I would argue > that this configuration > is completely unnecessary. > > "ignore lsa mospf" and the like is common. Then WHY WHY WHY are CLI lines like these in the code and what do they do if NOT ignored? If they check bits that you re-use, then don't you agree that this would severely break a legacy router??? Else, the failure could be random, and almost impossible to trace. BTW, I somewhat AGREE that it SHOULD BE un-necesary, except, I have seen implimentations that would MININALLY spit out a message if seen and NOT ignored? Would you minimally want your buffers to fill up with bogus messages? Also, unknown types sometimes trigger a message. Why shouldn't we just ignore them? It is because we recieve them, process them, and want to know what is uncoded for being recieved on our system. thus, IMO, a CLI should be : ignore lsa unknown which should be sufficent enough and if not ignored generate a message for the above reasons.. With routers having upwards of GBs of memory and Ghz CPUs, a few extra lines should fall into the "who cares category", compared to what happens if... Thus, if it isn't causing any problems, why fix it? Now mix the legacy routers with a set of updated routers. Do the legacy routers behave properly? THUS, The only thing that would somewhat satisfy me is with any re-use. Before the re-use, have a suite of source publicly available tests that checks for abnormalies. Make these tests available. And find out whether their are heterogenous problems. If their is even 1, it should be assumed that it is "just the tip of the iceberg". Thus, is it really worth it for re-use? Are their no alternatives? Mitchell Erblich ------------------- Acee Lindem wrote: > > Mitchell, > See inline. > > Erblichs wrote: > > >Acee, > > > > > > 1584 specifies v2, and I know of 4 large players > > who at least checked various items such as: > > > > MC options bit, > > W bit within the Router LSA, > > Group membership type 6, > > etc.. > > > > > And they can continue to do that even if we make RFC 1584 historic. > > > I know of many v2 implimentations Doing at least some checks for > > these items within the recvd pkts. > > > > Acee, And to quote you > > "to the best of my knowledge, no new implementations." > > > > Which I assume that you are speaking of just v2 doing > > at least some checks.... > > > > In OSPFv3.... > > "ignore lsa mospf" and the like is common. > > Thus, if the > > code that determines this is based on a bit and that bit > > is changed for re-use, this CLI will not work. If ignore > > is not used then the re-use will start executing MOSPF > > checks.. > > > > How many router companies have at least this 1 CLI line > > in OSPFv3 and no longer provide updates? I bet every > > OSPFv3 impliimentation has the above line or its equiv. > > > > > Since support for unknown types is implicit in OSPFv3, I would argue > that this configuration > is completely unnecessary. > > > Who has a line like this in their OSPFv3 CLI? Big guys > > please step up. > > > > Who had a line like this in their v3 CLI? > > > > What did they check or do if NOT ignored????? > > > > This is just awareness of the MOSPF functionality and > > doesn't need to be FULLY implimented to make routers > > MIS-BEHAVE. > > > > Thus, its okay to deprecate, but I VOTE NO for any re-use > > that may give any bit/etc two possible public meanings.. > > > > > I'm less worried about code to ignore MOSPF protocols constructs (bits, > LSA types, > etc). In fact, deprecating them since there are MOSPFv3 implementations > may allow > any MOSPF specific code to be removed from OSPFv3 implementations. > > Acee > > > Mitchell Erblich > > ---------------- > > > >Acee Lindem wrote: > > > > > >>Mitchell, > >>See inline. > >> > >>Erblichs wrote: > >> > >> > >> > >>>Acee, > >>> > >>> Is this an early April fools joke? > >>> > >>> Can we / should we deprecate 1349's v2's > >>> TOS bits and re-use them? What about the TOS > >>> metric? > >>> > >>> > >>> > >>> > >>RFC 1349 is defines TOS bits in IPv4 packet headers. Interestingly enough, > >>this RFC has been obsoleted by the DSCP definitions in RFC 2474. > >> > >> > >> > >>> IMO, There are at least four issues here. > >>> > >>> 1) Can you deprecate a publicly specified items > >>> like the bits from a newer version? > >>> > >>> > >>> > >>> > >>It's been done before if the function isn't used. An example from OSPFv2, > >>would be the TOS based routing defined in RFC 1583. > >> > >> > >> > >>> 2) Can you re-use deprecated bits? > >>> > >>> > >>> > >>> > >>With OSPFv2 MTR, those same RFC 1583 TOS metric encoding were revived > >>with different semantics. You can search the archives for a protracted > >>discussion > >>of the differences. > >> > >> > >> > >>> 3) Did any OSPFv3 implimnetation check for > >>> MOSPF and do anything based on the check? > >>> > >>> > >>> > >>> > >>That's what I asked. I don't know of any MOSPFv3 implementation. > >> > >> > >> > >>> 4) Do you want to differentiate v2 and v3 > >>> in this manner? > >>> > >>> > >>> > >>> > >>Yes. There are existing implementations of MOSPF (based on OSPFv2). > >> > >> > >> > >>> IMO, no for #2 and yes for #1, but then the > >>> RFC change should be moot for if you can't re-use > >>> them, why remove it from the spec? You could update > >>> the RFC that this feature is no-longer expected to > >>> be used. > >>> > >>> How does all the legacy router's customers who don't > >>> specify that they have at least checked that bit, > >>> and discard or whatever based on that bit speak up? > >>> This could obsolete these routers, if that bit was > >>> used/checked and re-used. > >>> > >>> How do defunt companies speak up? > >>> > >>> Thus, sorry, but IMO, once something is publicly > >>> RFC documented as anything but informational or experimental, > >>> it should be assumed that SOMEONE is using that feature. > >>> > >>> > >>> > >>> > >>This is simply not the case in the IETF. While each case must be > >>considered individually, there > >>have been numerous instances of deprecation. > >> > >>Thanks, > >>Acee > >> > >> > >> > >>> Mitchell Erblich > >>> ------------------- > >>> > >>> > >>> > >>>Acee Lindem wrote: > >>> > >>> > >>> > >>> > >>>>Consideration is being given to making MOSPF (RFC 1584) > >>>>historic - Any concerns? > >>>> > >>>>Also, has anyone implemented MOSPFv3? I'm considering deprecating > >>>>the bits in the OSPFv3 updated so they could be reused if we ever ran out. > >>>> > >>>>Thanks, > >>>>Acee > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jan 10 21:35:02 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwVpG-0006v6-EJ for ospf-archive@megatron.ietf.org; Tue, 10 Jan 2006 21:35: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 VAA03336 for ; Tue, 10 Jan 2006 21:33: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 <0.00010DED@wildebeest.ease.lsoft.com>; Tue, 10 Jan 2006 21:34:30 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95956991 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 10 Jan 2006 21:34:30 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 10 Jan 2006 21:34:30 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 10 Jan 2006 21:34:30 -0500 X-IronPort-AV: i="3.99,352,1131339600"; d="scan'208"; a="79990138:sNHT34489536" 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 k0B2YPJh009500 for ; Tue, 10 Jan 2006 21:34:28 -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, 10 Jan 2006 21:34:34 -0500 Received: from [10.82.241.204] ([10.82.241.204]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 Jan 2006 21:34:25 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <43C2E2D6.4080000@cisco.com> <43C3120C.AA6EE352@earthlink.net> <43C32474.2050106@cisco.com> <43C3596C.EA881B8D@earthlink.net> <43C42BAB.1000408@cisco.com> <43C43C65.2450F538@earthlink.net> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jan 2006 02:34:26.0037 (UTC) FILETIME=[8A07CA50:01C61657] Message-ID: <43C46EB1.5070309@cisco.com> Date: Tue, 10 Jan 2006 21:34:25 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: MOSPF - Multicast OSPF To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43C43C65.2450F538@earthlink.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Mitchell, Erblichs wrote: >Acee, > > > >>etc). In fact, deprecating them since there are MOSPFv3 implementations >>may allow >>any MOSPF specific code to be removed from OSPFv3 implementations. >> >> >> > > No. Assume that their are routers out their with no > code updates possible. > > Assume that someone in University has distributed over > the world MOSPF OSPFv3 support in Zebra, a fork of > Zebra, or a fork of the Merit consortiums implimnetation, > or whatever. Why wouldn't you make this assumption? > > I would have heard about it :^) > Don't change the code because my assumption is that > their are legacy routers out their that have NO ONE > to update the code. > > Second, some companies won't remove "obsolete" code > because the customer expects the old check and says > what if everything works fine and I add a OLD router > into my network, will this old router cause my NEW ones > to fail? > > This assumes someone has implemented and deployed MOSPFv3. > > >>Since support for unknown types is implicit in OSPFv3, I would argue >>that this configuration >>is completely unnecessary. >> >> >>> "ignore lsa mospf" and the like is common. >>> >>> > > Then WHY WHY WHY are CLI lines like these in the code > and what do they do if NOT ignored? If they check bits > that you re-use, then don't you agree that this would > severely break a legacy router??? Else, the failure > could be random, and almost impossible to trace. > > BTW, I somewhat AGREE that it SHOULD BE un-necesary, except, > I have seen implimentations that would MININALLY spit out > a message if seen and NOT ignored? Would you minimally > want your buffers to fill up with bogus messages? > > Also, unknown types sometimes trigger a message. Why > shouldn't we just ignore them? It is because we recieve > them, process them, and want to know what is uncoded > for being recieved on our system. > > thus, IMO, a CLI should be : ignore lsa unknown > which should be sufficent enough and if not ignored > generate a message for the above reasons.. > > With routers having upwards of GBs of memory and Ghz > CPUs, a few extra lines should fall into the "who cares > category", compared to what happens if... > > Thus, if it isn't causing any problems, why fix it? > > Now mix the legacy routers with a set of updated > routers. Do the legacy routers behave properly? > > THUS, The only thing that would somewhat satisfy me is > with any re-use. Before the re-use, have a suite of > source publicly available tests that checks for > abnormalies. Make these tests available. And find out > whether their are heterogenous problems. If their is > even 1, it should be assumed that it is "just the tip > of the iceberg". > > Since we're respinning RFC 2740 anyway, it makes sense to deprecate the protocol constructs that are necessary. No sense in leaving these in OSPFv3 if no one is using them. Thanks, Acee > Thus, is it really worth it for re-use? > Are their no alternatives? > > Mitchell Erblich > ------------------- > > > >Acee Lindem wrote: > > >>Mitchell, >>See inline. >> >>Erblichs wrote: >> >> >> >>>Acee, >>> >>> >>> 1584 specifies v2, and I know of 4 large players >>> who at least checked various items such as: >>> >>> MC options bit, >>> W bit within the Router LSA, >>> Group membership type 6, >>> etc.. >>> >>> >>> >>> >>And they can continue to do that even if we make RFC 1584 historic. >> >> >> >>> I know of many v2 implimentations Doing at least some checks for >>> these items within the recvd pkts. >>> >>> Acee, And to quote you >>> "to the best of my knowledge, no new implementations." >>> >>> Which I assume that you are speaking of just v2 doing >>> at least some checks.... >>> >>> In OSPFv3.... >>> "ignore lsa mospf" and the like is common. >>> Thus, if the >>> code that determines this is based on a bit and that bit >>> is changed for re-use, this CLI will not work. If ignore >>> is not used then the re-use will start executing MOSPF >>> checks.. >>> >>> How many router companies have at least this 1 CLI line >>> in OSPFv3 and no longer provide updates? I bet every >>> OSPFv3 impliimentation has the above line or its equiv. >>> >>> >>> >>> >>Since support for unknown types is implicit in OSPFv3, I would argue >>that this configuration >>is completely unnecessary. >> >> >> >>> Who has a line like this in their OSPFv3 CLI? Big guys >>> please step up. >>> >>> Who had a line like this in their v3 CLI? >>> >>> What did they check or do if NOT ignored????? >>> >>> This is just awareness of the MOSPF functionality and >>> doesn't need to be FULLY implimented to make routers >>> MIS-BEHAVE. >>> >>> Thus, its okay to deprecate, but I VOTE NO for any re-use >>> that may give any bit/etc two possible public meanings.. >>> >>> >>> >>> >>I'm less worried about code to ignore MOSPF protocols constructs (bits, >>LSA types, >>etc). In fact, deprecating them since there are MOSPFv3 implementations >>may allow >>any MOSPF specific code to be removed from OSPFv3 implementations. >> >>Acee >> >> >> >>> Mitchell Erblich >>> ---------------- >>> >>>Acee Lindem wrote: >>> >>> >>> >>> >>>>Mitchell, >>>>See inline. >>>> >>>>Erblichs wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Acee, >>>>> >>>>> Is this an early April fools joke? >>>>> >>>>> Can we / should we deprecate 1349's v2's >>>>> TOS bits and re-use them? What about the TOS >>>>> metric? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>RFC 1349 is defines TOS bits in IPv4 packet headers. Interestingly enough, >>>>this RFC has been obsoleted by the DSCP definitions in RFC 2474. >>>> >>>> >>>> >>>> >>>> >>>>> IMO, There are at least four issues here. >>>>> >>>>> 1) Can you deprecate a publicly specified items >>>>> like the bits from a newer version? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>It's been done before if the function isn't used. An example from OSPFv2, >>>>would be the TOS based routing defined in RFC 1583. >>>> >>>> >>>> >>>> >>>> >>>>> 2) Can you re-use deprecated bits? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>With OSPFv2 MTR, those same RFC 1583 TOS metric encoding were revived >>>>with different semantics. You can search the archives for a protracted >>>>discussion >>>>of the differences. >>>> >>>> >>>> >>>> >>>> >>>>> 3) Did any OSPFv3 implimnetation check for >>>>> MOSPF and do anything based on the check? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>That's what I asked. I don't know of any MOSPFv3 implementation. >>>> >>>> >>>> >>>> >>>> >>>>> 4) Do you want to differentiate v2 and v3 >>>>> in this manner? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>Yes. There are existing implementations of MOSPF (based on OSPFv2). >>>> >>>> >>>> >>>> >>>> >>>>> IMO, no for #2 and yes for #1, but then the >>>>> RFC change should be moot for if you can't re-use >>>>> them, why remove it from the spec? You could update >>>>> the RFC that this feature is no-longer expected to >>>>> be used. >>>>> >>>>> How does all the legacy router's customers who don't >>>>> specify that they have at least checked that bit, >>>>> and discard or whatever based on that bit speak up? >>>>> This could obsolete these routers, if that bit was >>>>> used/checked and re-used. >>>>> >>>>> How do defunt companies speak up? >>>>> >>>>> Thus, sorry, but IMO, once something is publicly >>>>> RFC documented as anything but informational or experimental, >>>>> it should be assumed that SOMEONE is using that feature. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>This is simply not the case in the IETF. While each case must be >>>>considered individually, there >>>>have been numerous instances of deprecation. >>>> >>>>Thanks, >>>>Acee >>>> >>>> >>>> >>>> >>>> >>>>> Mitchell Erblich >>>>> ------------------- >>>>> >>>>> >>>>> >>>>>Acee Lindem wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Consideration is being given to making MOSPF (RFC 1584) >>>>>>historic - Any concerns? >>>>>> >>>>>>Also, has anyone implemented MOSPFv3? I'm considering deprecating >>>>>>the bits in the OSPFv3 updated so they could be reused if we ever ran out. >>>>>> >>>>>>Thanks, >>>>>>Acee >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>> >>> >>> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 11 01:01:34 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwZ38-0002JM-HH for ospf-archive@megatron.ietf.org; Wed, 11 Jan 2006 01:01:34 -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 BAA16183 for ; Wed, 11 Jan 2006 01:00: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 <4.000111D4@wildebeest.ease.lsoft.com>; Wed, 11 Jan 2006 1:01:02 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95978834 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 11 Jan 2006 01:01:02 -0500 Received: from 64.233.162.192 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 11 Jan 2006 01:01:02 -0500 Received: by zproxy.gmail.com with SMTP id i11so84322nzh for ; Tue, 10 Jan 2006 22:01:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=R9YjSLtJrP7pfMTm6Gmcnlf+WmJo9pd1xtM50VDDxDlBaEyqi3f5GdOONyE+Cm6uaOzofpNsle7iJNK9RMAcCmn4aORsQg89k4s1wXjCA4Vh0+c1DelRf1bn/5bvybOz+pCX3wHeV8NphnpeQDff7WXc3IbKcWb+1K/R2BPo878= Received: by 10.36.220.15 with SMTP id s15mr399944nzg; Tue, 10 Jan 2006 22:01:02 -0800 (PST) Received: by 10.36.141.19 with HTTP; Tue, 10 Jan 2006 22:01:01 -0800 (PST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1659_25420358.1136959261175" References: <43C2E2D6.4080000@cisco.com> <43C3120C.AA6EE352@earthlink.net> <43C32474.2050106@cisco.com> <43C3596C.EA881B8D@earthlink.net> <43C42BAB.1000408@cisco.com> <43C43C65.2450F538@earthlink.net> Message-ID: <45f8514d0601102201m71154a45ga62d774ef7da43d2@mail.gmail.com> Date: Tue, 10 Jan 2006 22:01:01 -0800 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Re: MOSPF - Multicast OSPF To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43C43C65.2450F538@earthlink.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: ------=_Part_1659_25420358.1136959261175 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Also note that back in Nov 2002, we had dropped any further protocol work o= n MOSPF (v2) at the WG meeting. If anybody has a real problem with deprecating the bits (because they are implementing MOSPFv3), now would be a good time to step forward. Best, --rohit. ------=_Part_1659_25420358.1136959261175 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Also note that back in Nov 2002, we had dropped any further protocol work o= n MOSPF (v2) at the WG meeting.

If anybody has a real problem with deprecating the bits (because they are implementing MOSPFv3), now would be a good time to step forward.

Best,
--rohit.

------=_Part_1659_25420358.1136959261175-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 11 18:03:45 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ewp0L-0004Qx-Rz for ospf-archive@megatron.ietf.org; Wed, 11 Jan 2006 18:03:45 -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 SAA22289 for ; Wed, 11 Jan 2006 18:02:25 -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.00012376@wildebeest.ease.lsoft.com>; Wed, 11 Jan 2006 18:03:13 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 96059213 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 11 Jan 2006 18:03:13 -0500 Received: from 130.76.64.48 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 11 Jan 2006 18:03:13 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id PAA07939 for ; Wed, 11 Jan 2006 15:03:12 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k0BN3CW07422 for ; Wed, 11 Jan 2006 15:03:12 -0800 (PST) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jan 2006 15:03:05 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61703.2DEC0F20" Thread-Topic: MOSPF - Multicast OSPF Thread-Index: AcYWdGku1kJF8MART7uk1VwsiAMgMwAjUncg X-OriginalArrivalTime: 11 Jan 2006 23:03:05.0219 (UTC) FILETIME=[2E164530:01C61703] Message-ID: <77F357662F8BFA4CA7074B0410171B6DC9E8C9@XCH-NW-5V1.nw.nos.boeing.com> Date: Wed, 11 Jan 2006 15:03:04 -0800 Reply-To: Mailing List Sender: Mailing List From: "Henderson, Thomas R" Subject: Re: MOSPF - Multicast OSPF 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. ------_=_NextPart_001_01C61703.2DEC0F20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I missed this thread when it was on rtg-dir in December, else would have commented there. =20 We have used MOSPF in MANET experiments in the past (Moy's implementation) and found it was convenient in that environment. Once you have an efficient OSPF for MANET, why run a separate multicast routing protocol if you can avoid it? =20 So unless there is a bit crisis, I think it may be prudent to keep the bits for the time being, since OSPF for MANET is IPv6 only. =20 Tom ________________________________ From: Rohit Dube [mailto:dube.rohit@GMAIL.COM]=20 Sent: Tuesday, January 10, 2006 10:01 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: MOSPF - Multicast OSPF =09 =09 Also note that back in Nov 2002, we had dropped any further protocol work on MOSPF (v2) at the WG meeting. If anybody has a real problem with deprecating the bits (because they are implementing MOSPFv3), now would be a good time to step forward. Best, --rohit. ------_=_NextPart_001_01C61703.2DEC0F20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I missed this thread when it was on rtg-dir = in=20 December, else would have commented there.
 
We have used MOSPF in MANET experiments in = the past=20 (Moy's implementation) and found it was convenient in that = environment. =20 Once you have an efficient OSPF for MANET, why run a separate multicast = routing=20 protocol if you can avoid it?
 
So unless there is a bit crisis, I think it = may be=20 prudent to keep the bits for the time being, since OSPF for MANET is = IPv6=20 only.
 
Tom

From: Rohit Dube = [mailto:dube.rohit@GMAIL.COM]=20
Sent: Tuesday, January 10, 2006 10:01 PM
To:=20 OSPF@PEACH.EASE.LSOFT.COM
Subject: Re: MOSPF - Multicast=20 OSPF

Also note that back in Nov 2002, we had dropped any further = protocol work=20 on MOSPF (v2) at the WG meeting.

If anybody has a real problem = with=20 deprecating the bits (because they are implementing MOSPFv3), now would = be a=20 good time to step = forward.

Best,
--rohit.

------_=_NextPart_001_01C61703.2DEC0F20-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jan 12 10:17:12 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex4CO-000185-PQ for ospf-archive@megatron.ietf.org; Thu, 12 Jan 2006 10:17: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 KAA23731 for ; Thu, 12 Jan 2006 10:15: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 <15.00013299@wildebeest.ease.lsoft.com>; Thu, 12 Jan 2006 10:16:41 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 96117594 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 12 Jan 2006 10:16:41 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 12 Jan 2006 10:16:41 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 12 Jan 2006 07:16:40 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,360,1131350400"; d="scan'208"; a="19595653:sNHT23263004" 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 k0CFGB6X018584; Thu, 12 Jan 2006 10:16:32 -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); Thu, 12 Jan 2006 10:16:26 -0500 Received: from [10.82.217.22] ([10.82.217.22]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 Jan 2006 10:16:31 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <4m1t2v$8jkeh7@sj-inbound-a.cisco.com> Content-Type: text/plain; charset=GB2312 X-OriginalArrivalTime: 12 Jan 2006 15:16:31.0167 (UTC) FILETIME=[2ABEACF0:01C6178B] Message-ID: <43C672CE.2010102@cisco.com> Date: Thu, 12 Jan 2006 10:16:30 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: about ospfv3 neighbor Interface ID change Comments: To: =?GB2312?B?u8az57H1?= Comments: cc: jmoy@sycamorenet.com, dennis@juniper.net To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <4m1t2v$8jkeh7@sj-inbound-a.cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA23731 Hi =BB=C6=B3=E7=B1=F5, >RFC2740 > >3.4.3 Originating LSAs > >...... > >The Interface ID of a neighbor changes. This may cause a new=20 > >instance of a router-LSA to be originated for the associated area,=20 > >and the reorigination of one or more intra-area-prefix-LSAs. > > ...... > >=20 > >draft-ietf-ospf-ospfv3-update-06.txt > >=20 > >3.4.3 Originating LSAs > >=20 > > ...... > > o The Interface ID of a neighbor changes. This may cause a new > > instance of a router-LSA to be originated for the associated area. > > ...... > > =20 > >=20 > >my suggestion: > > 3.4.3 Originating LSAs > >...... > >The Interface ID of a neighbor changes. This may cause a new=20 > >instance of a router-LSA to be originated for the associated area,=20 > >and the intra-area-prefix-LSA to be originated for the link with the >neighbor.=20 > =20 > The change of a neighbor ID in and of itself doesn't effect the contents of the intra-area-prefix-LSA. A neighbor ID change may cause the adjacency to flap which may, in turn, result in other LSA changes but that is a secondary effect. Also, in text that I changed I've avoided stringing together multiple independent clauses with commas. I believe the modified text reads better. > ...... > >=20 > > 3.4.3.7 Intra-Area-Prefix-LSAs > >=20 > > ...... > > 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 and the link-LSA=A1=AFs Link State ID is the same with the nei= ghbor's >interface ID,=20 > =20 > I guess I could add the check for interface ID. Only link-LSAs scoped to = the link are considered. It is the neighbor's responsibility to flush any stale self-originated lnk-LSAs and originate one with the correct Link State ID (i.e., his interface ID). Thanks, Acee >the list of prefixes in the link-LSA is copied into the > > intra-area-prefix-LSA that is being built. > > =A1=AD=A1=AD > >=20 > >=BB=C6=B3=E7=B1=F5 =B8=A3=BD=A8=D0=C7=CD=F8=C8=F1=BD=DD=CD=F8=C2=E7=BF=C6= =BC=BC=D3=D0=CF=DE=B9=AB=CB=BE=CD=F8=C2=E7=B2=FA=C6=B7=D1=D0=BE=BF7=B2=BF >TEL: 0591-83057317 >ADDR: =B8=A3=D6=DD=CA=D0=BD=F0=C9=BD=B4=F3=B5=C0618=BA=C5=E9=D9=D4=B0=D6= =DE20-22#=D0=C7=CD=F8=C8=F1=BD=DD=BF=C6=BC=BC=D4=B022#=C8=FD=B2=E3=20 >URL=A3=BAhttp://www.ruijie.com.cn/ > >=20 > > > =20 > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jan 12 16:02:50 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex9aq-0001Vf-5y for ospf-archive@megatron.ietf.org; Thu, 12 Jan 2006 16:02: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 QAA19822 for ; Thu, 12 Jan 2006 16:01:25 -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.00013910@wildebeest.ease.lsoft.com>; Thu, 12 Jan 2006 16:02:15 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 96141387 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 12 Jan 2006 16:02:15 -0500 Received: from 209.119.1.41 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 12 Jan 2006 15:52:15 -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 <12.00043932@LIME.ease.lsoft.com>; Thu, 12 Jan 2006 15:51:27 -0500 Message-ID: Date: Thu, 12 Jan 2006 15:52:15 -0500 Reply-To: Mailing List Sender: Mailing List From: Ramesh Kandula Subject: Question about OSPF graceful restart To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Hi all, Can a router generate multiple grace-lsas with different restart reasons during OSPF graceful restart? Thanks in advance Ramesh From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jan 12 19:00:34 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExCMs-0003XI-6v for ospf-archive@megatron.ietf.org; Thu, 12 Jan 2006 19:00:34 -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 SAA08789 for ; Thu, 12 Jan 2006 18:59:12 -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.00013C16@wildebeest.ease.lsoft.com>; Thu, 12 Jan 2006 19:00:02 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 96152786 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 12 Jan 2006 19:00:01 -0500 Received: from 171.71.176.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 12 Jan 2006 19:00:00 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 12 Jan 2006 16:00:01 -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 k0CNxwk3001223 for ; Thu, 12 Jan 2006 16:00: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); Thu, 12 Jan 2006 18:59:48 -0500 Received: from [10.82.217.22] ([10.82.217.22]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 Jan 2006 18:59:48 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <77F357662F8BFA4CA7074B0410171B6DC9E8C9@XCH-NW-5V1.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jan 2006 23:59:48.0727 (UTC) FILETIME=[45262070:01C617D4] Message-ID: <43C6ED74.5070506@cisco.com> Date: Thu, 12 Jan 2006 18:59:48 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: MOSPF - Multicast OSPF To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <77F357662F8BFA4CA7074B0410171B6DC9E8C9@XCH-NW-5V1.nw.nos.boeing.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Hi Tom, Henderson, Thomas R wrote: >I missed this thread when it was on rtg-dir in December, else would have >commented there. > > This is as good a time as any to comment. I haven't made any changes to the OSPFv3 update draft :^) > >We have used MOSPF in MANET experiments in the past (Moy's >implementation) and found it was convenient in that environment. Once >you have an efficient OSPF for MANET, why run a separate multicast >routing protocol if you can avoid it? > > I guess for the same reasons you run a separate multicast protocol in a non-MANET (wired) environment. However, the decision for wired networks was made a long time ago and perhaps today's technologies and the differences in the MANET environment would yield a different answer. > >So unless there is a bit crisis, I think it may be prudent to keep the >bits for the time being, since OSPF for MANET is IPv6 only. > > So, you feel that there is a chance that MOSPFv3 may be fully specified and implemented for MANET networks sometime in the future (1-4 years). Correct? If there is serious consideration of this work, I'll leave the MOSPF specific bits in the OSPFv3 draft. Any other comments? Thanks, Acee > >Tom > > >________________________________ > > From: Rohit Dube [mailto:dube.rohit@GMAIL.COM] > Sent: Tuesday, January 10, 2006 10:01 PM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: MOSPF - Multicast OSPF > > > >Also note that back in Nov 2002, we had dropped any further protocol >work on MOSPF (v2) at the WG meeting. > >If anybody has a real problem with deprecating the bits (because they >are implementing MOSPFv3), now would be a good time to step forward. > >Best, >--rohit. > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jan 12 19:08:11 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExCUE-0006hI-R5 for ospf-archive@megatron.ietf.org; Thu, 12 Jan 2006 19:08: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 TAA10623 for ; Thu, 12 Jan 2006 19: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 <5.00013C42@wildebeest.ease.lsoft.com>; Thu, 12 Jan 2006 19:07:38 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 96153192 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 12 Jan 2006 19:07:38 -0500 Received: from 143.209.238.161 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 12 Jan 2006 19:07:38 -0500 Received: from mvrelay.mv.usa.alcatel.com (mvrelay.mv.usa.alcatel.com [128.251.10.15]) by audl951.usa.alcatel.com (ALCANET) with ESMTP id k0D07b9w021310; Thu, 12 Jan 2006 18:07:37 -0600 Received: from SPEEDY1PC (localhost [127.0.0.1]) by mvrelay.mv.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id k0D07rQu028268; Thu, 12 Jan 2006 16:07:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-index: AcYX1HA6XNmQPfsOTuWmxdJiGHQIvQAAJe4w X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 Message-ID: <200601130007.k0D07rQu028268@mvrelay.mv.usa.alcatel.com> Date: Thu, 12 Jan 2006 16:07:35 -0800 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: Question about OSPF graceful restart Comments: To: Ramesh Kandula 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 Since grace LSAs are link-local in scope and associated with one and only neighbor on that link, if the receiving router (aka the helper) stores the restart reason, I suppose that the reasons "could" be different on each interface. The specifics of what implementations do with the restart reason has not been included in the RFC so there are no clauses restricting different reasons in different grace LSAs from the same restarting router. -don -----Original Message----- From: owner-ospf@PEACH.EASE.LSOFT.COM [mailto:owner-ospf@PEACH.EASE.LSOFT.COM] On Behalf Of Ramesh Kandula Sent: Thursday, January 12, 2006 12:52 PM To: OSPF@PEACH.EASE.LSOFT.COM Cc: Ramesh Kandula Subject: Question about OSPF graceful restart Hi all, Can a router generate multiple grace-lsas with different restart reasons during OSPF graceful restart? Thanks in advance Ramesh From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jan 12 19:49:31 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExD8F-0008VP-Cy for ospf-archive@megatron.ietf.org; Thu, 12 Jan 2006 19:49: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 TAA14057 for ; Thu, 12 Jan 2006 19:48: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 <2.00013CE0@wildebeest.ease.lsoft.com>; Thu, 12 Jan 2006 19:48:59 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 96155399 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 12 Jan 2006 19:48:59 -0500 Received: from 209.119.1.41 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 12 Jan 2006 19:48:58 -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.0007EE64@LIME.ease.lsoft.com>; Thu, 12 Jan 2006 19:48:11 -0500 Message-ID: Date: Thu, 12 Jan 2006 19:48:56 -0500 Reply-To: Mailing List Sender: Mailing List From: Ramesh Kandula Subject: Re: Question about OSPF graceful restart To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Don, Thanks for the reply. That makes sense. However, I am looking at a scenario where the router is originating multiple grace-lsas with different reasons over the same interface. Is this allowed? The setup consists of two routers on an Etherent segment. OSPF is enabled on both of them. After a full adjacency is established, one of the routers control plane is restarted gracefully. I observed that the restarting router is sending two grace-lsas with different restart reasons (Software Upgrace/Reload and Software Restart). I confirmed this both on restarting router as well as the helper router. ramesh From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jan 12 19:52:52 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExDBT-0001EL-SH for ospf-archive@megatron.ietf.org; Thu, 12 Jan 2006 19:52: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 TAA14324 for ; Thu, 12 Jan 2006 19:51: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 <15.00013CE7@wildebeest.ease.lsoft.com>; Thu, 12 Jan 2006 19:52:21 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 96155814 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 12 Jan 2006 19:52:20 -0500 Received: from 143.209.238.161 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 12 Jan 2006 19:52:20 -0500 Received: from mvrelay.mv.usa.alcatel.com (mvrelay.mv.usa.alcatel.com [128.251.10.15]) by audl951.usa.alcatel.com (ALCANET) with ESMTP id k0D0qJBZ023807; Thu, 12 Jan 2006 18:52:19 -0600 Received: from SPEEDY1PC (localhost [127.0.0.1]) by mvrelay.mv.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id k0D0qaQu028470; Thu, 12 Jan 2006 16:52:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-index: AcYX2yrNZhXknmpvSXKoAt2OTOiNNwAAFSYA X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 Message-ID: <200601130052.k0D0qaQu028470@mvrelay.mv.usa.alcatel.com> Date: Thu, 12 Jan 2006 16:52:18 -0800 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: Question about OSPF graceful restart Comments: To: Ramesh Kandula 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 If the sequence # is different, then this would be completely acceptible. The helper should update the restart reason in this case based upon the new data. -don -----Original Message----- From: owner-ospf@PEACH.EASE.LSOFT.COM [mailto:owner-ospf@PEACH.EASE.LSOFT.COM] On Behalf Of Ramesh Kandula Sent: Thursday, January 12, 2006 4:49 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Question about OSPF graceful restart Don, Thanks for the reply. That makes sense. However, I am looking at a scenario where the router is originating multiple grace-lsas with different reasons over the same interface. Is this allowed? The setup consists of two routers on an Etherent segment. OSPF is enabled on both of them. After a full adjacency is established, one of the routers control plane is restarted gracefully. I observed that the restarting router is sending two grace-lsas with different restart reasons (Software Upgrace/Reload and Software Restart). I confirmed this both on restarting router as well as the helper router. ramesh From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jan 12 19:59:05 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExDHV-00034k-6s for ospf-archive@megatron.ietf.org; Thu, 12 Jan 2006 19:59: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 TAA14781 for ; Thu, 12 Jan 2006 19:57:44 -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.00013CDD@wildebeest.ease.lsoft.com>; Thu, 12 Jan 2006 19:58:34 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 96156214 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 12 Jan 2006 19:58:34 -0500 Received: from 209.119.1.41 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 12 Jan 2006 19:58: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 <9.00043E0B@LIME.ease.lsoft.com>; Thu, 12 Jan 2006 19:57:46 -0500 Message-ID: Date: Thu, 12 Jan 2006 19:58:29 -0500 Reply-To: Mailing List Sender: Mailing List From: Ramesh Kandula Subject: Re: Question about OSPF graceful restart To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Don, That is exactly what I thought. However, the sequence number is not incremented. So sometimes the helper router thinks it has a more recent version of grace-lsa (since sequence numbers are same, it boils to down checksum) when it receives a grace-lsa with a different reason and keeps on sending lsa updates to the restarting router. ramesh From owner-ospf@PEACH.EASE.LSOFT.COM Thu Jan 12 20:54:00 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExE8d-0003hU-RU for ospf-archive@megatron.ietf.org; Thu, 12 Jan 2006 20:54: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 UAA18854 for ; Thu, 12 Jan 2006 20:52: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 <7.00013DF0@wildebeest.ease.lsoft.com>; Thu, 12 Jan 2006 20:53:27 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 96158714 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 12 Jan 2006 20:53:27 -0500 Received: from 207.69.195.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 12 Jan 2006 20:53:27 -0500 Received: from h-68-164-83-132.snvacaid.dynamic.covad.net ([68.164.83.132] helo=earthlink.net) by pop-altamira.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1ExE86-0006TY-00 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 12 Jan 2006 20:53:27 -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: <77F357662F8BFA4CA7074B0410171B6DC9E8C9@XCH-NW-5V1.nw.nos.boeing.com> <43C6ED74.5070506@cisco.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43C70AE8.4052557C@earthlink.net> Date: Thu, 12 Jan 2006 18:05:28 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: draft comments : Re: MOSPF - Multicast OSPF 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, Here are my first few comments. I will give you more this weekend if my reading is to your aggreement. 1) A.4 LSA formats "defines seven distinct types of LSAs." A.4.2.1 LSA Type : lists 9 types, thus seven -> nine 2) 3.1.3 Neighbor Data Structure Neighbor's Backup Designated Router The neighbor's choice of Designated Router is now encoded as a Router ID instead of as an IP address. Insert Backup between : Designated Router, because we are talking about the BDR. Or have you now the the same router ID for the DR and BDR? :^) 3) 3.2.1.1 Sending Hello packets and the DC-bit is set if and only if the router wishes to suppress the sending of future Hellos over the interface (see [DEMAND]). ONLY after an a "full" adj has been established ?????? 4) transparent functional suggestions to possibly improve convergence, the first hello pkt can be sent the moment the interface becomes active if like routers are used and their is a concern for hello xmit synchronization, after the first hello is sent randomize just the next hello between 0 and the hello interval, then send hellos at the hello interval 5) 3.4.3.2 Network-LSAs "having two or more attached routers" to having one or more attached routers each having a adjacency with the DR. Mitchell Erblich --------------------- Acee Lindem wrote: > > Hi Tom, > > Henderson, Thomas R wrote: > > >I missed this thread when it was on rtg-dir in December, else would have > >commented there. > > > > > This is as good a time as any to comment. I haven't made any changes to > the OSPFv3 update draft :^) > > > > >We have used MOSPF in MANET experiments in the past (Moy's > >implementation) and found it was convenient in that environment. Once > >you have an efficient OSPF for MANET, why run a separate multicast > >routing protocol if you can avoid it? > > > > > I guess for the same reasons you run a separate multicast protocol in a > non-MANET (wired) > environment. However, the decision for wired networks was made a long > time ago and > perhaps today's technologies and the differences in the MANET environment > would yield a different answer. > > > > >So unless there is a bit crisis, I think it may be prudent to keep the > >bits for the time being, since OSPF for MANET is IPv6 only. > > > > > So, you feel that there is a chance that MOSPFv3 may be fully specified > and implemented for > MANET networks sometime in the future (1-4 years). Correct? If there is > serious > consideration of this work, I'll leave the MOSPF specific bits in the > OSPFv3 draft. Any > other comments? > > Thanks, > Acee > > > > >Tom > > > > > >________________________________ > > > > From: Rohit Dube [mailto:dube.rohit@GMAIL.COM] > > Sent: Tuesday, January 10, 2006 10:01 PM > > To: OSPF@PEACH.EASE.LSOFT.COM > > Subject: Re: MOSPF - Multicast OSPF > > > > > > > >Also note that back in Nov 2002, we had dropped any further protocol > >work on MOSPF (v2) at the WG meeting. > > > >If anybody has a real problem with deprecating the bits (because they > >are implementing MOSPFv3), now would be a good time to step forward. > > > >Best, > >--rohit. > > > > > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 13 02:28:17 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExJM8-0001b3-RE for ospf-archive@megatron.ietf.org; Fri, 13 Jan 2006 02:28: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 CAA09082 for ; Fri, 13 Jan 2006 02:26: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 <1.000142F0@wildebeest.ease.lsoft.com>; Fri, 13 Jan 2006 2:27:45 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 96178618 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 13 Jan 2006 02:27:44 -0500 Received: from 130.76.96.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 13 Jan 2006 02:27:44 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id BAA26073 for ; Fri, 13 Jan 2006 01:27:44 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k0D7RiN15625 for ; Fri, 13 Jan 2006 01:27:44 -0600 (CST) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jan 2006 23:27:41 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: MOSPF - Multicast OSPF Thread-Index: AcYX1ih8gyRAEnrCQkWpUzSZ9xLpdAAOsV8Q X-OriginalArrivalTime: 13 Jan 2006 07:27:41.0299 (UTC) FILETIME=[D6733430:01C61812] Message-ID: <77F357662F8BFA4CA7074B0410171B6DC9E8DC@XCH-NW-5V1.nw.nos.boeing.com> Date: Thu, 12 Jan 2006 23:27:41 -0800 Reply-To: Mailing List Sender: Mailing List From: "Henderson, Thomas R" Subject: Re: MOSPF - Multicast OSPF To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable > > > So, you feel that there is a chance that MOSPFv3 may be fully=20 > specified=20 > and implemented for > MANET networks sometime in the future (1-4 years). Correct?=20 I don't know what the prospects are for such work, although maybe we might turn some attention there once the unicast MANET work is more settled. What I can say is that, in some environments where OSPF MANET is likely to be attractive, multicast is also needed. We have in fact conducted demos using an earlier version of OSPF MANET, complemented by MOSPF(v2). The SMF work is the other MANET multicast work at present, but it also relies on protocol to elect a relay set, and doesn't have mechanism for managing group membership, so it may be the case that MOSPFv3 makes more sense than SMF if one is already doing OSPFv3 MANET. Tom From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 13 14:20:00 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExUSt-0007eH-US for ospf-archive@megatron.ietf.org; Fri, 13 Jan 2006 14:20: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 OAA29854 for ; Fri, 13 Jan 2006 14:18: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 <10.00014EAE@wildebeest.ease.lsoft.com>; Fri, 13 Jan 2006 14:19:27 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 96233285 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 13 Jan 2006 14:19:28 -0500 Received: from 207.69.195.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 13 Jan 2006 14:19:28 -0500 Received: from h-68-164-83-132.snvacaid.dynamic.covad.net ([68.164.83.132] helo=earthlink.net) by pop-borzoi.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1ExUSL-0005el-00 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 13 Jan 2006 14:19: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: <77F357662F8BFA4CA7074B0410171B6DC9E8C9@XCH-NW-5V1.nw.nos.boeing.com> <43C6ED74.5070506@cisco.com> <43C70AE8.4052557C@earthlink.net> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43C800B4.90FA9D51@earthlink.net> Date: Fri, 13 Jan 2006 11:34:12 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: draft comments : 2740 update: Re: MOSPF - Multicast OSPF To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit group, yes, these are suggested comments to the 2740 revision.. Mitchell Erblich ----------------- Erblichs wrote: > > Acee, et, al, > > Here are my first few comments. I will give you more > this weekend if my reading is to your aggreement. > > 1) > A.4 LSA formats > "defines seven distinct types of LSAs." > > A.4.2.1 LSA Type : lists 9 types, thus seven -> nine > > 2) > 3.1.3 Neighbor Data Structure > > > Neighbor's Backup Designated Router > > The neighbor's choice of Designated Router is now encoded as a > Router ID instead of as an IP address. > > Insert Backup between : Designated Router, because we are > talking about the BDR. Or have you now the the same router > ID for the DR and BDR? :^) ... choice of Backup Designated Router .... > > 3) > 3.2.1.1 Sending Hello packets > > and the DC-bit is set if > and only if the router wishes to suppress the sending of future > Hellos over the interface (see [DEMAND]). > > ONLY after an a "full" adj has been established ?????? as I am assuming that hello supression should not be done until after at least 2-way state is attempted to be achieved. No, I am not 100% sure whether hellos should be sent on a DC link if their is a hello mismatch at the normal hello-interval or some less freq 2x interval should be chosen. Cost versus reliability / notification. Thus, it is assumed that the repeated hellos on a DC link could be an indication that a adj hasn't formed. Need to ask the DC authors.. > > 4) transparent functional suggestions > > to possibly improve convergence, the first hello pkt can > be sent the moment the interface becomes active > > if like routers are used and their is a concern for > hello xmit synchronization, after the first hello is > sent randomize just the next hello between 0 and the > hello interval, then send hellos at the hello interval > > 5) > 3.4.3.2 Network-LSAs > > "having two or more attached routers" > > to > > having one or more attached routers each having a adjacency > with the DR. oh... should be full adjacency... > > Mitchell Erblich > --------------------- > > Acee Lindem wrote: > > > > Hi Tom, > > > > Henderson, Thomas R wrote: > > > > >I missed this thread when it was on rtg-dir in December, else would have > > >commented there. > > > > > > > > This is as good a time as any to comment. I haven't made any changes to > > the OSPFv3 update draft :^) > > > > > > > >We have used MOSPF in MANET experiments in the past (Moy's > > >implementation) and found it was convenient in that environment. Once > > >you have an efficient OSPF for MANET, why run a separate multicast > > >routing protocol if you can avoid it? > > > > > > > > I guess for the same reasons you run a separate multicast protocol in a > > non-MANET (wired) > > environment. However, the decision for wired networks was made a long > > time ago and > > perhaps today's technologies and the differences in the MANET environment > > would yield a different answer. > > > > > > > >So unless there is a bit crisis, I think it may be prudent to keep the > > >bits for the time being, since OSPF for MANET is IPv6 only. > > > > > > > > So, you feel that there is a chance that MOSPFv3 may be fully specified > > and implemented for > > MANET networks sometime in the future (1-4 years). Correct? If there is > > serious > > consideration of this work, I'll leave the MOSPF specific bits in the > > OSPFv3 draft. Any > > other comments? > > > > Thanks, > > Acee > > > > > > > >Tom > > > > > > > > >________________________________ > > > > > > From: Rohit Dube [mailto:dube.rohit@GMAIL.COM] > > > Sent: Tuesday, January 10, 2006 10:01 PM > > > To: OSPF@PEACH.EASE.LSOFT.COM > > > Subject: Re: MOSPF - Multicast OSPF > > > > > > > > > > > >Also note that back in Nov 2002, we had dropped any further protocol > > >work on MOSPF (v2) at the WG meeting. > > > > > >If anybody has a real problem with deprecating the bits (because they > > >are implementing MOSPFv3), now would be a good time to step forward. > > > > > >Best, > > >--rohit. > > > > > > > > > > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 13 16:00:37 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExW2H-0000iJ-AD for ospf-archive@megatron.ietf.org; Fri, 13 Jan 2006 16:00: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 PAA08389 for ; Fri, 13 Jan 2006 15:59: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 <9.0001507F@wildebeest.ease.lsoft.com>; Fri, 13 Jan 2006 16:00:03 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 96239131 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 13 Jan 2006 16:00:02 -0500 Received: from 132.151.6.50 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 13 Jan 2006 15:50:02 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ExVs1-0002Bq-Q6; Fri, 13 Jan 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-ID: Date: Fri, 13 Jan 2006 15:50:01 -0500 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-mt-05.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-05.txt Pages : 23 Date : 2006-1-13 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-05.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-05.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-05.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-1-13135818.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-mt-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-mt-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-13135818.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 13 16:38:19 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExWcl-0001Qx-8J for ospf-archive@megatron.ietf.org; Fri, 13 Jan 2006 16:38: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 QAA13383 for ; Fri, 13 Jan 2006 16:36: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 <7.00015125@wildebeest.ease.lsoft.com>; Fri, 13 Jan 2006 16:37:48 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 96242747 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 13 Jan 2006 16:37:47 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 13 Jan 2006 16:37:47 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 13 Jan 2006 13:37:47 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,366,1131350400"; d="scan'208"; a="19708536:sNHT22732504" 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 k0DLbi6H005681 for ; Fri, 13 Jan 2006 16:37: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, 13 Jan 2006 16:37:42 -0500 Received: from [10.82.217.22] ([10.82.217.22]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 Jan 2006 16:37:38 -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 Jan 2006 21:37:39.0015 (UTC) FILETIME=[93751D70:01C61889] Message-ID: <43C81DA2.30807@cisco.com> Date: Fri, 13 Jan 2006 16:37:38 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Question about 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 Ramesh Kandula wrote: >Don, > >That is exactly what I thought. However, the sequence number is not >incremented. > >So sometimes the helper router thinks it has a more recent version of >grace-lsa (since sequence numbers are same, it boils to down checksum) >when it receives a grace-lsa with a different reason and keeps on sending >lsa updates to the restarting router. > > Ramesh, The restarting router shouldn't multiple grace-LSAs with the same sequence number and different contents. If it restarts multiple times and encouters a stale grace LSA, it should increment the sequence number and re-orginate its most recent version. Thanks, Acee >ramesh > > > From owner-ospf@PEACH.EASE.LSOFT.COM Sun Jan 15 10:04:40 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ey9Qt-000089-9e for ospf-archive@megatron.ietf.org; Sun, 15 Jan 2006 10:04:40 -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 KAA28614 for ; Sun, 15 Jan 2006 10:03:15 -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.00015B5C@wildebeest.ease.lsoft.com>; Sat, 14 Jan 2006 4:00:27 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 96432258 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 14 Jan 2006 04:00:26 -0500 Received: from 203.91.193.32 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 14 Jan 2006 01:19:00 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 32DCC20875; Sat, 14 Jan 2006 10:48:47 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id C4EB821181; Sat, 14 Jan 2006 10:28:58 +0530 (IST) Received: from mail pickup service by blr-ec-bh02.wipro.com with Microsoft SMTPSVC; Sat, 14 Jan 2006 04:53:33 +0530 Received: from blr-ec-bh01.wipro.com ([10.201.50.91]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Jan 2006 02:47:51 +0530 Received: from wip-ectls-mx17.wipro.com ([203.91.193.27]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Jan 2006 02:37:44 +0530 Received: from wip-ectls-mx6.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3DFA214AB4D; Sat, 14 Jan 2006 02:37:08 +0530 (IST) Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by wip-ectls-mx6.wipro.com (Postfix) with ESMTP id 65ED611AE44; Sat, 14 Jan 2006 02:37:06 +0530 (IST) Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExVsJ-0005eQ-UH; Fri, 13 Jan 2006 15:50:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExVs4-0005Wh-Ob for i-d-announce@megatron.ietf.org; Fri, 13 Jan 2006 15:50:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06089 for ; Fri, 13 Jan 2006 15:48:41 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ExVzQ-0002jL-Gx for i-d-announce@ietf.org; Fri, 13 Jan 2006 15:57:41 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ExVs1-0002Bq-Q6; Fri, 13 Jan 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: i-d-announce.ietf.org Errors-To: i-d-announce-bounces@ietf.org X-OriginalArrivalTime: 13 Jan 2006 21:07:44.0012 (UTC) FILETIME=[658D64C0:01C61885] Message-ID: Date: Fri, 13 Jan 2006 15:50:01 -0500 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-mt-05.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM 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-05.txt Pages : 23 Date : 2006-1-13 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-05.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-05.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-05.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-1-13135818.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-mt-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-mt-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-13135818.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 18 16:38:09 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzL0L-000797-A3 for ospf-archive@megatron.ietf.org; Wed, 18 Jan 2006 16:38: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 QAA06405 for ; Wed, 18 Jan 2006 16:36: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 <11.0001BE78@wildebeest.ease.lsoft.com>; Wed, 18 Jan 2006 16:37:35 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 96980965 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 18 Jan 2006 16:37:35 -0500 Received: from 171.68.10.86 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 18 Jan 2006 16:37:35 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 18 Jan 2006 13:37:33 -0800 X-IronPort-AV: i="3.99,381,1131350400"; d="scan'208"; a="1767880825:sNHT34412018" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k0ILbCc9018099 for ; Wed, 18 Jan 2006 13:37:33 -0800 (PST) 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); Wed, 18 Jan 2006 16:37:26 -0500 Received: from [10.82.241.10] ([10.82.241.10]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 Jan 2006 16:37:26 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <77F357662F8BFA4CA7074B0410171B6DC9E8C9@XCH-NW-5V1.nw.nos.boeing.com> <43C6ED74.5070506@cisco.com> <43C70AE8.4052557C@earthlink.net> <43C800B4.90FA9D51@earthlink.net> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jan 2006 21:37:26.0531 (UTC) FILETIME=[6014F530:01C61C77] Message-ID: <43CEB516.6060604@cisco.com> Date: Wed, 18 Jan 2006 16:37:26 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft comments : 2740 update: Re: MOSPF - Multicast OSPF To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43C800B4.90FA9D51@earthlink.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Hi Mitchell, Thanks for the comments. See inline. Erblichs wrote: >group, > > yes, these are suggested comments to the 2740 revision.. > > Mitchell Erblich > ----------------- > >Erblichs wrote: > > >>Acee, et, al, >> >> Here are my first few comments. I will give you more >> this weekend if my reading is to your aggreement. >> >> 1) >> A.4 LSA formats >> "defines seven distinct types of LSAs." >> >> A.4.2.1 LSA Type : lists 9 types, thus seven -> nine >> >> We have router-LSAs, network-LSAs, intra-area-prefix-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs, AS-external-LSAs, link-LSAs, and NSSA-LSAs. That makes eight - Corrected. >> 2) >> 3.1.3 Neighbor Data Structure >> >> >> Neighbor's Backup Designated Router >> >> The neighbor's choice of Designated Router is now encoded as a >> Router ID instead of as an IP address. >> >> Insert Backup between : Designated Router, because we are >> talking about the BDR. Or have you now the the same router >> ID for the DR and BDR? :^) >> >> > > ... choice of Backup Designated Router .... > > Corrected. >> 3) >> 3.2.1.1 Sending Hello packets >> >> and the DC-bit is set if >> and only if the router wishes to suppress the sending of future >> Hellos over the interface (see [DEMAND]). >> >> ONLY after an a "full" adj has been established ?????? >> >> > > as I am assuming that hello supression should not be done > until after at least 2-way state is attempted to be achieved. > > No, I am not 100% sure whether hellos should be > sent on a DC link if their is a hello mismatch at the > normal hello-interval or some less freq 2x interval > should be chosen. Cost versus reliability / notification. > > Thus, it is assumed that the repeated hellos on a DC link could > be an indication that a adj hasn't formed. Need to ask the DC > authors.. > > The DC bit is set anytime the hello sender wants to negotiate Demand Circuit operation. My assumption is that the DC specification doesn't have any unique changes for OSPFv3 (other than the location of the option bit in the options). BTW, you are correct that hello suppression doesn't kick in until FULL state is reached. > > >> 4) transparent functional suggestions >> >> to possibly improve convergence, the first hello pkt can >> be sent the moment the interface becomes active >> >> I don't see a need to add this to the specification. >> if like routers are used and their is a concern for >> hello xmit synchronization, after the first hello is >> sent randomize just the next hello between 0 and the >> hello interval, then send hellos at the hello interval >> >> 5) >> 3.4.3.2 Network-LSAs >> >> "having two or more attached routers" >> >> Corrected. >> to >> >> having one or more attached routers each having a adjacency >> with the DR. >> >> > > oh... should be full adjacency... > > New text states this. Thanks, Acee >> Mitchell Erblich >> --------------------- >> >>Acee Lindem wrote: >> >> >>>Hi Tom, >>> >>>Henderson, Thomas R wrote: >>> >>> >>> >>>>I missed this thread when it was on rtg-dir in December, else would have >>>>commented there. >>>> >>>> >>>> >>>> >>>This is as good a time as any to comment. I haven't made any changes to >>>the OSPFv3 update draft :^) >>> >>> >>> >>>>We have used MOSPF in MANET experiments in the past (Moy's >>>>implementation) and found it was convenient in that environment. Once >>>>you have an efficient OSPF for MANET, why run a separate multicast >>>>routing protocol if you can avoid it? >>>> >>>> >>>> >>>> >>>I guess for the same reasons you run a separate multicast protocol in a >>>non-MANET (wired) >>>environment. However, the decision for wired networks was made a long >>>time ago and >>>perhaps today's technologies and the differences in the MANET environment >>>would yield a different answer. >>> >>> >>> >>>>So unless there is a bit crisis, I think it may be prudent to keep the >>>>bits for the time being, since OSPF for MANET is IPv6 only. >>>> >>>> >>>> >>>> >>>So, you feel that there is a chance that MOSPFv3 may be fully specified >>>and implemented for >>>MANET networks sometime in the future (1-4 years). Correct? If there is >>>serious >>>consideration of this work, I'll leave the MOSPF specific bits in the >>>OSPFv3 draft. Any >>>other comments? >>> >>>Thanks, >>>Acee >>> >>> >>> >>>>Tom >>>> >>>> >>>>________________________________ >>>> >>>> From: Rohit Dube [mailto:dube.rohit@GMAIL.COM] >>>> Sent: Tuesday, January 10, 2006 10:01 PM >>>> To: OSPF@PEACH.EASE.LSOFT.COM >>>> Subject: Re: MOSPF - Multicast OSPF >>>> >>>> >>>> >>>>Also note that back in Nov 2002, we had dropped any further protocol >>>>work on MOSPF (v2) at the WG meeting. >>>> >>>>If anybody has a real problem with deprecating the bits (because they >>>>are implementing MOSPFv3), now would be a good time to step forward. >>>> >>>>Best, >>>>--rohit. >>>> >>>> >>>> >>>> >>>> >>>> >>>> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 18 20:26:05 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzOYv-0001Xh-5j for ospf-archive@megatron.ietf.org; Wed, 18 Jan 2006 20:26: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 UAA29526 for ; Wed, 18 Jan 2006 20:24: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 <2.0001C269@wildebeest.ease.lsoft.com>; Wed, 18 Jan 2006 20:25:30 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 96994638 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 18 Jan 2006 20:25:30 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 18 Jan 2006 20:25:30 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 18 Jan 2006 20:25:22 -0500 X-IronPort-AV: i="3.99,382,1131339600"; d="scan'208"; a="80516955:sNHT25252748236" 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 k0J1Ow6T008235 for ; Wed, 18 Jan 2006 20:25:19 -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); Wed, 18 Jan 2006 20:25:18 -0500 Received: from [10.82.241.10] ([10.82.241.10]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 18 Jan 2006 20:25:17 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <77F357662F8BFA4CA7074B0410171B6DC9E8DC@XCH-NW-5V1.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jan 2006 01:25:17.0937 (UTC) FILETIME=[34DFF610:01C61C97] Message-ID: <43CEEA7D.5050606@cisco.com> Date: Wed, 18 Jan 2006 20:25:17 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: MOSPF - Multicast OSPF To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <77F357662F8BFA4CA7074B0410171B6DC9E8DC@XCH-NW-5V1.nw.nos.boeing.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Henderson, Thomas R wrote: >>So, you feel that there is a chance that MOSPFv3 may be fully >>specified >>and implemented for >>MANET networks sometime in the future (1-4 years). Correct? >> >> > >I don't know what the prospects are for such work, although maybe we >might turn some attention there once the unicast MANET work is more >settled. What I can say is that, in some environments where OSPF MANET >is likely to be attractive, multicast is also needed. We have in fact >conducted demos using an earlier version of OSPF MANET, complemented by >MOSPF(v2). The SMF work is the other MANET multicast work at present, >but it also relies on protocol to elect a relay set, and doesn't have >mechanism for managing group membership, so it may be the case that >MOSPFv3 makes more sense than SMF if one is already doing OSPFv3 MANET. > > Hi Tom, My opinion is that existing protocol constructs wouldn't be used even if we ever specified and implemented MOSPFv3. Rather, I'd envision any future MOSPFv3 using the proposed MTR encodings. However, now is not the time for that discussion and I guess there is enough dissenting opinions to leave them alone for now. Thanks, Acee >Tom > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 18 20:54:57 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzP0q-0004HY-UC for ospf-archive@megatron.ietf.org; Wed, 18 Jan 2006 20:54: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 UAA05947 for ; Wed, 18 Jan 2006 20:53: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 <6.0001C2D4@wildebeest.ease.lsoft.com>; Wed, 18 Jan 2006 20:54:25 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 96996174 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 18 Jan 2006 20:54:25 -0500 Received: from 207.69.195.63 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 18 Jan 2006 20:54:25 -0500 Received: from h-68-164-83-132.snvacaid.dynamic.covad.net ([68.164.83.132] helo=earthlink.net) by pop-satin.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1EzP0L-0005EC-00 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 18 Jan 2006 20:54: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: <77F357662F8BFA4CA7074B0410171B6DC9E8C9@XCH-NW-5V1.nw.nos.boeing.com> <43C6ED74.5070506@cisco.com> <43C70AE8.4052557C@earthlink.net> <43C800B4.90FA9D51@earthlink.net> <43CEB516.6060604@cisco.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43CEF47F.B8AF28C5@earthlink.net> Date: Wed, 18 Jan 2006 18:07:59 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: draft comments : 2740 update: Re: MOSPF - Multicast OSPF 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, Just a few additional item Suggestions: A) A.3.2 The Hello Packet Neighbor Id Append -> (exception of D/C neighbors) Where I don't expect to see a hello within RouterDeadInterval sec. B) A.3.3 DD Packet field layout Options field is shown 1 bit to small. C) A.3.6 To make the flooding of LSAs reliable, flooded LSAs are explicitly acknowledged. Shouldn't it be ... flooded LSAs are explicitly or implicitly acknowledged. Then ... This acknowledgment is ... to The explicit acknowledgment is D) C.3 RouterDeadInterval before its neighbors declare the router down to before its neighbors declare the non D/C neighbor down. We are talking about missing hellos here.. E) 3 items: Inline.. Mitchell Erblich -------------------------- Acee Lindem wrote: > > Hi Mitchell, > > Thanks for the comments. See inline. > > Erblichs wrote: > > >group, > > > > yes, these are suggested comments to the 2740 revision.. > > > > Mitchell Erblich > > ----------------- > > > >Erblichs wrote: > > > > > >>Acee, et, al, > >> > >> Here are my first few comments. I will give you more > >> this weekend if my reading is to your aggreement. > >> > >> 1) > >> A.4 LSA formats > >> "defines seven distinct types of LSAs." > >> > >> A.4.2.1 LSA Type : lists 9 types, thus seven -> nine > >> > >> > We have router-LSAs, network-LSAs, intra-area-prefix-LSAs, > inter-area-prefix-LSAs, > inter-area-router-LSAs, AS-external-LSAs, link-LSAs, and NSSA-LSAs. > That makes > eight - Corrected. > E1) --> Group-membership-LSA was in the list > >> 2) > >> 3.1.3 Neighbor Data Structure > >> > >> > >> Neighbor's Backup Designated Router > >> > >> The neighbor's choice of Designated Router is now encoded as a > >> Router ID instead of as an IP address. > >> > >> Insert Backup between : Designated Router, because we are > >> talking about the BDR. Or have you now the the same router > >> ID for the DR and BDR? :^) > >> > >> > > > > ... choice of Backup Designated Router .... > > > > > > Corrected. > > >> 3) > >> 3.2.1.1 Sending Hello packets > >> > >> and the DC-bit is set if > >> and only if the router wishes to suppress the sending of future > >> Hellos over the interface (see [DEMAND]). > >> > >> ONLY after an a "full" adj has been established ?????? > >> > >> > > > > as I am assuming that hello supression should not be done > > until after at least 2-way state is attempted to be achieved. > > > > No, I am not 100% sure whether hellos should be > > sent on a DC link if their is a hello mismatch at the > > normal hello-interval or some less freq 2x interval > > should be chosen. Cost versus reliability / notification. > > > > Thus, it is assumed that the repeated hellos on a DC link could > > be an indication that a adj hasn't formed. Need to ask the DC > > authors.. > > > > > The DC bit is set anytime the hello sender wants to negotiate Demand > Circuit operation. My assumption > is that the DC specification doesn't have any unique changes for OSPFv3 > (other than the location > of the option bit in the options). BTW, you are correct that hello > suppression doesn't kick in until > FULL state is reached. > E2) Should we explicitly add the above phrase to mention that only after a "full adj" : (Only ... established.) was my suggestion without the "???". And the other question I was raising is whether a mismatch SHOULD cause some (2x) backoff of the hello as to still reduce cost with D/C neighborrs. Seeing hellos on a D/C should say something anyway, so some are needed in case whatever is causing the mismatch is administratively fixed. > > > > > >> 4) transparent functional suggestions > >> > >> to possibly improve convergence, the first hello pkt can > >> be sent the moment the interface becomes active > >> > >> > I don't see a need to add this to the specification. > E3) Yes, this is really a implementation item for improved convergence. I thought that this is a transparent change and should be a common sense item that should be added. I don't know of a single implementation argument against it. > >> if like routers are used and their is a concern for > >> hello xmit synchronization, after the first hello is > >> sent randomize just the next hello between 0 and the > >> hello interval, then send hellos at the hello interval > >> > >> 5) > >> 3.4.3.2 Network-LSAs > >> > >> "having two or more attached routers" > >> > >> > Corrected. > > >> to > >> > >> having one or more attached routers each having a adjacency > >> with the DR. > >> > >> > > > > oh... should be full adjacency... > > > > > New text states this. > > Thanks, > Acee > > >> Mitchell Erblich > >> --------------------- > >> > >>Acee Lindem wrote: > >> > >> > >>>Hi Tom, > >>> > >>>Henderson, Thomas R wrote: > >>> > >>> > >>> > >>>>I missed this thread when it was on rtg-dir in December, else would have > >>>>commented there. > >>>> > >>>> > >>>> > >>>> > >>>This is as good a time as any to comment. I haven't made any changes to > >>>the OSPFv3 update draft :^) > >>> > >>> > >>> > >>>>We have used MOSPF in MANET experiments in the past (Moy's > >>>>implementation) and found it was convenient in that environment. Once > >>>>you have an efficient OSPF for MANET, why run a separate multicast > >>>>routing protocol if you can avoid it? > >>>> > >>>> > >>>> > >>>> > >>>I guess for the same reasons you run a separate multicast protocol in a > >>>non-MANET (wired) > >>>environment. However, the decision for wired networks was made a long > >>>time ago and > >>>perhaps today's technologies and the differences in the MANET environment > >>>would yield a different answer. > >>> > >>> > >>> > >>>>So unless there is a bit crisis, I think it may be prudent to keep the > >>>>bits for the time being, since OSPF for MANET is IPv6 only. > >>>> > >>>> > >>>> > >>>> > >>>So, you feel that there is a chance that MOSPFv3 may be fully specified > >>>and implemented for > >>>MANET networks sometime in the future (1-4 years). Correct? If there is > >>>serious > >>>consideration of this work, I'll leave the MOSPF specific bits in the > >>>OSPFv3 draft. Any > >>>other comments? > >>> > >>>Thanks, > >>>Acee > >>> > >>> > >>> > >>>>Tom > >>>> > >>>> > >>>>________________________________ > >>>> > >>>> From: Rohit Dube [mailto:dube.rohit@GMAIL.COM] > >>>> Sent: Tuesday, January 10, 2006 10:01 PM > >>>> To: OSPF@PEACH.EASE.LSOFT.COM > >>>> Subject: Re: MOSPF - Multicast OSPF > >>>> > >>>> > >>>> > >>>>Also note that back in Nov 2002, we had dropped any further protocol > >>>>work on MOSPF (v2) at the WG meeting. > >>>> > >>>>If anybody has a real problem with deprecating the bits (because they > >>>>are implementing MOSPFv3), now would be a good time to step forward. > >>>> > >>>>Best, > >>>>--rohit. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 20 12: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 1F008W-0004Yi-Nr for ospf-archive@megatron.ietf.org; Fri, 20 Jan 2006 12: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 MAA03524 for ; Fri, 20 Jan 2006 12:31:51 -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.0001D776@wildebeest.ease.lsoft.com>; Fri, 20 Jan 2006 12:32:45 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 97153909 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 20 Jan 2006 12:32:45 -0500 Received: from 171.68.10.86 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 20 Jan 2006 12:32:44 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 20 Jan 2006 09:32:44 -0800 X-IronPort-AV: i="4.01,206,1136188800"; d="scan'208"; a="1768562756:sNHT36763906" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k0KHWhc1014881 for ; Fri, 20 Jan 2006 09:32:44 -0800 (PST) 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, 20 Jan 2006 12:32:43 -0500 Received: from [10.82.224.62] ([10.82.224.62]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 Jan 2006 12:32:43 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <77F357662F8BFA4CA7074B0410171B6DC9E8C9@XCH-NW-5V1.nw.nos.boeing.com> <43C6ED74.5070506@cisco.com> <43C70AE8.4052557C@earthlink.net> <43C800B4.90FA9D51@earthlink.net> <43CEB516.6060604@cisco.com> <43CEF47F.B8AF28C5@earthlink.net> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jan 2006 17:32:43.0505 (UTC) FILETIME=[85247E10:01C61DE7] Message-ID: <43D11EBA.7050707@cisco.com> Date: Fri, 20 Jan 2006 12:32:42 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft comments : 2740 update To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43CEF47F.B8AF28C5@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, > > Just a few additional item Suggestions: > > A) A.3.2 The Hello Packet > > Neighbor Id > > Append -> (exception of D/C neighbors) > > Where I don't expect to see a hello within > RouterDeadInterval sec. > > This could be a slippery slope to try and incorporate every exception case. One could make the same argument for graceful restart when the grace interval is greater than the dead interval. I've change this to "each router on the network with neighbor state 1-Way or greater". > B) A.3.3 DD Packet field layout > > Options field is shown 1 bit to small. > > Bits 8-31 - It's 24 bits as defined. > C) A.3.6 > To make the flooding of LSAs reliable, flooded > LSAs are explicitly acknowledged. > > Shouldn't it be ... flooded LSAs are explicitly or > implicitly acknowledged. > > Then ... > > This acknowledgment is ... > > to > > The explicit acknowledgment is > > Corrected (although I think the intent was clear without it). > D) C.3 > RouterDeadInterval > > before its neighbors declare the router down > > to > > before its neighbors declare the non D/C neighbor > down. > > We are talking about missing hellos here.. > > Since this section is defining RouterDeadInterval, I'm not sure we want to try and document every case where it isn't applicable. > E) 3 items: Inline.. > > > Mitchell Erblich > -------------------------- > > > >Acee Lindem wrote: > > >>Hi Mitchell, >> >>Thanks for the comments. See inline. >> >>Erblichs wrote: >> >> >> >>>group, >>> >>> yes, these are suggested comments to the 2740 revision.. >>> >>> Mitchell Erblich >>> ----------------- >>> >>>Erblichs wrote: >>> >>> >>> >>> >>>>Acee, et, al, >>>> >>>> Here are my first few comments. I will give you more >>>> this weekend if my reading is to your aggreement. >>>> >>>> 1) >>>> A.4 LSA formats >>>> "defines seven distinct types of LSAs." >>>> >>>> A.4.2.1 LSA Type : lists 9 types, thus seven -> nine >>>> >>>> >>>> >>>> >>We have router-LSAs, network-LSAs, intra-area-prefix-LSAs, >>inter-area-prefix-LSAs, >> inter-area-router-LSAs, AS-external-LSAs, link-LSAs, and NSSA-LSAs. >>That makes >>eight - Corrected. >> >> >> > E1) --> Group-membership-LSA was in the list > > The format of this LSA is not documented in this specification. In fact, we were considering getting rid of it completely but there was some opposition. >>>> 2) >>>> 3.1.3 Neighbor Data Structure >>>> >>>> >>>> Neighbor's Backup Designated Router >>>> >>>> The neighbor's choice of Designated Router is now encoded as a >>>> Router ID instead of as an IP address. >>>> >>>> Insert Backup between : Designated Router, because we are >>>> talking about the BDR. Or have you now the the same router >>>> ID for the DR and BDR? :^) >>>> >>>> >>>> >>>> >>> ... choice of Backup Designated Router .... >>> >>> >>> >>> >>Corrected. >> >> >> >>>> 3) >>>> 3.2.1.1 Sending Hello packets >>>> >>>> and the DC-bit is set if >>>> and only if the router wishes to suppress the sending of future >>>> Hellos over the interface (see [DEMAND]). >>>> >>>> ONLY after an a "full" adj has been established ?????? >>>> >>>> >>>> >>>> >>> as I am assuming that hello supression should not be done >>> until after at least 2-way state is attempted to be achieved. >>> >>> No, I am not 100% sure whether hellos should be >>> sent on a DC link if their is a hello mismatch at the >>> normal hello-interval or some less freq 2x interval >>> should be chosen. Cost versus reliability / notification. >>> >>> Thus, it is assumed that the repeated hellos on a DC link could >>> be an indication that a adj hasn't formed. Need to ask the DC >>> authors.. >>> >>> >>> >>> >>The DC bit is set anytime the hello sender wants to negotiate Demand >>Circuit operation. My assumption >>is that the DC specification doesn't have any unique changes for OSPFv3 >>(other than the location >>of the option bit in the options). BTW, you are correct that hello >>suppression doesn't kick in until >>FULL state is reached. >> >> >> > > E2) > Should we explicitly add the above phrase to mention that > only after a "full adj" : (Only ... established.) was my > suggestion without the "???". > > No - In this context, "future" means after the adjacency goes full. One should go RFC 1793 for a precise definition of demand circuits. > And the other question I was raising is whether a mismatch SHOULD > cause some (2x) backoff of the hello as to still reduce cost > with D/C neighborrs. > > Seeing hellos on a D/C should say something anyway, so > some are needed in case whatever is causing the mismatch > is administratively fixed. > > >>> >>> >>>> 4) transparent functional suggestions >>>> >>>> to possibly improve convergence, the first hello pkt can >>>> be sent the moment the interface becomes active >>>> >>>> >>>> >>>> >>I don't see a need to add this to the specification. >> >> >> > > E3) > Yes, this is really a implementation item for > improved convergence. I thought that this is > a transparent change and should be a common > sense item that should be added. I don't know > of a single implementation argument against it. > > There is not agreement in the WG on whether or not these little implementation tweaks which have been practice for many years should be documented in an informational RFC. I suggest you collaborate with authors of draft-kou-ospf-immediately-replying-hello-00.txt. Thanks, Acee > > > >>>> if like routers are used and their is a concern for >>>> hello xmit synchronization, after the first hello is >>>> sent randomize just the next hello between 0 and the >>>> hello interval, then send hellos at the hello interval >>>> >>>> 5) >>>> 3.4.3.2 Network-LSAs >>>> >>>> "having two or more attached routers" >>>> >>>> >>>> >>>> >>Corrected. >> >> >> >>>> to >>>> >>>> having one or more attached routers each having a adjacency >>>> with the DR. >>>> >>>> >>>> >>>> >>> oh... should be full adjacency... >>> >>> >>> >>> >>New text states this. >> >>Thanks, >>Acee >> >> >> >>>> Mitchell Erblich >>>> --------------------- >>>> >>>>Acee Lindem wrote: >>>> >>>> >>>> >>>> >>>>>Hi Tom, >>>>> >>>>>Henderson, Thomas R wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>I missed this thread when it was on rtg-dir in December, else would have >>>>>>commented there. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>This is as good a time as any to comment. I haven't made any changes to >>>>>the OSPFv3 update draft :^) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>We have used MOSPF in MANET experiments in the past (Moy's >>>>>>implementation) and found it was convenient in that environment. Once >>>>>>you have an efficient OSPF for MANET, why run a separate multicast >>>>>>routing protocol if you can avoid it? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>I guess for the same reasons you run a separate multicast protocol in a >>>>>non-MANET (wired) >>>>>environment. However, the decision for wired networks was made a long >>>>>time ago and >>>>>perhaps today's technologies and the differences in the MANET environment >>>>>would yield a different answer. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>So unless there is a bit crisis, I think it may be prudent to keep the >>>>>>bits for the time being, since OSPF for MANET is IPv6 only. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>So, you feel that there is a chance that MOSPFv3 may be fully specified >>>>>and implemented for >>>>>MANET networks sometime in the future (1-4 years). Correct? If there is >>>>>serious >>>>>consideration of this work, I'll leave the MOSPF specific bits in the >>>>>OSPFv3 draft. Any >>>>>other comments? >>>>> >>>>>Thanks, >>>>>Acee >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Tom >>>>>> >>>>>> >>>>>>________________________________ >>>>>> >>>>>> From: Rohit Dube [mailto:dube.rohit@GMAIL.COM] >>>>>> Sent: Tuesday, January 10, 2006 10:01 PM >>>>>> To: OSPF@PEACH.EASE.LSOFT.COM >>>>>> Subject: Re: MOSPF - Multicast OSPF >>>>>> >>>>>> >>>>>> >>>>>>Also note that back in Nov 2002, we had dropped any further protocol >>>>>>work on MOSPF (v2) at the WG meeting. >>>>>> >>>>>>If anybody has a real problem with deprecating the bits (because they >>>>>>are implementing MOSPFv3), now would be a good time to step forward. >>>>>> >>>>>>Best, >>>>>>--rohit. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>> >>> >>> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 20 17:42:06 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F04xI-00088g-Gd for ospf-archive@megatron.ietf.org; Fri, 20 Jan 2006 17:42: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 RAA08409 for ; Fri, 20 Jan 2006 17:40: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 <14.0001D82E@wildebeest.ease.lsoft.com>; Fri, 20 Jan 2006 17:41:26 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 97179037 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 20 Jan 2006 17:41:25 -0500 Received: from 207.69.195.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 20 Jan 2006 17:41:25 -0500 Received: from h-68-164-83-132.snvacaid.dynamic.covad.net ([68.164.83.132] helo=earthlink.net) by pop-siberian.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1F04we-00079p-00 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 20 Jan 2006 17:41:24 -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: <77F357662F8BFA4CA7074B0410171B6DC9E8C9@XCH-NW-5V1.nw.nos.boeing.com> <43C6ED74.5070506@cisco.com> <43C70AE8.4052557C@earthlink.net> <43C800B4.90FA9D51@earthlink.net> <43CEB516.6060604@cisco.com> <43CEF47F.B8AF28C5@earthlink.net> <43D11EBA.7050707@cisco.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43D16A8B.3167534D@earthlink.net> Date: Fri, 20 Jan 2006 14:56:11 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: draft comments : 2740 update 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, This is getting messy.. I guess you raised to me what seems like a bigger question. Should generic protocol RFCs (Ex:2740) at the time of creation or modificiation attempt to generate an illusion of completeness? If this is so, then yes, I would like to see at least all exceptions to common expected practices that could be "hidden" within one of tens of RFCs. Yes, I would like to see a Reference to Graceful Restart within this spec, if and only if (iff) it is a publicly documented spec AND it is(to become) common. Else, how would the people who read the V2 or V3 specs just know of its existance. Ex: So, who can find me in what RFC totally stubby area support is defined? NSSA is Ref in v3 and v2. And, i think we SHOULD make these RFCs with as minimal amount of ambiguity as possible and cross-reference them as freq as possible, to make sure that ALL curently supported implimnetations support a common set of features. Thus, if major changes were being done, yes, I would also suggest incorporation how each LSA type with its various scope is handled in stubs, totally stubby, not so totally stubby, etc area interactions. So, the RFC had/has the GM LSA as one of the 9 types and a separate RFC defines its processing, so I did see a need to include it, because it is slated for removal. But as it should be clear, at best IMO it should at most go to reserve with the type value and not reused. It could then be covered with other unknown types as you stated in a earlier email. >I've change this to "each router on the network with > neighbor > state 1-Way or greater". Yes, I agree, this is more accurate, But it looses the implicit hello pkt to hello pkt field exchange. > Since this section is defining RouterDeadInterval, I'm not sure we want > to try and document > every case where it isn't applicable. Why not? :) Actually, in general, I would expect us to list at least A FEW exceptions as we see them and indicate in a footnote that the list may not be ALL encompassing. Else, we should consider it as an equiv as a Architectural constant. > There is not agreement in the WG on whether or not these little > implementation tweaks > which have been practice for many years should be documented in an > informational RFC. If "little implemenatation tweaks" are common public practice, then at least they should be documented/ standardized, IMO. Mitchell Erblich ---------------------- Acee Lindem wrote: > > Hi Mitchell, > > Erblichs wrote: > > >Acee, et al, > > > > Just a few additional item Suggestions: > > > > A) A.3.2 The Hello Packet > > > > Neighbor Id > > > > Append -> (exception of D/C neighbors) > > > > Where I don't expect to see a hello within > > RouterDeadInterval sec. > > > > > This could be a slippery slope to try and incorporate every exception > case. One could > make the same argument for graceful restart when the grace interval is > greater than > the dead interval. I've change this to "each router on the network with > neighbor > state 1-Way or greater". > > > B) A.3.3 DD Packet field layout > > > > Options field is shown 1 bit to small. > > > > > Bits 8-31 - It's 24 bits as defined. > > > C) A.3.6 > > To make the flooding of LSAs reliable, flooded > > LSAs are explicitly acknowledged. > > > > Shouldn't it be ... flooded LSAs are explicitly or > > implicitly acknowledged. > > > > Then ... > > > > This acknowledgment is ... > > > > to > > > > The explicit acknowledgment is > > > > > Corrected (although I think the intent was clear without it). > > > D) C.3 > > RouterDeadInterval > > > > before its neighbors declare the router down > > > > to > > > > before its neighbors declare the non D/C neighbor > > down. > > > > We are talking about missing hellos here.. > > > > > Since this section is defining RouterDeadInterval, I'm not sure we want > to try and document > every case where it isn't applicable. > > > E) 3 items: Inline.. > > > > > > Mitchell Erblich > > -------------------------- > > > > > > > >Acee Lindem wrote: > > > > > >>Hi Mitchell, > >> > >>Thanks for the comments. See inline. > >> > >>Erblichs wrote: > >> > >> > >> > >>>group, > >>> > >>> yes, these are suggested comments to the 2740 revision.. > >>> > >>> Mitchell Erblich > >>> ----------------- > >>> > >>>Erblichs wrote: > >>> > >>> > >>> > >>> > >>>>Acee, et, al, > >>>> > >>>> Here are my first few comments. I will give you more > >>>> this weekend if my reading is to your aggreement. > >>>> > >>>> 1) > >>>> A.4 LSA formats > >>>> "defines seven distinct types of LSAs." > >>>> > >>>> A.4.2.1 LSA Type : lists 9 types, thus seven -> nine > >>>> > >>>> > >>>> > >>>> > >>We have router-LSAs, network-LSAs, intra-area-prefix-LSAs, > >>inter-area-prefix-LSAs, > >> inter-area-router-LSAs, AS-external-LSAs, link-LSAs, and NSSA-LSAs. > >>That makes > >>eight - Corrected. > >> > >> > >> > > E1) --> Group-membership-LSA was in the list > > > > > The format of this LSA is not documented in this specification. In fact, > we were considering > getting rid of it completely but there was some opposition. > > >>>> 2) > >>>> 3.1.3 Neighbor Data Structure > >>>> > >>>> > >>>> Neighbor's Backup Designated Router > >>>> > >>>> The neighbor's choice of Designated Router is now encoded as a > >>>> Router ID instead of as an IP address. > >>>> > >>>> Insert Backup between : Designated Router, because we are > >>>> talking about the BDR. Or have you now the the same router > >>>> ID for the DR and BDR? :^) > >>>> > >>>> > >>>> > >>>> > >>> ... choice of Backup Designated Router .... > >>> > >>> > >>> > >>> > >>Corrected. > >> > >> > >> > >>>> 3) > >>>> 3.2.1.1 Sending Hello packets > >>>> > >>>> and the DC-bit is set if > >>>> and only if the router wishes to suppress the sending of future > >>>> Hellos over the interface (see [DEMAND]). > >>>> > >>>> ONLY after an a "full" adj has been established ?????? > >>>> > >>>> > >>>> > >>>> > >>> as I am assuming that hello supression should not be done > >>> until after at least 2-way state is attempted to be achieved. > >>> > >>> No, I am not 100% sure whether hellos should be > >>> sent on a DC link if their is a hello mismatch at the > >>> normal hello-interval or some less freq 2x interval > >>> should be chosen. Cost versus reliability / notification. > >>> > >>> Thus, it is assumed that the repeated hellos on a DC link could > >>> be an indication that a adj hasn't formed. Need to ask the DC > >>> authors.. > >>> > >>> > >>> > >>> > >>The DC bit is set anytime the hello sender wants to negotiate Demand > >>Circuit operation. My assumption > >>is that the DC specification doesn't have any unique changes for OSPFv3 > >>(other than the location > >>of the option bit in the options). BTW, you are correct that hello > >>suppression doesn't kick in until > >>FULL state is reached. > >> > >> > >> > > > > E2) > > Should we explicitly add the above phrase to mention that > > only after a "full adj" : (Only ... established.) was my > > suggestion without the "???". > > > > > No - In this context, "future" means after the adjacency goes full. One > should go RFC 1793 for > a precise definition of demand circuits. > > > And the other question I was raising is whether a mismatch SHOULD > > cause some (2x) backoff of the hello as to still reduce cost > > with D/C neighborrs. > > > > Seeing hellos on a D/C should say something anyway, so > > some are needed in case whatever is causing the mismatch > > is administratively fixed. > > > > > >>> > >>> > >>>> 4) transparent functional suggestions > >>>> > >>>> to possibly improve convergence, the first hello pkt can > >>>> be sent the moment the interface becomes active > >>>> > >>>> > >>>> > >>>> > >>I don't see a need to add this to the specification. > >> > >> > >> > > > > E3) > > Yes, this is really a implementation item for > > improved convergence. I thought that this is > > a transparent change and should be a common > > sense item that should be added. I don't know > > of a single implementation argument against it. > > > > > There is not agreement in the WG on whether or not these little > implementation tweaks > which have been practice for many years should be documented in an > informational RFC. I suggest you collaborate with authors of > draft-kou-ospf-immediately-replying-hello-00.txt. > > Thanks, > Acee > > > > > > > > >>>> if like routers are used and their is a concern for > >>>> hello xmit synchronization, after the first hello is > >>>> sent randomize just the next hello between 0 and the > >>>> hello interval, then send hellos at the hello interval > >>>> > >>>> 5) > >>>> 3.4.3.2 Network-LSAs > >>>> > >>>> "having two or more attached routers" > >>>> > >>>> > >>>> > >>>> > >>Corrected. > >> > >> > >> > >>>> to > >>>> > >>>> having one or more attached routers each having a adjacency > >>>> with the DR. > >>>> > >>>> > >>>> > >>>> > >>> oh... should be full adjacency... > >>> > >>> > >>> > >>> > >>New text states this. > >> > >>Thanks, > >>Acee > >> > >> > >> > >>>> Mitchell Erblich > >>>> --------------------- > >>>> > >>>>Acee Lindem wrote: > >>>> > >>>> > >>>> > >>>> > >>>>>Hi Tom, > >>>>> > >>>>>Henderson, Thomas R wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>I missed this thread when it was on rtg-dir in December, else would have > >>>>>>commented there. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>This is as good a time as any to comment. I haven't made any changes to > >>>>>the OSPFv3 update draft :^) > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>We have used MOSPF in MANET experiments in the past (Moy's > >>>>>>implementation) and found it was convenient in that environment. Once > >>>>>>you have an efficient OSPF for MANET, why run a separate multicast > >>>>>>routing protocol if you can avoid it? > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>I guess for the same reasons you run a separate multicast protocol in a > >>>>>non-MANET (wired) > >>>>>environment. However, the decision for wired networks was made a long > >>>>>time ago and > >>>>>perhaps today's technologies and the differences in the MANET environment > >>>>>would yield a different answer. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>So unless there is a bit crisis, I think it may be prudent to keep the > >>>>>>bits for the time being, since OSPF for MANET is IPv6 only. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>So, you feel that there is a chance that MOSPFv3 may be fully specified > >>>>>and implemented for > >>>>>MANET networks sometime in the future (1-4 years). Correct? If there is > >>>>>serious > >>>>>consideration of this work, I'll leave the MOSPF specific bits in the > >>>>>OSPFv3 draft. Any > >>>>>other comments? > >>>>> > >>>>>Thanks, > >>>>>Acee > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>Tom > >>>>>> > >>>>>> > >>>>>>________________________________ > >>>>>> > >>>>>> From: Rohit Dube [mailto:dube.rohit@GMAIL.COM] > >>>>>> Sent: Tuesday, January 10, 2006 10:01 PM > >>>>>> To: OSPF@PEACH.EASE.LSOFT.COM > >>>>>> Subject: Re: MOSPF - Multicast OSPF > >>>>>> > >>>>>> > >>>>>> > >>>>>>Also note that back in Nov 2002, we had dropped any further protocol > >>>>>>work on MOSPF (v2) at the WG meeting. > >>>>>> > >>>>>>If anybody has a real problem with deprecating the bits (because they > >>>>>>are implementing MOSPFv3), now would be a good time to step forward. > >>>>>> > >>>>>>Best, > >>>>>>--rohit. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>> > >>> > >>> > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Jan 20 19:58:09 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F074y-0004QN-0i for ospf-archive@megatron.ietf.org; Fri, 20 Jan 2006 19:58: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 TAA17363 for ; Fri, 20 Jan 2006 19:56: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 <10.0001D881@wildebeest.ease.lsoft.com>; Fri, 20 Jan 2006 19:57:30 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 97185632 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 20 Jan 2006 19:57:29 -0500 Received: from 171.68.10.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 20 Jan 2006 19:57:28 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 20 Jan 2006 15:01:08 -0800 X-IronPort-AV: i="unknown"; a="250462678:sNHT0" 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 k0KN1U9b029446 for ; Fri, 20 Jan 2006 15:01:32 -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, 20 Jan 2006 18:01:30 -0500 Received: from [10.82.209.43] ([10.82.209.43]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 20 Jan 2006 18:01:29 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <77F357662F8BFA4CA7074B0410171B6DC9E8C9@XCH-NW-5V1.nw.nos.boeing.com> <43C6ED74.5070506@cisco.com> <43C70AE8.4052557C@earthlink.net> <43C800B4.90FA9D51@earthlink.net> <43CEB516.6060604@cisco.com> <43CEF47F.B8AF28C5@earthlink.net> <43D11EBA.7050707@cisco.com> <43D16A8B.3167534D@earthlink.net> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jan 2006 23:01:29.0938 (UTC) FILETIME=[73034B20:01C61E15] Message-ID: <43D16BC9.3050008@cisco.com> Date: Fri, 20 Jan 2006 18:01:29 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft comments : 2740 update To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43D16A8B.3167534D@earthlink.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Mitchell, Erblichs wrote: >Acee, et al, > > This is getting messy.. > > I guess you raised to me what seems like a bigger > question. Should generic protocol RFCs (Ex:2740) at > the time of creation or modificiation attempt to > generate an illusion of completeness? > > If this is so, then yes, I would like to see at least > all exceptions to common expected practices that could > be "hidden" within one of tens of RFCs. > > When the exception needs to be documented for the specification to be correct, I'll add it or re-word the text. I am not going to document every exception every time a given protocol construct is mentioned. As Editor, I'll make the determination of whether or not a suggestion adds value or simply bulk. > Yes, I would like to see a Reference to Graceful Restart > within this spec, if and only if (iff) it is a publicly > documented spec AND it is(to become) common. Else, > how would the people who read the V2 or V3 specs just > know of its existance. > > Ex: So, who can find me in what RFC totally stubby area > support is defined? NSSA is Ref in v3 and v2. > > RFC 3101 is the definitive source for OSPF NSSA. The OSPFv3 unique encodings and protocol processing are included in the draft. If any are missing, please bring them forward. > And, i think we SHOULD make these RFCs with as minimal > amount of ambiguity as possible and cross-reference them > as freq as possible, to make sure that ALL curently supported > implimnetations support a common set of features. > > Thus, if major changes were being done, yes, I would > also suggest incorporation how each LSA type with its > various scope is handled in stubs, totally stubby, > not so totally stubby, etc area interactions. > > So, the RFC had/has the GM LSA as one of the 9 types > and a separate RFC defines its processing, so I did > see a need to include it, because it is slated for > removal. But as it should be clear, at best IMO it > should at most go to reserve with the type value and > not reused. It could then be covered with other unknown > types as you stated in a earlier email. >I've change this to "each router on the network with >neighbor >state 1-Way or greater". > > > > Yes, I agree, this is more accurate, But it looses > the implicit hello pkt to hello pkt field exchange. > > This section describes the hello packet format. > > >>Since this section is defining RouterDeadInterval, I'm not sure we want >>to try and document >>every case where it isn't applicable. >> >> > > Why not? :) > Actually, in general, I would expect us to list at least > A FEW exceptions as we see them and indicate in a footnote > that the list may not be ALL encompassing. > > Else, we should consider it as an equiv as a Architectural > constant. > > I disagree. It isn't really necessary. If one is going to implement demand circuits one must consult RFC 1793. I'd reconsider if you can garner the support of others. Otherwise, give it up. > > > > >>There is not agreement in the WG on whether or not these little >>implementation tweaks >>which have been practice for many years should be documented in an >>informational RFC. >> >> > > If "little implemenatation tweaks" are common public > practice, then at least they should be documented/ standardized, > IMO. > > My previous suggestion on who to collaborate with still holds. Thanks, Acee > Mitchell Erblich > ---------------------- > > > > >Acee Lindem wrote: > > >>Hi Mitchell, >> >>Erblichs wrote: >> >> >> >>>Acee, et al, >>> >>> Just a few additional item Suggestions: >>> >>> A) A.3.2 The Hello Packet >>> >>> Neighbor Id >>> >>> Append -> (exception of D/C neighbors) >>> >>> Where I don't expect to see a hello within >>> RouterDeadInterval sec. >>> >>> >>> >>> >>This could be a slippery slope to try and incorporate every exception >>case. One could >>make the same argument for graceful restart when the grace interval is >>greater than >>the dead interval. I've change this to "each router on the network with >>neighbor >>state 1-Way or greater". >> >> >> >>> B) A.3.3 DD Packet field layout >>> >>> Options field is shown 1 bit to small. >>> >>> >>> >>> >>Bits 8-31 - It's 24 bits as defined. >> >> >> >>> C) A.3.6 >>> To make the flooding of LSAs reliable, flooded >>> LSAs are explicitly acknowledged. >>> >>> Shouldn't it be ... flooded LSAs are explicitly or >>> implicitly acknowledged. >>> >>> Then ... >>> >>> This acknowledgment is ... >>> >>> to >>> >>> The explicit acknowledgment is >>> >>> >>> >>> >>Corrected (although I think the intent was clear without it). >> >> >> >>> D) C.3 >>> RouterDeadInterval >>> >>> before its neighbors declare the router down >>> >>> to >>> >>> before its neighbors declare the non D/C neighbor >>> down. >>> >>> We are talking about missing hellos here.. >>> >>> >>> >>> >>Since this section is defining RouterDeadInterval, I'm not sure we want >>to try and document >>every case where it isn't applicable. >> >> >> >>> E) 3 items: Inline.. >>> >>> >>> Mitchell Erblich >>> -------------------------- >>> >>> >>> >>>Acee Lindem wrote: >>> >>> >>> >>> >>>>Hi Mitchell, >>>> >>>>Thanks for the comments. See inline. >>>> >>>>Erblichs wrote: >>>> >>>> >>>> >>>> >>>> >>>>>group, >>>>> >>>>> yes, these are suggested comments to the 2740 revision.. >>>>> >>>>> Mitchell Erblich >>>>> ----------------- >>>>> >>>>>Erblichs wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Acee, et, al, >>>>>> >>>>>> Here are my first few comments. I will give you more >>>>>> this weekend if my reading is to your aggreement. >>>>>> >>>>>> 1) >>>>>> A.4 LSA formats >>>>>> "defines seven distinct types of LSAs." >>>>>> >>>>>> A.4.2.1 LSA Type : lists 9 types, thus seven -> nine >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>We have router-LSAs, network-LSAs, intra-area-prefix-LSAs, >>>>inter-area-prefix-LSAs, >>>>inter-area-router-LSAs, AS-external-LSAs, link-LSAs, and NSSA-LSAs. >>>>That makes >>>>eight - Corrected. >>>> >>>> >>>> >>>> >>>> >>> E1) --> Group-membership-LSA was in the list >>> >>> >>> >>> >>The format of this LSA is not documented in this specification. In fact, >>we were considering >>getting rid of it completely but there was some opposition. >> >> >> >>>>>> 2) >>>>>> 3.1.3 Neighbor Data Structure >>>>>> >>>>>> >>>>>> Neighbor's Backup Designated Router >>>>>> >>>>>> The neighbor's choice of Designated Router is now encoded as a >>>>>> Router ID instead of as an IP address. >>>>>> >>>>>> Insert Backup between : Designated Router, because we are >>>>>> talking about the BDR. Or have you now the the same router >>>>>> ID for the DR and BDR? :^) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> ... choice of Backup Designated Router .... >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>Corrected. >>>> >>>> >>>> >>>> >>>> >>>>>> 3) >>>>>> 3.2.1.1 Sending Hello packets >>>>>> >>>>>> and the DC-bit is set if >>>>>> and only if the router wishes to suppress the sending of future >>>>>> Hellos over the interface (see [DEMAND]). >>>>>> >>>>>> ONLY after an a "full" adj has been established ?????? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> as I am assuming that hello supression should not be done >>>>> until after at least 2-way state is attempted to be achieved. >>>>> >>>>> No, I am not 100% sure whether hellos should be >>>>> sent on a DC link if their is a hello mismatch at the >>>>> normal hello-interval or some less freq 2x interval >>>>> should be chosen. Cost versus reliability / notification. >>>>> >>>>> Thus, it is assumed that the repeated hellos on a DC link could >>>>> be an indication that a adj hasn't formed. Need to ask the DC >>>>> authors.. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>The DC bit is set anytime the hello sender wants to negotiate Demand >>>>Circuit operation. My assumption >>>>is that the DC specification doesn't have any unique changes for OSPFv3 >>>>(other than the location >>>>of the option bit in the options). BTW, you are correct that hello >>>>suppression doesn't kick in until >>>>FULL state is reached. >>>> >>>> >>>> >>>> >>>> >>> E2) >>> Should we explicitly add the above phrase to mention that >>> only after a "full adj" : (Only ... established.) was my >>> suggestion without the "???". >>> >>> >>> >>> >>No - In this context, "future" means after the adjacency goes full. One >>should go RFC 1793 for >>a precise definition of demand circuits. >> >> >> >>> And the other question I was raising is whether a mismatch SHOULD >>> cause some (2x) backoff of the hello as to still reduce cost >>> with D/C neighborrs. >>> >>> Seeing hellos on a D/C should say something anyway, so >>> some are needed in case whatever is causing the mismatch >>> is administratively fixed. >>> >>> >>> >>> >>>>> >>>>> >>>>>> 4) transparent functional suggestions >>>>>> >>>>>> to possibly improve convergence, the first hello pkt can >>>>>> be sent the moment the interface becomes active >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>I don't see a need to add this to the specification. >>>> >>>> >>>> >>>> >>>> >>> E3) >>> Yes, this is really a implementation item for >>> improved convergence. I thought that this is >>> a transparent change and should be a common >>> sense item that should be added. I don't know >>> of a single implementation argument against it. >>> >>> >>> >>> >>There is not agreement in the WG on whether or not these little >>implementation tweaks >>which have been practice for many years should be documented in an >>informational RFC. I suggest you collaborate with authors of >>draft-kou-ospf-immediately-replying-hello-00.txt. >> >>Thanks, >>Acee >> >> >> >>> >>> >>> >>>>>> if like routers are used and their is a concern for >>>>>> hello xmit synchronization, after the first hello is >>>>>> sent randomize just the next hello between 0 and the >>>>>> hello interval, then send hellos at the hello interval >>>>>> >>>>>> 5) >>>>>> 3.4.3.2 Network-LSAs >>>>>> >>>>>> "having two or more attached routers" >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>Corrected. >>>> >>>> >>>> >>>> >>>> >>>>>> to >>>>>> >>>>>> having one or more attached routers each having a adjacency >>>>>> with the DR. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> oh... should be full adjacency... >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>New text states this. >>>> >>>>Thanks, >>>>Acee >>>> >>>> >>>> >>>> >>>> >>>>>> Mitchell Erblich >>>>>> --------------------- >>>>>> >>>>>>Acee Lindem wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Hi Tom, >>>>>>> >>>>>>>Henderson, Thomas R wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>I missed this thread when it was on rtg-dir in December, else would have >>>>>>>>commented there. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>This is as good a time as any to comment. I haven't made any changes to >>>>>>>the OSPFv3 update draft :^) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>We have used MOSPF in MANET experiments in the past (Moy's >>>>>>>>implementation) and found it was convenient in that environment. Once >>>>>>>>you have an efficient OSPF for MANET, why run a separate multicast >>>>>>>>routing protocol if you can avoid it? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>I guess for the same reasons you run a separate multicast protocol in a >>>>>>>non-MANET (wired) >>>>>>>environment. However, the decision for wired networks was made a long >>>>>>>time ago and >>>>>>>perhaps today's technologies and the differences in the MANET environment >>>>>>>would yield a different answer. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>So unless there is a bit crisis, I think it may be prudent to keep the >>>>>>>>bits for the time being, since OSPF for MANET is IPv6 only. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>So, you feel that there is a chance that MOSPFv3 may be fully specified >>>>>>>and implemented for >>>>>>>MANET networks sometime in the future (1-4 years). Correct? If there is >>>>>>>serious >>>>>>>consideration of this work, I'll leave the MOSPF specific bits in the >>>>>>>OSPFv3 draft. Any >>>>>>>other comments? >>>>>>> >>>>>>>Thanks, >>>>>>>Acee >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Tom >>>>>>>> >>>>>>>> >>>>>>>>________________________________ >>>>>>>> >>>>>>>> From: Rohit Dube [mailto:dube.rohit@GMAIL.COM] >>>>>>>> Sent: Tuesday, January 10, 2006 10:01 PM >>>>>>>> To: OSPF@PEACH.EASE.LSOFT.COM >>>>>>>> Subject: Re: MOSPF - Multicast OSPF >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>Also note that back in Nov 2002, we had dropped any further protocol >>>>>>>>work on MOSPF (v2) at the WG meeting. >>>>>>>> >>>>>>>>If anybody has a real problem with deprecating the bits (because they >>>>>>>>are implementing MOSPFv3), now would be a good time to step forward. >>>>>>>> >>>>>>>>Best, >>>>>>>>--rohit. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>> >>>>> >>>>> >>> >>> >>> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 23 14:24:19 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F17IY-0006df-VD for ospf-archive@megatron.ietf.org; Mon, 23 Jan 2006 14:24: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 OAA11222 for ; Mon, 23 Jan 2006 14:22:48 -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.0001DE08@wildebeest.ease.lsoft.com>; Mon, 23 Jan 2006 14:23:47 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 97399823 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 23 Jan 2006 14:23:46 -0500 Received: from 206.190.38.104 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 23 Jan 2006 14:13:46 -0500 Received: (qmail 23830 invoked by uid 60001); 23 Jan 2006 19:13:46 -0000 Received: from [206.54.51.125] by web50706.mail.yahoo.com via HTTP; Mon, 23 Jan 2006 11:13:46 PST MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2004102865-1138043626=:21704" Content-Transfer-Encoding: 8bit Message-ID: <20060123191346.23828.qmail@web50706.mail.yahoo.com> Date: Mon, 23 Jan 2006 11:13:46 -0800 Reply-To: Mailing List Sender: Mailing List From: "Aniket D." Subject: 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: --0-2004102865-1138043626=:21704 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I had a question about the Router id and its relation with IPv4 addresses. The popular and common choice for Router Id is the highest loopback IPv4 address or the IPv4 address of any other interface. Now if we continue to use the same scheme for the Router id for OSPFv3, what happens is: A) OSPFv3 process cannot be started until an IPv4 address is configured on the box. B) Suppose: An IPv4 address is configured to start the OSPFv3 routing process. Now if we remove all IPv4 addresses from all the interfaces what is it that should happen. With a Cisco router, the OSPFv3 adjacencies persist and the same router id continues to be used despite that address no longer being configured on any interface on that box. - What this leads you to is that - now if you do a save running-config and reload the box, the OSPFv3 adjacencies wont come up, which were already up before reloading the box. C) What is the right behaviour? Should OSPFv3 adjacencies go down when all IPv4 addresses are removed? D) Should the Router Id be chosen with some other algorithm? Thanks and regards, Aniket. --------------------------------- Yahoo! Photos Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-2004102865-1138043626=:21704 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
I had a question about the Router id and its relation with IPv4 addresses.
 
The popular and common choice for Router Id is the highest loopback IPv4 address or the IPv4 address of any other interface.
 
Now if we continue to use the same scheme for the Router id for OSPFv3, what happens is:
A) OSPFv3 process cannot be started until an IPv4 address is configured on the box.
 
B) Suppose: An IPv4 address is configured to start the OSPFv3 routing process. Now if we remove all IPv4 addresses from all the interfaces what is it that should happen. With a Cisco router, the OSPFv3 adjacencies persist and the same router id continues to be used despite that address no longer being configured on any interface on that box.
- What this leads you to is that - now if you do a save running-config and reload the box, the OSPFv3 adjacencies! wont come up, which were already up before reloading the box.
 
C) What is the right behaviour? Should OSPFv3 adjacencies go down when all IPv4 addresses are removed?
 
D) Should the Router Id be chosen with some other algorithm?
 
Thanks and regards,
Aniket.

Yahoo! Photos
Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. --0-2004102865-1138043626=:21704-- From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 23 14:33:07 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F17R5-0008Bh-EG for ospf-archive@megatron.ietf.org; Mon, 23 Jan 2006 14:33: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 OAA11712 for ; Mon, 23 Jan 2006 14:31:36 -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.0001DE2A@wildebeest.ease.lsoft.com>; Mon, 23 Jan 2006 14:32:35 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 97401035 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 23 Jan 2006 14:32:34 -0500 Received: from 171.71.176.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 23 Jan 2006 14:32:34 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 23 Jan 2006 11:32:34 -0800 Received: from irp-view9.cisco.com (irp-view9.cisco.com [171.70.65.147]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k0NJWXWG023668 for ; Mon, 23 Jan 2006 11:32:33 -0800 (PST) References: <20060123191346.23828.qmail@web50706.mail.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Message-ID: Date: Mon, 23 Jan 2006 11:32:33 -0800 Reply-To: Mailing List Sender: Mailing List From: Abhay Roy Subject: Re: Selection of router id. And behaviour with IPv4 address removal. To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20060123191346.23828.qmail@web50706.mail.yahoo.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: I guess the same "issue" also arises in OSPFv2. The best way to overcome them is to use a manually configured Router ID v/s letting the routers choose automagically.. Regards, -Abhay On 01/23/06-0800 at 11:13am, Aniket D. writes: > I had a question about the Router id and its relation with IPv4 addresses. > > The popular and common choice for Router Id is the highest loopback IPv4 address or the IPv4 address of any other interface. > > Now if we continue to use the same scheme for the Router id for OSPFv3, what happens is: > A) OSPFv3 process cannot be started until an IPv4 address is configured on the box. > > B) Suppose: An IPv4 address is configured to start the OSPFv3 routing process. Now if we remove all IPv4 addresses from all the interfaces what is it that should happen. With a Cisco router, the OSPFv3 adjacencies persist and the same router id continues to be used despite that address no longer being configured on any interface on that box. > - What this leads you to is that - now if you do a save running-config and reload the box, the OSPFv3 adjacencies wont come up, which were already up before reloading the box. > > C) What is the right behaviour? Should OSPFv3 adjacencies go down when all IPv4 addresses are removed? > > D) Should the Router Id be chosen with some other algorithm? > > Thanks and regards, > Aniket. > > > > --------------------------------- > Yahoo! Photos > Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever. From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 23 23:26:18 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Fl4-0001LS-6Q for ospf-archive@megatron.ietf.org; Mon, 23 Jan 2006 23:26: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 XAA03360 for ; Mon, 23 Jan 2006 23:24:48 -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.0001DFF0@wildebeest.ease.lsoft.com>; Mon, 23 Jan 2006 23:25:46 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 97432602 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 23 Jan 2006 23:25:46 -0500 Received: from 207.69.195.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 23 Jan 2006 23:25:46 -0500 Received: from h-68-164-83-132.snvacaid.dynamic.covad.net ([68.164.83.132] helo=earthlink.net) by pop-sarus.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1F1FkW-0000Hv-00; Mon, 23 Jan 2006 23:25: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: <77F357662F8BFA4CA7074B0410171B6DC9E8C9@XCH-NW-5V1.nw.nos.boeing.com> <43C6ED74.5070506@cisco.com> <43C70AE8.4052557C@earthlink.net> <43C800B4.90FA9D51@earthlink.net> <43CEB516.6060604@cisco.com> <43CEF47F.B8AF28C5@earthlink.net> <43D11EBA.7050707@cisco.com> <43D16A8B.3167534D@earthlink.net> <43D16BC9.3050008@cisco.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43D5AA1B.BF111384@earthlink.net> Date: Mon, 23 Jan 2006 20:16:27 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: draft comments : 2740 update Comments: To: pmurphy@noc.usgs.net To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Acee, This is an example of items that IMO SHOULD have at least mention the new area type within the V2 and V3 mods to OSPF. FYI to readers: Well known OSPF implimentors had publicly documented an area type known as "Totally Stubby" that removes all Type-3 LSAs, except a single type-3 to advertise the default route. This was done YEARS ago. 3101 now has the ImportSummmaries of the NSSA RFC that covers the usage of Type-3 LSAs and when NOT-ENABLED, transforms support for the "Totally Stubby" area type. ---->RFC 3101 Suggested line addition. 2.7 Optionally Importing Summary Routes "This alternate type-3 behaviour is part of a sub-area type known as "Totally Stubby". -------------- So, In general I would have expected that the original and newer v3 specs to explicitly mention the sub, NSSA, and the totally stubby area type, with the last one mentioning a possible change of behaviour of LSA type-3s. This is because alot of readers will not associate the well known area type of "Totally Stubby", with this new change. Mitchell Erblich =================== Acee Lindem wrote: > > Mitchell, > > Erblichs wrote: > > >Acee, et al, > > > > This is getting messy.. > > > > I guess you raised to me what seems like a bigger > > question. Should generic protocol RFCs (Ex:2740) at > > the time of creation or modificiation attempt to > > generate an illusion of completeness? > > > > If this is so, then yes, I would like to see at least > > all exceptions to common expected practices that could > > be "hidden" within one of tens of RFCs. > > > > > When the exception needs to be documented for the specification to be > correct, I'll > add it or re-word the text. I am not going to document every exception > every time > a given protocol construct is mentioned. As Editor, I'll make the > determination of > whether or not a suggestion adds value or simply bulk. > > > Yes, I would like to see a Reference to Graceful Restart > > within this spec, if and only if (iff) it is a publicly > > documented spec AND it is(to become) common. Else, > > how would the people who read the V2 or V3 specs just > > know of its existance. > > > > Ex: So, who can find me in what RFC totally stubby area > > support is defined? NSSA is Ref in v3 and v2. > > > > > RFC 3101 is the definitive source for OSPF NSSA. The OSPFv3 unique encodings > and protocol processing are included in the draft. If any are missing, > please bring them > forward. > > > And, i think we SHOULD make these RFCs with as minimal > > amount of ambiguity as possible and cross-reference them > > as freq as possible, to make sure that ALL curently supported > > implimnetations support a common set of features. > > > > Thus, if major changes were being done, yes, I would > > also suggest incorporation how each LSA type with its > > various scope is handled in stubs, totally stubby, > > not so totally stubby, etc area interactions. > > > > So, the RFC had/has the GM LSA as one of the 9 types > > and a separate RFC defines its processing, so I did > > see a need to include it, because it is slated for > > removal. But as it should be clear, at best IMO it > > should at most go to reserve with the type value and > > not reused. It could then be covered with other unknown > > types as you stated in a earlier email. > >I've change this to "each router on the network with > >neighbor > >state 1-Way or greater". > > > > > > > > Yes, I agree, this is more accurate, But it looses > > the implicit hello pkt to hello pkt field exchange. > > > > > This section describes the hello packet format. > > > > > > >>Since this section is defining RouterDeadInterval, I'm not sure we want > >>to try and document > >>every case where it isn't applicable. > >> > >> > > > > Why not? :) > > Actually, in general, I would expect us to list at least > > A FEW exceptions as we see them and indicate in a footnote > > that the list may not be ALL encompassing. > > > > Else, we should consider it as an equiv as a Architectural > > constant. > > > > > I disagree. It isn't really necessary. If one is going to implement > demand circuits one must > consult RFC 1793. I'd reconsider if you can garner the support of > others. Otherwise, give it > up. > > > > > > > > > > >>There is not agreement in the WG on whether or not these little > >>implementation tweaks > >>which have been practice for many years should be documented in an > >>informational RFC. > >> > >> > > > > If "little implemenatation tweaks" are common public > > practice, then at least they should be documented/ standardized, > > IMO. > > > > > My previous suggestion on who to collaborate with still holds. > > Thanks, > Acee > > > Mitchell Erblich > > ---------------------- > > > > > > > > > >Acee Lindem wrote: > > > > > >>Hi Mitchell, > >> > >>Erblichs wrote: > >> > >> > >> > >>>Acee, et al, > >>> > >>> Just a few additional item Suggestions: > >>> > >>> A) A.3.2 The Hello Packet > >>> > >>> Neighbor Id > >>> > >>> Append -> (exception of D/C neighbors) > >>> > >>> Where I don't expect to see a hello within > >>> RouterDeadInterval sec. > >>> > >>> > >>> > >>> > >>This could be a slippery slope to try and incorporate every exception > >>case. One could > >>make the same argument for graceful restart when the grace interval is > >>greater than > >>the dead interval. I've change this to "each router on the network with > >>neighbor > >>state 1-Way or greater". > >> > >> > >> > >>> B) A.3.3 DD Packet field layout > >>> > >>> Options field is shown 1 bit to small. > >>> > >>> > >>> > >>> > >>Bits 8-31 - It's 24 bits as defined. > >> > >> > >> > >>> C) A.3.6 > >>> To make the flooding of LSAs reliable, flooded > >>> LSAs are explicitly acknowledged. > >>> > >>> Shouldn't it be ... flooded LSAs are explicitly or > >>> implicitly acknowledged. > >>> > >>> Then ... > >>> > >>> This acknowledgment is ... > >>> > >>> to > >>> > >>> The explicit acknowledgment is > >>> > >>> > >>> > >>> > >>Corrected (although I think the intent was clear without it). > >> > >> > >> > >>> D) C.3 > >>> RouterDeadInterval > >>> > >>> before its neighbors declare the router down > >>> > >>> to > >>> > >>> before its neighbors declare the non D/C neighbor > >>> down. > >>> > >>> We are talking about missing hellos here.. > >>> > >>> > >>> > >>> > >>Since this section is defining RouterDeadInterval, I'm not sure we want > >>to try and document > >>every case where it isn't applicable. > >> > >> > >> > >>> E) 3 items: Inline.. > >>> > >>> > >>> Mitchell Erblich > >>> -------------------------- > >>> > >>> > >>> > >>>Acee Lindem wrote: > >>> > >>> > >>> > >>> > >>>>Hi Mitchell, > >>>> > >>>>Thanks for the comments. See inline. > >>>> > >>>>Erblichs wrote: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>group, > >>>>> > >>>>> yes, these are suggested comments to the 2740 revision.. > >>>>> > >>>>> Mitchell Erblich > >>>>> ----------------- > >>>>> > >>>>>Erblichs wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>Acee, et, al, > >>>>>> > >>>>>> Here are my first few comments. I will give you more > >>>>>> this weekend if my reading is to your aggreement. > >>>>>> > >>>>>> 1) > >>>>>> A.4 LSA formats > >>>>>> "defines seven distinct types of LSAs." > >>>>>> > >>>>>> A.4.2.1 LSA Type : lists 9 types, thus seven -> nine > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>We have router-LSAs, network-LSAs, intra-area-prefix-LSAs, > >>>>inter-area-prefix-LSAs, > >>>>inter-area-router-LSAs, AS-external-LSAs, link-LSAs, and NSSA-LSAs. > >>>>That makes > >>>>eight - Corrected. > >>>> > >>>> > >>>> > >>>> > >>>> > >>> E1) --> Group-membership-LSA was in the list > >>> > >>> > >>> > >>> > >>The format of this LSA is not documented in this specification. In fact, > >>we were considering > >>getting rid of it completely but there was some opposition. > >> > >> > >> > >>>>>> 2) > >>>>>> 3.1.3 Neighbor Data Structure > >>>>>> > >>>>>> > >>>>>> Neighbor's Backup Designated Router > >>>>>> > >>>>>> The neighbor's choice of Designated Router is now encoded as a > >>>>>> Router ID instead of as an IP address. > >>>>>> > >>>>>> Insert Backup between : Designated Router, because we are > >>>>>> talking about the BDR. Or have you now the the same router > >>>>>> ID for the DR and BDR? :^) > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> ... choice of Backup Designated Router .... > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>Corrected. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>> 3) > >>>>>> 3.2.1.1 Sending Hello packets > >>>>>> > >>>>>> and the DC-bit is set if > >>>>>> and only if the router wishes to suppress the sending of future > >>>>>> Hellos over the interface (see [DEMAND]). > >>>>>> > >>>>>> ONLY after an a "full" adj has been established ?????? > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> as I am assuming that hello supression should not be done > >>>>> until after at least 2-way state is attempted to be achieved. > >>>>> > >>>>> No, I am not 100% sure whether hellos should be > >>>>> sent on a DC link if their is a hello mismatch at the > >>>>> normal hello-interval or some less freq 2x interval > >>>>> should be chosen. Cost versus reliability / notification. > >>>>> > >>>>> Thus, it is assumed that the repeated hellos on a DC link could > >>>>> be an indication that a adj hasn't formed. Need to ask the DC > >>>>> authors.. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>The DC bit is set anytime the hello sender wants to negotiate Demand > >>>>Circuit operation. My assumption > >>>>is that the DC specification doesn't have any unique changes for OSPFv3 > >>>>(other than the location > >>>>of the option bit in the options). BTW, you are correct that hello > >>>>suppression doesn't kick in until > >>>>FULL state is reached. > >>>> > >>>> > >>>> > >>>> > >>>> > >>> E2) > >>> Should we explicitly add the above phrase to mention that > >>> only after a "full adj" : (Only ... established.) was my > >>> suggestion without the "???". > >>> > >>> > >>> > >>> > >>No - In this context, "future" means after the adjacency goes full. One > >>should go RFC 1793 for > >>a precise definition of demand circuits. > >> > >> > >> > >>> And the other question I was raising is whether a mismatch SHOULD > >>> cause some (2x) backoff of the hello as to still reduce cost > >>> with D/C neighborrs. > >>> > >>> Seeing hellos on a D/C should say something anyway, so > >>> some are needed in case whatever is causing the mismatch > >>> is administratively fixed. > >>> > >>> > >>> > >>> > >>>>> > >>>>> > >>>>>> 4) transparent functional suggestions > >>>>>> > >>>>>> to possibly improve convergence, the first hello pkt can > >>>>>> be sent the moment the interface becomes active > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>I don't see a need to add this to the specification. > >>>> > >>>> > >>>> > >>>> > >>>> > >>> E3) > >>> Yes, this is really a implementation item for > >>> improved convergence. I thought that this is > >>> a transparent change and should be a common > >>> sense item that should be added. I don't know > >>> of a single implementation argument against it. > >>> > >>> > >>> > >>> > >>There is not agreement in the WG on whether or not these little > >>implementation tweaks > >>which have been practice for many years should be documented in an > >>informational RFC. I suggest you collaborate with authors of > >>draft-kou-ospf-immediately-replying-hello-00.txt. > >> > >>Thanks, > >>Acee > >> > >> > >> > >>> > >>> > >>> > >>>>>> if like routers are used and their is a concern for > >>>>>> hello xmit synchronization, after the first hello is > >>>>>> sent randomize just the next hello between 0 and the > >>>>>> hello interval, then send hellos at the hello interval > >>>>>> > >>>>>> 5) > >>>>>> 3.4.3.2 Network-LSAs > >>>>>> > >>>>>> "having two or more attached routers" > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>Corrected. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>> to > >>>>>> > >>>>>> having one or more attached routers each having a adjacency > >>>>>> with the DR. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> oh... should be full adjacency... > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>New text states this. > >>>> > >>>>Thanks, > >>>>Acee > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>> Mitchell Erblich > >>>>>> --------------------- > >>>>>> > >>>>>>Acee Lindem wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>Hi Tom, > >>>>>>> > >>>>>>>Henderson, Thomas R wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>I missed this thread when it was on rtg-dir in December, else would have > >>>>>>>>commented there. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>This is as good a time as any to comment. I haven't made any changes to > >>>>>>>the OSPFv3 update draft :^) > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>We have used MOSPF in MANET experiments in the past (Moy's > >>>>>>>>implementation) and found it was convenient in that environment. Once > >>>>>>>>you have an efficient OSPF for MANET, why run a separate multicast > >>>>>>>>routing protocol if you can avoid it? > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>I guess for the same reasons you run a separate multicast protocol in a > >>>>>>>non-MANET (wired) > >>>>>>>environment. However, the decision for wired networks was made a long > >>>>>>>time ago and > >>>>>>>perhaps today's technologies and the differences in the MANET environment > >>>>>>>would yield a different answer. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>So unless there is a bit crisis, I think it may be prudent to keep the > >>>>>>>>bits for the time being, since OSPF for MANET is IPv6 only. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>So, you feel that there is a chance that MOSPFv3 may be fully specified > >>>>>>>and implemented for > >>>>>>>MANET networks sometime in the future (1-4 years). Correct? If there is > >>>>>>>serious > >>>>>>>consideration of this work, I'll leave the MOSPF specific bits in the > >>>>>>>OSPFv3 draft. Any > >>>>>>>other comments? > >>>>>>> > >>>>>>>Thanks, > >>>>>>>Acee > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>Tom > >>>>>>>> > >>>>>>>> > >>>>>>>>________________________________ > >>>>>>>> > >>>>>>>> From: Rohit Dube [mailto:dube.rohit@GMAIL.COM] > >>>>>>>> Sent: Tuesday, January 10, 2006 10:01 PM > >>>>>>>> To: OSPF@PEACH.EASE.LSOFT.COM > >>>>>>>> Subject: Re: MOSPF - Multicast OSPF > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>Also note that back in Nov 2002, we had dropped any further protocol > >>>>>>>>work on MOSPF (v2) at the WG meeting. > >>>>>>>> > >>>>>>>>If anybody has a real problem with deprecating the bits (because they > >>>>>>>>are implementing MOSPFv3), now would be a good time to step forward. > >>>>>>>> > >>>>>>>>Best, > >>>>>>>>--rohit. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>> > >>>>> > >>>>> > >>> > >>> > >>> > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jan 24 13:58:22 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1TN0-0004Vm-EU for ospf-archive@megatron.ietf.org; Tue, 24 Jan 2006 13:58: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 NAA09437 for ; Tue, 24 Jan 2006 13:56: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 <3.0001E1CB@wildebeest.ease.lsoft.com>; Tue, 24 Jan 2006 13:57:48 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 97495095 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 24 Jan 2006 13:57:47 -0500 Received: from 171.71.176.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 24 Jan 2006 13:57:47 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 24 Jan 2006 10:57:47 -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 k0OIvjKX000638 for ; Tue, 24 Jan 2006 10:57: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); Tue, 24 Jan 2006 13:57:46 -0500 Received: from [10.82.209.43] ([10.82.209.43]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 Jan 2006 13:57:45 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <77F357662F8BFA4CA7074B0410171B6DC9E8C9@XCH-NW-5V1.nw.nos.boeing.com> <43C6ED74.5070506@cisco.com> <43C70AE8.4052557C@earthlink.net> <43C800B4.90FA9D51@earthlink.net> <43CEB516.6060604@cisco.com> <43CEF47F.B8AF28C5@earthlink.net> <43D11EBA.7050707@cisco.com> <43D16A8B.3167534D@earthlink.net> <43D16BC9.3050008@cisco.com> <43D5AA1B.BF111384@earthlink.net> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jan 2006 18:57:45.0355 (UTC) FILETIME=[0FBC05B0:01C62118] Message-ID: <43D678A8.9060806@cisco.com> Date: Tue, 24 Jan 2006 13:57:44 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft comments : 2740 update To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43D5AA1B.BF111384@earthlink.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Mitchell, Erblichs wrote: >Acee, > This is an example of items that IMO SHOULD have > at least mention the new area type within > the V2 and V3 mods to OSPF. > > FYI to readers: Well known OSPF implimentors > had publicly documented an area type > known as "Totally Stubby" that removes > all Type-3 LSAs, except a single type-3 > to advertise the default route. This was > done YEARS ago. > > 3101 now has the ImportSummmaries > of the NSSA RFC that covers the usage > of Type-3 LSAs and when NOT-ENABLED, > transforms support for the "Totally Stubby" > area type. > > ---->RFC 3101 Suggested line addition. > > 2.7 Optionally Importing Summary Routes > "This alternate type-3 behaviour is part of a > sub-area type known as "Totally Stubby". > -------------- > > So, In general I would have expected that the > original and newer v3 specs to explicitly mention > the sub, NSSA, and the totally > stubby area type, with the last one mentioning a > possible change of behaviour of LSA type-3s. This > is because alot of readers will not associate the > well known area type of "Totally Stubby", with > this new change. > > Characterizing an NSSA or stub area with ImportSummaries enabled as a "Totally Stubby" is not necessary to understand or implement the NSSA specification. I believe the term was coined by my current employer and later adopted by other vendors. However, that doesn't mean it needs to be part of the standard. Notice that nobody has you configure these as new area types. I did add "ImportSummaries" to appendix C.2. Any other opinions? Thanks, Acee > > Mitchell Erblich > =================== > > > > >Acee Lindem wrote: > > >>Mitchell, >> >>Erblichs wrote: >> >> >> >>>Acee, et al, >>> >>> This is getting messy.. >>> >>> I guess you raised to me what seems like a bigger >>> question. Should generic protocol RFCs (Ex:2740) at >>> the time of creation or modificiation attempt to >>> generate an illusion of completeness? >>> >>> If this is so, then yes, I would like to see at least >>> all exceptions to common expected practices that could >>> be "hidden" within one of tens of RFCs. >>> >>> >>> >>> >>When the exception needs to be documented for the specification to be >>correct, I'll >>add it or re-word the text. I am not going to document every exception >>every time >>a given protocol construct is mentioned. As Editor, I'll make the >>determination of >>whether or not a suggestion adds value or simply bulk. >> >> >> >>> Yes, I would like to see a Reference to Graceful Restart >>> within this spec, if and only if (iff) it is a publicly >>> documented spec AND it is(to become) common. Else, >>> how would the people who read the V2 or V3 specs just >>> know of its existance. >>> >>> Ex: So, who can find me in what RFC totally stubby area >>> support is defined? NSSA is Ref in v3 and v2. >>> >>> >>> >>> >>RFC 3101 is the definitive source for OSPF NSSA. The OSPFv3 unique encodings >>and protocol processing are included in the draft. If any are missing, >>please bring them >>forward. >> >> > > > > >>> And, i think we SHOULD make these RFCs with as minimal >>> amount of ambiguity as possible and cross-reference them >>> as freq as possible, to make sure that ALL curently supported >>> implimnetations support a common set of features. >>> >>> Thus, if major changes were being done, yes, I would >>> also suggest incorporation how each LSA type with its >>> various scope is handled in stubs, totally stubby, >>> not so totally stubby, etc area interactions. >>> >>> So, the RFC had/has the GM LSA as one of the 9 types >>> and a separate RFC defines its processing, so I did >>> see a need to include it, because it is slated for >>> removal. But as it should be clear, at best IMO it >>> should at most go to reserve with the type value and >>> not reused. It could then be covered with other unknown >>> types as you stated in a earlier email. >>>I've change this to "each router on the network with >>>neighbor >>>state 1-Way or greater". >>> >>> >>> >>> Yes, I agree, this is more accurate, But it looses >>> the implicit hello pkt to hello pkt field exchange. >>> >>> >>> >>> >>This section describes the hello packet format. >> >> >> >>> >>> >>>>Since this section is defining RouterDeadInterval, I'm not sure we want >>>>to try and document >>>>every case where it isn't applicable. >>>> >>>> >>>> >>>> >>> Why not? :) >>> Actually, in general, I would expect us to list at least >>> A FEW exceptions as we see them and indicate in a footnote >>> that the list may not be ALL encompassing. >>> >>> Else, we should consider it as an equiv as a Architectural >>> constant. >>> >>> >>> >>> >>I disagree. It isn't really necessary. If one is going to implement >>demand circuits one must >>consult RFC 1793. I'd reconsider if you can garner the support of >>others. Otherwise, give it >>up. >> >> >> >>> >>> >>> >>> >>>>There is not agreement in the WG on whether or not these little >>>>implementation tweaks >>>>which have been practice for many years should be documented in an >>>>informational RFC. >>>> >>>> >>>> >>>> >>> If "little implemenatation tweaks" are common public >>> practice, then at least they should be documented/ standardized, >>> IMO. >>> >>> >>> >>> >>My previous suggestion on who to collaborate with still holds. >> >>Thanks, >>Acee >> >> >> >>> Mitchell Erblich >>> ---------------------- >>> >>> >>> >>> >>>Acee Lindem wrote: >>> >>> >>> >>> >>>>Hi Mitchell, >>>> >>>>Erblichs wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Acee, et al, >>>>> >>>>> Just a few additional item Suggestions: >>>>> >>>>> A) A.3.2 The Hello Packet >>>>> >>>>> Neighbor Id >>>>> >>>>> Append -> (exception of D/C neighbors) >>>>> >>>>> Where I don't expect to see a hello within >>>>> RouterDeadInterval sec. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>This could be a slippery slope to try and incorporate every exception >>>>case. One could >>>>make the same argument for graceful restart when the grace interval is >>>>greater than >>>>the dead interval. I've change this to "each router on the network with >>>>neighbor >>>>state 1-Way or greater". >>>> >>>> >>>> >>>> >>>> >>>>> B) A.3.3 DD Packet field layout >>>>> >>>>> Options field is shown 1 bit to small. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>Bits 8-31 - It's 24 bits as defined. >>>> >>>> >>>> >>>> >>>> >>>>> C) A.3.6 >>>>> To make the flooding of LSAs reliable, flooded >>>>> LSAs are explicitly acknowledged. >>>>> >>>>> Shouldn't it be ... flooded LSAs are explicitly or >>>>> implicitly acknowledged. >>>>> >>>>> Then ... >>>>> >>>>> This acknowledgment is ... >>>>> >>>>> to >>>>> >>>>> The explicit acknowledgment is >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>Corrected (although I think the intent was clear without it). >>>> >>>> >>>> >>>> >>>> >>>>> D) C.3 >>>>> RouterDeadInterval >>>>> >>>>> before its neighbors declare the router down >>>>> >>>>> to >>>>> >>>>> before its neighbors declare the non D/C neighbor >>>>> down. >>>>> >>>>> We are talking about missing hellos here.. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>Since this section is defining RouterDeadInterval, I'm not sure we want >>>>to try and document >>>>every case where it isn't applicable. >>>> >>>> >>>> >>>> >>>> >>>>> E) 3 items: Inline.. >>>>> >>>>> >>>>> Mitchell Erblich >>>>> -------------------------- >>>>> >>>>> >>>>> >>>>>Acee Lindem wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Hi Mitchell, >>>>>> >>>>>>Thanks for the comments. See inline. >>>>>> >>>>>>Erblichs wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>group, >>>>>>> >>>>>>> yes, these are suggested comments to the 2740 revision.. >>>>>>> >>>>>>> Mitchell Erblich >>>>>>> ----------------- >>>>>>> >>>>>>>Erblichs wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Acee, et, al, >>>>>>>> >>>>>>>> Here are my first few comments. I will give you more >>>>>>>> this weekend if my reading is to your aggreement. >>>>>>>> >>>>>>>> 1) >>>>>>>> A.4 LSA formats >>>>>>>> "defines seven distinct types of LSAs." >>>>>>>> >>>>>>>> A.4.2.1 LSA Type : lists 9 types, thus seven -> nine >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>We have router-LSAs, network-LSAs, intra-area-prefix-LSAs, >>>>>>inter-area-prefix-LSAs, >>>>>>inter-area-router-LSAs, AS-external-LSAs, link-LSAs, and NSSA-LSAs. >>>>>>That makes >>>>>>eight - Corrected. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> E1) --> Group-membership-LSA was in the list >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>The format of this LSA is not documented in this specification. In fact, >>>>we were considering >>>>getting rid of it completely but there was some opposition. >>>> >>>> >>>> >>>> >>>> >>>>>>>> 2) >>>>>>>> 3.1.3 Neighbor Data Structure >>>>>>>> >>>>>>>> >>>>>>>> Neighbor's Backup Designated Router >>>>>>>> >>>>>>>> The neighbor's choice of Designated Router is now encoded as a >>>>>>>> Router ID instead of as an IP address. >>>>>>>> >>>>>>>> Insert Backup between : Designated Router, because we are >>>>>>>> talking about the BDR. Or have you now the the same router >>>>>>>> ID for the DR and BDR? :^) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> ... choice of Backup Designated Router .... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>Corrected. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> 3) >>>>>>>> 3.2.1.1 Sending Hello packets >>>>>>>> >>>>>>>> and the DC-bit is set if >>>>>>>> and only if the router wishes to suppress the sending of future >>>>>>>> Hellos over the interface (see [DEMAND]). >>>>>>>> >>>>>>>> ONLY after an a "full" adj has been established ?????? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> as I am assuming that hello supression should not be done >>>>>>> until after at least 2-way state is attempted to be achieved. >>>>>>> >>>>>>> No, I am not 100% sure whether hellos should be >>>>>>> sent on a DC link if their is a hello mismatch at the >>>>>>> normal hello-interval or some less freq 2x interval >>>>>>> should be chosen. Cost versus reliability / notification. >>>>>>> >>>>>>> Thus, it is assumed that the repeated hellos on a DC link could >>>>>>> be an indication that a adj hasn't formed. Need to ask the DC >>>>>>> authors.. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>The DC bit is set anytime the hello sender wants to negotiate Demand >>>>>>Circuit operation. My assumption >>>>>>is that the DC specification doesn't have any unique changes for OSPFv3 >>>>>>(other than the location >>>>>>of the option bit in the options). BTW, you are correct that hello >>>>>>suppression doesn't kick in until >>>>>>FULL state is reached. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> E2) >>>>> Should we explicitly add the above phrase to mention that >>>>> only after a "full adj" : (Only ... established.) was my >>>>> suggestion without the "???". >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>No - In this context, "future" means after the adjacency goes full. One >>>>should go RFC 1793 for >>>>a precise definition of demand circuits. >>>> >>>> >>>> >>>> >>>> >>>>> And the other question I was raising is whether a mismatch SHOULD >>>>> cause some (2x) backoff of the hello as to still reduce cost >>>>> with D/C neighborrs. >>>>> >>>>> Seeing hellos on a D/C should say something anyway, so >>>>> some are needed in case whatever is causing the mismatch >>>>> is administratively fixed. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>> >>>>>>> >>>>>>>> 4) transparent functional suggestions >>>>>>>> >>>>>>>> to possibly improve convergence, the first hello pkt can >>>>>>>> be sent the moment the interface becomes active >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>I don't see a need to add this to the specification. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> E3) >>>>> Yes, this is really a implementation item for >>>>> improved convergence. I thought that this is >>>>> a transparent change and should be a common >>>>> sense item that should be added. I don't know >>>>> of a single implementation argument against it. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>There is not agreement in the WG on whether or not these little >>>>implementation tweaks >>>>which have been practice for many years should be documented in an >>>>informational RFC. I suggest you collaborate with authors of >>>>draft-kou-ospf-immediately-replying-hello-00.txt. >>>> >>>>Thanks, >>>>Acee >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>>>>> if like routers are used and their is a concern for >>>>>>>> hello xmit synchronization, after the first hello is >>>>>>>> sent randomize just the next hello between 0 and the >>>>>>>> hello interval, then send hellos at the hello interval >>>>>>>> >>>>>>>> 5) >>>>>>>> 3.4.3.2 Network-LSAs >>>>>>>> >>>>>>>> "having two or more attached routers" >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>Corrected. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> to >>>>>>>> >>>>>>>> having one or more attached routers each having a adjacency >>>>>>>> with the DR. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> oh... should be full adjacency... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>New text states this. >>>>>> >>>>>>Thanks, >>>>>>Acee >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> Mitchell Erblich >>>>>>>> --------------------- >>>>>>>> >>>>>>>>Acee Lindem wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>Hi Tom, >>>>>>>>> >>>>>>>>>Henderson, Thomas R wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>I missed this thread when it was on rtg-dir in December, else would have >>>>>>>>>>commented there. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>This is as good a time as any to comment. I haven't made any changes to >>>>>>>>>the OSPFv3 update draft :^) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>We have used MOSPF in MANET experiments in the past (Moy's >>>>>>>>>>implementation) and found it was convenient in that environment. Once >>>>>>>>>>you have an efficient OSPF for MANET, why run a separate multicast >>>>>>>>>>routing protocol if you can avoid it? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>I guess for the same reasons you run a separate multicast protocol in a >>>>>>>>>non-MANET (wired) >>>>>>>>>environment. However, the decision for wired networks was made a long >>>>>>>>>time ago and >>>>>>>>>perhaps today's technologies and the differences in the MANET environment >>>>>>>>>would yield a different answer. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>So unless there is a bit crisis, I think it may be prudent to keep the >>>>>>>>>>bits for the time being, since OSPF for MANET is IPv6 only. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>So, you feel that there is a chance that MOSPFv3 may be fully specified >>>>>>>>>and implemented for >>>>>>>>>MANET networks sometime in the future (1-4 years). Correct? If there is >>>>>>>>>serious >>>>>>>>>consideration of this work, I'll leave the MOSPF specific bits in the >>>>>>>>>OSPFv3 draft. Any >>>>>>>>>other comments? >>>>>>>>> >>>>>>>>>Thanks, >>>>>>>>>Acee >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>Tom >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>________________________________ >>>>>>>>>> >>>>>>>>>> From: Rohit Dube [mailto:dube.rohit@GMAIL.COM] >>>>>>>>>> Sent: Tuesday, January 10, 2006 10:01 PM >>>>>>>>>> To: OSPF@PEACH.EASE.LSOFT.COM >>>>>>>>>> Subject: Re: MOSPF - Multicast OSPF >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>Also note that back in Nov 2002, we had dropped any further protocol >>>>>>>>>>work on MOSPF (v2) at the WG meeting. >>>>>>>>>> >>>>>>>>>>If anybody has a real problem with deprecating the bits (because they >>>>>>>>>>are implementing MOSPFv3), now would be a good time to step forward. >>>>>>>>>> >>>>>>>>>>Best, >>>>>>>>>>--rohit. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>> >>> >>> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 25 00:11:54 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1cwk-00033l-Fb for ospf-archive@megatron.ietf.org; Wed, 25 Jan 2006 00:11: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 AAA08911 for ; Wed, 25 Jan 2006 00:10: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 <1.0001E3B6@wildebeest.ease.lsoft.com>; Wed, 25 Jan 2006 0:11:21 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 97530541 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 25 Jan 2006 00:11:21 -0500 Received: from 207.69.195.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 25 Jan 2006 00:00:39 -0500 Received: from h-68-164-83-132.snvacaid.dynamic.covad.net ([68.164.83.132] helo=earthlink.net) by pop-sarus.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1F1Xtl-0007Tw-00 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 24 Jan 2006 18:48:29 -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: <43D6BE67.59B28AFA@earthlink.net> Date: Tue, 24 Jan 2006 15:55:19 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: RFC 2740 : LSDB Unknowns and stubs To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Acee, working group, et al, Have you considered for section 2.1 Stub area support of a limit of unrecognized LS types? Wouldn't a RFC 1765 Database Overflow equivalent prevent this from occuring? Yes, place a high watermark level of ALL unrecognized LS types for stubs. Since we are talking about area scope, the offending routers could prioritize what they originate IFF the limit is reached, IMO. Mitchell Erblich -------------------- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 25 07:05:44 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1jPE-0005np-5q for ospf-archive@megatron.ietf.org; Wed, 25 Jan 2006 07:05: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 HAA04855 for ; Wed, 25 Jan 2006 07:04:13 -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.0001E407@wildebeest.ease.lsoft.com>; Wed, 25 Jan 2006 7:05:12 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 97553194 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 25 Jan 2006 07:05:12 -0500 Received: from 203.196.196.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 25 Jan 2006 07:05:11 -0500 Received: from netd.com ([10.91.0.5]) (authenticated bits=0) by BLR-MAIL.NETD.COM (8.12.8/8.12.8) with ESMTP id k0PC9aAE003052; Wed, 25 Jan 2006 17:39:37 +0530 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20060123191346.23828.qmail@web50706.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NetD-India-MailScanner-Information: Please contact the NetD-India Sysadmin for more information X-NetD-India-MailScanner: Found to be clean X-MailScanner-From: tajay@netd.com Message-ID: <43D76890.4090500@netd.com> Date: Wed, 25 Jan 2006 17:31:20 +0530 Reply-To: Mailing List Sender: Mailing List From: AJAY THAKUR Subject: Re: Selection of router id. And behaviour with IPv4 address removal. To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20060123191346.23828.qmail@web50706.mail.yahoo.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Aniket, This is related to implementation. Starting ospf process without router-Id is not allowed in cisco but it is not true for other implementations. But still I do have some more question on the same topic, (1) Configure ip address 1.1.1.1 Now this is ospf router id (2) Now configure ip address 2.2.2.2 Now still ospf uses 1.1.1.1 as router-Id. (3) Now uncofigure 1.1.1.1 ip address. Now if you reload the box ospf will not identify self-originated lsa and in this case these lsa will remain in database for MAX_AGE. What do you say about this behaviour? Thanks ajay Aniket D. wrote: > I had a question about the Router id and its relation with IPv4 addresses. > > The popular and common choice for Router Id is the highest loopback > IPv4 address or the IPv4 address of any other interface. > > Now if we continue to use the same scheme for the Router id for > OSPFv3, what happens is: > A) OSPFv3 process cannot be started until an IPv4 address is > configured on the box. > > B) Suppose: An IPv4 address is configured to start the OSPFv3 routing > process. Now if we remove all IPv4 addresses from all the interfaces > what is it that should happen. With a Cisco router, the OSPFv3 > adjacencies persist and the same router id continues to be used > despite that address no longer being configured on any interface on > that box. > - What this leads you to is that - now if you do a save running-config > and reload the box, the OSPFv3 adjacencies! wont come up, which were > already up before reloading the box. > > C) What is the right behaviour? Should OSPFv3 adjacencies go down when > all IPv4 addresses are removed? > > D) Should the Router Id be chosen with some other algorithm? > > Thanks and regards, > Aniket. > > ------------------------------------------------------------------------ > Yahoo! Photos > Ring in the New Year with Photo Calendars > . > Add photos, events, holidays, whatever. From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 25 09:54:31 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1m2Z-0005Nv-QU for ospf-archive@megatron.ietf.org; Wed, 25 Jan 2006 09:54: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 JAA18346 for ; Wed, 25 Jan 2006 09:53:00 -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.0001E48C@wildebeest.ease.lsoft.com>; Wed, 25 Jan 2006 9:54:00 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 97562028 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 25 Jan 2006 09:53:59 -0500 Received: from 171.71.176.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 25 Jan 2006 09:53:59 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 25 Jan 2006 06:53:59 -0800 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 k0PErxWF012823 for ; Wed, 25 Jan 2006 06:53:59 -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, 25 Jan 2006 09:53:58 -0500 Received: from [10.82.209.43] ([10.82.209.43]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 Jan 2006 09:53:58 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <43D6BE67.59B28AFA@earthlink.net> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jan 2006 14:53:58.0539 (UTC) FILETIME=[2BE2C5B0:01C621BF] Message-ID: <43D79106.2030707@cisco.com> Date: Wed, 25 Jan 2006 09:53:58 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: RFC 2740 : LSDB Unknowns and stubs To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43D6BE67.59B28AFA@earthlink.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Mitchell, Erblichs wrote: >Acee, working group, et al, > > Have you considered for section 2.1 Stub area support > of a limit of unrecognized LS types? > > The removal of the existing restriction of ABR propagation of unknown LSAs was discussed and decided a while back: http://www3.ietf.org/proceedings/05aug/slides/ospf-2/sld1.htm > Wouldn't a RFC 1765 Database Overflow equivalent prevent > this from occuring? > > Yes, place a high watermark level of ALL unrecognized > LS types for stubs. > > Since we are talking about area scope, the offending > routers could prioritize what they originate IFF the > limit is reached, IMO. > > I'd consider this a new proposal. I don't see it as having much merit but that would be for the OSPF WG to decide. Thanks, Acee > Mitchell Erblich > -------------------- > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Jan 25 13:46:15 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1peo-0005fY-S5 for ospf-archive@megatron.ietf.org; Wed, 25 Jan 2006 13:46: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 NAA12147 for ; Wed, 25 Jan 2006 13:44:43 -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.0001E532@wildebeest.ease.lsoft.com>; Wed, 25 Jan 2006 13:45:41 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 97577696 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 25 Jan 2006 13:45:41 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 25 Jan 2006 13:45:41 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 25 Jan 2006 10:45:41 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.01,218,1136188800"; d="scan'208"; a="20434186:sNHT23895228" 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 k0PIj96j017584 for ; Wed, 25 Jan 2006 13:45:39 -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); Wed, 25 Jan 2006 13:45:14 -0500 Received: from [64.102.198.229] ([64.102.198.229]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 25 Jan 2006 13:45:14 -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: 25 Jan 2006 18:45:14.0430 (UTC) FILETIME=[7A8FB5E0:01C621DF] Message-ID: <43D7C73A.4030503@cisco.com> Date: Wed, 25 Jan 2006 13:45:14 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: I-D ACTION:draft-ietf-ospf-mt-05.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 revision clarifies the setting of the MT bit in the OSPF options. Previously it was unclear whether it should be only be set in hello packets or set in both hello and Database Description packets. Now it is clear that the option should be set in both. Also, section (5.1) covering compatibility concerns for demand circuits was included. If you have any comments or concerns, please register them on before February 8th, 2006. 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-05.txt > Pages : 23 > Date : 2006-1-13 > >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-05.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-05.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-05.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 Mon Jan 30 01:09:36 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3SEK-0002lR-47 for ospf-archive@megatron.ietf.org; Mon, 30 Jan 2006 01:09:36 -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 BAA29321 for ; Mon, 30 Jan 2006 01:08:01 -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.0001EE24@wildebeest.ease.lsoft.com>; Mon, 30 Jan 2006 1:08:58 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98012979 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 30 Jan 2006 01:08:58 -0500 Received: from 61.144.161.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 30 Jan 2006 00:58:53 -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 <0ITW00IVI6HPM0@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Mon, 30 Jan 2006 14:10:37 +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 <0ITW00DLT6HP5G@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Mon, 30 Jan 2006 14:10:37 +0800 (CST) Received: from anup ([10.18.4.206]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ITW002G96HHK2@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Mon, 30 Jan 2006 14:10:30 +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: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <001401c62562$38d25910$ce04120a@china.huawei.com> Date: Mon, 30 Jan 2006 11:28:40 +0530 Reply-To: Mailing List Sender: Mailing List From: anup Subject: Re: Selection of router id. And behaviour with IPv4 address removal. To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43D76890.4090500@netd.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT One good solution is to flush the router lsa and the network lsa that were originated with the old router-id. This ensures that the router with old router-id is no longer reachable. Anup -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of AJAY THAKUR Sent: Wednesday, January 25, 2006 5:31 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Selection of router id. And behaviour with IPv4 address removal. Aniket, This is related to implementation. Starting ospf process without router-Id is not allowed in cisco but it is not true for other implementations. But still I do have some more question on the same topic, (1) Configure ip address 1.1.1.1 Now this is ospf router id (2) Now configure ip address 2.2.2.2 Now still ospf uses 1.1.1.1 as router-Id. (3) Now uncofigure 1.1.1.1 ip address. Now if you reload the box ospf will not identify self-originated lsa and in this case these lsa will remain in database for MAX_AGE. What do you say about this behaviour? Thanks ajay Aniket D. wrote: > I had a question about the Router id and its relation with IPv4 addresses. > > The popular and common choice for Router Id is the highest loopback > IPv4 address or the IPv4 address of any other interface. > > Now if we continue to use the same scheme for the Router id for > OSPFv3, what happens is: > A) OSPFv3 process cannot be started until an IPv4 address is > configured on the box. > > B) Suppose: An IPv4 address is configured to start the OSPFv3 routing > process. Now if we remove all IPv4 addresses from all the interfaces > what is it that should happen. With a Cisco router, the OSPFv3 > adjacencies persist and the same router id continues to be used > despite that address no longer being configured on any interface on > that box. > - What this leads you to is that - now if you do a save running-config > and reload the box, the OSPFv3 adjacencies! wont come up, which were > already up before reloading the box. > > C) What is the right behaviour? Should OSPFv3 adjacencies go down when > all IPv4 addresses are removed? > > D) Should the Router Id be chosen with some other algorithm? > > Thanks and regards, > Aniket. > > ------------------------------------------------------------------------ > Yahoo! Photos > Ring in the New Year with Photo Calendars > . > Add photos, events, holidays, whatever. From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 30 01:14:58 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3SJU-0003HE-1l for ospf-archive@megatron.ietf.org; Mon, 30 Jan 2006 01:14: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 BAA29450 for ; Mon, 30 Jan 2006 01:13:12 -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.0001EE0F@wildebeest.ease.lsoft.com>; Mon, 30 Jan 2006 1:14:34 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98013513 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 30 Jan 2006 01:14:34 -0500 Received: from 207.17.137.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 30 Jan 2006 01:14:34 -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 k0U6EW1Z039372 for ; Sun, 29 Jan 2006 22:14:33 -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 k0U6EW563521 for ; Sun, 29 Jan 2006 22:14:32 -0800 (PST) (envelope-from dkatz@juniper.net) References: <001401c62562$38d25910$ce04120a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.746.2) Message-ID: <5A25213E-2382-4379-8AB9-29B782A3B3F5@juniper.net> Date: Sun, 29 Jan 2006 22:14:31 -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: <001401c62562$38d25910$ce04120a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit On Jan 29, 2006, at 9:58 PM, anup wrote: > One good solution is to flush the router lsa and the network lsa > that were > originated with the old router-id. This ensures that the router > with old > router-id is no longer reachable. This is unnecessary, since the old router ID will be unreachable anyhow (nobody will be adjacent to it, so the LSAs will never be considered in the SPF.) There's no harm in letting them rot for an hour, it's just memory. From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 30 01:15:07 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3SJT-0003HD-HT for ospf-archive@megatron.ietf.org; Mon, 30 Jan 2006 01:15: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 BAA29448 for ; Mon, 30 Jan 2006 01:13:12 -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.0001EE2F@wildebeest.ease.lsoft.com>; Mon, 30 Jan 2006 1:14:15 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98013494 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 30 Jan 2006 01:14:15 -0500 Received: from 203.196.196.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 30 Jan 2006 01:14:14 -0500 Received: from netd.com ([10.91.0.5]) (authenticated bits=0) by BLR-MAIL.NETD.COM (8.12.8/8.12.8) with ESMTP id k0U6JGAE005008; Mon, 30 Jan 2006 11:49:16 +0530 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <001401c62562$38d25910$ce04120a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NetD-India-MailScanner-Information: Please contact the NetD-India Sysadmin for more information X-NetD-India-MailScanner: Found to be clean X-MailScanner-From: tajay@netd.com Message-ID: <43DDADD7.5000901@netd.com> Date: Mon, 30 Jan 2006 11:40:31 +0530 Reply-To: Mailing List Sender: Mailing List From: AJAY THAKUR Subject: Re: Selection of router id. And behaviour with IPv4 address removal. To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <001401c62562$38d25910$ce04120a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Anup, In all implementation we do follow this .. we flush all the self-originated LSA whenever router-Id is changed. But my concern was that, "what if router does not get chance to flush the self-originated lsas (in case of reload) and after reload router-Id is no more same". This is still valid.. thanks ajay anup wrote: >One good solution is to flush the router lsa and the network lsa that were >originated with the old router-id. This ensures that the router with old >router-id is no longer reachable. > >Anup > > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of AJAY >THAKUR >Sent: Wednesday, January 25, 2006 5:31 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: Selection of router id. And behaviour with IPv4 address >removal. > >Aniket, >This is related to implementation. >Starting ospf process without router-Id is not allowed in cisco but >it is not true for other implementations. > >But still I do have some more question >on the same topic, > >(1) Configure ip address 1.1.1.1 > Now this is ospf router id > >(2) Now configure ip address 2.2.2.2 >Now still ospf uses 1.1.1.1 as router-Id. > >(3) Now uncofigure 1.1.1.1 ip address. > >Now if you reload the box ospf will not identify self-originated lsa >and in this case these lsa will remain in database for MAX_AGE. > >What do you say about this behaviour? >Thanks >ajay > > > >Aniket D. wrote: > > > >>I had a question about the Router id and its relation with IPv4 addresses. >> >>The popular and common choice for Router Id is the highest loopback >>IPv4 address or the IPv4 address of any other interface. >> >>Now if we continue to use the same scheme for the Router id for >>OSPFv3, what happens is: >>A) OSPFv3 process cannot be started until an IPv4 address is >>configured on the box. >> >>B) Suppose: An IPv4 address is configured to start the OSPFv3 routing >>process. Now if we remove all IPv4 addresses from all the interfaces >>what is it that should happen. With a Cisco router, the OSPFv3 >>adjacencies persist and the same router id continues to be used >>despite that address no longer being configured on any interface on >>that box. >>- What this leads you to is that - now if you do a save running-config >>and reload the box, the OSPFv3 adjacencies! wont come up, which were >>already up before reloading the box. >> >>C) What is the right behaviour? Should OSPFv3 adjacencies go down when >>all IPv4 addresses are removed? >> >>D) Should the Router Id be chosen with some other algorithm? >> >>Thanks and regards, >>Aniket. >> >>------------------------------------------------------------------------ >>Yahoo! Photos >>Ring in the New Year with Photo Calendars >> >> >> >/us.rd.yahoo.com/mail_us/taglines/photos/evt=38087/*http://pg.photos.yahoo.c >om/ph//page?.file=calendar_splash.html&.dir=>. > > >>Add photos, events, holidays, whatever. >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 30 01:24:39 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3SSs-0004YL-VE for ospf-archive@megatron.ietf.org; Mon, 30 Jan 2006 01:24: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 BAA29884 for ; Mon, 30 Jan 2006 01:23: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.0001EE26@wildebeest.ease.lsoft.com>; Mon, 30 Jan 2006 1:24:07 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98013929 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 30 Jan 2006 01:24:07 -0500 Received: from 61.144.161.53 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 30 Jan 2006 01:24:06 -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 <0ITW009M07KB2A@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Mon, 30 Jan 2006 14:33:48 +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 <0ITW003L77KBQC@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Mon, 30 Jan 2006 14:33:47 +0800 (CST) Received: from anup ([10.18.4.206]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ITW002DL7NPK2@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Mon, 30 Jan 2006 14:35:50 +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: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <003701c62565$c41f0650$ce04120a@china.huawei.com> Date: Mon, 30 Jan 2006 11:54:02 +0530 Reply-To: Mailing List Sender: Mailing List From: anup Subject: Re: Selection of router id. And behaviour with IPv4 address removal. To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <5A25213E-2382-4379-8AB9-29B782A3B3F5@juniper.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT The lsas originated by the router remain in the LSDB of other routers for an hour. During this time, the router with old router-id is virtually intact (still reachable) from other routers' perspective. So, it is necessary to flush all the lsas with old router-id. But, it is sufficient if only router and network lsas are flushed. In case of ospfv3, additional lsas might have to be flushed. Correct me if I'm wrong. Anup -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Dave Katz Sent: Monday, January 30, 2006 11:45 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Selection of router id. And behaviour with IPv4 address removal. On Jan 29, 2006, at 9:58 PM, anup wrote: > One good solution is to flush the router lsa and the network lsa > that were > originated with the old router-id. This ensures that the router > with old > router-id is no longer reachable. This is unnecessary, since the old router ID will be unreachable anyhow (nobody will be adjacent to it, so the LSAs will never be considered in the SPF.) There's no harm in letting them rot for an hour, it's just memory. From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 30 01:32:53 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3Sar-0005fb-Ii for ospf-archive@megatron.ietf.org; Mon, 30 Jan 2006 01:32:53 -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 BAA00353 for ; Mon, 30 Jan 2006 01:31: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 <6.0001EE19@wildebeest.ease.lsoft.com>; Mon, 30 Jan 2006 1:32:13 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98014150 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 30 Jan 2006 01:32:13 -0500 Received: from 207.17.137.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 30 Jan 2006 01:32:13 -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 k0U6WD1Z039458 for ; Sun, 29 Jan 2006 22:32:13 -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 k0U6WC565398 for ; Sun, 29 Jan 2006 22:32:13 -0800 (PST) (envelope-from dkatz@juniper.net) References: <003701c62565$c41f0650$ce04120a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.746.2) Message-ID: <0488B500-E096-42FD-B69B-DB52CD3C26CF@juniper.net> Date: Sun, 29 Jan 2006 22:32:13 -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: <003701c62565$c41f0650$ce04120a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit On Jan 29, 2006, at 10:24 PM, anup wrote: > The lsas originated by the router remain in the LSDB of other > routers for an > hour. During this time, the router with old router-id is virtually > intact > (still reachable) from other routers' perspective. So, it is > necessary to > flush all the lsas with old router-id. But, it is sufficient if > only router > and network lsas are flushed. No, they are not reachable. No other router will have the offending router ID in their router LSAs, so SPF will ignore them. There is no reason, other than tidiness, to try to flush them. Topologically the offending LSAs are partitioned from the rest of the network. From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 30 02:10:05 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3TAr-00025h-EN for ospf-archive@megatron.ietf.org; Mon, 30 Jan 2006 02:10: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 CAA02289 for ; Mon, 30 Jan 2006 02:08: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 <7.0001EE06@wildebeest.ease.lsoft.com>; Mon, 30 Jan 2006 2:09:33 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98014964 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 30 Jan 2006 02:09:33 -0500 Received: from 203.196.196.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 30 Jan 2006 01:59:33 -0500 Received: from netd.com ([10.91.0.55]) by BLR-MAIL.NETD.COM (8.12.8/8.12.8) with ESMTP id k0U74YAE009284 for ; Mon, 30 Jan 2006 12:34:35 +0530 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <003701c62565$c41f0650$ce04120a@china.huawei.com> <0488B500-E096-42FD-B69B-DB52CD3C26CF@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NetD-India-MailScanner-Information: Please contact the NetD-India Sysadmin for more information X-NetD-India-MailScanner: Found to be clean X-MailScanner-From: ddhar@netd.com Message-ID: <43DDBAB7.6070802@netd.com> Date: Mon, 30 Jan 2006 12:35:27 +0530 Reply-To: Mailing List Sender: Mailing List From: Divakar Dhar Subject: Re: Selection of router id. And behaviour with IPv4 address removal. To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <0488B500-E096-42FD-B69B-DB52CD3C26CF@juniper.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Dave Katz wrote: > On Jan 29, 2006, at 10:24 PM, anup wrote: > >> The lsas originated by the router remain in the LSDB of other >> routers for an >> hour. During this time, the router with old router-id is virtually >> intact >> (still reachable) from other routers' perspective. So, it is >> necessary to >> flush all the lsas with old router-id. But, it is sufficient if only >> router >> and network lsas are flushed. > > > No, they are not reachable. No other router will have the offending > router ID in their router LSAs, so SPF will ignore them. There is no > reason, other than tidiness, to try to flush them. Topologically the > offending LSAs are partitioned from the rest of the network. exactly...there is nothing wrong in keeping the LSA's for MAX_AGE. It is just a question of memory and no other router would be seeing us as fully adjacent router, so there is no issue with the sanity of routing tables. The router-id is taken from loopback interface addresses (even in cisco) even if some non-loopback interface IP address is more than the loopback interface address. It is because, it is expected that the loopback interface addresses wont change much often. -Divakar From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 30 03:33:30 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3UTa-000409-7U for ospf-archive@megatron.ietf.org; Mon, 30 Jan 2006 03:33: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 DAA05946 for ; Mon, 30 Jan 2006 03:31: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 <2.0001EE2C@wildebeest.ease.lsoft.com>; Mon, 30 Jan 2006 3:32:49 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98017807 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 30 Jan 2006 03:32:48 -0500 Received: from 207.69.195.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 30 Jan 2006 03:32:48 -0500 Received: from h-68-164-91-137.snvacaid.dynamic.covad.net ([68.164.91.137] helo=earthlink.net) by pop-sarus.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1F3USr-0004nJ-00 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 30 Jan 2006 03:32:48 -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> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43DDC0A5.CB67424F@earthlink.net> Date: Sun, 29 Jan 2006 23:30:45 -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 Dave, et al, Dave, aren't you simplfing the issue? Here are just a few quick items. Will the SPF or incremental SPF still run upon flushing them, even though the results will not change? I think so. Second, worse case (Murphy's Law) scenario. What happens if all routers within the area/AS reboot ` without MAXAGING their LSAs? We could theoreticly use 2x the amount of memory for out LSDB? Could this trigger some type of LSDB overload protection? If we had just originated new LSAs, should we wait until we can transmit the LSA with MAXAGE? their is a significant amount of work to flush. What is the cost of flushing vs not flushing? Additionally to the above, "dead LSAs in our LSDB", will also be aged (assume non DNA) and checksummed periodicly and still need to be aged out. Then why waste the memory? 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. 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. Just a few things to consider. Sorry about the MPLS concepts, I just had to use them. :) Mitchell Erblich ---------------------- Dave Katz wrote: > > On Jan 29, 2006, at 10:24 PM, anup wrote: > > > The lsas originated by the router remain in the LSDB of other > > routers for an > > hour. During this time, the router with old router-id is virtually > > intact > > (still reachable) from other routers' perspective. So, it is > > necessary to > > flush all the lsas with old router-id. But, it is sufficient if > > only router > > and network lsas are flushed. > > No, they are not reachable. No other router will have the offending > router ID in their router LSAs, so SPF will ignore them. There is no > reason, other than tidiness, to try to flush them. Topologically the > offending LSAs are partitioned from the rest of the network. From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 30 05:40:27 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3WSR-0004u2-Kd for ospf-archive@megatron.ietf.org; Mon, 30 Jan 2006 05:40: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 FAA12065 for ; Mon, 30 Jan 2006 05:38: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 <3.0001EE31@wildebeest.ease.lsoft.com>; Mon, 30 Jan 2006 5:39:46 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98022902 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 30 Jan 2006 05:39:45 -0500 Received: from 207.17.137.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 30 Jan 2006 05:39:45 -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 k0UAdi500712 for ; Mon, 30 Jan 2006 02:39:44 -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 k0UAdd593195 for ; Mon, 30 Jan 2006 02:39:39 -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> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.746.2) Message-ID: <7C48929A-88C1-458C-9E82-F8B82953779B@juniper.net> Date: Mon, 30 Jan 2006 02:39:39 -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: <43DDC0A5.CB67424F@earthlink.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit 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 Jan 30 06:36:44 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3XKu-0005hc-L4 for ospf-archive@megatron.ietf.org; Mon, 30 Jan 2006 06:36: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 GAA15604 for ; Mon, 30 Jan 2006 06:35:09 -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.0001EF44@wildebeest.ease.lsoft.com>; Mon, 30 Jan 2006 6:36:13 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98039444 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 30 Jan 2006 06:36:13 -0500 Received: from 203.199.83.245 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 30 Jan 2006 06:35:42 -0500 Received: (qmail 18592 invoked by uid 510); 30 Jan 2006 11:35:17 -0000 Received: from unknown (203.126.136.220) by rediffmail.com via HTTP; 30 jan 2006 11:35:17 -0000 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="Next_1138620917---0-203.199.83.245-18586" Message-ID: <20060130113517.18591.qmail@webmail33.rediffmail.com> Date: Mon, 30 Jan 2006 11:35:17 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: draft-ietf-ospf-mib-update-08.txt 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_1138620917---0-203.199.83.245-18586 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi,=0AFew queries on "draft-ietf-ospf-mib-update-08.txt"=0A=0A1) MAX-ACCESS= for Table index is mentioned as "read-only"=0A=0A Shouldn't it be: "not-= accessible"=0A=0AE.g: =0A ospfHostIpAddress OBJECT-TYPE =0A SYNT= AX IpAddress =0A MAX-ACCESS read-only =0A STATUS = current =0A DESCRIPTION =0A "The IP Address of the H= ost." =0A REFERENCE =0A "OSPF Version 2, Appendix C.7 Ho= st route parameters" =0A ::=3D { ospfHostEntry 1 }=0A=0A2) OSPF Tra= p=0A=0AospfVirtIfStateChange NOTIFICATION-TYPE =0A OBJECTS { ospfRo= uterId, -- The originator of the trap =0A ospfVirtIfAreaId, =0A = ospfVirtIfNeighbor, =0A ospfVirtIfState -- The new s= tate =0A } =0A=0AObject "ospfVirtIfState" is a column in ospfVir= tIfTable =0AAnd "ospfVirtIfAreaId" , "ospfVirtIfNeighbor" index in same tab= le.=0A=0AInofrmation about "ospfVirtIfState" implies knowledge of "ospfVirt= IfAreaId" , "ospfVirtIfNeighbor".=0A=0AShould than these ("ospfVirtIfAreaId= " , "ospfVirtIfNeighbor") be part of Trap Object.=0A=0AThanks=0AVivek=0A=0A= =0A --Next_1138620917---0-203.199.83.245-18586 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0AHi,
=0AFew queries on "draft-ietf-ospf-mib-update-08.txt"= ;
=0A
=0A1) MAX-ACCESS for Table index is mentioned as "read-onl= y"
=0A
=0A  Shouldn't it be: "not-accessible"=0A
=0AE.g:
=0A    ospfHostIpAddress OBJECT-TYPE
=0A&= nbsp;       SYNTAX      IpAddress
=0A&n= bsp;       MAX-ACCESS  read-only
=0A   =     STATUS      current
=0A    &n= bsp;   DESCRIPTION
=0A            &= quot;The IP Address of the Host."
=0A        = REFERENCE
=0A            "OSPF Versi= on 2, Appendix C.7 Host route parameters"
=0A      =   ::=3D { ospfHostEntry 1 }
=0A
=0A2) OSPF Trap
=0A
=0Aos= pfVirtIfStateChange NOTIFICATION-TYPE
=0A        O= BJECTS { ospfRouterId, -- The originator of the trap
=0A    &= nbsp;       ospfVirtIfAreaId,
=0A      &n= bsp;     ospfVirtIfNeighbor,
=0A        &= nbsp;   ospfVirtIfState  -- The new state
=0A    &n= bsp;       }
=0A
=0AObject "ospfVirtIfState"= ; is a column in ospfVirtIfTable
=0AAnd "ospfVirtIfAreaId" , = "ospfVirtIfNeighbor" index in same table.
=0A
=0AInofrmatio= n about "ospfVirtIfState" implies knowledge of "ospfVirtIfAr= eaId" , "ospfVirtIfNeighbor".
=0A
=0AShould than these= ("ospfVirtIfAreaId" , "ospfVirtIfNeighbor") be part of= Trap Object.
=0A
=0AThanks
=0AVivek
=0A
=0A
=0A=0A

= =0A

=0A=0A --Next_1138620917---0-203.199.83.245-18586-- From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 30 11:00:43 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3bSN-0001pR-QZ for ospf-archive@megatron.ietf.org; Mon, 30 Jan 2006 11:00:43 -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 KAA03041 for ; Mon, 30 Jan 2006 10:59:09 -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.0001EFBD@wildebeest.ease.lsoft.com>; Mon, 30 Jan 2006 11:00:08 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98056132 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 30 Jan 2006 11:00:08 -0500 Received: from 132.151.6.50 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 30 Jan 2006 10:50:08 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F3bI1-0002WO-Uj; Mon, 30 Jan 2006 10:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-ID: Date: Mon, 30 Jan 2006 10:50:01 -0500 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-mib-update-09.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 : OSPF Version 2 Management Information Base Author(s) : S. Giacalone, et al. Filename : draft-ietf-ospf-mib-update-09.txt Pages : 109 Date : 2006-1-30 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing version 2 of the Open Shortest Path First Routing Protocol. Version 2 of the OSPF protocol is specific to the IPv4 address family. Version 3 of the OSPF protocol is specific to the IPv6 address family. This memo is intended to update and obsolete RFC 1850, however, it is designed to be backwards compatible. The functional differences between this memo and RFC 1850 are explained in section 12. Please send comments to ospf@peach.ease.lsoft.com. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-mib-update-09.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-mib-update-09.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-mib-update-09.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-1-30104219.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-mib-update-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-mib-update-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-30104219.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 30 14:20:19 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3eZX-0001RS-DC for ospf-archive@megatron.ietf.org; Mon, 30 Jan 2006 14:20: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 OAA19027 for ; Mon, 30 Jan 2006 14:18:43 -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.0001F05D@wildebeest.ease.lsoft.com>; Mon, 30 Jan 2006 14:19:47 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98072870 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 30 Jan 2006 14:19:47 -0500 Received: from 207.69.195.68 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 30 Jan 2006 14:19:47 -0500 Received: from h-68-164-91-137.snvacaid.dynamic.covad.net ([68.164.91.137] helo=earthlink.net) by pop-cowbird.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1F3eZ0-0004Pe-00 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 30 Jan 2006 14:19: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: <003701c62565$c41f0650$ce04120a@china.huawei.com> <0488B500-E096-42FD-B69B-DB52CD3C26CF@juniper.net> <43DDBAB7.6070802@netd.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43DE6A95.50F8EC1F@earthlink.net> Date: Mon, 30 Jan 2006 11:35:49 -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, A much more common case is just a router leaving the area. In the BMA environment, after the dead router interval has passed. Their is no MUST requirement that a router clean up its LSAs before leaving. Does anyone think that a Network LSA would then be re-originated showing that the old router is no longer reachable? Mitchell Erblich ------------------- Divakar Dhar wrote: > > Dave Katz wrote: > > > On Jan 29, 2006, at 10:24 PM, anup wrote: > > > >> The lsas originated by the router remain in the LSDB of other > >> routers for an > >> hour. During this time, the router with old router-id is virtually > >> intact > >> (still reachable) from other routers' perspective. So, it is > >> necessary to > >> flush all the lsas with old router-id. But, it is sufficient if only > >> router > >> and network lsas are flushed. > > > > > > No, they are not reachable. No other router will have the offending > > router ID in their router LSAs, so SPF will ignore them. There is no > > reason, other than tidiness, to try to flush them. Topologically the > > offending LSAs are partitioned from the rest of the network. > > exactly...there is nothing wrong in keeping the LSA's for MAX_AGE. It > is just a question of memory and no other router would be seeing us as > fully adjacent router, so there is no issue with the sanity of routing > tables. > The router-id is taken from loopback interface addresses (even in cisco) > even if some non-loopback interface IP address is more than the loopback > interface address. It is because, it is expected that the loopback > interface addresses wont change much often. > -Divakar From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 30 14:25:55 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3eew-0002n0-6h for ospf-archive@megatron.ietf.org; Mon, 30 Jan 2006 14:25: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 OAA19671 for ; Mon, 30 Jan 2006 14:24: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 <12.0001F050@wildebeest.ease.lsoft.com>; Mon, 30 Jan 2006 14:25:15 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98073237 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 30 Jan 2006 14:25:15 -0500 Received: from 143.209.238.162 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 30 Jan 2006 14:25:15 -0500 Received: from mvrelay.mv.usa.alcatel.com (mvrelay.mv.usa.alcatel.com [128.251.10.15]) by audl953.usa.alcatel.com (ALCANET) with ESMTP id k0UJPEEq024939; Mon, 30 Jan 2006 13:25:14 -0600 Received: from dgoodspeedpc (localhost [127.0.0.1]) by mvrelay.mv.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id k0UJPWvs022300; Mon, 30 Jan 2006 11:25:33 -0800 (PST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01C6258F.D689BD60" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Thread-index: AcYlkWV/Y4Ohc0uNRHOoTYK8tMJBLAAQLVMA X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 Message-ID: <200601301925.k0UJPWvs022300@mvrelay.mv.usa.alcatel.com> Date: Mon, 30 Jan 2006 11:25:12 -0800 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Organization: Alcatel Subject: Re: draft-ietf-ospf-mib-update-08.txt Comments: To: Vivek Dubey To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20060130113517.18591.qmail@webmail33.rediffmail.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_0024_01C6258F.D689BD60 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Vivek, On #1 yes it "should" be but this is a grand-fathered MIB originally created before that rule became mandatory so it would remain until the MIB (or the MIB table) is deprecated and replaced. On #2, once again, this is how it existed in the original MIB. If this MIB were to be written from scratch today, yes those extra OIDs would be deemed redundant. But once again since this was in the original MIB definition, the NOTIFICATION would need to be replaced for this to occur (can only add to NOTIFICATIONs, not delete or modify). -don _____ From: owner-ospf@PEACH.EASE.LSOFT.COM [mailto:owner-ospf@PEACH.EASE.LSOFT.COM] On Behalf Of Vivek Dubey Sent: Monday, January 30, 2006 3:35 AM To: Mailing List Subject: draft-ietf-ospf-mib-update-08.txt Hi, Few queries on "draft-ietf-ospf-mib-update-08.txt" 1) MAX-ACCESS for Table index is mentioned as "read-only" Shouldn't it be: "not-accessible" E.g: ospfHostIpAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP Address of the Host." REFERENCE "OSPF Version 2, Appendix C.7 Host route parameters" ::= { ospfHostEntry 1 } 2) OSPF Trap ospfVirtIfStateChange NOTIFICATION-TYPE OBJECTS { ospfRouterId, -- The originator of the trap ospfVirtIfAreaId, ospfVirtIfNeighbor, ospfVirtIfState -- The new state } Object "ospfVirtIfState" is a column in ospfVirtIfTable And "ospfVirtIfAreaId" , "ospfVirtIfNeighbor" index in same table. Inofrmation about "ospfVirtIfState" implies knowledge of "ospfVirtIfAreaId" , "ospfVirtIfNeighbor". Should than these ("ospfVirtIfAreaId" , "ospfVirtIfNeighbor") be part of Trap Object. Thanks Vivek ------=_NextPart_000_0024_01C6258F.D689BD60 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Vivek,
 
On #1 yes it "should" be but this is a = grand-fathered MIB=20 originally created before that
rule became mandatory so it would remain until = the MIB (or=20 the MIB table) is deprecated
and replaced.
 
On #2, once again, this is how it existed in = the original=20 MIB.  If this MIB were to be written
from scratch today, yes those extra OIDs would = be deemed=20 redundant.  But once again
since this was in the original MIB definition, = the=20 NOTIFICATION would need to be replaced
for this to occur (can only add to = NOTIFICATIONs, not=20 delete or modify).
 
-don

From: = owner-ospf@PEACH.EASE.LSOFT.COM=20 [mailto:owner-ospf@PEACH.EASE.LSOFT.COM] On Behalf Of Vivek=20 Dubey
Sent: Monday, January 30, 2006 3:35 AM
To: = Mailing=20 List
Subject: = draft-ietf-ospf-mib-update-08.txt

Hi,
Few queries on "draft-ietf-ospf-mib-update-08.txt"

1)=20 MAX-ACCESS for Table index is mentioned as "read-only"

  = Shouldn't=20 it be: "not-accessible"

E.g:
    ospfHostIpAddress=20 OBJECT-TYPE
        SYNTAX      = IpAddress=20
        MAX-ACCESS  read-only
  =  =20     STATUS      current
    =    =20 DESCRIPTION
            "The IP = Address of the=20 Host."
        REFERENCE
    =    =20     "OSPF Version 2, Appendix C.7 Host route parameters" =
 =20       ::=3D { ospfHostEntry 1 }

2) OSPF=20 Trap

ospfVirtIfStateChange NOTIFICATION-TYPE
    =  =20   OBJECTS { ospfRouterId, -- The originator of the trap
  =  =20         ospfVirtIfAreaId,
      =  =20     ospfVirtIfNeighbor,
          =  =20 ospfVirtIfState  -- The new state
        =  =20   }

Object "ospfVirtIfState" is a column in ospfVirtIfTable =
And=20 "ospfVirtIfAreaId" , "ospfVirtIfNeighbor" index in same=20 table.

Inofrmation about "ospfVirtIfState" implies knowledge of=20 "ospfVirtIfAreaId" , "ospfVirtIfNeighbor".

Should than these=20 ("ospfVirtIfAreaId" , "ospfVirtIfNeighbor") be part of Trap=20 Object.

Thanks
Vivek




------=_NextPart_000_0024_01C6258F.D689BD60-- From owner-ospf@PEACH.EASE.LSOFT.COM Mon Jan 30 16:00:49 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3g8n-0007Lv-CV for ospf-archive@megatron.ietf.org; Mon, 30 Jan 2006 16:00: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 PAA28321 for ; Mon, 30 Jan 2006 15:59:04 -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.0001F0C8@wildebeest.ease.lsoft.com>; Mon, 30 Jan 2006 16:00:03 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98078200 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 30 Jan 2006 16:00:02 -0500 Received: from 132.151.6.50 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 30 Jan 2006 15:50:02 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F3fyL-0007Xo-UV; Mon, 30 Jan 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-ID: Date: Mon, 30 Jan 2006 15:50:01 -0500 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-ospfv3-update-07.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 : OSPF for IPv6 Author(s) : D. Ferguson, et al. Filename : draft-ietf-ospf-ospfv3-update-07.txt Pages : 97 Date : 2006-1-30 This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, DR election, area support, SPF calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. Changes between OSPF for IPv4 and this document include the following. Addressing semantics have been removed from OSPF packets and the basic LSAs. New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload. Even with larger IPv6 packet, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible. All of OSPF for IPv4's optional capabilities, including demand circuit support, NSSA areas, and the multicast extensions to OSPF (MOSPF) are also supported in OSPF for IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-update-07.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-ospfv3-update-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-ospfv3-update-07.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-1-30110136.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-ospfv3-update-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-ospfv3-update-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-30110136.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jan 31 14:05:50 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F40p4-0005xx-7S for ospf-archive@megatron.ietf.org; Tue, 31 Jan 2006 14:05: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 OAA19780 for ; Tue, 31 Jan 2006 14:04:11 -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.0001F478@wildebeest.ease.lsoft.com>; Tue, 31 Jan 2006 14:04:51 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98161542 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 31 Jan 2006 14:04:51 -0500 Received: from 209.119.1.41 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 31 Jan 2006 14:04: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 <0.000A54C6@LIME.ease.lsoft.com>; Tue, 31 Jan 2006 14:03:51 -0500 Message-ID: Date: Tue, 31 Jan 2006 14:04:47 -0500 Reply-To: Mailing List Sender: Mailing List From: SUBSCRIBE OSPF vishnuvardhan B Subject: Re: Mapping between routerlsa and intra-area prefix lsa Comments: To: Acee Lindem To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Hi All, Thanks for the Responses,Still have a query on SPF calculation on broadcast medium. On broadcast medium how should SPF add the prefixes to the local RIB. Should i use type-9 LSA(reftype-network), here i have a problem, how about the next hop calculation. So canany one give me a detailed approach of how should SPF calculate the prefixes on broadcast medium. Regards, Vishnu From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jan 31 18:50:44 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F45Gm-0006CK-Md for ospf-archive@megatron.ietf.org; Tue, 31 Jan 2006 18:50: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 SAA12457 for ; Tue, 31 Jan 2006 18:49:00 -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.0001F509@wildebeest.ease.lsoft.com>; Tue, 31 Jan 2006 18:50:03 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98180363 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 31 Jan 2006 18:50:03 -0500 Received: from 207.69.195.63 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 31 Jan 2006 18:50:03 -0500 Received: from h-68-164-91-137.snvacaid.dynamic.covad.net ([68.164.91.137] helo=earthlink.net) by pop-satin.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1F45G6-0001F3-00 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 31 Jan 2006 18:50: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: <43DFFB6D.66131696@earthlink.net> Date: Tue, 31 Jan 2006 16:06:05 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: 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 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. 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 is no longer a requirement for neighbor acceptance in many implementations. Mitchell Erblich From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jan 31 18:58:13 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F45O1-0000X7-Pv for ospf-archive@megatron.ietf.org; Tue, 31 Jan 2006 18:58: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 SAA12822 for ; Tue, 31 Jan 2006 18:56:29 -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.0001F51F@wildebeest.ease.lsoft.com>; Tue, 31 Jan 2006 18:57:34 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98181648 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 31 Jan 2006 18:57:34 -0500 Received: from 207.69.195.63 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 31 Jan 2006 18:57:30 -0500 Received: from h-68-164-91-137.snvacaid.dynamic.covad.net ([68.164.91.137] helo=earthlink.net) by pop-satin.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1F45NJ-0002ym-00 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 31 Jan 2006 18:57:29 -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> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43DFFD2A.6D8E8428@earthlink.net> Date: Tue, 31 Jan 2006 16:13:30 -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 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. > > 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. > > Mitchell Erblich From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jan 31 19:42:31 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F464t-0006UY-6u for ospf-archive@megatron.ietf.org; Tue, 31 Jan 2006 19:42: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 TAA15583 for ; Tue, 31 Jan 2006 19:40: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 <1.0001F535@wildebeest.ease.lsoft.com>; Tue, 31 Jan 2006 19:41:55 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98183620 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 31 Jan 2006 19:41:55 -0500 Received: from 207.17.137.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 31 Jan 2006 19:41:55 -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 k110fs533079 for ; Tue, 31 Jan 2006 16:41:54 -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 k110fh563712 for ; Tue, 31 Jan 2006 16:41:43 -0800 (PST) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v746.2) References: <43DFFB6D.66131696@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: <4530A3B7-EB4E-494F-846C-EF7EF236413F@juniper.net> Date: Tue, 31 Jan 2006 16:41:41 -0800 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: draft-ietf-ospf-ospfv3-update-07.txt : Constants To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43DFFB6D.66131696@earthlink.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit I'm assuming that in this "fast hello" mode, routers send a hello interval of 0 and a dead interval of 1? Strictly speaking, there's nothing to ignore, since the only test is that everybody is saying "0". In any case, this draft doesn't seem to be the place to talk about changes to OSPFv2, which I believe is what you're really referring to. Changes to the base spec (that don't conflict with v3) should be in a separate draft. --Dave On Jan 31, 2006, at 4:06 PM, 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. > > 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 is no > longer a requirement for neighbor acceptance in many > implementations. > > > Mitchell Erblich > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jan 31 19:53:49 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F46Fp-0001bQ-A4 for ospf-archive@megatron.ietf.org; Tue, 31 Jan 2006 19:53: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 TAA16465 for ; Tue, 31 Jan 2006 19:52: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 <1.0001F53F@wildebeest.ease.lsoft.com>; Tue, 31 Jan 2006 19:53:10 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98184232 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 31 Jan 2006 19:53:10 -0500 Received: from 207.69.195.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 31 Jan 2006 19:53:10 -0500 Received: from h-68-164-91-137.snvacaid.dynamic.covad.net ([68.164.91.137] helo=earthlink.net) by pop-knobcone.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1F46F7-0003NH-00; Tue, 31 Jan 2006 19:53:05 -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: <43E00A1C.70669007@earthlink.net> Date: Tue, 31 Jan 2006 17:08:44 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: draft-ietf-ospf-ospfv3-update-07.txt : instance Comments: To: jmoy@sycamorenet.com, acee@cisco.com, dennis@juniper.net To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit 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? 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. 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 Tue Jan 31 20:28:54 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F46nk-00012s-Aj for ospf-archive@megatron.ietf.org; Tue, 31 Jan 2006 20:28: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 UAA21255 for ; Tue, 31 Jan 2006 20:27:15 -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.0001F545@wildebeest.ease.lsoft.com>; Tue, 31 Jan 2006 20:28:20 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98186090 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 31 Jan 2006 20:28:20 -0500 Received: from 207.69.195.66 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 31 Jan 2006 20:28:20 -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 1F46nD-0005mn-00 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 31 Jan 2006 20:28:19 -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> <4530A3B7-EB4E-494F-846C-EF7EF236413F@juniper.net> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43E01243.3C6438F1@earthlink.net> Date: Tue, 31 Jan 2006 17:43:31 -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 Dave Katz, First, I did do an almost immediate followup to keep just dead interval as a valid match in this suggestion. That is all that is really needed and still behave as expected. Yes... But the 0 value is ignored and doesn't follow the expected original usage of what we should do if we see a 0. AND Because we later specify in section C.3 Router interface parameters "HelloInterval The length of time, in seconds, between Hello Packets that the router sends on the interface. This value is advertised in the router's Hello Packets. It MUST be the same for all routers attached to a common link. The smaller the HelloInterval, the faster topological changes will be detected. However, more OSPF routing protocol traffic will ensue. Sample value for a X.25 PDN: 30 seconds. Sample value for a local area network (LAN): 10 seconds." And in the preceeding section and throughout this document, implementations are diverging so far from RFCs, that some of these docs are becoming mythical.. Would the avg router BREAK if they see a 0 for HelloInterval and not configured via a CLI to see it. If they would, these RFCs are supposed to attempt to achieve compatiblity. This suggestion is to attempt to still achieve that goal in this section. LASTLY, yes, I do believe that many v3 implimentations also support some notion of "fast hellos". Mitchell Erblich --------------------- Dave Katz wrote: > > I'm assuming that in this "fast hello" mode, routers send a hello > interval of 0 and a dead interval of 1? Strictly speaking, there's > nothing to ignore, since the only test is that everybody is saying "0". > > In any case, this draft doesn't seem to be the place to talk about > changes to OSPFv2, which I believe is what you're really referring > to. Changes to the base spec (that don't conflict with v3) should be > in a separate draft. > > --Dave > > On Jan 31, 2006, at 4:06 PM, 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. > > > > 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 is no > > longer a requirement for neighbor acceptance in many > > implementations. > > > > > > Mitchell Erblich > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Jan 31 20:49:18 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F477W-0007Bx-RN for ospf-archive@megatron.ietf.org; Tue, 31 Jan 2006 20:49: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 UAA24701 for ; Tue, 31 Jan 2006 20:47: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 <7.0001F538@wildebeest.ease.lsoft.com>; Tue, 31 Jan 2006 20:48:32 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98186774 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 31 Jan 2006 20:48:32 -0500 Received: from 171.71.176.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 31 Jan 2006 20:48:32 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 31 Jan 2006 17:48:32 -0800 X-IronPort-AV: i="4.01,242,1136188800"; d="scan'208"; a="398993521:sNHT31148828" 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 k111mVWF001958 for ; Tue, 31 Jan 2006 17:48:31 -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); Tue, 31 Jan 2006 20:48:31 -0500 Received: from [10.82.240.156] ([10.82.240.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 Jan 2006 20:48:30 -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> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Feb 2006 01:48:31.0039 (UTC) FILETIME=[9A9934F0:01C626D1] Message-ID: <43E0136E.6090706@cisco.com> Date: Tue, 31 Jan 2006 20:48:30 -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: <43DFFD2A.6D8E8428@earthlink.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit 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 Tue Jan 31 21:04:06 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F47Lq-0003UK-9P for ospf-archive@megatron.ietf.org; Tue, 31 Jan 2006 21:04: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 VAA25993 for ; Tue, 31 Jan 2006 21:02:21 -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.0001F54A@wildebeest.ease.lsoft.com>; Tue, 31 Jan 2006 21:03:26 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98187500 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 31 Jan 2006 21:03:26 -0500 Received: from 171.71.176.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 31 Jan 2006 21:03:26 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 31 Jan 2006 18:03:26 -0800 X-IronPort-AV: i="4.01,242,1136188800"; d="scan'208"; a="399003346:sNHT32529700" 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 k1123PKV001150 for ; Tue, 31 Jan 2006 18:03:25 -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); Tue, 31 Jan 2006 21:03:25 -0500 Received: from [10.82.240.156] ([10.82.240.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 Jan 2006 21:03:25 -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> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Feb 2006 02:03:25.0086 (UTC) FILETIME=[AF7DF3E0:01C626D3] Message-ID: <43E016EC.10401@cisco.com> Date: Tue, 31 Jan 2006 21:03:24 -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: <43E00A1C.70669007@earthlink.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit 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 Tue Jan 31 23:37:06 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F49jr-0001ry-OG for ospf-archive@megatron.ietf.org; Tue, 31 Jan 2006 23:37: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 XAA06051 for ; Tue, 31 Jan 2006 23:35: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 <2.0001F587@wildebeest.ease.lsoft.com>; Tue, 31 Jan 2006 23:36:23 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 98196835 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 31 Jan 2006 23:36:22 -0500 Received: from 207.69.195.68 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 31 Jan 2006 23:31:33 -0500 Received: from h-68-164-91-137.snvacaid.dynamic.covad.net ([68.164.91.137] helo=earthlink.net) by pop-cowbird.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1F49eW-0003FR-00 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 31 Jan 2006 23:31:32 -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: <43E00A1C.70669007@earthlink.net> <43E016EC.10401@cisco.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43E03BA3.FC683596@earthlink.net> Date: Tue, 31 Jan 2006 20:40:03 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: draft-ietf-ospf-ospfv3-update-07.txt : instance To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit 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. 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. 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 > > > > > >