From owner-ospf@DISCUSS.MICROSOFT.COM Sat Jun 1 08:25:49 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22069 for ; Sat, 1 Jun 2002 08:25:49 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0062FFD8@cherry.ease.lsoft.com>; Sat, 1 Jun 2002 8:26:10 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 883846 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 1 Jun 2002 08:26:09 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sat, 1 Jun 2002 08:26:09 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Sat, 1 Jun 2002 08:21:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Sat, 1 Jun 2002 08:25:39 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Dynamic Priority setting for DR election To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Mitchell, I do not know your exact intent and what you want to achieve here, but this method would not be backward compatible with the existing methods. For a method to be useful, its extremely important it is able to interoperate with existing methods. I dont know of anything like this having been proposed in any draft in the recent past. However I guess there are some implementations in ISIS which flip up the priority of the DIS(DR) so as to prevent frequent changes of the DIS(as has been pointed out earlier in the list). I do not know of any dynamic selection of priority though. Thanks, Vishwas -----Original Message----- From: Erblichs [mailto:erblichs@EARTHLINK.NET] Sent: Saturday, June 01, 2002 4:31 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Dynamic Priority setting for DR election Hi Group, Has anyone heard of a router's priority selection based based on incoming values of the hello packet's priority field? Would their be an experimental draft during the past years that explictly or implicitly state this type of feature? Basicly 0) Assuming that a DR and BDR were not already elected. 1) delaying hello xmits during bootup for a period not to exceed or equal waittime, 2) Identifing a max of the priorities per DR capable interface, 3) Then transmitting hello packets with a higher priority than the calculated max and dynamically setting that value.. This would make it the DR, unless another router's priority was set to the max.. Yes, I believe this would be a non-standard functionality, and should require the formal setting of a CLI command to enable this type of feature. And yes, their could be issues with two or more routers configured this way. Mitchell Erblich From owner-ospf@DISCUSS.MICROSOFT.COM Sat Jun 1 15:03:09 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26421 for ; Sat, 1 Jun 2002 15:03:08 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00630319@cherry.ease.lsoft.com>; Sat, 1 Jun 2002 15:03:35 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 884347 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 1 Jun 2002 15:03:35 -0400 Received: from 144.254.15.119 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sat, 1 Jun 2002 15:03:34 -0400 Received: from asmhome (asmirnov-isdn-home.cisco.com [10.49.1.50]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with SMTP id g51J3XW02773 for ; Sat, 1 Jun 2002 21:03:33 +0200 (CEST) References: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <001501c2099f$12789e60$3201310a@asmhome> Date: Sat, 1 Jun 2002 21:03:51 +0200 Reply-To: Mailing List Sender: Mailing List From: Anton Smirnov Organization: Cisco Systems Subject: Re: Dynamic Priority setting for DR election To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Mitchell, I don't think DR's responsibilities have big impact on resources of , especially if any technique to optimize flooding over parallel links has been implemented. Thus dynamic priority change looks like bringing problems rather than solving them... Anton ----- Original Message ----- From: "Manral, Vishwas" To: Sent: Saturday, June 01, 2002 2:25 PM Subject: Re: [OSPF] Dynamic Priority setting for DR election > Hi Mitchell, > > I do not know your exact intent and what you want to achieve here, but this > method would not be backward compatible with the existing methods. For a > method to be useful, its extremely important it is able to interoperate with > existing methods. > > I dont know of anything like this having been proposed in any draft in the > recent past. > > However I guess there are some implementations in ISIS which flip up the > priority of the DIS(DR) so as to prevent frequent changes of the DIS(as has > been pointed out earlier in the list). I do not know of any dynamic > selection of priority though. > > Thanks, > Vishwas > > > -----Original Message----- > From: Erblichs [mailto:erblichs@EARTHLINK.NET] > Sent: Saturday, June 01, 2002 4:31 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Dynamic Priority setting for DR election > > > Hi Group, > > Has anyone heard of a router's priority selection based > based on incoming values of the hello packet's priority > field? > > Would their be an experimental draft during the past > years that explictly or implicitly state this type > of feature? > > Basicly > > 0) Assuming that a DR and BDR were not already > elected. > > 1) delaying hello xmits during bootup for > a period not to exceed or equal waittime, > > 2) Identifing a max of the priorities per > DR capable interface, > > 3) Then transmitting hello packets with a higher > priority than the calculated max and dynamically > setting that value.. > > This would make it the DR, unless another > router's priority was set to the max.. > > Yes, I believe this would be a non-standard functionality, > and should require the formal setting of a CLI command > to enable this type of feature. > > And yes, their could be issues with two or more > routers configured this way. > > Mitchell Erblich > From owner-ospf@DISCUSS.MICROSOFT.COM Sat Jun 1 15:42:33 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26657 for ; Sat, 1 Jun 2002 15:42:33 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.006303F5@cherry.ease.lsoft.com>; Sat, 1 Jun 2002 15:42:58 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 884395 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 1 Jun 2002 15:42:58 -0400 Received: from 207.217.120.232 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sat, 1 Jun 2002 15:42:58 -0400 Received: from 209-239-210-72.oak.jps.net ([209.239.210.72] helo=earthlink.net) by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17EEm8-00059z-00 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 01 Jun 2002 12:42:57 -0700 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <001501c2099f$12789e60$3201310a@asmhome> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3CF925E3.409A143C@earthlink.net> Date: Sat, 1 Jun 2002 12:52:03 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Dynamic Priority setting for DR election To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Anton, This was a request to investigate this functionality. My assumption is that if the router architecture supports MANY DR capable interfaces, then they would like to have different routers willing to over-ride other configured priority values.. So, they don't have to set a fixed priority value per interface and not be sure that the router will be the DR. They don't have to set the highest value. After the router is elected DR. They only have to execute a CLI to determine what is the current priority that the router selected per interface. Simply, this is a administration issue. And, if I understand your resource statement correctly, then I would have to disagree. A one item example.. After a DR is elected, this router would then have to sychronize its database with all DRothers.. The time to do this is mostly dependent on the number of capable simultaneous adj formations without overload.. And of course, their is a overload draft that suggests to limit this simultaneous adjs to a known acceptable value. This value is dependent on the capabilities of the router.. Mitchell Erblich PS: And if anyone was wondering, the hello interval and the ROUTERDEADINTERVAL could also be read from recieved hellos. Again, this could lead to less required configuration to establish 2-ways. ======================== Anton Smirnov wrote: > > Mitchell, > I don't think DR's responsibilities have big impact on resources of > , especially if any technique to optimize flooding over parallel > links has been implemented. Thus dynamic priority change looks like bringing > problems rather than solving them... > > Anton > > ----- Original Message ----- > From: "Manral, Vishwas" > To: > Sent: Saturday, June 01, 2002 2:25 PM > Subject: Re: [OSPF] Dynamic Priority setting for DR election > > > Hi Mitchell, > > > > I do not know your exact intent and what you want to achieve here, but > this > > method would not be backward compatible with the existing methods. For a > > method to be useful, its extremely important it is able to interoperate > with > > existing methods. > > > > I dont know of anything like this having been proposed in any draft in the > > recent past. > > > > However I guess there are some implementations in ISIS which flip up the > > priority of the DIS(DR) so as to prevent frequent changes of the DIS(as > has > > been pointed out earlier in the list). I do not know of any dynamic > > selection of priority though. > > > > Thanks, > > Vishwas > > > > > > -----Original Message----- > > From: Erblichs [mailto:erblichs@EARTHLINK.NET] > > Sent: Saturday, June 01, 2002 4:31 AM > > To: OSPF@DISCUSS.MICROSOFT.COM > > Subject: Dynamic Priority setting for DR election > > > > > > Hi Group, > > > > Has anyone heard of a router's priority selection based > > based on incoming values of the hello packet's priority > > field? > > > > Would their be an experimental draft during the past > > years that explictly or implicitly state this type > > of feature? > > > > Basicly > > > > 0) Assuming that a DR and BDR were not already > > elected. > > > > 1) delaying hello xmits during bootup for > > a period not to exceed or equal waittime, > > > > 2) Identifing a max of the priorities per > > DR capable interface, > > > > 3) Then transmitting hello packets with a higher > > priority than the calculated max and dynamically > > setting that value.. > > > > This would make it the DR, unless another > > router's priority was set to the max.. > > > > Yes, I believe this would be a non-standard functionality, > > and should require the formal setting of a CLI command > > to enable this type of feature. > > > > And yes, their could be issues with two or more > > routers configured this way. > > > > Mitchell Erblich > > From owner-ospf@DISCUSS.MICROSOFT.COM Sat Jun 1 17:43:12 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27913 for ; Sat, 1 Jun 2002 17:43:12 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00630752@cherry.ease.lsoft.com>; Sat, 1 Jun 2002 17:43:38 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 874708 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 1 Jun 2002 17:43:38 -0400 Received: from 144.254.15.119 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sat, 1 Jun 2002 17:43:37 -0400 Received: from asmhome (asmirnov-isdn-home.cisco.com [10.49.1.50]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with SMTP id g51LhZW10108 for ; Sat, 1 Jun 2002 23:43:35 +0200 (CEST) References: <001501c2099f$12789e60$3201310a@asmhome> <3CF925E3.409A143C@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <001101c209b5$6df6b310$3201310a@asmhome> Date: Sat, 1 Jun 2002 23:43:53 +0200 Reply-To: Mailing List Sender: Mailing List From: Anton Smirnov Organization: Cisco Systems Subject: Re: Dynamic Priority setting for DR election To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Mitchel, there must be several conditions met for platform to benefit from DR offload: - (in broad sense of the word) must have many interfaces, dozens if not hundreds - These interfaces must be OSPF broadcast/NBMA (because there is no DR on ptp links) - On each interface more than one neighbor should be present. This rule is because otherwise interfaces should be converted - manually or somehow automatically - to ptp. Thus dozens of apparently needless Net LSAs will be eliminated from LSDB, having other benefits (less flooding and simpler SPF in the area) - Set of routers on each interface should be different. If same routers are neighboring thru dozens of transit interfaces then one must think about reasonable network design, right? I can't think of any widely accepted industry solution matching all these requirements. Access solutions tend to have ptp links, whatever L2 method is employed. Layer 3 switches come closest to matching all these conditions but it is because last rule usually neglected. On L3 switches all interfaces (or vlans) where end clients are connected may and should be configured as stub networks, not transit. Then I just do not see a case where DR offload may be beneficial. That was my point. Of course, there always exist freaks who for very specific reasons want to do something unusual. But these freaks can manually play with OSPF priorities on interfaces of routers. Anton ----- Original Message ----- From: "Erblichs" To: Sent: Saturday, June 01, 2002 9:52 PM Subject: Re: [OSPF] Dynamic Priority setting for DR election > Anton, > > This was a request to investigate this functionality. > > My assumption is that if the router architecture supports > MANY DR capable interfaces, then they would like to > have different routers willing to over-ride other > configured priority values.. > > So, they don't have to set a fixed priority value per > interface and not be sure that the router will be the > DR. They don't have to set the highest value. After > the router is elected DR. They only have to execute > a CLI to determine what is the current priority that > the router selected per interface. > > Simply, this is a administration issue. > > And, if I understand your resource statement correctly, > then I would have to disagree. A one item example.. > After a DR is elected, > this router would then have to sychronize its database > with all DRothers.. The time to do this is mostly dependent > on the number of capable simultaneous adj formations > without overload.. > And of course, their is a overload draft that > suggests to limit this simultaneous adjs to a known > acceptable value. This value is dependent on the > capabilities of the router.. > > Mitchell Erblich > PS: And if anyone was wondering, the hello interval > and the ROUTERDEADINTERVAL could also be read from > recieved hellos. Again, this could lead to less required > configuration to establish 2-ways. > ======================== > > > > > Anton Smirnov wrote: > > > > Mitchell, > > I don't think DR's responsibilities have big impact on resources of > > , especially if any technique to optimize flooding over parallel > > links has been implemented. Thus dynamic priority change looks like bringing > > problems rather than solving them... > > > > Anton > > > > ----- Original Message ----- > > From: "Manral, Vishwas" > > To: > > Sent: Saturday, June 01, 2002 2:25 PM > > Subject: Re: [OSPF] Dynamic Priority setting for DR election > > > > > Hi Mitchell, > > > > > > I do not know your exact intent and what you want to achieve here, but > > this > > > method would not be backward compatible with the existing methods. For a > > > method to be useful, its extremely important it is able to interoperate > > with > > > existing methods. > > > > > > I dont know of anything like this having been proposed in any draft in the > > > recent past. > > > > > > However I guess there are some implementations in ISIS which flip up the > > > priority of the DIS(DR) so as to prevent frequent changes of the DIS(as > > has > > > been pointed out earlier in the list). I do not know of any dynamic > > > selection of priority though. > > > > > > Thanks, > > > Vishwas > > > > > > > > > -----Original Message----- > > > From: Erblichs [mailto:erblichs@EARTHLINK.NET] > > > Sent: Saturday, June 01, 2002 4:31 AM > > > To: OSPF@DISCUSS.MICROSOFT.COM > > > Subject: Dynamic Priority setting for DR election > > > > > > > > > Hi Group, > > > > > > Has anyone heard of a router's priority selection based > > > based on incoming values of the hello packet's priority > > > field? > > > > > > Would their be an experimental draft during the past > > > years that explictly or implicitly state this type > > > of feature? > > > > > > Basicly > > > > > > 0) Assuming that a DR and BDR were not already > > > elected. > > > > > > 1) delaying hello xmits during bootup for > > > a period not to exceed or equal waittime, > > > > > > 2) Identifing a max of the priorities per > > > DR capable interface, > > > > > > 3) Then transmitting hello packets with a higher > > > priority than the calculated max and dynamically > > > setting that value.. > > > > > > This would make it the DR, unless another > > > router's priority was set to the max.. > > > > > > Yes, I believe this would be a non-standard functionality, > > > and should require the formal setting of a CLI command > > > to enable this type of feature. > > > > > > And yes, their could be issues with two or more > > > routers configured this way. > > > > > > Mitchell Erblich > > > > From owner-ospf@DISCUSS.MICROSOFT.COM Sun Jun 2 09:26:17 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14418 for ; Sun, 2 Jun 2002 09:26:17 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00631461@cherry.ease.lsoft.com>; 2 Jun 2002 9:26:39 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 876584 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 2 Jun 2002 09:26:38 -0400 Received: from 202.54.64.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sun, 2 Jun 2002 09:26:37 -0400 Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Sun, 2 Jun 2002 19:11:06 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <55E277B99171E041ABF5F4B1C6DDCA06184BCF@HARITHA> Date: Sun, 2 Jun 2002 18:58:36 +0530 Reply-To: Mailing List Sender: Mailing List From: "Balaji R (Networking) - CTD, Chennai." Subject: Re: Identification of neighbors in PTP links To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hello, Thanks for your inputs Acee and Venkata. ---------------------------------------------------------------------------- ------------------------------------------- In ptp links, if the two sides have dissimilar IP subnets assigned, then I guess option 2 of 12.4.1.1 can't be applied. So, we would have to go with option 1. Since Link ID contains the neighbor's IP address in this case, we would have re-originate the LSA when the neigbor's IP address changes, or else the interface for which IP address has changed will not be reachable. To exemplify, Let us say that routers R1 and R2 are connected to each other through a numbered ptp link. R1's IP address is 192.168.232.1/16 and R2's is 193.168.232.1/16. Now, R1 would advertise an LSA with Link ID set to 193.168.232.1/16 and R2 would advertise 192.168.232.1/16. So, 193.168.232.1 is reachable through R1 only (same is the case for 192.168.232.1 advertised by R2). At this stage, if R2's IP address changes to, say, 194.168.232.1/16, it would not be reachable unless and until R1 began to advertise this. This is why I thought change in neighbor's IP adderss has to be detected. Correct me if I am wrong. ---------------------------------------------------------------------------- ------------------------------------------- I would be more interested in knowing the implications of identifying neighbors based on source IP address as against the router ID as mentioned in the RFC 2328 in section 10.5. ---------------------------------------------------------------------------- -------------------------------------------- Thanks, Balaji.R. -----Original Message----- From: Acee Lindem [mailto:acee@REDBACK.COM] Sent: Friday, May 31, 2002 7:13 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Identification of neighbors in PTP links Naidu, Venkata wrote: > Balaji, Acee, > > -> (Actually, on numbered ptp links, we would have to check if the > -> source IP address has > -> > changed every time we receive a packet, since we originate > -> router LSA with > -> > the neighbor's IP address. I guess we would have to > -> re-originate a new LSA > -> > if the neighbor's IP address changed. So, I thought > -> locating the neighbor > -> > based on source IP address would hanlde this case more easily.) > -> > -> For P2P links, the link data in your router link contains > -> your interface IP > -> address - not your neighbors. You should not have to > -> originate a new router > -> LSA if your neighbor's IP address changes. > > In Option 1, P2P stub link represents neighbor IP address > and not local interface IP address. I guess I didn't even support this option this time around since option 2 results in fewer routes in the OSPF routing domain. > > More over, the neighbor IP address is used as the next > hop for all the SPF routes through the neighbor router. > Though, next hop IP address is not required for P2P links > (numbered or unnumbered) - because the L3->L2 address > resolution won't arise when forwarding packets in case of > P2P links, most of the implementations still uses neighbor > IP address as the next hop for all those routes. > > For all the above reason, the neighbor IP address change > might results in re-originating and/or re-computing SPF. The router whose IP address changes should be responsible for re-originating their LSA. This will result in SPF computations on other routers in the OSPF area. If you perform an SPF when the IP source address changes you'll end doing another one when you receive the changed LSA. > > -- > Venkata. > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Sun Jun 2 13:38:15 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17433 for ; Sun, 2 Jun 2002 13:38:15 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00631785@cherry.ease.lsoft.com>; 2 Jun 2002 13:38:42 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 877048 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 2 Jun 2002 13:38:42 -0400 Received: from 64.12.136.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sun, 2 Jun 2002 13:38:42 -0400 Received: from Jjsyed@aol.com by imo-m04.mx.aol.com (mail_out_v32.5.) id 7.12a.120346f7 (15702) for ; Sun, 2 Jun 2002 13:38:36 -0400 (EDT) Received: from aol.com (mow-m32.webmail.aol.com [64.12.137.9]) by air-id05.mx.aol.com (v86.12) with ESMTP id MAILINID53-0602133835; Sun, 02 Jun 2002 13:38:35 -0400 X-Mailer: Atlas Mailer 2.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <582F942D.481C624A.0004D071@aol.com> Date: Sun, 2 Jun 2002 13:38:35 -0400 Reply-To: Mailing List Sender: Mailing List From: Javed Syed Subject: Routing bit set on sho ip ospf database To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit Hi, I have question on " sho ip ospf database " output command. One of the line from the output has a routing bit set. Can somebody explain me the importance of this field. I have not seen this line when I do above command on ASBR router. I think I know the answer but still would like to have good explanation from this alias. regards js From owner-ospf@DISCUSS.MICROSOFT.COM Sun Jun 2 13:51:27 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17552 for ; Sun, 2 Jun 2002 13:51:27 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.0063178C@cherry.ease.lsoft.com>; 2 Jun 2002 13:51:54 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 877112 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 2 Jun 2002 13:51:54 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sun, 2 Jun 2002 13:51:54 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 01617FC054 for ; Sun, 2 Jun 2002 10:51:51 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <582F942D.481C624A.0004D071@aol.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3CFA5A62.60106@redback.com> Date: Sun, 2 Jun 2002 13:48:18 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Routing bit set on sho ip ospf database To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Javed Syed wrote: > Hi, > > I have question on " sho ip ospf database " output command. One of the line from the output has a routing bit set. Can somebody explain me the importance of this field. I have not seen this line when I do above command on ASBR router. > I think I know the answer but still would like to have good explanation from this alias. Syed, I believe this is a vendor specific question and you'd better served by directing it to your vendor. Having said that, if your vendor's implementation is similiar to ours the router bits in the "show ospf database detail" output corresponding directly to the type LSA 1 router bits as documented in section A.4.2 of RFC 2328. [local]SE1#show ospf database router detail --- OSPF Link State Database for Instance 1/Router ID 193.10.25.7 --- --- Router LSA 193.10.25.7 (Area 0.0.0.0) --- Link State Id : 193.10.25.7 Advertising Router : 193.10.25.7 Sequence Number : 0x80000004 Checksum : 0xfc53 Options : E,DC,O Length : 36 RouterBits : B LinkCount : 1 Age : 290 Link Type : stub Network Number (Link id) : 193.4.0.0 Link Metric : 1 Network Mask (Link data) : 255.255.0.0 --- Router LSA 193.10.25.7 (Area 0.0.0.1) --- Link State Id : 193.10.25.7 Advertising Router : 193.10.25.7 Sequence Number : 0x80000006 Checksum : 0x6387 Options : E,DC,O Length : 48 RouterBits : B LinkCount : 2 Age : 290 Link Type : stub Network Number (Link id) : 10.1.0.0 Link Metric : 1 Network Mask (Link data) : 255.255.0.0 Link Type : stub Network Number (Link id) : 10.3.0.0 Link Metric : 1 Network Mask (Link data) : 255.255.0.0 > > regards > js > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Sun Jun 2 23:19:59 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23458 for ; Sun, 2 Jun 2002 23:19:59 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00632455@cherry.ease.lsoft.com>; 2 Jun 2002 23:20:25 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 878020 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 2 Jun 2002 23:20:24 -0400 Received: from 66.163.169.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sun, 2 Jun 2002 23:20:24 -0400 Received: from [203.200.20.226] by web21508.mail.yahoo.com via HTTP; Sun, 02 Jun 2002 20:20:23 PDT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-597926419-1023074423=:91050" Message-ID: <20020603032023.91076.qmail@web21508.mail.yahoo.com> Date: Sun, 2 Jun 2002 20:20:23 -0700 Reply-To: Mailing List Sender: Mailing List From: Amit Srivastava Subject: DR & BDR Election?? To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20020528.154515.58386327.yasu@sfc.wide.ad.jp> Precedence: list --0-597926419-1023074423=:91050 Content-Type: text/plain; charset=us-ascii Hi Yasu, When you say that DR(Router A) has resigned from DR what exactly do you mean??? Is it that A goes down.In that case also it would take 40 seconds( Usual router dead interval) for the BDR to detect that the router has gone down and by that time there would again be the 2nd DR and BDR election. I hope i am clear!! If you have explanation of this please let me know the answer!! Regards Amit Yasuhiro Ohara wrote: > Question > --------- > I have doubt with (ii) and (iii). Should router A have placed itself in BDR > candidates list before recalculating steps (2) and (3) or just allow router > C to retain its BDR post? In my understanding, an implementation strictly following RFC2328 will do latter: just allow router C to retain its BDR post. The next BDR view of the segment depends on whether A will declare itself as BDR or not. > I can understand why a newly designated DR needs to repeat steps (2) and > (3). Those steps avoid the router from claiming to be DR and BDR at one > time. However I cannot see why *repetition* of those steps are required for > a router that self-nominate as BDR, resigning from BDR, or resigning from > DR, as indicated by step (4) because even after the recalculation, its view > will never change. Do I miss any important point here? I can't think of a situation where the 2nd calculation of DR (2nd (3)) is necessary ... (I want someone to teach me ...) But obviously 2nd calculation of BDR (2nd (2)) is necessary, see below: # note: RFC2328 9.4 (2) describes BDR calculation, (3) describes DR # calculation new comer +-+-+ +-+-+ +-+-+ |A|1| |B|0| |C|2| +-+-+ +-+-+ +-+-+ | A | | A | | C | +---+ +---+ +---+ | - | | - | | - | +---+ +---+ +---+ after C 1st (2)(3) - after C 2nd (2) A Router B has priority 0 so he is not eligible to become neither DR nor BDR. So before the newcomer comes, the segment's DR is A and BDR is none. Looking into A's calculation, After the newcomer has come and just after 1st calculation of DR/BDR, A has just resigned DR but he's yet eligible to become BDR. If we don't recalculate BDR/DR again, A cannot realize that he can be BDR. regards. yasu --------------------------------- Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup --0-597926419-1023074423=:91050 Content-Type: text/html; charset=us-ascii

Hi Yasu,

        When you say that DR(Router A) has resigned from DR what exactly do you mean??? Is it that A goes down.In that case also it would take 40 seconds( Usual router dead interval) for the BDR to detect that the router has gone down and by that time there would again be the 2nd DR and BDR election.

                    I hope i am clear!! If you have explanation of this please let me know the answer!!

Regards

Amit

 

  Yasuhiro Ohara <yasu@SFC.WIDE.AD.JP> wrote:

> Question
> ---------
> I have doubt with (ii) and (iii). Should router A have placed itself in BDR
> candidates list before recalculating steps (2) and (3) or just allow router
> C to retain its BDR post?

In my understanding, an implementation strictly following RFC2328 will
do latter: just allow router C to retain its BDR post. The next BDR
view of the segment depends on whether A will declare itself as BDR or
not.

> I can understand why a newly designated DR needs to repeat steps (2) and
> (3). Those steps avoid the router from claiming to be DR and BDR at one
> time. However I cannot see why *repetition* of those steps are required for
> a router that self-nominate as BDR, resigning from BDR, or resigning from
> DR, as indicated by step (4) because even after the recalculation, its view
> will never change. Do I miss any important point here?

I can't think of a situation where the 2nd calculation of DR (2nd (3))
is necessary ... (I want someone to teach me ...)

But obviously 2nd calculation of BDR (2nd (2)) is necessary, see
below:

# note: RFC2328 9.4 (2) describes BDR calculation, (3) describes DR
# calculation

new comer
+-+-+ +-+-+ +-+-+
|A|1| |B|0| |C|2|
+-+-+ +-+-+ +-+-+
| A | | A | | C |
+---+ +---+ +---+
| - | | - | | - |
+---+ +---+ +---+

after C
1st (2)(3) -

after C
2nd (2) A

Router B has priority 0 so he is not eligible to become neither DR nor
BDR. So before the newcomer comes, the segment's DR is A and BDR is
none.

Looking into A's calculation, After the newcomer has come and just
after 1st calculation of DR/BDR, A has just resigned DR but he's
yet eligible to become BDR. If we don't recalculate BDR/DR again,
A cannot realize that he can be BDR.

regards.
yasu


Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup --0-597926419-1023074423=:91050-- From owner-ospf@DISCUSS.MICROSOFT.COM Sun Jun 2 23:31:48 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23919 for ; Sun, 2 Jun 2002 23:31:48 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.006325D6@cherry.ease.lsoft.com>; 2 Jun 2002 23:32:15 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 878056 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 2 Jun 2002 23:32:15 -0400 Received: from 203.254.224.25 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sun, 2 Jun 2002 23:32:15 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) id <0GX400J011SDEV@mailout2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Mon, 03 Jun 2002 12:31:25 +0900 (KST) Received: from ms (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GX400J061SDEL@mailout2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Mon, 03 Jun 2002 12:31:25 +0900 (KST) Received: from custom-daemon.ms.samsung.com by ms.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) id <0GX4007011M93M@ms.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Mon, 03 Jun 2002 12:27:45 +0900 (KST) Received: from samsung.com (localhost [127.0.0.1]) by ms.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GX4006GC1M9GM@ms.samsung.com>; Mon, 03 Jun 2002 12:27:45 +0900 (KST) Received: from [165.213.140.94] by ms.samsung.com (mshttpd); Mon, 03 Jun 2002 03:27:45 +0000 (GMT) MIME-version: 1.0 X-Mailer: iPlanet Webmail Content-type: text/html; charset=EUC-KR Content-language: ko Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: ko Message-ID: <2ce052ff82.2ff822ce05@samsung.com> Date: Mon, 3 Jun 2002 03:27:45 +0000 Reply-To: Mailing List Sender: Mailing List From: Manav Bhatia Subject: good morning Comments: To: ospfisfun@YAHOO.COM To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable = =3Chtml=3E=3Cnobr=3E=3Cimg src=3Dhttp=3A//maildb=2Esamsung=2Ecom=3A8001/o= penconfirm=3Fparm=3Dmanav=5F=5Fmanav20020604123702324 width=3D=221=22 hei= ght=3D=221=22=3E=3C/nobr=3E =3Cfont size=3D3 face=3D=22=B1=BC=B8=B2=C3=BC=22=3E =3Cpre=3Eamit=2C this is somewhat urgent ! contact deepak asap and tell him to mail me =2E=2E i dont have yahoo mssn= gr installed on this laptop and i cant thus chat with him =2E=2E he must mail me at ma= nav=40samsung=2Ecom i dont know his mail id and am thus asking you! rest everything is okay =2E=2E the girls here are going crazy thinking of= you =2E=2E = and all the girls remmeber just one name =22amIt =2E =2Eamit =2E=2E amit = =2E=2E amit=22 manav=3C/font=3E=3C/pre=3E=3C/html=3E From owner-ospf@DISCUSS.MICROSOFT.COM Sun Jun 2 23:38:01 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24017 for ; Sun, 2 Jun 2002 23:38:00 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.006324DA@cherry.ease.lsoft.com>; 2 Jun 2002 23:38:27 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 878089 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 2 Jun 2002 23:38:27 -0400 Received: from 203.254.224.25 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sun, 2 Jun 2002 23:38:27 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) id <0GX400J0122PXH@mailout2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Mon, 03 Jun 2002 12:37:37 +0900 (KST) Received: from ms (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GX400JDS22PEL@mailout2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Mon, 03 Jun 2002 12:37:37 +0900 (KST) Received: from custom-daemon.ms.samsung.com by ms.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) id <0GX4007011WM60@ms.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Mon, 03 Jun 2002 12:33:58 +0900 (KST) Received: from samsung.com (localhost [127.0.0.1]) by ms.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GX40068I1WLUJ@ms.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Mon, 03 Jun 2002 12:33:57 +0900 (KST) Received: from [165.213.140.94] by ms.samsung.com (mshttpd); Mon, 03 Jun 2002 03:33:57 +0000 (GMT) MIME-version: 1.0 X-Mailer: iPlanet Webmail Content-type: text/html; charset=EUC-KR Content-language: ko Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: ko Message-ID: <2e1fa2e275.2e2752e1fa@samsung.com> Date: Mon, 3 Jun 2002 03:33:57 +0000 Reply-To: Mailing List Sender: Mailing List From: Manav Bhatia Subject: Re : good morning To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable = =3Chtml=3E=3Cnobr=3E=3Cimg src=3Dhttp=3A//maildb=2Esamsung=2Ecom=3A8001/o= penconfirm=3Fparm=3Dmanav=5F=5Fmanav20020604124314646 width=3D=221=22 hei= ght=3D=221=22=3E=3C/nobr=3E =3Cfont size=3D3 face=3D=22=B1=BC=B8=B2=C3=BC=22=3E =3Cpre=3Ei am very so= rry =2E=2E this mail was not intended to be mailed on to the list!! regards and apologies=2C manav ----------- original message ------------- Sender=3A Manav Bhatia =3Cmanav=40samsung=2Ecom=3E Date=3A 2002=B3=E2 6=BF=F9 3=C0=CF =BF=C0=C8=C412=3A27 Subject=3A good morning =3E amit=2C =3E this is somewhat urgent ! =3E contact deepak asap and tell him to = =3E mail me =2E=2E i dont have yahoo mssngr = =3E installedon this laptop and i cant = =3E thus chat with him =2E=2E he must mail = =3E me at manav=40samsung=2Ecom =3E = =3E i dont know his mail id and am thus = =3E asking you! =3E = =3E rest everything is okay =2E=2E the girls = =3E here are going crazy thinking of you = =3E =2E=2E = =3E and all the girls remmeber just one = =3E name =22amIt =2E =2Eamit =2E=2E amit =2E=2E amit=22 =3E = =3E manav=3C/font=3E=3C/pre=3E=3C/html=3E From owner-ospf@DISCUSS.MICROSOFT.COM Mon Jun 3 07:00:16 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07826 for ; Mon, 3 Jun 2002 07:00:16 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00632C18@cherry.ease.lsoft.com>; Mon, 3 Jun 2002 7:00:43 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 880334 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 3 Jun 2002 07:00:43 -0400 Received: from 66.163.169.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 3 Jun 2002 07:00:43 -0400 Received: from [203.200.20.226] by web21501.mail.yahoo.com via HTTP; Mon, 03 Jun 2002 04:00:37 PDT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-706124454-1023102037=:12629" Message-ID: <20020603110037.12823.qmail@web21501.mail.yahoo.com> Date: Mon, 3 Jun 2002 04:00:37 -0700 Reply-To: Mailing List Sender: Mailing List From: Amit Srivastava Subject: Re: DR and BDR election: Simplified.. To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3CEF2FBF.77B7D7B9@earthlink.net> Precedence: list --0-706124454-1023102037=:12629 Content-Type: text/plain; charset=us-ascii Hi all, I am still not getting any specific scenario where we would require to run the DR and BDR election again as specified by the RFC Regards Amit Erblichs wrote: I would like to try to simplify the election process.. Flames are expected... Please be aware that I tend to be verbose.. here goes... Assuming the proper network topology and that all the routers have just come up and that the BDR and DR are initially defined as 0.0.0.0... 1) First we wait for the configured wait time to expire.. 2) Now we walk thru all the viable routers who can be the BDR. They should be at least in the 2WAY state and have a non-zero priority.. 3) The highest priority one becomes the BDR... 4) Now we do #2 and #3 for the DR.. 5) The highest priority router actually becomes the DR because he was promoted to become the DR.. See Cisco ref #5 and #6.p. 422 Chapt 9. OSPF... 6) Problem is that he is now the BDR AND the DR.. 7) So we run the election for the BDR again eliminating the DR as a viable candidate for the BDR and get the next highest priority eligible router as the BDR.. If their is no candidate now for the BDR position it is set to 0.0.0.0.. 8) This is it in a nutshell.. Or what was originally coded years ago.. *** Again this is just one sequence that goes with the election process.. No, * I have not covered the DR who due to RouterDeadInterval lost his DR status.. * I have not covered when their is an existing DR... * Etc... My understanding of the confusion is with declaration of multiple routers declaring themselves the DR or BDR when an area was PARTITIONED and only remerged.. Paritioning may also happen if one or more hello parameters was not matched with all the routers, but actually formed two or more sets of routers within an area.. I BELIEVE, One or more routers may declare themselves ONLY if the areas or subareas was then merged together.. This is how you can have two or more DRs or BDRs declaring themselves as such. Only in this case, will you elect the router with the highest priority in both cases to become the newer BDR and DR from the declared groups.. Hope this helps... Mitchell Erblich --------------------------------- Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup --0-706124454-1023102037=:12629 Content-Type: text/html; charset=us-ascii

Hi all,

        I am still not getting any specific scenario where we would require to run the DR and BDR election again as specified by the RFC

Regards

Amit

  Erblichs <erblichs@EARTHLINK.NET> wrote:

I would like to try to simplify the election process..
Flames are expected...
Please be aware that I tend to be verbose..

here goes...

Assuming the proper network topology and that all
the routers have just come up and that the
BDR and DR are initially defined as 0.0.0.0...

1) First we wait for the configured wait time
to expire..

2) Now we walk thru all the viable routers who
can be the BDR. They should be at least in
the 2WAY state and have a non-zero priority..

3) The highest priority one becomes the BDR...

4) Now we do #2 and #3 for the DR..

5) The highest priority router actually becomes
the DR because he was promoted to become
the DR.. See Cisco ref #5 and #6.p. 422 Chapt 9. OSPF...

6) Problem is that he is now the BDR AND the
DR..

7) So we run the election for the BDR again
eliminating the DR as a viable candidate
for the BDR and get the next highest priority
eligible router as the BDR.. If their is
no candidate now for the BDR position it is
set to 0.0.0.0..

8) This is it in a nutshell.. Or what was originally
coded years ago..

*** Again this is just one sequence that goes
with the election process..

No,

* I have not covered the DR who due to RouterDeadInterval
lost his DR status..

* I have not covered when their is an existing DR...

* Etc...

My understanding of the confusion is with declaration of
multiple routers declaring themselves the DR or BDR when an
area was PARTITIONED and only remerged..

Paritioning may also happen if one or more hello parameters
was not matched with all the routers, but actually formed
two or more sets of routers within an area..

I BELIEVE, One or more routers may declare themselves ONLY
if the areas or subareas was then merged together.. This is how
you can have two or more DRs or BDRs declaring themselves
as such. Only in this case,
will you elect the router with the highest priority in
both cases to become the newer BDR and DR from the declared
groups..

Hope this helps...

Mitchell Erblich


Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup --0-706124454-1023102037=:12629-- From owner-ospf@DISCUSS.MICROSOFT.COM Mon Jun 3 07:18:17 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08037 for ; Mon, 3 Jun 2002 07:18:17 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00632C04@cherry.ease.lsoft.com>; Mon, 3 Jun 2002 7:18:44 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 880411 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 3 Jun 2002 07:18:44 -0400 Received: from 203.178.142.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 3 Jun 2002 07:18:44 -0400 Received: from localhost (page.sfc.wide.ad.jp [203.178.143.89]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id AEE0B5D012; Mon, 3 Jun 2002 20:18:42 +0900 (JST) References: <20020528.154515.58386327.yasu@sfc.wide.ad.jp> <20020603032023.91076.qmail@web21508.mail.yahoo.com> X-Mailer: Mew version 2.1 on XEmacs 21.1.14 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Message-ID: <20020603.201209.31226830.yasu@sfc.wide.ad.jp> Date: Mon, 3 Jun 2002 20:12:09 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: DR & BDR Election?? Comments: To: ospfisfun@YAHOO.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20020603032023.91076.qmail@web21508.mail.yahoo.com> Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA08037 No, I don't mean "router down" by "resigning DR". In that situation cited below, 1st DR calculation of "A" results that "A" is not DR anymore. This means "resigning DR". Again, if "A" does not do the 2nd DR Calculation, "A" cannot find that he can be BDR. If "A" does not declare himself as BDR, there's still no BDR on the segment, which is not nice. regards. yasu > Hi Yasu, > >         When you say that DR(Router A) has resigned from DR what exactly do > you mean??? Is it that A goes down.In that case also it would take 40 seconds( > Usual router dead interval) for the BDR to detect that the router has gone > down and by that time there would again be the 2nd DR and BDR election. > >                     I hope i am clear!! If you have explanation of this please > let me know the answer!! > > Regards > > Amit > >   > >   Yasuhiro Ohara wrote: > > > Question > > --------- > > I have doubt with (ii) and (iii). Should router A have placed itself in > BDR > > candidates list before recalculating steps (2) and (3) or just allow > router > > C to retain its BDR post? > > In my understanding, an implementation strictly following RFC2328 will > do latter: just allow router C to retain its BDR post. The next BDR > view of the segment depends on whether A will declare itself as BDR or > not. > > > I can understand why a newly designated DR needs to repeat steps (2) and > > (3). Those steps avoid the router from claiming to be DR and BDR at one > > time. However I cannot see why *repetition* of those steps are required > for > > a router that self-nominate as BDR, resigning from BDR, or resigning > from > > DR, as indicated by step (4) because even after the recalculation, its > view > > will never change. Do I miss any important point here? > > I can't think of a situation where the 2nd calculation of DR (2nd (3)) > is necessary ... (I want someone to teach me ...) > > But obviously 2nd calculation of BDR (2nd (2)) is necessary, see > below: > > # note: RFC2328 9.4 (2) describes BDR calculation, (3) describes DR > # calculation > > new comer > +-+-+ +-+-+ +-+-+ > |A|1| |B|0| |C|2| > +-+-+ +-+-+ +-+-+ > | A | | A | | C | > +---+ +---+ +---+ > | - | | - | | - | > +---+ +---+ +---+ > > after C > 1st (2)(3) - > > after C > 2nd (2) A > > Router B has priority 0 so he is not eligible to become neither DR nor > BDR. So before the newcomer comes, the segment's DR is A and BDR is > none. > > Looking into A's calculation, After the newcomer has come and just > after 1st calculation of DR/BDR, A has just resigned DR but he's > yet eligible to become BDR. If we don't recalculate BDR/DR again, > A cannot realize that he can be BDR. > > regards. > yasu > > ------------------------------------------------------------------------------ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > From owner-ospf@DISCUSS.MICROSOFT.COM Mon Jun 3 22:05:52 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06839 for ; Mon, 3 Jun 2002 22:05:52 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00634C25@cherry.ease.lsoft.com>; Mon, 3 Jun 2002 22:06:14 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 878011 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 3 Jun 2002 22:06:14 -0400 Received: from 192.11.223.161 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 3 Jun 2002 22:06:14 -0400 Received: from ci1093exch001p.wins.lucent.com (h135-252-12-239.lucent.com [135.252.12.239]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g5426Cx07864 for ; Mon, 3 Jun 2002 22:06:12 -0400 (EDT) Received: by CI1093EXCH001P with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Jun 2002 10:06:11 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="gb2312" Message-ID: <31C0F08B0D18D511ACC800508BAE7B4702B9CFF4@CI0026EXCH001U> Date: Tue, 4 Jun 2002 10:06:07 +0800 Reply-To: Mailing List Sender: Mailing List From: "Li, Ke Qin (Peter)" Subject: Loop Detection To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, I've the following question: Given a network with several routers, is there any tool/application to detect loops in the routing tables? Keqin Li Bell Labs Research China Tel: 86-010-68748088-8438 From owner-ospf@DISCUSS.MICROSOFT.COM Mon Jun 3 22:24:12 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07089 for ; Mon, 3 Jun 2002 22:24:12 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00634CB2@cherry.ease.lsoft.com>; Mon, 3 Jun 2002 22:24:41 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 878042 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 3 Jun 2002 22:24:41 -0400 Received: from 64.246.202.156 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 3 Jun 2002 22:24:40 -0400 Received: from [192.168.254.10] by mainserver (ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.1.1)); Mon, 3 Jun 2002 22:21:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: Date: Mon, 3 Jun 2002 22:25:02 -0400 Reply-To: Mailing List Sender: Mailing List From: Tom Thomas Subject: Re: Loop Detection To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <31C0F08B0D18D511ACC800508BAE7B4702B9CFF4@CI0026EXCH001U> Precedence: list Content-Transfer-Encoding: 7bit traceroute? -----Original Message----- From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Li, Ke Qin (Peter) Sent: Monday, June 03, 2002 10:06 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Loop Detection Hi, I've the following question: Given a network with several routers, is there any tool/application to detect loops in the routing tables? Keqin Li Bell Labs Research China Tel: 86-010-68748088-8438 From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jun 4 13:30:41 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06920 for ; Tue, 4 Jun 2002 13:30:41 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00636072@cherry.ease.lsoft.com>; Tue, 4 Jun 2002 13:31:05 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 880661 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 4 Jun 2002 13:31:05 -0400 Received: from 157.181.1.137 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 4 Jun 2002 13:21:05 -0400 Received: from pandora (pandora.inf.elte.hu [157.181.161.17]) by mx1.elte.hu (Postfix) with SMTP id 004C94454E for ; Tue, 4 Jun 2002 19:20:11 +0200 (CEST) Message-ID: <20020604172011.004C94454E@mx1.elte.hu> Date: Tue, 4 Jun 2002 17:06:09 +0200 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Attila Nohl Subject: Sending new LSA To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hello! I have question about originating new LSAs. Let's say that the status of a router's interface changes. In this case, the router creates a new Router LSA, replaces its own Router LSA in its LSA database and sends the new LSA to its neighbours. My questions are: - When the LSA is replaced in the LSA database, does the router run an SPF calculation (because the LSA database has changed)? I think, if the interface is towards a transit network, then the router must run the SPF calculation, but what happens in case of interfaces towards stub networks? - If the router runs an SPF calculation, which happens sooner? The sending of the LSA to the neighbours or the SPF calculation? Bye,NAR From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jun 4 15:14:53 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11217 for ; Tue, 4 Jun 2002 15:14:53 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00636236@cherry.ease.lsoft.com>; Tue, 4 Jun 2002 15:15:21 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 881009 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 4 Jun 2002 15:15:21 -0400 Received: from 144.254.15.119 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 4 Jun 2002 15:15:21 -0400 Received: from asmhome (asmirnov-isdn-home.cisco.com [10.49.1.50]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with SMTP id g54JFJW07772 for ; Tue, 4 Jun 2002 21:15:19 +0200 (CEST) References: <20020604172011.004C94454E@mx1.elte.hu> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <003101c20bfc$3727bb10$3201310a@asmhome> Date: Tue, 4 Jun 2002 21:15:38 +0200 Reply-To: Mailing List Sender: Mailing List From: Anton Smirnov Organization: Cisco Systems Subject: Re: Sending new LSA To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Attila, you can schedule full SPF whenever your own router LSA changes to be on the safe side. But apparently implementation may try to optimize SPF algorithm - including complete elimination of SPF run - if this doesn't produce discrepancy with standardized behavior. It makes very good sense to schedule SPF based on interface+neighbor state change rather than on only interface up or down change. If router doesn't have any neighbors on local interface then full SPF likely to bring no changes in the routing table (though some implementation may require it for some reason) If you strictly follow standard timers then router always sends LSA before running SPF (at least if SPF was triggered by change in this LSA, not by another LSA some seconds earlier). In theory, I could imagine that well-designed implementation sends LSA "at the very same time" as SPF is running. But, generally speaking, if you run SPF first then flood then changes in routing tables throughout OSPF domain will look more like in distance-vector protocols. Remember that SPF run is relatively slow process. Not a nice thing you could expect from link state protocol, right? Such timers configuration better be avoided. Anton ----- Original Message ----- From: "Attila Nohl" To: Sent: Tuesday, June 04, 2002 5:06 PM Subject: [OSPF] Sending new LSA > Hello! > > I have question about originating new LSAs. Let's say that the status of > a router's interface changes. In this case, the router creates a new > Router LSA, replaces its own Router LSA in its LSA database and sends the > new LSA to its neighbours. My questions are: > > - When the LSA is replaced in the LSA database, does the router run an SPF > calculation (because the LSA database has changed)? I think, if the > interface is towards a transit network, then the router must run the > SPF calculation, but what happens in case of interfaces towards stub > networks? > > - If the router runs an SPF calculation, which happens sooner? The sending > of the LSA to the neighbours or the SPF calculation? > > Bye,NAR > From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jun 4 16:16:40 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13488 for ; Tue, 4 Jun 2002 16:16:38 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.006367C5@cherry.ease.lsoft.com>; Tue, 4 Jun 2002 16:17:07 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 881321 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 4 Jun 2002 16:17:07 -0400 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 4 Jun 2002 16:17:07 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA23291 for ; Tue, 4 Jun 2002 16:17:04 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA17685 for ; Tue, 4 Jun 2002 16:16:59 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 4 Jun 2002 16:16:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC557631E1@vie-msgusr-01.dc.fore.com> Date: Tue, 4 Jun 2002 16:16:49 -0400 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: Sending new LSA To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Attila, -> - When the LSA is replaced in the LSA database, does the -> router run an SPF calculation (because the LSA database has changed)? Yes, as per OSPF standard, schedule SPF computation (partial/whole) when database changes. There was some good amount of work done in reducing the Routing Table Computation Cost in OSPF using WARs. (this work is never published in IETF - because figuring out WARs is very difficult and complicated task with many limitations) http://www.isoc.org/isoc/conferences/inet/99/proceedings/4g/4g_2.htm -> - If the router runs an SPF calculation, which happens -> sooner? The sending of the LSA to the neighbours or the -> SPF calculation? This is implementation dependent. Option of local convergence w.r.t global one (in the vicinity if few negligible seconds). If you delay flooding little bit, remember the global convergence will affect (based on queuing theory - including propagation and processing delays in each and every router). My choice - flood first. -- Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jun 4 22:15:14 2002 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22255 for ; Tue, 4 Jun 2002 22:15:14 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00637B3E@cherry.ease.lsoft.com>; Tue, 4 Jun 2002 22:15:29 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 882711 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 4 Jun 2002 22:15:29 -0400 Received: from 192.11.223.161 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 4 Jun 2002 22:15:29 -0400 Received: from ci1093exch001p.wins.lucent.com (h135-252-12-239.lucent.com [135.252.12.239]) by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g552FRi23206 for ; Tue, 4 Jun 2002 22:15:27 -0400 (EDT) Received: by CI1093EXCH001P with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Jun 2002 10:15:25 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20C36.D7DC46E0" Message-ID: <31C0F08B0D18D511ACC800508BAE7B4702B9CFF6@CI0026EXCH001U> Date: Wed, 5 Jun 2002 10:15:20 +0800 Reply-To: Mailing List Sender: Mailing List From: "Li, Ke Qin (Peter)" Subject: Re: Loop Detection Comments: To: "jshen@cad.zju.edu.cn" , routing-discussion@ietf.org To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C20C36.D7DC46E0 Content-Type: text/plain; charset="gb2312" But even every destinations in the network have been tracerouted from one router A, there can still be loops. In that case, the loop is not in any paths from A to other nodes. Is there any other approach? Keqin Li -----Original Message----- From: Jing Shen [mailto:jshen@cad.zju.edu.cn] Sent: Tuesday, June 04, 2002 10:48 AM To: Mailing List; routing-discussion@ietf.org Subject: Re: Loop Detection this is quite straight. traceroute will do help in finding such problem. Hi, I've the following question: Given a network with several routers, is there any tool/application to detect loops in the routing tables? Keqin Li Bell Labs Research China Tel: 86-010-68748088-8438 -- Jing Shen State Key Lab of CAD&CG ZheJiang University (YuQuan) HangZhou, ZheJiang Province 310027 P.R.China Email: jshen@cad.zju.edu.cn ********************************************************************** * The SunShine of life is made up of very little beams which is * * bright all the time * ********************************************************************** ------_=_NextPart_001_01C20C36.D7DC46E0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
But even=20 every destinations in the network have been tracerouted from one router = A, there=20 can still be loops. In that case, the loop is not in any paths from A = to other=20 nodes.
 
Is there=20 any other approach?
 
Keqin=20 Li
-----Original Message-----
From: Jing Shen=20 [mailto:jshen@cad.zju.edu.cn]
Sent: Tuesday, June 04, 2002 = 10:48=20 AM
To: Mailing List; = routing-discussion@ietf.org
Subject:=20 Re: Loop Detection

 this  is quite=20 straight.  traceroute will do help in finding such problem.=20
Hi,=20

I've the following question:=20

Given a network with several routers, is there any = tool/application to=20
detect loops in the routing tables?=20

Keqin Li
Bell Labs Research China
Tel:=20 86-010-68748088-8438

-- 
Jing Shen

State Key Lab of CAD&CG
ZheJiang University (YuQuan)
HangZhou, ZheJiang Province 310027
P.R.China

Email: jshen@cad.zju.edu.cn

**********************************************************************
* The SunShine of life is made up of very little beams which =
is      *
*  bright all the =
time           &n=
bsp;           &n=
bsp;           &n=
bsp;           *
********************************************************************** =20


------_=_NextPart_001_01C20C36.D7DC46E0--


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Jun  5 02:40:30 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21416
	for ; Wed, 5 Jun 2002 02:40:30 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0063868C@cherry.ease.lsoft.com>; Wed, 5 Jun 2002 2:40:58 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 883548 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 5 Jun 2002 02:40:58 -0400
Received: from 203.199.83.30 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 5 Jun 2002 02:40:56 -0400
Received: (qmail 29156 invoked by uid 510); 5 Jun 2002 06:40:33 -0000
Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 05 Jun
          2002 06:40:33 -0000
MIME-Version: 1.0
Content-type: text/plain; format=flowed
Content-Disposition: inline
Message-ID:  <20020605064033.29155.qmail@webmail20.rediffmail.com>
Date:         Wed, 5 Jun 2002 06:40:33 -0000
Reply-To: Mailing List 
Sender: Mailing List 
From: manish gupta 
Subject: VIRTUAL LINK
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

HI All,
      acoording to RFC 2328 to calculate the next hop..

If the destination is a router connected to the calculating router
via a virtual link, the setting of the next hop should be       deferred
until the calculation in Section 16.3.
but section 16.3 doesn't say anything regarding this.

my topology is

    0.0.0.0             1.1.1.1              2.2.2.2
   -----------R1-----------R2------------R3------

at every interface ospf is enabled
i configured a virtual link between R1 and R3
area 1.1.1.1 is transit area

should at R1's Routing table it have a routing entry to ABR R3 in
Backbone Area ???
as far as routing table at R1 for transit area it have a routing
entry for ABR R3 with next hop R2 Interface connected to R1 and i
feel it's correct ???

my question is while calculating Routing table at R1 for backbone
area should we have a routing entry for ABR R3
and if yes then how to calculate next hop and where to
calculate.

Regards
Manish Gupta










_________________________________________________________
Click below to visit monsterindia.com and review jobs in India or
Abroad
http://monsterindia.rediff.com/jobs


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Jun  5 21:09:53 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02812
	for ; Wed, 5 Jun 2002 21:09:53 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.0063A13B@cherry.ease.lsoft.com>; Wed, 5 Jun 2002 21:10:21 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 0062 for OSPF@DISCUSS.MICROSOFT.COM; Wed,
          5 Jun 2002 21:10:21 -0400
Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 5 Jun 2002 21:10:21 -0400
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for
          Digital Unix v1.1b) with SMTP id <0.0063A218@cherry.ease.lsoft.com>;
          Wed, 5 Jun 2002 21:10:21 -0400
Message-ID:  
Date:         Wed, 5 Jun 2002 21:10:21 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: Wu Jina 
Subject: Re: VIRTUAL LINK
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi,

About this question, I think the process like the following:

After all router is configured, R1, R2 and R3 will generate the router LSA
for all link at each router, except virtual link at R1 and R3, After the
database synchronize, R1, R2, R3 will generate the new router LSA for theirs
neighbor. At R1, when new router LSA is added to LSDB, the SPF will be
secheduled, then R1 will found R3 in the SPF process for the area 1.1.1.1,
then virtual link up, new router LSA will be generate include virtual link,
the next time, when the SPF is process, R1 will found R3 at area 0.0.0.0.
R3 is same.

Jina.

==========================================================================
HI All,
      acoording to RFC 2328 to calculate the next hop..

If the destination is a router connected to the calculating router
via a virtual link, the setting of the next hop should be       deferred
until the calculation in Section 16.3.
but section 16.3 doesn't say anything regarding this.

my topology is

    0.0.0.0             1.1.1.1              2.2.2.2
   -----------R1-----------R2------------R3------

at every interface ospf is enabled
i configured a virtual link between R1 and R3
area 1.1.1.1 is transit area

should at R1's Routing table it have a routing entry to ABR R3 in
Backbone Area ???
as far as routing table at R1 for transit area it have a routing
entry for ABR R3 with next hop R2 Interface connected to R1 and i
feel it's correct ???

my question is while calculating Routing table at R1 for backbone
area should we have a routing entry for ABR R3
and if yes then how to calculate next hop and where to
calculate.

Regards
Manish Gupta


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Jun  6 06:00:55 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04057
	for ; Thu, 6 Jun 2002 06:00:55 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0063AFCC@cherry.ease.lsoft.com>; Thu, 6 Jun 2002 6:01:21 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 1657 for OSPF@DISCUSS.MICROSOFT.COM; Thu,
          6 Jun 2002 06:01:20 -0400
Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 6 Jun 2002 06:01:20 -0400
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for
          Digital Unix v1.1b) with SMTP id <18.0063AF19@cherry.ease.lsoft.com>;
          Thu, 6 Jun 2002 6:01:21 -0400
Message-ID:  
Date:         Thu, 6 Jun 2002 06:01:20 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: Wu Jina 
Subject: Increate update for the OSPF for IPV6.
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hello, everyone:

Recently, I am studying the RFC2740, I have one question:

Now, router LSA already is split two part: router lsa and intra area prefix
lsa, sometime router lsa is not changed when the intra area prefix lsa is
changed, this condition, I think it is not necessary that the whole SPF is
schedule, we only need consider the prefix for the network N, intra area
prefix lsa, inter area prefix lsa or as external lsa will be considered.

I don't know if it is possible, can someone help me?

Thanks
Rahul.


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Jun  6 08:08:27 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09133
	for ; Thu, 6 Jun 2002 08:08:27 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0063B58C@cherry.ease.lsoft.com>; Thu, 6 Jun 2002 8:08:56 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 2392 for OSPF@DISCUSS.MICROSOFT.COM; Thu,
          6 Jun 2002 08:08:55 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 6 Jun 2002 08:08:54 -0400
Received: from redback.com (login002.redback.com [155.53.12.54]) by
          prattle.redback.com (Postfix) with ESMTP id F34E72CDB42 for
          ; Thu,  6 Jun 2002 05:08:53 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <20020605064033.29155.qmail@webmail20.rediffmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3CFF509C.5050106@redback.com>
Date:         Thu, 6 Jun 2002 08:07:56 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: Acee Lindem 
Subject: Re: VIRTUAL LINK
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Section 16.3 pertains to summary LSAs that may have a shorter
path via the transit area. For a virtual link to be in P2P state
it must have an intra-area route through the transit area. The
next-hop for this route will be your R3 next-hop (unless you have
a lower cost area 0 intra-area path to R3).

manish gupta wrote:
> HI All,
>      acoording to RFC 2328 to calculate the next hop..
>
> If the destination is a router connected to the calculating router
> via a virtual link, the setting of the next hop should be       deferred
> until the calculation in Section 16.3.
> but section 16.3 doesn't say anything regarding this.
>
> my topology is
>
>    0.0.0.0             1.1.1.1              2.2.2.2
>   -----------R1-----------R2------------R3------
>
> at every interface ospf is enabled
> i configured a virtual link between R1 and R3
> area 1.1.1.1 is transit area
>
> should at R1's Routing table it have a routing entry to ABR R3 in
> Backbone Area ???
> as far as routing table at R1 for transit area it have a routing
> entry for ABR R3 with next hop R2 Interface connected to R1 and i
> feel it's correct ???
>
> my question is while calculating Routing table at R1 for backbone
> area should we have a routing entry for ABR R3
> and if yes then how to calculate next hop and where to
> calculate.
>
> Regards
> Manish Gupta
>
>
>
>
>
>
>
>
>
>
> _________________________________________________________
> Click below to visit monsterindia.com and review jobs in India or
> Abroad
> http://monsterindia.rediff.com/jobs
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Jun  6 10:21:10 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14972
	for ; Thu, 6 Jun 2002 10:21:10 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0063B781@cherry.ease.lsoft.com>; Thu, 6 Jun 2002 10:21:40 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 2878 for OSPF@DISCUSS.MICROSOFT.COM; Thu,
          6 Jun 2002 10:21:40 -0400
Received: from 203.178.142.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Thu, 6 Jun 2002 10:21:39 -0400
Received: from localhost (page.sfc.wide.ad.jp [203.178.143.89]) by
          shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 148A55D0BD; Thu,  6 Jun
          2002 23:21:38 +0900 (JST)
References: 
X-Mailer: Mew version 2.1 on XEmacs 21.1.14 (Cuyahoga Valley)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <20020606.231501.100288892.yasu@sfc.wide.ad.jp>
Date:         Thu, 6 Jun 2002 23:15:01 +0900
Reply-To: Mailing List 
Sender: Mailing List 
From: Yasuhiro Ohara 
Subject: Re: Increate update for the OSPF for IPV6.
Comments: To: jinawucn@YAHOO.COM.CN
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  
Precedence: list
Content-Transfer-Encoding: 7bit

Agree. I think it's possible.

        yasu

jinawucn> Hello, everyone:
jinawucn>
jinawucn> Recently, I am studying the RFC2740, I have one question:
jinawucn>
jinawucn> Now, router LSA already is split two part: router lsa and intra area prefix
jinawucn> lsa, sometime router lsa is not changed when the intra area prefix lsa is
jinawucn> changed, this condition, I think it is not necessary that the whole SPF is
jinawucn> schedule, we only need consider the prefix for the network N, intra area
jinawucn> prefix lsa, inter area prefix lsa or as external lsa will be considered.
jinawucn>
jinawucn> I don't know if it is possible, can someone help me?
jinawucn>
jinawucn> Thanks
jinawucn> Rahul.


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Jun  6 18:56:57 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05579
	for ; Thu, 6 Jun 2002 18:56:57 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0063BD62@cherry.ease.lsoft.com>; Thu, 6 Jun 2002 14:27:26 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 4054 for OSPF@DISCUSS.MICROSOFT.COM; Thu,
          6 Jun 2002 14:27:26 -0400
Received: from 207.217.120.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Thu, 6 Jun 2002 14:27:26 -0400
Received: from 209-239-207-139.oak.jps.net ([209.239.207.139]
          helo=earthlink.net) by snipe.prod.itd.earthlink.net with esmtp (Exim
          3.33 #2) id 17G1yi-0006eD-00 for ospf@discuss.microsoft.com; Thu, 06
          Jun 2002 11:27:20 -0700
X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified)
X-Mailer: Mozilla 4.72 [en]C-gatewaynet  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3CFFABBC.77AF468@earthlink.net>
Date:         Thu, 6 Jun 2002 11:36:44 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Erblichs 
Subject: draft-bmwg-ospfconv-term-00.:P2P Converge Time
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Group,

        I have a few items that I don't necessarily agree
        with here, but the one item that I feel most
        strongly with is..

        5. Definition
        Point-to-Point links
        Discussion      "will take lesser time to converge than
                        a broadcast link"

        Yes, I do agree that a DR election, mainly due to the
        initial wait time, can become a large part in the time
        to converge.

        Given that if point-to-point links are substituted for
        broadcast links, I feel that the above statement becomes
        false..

        Note: adjacencies = adjs

        Why,,

        The fewer number of adjs
        allows a fewer number of database description packets to
        be exchanged, a fewer number of master/slave negotiations,
        etc. As each additional adj is formed, there is a higher
         probability that additional SPF calculations will need
        to be performed.

        In addition, additional flooding due to additional adjs
        will slow the converge process. Also with the additional
        load, the router may identify a overload condition, and
        even temporally reject some of these point-to-point adj
        formations..

        I am unsure whether a single slow router to inform the
        DR or BDR of its links vs informing all of the adjs of
        its links, will adversely effect the MA vs the P2P link
        topology more. In my mind there are just too many variables.

        In addition, the statement does not implicitly or explicitly
        imply whether the routing topology has changed and thus
        the BDR is being elected as the DR.

        THUS, I would consider a different wording to be on the
        order of ... (Please note that I have not mentioned
        Ethernet (shared-meda) type links where collisions with
        exponential backoff may play a role OR....) To keep it
        simple.

        A point-to-point link network topology makes the tradeoff
        of additional adjacencies formations vs the overhead of
        the required multi-access DR/ BDR election. Given a small
        number of adjacencies in a point-to-point environment, it
        can be more efficent than a multi-access topology if the
        links between the DR and DRothers are constantly changing
        OR that the election wait-time requirement is a large
        part of the convergence time.

        Thanks,
                Mitchell Erblich


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Jun 10 09:54:08 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04381
	for ; Mon, 10 Jun 2002 09:54:07 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00642545@cherry.ease.lsoft.com>; Mon, 10 Jun 2002 9:54:40 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 19645 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 10 Jun 2002 09:54:39 -0400
Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Mon, 10 Jun 2002 09:54:39 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id ; Mon, 10 Jun 2002 09:50:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  
Date:         Mon, 10 Jun 2002 08:17:45 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: "Manral, Vishwas" 
Subject: Re: draft-bmwg-ospfconv-term-00.:P2P Converge Time
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi Mitchell,

Apologies for the delayed reply(I have been away from my mail for some time
now) and thanks for the comment.

I guess the point you are trying to make is that although the DR election
itself could cause a delay in the broadcast case, there are certain other
factors involved.

However in the context of the discussion, what we have tried to say is that
all other things being the same(as we have put it as "of the same speed"),
because on a broadcast network if routers were comming up symultaneously
they would have to wait for the Waiting interval before electing a DR, it
would take a longer time. Also the flooding takes place via the DR/BDR and
that causes additional delay. Maybe we will try and modify the text to make
the fact clearer.

Besides I would like to know of any other point you you would like to
comment on(not agree on) within the draft.

Thanks,
Vishwas

-----Original Message-----
From: Erblichs [mailto:erblichs@EARTHLINK.NET]
Sent: Friday, June 07, 2002 12:07 AM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: draft-bmwg-ospfconv-term-00.:P2P Converge Time


Group,

        I have a few items that I don't necessarily agree
        with here, but the one item that I feel most
        strongly with is..

        5. Definition
        Point-to-Point links
        Discussion      "will take lesser time to converge than
                        a broadcast link"

        Yes, I do agree that a DR election, mainly due to the
        initial wait time, can become a large part in the time
        to converge.

        Given that if point-to-point links are substituted for
        broadcast links, I feel that the above statement becomes
        false..

        Note: adjacencies = adjs

        Why,,

        The fewer number of adjs
        allows a fewer number of database description packets to
        be exchanged, a fewer number of master/slave negotiations,
        etc. As each additional adj is formed, there is a higher
         probability that additional SPF calculations will need
        to be performed.

        In addition, additional flooding due to additional adjs
        will slow the converge process. Also with the additional
        load, the router may identify a overload condition, and
        even temporally reject some of these point-to-point adj
        formations..

        I am unsure whether a single slow router to inform the
        DR or BDR of its links vs informing all of the adjs of
        its links, will adversely effect the MA vs the P2P link
        topology more. In my mind there are just too many variables.

        In addition, the statement does not implicitly or explicitly
        imply whether the routing topology has changed and thus
        the BDR is being elected as the DR.

        THUS, I would consider a different wording to be on the
        order of ... (Please note that I have not mentioned
        Ethernet (shared-meda) type links where collisions with
        exponential backoff may play a role OR....) To keep it
        simple.

        A point-to-point link network topology makes the tradeoff
        of additional adjacencies formations vs the overhead of
        the required multi-access DR/ BDR election. Given a small
        number of adjacencies in a point-to-point environment, it
        can be more efficent than a multi-access topology if the
        links between the DR and DRothers are constantly changing
        OR that the election wait-time requirement is a large
        part of the convergence time.

        Thanks,
                Mitchell Erblich


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Jun 10 15:19:14 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20574
	for ; Mon, 10 Jun 2002 15:19:13 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.006432F0@cherry.ease.lsoft.com>; Mon, 10 Jun 2002 15:19:47 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 21209 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 10 Jun 2002 15:19:47 -0400
Received: from 207.217.120.22 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Mon, 10 Jun 2002 15:19:47 -0400
Received: from user-2ivfjg4.dialup.mindspring.com ([165.247.206.4]
          helo=earthlink.net) by hawk.mail.pas.earthlink.net with esmtp (Exim
          3.33 #2) id 17HUhc-0000jS-00 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 10
          Jun 2002 12:19:44 -0700
X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified)
X-Mailer: Mozilla 4.72 [en]C-gatewaynet  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D04FE0F.4518A8E7@earthlink.net>
Date:         Mon, 10 Jun 2002 12:29:19 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Erblichs 
Subject: Re: draft-bmwg-ospfconv-term-00.:P2P Converge Time
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

A)

5. Definitions

 Hello Interval

"and point-to-point networks" -> and non-Demand Circuit point-to-point
networks.

OR

"and point-to-point networks". + Exceptions of some point-to-point
circuits are demand point to point circuits, which would be the
successful of hello supression negotiation..


On the assumption that RFC 1793 Hello suppression is employed.

B) 5. Definitions

Shortest Path First Time

ADD... Some implimentations may force a interval between
successive SPF calculations. If it exists, then this additional time
value should be subtracted from the total time.

C) Meaning of Convergence

I would suggest..

A network is termed converged at one point in time when all of the
following has occured.

* all adjacencies that are to be formed have proceeded to full
  state.
* all retransmission lists are empty
* all recieved update, req LSAs have been processed
* All MAXAGE LSAs within the link state databases have been removed
* the link state databases are synchronized, exceptions are opaque LSAs
* all routers within an area have completed their SPF calculations
  and have inserted the results into their respective routing tables


D) New item....

6.3 Types of Network Events

* SPF events / triggers

Time the various types of events/triggers that would cause a
SPF calculation to occur.

Mitchell Erblich
==========================



"Manral, Vishwas" wrote:
>
> Hi Mitchell,
>
> Apologies for the delayed reply(I have been away from my mail for some time
> now) and thanks for the comment.
>
> I guess the point you are trying to make is that although the DR election
> itself could cause a delay in the broadcast case, there are certain other
> factors involved.
>
> However in the context of the discussion, what we have tried to say is that
> all other things being the same(as we have put it as "of the same speed"),
> because on a broadcast network if routers were comming up symultaneously
> they would have to wait for the Waiting interval before electing a DR, it
> would take a longer time. Also the flooding takes place via the DR/BDR and
> that causes additional delay. Maybe we will try and modify the text to make
> the fact clearer.
>
> Besides I would like to know of any other point you you would like to
> comment on(not agree on) within the draft.
>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Erblichs [mailto:erblichs@EARTHLINK.NET]
> Sent: Friday, June 07, 2002 12:07 AM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: draft-bmwg-ospfconv-term-00.:P2P Converge Time
>
> Group,
>
>         I have a few items that I don't necessarily agree
>         with here, but the one item that I feel most
>         strongly with is..
>
>         5. Definition
>         Point-to-Point links
>         Discussion      "will take lesser time to converge than
>                         a broadcast link"
>
>         Yes, I do agree that a DR election, mainly due to the
>         initial wait time, can become a large part in the time
>         to converge.
>
>         Given that if point-to-point links are substituted for
>         broadcast links, I feel that the above statement becomes
>         false..
>
>         Note: adjacencies = adjs
>
>         Why,,
>
>         The fewer number of adjs
>         allows a fewer number of database description packets to
>         be exchanged, a fewer number of master/slave negotiations,
>         etc. As each additional adj is formed, there is a higher
>          probability that additional SPF calculations will need
>         to be performed.
>
>         In addition, additional flooding due to additional adjs
>         will slow the converge process. Also with the additional
>         load, the router may identify a overload condition, and
>         even temporally reject some of these point-to-point adj
>         formations..
>
>         I am unsure whether a single slow router to inform the
>         DR or BDR of its links vs informing all of the adjs of
>         its links, will adversely effect the MA vs the P2P link
>         topology more. In my mind there are just too many variables.
>
>         In addition, the statement does not implicitly or explicitly
>         imply whether the routing topology has changed and thus
>         the BDR is being elected as the DR.
>
>         THUS, I would consider a different wording to be on the
>         order of ... (Please note that I have not mentioned
>         Ethernet (shared-meda) type links where collisions with
>         exponential backoff may play a role OR....) To keep it
>         simple.
>
>         A point-to-point link network topology makes the tradeoff
>         of additional adjacencies formations vs the overhead of
>         the required multi-access DR/ BDR election. Given a small
>         number of adjacencies in a point-to-point environment, it
>         can be more efficent than a multi-access topology if the
>         links between the DR and DRothers are constantly changing
>         OR that the election wait-time requirement is a large
>         part of the convergence time.
>
>         Thanks,
>                 Mitchell Erblich


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Jun 11 01:19:13 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04819
	for ; Tue, 11 Jun 2002 01:19:13 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00646237@cherry.ease.lsoft.com>; Tue, 11 Jun 2002 1:19:45 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 23159 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 11 Jun 2002 01:19:46 -0400
Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Tue, 11 Jun 2002 01:19:46 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id ; Tue, 11 Jun 2002 01:15:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  
Date:         Tue, 11 Jun 2002 01:19:20 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: "Manral, Vishwas" 
Subject: Re: draft-bmwg-ospfconv-term-00.:P2P Converge Time
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi Mitchell,

Thanks for the comments. My comments are inline prefixed by a VM>.

-Vishwas

-----------------------------------------------------------
A)

5. Definitions

 Hello Interval

"and point-to-point networks" -> and non-Demand Circuit point-to-point
networks.

OR

"and point-to-point networks". + Exceptions of some point-to-point
circuits are demand point to point circuits, which would be the
successful of hello supression negotiation..


On the assumption that RFC 1793 Hello suppression is employed.
VM> I agree to your point. However I think its an overkill to put all the
special cases in a definition.

B) 5. Definitions

Shortest Path First Time

ADD... Some implimentations may force a interval between
successive SPF calculations. If it exists, then this additional time
value should be subtracted from the total time.
VM> If you check the methodology draft, we have taken care of this.

C) Meaning of Convergence

I would suggest..

A network is termed converged at one point in time when all of the
following has occured.

* all adjacencies that are to be formed have proceeded to full
  state.
* all retransmission lists are empty
* all recieved update, req LSAs have been processed
* All MAXAGE LSAs within the link state databases have been removed
* the link state databases are synchronized, exceptions are opaque LSAs
* all routers within an area have completed their SPF calculations
  and have inserted the results into their respective routing tables

VM> The definition of convergence that has been derived has come out after
atleast  40 mail exchanges on the bmwg list. I however do not agree to many
of the points you state above, like the one on retransmission lists(the same
LSDB may be on all the routers and they still may have LSA's on the
retransmit list), Maxage etc.

D) New item....

6.3 Types of Network Events

* SPF events / triggers

Time the various types of events/triggers that would cause a
SPF calculation to occur.
VM> I guess that is something we do not require in the draft at all. Network
events have been listed, as we have given the methodology to find time to
converge when the events occur.

Thanks again.



"Manral, Vishwas" wrote:
>
> Hi Mitchell,
>
> Apologies for the delayed reply(I have been away from my mail for some
time
> now) and thanks for the comment.
>
> I guess the point you are trying to make is that although the DR election
> itself could cause a delay in the broadcast case, there are certain other
> factors involved.
>
> However in the context of the discussion, what we have tried to say is
that
> all other things being the same(as we have put it as "of the same speed"),
> because on a broadcast network if routers were comming up symultaneously
> they would have to wait for the Waiting interval before electing a DR, it
> would take a longer time. Also the flooding takes place via the DR/BDR and
> that causes additional delay. Maybe we will try and modify the text to
make
> the fact clearer.
>
> Besides I would like to know of any other point you you would like to
> comment on(not agree on) within the draft.
>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Erblichs [mailto:erblichs@EARTHLINK.NET]
> Sent: Friday, June 07, 2002 12:07 AM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: draft-bmwg-ospfconv-term-00.:P2P Converge Time
>
> Group,
>
>         I have a few items that I don't necessarily agree
>         with here, but the one item that I feel most
>         strongly with is..
>
>         5. Definition
>         Point-to-Point links
>         Discussion      "will take lesser time to converge than
>                         a broadcast link"
>
>         Yes, I do agree that a DR election, mainly due to the
>         initial wait time, can become a large part in the time
>         to converge.
>
>         Given that if point-to-point links are substituted for
>         broadcast links, I feel that the above statement becomes
>         false..
>
>         Note: adjacencies = adjs
>
>         Why,,
>
>         The fewer number of adjs
>         allows a fewer number of database description packets to
>         be exchanged, a fewer number of master/slave negotiations,
>         etc. As each additional adj is formed, there is a higher
>          probability that additional SPF calculations will need
>         to be performed.
>
>         In addition, additional flooding due to additional adjs
>         will slow the converge process. Also with the additional
>         load, the router may identify a overload condition, and
>         even temporally reject some of these point-to-point adj
>         formations..
>
>         I am unsure whether a single slow router to inform the
>         DR or BDR of its links vs informing all of the adjs of
>         its links, will adversely effect the MA vs the P2P link
>         topology more. In my mind there are just too many variables.
>
>         In addition, the statement does not implicitly or explicitly
>         imply whether the routing topology has changed and thus
>         the BDR is being elected as the DR.
>
>         THUS, I would consider a different wording to be on the
>         order of ... (Please note that I have not mentioned
>         Ethernet (shared-meda) type links where collisions with
>         exponential backoff may play a role OR....) To keep it
>         simple.
>
>         A point-to-point link network topology makes the tradeoff
>         of additional adjacencies formations vs the overhead of
>         the required multi-access DR/ BDR election. Given a small
>         number of adjacencies in a point-to-point environment, it
>         can be more efficent than a multi-access topology if the
>         links between the DR and DRothers are constantly changing
>         OR that the election wait-time requirement is a large
>         part of the convergence time.
>
>         Thanks,
>                 Mitchell Erblich


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Jun 11 14:53:39 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08192
	for ; Tue, 11 Jun 2002 14:53:37 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00647EFF@cherry.ease.lsoft.com>; Tue, 11 Jun 2002 14:52:50 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 26897 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 11 Jun 2002 14:52:51 -0400
Received: from 207.217.120.50 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Tue, 11 Jun 2002 14:52:51 -0400
Received: from user-2ivfmqt.dialup.mindspring.com ([165.247.219.93]
          helo=earthlink.net) by avocet.mail.pas.earthlink.net with esmtp (Exim
          3.33 #2) id 17Hql5-0004Ry-00 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 11
          Jun 2002 11:52:47 -0700
X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified)
X-Mailer: Mozilla 4.72 [en]C-gatewaynet  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D064940.D50E1992@earthlink.net>
Date:         Tue, 11 Jun 2002 12:02:24 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Erblichs 
Subject: Re: draft-bmwg-ospfconv-term-00.:P2P Converge Time
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Vishwas,

        Most of the points here are what I call nits..

        However, the convergence item "C" is the most
        interesting one. You state that "the same LSDB may be on
        all the routers and they still may have LSA's on the
        retransmit list), Maxage etc."

        I consider convergence is when a level of stasis
        (a non-changing time is present). When LSA are on
        re-xmit lists, it needs to be assumed that one or
        more routers (IS's) may not have the LSA. They may
        have had it and it may have been aged out.

        As a implicit item in my statement, the item may
        be on the re-xmit list because the one or more
        other link-partners may have lost its link and
        the adjacency timer has not yet fired.

        Thus, I was striving for a known state that we
        are in a state of stable non-changing conditions
        for at least a moment in time..

        I have seen non-loop free paths and all of the
        link state databases have identical LSAs. It was
        due to configuration errors and redistribution
        differences in a multi-protocol environment.

        Yes, it is a level of more complexity than as
        the wg's definition.. I have run into a number of
        people who disagree on really what is meant by
        convergence. I don't think it really has been
        stated with a precise definition. So, I was
        trying to nail it down here...

        Mitchell Erblich
        =================






"Manral, Vishwas" wrote:
>
> Hi Mitchell,
>
> Thanks for the comments. My comments are inline prefixed by a VM>.
>
> -Vishwas
>
> -----------------------------------------------------------
> A)
>
> 5. Definitions
>
>  Hello Interval
>
> "and point-to-point networks" -> and non-Demand Circuit point-to-point
> networks.
>
> OR
>
> "and point-to-point networks". + Exceptions of some point-to-point
> circuits are demand point to point circuits, which would be the
> successful of hello supression negotiation..
>
> On the assumption that RFC 1793 Hello suppression is employed.
> VM> I agree to your point. However I think its an overkill to put all the
> special cases in a definition.
>
> B) 5. Definitions
>
> Shortest Path First Time
>
> ADD... Some implimentations may force a interval between
> successive SPF calculations. If it exists, then this additional time
> value should be subtracted from the total time.
> VM> If you check the methodology draft, we have taken care of this.
>
> C) Meaning of Convergence
>
> I would suggest..
>
> A network is termed converged at one point in time when all of the
> following has occured.
>
> * all adjacencies that are to be formed have proceeded to full
>   state.
> * all retransmission lists are empty
> * all recieved update, req LSAs have been processed
> * All MAXAGE LSAs within the link state databases have been removed
> * the link state databases are synchronized, exceptions are opaque LSAs
> * all routers within an area have completed their SPF calculations
>   and have inserted the results into their respective routing tables
>
> VM> The definition of convergence that has been derived has come out after
> atleast  40 mail exchanges on the bmwg list. I however do not agree to many
> of the points you state above, like the one on retransmission lists(the same
> LSDB may be on all the routers and they still may have LSA's on the
> retransmit list), Maxage etc.
>
> D) New item....
>
> 6.3 Types of Network Events
>
> * SPF events / triggers
>
> Time the various types of events/triggers that would cause a
> SPF calculation to occur.
> VM> I guess that is something we do not require in the draft at all. Network
> events have been listed, as we have given the methodology to find time to
> converge when the events occur.
>
> Thanks again.
>
> "Manral, Vishwas" wrote:
> >
> > Hi Mitchell,
> >
> > Apologies for the delayed reply(I have been away from my mail for some
> time
> > now) and thanks for the comment.
> >
> > I guess the point you are trying to make is that although the DR election
> > itself could cause a delay in the broadcast case, there are certain other
> > factors involved.
> >
> > However in the context of the discussion, what we have tried to say is
> that
> > all other things being the same(as we have put it as "of the same speed"),
> > because on a broadcast network if routers were comming up symultaneously
> > they would have to wait for the Waiting interval before electing a DR, it
> > would take a longer time. Also the flooding takes place via the DR/BDR and
> > that causes additional delay. Maybe we will try and modify the text to
> make
> > the fact clearer.
> >
> > Besides I would like to know of any other point you you would like to
> > comment on(not agree on) within the draft.
> >
> > Thanks,
> > Vishwas
> >
> > -----Original Message-----
> > From: Erblichs [mailto:erblichs@EARTHLINK.NET]
> > Sent: Friday, June 07, 2002 12:07 AM
> > To: OSPF@DISCUSS.MICROSOFT.COM
> > Subject: draft-bmwg-ospfconv-term-00.:P2P Converge Time
> >
> > Group,
> >
> >         I have a few items that I don't necessarily agree
> >         with here, but the one item that I feel most
> >         strongly with is..
> >
> >         5. Definition
> >         Point-to-Point links
> >         Discussion      "will take lesser time to converge than
> >                         a broadcast link"
> >
> >         Yes, I do agree that a DR election, mainly due to the
> >         initial wait time, can become a large part in the time
> >         to converge.
> >
> >         Given that if point-to-point links are substituted for
> >         broadcast links, I feel that the above statement becomes
> >         false..
> >
> >         Note: adjacencies = adjs
> >
> >         Why,,
> >
> >         The fewer number of adjs
> >         allows a fewer number of database description packets to
> >         be exchanged, a fewer number of master/slave negotiations,
> >         etc. As each additional adj is formed, there is a higher
> >          probability that additional SPF calculations will need
> >         to be performed.
> >
> >         In addition, additional flooding due to additional adjs
> >         will slow the converge process. Also with the additional
> >         load, the router may identify a overload condition, and
> >         even temporally reject some of these point-to-point adj
> >         formations..
> >
> >         I am unsure whether a single slow router to inform the
> >         DR or BDR of its links vs informing all of the adjs of
> >         its links, will adversely effect the MA vs the P2P link
> >         topology more. In my mind there are just too many variables.
> >
> >         In addition, the statement does not implicitly or explicitly
> >         imply whether the routing topology has changed and thus
> >         the BDR is being elected as the DR.
> >
> >         THUS, I would consider a different wording to be on the
> >         order of ... (Please note that I have not mentioned
> >         Ethernet (shared-meda) type links where collisions with
> >         exponential backoff may play a role OR....) To keep it
> >         simple.
> >
> >         A point-to-point link network topology makes the tradeoff
> >         of additional adjacencies formations vs the overhead of
> >         the required multi-access DR/ BDR election. Given a small
> >         number of adjacencies in a point-to-point environment, it
> >         can be more efficent than a multi-access topology if the
> >         links between the DR and DRothers are constantly changing
> >         OR that the election wait-time requirement is a large
> >         part of the convergence time.
> >
> >         Thanks,
> >                 Mitchell Erblich


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Jun 12 00:59:37 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24443
	for ; Wed, 12 Jun 2002 00:59:37 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00649863@cherry.ease.lsoft.com>; Wed, 12 Jun 2002 1:00:09 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 28762 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 12 Jun 2002 01:00:09 -0400
Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 12 Jun 2002 01:00:09 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id ; Wed, 12 Jun 2002 00:55:39 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  
Date:         Wed, 12 Jun 2002 00:59:51 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: "Manral, Vishwas" 
Subject: Re: draft-bmwg-ospfconv-term-00.:P2P Converge Time
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi Mitchell,

Thanks for ur response.

If you read the methodology draft, you will observe that most of the tests
are like, how long it takes for a change to be propagated to other routers
and the SPF being calculated. The definition of convergence is given in the
context of this, as are all other definitions, where the LSA change does
cause a route change in the neighbor. I do understand ur point however.

I guess I agree we can change the definiton of convergence to better reflect
the what you say. We could have loop free paths even with different
databases and this may not be what we want to convey.

Thanks,
Vishwas

-----Original Message-----
From: Erblichs [mailto:erblichs@EARTHLINK.NET]
Sent: Wednesday, June 12, 2002 12:32 AM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: draft-bmwg-ospfconv-term-00.:P2P Converge Time


Vishwas,

        Most of the points here are what I call nits..

        However, the convergence item "C" is the most
        interesting one. You state that "the same LSDB may be on
        all the routers and they still may have LSA's on the
        retransmit list), Maxage etc."

        I consider convergence is when a level of stasis
        (a non-changing time is present). When LSA are on
        re-xmit lists, it needs to be assumed that one or
        more routers (IS's) may not have the LSA. They may
        have had it and it may have been aged out.

        As a implicit item in my statement, the item may
        be on the re-xmit list because the one or more
        other link-partners may have lost its link and
        the adjacency timer has not yet fired.

        Thus, I was striving for a known state that we
        are in a state of stable non-changing conditions
        for at least a moment in time..

        I have seen non-loop free paths and all of the
        link state databases have identical LSAs. It was
        due to configuration errors and redistribution
        differences in a multi-protocol environment.

        Yes, it is a level of more complexity than as
        the wg's definition.. I have run into a number of
        people who disagree on really what is meant by
        convergence. I don't think it really has been
        stated with a precise definition. So, I was
        trying to nail it down here...

        Mitchell Erblich
        =================






"Manral, Vishwas" wrote:
>
> Hi Mitchell,
>
> Thanks for the comments. My comments are inline prefixed by a VM>.
>
> -Vishwas
>
> -----------------------------------------------------------
> A)
>
> 5. Definitions
>
>  Hello Interval
>
> "and point-to-point networks" -> and non-Demand Circuit point-to-point
> networks.
>
> OR
>
> "and point-to-point networks". + Exceptions of some point-to-point
> circuits are demand point to point circuits, which would be the
> successful of hello supression negotiation..
>
> On the assumption that RFC 1793 Hello suppression is employed.
> VM> I agree to your point. However I think its an overkill to put all the
> special cases in a definition.
>
> B) 5. Definitions
>
> Shortest Path First Time
>
> ADD... Some implimentations may force a interval between
> successive SPF calculations. If it exists, then this additional time
> value should be subtracted from the total time.
> VM> If you check the methodology draft, we have taken care of this.
>
> C) Meaning of Convergence
>
> I would suggest..
>
> A network is termed converged at one point in time when all of the
> following has occured.
>
> * all adjacencies that are to be formed have proceeded to full
>   state.
> * all retransmission lists are empty
> * all recieved update, req LSAs have been processed
> * All MAXAGE LSAs within the link state databases have been removed
> * the link state databases are synchronized, exceptions are opaque LSAs
> * all routers within an area have completed their SPF calculations
>   and have inserted the results into their respective routing tables
>
> VM> The definition of convergence that has been derived has come out after
> atleast  40 mail exchanges on the bmwg list. I however do not agree to
many
> of the points you state above, like the one on retransmission lists(the
same
> LSDB may be on all the routers and they still may have LSA's on the
> retransmit list), Maxage etc.
>
> D) New item....
>
> 6.3 Types of Network Events
>
> * SPF events / triggers
>
> Time the various types of events/triggers that would cause a
> SPF calculation to occur.
> VM> I guess that is something we do not require in the draft at all.
Network
> events have been listed, as we have given the methodology to find time to
> converge when the events occur.
>
> Thanks again.
>
> "Manral, Vishwas" wrote:
> >
> > Hi Mitchell,
> >
> > Apologies for the delayed reply(I have been away from my mail for some
> time
> > now) and thanks for the comment.
> >
> > I guess the point you are trying to make is that although the DR
election
> > itself could cause a delay in the broadcast case, there are certain
other
> > factors involved.
> >
> > However in the context of the discussion, what we have tried to say is
> that
> > all other things being the same(as we have put it as "of the same
speed"),
> > because on a broadcast network if routers were comming up symultaneously
> > they would have to wait for the Waiting interval before electing a DR,
it
> > would take a longer time. Also the flooding takes place via the DR/BDR
and
> > that causes additional delay. Maybe we will try and modify the text to
> make
> > the fact clearer.
> >
> > Besides I would like to know of any other point you you would like to
> > comment on(not agree on) within the draft.
> >
> > Thanks,
> > Vishwas
> >
> > -----Original Message-----
> > From: Erblichs [mailto:erblichs@EARTHLINK.NET]
> > Sent: Friday, June 07, 2002 12:07 AM
> > To: OSPF@DISCUSS.MICROSOFT.COM
> > Subject: draft-bmwg-ospfconv-term-00.:P2P Converge Time
> >
> > Group,
> >
> >         I have a few items that I don't necessarily agree
> >         with here, but the one item that I feel most
> >         strongly with is..
> >
> >         5. Definition
> >         Point-to-Point links
> >         Discussion      "will take lesser time to converge than
> >                         a broadcast link"
> >
> >         Yes, I do agree that a DR election, mainly due to the
> >         initial wait time, can become a large part in the time
> >         to converge.
> >
> >         Given that if point-to-point links are substituted for
> >         broadcast links, I feel that the above statement becomes
> >         false..
> >
> >         Note: adjacencies = adjs
> >
> >         Why,,
> >
> >         The fewer number of adjs
> >         allows a fewer number of database description packets to
> >         be exchanged, a fewer number of master/slave negotiations,
> >         etc. As each additional adj is formed, there is a higher
> >          probability that additional SPF calculations will need
> >         to be performed.
> >
> >         In addition, additional flooding due to additional adjs
> >         will slow the converge process. Also with the additional
> >         load, the router may identify a overload condition, and
> >         even temporally reject some of these point-to-point adj
> >         formations..
> >
> >         I am unsure whether a single slow router to inform the
> >         DR or BDR of its links vs informing all of the adjs of
> >         its links, will adversely effect the MA vs the P2P link
> >         topology more. In my mind there are just too many variables.
> >
> >         In addition, the statement does not implicitly or explicitly
> >         imply whether the routing topology has changed and thus
> >         the BDR is being elected as the DR.
> >
> >         THUS, I would consider a different wording to be on the
> >         order of ... (Please note that I have not mentioned
> >         Ethernet (shared-meda) type links where collisions with
> >         exponential backoff may play a role OR....) To keep it
> >         simple.
> >
> >         A point-to-point link network topology makes the tradeoff
> >         of additional adjacencies formations vs the overhead of
> >         the required multi-access DR/ BDR election. Given a small
> >         number of adjacencies in a point-to-point environment, it
> >         can be more efficent than a multi-access topology if the
> >         links between the DR and DRothers are constantly changing
> >         OR that the election wait-time requirement is a large
> >         part of the convergence time.
> >
> >         Thanks,
> >                 Mitchell Erblich


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Jun 12 07:56:11 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23932
	for ; Wed, 12 Jun 2002 07:56:10 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00649EE4@cherry.ease.lsoft.com>; Wed, 12 Jun 2002 7:56:43 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 31596 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 12 Jun 2002 07:56:44 -0400
Received: from 204.147.80.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 12 Jun 2002 07:46:44 -0400
Received: (qmail 78678 invoked from network); 12 Jun 2002 11:46:41 -0000
Received: from unknown (HELO KasiViswanath) (61.11.55.197) by
          mplspop6.mpls.uswest.net with SMTP; 12 Jun 2002 11:46:41 -0000
References:  
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Message-ID:  <007201c21206$959d1a40$0401a8c0@KasiViswanath>
Date:         Wed, 12 Jun 2002 17:14:49 +0530
Reply-To: Mailing List 
Sender: Mailing List 
From: Kasi Viswanath 
Subject: Re: draft-bmwg-ospfconv-term-00.:P2P Converge Time
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi all

I'm new to this mailing list,
and I'm doing ospf implementation as my academic project
and I have lots of doubts to clarify.
Is there any format or rules to ask question?

TIA

with regards
kasi viswanath.N.J



----- Original Message -----
From: "Manral, Vishwas" 
To: 
Sent: Wednesday, June 12, 2002 10:29 AM
Subject: Re: draft-bmwg-ospfconv-term-00.:P2P Converge Time


> Hi Mitchell,
>
> Thanks for ur response.
>
> If you read the methodology draft, you will observe that most of the tests
> are like, how long it takes for a change to be propagated to other routers
> and the SPF being calculated. The definition of convergence is given in
the
> context of this, as are all other definitions, where the LSA change does
> cause a route change in the neighbor. I do understand ur point however.
>
> I guess I agree we can change the definiton of convergence to better
reflect
> the what you say. We could have loop free paths even with different
> databases and this may not be what we want to convey.
>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Erblichs [mailto:erblichs@EARTHLINK.NET]
> Sent: Wednesday, June 12, 2002 12:32 AM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Re: draft-bmwg-ospfconv-term-00.:P2P Converge Time
>
>
> Vishwas,
>
>         Most of the points here are what I call nits..
>
>         However, the convergence item "C" is the most
>         interesting one. You state that "the same LSDB may be on
>         all the routers and they still may have LSA's on the
>         retransmit list), Maxage etc."
>
>         I consider convergence is when a level of stasis
>         (a non-changing time is present). When LSA are on
>         re-xmit lists, it needs to be assumed that one or
>         more routers (IS's) may not have the LSA. They may
>         have had it and it may have been aged out.
>
>         As a implicit item in my statement, the item may
>         be on the re-xmit list because the one or more
>         other link-partners may have lost its link and
>         the adjacency timer has not yet fired.
>
>         Thus, I was striving for a known state that we
>         are in a state of stable non-changing conditions
>         for at least a moment in time..
>
>         I have seen non-loop free paths and all of the
>         link state databases have identical LSAs. It was
>         due to configuration errors and redistribution
>         differences in a multi-protocol environment.
>
>         Yes, it is a level of more complexity than as
>         the wg's definition.. I have run into a number of
>         people who disagree on really what is meant by
>         convergence. I don't think it really has been
>         stated with a precise definition. So, I was
>         trying to nail it down here...
>
>         Mitchell Erblich
>         =================
>
>
>
>
>
>
> "Manral, Vishwas" wrote:
> >
> > Hi Mitchell,
> >
> > Thanks for the comments. My comments are inline prefixed by a VM>.
> >
> > -Vishwas
> >
> > -----------------------------------------------------------
> > A)
> >
> > 5. Definitions
> >
> >  Hello Interval
> >
> > "and point-to-point networks" -> and non-Demand Circuit point-to-point
> > networks.
> >
> > OR
> >
> > "and point-to-point networks". + Exceptions of some point-to-point
> > circuits are demand point to point circuits, which would be the
> > successful of hello supression negotiation..
> >
> > On the assumption that RFC 1793 Hello suppression is employed.
> > VM> I agree to your point. However I think its an overkill to put all
the
> > special cases in a definition.
> >
> > B) 5. Definitions
> >
> > Shortest Path First Time
> >
> > ADD... Some implimentations may force a interval between
> > successive SPF calculations. If it exists, then this additional time
> > value should be subtracted from the total time.
> > VM> If you check the methodology draft, we have taken care of this.
> >
> > C) Meaning of Convergence
> >
> > I would suggest..
> >
> > A network is termed converged at one point in time when all of the
> > following has occured.
> >
> > * all adjacencies that are to be formed have proceeded to full
> >   state.
> > * all retransmission lists are empty
> > * all recieved update, req LSAs have been processed
> > * All MAXAGE LSAs within the link state databases have been removed
> > * the link state databases are synchronized, exceptions are opaque LSAs
> > * all routers within an area have completed their SPF calculations
> >   and have inserted the results into their respective routing tables
> >
> > VM> The definition of convergence that has been derived has come out
after
> > atleast  40 mail exchanges on the bmwg list. I however do not agree to
> many
> > of the points you state above, like the one on retransmission lists(the
> same
> > LSDB may be on all the routers and they still may have LSA's on the
> > retransmit list), Maxage etc.
> >
> > D) New item....
> >
> > 6.3 Types of Network Events
> >
> > * SPF events / triggers
> >
> > Time the various types of events/triggers that would cause a
> > SPF calculation to occur.
> > VM> I guess that is something we do not require in the draft at all.
> Network
> > events have been listed, as we have given the methodology to find time
to
> > converge when the events occur.
> >
> > Thanks again.
> >
> > "Manral, Vishwas" wrote:
> > >
> > > Hi Mitchell,
> > >
> > > Apologies for the delayed reply(I have been away from my mail for some
> > time
> > > now) and thanks for the comment.
> > >
> > > I guess the point you are trying to make is that although the DR
> election
> > > itself could cause a delay in the broadcast case, there are certain
> other
> > > factors involved.
> > >
> > > However in the context of the discussion, what we have tried to say is
> > that
> > > all other things being the same(as we have put it as "of the same
> speed"),
> > > because on a broadcast network if routers were comming up
symultaneously
> > > they would have to wait for the Waiting interval before electing a DR,
> it
> > > would take a longer time. Also the flooding takes place via the DR/BDR
> and
> > > that causes additional delay. Maybe we will try and modify the text to
> > make
> > > the fact clearer.
> > >
> > > Besides I would like to know of any other point you you would like to
> > > comment on(not agree on) within the draft.
> > >
> > > Thanks,
> > > Vishwas
> > >
> > > -----Original Message-----
> > > From: Erblichs [mailto:erblichs@EARTHLINK.NET]
> > > Sent: Friday, June 07, 2002 12:07 AM
> > > To: OSPF@DISCUSS.MICROSOFT.COM
> > > Subject: draft-bmwg-ospfconv-term-00.:P2P Converge Time
> > >
> > > Group,
> > >
> > >         I have a few items that I don't necessarily agree
> > >         with here, but the one item that I feel most
> > >         strongly with is..
> > >
> > >         5. Definition
> > >         Point-to-Point links
> > >         Discussion      "will take lesser time to converge than
> > >                         a broadcast link"
> > >
> > >         Yes, I do agree that a DR election, mainly due to the
> > >         initial wait time, can become a large part in the time
> > >         to converge.
> > >
> > >         Given that if point-to-point links are substituted for
> > >         broadcast links, I feel that the above statement becomes
> > >         false..
> > >
> > >         Note: adjacencies = adjs
> > >
> > >         Why,,
> > >
> > >         The fewer number of adjs
> > >         allows a fewer number of database description packets to
> > >         be exchanged, a fewer number of master/slave negotiations,
> > >         etc. As each additional adj is formed, there is a higher
> > >          probability that additional SPF calculations will need
> > >         to be performed.
> > >
> > >         In addition, additional flooding due to additional adjs
> > >         will slow the converge process. Also with the additional
> > >         load, the router may identify a overload condition, and
> > >         even temporally reject some of these point-to-point adj
> > >         formations..
> > >
> > >         I am unsure whether a single slow router to inform the
> > >         DR or BDR of its links vs informing all of the adjs of
> > >         its links, will adversely effect the MA vs the P2P link
> > >         topology more. In my mind there are just too many variables.
> > >
> > >         In addition, the statement does not implicitly or explicitly
> > >         imply whether the routing topology has changed and thus
> > >         the BDR is being elected as the DR.
> > >
> > >         THUS, I would consider a different wording to be on the
> > >         order of ... (Please note that I have not mentioned
> > >         Ethernet (shared-meda) type links where collisions with
> > >         exponential backoff may play a role OR....) To keep it
> > >         simple.
> > >
> > >         A point-to-point link network topology makes the tradeoff
> > >         of additional adjacencies formations vs the overhead of
> > >         the required multi-access DR/ BDR election. Given a small
> > >         number of adjacencies in a point-to-point environment, it
> > >         can be more efficent than a multi-access topology if the
> > >         links between the DR and DRothers are constantly changing
> > >         OR that the election wait-time requirement is a large
> > >         part of the convergence time.
> > >
> > >         Thanks,
> > >                 Mitchell Erblich
>


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Jun 12 08:01:31 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24117
	for ; Wed, 12 Jun 2002 08:01:30 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00649F3B@cherry.ease.lsoft.com>; Wed, 12 Jun 2002 8:02:04 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 31747 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 12 Jun 2002 08:02:05 -0400
Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 12 Jun 2002 08:02:04 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id ; Wed, 12 Jun 2002 07:57:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  
Date:         Wed, 12 Jun 2002 08:01:44 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: "Manral, Vishwas" 
Subject: Re: draft-bmwg-ospfconv-term-00.:P2P Converge Time
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi Kasi,

I guess there are no rules I know of, however you could always check the
archives located at
http://discuss.microsoft.com/archives/ospf.html for basic question/doubts as
most of them have been asked earlier.

Thanks,
Vishwas

-----Original Message-----
From: Kasi Viswanath [mailto:kasin@SDKSOFT.COM]
Sent: Wednesday, June 12, 2002 5:15 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: draft-bmwg-ospfconv-term-00.:P2P Converge Time


Hi all

I'm new to this mailing list,
and I'm doing ospf implementation as my academic project
and I have lots of doubts to clarify.
Is there any format or rules to ask question?

TIA

with regards
kasi viswanath.N.J



----- Original Message -----
From: "Manral, Vishwas" 
To: 
Sent: Wednesday, June 12, 2002 10:29 AM
Subject: Re: draft-bmwg-ospfconv-term-00.:P2P Converge Time


> Hi Mitchell,
>
> Thanks for ur response.
>
> If you read the methodology draft, you will observe that most of the tests
> are like, how long it takes for a change to be propagated to other routers
> and the SPF being calculated. The definition of convergence is given in
the
> context of this, as are all other definitions, where the LSA change does
> cause a route change in the neighbor. I do understand ur point however.
>
> I guess I agree we can change the definiton of convergence to better
reflect
> the what you say. We could have loop free paths even with different
> databases and this may not be what we want to convey.
>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Erblichs [mailto:erblichs@EARTHLINK.NET]
> Sent: Wednesday, June 12, 2002 12:32 AM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Re: draft-bmwg-ospfconv-term-00.:P2P Converge Time
>
>
> Vishwas,
>
>         Most of the points here are what I call nits..
>
>         However, the convergence item "C" is the most
>         interesting one. You state that "the same LSDB may be on
>         all the routers and they still may have LSA's on the
>         retransmit list), Maxage etc."
>
>         I consider convergence is when a level of stasis
>         (a non-changing time is present). When LSA are on
>         re-xmit lists, it needs to be assumed that one or
>         more routers (IS's) may not have the LSA. They may
>         have had it and it may have been aged out.
>
>         As a implicit item in my statement, the item may
>         be on the re-xmit list because the one or more
>         other link-partners may have lost its link and
>         the adjacency timer has not yet fired.
>
>         Thus, I was striving for a known state that we
>         are in a state of stable non-changing conditions
>         for at least a moment in time..
>
>         I have seen non-loop free paths and all of the
>         link state databases have identical LSAs. It was
>         due to configuration errors and redistribution
>         differences in a multi-protocol environment.
>
>         Yes, it is a level of more complexity than as
>         the wg's definition.. I have run into a number of
>         people who disagree on really what is meant by
>         convergence. I don't think it really has been
>         stated with a precise definition. So, I was
>         trying to nail it down here...
>
>         Mitchell Erblich
>         =================
>
>
>
>
>
>
> "Manral, Vishwas" wrote:
> >
> > Hi Mitchell,
> >
> > Thanks for the comments. My comments are inline prefixed by a VM>.
> >
> > -Vishwas
> >
> > -----------------------------------------------------------
> > A)
> >
> > 5. Definitions
> >
> >  Hello Interval
> >
> > "and point-to-point networks" -> and non-Demand Circuit point-to-point
> > networks.
> >
> > OR
> >
> > "and point-to-point networks". + Exceptions of some point-to-point
> > circuits are demand point to point circuits, which would be the
> > successful of hello supression negotiation..
> >
> > On the assumption that RFC 1793 Hello suppression is employed.
> > VM> I agree to your point. However I think its an overkill to put all
the
> > special cases in a definition.
> >
> > B) 5. Definitions
> >
> > Shortest Path First Time
> >
> > ADD... Some implimentations may force a interval between
> > successive SPF calculations. If it exists, then this additional time
> > value should be subtracted from the total time.
> > VM> If you check the methodology draft, we have taken care of this.
> >
> > C) Meaning of Convergence
> >
> > I would suggest..
> >
> > A network is termed converged at one point in time when all of the
> > following has occured.
> >
> > * all adjacencies that are to be formed have proceeded to full
> >   state.
> > * all retransmission lists are empty
> > * all recieved update, req LSAs have been processed
> > * All MAXAGE LSAs within the link state databases have been removed
> > * the link state databases are synchronized, exceptions are opaque LSAs
> > * all routers within an area have completed their SPF calculations
> >   and have inserted the results into their respective routing tables
> >
> > VM> The definition of convergence that has been derived has come out
after
> > atleast  40 mail exchanges on the bmwg list. I however do not agree to
> many
> > of the points you state above, like the one on retransmission lists(the
> same
> > LSDB may be on all the routers and they still may have LSA's on the
> > retransmit list), Maxage etc.
> >
> > D) New item....
> >
> > 6.3 Types of Network Events
> >
> > * SPF events / triggers
> >
> > Time the various types of events/triggers that would cause a
> > SPF calculation to occur.
> > VM> I guess that is something we do not require in the draft at all.
> Network
> > events have been listed, as we have given the methodology to find time
to
> > converge when the events occur.
> >
> > Thanks again.
> >
> > "Manral, Vishwas" wrote:
> > >
> > > Hi Mitchell,
> > >
> > > Apologies for the delayed reply(I have been away from my mail for some
> > time
> > > now) and thanks for the comment.
> > >
> > > I guess the point you are trying to make is that although the DR
> election
> > > itself could cause a delay in the broadcast case, there are certain
> other
> > > factors involved.
> > >
> > > However in the context of the discussion, what we have tried to say is
> > that
> > > all other things being the same(as we have put it as "of the same
> speed"),
> > > because on a broadcast network if routers were comming up
symultaneously
> > > they would have to wait for the Waiting interval before electing a DR,
> it
> > > would take a longer time. Also the flooding takes place via the DR/BDR
> and
> > > that causes additional delay. Maybe we will try and modify the text to
> > make
> > > the fact clearer.
> > >
> > > Besides I would like to know of any other point you you would like to
> > > comment on(not agree on) within the draft.
> > >
> > > Thanks,
> > > Vishwas
> > >
> > > -----Original Message-----
> > > From: Erblichs [mailto:erblichs@EARTHLINK.NET]
> > > Sent: Friday, June 07, 2002 12:07 AM
> > > To: OSPF@DISCUSS.MICROSOFT.COM
> > > Subject: draft-bmwg-ospfconv-term-00.:P2P Converge Time
> > >
> > > Group,
> > >
> > >         I have a few items that I don't necessarily agree
> > >         with here, but the one item that I feel most
> > >         strongly with is..
> > >
> > >         5. Definition
> > >         Point-to-Point links
> > >         Discussion      "will take lesser time to converge than
> > >                         a broadcast link"
> > >
> > >         Yes, I do agree that a DR election, mainly due to the
> > >         initial wait time, can become a large part in the time
> > >         to converge.
> > >
> > >         Given that if point-to-point links are substituted for
> > >         broadcast links, I feel that the above statement becomes
> > >         false..
> > >
> > >         Note: adjacencies = adjs
> > >
> > >         Why,,
> > >
> > >         The fewer number of adjs
> > >         allows a fewer number of database description packets to
> > >         be exchanged, a fewer number of master/slave negotiations,
> > >         etc. As each additional adj is formed, there is a higher
> > >          probability that additional SPF calculations will need
> > >         to be performed.
> > >
> > >         In addition, additional flooding due to additional adjs
> > >         will slow the converge process. Also with the additional
> > >         load, the router may identify a overload condition, and
> > >         even temporally reject some of these point-to-point adj
> > >         formations..
> > >
> > >         I am unsure whether a single slow router to inform the
> > >         DR or BDR of its links vs informing all of the adjs of
> > >         its links, will adversely effect the MA vs the P2P link
> > >         topology more. In my mind there are just too many variables.
> > >
> > >         In addition, the statement does not implicitly or explicitly
> > >         imply whether the routing topology has changed and thus
> > >         the BDR is being elected as the DR.
> > >
> > >         THUS, I would consider a different wording to be on the
> > >         order of ... (Please note that I have not mentioned
> > >         Ethernet (shared-meda) type links where collisions with
> > >         exponential backoff may play a role OR....) To keep it
> > >         simple.
> > >
> > >         A point-to-point link network topology makes the tradeoff
> > >         of additional adjacencies formations vs the overhead of
> > >         the required multi-access DR/ BDR election. Given a small
> > >         number of adjacencies in a point-to-point environment, it
> > >         can be more efficent than a multi-access topology if the
> > >         links between the DR and DRothers are constantly changing
> > >         OR that the election wait-time requirement is a large
> > >         part of the convergence time.
> > >
> > >         Thanks,
> > >                 Mitchell Erblich
>


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Jun 12 13:52:40 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06871
	for ; Wed, 12 Jun 2002 13:52:40 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0064A8BB@cherry.ease.lsoft.com>; Wed, 12 Jun 2002 13:53:12 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 32635 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 12 Jun 2002 13:53:12 -0400
Received: from 207.217.120.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Wed, 12 Jun 2002 13:53:12 -0400
Received: from user-2ivfjee.dialup.mindspring.com ([165.247.205.206]
          helo=earthlink.net) by goose.mail.pas.earthlink.net with esmtp (Exim
          3.33 #2) id 17ICIr-0001L7-00 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 12
          Jun 2002 10:53:06 -0700
X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified)
X-Mailer: Mozilla 4.72 [en]C-gatewaynet  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
            <007201c21206$959d1a40$0401a8c0@KasiViswanath>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D078CC3.3A8F3250@earthlink.net>
Date:         Wed, 12 Jun 2002 11:02:43 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Erblichs 
Subject: resubjectized: re-academia project
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Wow,

        Hope this helps:

        First try to identify what you are trying to do and
        limit your scope to the amount of time and effort
        available...

        1) Are you concerned with byte order?
        2) Are you concerned with stack overflow?
        3) Are you concerned with redistribution?
        4) Do you need to support area border routers (ABR)?
        5) Do you need to do packet/field validation?
        6) Do you need to write your own spf algorithm?
        7) Do you need to support opaque LSAs?
        8) Are you concerned with only intra-area routes?
        9) Are you concerned with BMA, P2P, etc support?
        10) Do you need to support Ethernet, ATM, FDDI, etc?
        11) Are you concerned with authentication support?
        12) Do you need to write your own Command Line Interface (CLI)?
        ...  :-)
        100) What is your testing configuration, environment,criteria?

        And verify that the scope is acceptable for your project.

        Mitchell Erblich
        -----------------------


Kasi Viswanath wrote:
>
> Hi all
>
> I'm new to this mailing list,
> and I'm doing ospf implementation as my academic project
> and I have lots of doubts to clarify.
> Is there any format or rules to ask question?
>
> TIA
>
> with regards
> kasi viswanath.N.J
>
> ----- Original Message -----
> From: "Manral, Vishwas" 
> To: 
> Sent: Wednesday, June 12, 2002 10:29 AM
> Subject: Re: draft-bmwg-ospfconv-term-00.:P2P Converge Time
>
> > Hi Mitchell,
> >
> > Thanks for ur response.
> >
> > If you read the methodology draft, you will observe that most of the tests
> > are like, how long it takes for a change to be propagated to other routers
> > and the SPF being calculated. The definition of convergence is given in
> the
> > context of this, as are all other definitions, where the LSA change does
> > cause a route change in the neighbor. I do understand ur point however.
> >
> > I guess I agree we can change the definiton of convergence to better
> reflect
> > the what you say. We could have loop free paths even with different
> > databases and this may not be what we want to convey.
> >
> > Thanks,
> > Vishwas
> >
> > -----Original Message-----
> > From: Erblichs [mailto:erblichs@EARTHLINK.NET]
> > Sent: Wednesday, June 12, 2002 12:32 AM
> > To: OSPF@DISCUSS.MICROSOFT.COM
> > Subject: Re: draft-bmwg-ospfconv-term-00.:P2P Converge Time
> >
> >
> > Vishwas,
> >
> >         Most of the points here are what I call nits..
> >
> >         However, the convergence item "C" is the most
> >         interesting one. You state that "the same LSDB may be on
> >         all the routers and they still may have LSA's on the
> >         retransmit list), Maxage etc."
> >
> >         I consider convergence is when a level of stasis
> >         (a non-changing time is present). When LSA are on
> >         re-xmit lists, it needs to be assumed that one or
> >         more routers (IS's) may not have the LSA. They may
> >         have had it and it may have been aged out.
> >
> >         As a implicit item in my statement, the item may
> >         be on the re-xmit list because the one or more
> >         other link-partners may have lost its link and
> >         the adjacency timer has not yet fired.
> >
> >         Thus, I was striving for a known state that we
> >         are in a state of stable non-changing conditions
> >         for at least a moment in time..
> >
> >         I have seen non-loop free paths and all of the
> >         link state databases have identical LSAs. It was
> >         due to configuration errors and redistribution
> >         differences in a multi-protocol environment.
> >
> >         Yes, it is a level of more complexity than as
> >         the wg's definition.. I have run into a number of
> >         people who disagree on really what is meant by
> >         convergence. I don't think it really has been
> >         stated with a precise definition. So, I was
> >         trying to nail it down here...
> >
> >         Mitchell Erblich
> >         =================
> >
> >
> >
> >
> >
> >
> > "Manral, Vishwas" wrote:
> > >
> > > Hi Mitchell,
> > >
> > > Thanks for the comments. My comments are inline prefixed by a VM>.
> > >
> > > -Vishwas
> > >
> > > -----------------------------------------------------------
> > > A)
> > >
> > > 5. Definitions
> > >
> > >  Hello Interval
> > >
> > > "and point-to-point networks" -> and non-Demand Circuit point-to-point
> > > networks.
> > >
> > > OR
> > >
> > > "and point-to-point networks". + Exceptions of some point-to-point
> > > circuits are demand point to point circuits, which would be the
> > > successful of hello supression negotiation..
> > >
> > > On the assumption that RFC 1793 Hello suppression is employed.
> > > VM> I agree to your point. However I think its an overkill to put all
> the
> > > special cases in a definition.
> > >
> > > B) 5. Definitions
> > >
> > > Shortest Path First Time
> > >
> > > ADD... Some implimentations may force a interval between
> > > successive SPF calculations. If it exists, then this additional time
> > > value should be subtracted from the total time.
> > > VM> If you check the methodology draft, we have taken care of this.
> > >
> > > C) Meaning of Convergence
> > >
> > > I would suggest..
> > >
> > > A network is termed converged at one point in time when all of the
> > > following has occured.
> > >
> > > * all adjacencies that are to be formed have proceeded to full
> > >   state.
> > > * all retransmission lists are empty
> > > * all recieved update, req LSAs have been processed
> > > * All MAXAGE LSAs within the link state databases have been removed
> > > * the link state databases are synchronized, exceptions are opaque LSAs
> > > * all routers within an area have completed their SPF calculations
> > >   and have inserted the results into their respective routing tables
> > >
> > > VM> The definition of convergence that has been derived has come out
> after
> > > atleast  40 mail exchanges on the bmwg list. I however do not agree to
> > many
> > > of the points you state above, like the one on retransmission lists(the
> > same
> > > LSDB may be on all the routers and they still may have LSA's on the
> > > retransmit list), Maxage etc.
> > >
> > > D) New item....
> > >
> > > 6.3 Types of Network Events
> > >
> > > * SPF events / triggers
> > >
> > > Time the various types of events/triggers that would cause a
> > > SPF calculation to occur.
> > > VM> I guess that is something we do not require in the draft at all.
> > Network
> > > events have been listed, as we have given the methodology to find time
> to
> > > converge when the events occur.
> > >
> > > Thanks again.
> > >
> > > "Manral, Vishwas" wrote:
> > > >
> > > > Hi Mitchell,
> > > >
> > > > Apologies for the delayed reply(I have been away from my mail for some
> > > time
> > > > now) and thanks for the comment.
> > > >
> > > > I guess the point you are trying to make is that although the DR
> > election
> > > > itself could cause a delay in the broadcast case, there are certain
> > other
> > > > factors involved.
> > > >
> > > > However in the context of the discussion, what we have tried to say is
> > > that
> > > > all other things being the same(as we have put it as "of the same
> > speed"),
> > > > because on a broadcast network if routers were comming up
> symultaneously
> > > > they would have to wait for the Waiting interval before electing a DR,
> > it
> > > > would take a longer time. Also the flooding takes place via the DR/BDR
> > and
> > > > that causes additional delay. Maybe we will try and modify the text to
> > > make
> > > > the fact clearer.
> > > >
> > > > Besides I would like to know of any other point you you would like to
> > > > comment on(not agree on) within the draft.
> > > >
> > > > Thanks,
> > > > Vishwas
> > > >
> > > > -----Original Message-----
> > > > From: Erblichs [mailto:erblichs@EARTHLINK.NET]
> > > > Sent: Friday, June 07, 2002 12:07 AM
> > > > To: OSPF@DISCUSS.MICROSOFT.COM
> > > > Subject: draft-bmwg-ospfconv-term-00.:P2P Converge Time
> > > >
> > > > Group,
> > > >
> > > >         I have a few items that I don't necessarily agree
> > > >         with here, but the one item that I feel most
> > > >         strongly with is..
> > > >
> > > >         5. Definition
> > > >         Point-to-Point links
> > > >         Discussion      "will take lesser time to converge than
> > > >                         a broadcast link"
> > > >
> > > >         Yes, I do agree that a DR election, mainly due to the
> > > >         initial wait time, can become a large part in the time
> > > >         to converge.
> > > >
> > > >         Given that if point-to-point links are substituted for
> > > >         broadcast links, I feel that the above statement becomes
> > > >         false..
> > > >
> > > >         Note: adjacencies = adjs
> > > >
> > > >         Why,,
> > > >
> > > >         The fewer number of adjs
> > > >         allows a fewer number of database description packets to
> > > >         be exchanged, a fewer number of master/slave negotiations,
> > > >         etc. As each additional adj is formed, there is a higher
> > > >          probability that additional SPF calculations will need
> > > >         to be performed.
> > > >
> > > >         In addition, additional flooding due to additional adjs
> > > >         will slow the converge process. Also with the additional
> > > >         load, the router may identify a overload condition, and
> > > >         even temporally reject some of these point-to-point adj
> > > >         formations..
> > > >
> > > >         I am unsure whether a single slow router to inform the
> > > >         DR or BDR of its links vs informing all of the adjs of
> > > >         its links, will adversely effect the MA vs the P2P link
> > > >         topology more. In my mind there are just too many variables.
> > > >
> > > >         In addition, the statement does not implicitly or explicitly
> > > >         imply whether the routing topology has changed and thus
> > > >         the BDR is being elected as the DR.
> > > >
> > > >         THUS, I would consider a different wording to be on the
> > > >         order of ... (Please note that I have not mentioned
> > > >         Ethernet (shared-meda) type links where collisions with
> > > >         exponential backoff may play a role OR....) To keep it
> > > >         simple.
> > > >
> > > >         A point-to-point link network topology makes the tradeoff
> > > >         of additional adjacencies formations vs the overhead of
> > > >         the required multi-access DR/ BDR election. Given a small
> > > >         number of adjacencies in a point-to-point environment, it
> > > >         can be more efficent than a multi-access topology if the
> > > >         links between the DR and DRothers are constantly changing
> > > >         OR that the election wait-time requirement is a large
> > > >         part of the convergence time.
> > > >
> > > >         Thanks,
> > > >                 Mitchell Erblich
> >


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Jun 12 21:27:40 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18509
	for ; Wed, 12 Jun 2002 21:27:40 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.0064B5A4@cherry.ease.lsoft.com>; Wed, 12 Jun 2002 21:28:13 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 33871 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 12 Jun 2002 21:28:13 -0400
Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 12 Jun 2002 21:28:13 -0400
Received: from 12-234-73-224.client.attbi.com ([12.234.73.224]) by psg.com with
          esmtp (Exim 3.36 #1) id 17IJPF-000HWj-00; Wed, 12 Jun 2002 18:28:09
          -0700
X-Mailer: The Bat! (v1.51) Personal
X-Priority: 3 (Normal)
References: <55E277B99171E041ABF5F4B1C6DDCA06184BCF@HARITHA>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3845764024.20020612182655@psg.com>
Date:         Wed, 12 Jun 2002 18:26:55 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Alex Zinin 
Subject: Re: Identification of neighbors in PTP links
Comments: To: "Balaji R (Networking) - CTD, Chennai." 
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <55E277B99171E041ABF5F4B1C6DDCA06184BCF@HARITHA>
Precedence: list
Content-Transfer-Encoding: 7bit

Balaji:

> In ptp links, if the two sides have dissimilar IP subnets assigned, then I
> guess option 2 of 12.4.1.1 can't be applied.

It still can be. Each side will announce its own subnet and both will
be reachable.

[...]

> I would be more interested in knowing the implications of identifying
> neighbors based on source IP address as against the router ID as mentioned
> in the RFC 2328 in section 10.5.

Identifying neighbors by the IP address has the drawback of a flapping
adjacency when the interface address on the router is changed. This
does not have to happen, as the topology has not changed. Besides,
the router-ID is considered to be a more stable entity.

Identifying neighbors by their router IDs is the "clean" method, as
the network's topological model will not depend on any IP address
info in this case. The difference in neighbor identification in p2p
and multiaccess case in OSPFv2 has to do with support of multiple interfaces
to the same subnet and is something that you just have to live with.
Note that in OSPFv3, neighbors are always identified by their router IDs
and the case of multiple interfaces to the same link is addressed by
allowing only a single interface to send and receive OSPF control packets.

Alex


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Jun 12 21:33:06 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18618
	for ; Wed, 12 Jun 2002 21:33:06 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0064B515@cherry.ease.lsoft.com>; Wed, 12 Jun 2002 21:33:40 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 33922 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 12 Jun 2002 21:33:41 -0400
Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 12 Jun 2002 21:33:41 -0400
Received: from 12-234-73-224.client.attbi.com ([12.234.73.224]) by psg.com with
          esmtp (Exim 3.36 #1) id 17IJUW-000Hdj-00; Wed, 12 Jun 2002 18:33:37
          -0700
X-Mailer: The Bat! (v1.51) Personal
X-Priority: 3 (Normal)
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <11146095228.20020612183227@psg.com>
Date:         Wed, 12 Jun 2002 18:32:27 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Alex Zinin 
Subject: Re: OSPF checksum error between two differents contructors routers
Comments: To: Arnaud Lemaire 
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  
Precedence: list
Content-Transfer-Encoding: 7bit

Arnaud,

  What might be happening is one router may be configured
  with MD5 authentication and is expecting the checksum
  to be 0, while another router is using another authentication
  mechanism or none at all. Normally, one would expect the first
  router to complain about the authentication type, but I could
  easily imagine an implementation mistakenly performing these
  checks in a different order.

--
Alex

Friday, May 31, 2002, 3:45:25 AM, you wrote:
> Hi,

> i have got a problem with a multi-constructor network :

> Here is my question : Two equipments are connected in OSPF, one send LSA
> update with a 0xFFFF checksum the second router drop the packet and
> said "checksum eror, should be zero".

> RFC 2328 says : "a checksum should never be zero".

> RFC 905 about Fletcher Checksum says :" one's  complement  arithmetic  in
> which  if  any  of  the variables  has the value minus zero (i.e. 255 "or
> OxFFFF) it shall be regarded as though it was plus zero (i.e. 0).

> Can we conclude wich equipement is wrong : the one which sent the FFFF
> checksum or the one which said should be zero ?

> What i understand is that sending an FFFF checksum is like sending a 0
> cehcksum and it is an wrong value.

> Thanx for helping,


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Jun 12 21:36:12 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18653
	for ; Wed, 12 Jun 2002 21:36:12 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0064B6AD@cherry.ease.lsoft.com>; Wed, 12 Jun 2002 21:36:47 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 33958 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 12 Jun 2002 21:36:47 -0400
Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 12 Jun 2002 21:36:47 -0400
Received: from 12-234-73-224.client.attbi.com ([12.234.73.224]) by psg.com with
          esmtp (Exim 3.36 #1) id 17IJXa-000Hgw-00; Wed, 12 Jun 2002 18:36:46
          -0700
X-Mailer: The Bat! (v1.51) Personal
X-Priority: 3 (Normal)
References: <582F942D.481C624A.0004D071@aol.com> <3CFA5A62.60106@redback.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <11646284374.20020612183536@psg.com>
Date:         Wed, 12 Jun 2002 18:35:36 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Alex Zinin 
Subject: Re: Routing bit set on sho ip ospf database
Comments: To: Acee Lindem 
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <3CFA5A62.60106@redback.com>
Precedence: list
Content-Transfer-Encoding: 7bit

In the case of that particular vendor, whose implementation
I just happen to have worked with a bit ;), the "routing bit"
means that the advertising router is reachable through SPF.
Cool for network troubleshooting, saved me hours many times.

Alex


> I believe this is a vendor specific question and you'd better
> served by directing it to your vendor. Having said that, if your
> vendor's implementation is similiar to ours the router bits
> in the "show ospf database detail" output corresponding directly
> to the type LSA 1 router bits as documented in section A.4.2 of
> RFC 2328.


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Jun 12 22:06:40 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19386
	for ; Wed, 12 Jun 2002 22:06:39 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.0064B675@cherry.ease.lsoft.com>; Wed, 12 Jun 2002 22:07:14 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 34008 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 12 Jun 2002 22:07:14 -0400
Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 12 Jun 2002 22:07:14 -0400
Received: from 12-234-73-224.client.attbi.com ([12.234.73.224]) by psg.com with
          esmtp (Exim 3.36 #1) id 17IK11-000IFN-00; Wed, 12 Jun 2002 19:07:11
          -0700
X-Mailer: The Bat! (v1.51) Personal
X-Priority: 3 (Normal)
References: 
            <001501c2099f$12789e60$3201310a@asmhome>
            <3CF925E3.409A143C@earthlink.net>
            <001101c209b5$6df6b310$3201310a@asmhome>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <6648109738.20020612190601@psg.com>
Date:         Wed, 12 Jun 2002 19:06:01 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Alex Zinin 
Subject: Re: Dynamic Priority setting for DR election
Comments: To: Anton Smirnov 
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <001101c209b5$6df6b310$3201310a@asmhome>
Precedence: list
Content-Transfer-Encoding: 7bit

 In fact, there are situations where even with a single segment,
 DR responsibilities are too much of a burden for a given router,
 especially when there's a big number of neighbors and a constant
 stream of LSA updates or a flooding storm. So, the situations
 where you do want to shift the DR responsibility may be quite
 realistic.

 In fact, there's a backward-compatible way to preempt the DR
 responsibilities that I already mentioned on the list. The idea
 is to use the process that is seen when a partitioned segment
 is reconnected again. In this case, two routers believe they are
 the DR and compete for this position, as each of them announces
 itself as the DR. Similarly to this process, a router could try
 to preempt the DR role if it announces itself as the DR (or the
 BDR if that's what we need).  If the admin happened to configure
 correct priority, the DR role will shift. A nice thing is that
 we can always tell if preemption is possible based on the local
 configuration and neighbors' announced priorities & IDs.

 That's a small hack and if we see enough interest from the OPS
 community, I guess the WG could consider working on a draft for
 it.

--
Alex

Saturday, June 01, 2002, 2:43:53 PM, you wrote:
>    Mitchel,
>    there must be several conditions met for platform to benefit from DR
> offload:
> -  (in broad sense of the word) must have many interfaces, dozens if
> not hundreds
> - These interfaces must be OSPF broadcast/NBMA (because there is no DR on
> ptp links)
> - On each interface more than one neighbor should be present. This rule is
> because otherwise interfaces should be converted - manually or somehow
> automatically - to ptp. Thus dozens of apparently needless Net LSAs will be
> eliminated from LSDB, having other benefits (less flooding and simpler SPF
> in the area)
> - Set of routers on each interface should be different. If same routers are
> neighboring thru dozens of transit interfaces then one must think about
> reasonable network design, right?

>    I can't think of any widely accepted industry solution matching all these
> requirements. Access solutions tend to have ptp links, whatever L2 method is
> employed. Layer 3 switches come closest to matching all these conditions but
> it is because last rule usually neglected. On L3 switches all interfaces (or
> vlans) where end clients are connected may and should be configured as stub
> networks, not transit.
>    Then I just do not see a case where DR offload may be beneficial. That
> was my point.

>    Of course, there always exist freaks who for very specific reasons want
> to do something unusual. But these freaks can manually play with OSPF
> priorities on interfaces of routers.

> Anton


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Jun 12 22:23:19 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19526
	for ; Wed, 12 Jun 2002 22:23:18 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0064B683@cherry.ease.lsoft.com>; Wed, 12 Jun 2002 22:23:53 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 34067 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 12 Jun 2002 22:23:54 -0400
Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 12 Jun 2002 22:23:54 -0400
Received: from 12-234-73-224.client.attbi.com ([12.234.73.224]) by psg.com with
          esmtp (Exim 3.36 #1) id 17IKHA-000IVH-00; Wed, 12 Jun 2002 19:23:52
          -0700
X-Mailer: The Bat! (v1.51) Personal
X-Priority: 3 (Normal)
References: <4.3.2.7.1.20020514102916.00ae88a0@golf.cpgdesign.analog.com>
            <3CE1773D.46A19A6B@iprg.nokia.com>           
            <3CE17CD3.55FA7E66@earthlink.net> <3CE19CD0.6DCBF5E@iprg.nokia.com>
            <3CE1A922.84B8B0E1@earthlink.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <6349110273.20020612192241@psg.com>
Date:         Wed, 12 Jun 2002 19:22:41 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Alex Zinin 
Subject: Re: Using AH for Authentication for OSPFv3
Comments: To: Erblichs 
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <3CE1A922.84B8B0E1@earthlink.net>
Precedence: list
Content-Transfer-Encoding: 7bit

Mitchell:

 Actually, I wouldn't like this discussion to get carried
 away towards the marketing matters. I would love to hear
 opinions on whether we need more info on how to use IPSec
 for OSPFv3...

--
Alex

Tuesday, May 14, 2002, 5:17:38 PM, you wrote:
> Mukesh,
>         What you are really asking is when and where will
>         a XXX, ZZZ, etc is going to publicly announce
>         that they have deployments of routers with OSPFv3
>         support?

>         My question to you, how do you know that for instance,
>         XXX and ZZZ, etc doesn't have OSPFv3/ IPv6 software
>         installed but just not enabled? It it up to their
>         customers and their marketing/sales group to decide
>         when they plan to announce levels of functionality.

>         Mitchell Erblich


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Jun 13 01:04:09 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22640
	for ; Thu, 13 Jun 2002 01:04:08 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.0064BC13@cherry.ease.lsoft.com>; Thu, 13 Jun 2002 1:04:42 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 34394 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 13 Jun 2002 01:04:43 -0400
Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 13 Jun 2002 01:04:42 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id ; Thu, 13 Jun 2002 01:00:11 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  
Date:         Thu, 13 Jun 2002 01:04:24 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: "Manral, Vishwas" 
Subject: Re: Dynamic Priority setting for DR election
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Alex,

I guess this method can be improved a little using the OSPF concept of BDR,
so that when the DR goes down the BDR can immediately take over and does not
have to form adjacencies all over again.

We could use this, in the sense first declare ourself the BDR and then the
DR, so that the transition is smooth. Agree?

I do not have much idea of OPS though....anyone?

Thanks,
Vishwas

-----Original Message-----
From: Alex Zinin [mailto:zinin@PSG.COM]
Sent: Thursday, June 13, 2002 7:36 AM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: Dynamic Priority setting for DR election


 In fact, there are situations where even with a single segment,
 DR responsibilities are too much of a burden for a given router,
 especially when there's a big number of neighbors and a constant
 stream of LSA updates or a flooding storm. So, the situations
 where you do want to shift the DR responsibility may be quite
 realistic.

 In fact, there's a backward-compatible way to preempt the DR
 responsibilities that I already mentioned on the list. The idea
 is to use the process that is seen when a partitioned segment
 is reconnected again. In this case, two routers believe they are
 the DR and compete for this position, as each of them announces
 itself as the DR. Similarly to this process, a router could try
 to preempt the DR role if it announces itself as the DR (or the
 BDR if that's what we need).  If the admin happened to configure
 correct priority, the DR role will shift. A nice thing is that
 we can always tell if preemption is possible based on the local
 configuration and neighbors' announced priorities & IDs.

 That's a small hack and if we see enough interest from the OPS
 community, I guess the WG could consider working on a draft for
 it.

--
Alex

Saturday, June 01, 2002, 2:43:53 PM, you wrote:
>    Mitchel,
>    there must be several conditions met for platform to benefit from DR
> offload:
> -  (in broad sense of the word) must have many interfaces, dozens
if
> not hundreds
> - These interfaces must be OSPF broadcast/NBMA (because there is no DR on
> ptp links)
> - On each interface more than one neighbor should be present. This rule is
> because otherwise interfaces should be converted - manually or somehow
> automatically - to ptp. Thus dozens of apparently needless Net LSAs will
be
> eliminated from LSDB, having other benefits (less flooding and simpler SPF
> in the area)
> - Set of routers on each interface should be different. If same routers
are
> neighboring thru dozens of transit interfaces then one must think about
> reasonable network design, right?

>    I can't think of any widely accepted industry solution matching all
these
> requirements. Access solutions tend to have ptp links, whatever L2 method
is
> employed. Layer 3 switches come closest to matching all these conditions
but
> it is because last rule usually neglected. On L3 switches all interfaces
(or
> vlans) where end clients are connected may and should be configured as
stub
> networks, not transit.
>    Then I just do not see a case where DR offload may be beneficial. That
> was my point.

>    Of course, there always exist freaks who for very specific reasons want
> to do something unusual. But these freaks can manually play with OSPF
> priorities on interfaces of routers.

> Anton


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Jun 13 05:38:26 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05669
	for ; Thu, 13 Jun 2002 05:38:26 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.0064C0EA@cherry.ease.lsoft.com>; Thu, 13 Jun 2002 5:38:59 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 35043 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 13 Jun 2002 05:38:59 -0400
Received: from 158.43.128.27 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 13 Jun 2002 05:38:59 -0400
Received: (qmail 5092 invoked from network); 13 Jun 2002 09:38:57 -0000
Received: from userai43.uk.uudial.com (HELO tom3) (62.188.133.73) by
          smtp-2.dial.pipex.com with SMTP; 13 Jun 2002 09:38:57 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Message-ID:  <008d01c212bd$c8592700$0301a8c0@tom3>
Date:         Thu, 13 Jun 2002 10:32:45 +0100
Reply-To: Mailing List 
Sender: Mailing List 
From: Tom Petch 
Subject: Re: format or rules to ask question?
Comments: To: VishwasM@NETPLANE.COM, kasin@SDKSOFT.COM
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Yes, I think there are rules.

Overall, there are RFC published by the IETF as to what the IETF is
about and how mailing lists should be used - see the IETF web site.

Second, see the Working Group information on the web site as to what
the scope of a particular working group is, what mailing lists it has
and which should be used for what.  Some have multiple lists for eg
standards advancement and implementation.

Third, stick your neck out.  (Those who never make mistakes, never
....)  When you get it badly wrong, you get told: those who can still
remember what it was like to start will do so politely; others may not
so you may want a friend handy at such times.

And you will not be the only one who makes a mistake; there are
plenty - sigh - on the IETF web site.

Tom Petch, Network Consultant
nwnetworks@dial.pipex.com


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Jun 13 19:54:11 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04896
	for ; Thu, 13 Jun 2002 19:54:10 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.0064D1DC@cherry.ease.lsoft.com>; Thu, 13 Jun 2002 19:54:44 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 1135 for OSPF@DISCUSS.MICROSOFT.COM; Thu,
          13 Jun 2002 19:54:44 -0400
Received: from 135.207.30.103 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Thu, 13 Jun 2002 19:54:44 -0400
Received: from alliance.research.att.com (alliance.research.att.com
          [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP
          id E15CF1E013 for ; Thu, 13 Jun 2002
          19:54:43 -0400 (EDT)
Received: from windsor.research.att.com (windsor.research.att.com
          [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with
          ESMTP id TAA21954 for ; Thu, 13 Jun 2002
          19:54:43 -0400 (EDT)
Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5)
          id QAA11930; Thu, 13 Jun 2002 16:54:42 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Versions: dmail (solaris) 2.4c/makemail 2.9d
Message-ID:  <200206132354.QAA11930@windsor.research.att.com>
Date:         Thu, 13 Jun 2002 16:54:42 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Bill Fenner 
Subject: Heard from John lately?
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Has anyone here heard from John lately?  Please let me know privately.

Thanks,
  Bill


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Jun 14 17:43:05 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16368
	for ; Fri, 14 Jun 2002 17:43:05 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.0064EE1C@cherry.ease.lsoft.com>; Fri, 14 Jun 2002 17:43:39 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 5392 for OSPF@DISCUSS.MICROSOFT.COM; Fri,
          14 Jun 2002 17:43:39 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 14 Jun 2002 17:43:39 -0400
Received: from redback.com (login003.redback.com [155.53.12.55]) by
          prattle.redback.com (Postfix) with ESMTP id D81094F41AE; Fri, 14 Jun
          2002 14:43:37 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <582F942D.481C624A.0004D071@aol.com> <3CFA5A62.60106@redback.com>
            <11646284374.20020612183536@psg.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D0A62E0.3010104@redback.com>
Date:         Fri, 14 Jun 2002 17:40:48 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: Acee Lindem 
Subject: Re: Routing bit set on sho ip ospf database
Comments: To: Alex Zinin 
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Alex Zinin wrote:
> In the case of that particular vendor, whose implementation
> I just happen to have worked with a bit ;), the "routing bit"
> means that the advertising router is reachable through SPF.
> Cool for network troubleshooting, saved me hours many times.

I implemented the same hack but with the more intuitive :^)
"show ospf border-routers all" command.

>
> Alex
>
>
>
>>I believe this is a vendor specific question and you'd better
>>served by directing it to your vendor. Having said that, if your
>>vendor's implementation is similiar to ours the router bits
>>in the "show ospf database detail" output corresponding directly
>>to the type LSA 1 router bits as documented in section A.4.2 of
>>RFC 2328.
>
>
>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Sat Jun 15 03:50:16 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04469
	for ; Sat, 15 Jun 2002 03:50:16 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00650236@cherry.ease.lsoft.com>; Sat, 15 Jun 2002 3:50:51 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 6460 for OSPF@DISCUSS.MICROSOFT.COM; Sat,
          15 Jun 2002 03:50:50 -0400
Received: from 133.145.224.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Sat, 15 Jun 2002 03:50:50 -0400
Received: from navsg1.hitachi.co.jp by hitpro.hitachi.co.jp (8.9.3/3.7W-hitpro)
          id QAA27121; Sat, 15 Jun 2002 16:50:49 +0900 (JST)
Received: from navsg1.hitachi.co.jp by navsg1.hitachi.co.jp (8.9.3/3.7W-navsg1)
          id QAA19121; Sat, 15 Jun 2002 16:50:49 +0900 (JST)
Received: from newton.ebina.hitachi.co.jp ([158.214.184.5]) by
          navsg1.hitachi.co.jp (NAVGW 2.5.1.16) with SMTP id
          M2002061516504816928 for ; Sat, 15 Jun
          2002 16:50:48 +0900
Received: from one3463.ebina.hitachi.co.jp (root@[172.16.251.139]) by
          newton.ebina.hitachi.co.jp (8.9.0/3.7W-EBINA) with ESMTP id QAA22967
          for ; Sat, 15 Jun 2002 16:50:48 +0900
          (JST)
Received: from d51139.in.kanagawa.hitachi.co.jp (yamate@localhost [127.0.0.1])
          by one3463.ebina.hitachi.co.jp (8.8.5/3.7W-99032914) with ESMTP id
          QAA00776 for ; Sat, 15 Jun 2002 16:50:47
          +0900 (JST)
Message-ID:  <200206150750.QAA00776@one3463.ebina.hitachi.co.jp>
Date:         Sat, 15 Jun 2002 16:50:47 +0900
Reply-To: Mailing List 
Sender: Mailing List 
From: Yamate Keiichirou 
Subject: Some authentication problems with LLS?
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

  Hi.

  I want to know how link-local signaring
(draft-nguyen-ospf-lls-00.txt) prevents some reply attacks. Please
teach me.

  In assumption that there are two routers using cryptgraphic
authentication and supporting LLS and RS-bit, and an attacker's host
(called "Host") on same link, when one router is restarted (called
"Restart Router"), Restart Router will sends Hello with RS-bit set to
(a) neighboring router (called "Neighbor").

  Where sending hello, Restart Router generates both of Hello itself
and LLS that has RS-bit set with message digest and cryptgraphic
sequence number, since the link required to transmit OSPF packets with
cryptgraphic authentication.

  However, Restart Router shall not know what sequence number the
Restart Router's previous incarnation sent (on other hand, it SHOULD
be nonvolatile stored in hitless-restart).  I think two problems at
the time.

  One is, Restart Hello reply attack.

  Assumption of the cryptgraphic sequence number is "1" at (re)start,
Neighbor SHOULD be ignore the Restart Router's Hello because Hello has
little cryptgraphic sequence number than accepted previously. If Hello
was ignored, the adjacency will be reset in the result. And If Hello
was accepted against reversed sequence number, it is allow to Host to
attack simply replying the heard Hello with RS-bit set and it will
accepted at Neighbor in any time.

  Another is, LLS block reply attack attached to Neighbor's Hello with
same cryptgraphic sequence number.

  Whatever sequence number is, all LLS blocks in any Hellos are
authenticated only with cryptgraphic sequence number. It is possible
that Host store any LLC blocks attached to Hellos, and when Hello that
has same cryptgraphic sequence number as one of LLSs stored, there is
a potential that Host sends receiving Hello with LLS unassociated but
same sequence number.

Thank you.


From owner-ospf@DISCUSS.MICROSOFT.COM  Sat Jun 15 04:07:18 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04659
	for ; Sat, 15 Jun 2002 04:07:18 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00650205@cherry.ease.lsoft.com>; Sat, 15 Jun 2002 4:07:54 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 6506 for OSPF@DISCUSS.MICROSOFT.COM; Sat,
          15 Jun 2002 04:07:54 -0400
Received: from 207.217.120.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Sat, 15 Jun 2002 04:07:54 -0400
Received: from user-2ivfnde.dialup.mindspring.com ([165.247.221.174]
          helo=earthlink.net) by harrier.mail.pas.earthlink.net with esmtp
          (Exim 3.33 #2) id 17J8b9-0004OV-00 for OSPF@DISCUSS.MICROSOFT.COM;
          Sat, 15 Jun 2002 01:07:52 -0700
X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified)
X-Mailer: Mozilla 4.72 [en]C-gatewaynet  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <20020604172011.004C94454E@mx1.elte.hu>
            <003101c20bfc$3727bb10$3201310a@asmhome>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D0AF819.8EF408F9@earthlink.net>
Date:         Sat, 15 Jun 2002 01:17:29 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Erblichs 
Subject: Re: Sending new LSA
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Just a few late remarks..

First, it would be nice for the router to identify the
time it takes to run a FULL SPF  and not schedule more than
1 in that time frame.. This should be dynamic as the size
of the LSDB and time it takes for the SPF changes.

In my experience, once you recieve a LSA that should cause a
SPF calculation, there is a high chance that another LSA
isn't far behind... (buyer beware) It may make sense to support
a short duration wait timer before the next SPF is done...

If a OSPF router is over-loaded with LSAs, it may make sense
to pospone SPF.

Disjoint router groups may allow sub-SPF type calculations.

When a OSPF interface is enabled, it may make sense to have
a larger than normal delay before the SPF is run..

All LSAs are not considered equal and some may not require
a SPF..

The loss of neighbors and or down interfaces does not necessarily
need a new SPF. This assumes that your SPF code has extra smarts..

....

Inter-area OSPF routes are distance-vector calculations.... and
are not SPF calculations like it's link-state cousin, IS-IS.

Mitchell Erblich





Anton Smirnov wrote:
>
>    Attila,
>    you can schedule full SPF whenever your own router LSA changes to be on
> the safe side. But apparently implementation may try to optimize SPF
> algorithm - including complete elimination of SPF run - if this doesn't
> produce discrepancy with standardized behavior.
>    It makes very good sense to schedule SPF based on interface+neighbor
> state change rather than on only interface up or down change. If router
> doesn't have any neighbors on local interface then full SPF likely to bring
> no changes in the routing table (though some implementation may require it
> for some reason)
>    If you strictly follow standard timers then router always sends LSA
> before running SPF (at least if SPF was triggered by change in this LSA, not
> by another LSA some seconds earlier). In theory, I could imagine that
> well-designed implementation sends LSA "at the very same time" as SPF is
> running.
>    But, generally speaking, if you run SPF first then flood then changes in
> routing tables throughout OSPF domain will look more like in distance-vector
> protocols. Remember that SPF run is relatively slow process. Not a nice
> thing you could expect from link state protocol, right? Such timers
> configuration better be avoided.
>
> Anton
>
> ----- Original Message -----
> From: "Attila Nohl" 
> To: 
> Sent: Tuesday, June 04, 2002 5:06 PM
> Subject: [OSPF] Sending new LSA
>
> > Hello!
> >
> > I have question about originating new LSAs. Let's say that the status of
> > a router's interface changes. In this case, the router creates a new
> > Router LSA, replaces its own Router LSA in its LSA database and sends the
> > new LSA to its neighbours. My questions are:
> >
> > - When the LSA is replaced in the LSA database, does the router run an SPF
> >   calculation (because the LSA database has changed)? I think, if the
> >   interface is towards a transit network, then the router must run the
> >   SPF calculation, but what happens in case of interfaces towards stub
> >   networks?
> >
> > - If the router runs an SPF calculation, which happens sooner? The sending
> >   of the LSA to the neighbours or the SPF calculation?
> >
> >                                 Bye,NAR
> >


From owner-ospf@DISCUSS.MICROSOFT.COM  Sat Jun 15 14:35:15 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13260
	for ; Sat, 15 Jun 2002 14:35:14 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00651138@cherry.ease.lsoft.com>; Sat, 15 Jun 2002 14:35:49 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 7903 for OSPF@DISCUSS.MICROSOFT.COM; Sat,
          15 Jun 2002 14:35:48 -0400
Received: from 64.246.202.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Sat, 15 Jun 2002 14:35:48 -0400
Received: from [192.168.254.10] by mainserver (ArGoSoft Mail Server Pro for
          WinNT/2000/XP, Version 1.8 (1.8.1.1)); Sat, 15 Jun 2002 14:32:06 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Message-ID:  
Date:         Sat, 15 Jun 2002 14:35:46 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: Tom Thomas 
Subject: Re: draft-bmwg-ospfconv-term-00.:P2P Converge Time
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <007201c21206$959d1a40$0401a8c0@KasiViswanath>
Precedence: list
Content-Transfer-Encoding: 7bit

Depends in what way you are using "ospf implementation" if you are
considering doing it from a programming perspective then this si the right
forum. If you are doing it from 'how do I configure' routers X, Y, Z to use
OSPF this is not the right place. If you need some pointers to those places
contact me off line.

Tom

-----Original Message-----
From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Kasi
Viswanath
Sent: Wednesday, June 12, 2002 7:45 AM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: draft-bmwg-ospfconv-term-00.:P2P Converge Time


Hi all

I'm new to this mailing list,
and I'm doing ospf implementation as my academic project
and I have lots of doubts to clarify.
Is there any format or rules to ask question?

TIA

with regards
kasi viswanath.N.J



----- Original Message -----
From: "Manral, Vishwas" 
To: 
Sent: Wednesday, June 12, 2002 10:29 AM
Subject: Re: draft-bmwg-ospfconv-term-00.:P2P Converge Time


> Hi Mitchell,
>
> Thanks for ur response.
>
> If you read the methodology draft, you will observe that most of the tests
> are like, how long it takes for a change to be propagated to other routers
> and the SPF being calculated. The definition of convergence is given in
the
> context of this, as are all other definitions, where the LSA change does
> cause a route change in the neighbor. I do understand ur point however.
>
> I guess I agree we can change the definiton of convergence to better
reflect
> the what you say. We could have loop free paths even with different
> databases and this may not be what we want to convey.
>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Erblichs [mailto:erblichs@EARTHLINK.NET]
> Sent: Wednesday, June 12, 2002 12:32 AM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Re: draft-bmwg-ospfconv-term-00.:P2P Converge Time
>
>
> Vishwas,
>
>         Most of the points here are what I call nits..
>
>         However, the convergence item "C" is the most
>         interesting one. You state that "the same LSDB may be on
>         all the routers and they still may have LSA's on the
>         retransmit list), Maxage etc."
>
>         I consider convergence is when a level of stasis
>         (a non-changing time is present). When LSA are on
>         re-xmit lists, it needs to be assumed that one or
>         more routers (IS's) may not have the LSA. They may
>         have had it and it may have been aged out.
>
>         As a implicit item in my statement, the item may
>         be on the re-xmit list because the one or more
>         other link-partners may have lost its link and
>         the adjacency timer has not yet fired.
>
>         Thus, I was striving for a known state that we
>         are in a state of stable non-changing conditions
>         for at least a moment in time..
>
>         I have seen non-loop free paths and all of the
>         link state databases have identical LSAs. It was
>         due to configuration errors and redistribution
>         differences in a multi-protocol environment.
>
>         Yes, it is a level of more complexity than as
>         the wg's definition.. I have run into a number of
>         people who disagree on really what is meant by
>         convergence. I don't think it really has been
>         stated with a precise definition. So, I was
>         trying to nail it down here...
>
>         Mitchell Erblich
>         =================
>
>
>
>
>
>
> "Manral, Vishwas" wrote:
> >
> > Hi Mitchell,
> >
> > Thanks for the comments. My comments are inline prefixed by a VM>.
> >
> > -Vishwas
> >
> > -----------------------------------------------------------
> > A)
> >
> > 5. Definitions
> >
> >  Hello Interval
> >
> > "and point-to-point networks" -> and non-Demand Circuit point-to-point
> > networks.
> >
> > OR
> >
> > "and point-to-point networks". + Exceptions of some point-to-point
> > circuits are demand point to point circuits, which would be the
> > successful of hello supression negotiation..
> >
> > On the assumption that RFC 1793 Hello suppression is employed.
> > VM> I agree to your point. However I think its an overkill to put all
the
> > special cases in a definition.
> >
> > B) 5. Definitions
> >
> > Shortest Path First Time
> >
> > ADD... Some implimentations may force a interval between
> > successive SPF calculations. If it exists, then this additional time
> > value should be subtracted from the total time.
> > VM> If you check the methodology draft, we have taken care of this.
> >
> > C) Meaning of Convergence
> >
> > I would suggest..
> >
> > A network is termed converged at one point in time when all of the
> > following has occured.
> >
> > * all adjacencies that are to be formed have proceeded to full
> >   state.
> > * all retransmission lists are empty
> > * all recieved update, req LSAs have been processed
> > * All MAXAGE LSAs within the link state databases have been removed
> > * the link state databases are synchronized, exceptions are opaque LSAs
> > * all routers within an area have completed their SPF calculations
> >   and have inserted the results into their respective routing tables
> >
> > VM> The definition of convergence that has been derived has come out
after
> > atleast  40 mail exchanges on the bmwg list. I however do not agree to
> many
> > of the points you state above, like the one on retransmission lists(the
> same
> > LSDB may be on all the routers and they still may have LSA's on the
> > retransmit list), Maxage etc.
> >
> > D) New item....
> >
> > 6.3 Types of Network Events
> >
> > * SPF events / triggers
> >
> > Time the various types of events/triggers that would cause a
> > SPF calculation to occur.
> > VM> I guess that is something we do not require in the draft at all.
> Network
> > events have been listed, as we have given the methodology to find time
to
> > converge when the events occur.
> >
> > Thanks again.
> >
> > "Manral, Vishwas" wrote:
> > >
> > > Hi Mitchell,
> > >
> > > Apologies for the delayed reply(I have been away from my mail for some
> > time
> > > now) and thanks for the comment.
> > >
> > > I guess the point you are trying to make is that although the DR
> election
> > > itself could cause a delay in the broadcast case, there are certain
> other
> > > factors involved.
> > >
> > > However in the context of the discussion, what we have tried to say is
> > that
> > > all other things being the same(as we have put it as "of the same
> speed"),
> > > because on a broadcast network if routers were comming up
symultaneously
> > > they would have to wait for the Waiting interval before electing a DR,
> it
> > > would take a longer time. Also the flooding takes place via the DR/BDR
> and
> > > that causes additional delay. Maybe we will try and modify the text to
> > make
> > > the fact clearer.
> > >
> > > Besides I would like to know of any other point you you would like to
> > > comment on(not agree on) within the draft.
> > >
> > > Thanks,
> > > Vishwas
> > >
> > > -----Original Message-----
> > > From: Erblichs [mailto:erblichs@EARTHLINK.NET]
> > > Sent: Friday, June 07, 2002 12:07 AM
> > > To: OSPF@DISCUSS.MICROSOFT.COM
> > > Subject: draft-bmwg-ospfconv-term-00.:P2P Converge Time
> > >
> > > Group,
> > >
> > >         I have a few items that I don't necessarily agree
> > >         with here, but the one item that I feel most
> > >         strongly with is..
> > >
> > >         5. Definition
> > >         Point-to-Point links
> > >         Discussion      "will take lesser time to converge than
> > >                         a broadcast link"
> > >
> > >         Yes, I do agree that a DR election, mainly due to the
> > >         initial wait time, can become a large part in the time
> > >         to converge.
> > >
> > >         Given that if point-to-point links are substituted for
> > >         broadcast links, I feel that the above statement becomes
> > >         false..
> > >
> > >         Note: adjacencies = adjs
> > >
> > >         Why,,
> > >
> > >         The fewer number of adjs
> > >         allows a fewer number of database description packets to
> > >         be exchanged, a fewer number of master/slave negotiations,
> > >         etc. As each additional adj is formed, there is a higher
> > >          probability that additional SPF calculations will need
> > >         to be performed.
> > >
> > >         In addition, additional flooding due to additional adjs
> > >         will slow the converge process. Also with the additional
> > >         load, the router may identify a overload condition, and
> > >         even temporally reject some of these point-to-point adj
> > >         formations..
> > >
> > >         I am unsure whether a single slow router to inform the
> > >         DR or BDR of its links vs informing all of the adjs of
> > >         its links, will adversely effect the MA vs the P2P link
> > >         topology more. In my mind there are just too many variables.
> > >
> > >         In addition, the statement does not implicitly or explicitly
> > >         imply whether the routing topology has changed and thus
> > >         the BDR is being elected as the DR.
> > >
> > >         THUS, I would consider a different wording to be on the
> > >         order of ... (Please note that I have not mentioned
> > >         Ethernet (shared-meda) type links where collisions with
> > >         exponential backoff may play a role OR....) To keep it
> > >         simple.
> > >
> > >         A point-to-point link network topology makes the tradeoff
> > >         of additional adjacencies formations vs the overhead of
> > >         the required multi-access DR/ BDR election. Given a small
> > >         number of adjacencies in a point-to-point environment, it
> > >         can be more efficent than a multi-access topology if the
> > >         links between the DR and DRothers are constantly changing
> > >         OR that the election wait-time requirement is a large
> > >         part of the convergence time.
> > >
> > >         Thanks,
> > >                 Mitchell Erblich
>


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Jun 18 07:55:18 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13732
	for ; Tue, 18 Jun 2002 07:55:17 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00658187@cherry.ease.lsoft.com>; Tue, 18 Jun 2002 7:55:55 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 17502 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 18 Jun 2002 07:55:55 -0400
Received: from 66.163.169.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Tue, 18 Jun 2002 07:55:54 -0400
Received: from [203.200.20.226] by web21507.mail.yahoo.com via HTTP; Tue, 18
          Jun 2002 04:55:54 PDT
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <20020618115554.82203.qmail@web21507.mail.yahoo.com>
Date:         Tue, 18 Jun 2002 04:55:54 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Amit Srivastava 
Subject: OSPF Retransmission Doubt
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <3D0AF819.8EF408F9@earthlink.net>
Precedence: list

Hi All,
   I have the doubt which is described below:-
Suppose a router is there whose database is full.Now
it can send and receive hello packets but discards any
new LSA coming to it(as database is full) and hence it
will not ack that LSA.Now my doubt is that RFC 2328
says the the retransmission will continue till the
adjacency is broken.
    Does that mean if the database does not have space
for accomodating the new LSA infinite number of
retransmission would result???
Regards
Amit

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Jun 18 08:06:54 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14034
	for ; Tue, 18 Jun 2002 08:06:54 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00658247@cherry.ease.lsoft.com>; Tue, 18 Jun 2002 8:07:33 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 17535 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 18 Jun 2002 08:07:33 -0400
Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Tue, 18 Jun 2002 08:07:32 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id ; Tue, 18 Jun 2002 08:03:01 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  
Date:         Tue, 18 Jun 2002 08:07:13 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: "Manral, Vishwas" 
Subject: Re: OSPF Retransmission Doubt
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi Amit,

You may like to look at the RFC1765 - OSPF Database Overflow.
http://www.ietf.org/rfc/rfc1765.txt This RFC tells a way to deal with such
overflow when it occurs in OSPF.

Also as the RFC lists as enhancements, if the number of summary LSA's
increases we could as well flush type3/4 also and originate default routes
in the domain instead, which could lead to suboptimal routing or blackholing
however.

However in ur case if a router does not accept and acknowledge an LSA, it
will be continuously retransmitted as long as the adjacency is up. If this
is not done, the databases would have no way to come back to synch as the
adjacency itself would not be broken.

Thanks,
Vishwas

-----Original Message-----
From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
Sent: Tuesday, June 18, 2002 5:26 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: OSPF Retransmission Doubt


Hi All,
   I have the doubt which is described below:-
Suppose a router is there whose database is full.Now
it can send and receive hello packets but discards any
new LSA coming to it(as database is full) and hence it
will not ack that LSA.Now my doubt is that RFC 2328
says the the retransmission will continue till the
adjacency is broken.
    Does that mean if the database does not have space
for accomodating the new LSA infinite number of
retransmission would result???
Regards
Amit


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Jun 18 10:04:47 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18078
	for ; Tue, 18 Jun 2002 10:04:47 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.0065855C@cherry.ease.lsoft.com>; Tue, 18 Jun 2002 10:05:24 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 17924 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 18 Jun 2002 10:05:23 -0400
Received: from 66.163.169.14 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Tue, 18 Jun 2002 10:05:23 -0400
Received: from [203.200.20.226] by web21503.mail.yahoo.com via HTTP; Tue, 18
          Jun 2002 07:05:22 PDT
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-2120493646-1024409122=:63946"
Message-ID:  <20020618140522.65261.qmail@web21503.mail.yahoo.com>
Date:         Tue, 18 Jun 2002 07:05:22 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Amit Srivastava 
Subject: Re: OSPF Retransmission Doubt
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  
Precedence: list

--0-2120493646-1024409122=:63946
Content-Type: text/plain; charset=us-ascii


 Hi Vishwas!
          Actually after reading the RFC 1765 only i got this doubt.Here i feel once the OSPFEXTLSDBLinit variable is exceeded the router should indicate other routers that its database is full and they should not keep on retransmitting the LSA which will clog the n/w bandwidth.Once the router comes out of the database overflow state it should indicate to the other router that now they should send the LSA.
      What do you say about this??
Regards
Amit

  "Manral, Vishwas"  wrote: Hi Amit,

You may like to look at the RFC1765 - OSPF Database Overflow.
http://www.ietf.org/rfc/rfc1765.txt This RFC tells a way to deal with such
overflow when it occurs in OSPF.

Also as the RFC lists as enhancements, if the number of summary LSA's
increases we could as well flush type3/4 also and originate default routes
in the domain instead, which could lead to suboptimal routing or blackholing
however.

However in ur case if a router does not accept and acknowledge an LSA, it
will be continuously retransmitted as long as the adjacency is up. If this
is not done, the databases would have no way to come back to synch as the
adjacency itself would not be broken.

Thanks,
Vishwas

-----Original Message-----
From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
Sent: Tuesday, June 18, 2002 5:26 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: OSPF Retransmission Doubt


Hi All,
I have the doubt which is described below:-
Suppose a router is there whose database is full.Now
it can send and receive hello packets but discards any
new LSA coming to it(as database is full) and hence it
will not ack that LSA.Now my doubt is that RFC 2328
says the the retransmission will continue till the
adjacency is broken.
Does that mean if the database does not have space
for accomodating the new LSA infinite number of
retransmission would result???
Regards
Amit


---------------------------------
Do You Yahoo!?
Sign-up for Video Highlights of 2002 FIFA World Cup
--0-2120493646-1024409122=:63946
Content-Type: text/html; charset=us-ascii


 Hi Vishwas!

          Actually after reading the RFC 1765 only i got this doubt.Here i feel once the OSPFEXTLSDBLinit variable is exceeded the router should indicate other routers that its database is full and they should not keep on retransmitting the LSA which will clog the n/w bandwidth.Once the router comes out of the database overflow state it should indicate to the other router that now they should send the LSA.

      What do you say about this??

Regards

Amit     

 

  "Manral, Vishwas" <VishwasM@NETPLANE.COM> wrote:

Hi Amit,

You may like to look at the RFC1765 - OSPF Database Overflow.
http://www.ietf.org/rfc/rfc1765.txt This RFC tells a way to deal with such
overflow when it occurs in OSPF.

Also as the RFC lists as enhancements, if the number of summary LSA's
increases we could as well flush type3/4 also and originate default routes
in the domain instead, which could lead to suboptimal routing or blackholing
however.

However in ur case if a router does not accept and acknowledge an LSA, it
will be continuously retransmitted as long as the adjacency is up. If this
is not done, the databases would have no way to come back to synch as the
adjacency itself would not be broken.

Thanks,
Vishwas

-----Original Message-----
From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
Sent: Tuesday, June 18, 2002 5:26 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: OSPF Retransmission Doubt


Hi All,
I have the doubt which is described below:-
Suppose a router is there whose database is full.Now
it can send and receive hello packets but discards any
new LSA coming to it(as database is full) and hence it
will not ack that LSA.Now my doubt is that RFC 2328
says the the retransmission will continue till the
adjacency is broken.
Does that mean if the database does not have space
for accomodating the new LSA infinite number of
retransmission would result???
Regards
Amit

Do You Yahoo!?

Sign-up for Video Highlights of 2002 FIFA World Cup
--0-2120493646-1024409122=:63946--


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Jun 18 13:17:38 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27036
	for ; Tue, 18 Jun 2002 13:17:38 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00658B12@cherry.ease.lsoft.com>; Tue, 18 Jun 2002 13:17:00 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 18412 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 18 Jun 2002 13:17:00 -0400
Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Tue, 18 Jun 2002 13:16:58 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id ; Tue, 18 Jun 2002 13:12:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C216EB.DE754C30"
Message-ID:  
Date:         Tue, 18 Jun 2002 13:16:22 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: "Manral, Vishwas" 
Subject: Re: OSPF Retransmission Doubt
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C216EB.DE754C30
Content-Type: text/plain;
        charset="iso-8859-1"

Hi Amit,

If you note Section 1. in the RFC it clearly states that the value of
ospfExtLsdbLimit should be the same in all routers in the routing domain. So
the ASBR which is actually attempting to put the external LSA in the domain
will be the first one to overflow, so it will not originate the LSA
itself(the situation you describe will not occur itself).

This RFC is useful, especially cuz we have the entire BGP routing table
acually pumped in into the OSPF domain inadvertently(which supposedly
happens a few times, on the live networks, a year).

I guess if such a state exists when there are routers which cannot keep the
entire database, the network topology/route leaking/routers need a change
instead.

Thanks,
Vishwas

-----Original Message-----
From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
Sent: Tuesday, June 18, 2002 7:35 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: OSPF Retransmission Doubt



Hi Vishwas!


          Actually after reading the RFC 1765 only i got this doubt.Here i
feel once the OSPFEXTLSDBLinit variable is exceeded the router should
indicate other routers that its database is full and they should not keep on
retransmitting the LSA which will clog the n/w bandwidth.Once the router
comes out of the database overflow state it should indicate to the other
router that now they should send the LSA.


      What do you say about this??


Regards


Amit



  "Manral, Vishwas"  wrote:


Hi Amit,

You may like to look at the RFC1765 - OSPF Database Overflow.
http://www.ietf.org/rfc/rfc1765.txt This RFC tells a way to deal with such
overflow when it occurs in OSPF.

Also as the RFC lists as enhancements, if the number of summary LSA's
increases we could as well flush type3/4 also and originate default routes
in the domain instead, which could lead to suboptimal routing or blackholing
however.

However in ur case if a router does not accept and acknowledge an LSA, it
will be continuously retransmitted as long as the adjacency is up. If this
is not done, the databases would have no way to come back to synch as the
adjacency itself would not be broken.

Thanks,
Vishwas

-----Original Message-----
From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
Sent: Tuesday, June 18, 2002 5:26 PM
To: OSPF@DISCUSS.MICROSOFT.COM!
Subject: OSPF Retransmission Doubt


Hi All,
I have the doubt which is described below:-
Suppose a router is there whose database is full.Now
it can send and receive hello packets but discards any
new LSA coming to it(as database is full) and hence it
will not ack that LSA.Now my doubt is that RFC 2328
says the the retransmission will continue till the
adjacency is broken.
Does that mean if the database does not have space
for accomodating the new LSA infinite number of
retransmission would result???
Regards
Amit


------_=_NextPart_001_01C216EB.DE754C30
Content-Type: text/html;
        charset="iso-8859-1"









Hi
Amit,


 


If you
note Section 1. in the RFC it clearly states that the value of ospfExtLsdbLimit
should be the same in all routers in the routing domain. So the ASBR which is
actually attempting to put the external LSA in the domain will be the first one
to overflow, so it will not originate the LSA itself(the situation you describe
will not occur itself).


 


This
RFC is useful, especially cuz we have the entire BGP routing table acually
pumped in into the OSPF domain inadvertently(which supposedly happens a few
times, on the live networks, a year).


 


I
guess if such a state exists when there are routers which cannot keep the entire
database, the network topology/route leaking/routers need a change
instead.


 


Thanks,


Vishwas


 


-----Original Message-----
From: Amit
Srivastava [mailto:ospfisfun@YAHOO.COM]
Sent: Tuesday, June 18, 2002
7:35 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: OSPF
Retransmission Doubt




  
Hi Vishwas!
  
          Actually after
  reading the RFC 1765 only i got this doubt.Here i feel once the
  OSPFEXTLSDBLinit variable is exceeded the router should indicate other routers
  that its database is full and they should not keep on retransmitting the LSA
  which will clog the n/w bandwidth.Once the router comes out of the
  database overflow state it should indicate to the other router that
  now they should send the LSA.
  
      What do you say about this??
  
Regards
  
Amit     
  

  
  "Manral, Vishwas" <VishwasM@NETPLANE.COM> wrote:

  
Hi
    Amit,

You may like to look at the RFC1765 - OSPF Database
    Overflow.
http://www.ietf.org/rfc/rfc1765.txt This RFC tells a way to
    deal with such
overflow when it occurs in OSPF.

Also as the RFC
    lists as enhancements, if the number of summary LSA's
increases we could
    as well flush type3/4 also and originate default routes
in the domain
    instead, which could lead to suboptimal routing or
    blackholing
however.

However in ur case if a router does not
    accept and acknowledge an LSA, it
will be continuously retransmitted as
    long as the adjacency is up. If this
is not done, the databases would
    have no way to come back to synch as the
adjacency itself would not be
    broken.

Thanks,
Vishwas

-----Original Message-----
From:
    Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
Sent: Tuesday, June 18, 2002
    5:26 PM
To: OSPF@DISCUSS.MICROSOFT.COM! 
Subject: OSPF Retransmission
    Doubt


Hi All,
I have the doubt which is described
    below:-
Suppose a router is there whose database is full.Now
it can
    send and receive hello packets but discards any
new LSA coming to it(as
    database is full) and hence it
will not ack that LSA.Now my doubt is that
    RFC 2328
says the the retransmission will continue till the
adjacency
    is broken.
Does that mean if the database does not have space
for
    accomodating the new LSA infinite number of
retransmission would
    result???
Regards
Amit


------_=_NextPart_001_01C216EB.DE754C30--


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Jun 18 16:58:14 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04856
	for ; Tue, 18 Jun 2002 16:58:14 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.006597C4@cherry.ease.lsoft.com>; Tue, 18 Jun 2002 16:58:51 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 18951 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 18 Jun 2002 16:58:51 -0400
Received: from 207.217.120.49 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Tue, 18 Jun 2002 16:58:50 -0400
Received: from user-2ivfm53.dialup.mindspring.com ([165.247.216.163]
          helo=earthlink.net) by scaup.mail.pas.earthlink.net with esmtp (Exim
          3.33 #2) id 17KQ3p-0001pg-00 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 18
          Jun 2002 13:58:45 -0700
X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified)
X-Mailer: Mozilla 4.72 [en]C-gatewaynet  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D0FA153.D8098A61@earthlink.net>
Date:         Tue, 18 Jun 2002 14:08:35 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Erblichs 
Subject: Re: OSPF Retransmission Doubt
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

My two cents...

It is possible that with database overflow, that some routers
will actually have more LSAs in their database than others.

I am thinking about Opaque LSAs (RFC 2370) allowing opaque
capable routers to contain opaque LSAs.

Assuming that these three LSA types are enough to force a
database overflow, it is concieveable to drop all the adjacencies
with the opaque bit set and to re-establish the adjacency without
having the opaque bit set... It may make sense to keep a
counter of opaque LSAs in the lsdb.. Other LSA counters probably
couldn't hurt either..

Be careful if the adjacency is dropped for less than router
dead interval that the change in the opaque bits are seen. A
cleaner change is drop the adjacency for enough time (greater
than routerdeadinterval) and re-establish the adjacency.

To properly do this, it also concievable to wipe away just
the opaque LSAs, before the opaque bit is set, and to keep
the other ones.. Less time to re-establish the full adjs..

Once all the full adjs are re-established, then run the spf
calculation...

Mitchell Erblich
===================



Hi Amit,

If you note Section 1. in the RFC it clearly states that the value of
ospfExtLsdbLimit should be the same in all routers in
the routing domain. So the ASBR which is actually attempting to put the
external LSA in the domain will be the first one
to overflow, so it will not originate the LSA itself(the situation you
describe will not occur itself).

This RFC is useful, especially cuz we have the entire BGP routing table
acually pumped in into the OSPF domain
inadvertently(which supposedly happens a few times, on the live
networks, a year).

I guess if such a state exists when there are routers which cannot keep
the entire database, the network topology/route
leaking/routers need a change instead.

Thanks,
Vishwas

-----Original Message-----
From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
Sent: Tuesday, June 18, 2002 7:35 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: OSPF Retransmission Doubt

     Hi Vishwas!

               Actually after reading the RFC 1765 only i got this
doubt.Here i feel once the
     OSPFEXTLSDBLinit variable is exceeded the router should indicate
other routers that its database is
     full and they should not keep on retransmitting the LSA which will
clog the n/w bandwidth.Once the
     router comes out of the database overflow state it should indicate
to the other router that now they
     should send the LSA.

           What do you say about this??

     Regards

     Amit

       "Manral, Vishwas"  wrote:

            Hi Amit,

            You may like to look at the RFC1765 - OSPF Database
Overflow.
            http://www.ietf.org/rfc/rfc1765.txt This RFC tells a way to
deal with such
            overflow when it occurs in OSPF.

            Also as the RFC lists as enhancements, if the number of
summary LSA's
            increases we could as well flush type3/4 also and originate
default routes
            in the domain instead, which could lead to suboptimal
routing or blackholing
            however.

            However in ur case if a router does not accept and
acknowledge an LSA, it
            will be continuously retransmitted as long as the adjacency
is up. If this
            is not done, the databases would have no way to come back to
synch as the
            adjacency itself would not be broken.

            Thanks,
            Vishwas

            -----Original Message-----
            From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
            Sent: Tuesday, June 18, 2002 5:26 PM
            To: OSPF@DISCUSS.MICROSOFT.COM!
            Subject: OSPF Retransmission Doubt


            Hi All,
            I have the doubt which is described below:-
            Suppose a router is there whose database is full.Now
            it can send and receive hello packets but discards any
            new LSA coming to it(as database is full) and hence it
            will not ack that LSA.Now my doubt is that RFC 2328
            says the the retransmission will continue till the
            adjacency is broken.
            Does that mean if the database does not have space
            for accomodating the new LSA infinite number of
            retransmission would result???
            Regards
            Amit


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Jun 18 20:27:05 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09434
	for ; Tue, 18 Jun 2002 20:27:05 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.0065A025@cherry.ease.lsoft.com>; Tue, 18 Jun 2002 20:27:43 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 19620 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 18 Jun 2002 20:27:43 -0400
Received: from 216.136.175.137 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Tue, 18 Jun 2002 20:27:43 -0400
Received: from [63.251.106.30] by web13704.mail.yahoo.com via HTTP; Tue, 18 Jun
          2002 17:27:43 PDT
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <20020619002743.24284.qmail@web13704.mail.yahoo.com>
Date:         Tue, 18 Jun 2002 17:27:43 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Vishal Mishra 
Subject: Inconsistent Area Checksum (due to Type-10 LSA)
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi Folks,

    Are OSPF Area Checksums inconsistent between Opaque
capable and Opaque-incapable OSPF Neighbours within the same
Area, due to the presence/absence of Type-10 Opaque LSAs in
the converged (stable) state ?

Vishal.

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Jun 18 21:22:31 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10400
	for ; Tue, 18 Jun 2002 21:22:30 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0065A01B@cherry.ease.lsoft.com>; Tue, 18 Jun 2002 21:23:08 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 19750 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 18 Jun 2002 21:23:08 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Tue, 18 Jun 2002 21:23:08 -0400
Received: from redback.com (login003.redback.com [155.53.12.55]) by
          prattle.redback.com (Postfix) with ESMTP id D34DF1B8EF6 for
          ; Tue, 18 Jun 2002 18:23:06 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <20020619002743.24284.qmail@web13704.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D0FDD43.1030100@redback.com>
Date:         Tue, 18 Jun 2002 21:24:19 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: Acee Lindem 
Subject: Re: Inconsistent Area Checksum (due to Type-10 LSA)
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Vishal Mishra wrote:

> Hi Folks,
>
>     Are OSPF Area Checksums inconsistent between Opaque
> capable and Opaque-incapable OSPF Neighbours within the same
> Area, due to the presence/absence of Type-10 Opaque LSAs in
> the converged (stable) state ?


Yup. Refer to section 5.0 in RFC 2370.


>
> Vishal.
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com
>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Jun 19 02:13:36 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24541
	for ; Wed, 19 Jun 2002 02:13:36 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0065AA22@cherry.ease.lsoft.com>; Wed, 19 Jun 2002 2:13:22 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 20375 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 19 Jun 2002 02:13:22 -0400
Received: from 66.163.169.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 19 Jun 2002 02:13:22 -0400
Received: from [203.200.20.226] by web21506.mail.yahoo.com via HTTP; Tue, 18
          Jun 2002 23:13:21 PDT
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1680505106-1024467201=:69165"
Message-ID:  <20020619061321.71491.qmail@web21506.mail.yahoo.com>
Date:         Tue, 18 Jun 2002 23:13:21 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Amit Srivastava 
Subject: Re: OSPF Retransmission Doubt
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <20020618140522.65261.qmail@web21503.mail.yahoo.com>
Precedence: list

--0-1680505106-1024467201=:69165
Content-Type: text/plain; charset=us-ascii


 Hi Erblich and Vishwas,
      Erblich I got your point but is there any Draft or RFC which
states
this??
     And Vishwas thanks for your help i would also like to know if
there is any draft which states that we can withdraw Summary 3 and 4
non-default LSA.Because The RFC 2370 specks very little about it.
Regards
Amit

  Amit Srivastava  wrote:
Hi Vishwas!
          Actually after reading the RFC 1765 only i got this doubt.Here i feel once the OSPFEXTLSDBLinit variable is exceeded the router should indicate other routers that its database is full and they should not keep on retransmitting the LSA which will clog the n/w bandwidth.Once the router comes out of the database overflow state it should indicate to the other router that now they should send the LSA.
      What do you say about this??
Regards
Amit

  "Manral, Vishwas"  wrote: Hi Amit,

You may like to look at the RFC1765 - OSPF Database Overflow.
http://www.ietf.org/rfc/rfc1765.txt This RFC tells a way to deal with such
overflow when it occurs in OSPF.

Also as the RFC lists as enhancements, if the number of summary LSA's
increases we could as well flush type3/4 also and originate default routes
in the domain instead, which could lead to suboptimal routing or blackholing
however.

However in ur case if a router does not accept and acknowledge an LSA, it
will be continuously retransmitted as long as the adjacency is up. If this
is not done, the databases would have no way to come back to synch as the
adjacency itself would not be broken.

Thanks,
Vishwas

-----Original Message-----
From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
Sent: Tuesday, June 18, 2002 5:26 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: OSPF Retransmission Doubt


Hi All,
I have the doubt which is described below:-
Suppose a router is there whose database is full.Now
it can send and receive hello packets but discards any
new LSA coming to it(as database is full) and hence it
will not ack that LSA.Now my doubt is that RFC 2328
says the the retransmission will continue till the
adjacency is broken.
Does that mean if the database does not have space
for accomodating the new LSA infinite number of
retransmission would result???
Regards
Amit


---------------------------------
Do You Yahoo!?
Sign-up for Video Highlights of 2002 FIFA World Cup


---------------------------------
Do You Yahoo!?
Sign-up for Video Highlights of 2002 FIFA World Cup
--0-1680505106-1024467201=:69165
Content-Type: text/html; charset=us-ascii


 Hi Erblich and Vishwas,
      Erblich I got your point but is there any Draft or RFC which 
states 
this??
     And Vishwas thanks for your help i would also like to know if 
there is any draft which states that we can withdraw Summary 3 and 4  
non-default LSA.Because The RFC 2370 specks very little about it.
Regards
Amit


  Amit Srivastava <ospfisfun@YAHOO.COM> wrote:



Hi Vishwas!

          Actually after reading the RFC 1765 only i got this doubt.Here i feel once the OSPFEXTLSDBLinit variable is exceeded the router should indicate other routers that its database is full and they should not keep on retransmitting the LSA which will clog the n/w bandwidth.Once the router comes out of the database overflow state it should indicate to the other router that now they should send the LSA.

      What do you say about this??

Regards

Amit     



  "Manral, Vishwas" <VishwasM@NETPLANE.COM> wrote:

Hi Amit,

You may like to look at the RFC1765 - OSPF Database Overflow.
http://www.ietf.org/rfc/rfc1765.txt This RFC tells a way to deal with such
overflow when it occurs in OSPF.

Also as the RFC lists as enhancements, if the number of summary LSA's
increases we could as well flush type3/4 also and originate default routes
in the domain instead, which could lead to suboptimal routing or blackholing
however.

However in ur case if a router does not accept and acknowledge an LSA, it
will be continuously retransmitted as long as the adjacency is up. If this
is not done, the databases would have no way to come back to synch as the
adjacency itself would not be broken.

Thanks,
Vishwas

-----Original Message-----
From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
Sent: Tuesday, June 18, 2002 5:26 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: OSPF Retransmission Doubt


Hi All,
I have the doubt which is described below:-
Suppose a router is there whose database is full.Now
it can send and receive hello packets but discards any
new LSA coming to it(as database is full) and hence it
will not ack that LSA.Now my doubt is that RFC 2328
says the the retransmission will continue till the
adjacency is broken.
Does that mean if the database does not have space
for accomodating the new LSA infinite number of
retransmission would result???
Regards
Amit






Do You Yahoo!?
Sign-up for Video Highlights of 2002 FIFA World Cup

Do You Yahoo!?

Sign-up for Video Highlights of 2002 FIFA World Cup
--0-1680505106-1024467201=:69165--


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Jun 19 04:56:46 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11215
	for ; Wed, 19 Jun 2002 04:56:46 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0065B1B4@cherry.ease.lsoft.com>; Wed, 19 Jun 2002 4:57:23 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 20888 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 19 Jun 2002 04:57:23 -0400
Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 19 Jun 2002 04:57:23 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id ; Wed, 19 Jun 2002 04:52:51 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C2176F.46F9A610"
Message-ID:  
Date:         Wed, 19 Jun 2002 04:57:01 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: "Manral, Vishwas" 
Subject: Re: OSPF Retransmission Doubt
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2176F.46F9A610
Content-Type: text/plain;
        charset="iso-8859-1"

Hi Amit,

I do not think any RFC which talks about non-default type-3 LSA's exists.
The RFC1765 only talks about type-5 LSA's however it could be extended for
other type of LSA's i.e. type-7, type-11.

Thanks,
Vishwas

-----Original Message-----
From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
Sent: Wednesday, June 19, 2002 11:43 AM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: OSPF Retransmission Doubt



 Hi Erblich and Vishwas,
      Erblich I got your point but is there any Draft or RFC which
states
this??
     And Vishwas thanks for your help i would also like to know if
there is any draft which states that we can withdraw Summary 3 and 4
non-default LSA.Because The RFC 2370 specks very little about it.
Regards
Amit



  Amit Srivastava  wrote:


Hi Vishwas!


          Actually after reading the RFC 1765 only i got this doubt.Here i
feel once the OSPFEXTLSDBLinit variable is exceeded the router should
indicate other routers that its database is full and they should not keep on
retransmitting the LSA which will clog the n/w bandwidth.Once the router
comes out of the database overflow state it should indicate to the other
router that now they should send the LSA.


      What do you say about this??


Regards


Amit



  "Manral, Vishwas"  wrote:


Hi Amit,

You may like to look at the RFC1765 - OSPF Database Overflow.
http://www.ietf.org/rfc/rfc1765.txt This RFC tells a way to deal with such
overflow when it occurs in OSPF.

Also as the RFC lists as enhancements, if the number of summary LSA's
increases we could as well flush type3/4 also and originate default routes
in the domain instead, which could lead to suboptimal routing or blackholing
however.

However in ur case if a router does not accept and acknowledge an LSA, it
will be continuously retransmitted as long as the adjacency is up. If this
is not done, the databases would have no way to come back to synch as the
adjacency itself would not be broken.

Thanks,
Vishwas

-----Original Message-----
From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
Sent: Tuesday, June 18, 2002 5:26 PM
To: OSPF@DISCUSS.MICROSOFT.COM!
Subject: OSPF Retransmission Doubt


Hi All,
I have the doubt which is described below:-
Suppose a router is there whose database is full.Now
it can send and receive hello packets but discards any
new LSA coming to it(as database is full) and hence it
will not ack that LSA.Now my doubt is that RFC 2328
says the the retransmission will continue till the
adjacency is broken.
Does that mean if the database does not have space
for accomodating the new LSA infinite number of
retransmission would result???
Regards
Amit


------_=_NextPart_001_01C2176F.46F9A610
Content-Type: text/html;
        charset="iso-8859-1"









Hi
Amit,


 


I do
not think any RFC which talks about non-default type-3 LSA's exists. The RFC1765
only talks about type-5 LSA's however it could be extended for other type of
LSA's i.e. type-7, type-11.


 


Thanks,


Vishwas



  
-----Original Message-----
From: Amit Srivastava
  [mailto:ospfisfun@YAHOO.COM]
Sent: Wednesday, June 19, 2002 11:43
  AM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: OSPF
  Retransmission Doubt


  
 Hi Erblich and Vishwas,
      Erblich I
  got your point but is there any Draft or RFC which 
states
  
this??
     And Vishwas thanks for your help i
  would also like to know if 
there is any draft which states that we can
  withdraw Summary 3 and 4  
non-default LSA.Because The RFC 2370 specks
  very little about it.
Regards
Amit

  
  Amit Srivastava <ospfisfun@YAHOO.COM> wrote:
  

    
Hi Vishwas!
    
          Actually after
    reading the RFC 1765 only i got this doubt.Here i feel once the
    OSPFEXTLSDBLinit variable is exceeded the router should indicate other
    routers that its database is full and they should not keep on retransmitting
    the LSA which will clog the n/w bandwidth.Once the router comes out of the
    database overflow state it should indicate to the other router
    that now they should send the LSA.
    
      What do you say about this??
    
Regards
    
Amit     
    

    
  "Manral, Vishwas" <VishwasM@NETPLANE.COM>
    wrote:
    
Hi
      Amit,

You may like to look at the RFC1765 - OSPF Database
      Overflow.
http://www.ietf.org/rfc/rfc1765.txt This RFC tells a way to
      deal with such
overflow when it occurs in OSPF.

Also as the RFC
      lists as enhancements, if the number of summary LSA's
increases we
      could as well flush type3/4 also and originate default routes
in the
      domain instead, which could lead to suboptimal routing or
      blackholing
however.

However in ur case if a router does not
      accept and acknowledge an LSA, it
will be continuously retransmitted as
      long as the adjacency is up. If this
is not done, the databases would
      have no way to come back to synch as the
adjacency itself would not be
      broken.

Thanks,
Vishwas

-----Original
      Message-----
From: Amit Srivastava
      [mailto:ospfisfun@YAHOO.COM]
Sent: Tuesday, June 18, 2002 5:26
      PM
To: OSPF@DISCUSS.MICROSOFT.COM! 
Subject: OSPF Retransmission
      Doubt


Hi All,
I have the doubt which is described
      below:-
Suppose a router is there whose database is full.Now
it can
      send and receive hello packets but discards any
new LSA coming to it(as
      database is full) and hence it
will not ack that LSA.Now my doubt is
      that RFC 2328
says the the retransmission will continue till
      the
adjacency is broken.
Does that mean if the database does not
      have space
for accomodating the new LSA infinite number
      of
retransmission would
  result???
Regards
Amit


------_=_NextPart_001_01C2176F.46F9A610--


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Jun 19 07:38:56 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14173
	for ; Wed, 19 Jun 2002 07:38:56 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.0065B49B@cherry.ease.lsoft.com>; Wed, 19 Jun 2002 7:39:34 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 21704 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 19 Jun 2002 07:39:35 -0400
Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 19 Jun 2002 07:29:35 -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id HAA13572; Wed, 19 Jun 2002 07:27:53
          -0400 (EDT)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Message-ID:  <200206191127.HAA13572@ietf.org>
Date:         Wed, 19 Jun 2002 07:27:53 -0400
Reply-To: Mailing List 
Sender: Mailing List 
Comments:     RFC822 error:  Incorrect or incomplete address field found and
              ignored.
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ash-ospf-isis-congestion-control-02.txt
Comments: cc: isis-wg@juniper.net
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


        Title           : Proposed Mechanisms for Congestion Control/Failure
                          Recovery in OSPF & ISIS Networks
        Author(s)       : J. Ash et al.
        Filename        : draft-ash-ospf-isis-congestion-control-02.txt
        Pages           :
        Date            : 18-Jun-02

Earlier papers and contributions identified issues of congestion control and failure recovery for link-state protocol networks, such as OSPF, ISIS, and PNNI networks [maunder, choudhury, pappalardo1, pappalardo2, atm01-0101]. The problem addressed is to enable link-state protocols to a) gracefully recover from massive loss of topology database information, and b) respond gracefully to network overloads and failures. This contribution proposes specific additional considerations for network congestion control/failure recovery.  Candidate mechanisms are proposed for control of network congestion and failure recovery, in particular we initially propose to investigate the following mechanisms:
a)      throttle new connection setups, topology-state updates, and Hello updates based on automatic congestion control mechanisms,
b)      special marking of critical control messages (e.g., Hello and
topology-state-update Ack) so that they may receive prioritized processing,
c)      database backup, in which a topology database could be automatically recovered from loss based on local backup mechanisms, and
d)      hitless restart, which allows routes to continue to be used if there is an uninterrupted data path, even if the control path is interrupted due to a failure.
We propose that the OSPF and ISIS working groups include the candidate
mechanisms in an evaluation of congestion control/failure recovery for OSPF and ISIS networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ash-ospf-isis-congestion-control-02.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-ash-ospf-isis-congestion-control-02.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-ash-ospf-isis-congestion-control-02.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:     <20020618132155.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ash-ospf-isis-congestion-control-02.txt

--OtherAccess
Content-Type: Message/External-body;
        name="draft-ash-ospf-isis-congestion-control-02.txt";
        site="ftp.ietf.org";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <20020618132155.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Jun 19 08:25:41 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15583
	for ; Wed, 19 Jun 2002 08:25:41 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.0065B531@cherry.ease.lsoft.com>; Wed, 19 Jun 2002 8:26:20 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 21782 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 19 Jun 2002 08:26:20 -0400
Received: from 205.158.62.50 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 19 Jun 2002 08:16:19 -0400
Received: (qmail 56934 invoked by uid 1001); 19 Jun 2002 12:16:18 -0000
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-Mailer: MIME-tools 5.41 (Entity 5.404)
Received: from [129.187.222.167] by ws1-4.us4.outblaze.com with http for
          beatriz_hargrave@mail.com; Wed, 19 Jun 2002 07:16:18 -0500
X-Originating-Ip: 129.187.222.167
X-Originating-Server: ws1-4.us4.outblaze.com
Message-ID:  <20020619121618.56933.qmail@mail.com>
Date:         Wed, 19 Jun 2002 07:16:18 -0500
Reply-To: Mailing List 
Sender: Mailing List 
From: Beatriz Silva 
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi everybody !

I just joined the list ...


I would like to know if anybody knows how does the multicast address
AllSPFrouters (224.0.0.5) works. Do I have to configure somewhere the
computers who belong to this multicast group ? Or do I have to
configure my computer to listen to packets with this multicast
address ? And how do I do that ?

Does anybody knows other e-mail lists where people discuss only about
OSPF ??

Thank you very much,

Beatriz


--
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

Save up to $160 by signing up for NetZero Platinum Internet service.
http://www.netzero.net/?refcd=N2P0602NEP8


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Jun 19 09:13:59 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17142
	for ; Wed, 19 Jun 2002 09:13:59 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0065B6CC@cherry.ease.lsoft.com>; Wed, 19 Jun 2002 9:13:34 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 21851 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 19 Jun 2002 09:13:34 -0400
Received: from 47.129.242.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 19 Jun 2002 09:03:34 -0400
Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com
          [132.245.205.62]) by zcars04f.ca.nortel.com
          (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5JD3Vm14889 for
          ; Wed, 19 Jun 2002 09:03:31 -0400 (EDT)
Received: by zbl6c012.corpeast.baynetworks.com with Internet Mail Service
          (5.5.2653.19) id ; Wed, 19 Jun 2002 09:03:31 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C21791.B4CCE9A0"
Message-ID:  <8B888AAAAB0FD31189590008C79184430B507DA3@zbl6c002.corpeast.baynetworks.com>
Date:         Wed, 19 Jun 2002 09:03:29 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: Ruth Fax 
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C21791.B4CCE9A0
Content-Type: text/plain;
        charset="iso-8859-1"

Hi Beatriz,

Your operating system will provide multicast services.
If you are using the socket interface on a UNIX like OS, you can use a
socket
to listen on the multicast address and another socket to send
to the multicast addresss.  See Stevens, "UNIX Network Programming".

--Ruth


-----Original Message-----
From: Beatriz Silva [mailto:beatriz_hargrave@MAIL.COM]
Sent: Wednesday, June 19, 2002 8:16 AM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject:


Hi everybody !

I just joined the list ...


I would like to know if anybody knows how does the multicast address
AllSPFrouters (224.0.0.5) works. Do I have to configure somewhere the
computers who belong to this multicast group ? Or do I have to
configure my computer to listen to packets with this multicast
address ? And how do I do that ?

Does anybody knows other e-mail lists where people discuss only about
OSPF ??

Thank you very much,

Beatriz


--
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

Save up to $160 by signing up for NetZero Platinum Internet service.
http://www.netzero.net/?refcd=N2P0602NEP8

------_=_NextPart_001_01C21791.B4CCE9A0
Content-Type: text/html;
        charset="iso-8859-1"






RE: 




Hi Beatriz,




Your operating system will provide multicast services.

If you are using the socket interface on a UNIX like OS, you can use a socket

to listen on the multicast address and another socket to send

to the multicast addresss.  See Stevens, "UNIX Network Programming".




--Ruth






-----Original Message-----

From: Beatriz Silva [mailto:beatriz_hargrave@MAIL.COM]

Sent: Wednesday, June 19, 2002 8:16 AM

To: OSPF@DISCUSS.MICROSOFT.COM

Subject: 






Hi everybody !




I just joined the list ...






I would like to know if anybody knows how does the multicast address

AllSPFrouters (224.0.0.5) works. Do I have to configure somewhere the

computers who belong to this multicast group ? Or do I have to

configure my computer to listen to packets with this multicast

address ? And how do I do that ?




Does anybody knows other e-mail lists where people discuss only about

OSPF ??




Thank you very much,




Beatriz






--

__________________________________________________________

Sign-up for your own FREE Personalized E-mail at Mail.com

http://www.mail.com/?sr=signup




Save up to $160 by signing up for NetZero Platinum Internet service.

http://www.netzero.net/?refcd=N2P0602NEP8





------_=_NextPart_001_01C21791.B4CCE9A0--


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Jun 19 10:05:51 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19349
	for ; Wed, 19 Jun 2002 10:05:51 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0065B797@cherry.ease.lsoft.com>; Wed, 19 Jun 2002 10:06:28 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 22115 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 19 Jun 2002 10:06:28 -0400
Received: from 205.158.62.50 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 19 Jun 2002 10:06:28 -0400
Received: (qmail 3244 invoked by uid 1001); 19 Jun 2002 14:06:27 -0000
Content-Type: text/html; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-Mailer: MIME-tools 5.41 (Entity 5.404)
Received: from [129.187.222.168] by ws1-4.us4.outblaze.com with http for
          beatriz_hargrave@mail.com; Wed, 19 Jun 2002 09:06:27 -0500
X-Originating-Ip: 129.187.222.168
X-Originating-Server: ws1-4.us4.outblaze.com
Message-ID:  <20020619140627.3242.qmail@mail.com>
Date:         Wed, 19 Jun 2002 09:06:27 -0500
Reply-To: Mailing List 
Sender: Mailing List 
From: Beatriz Silva 
Subject: Multicast address OSPF
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit


Thanks Ruth.


But what about if I am using Windows ?


Does anybody knows about any library for OSPF protocol ?


Thanks,


Beatriz


 


 


 




----- Original Message -----
From: Ruth Fax 
Date: Wed, 19 Jun 2002 09:03:29 -0400
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: 


Content-Type: text/html; charset="iso-8859-1" 



Hi Beatriz, 


Your operating system will provide multicast services. 
If you are using the socket interface on a UNIX like OS, you can use a socket 
to listen on the multicast address and another socket to send 
to the multicast addresss.  See Stevens, "UNIX Network Programming". 


--Ruth 



-----Original Message----- 
From: Beatriz Silva [mailto:beatriz_hargrave@MAIL.COM] 
Sent: Wednesday, June 19, 2002 8:16 AM 
To: OSPF@DISCUSS.MICROSOFT.COM 
Subject: 



Hi everybody ! 


I just joined the list ... 



I would like to know if anybody knows how does the multicast address 
AllSPFrouters (224.0.0.5) works. Do I have to configure somewhere the 
computers who belong to this multicast group ? Or do I have to 
configure my computer to listen to packets with this multicast 
address ? And how do I do that ? 


Does anybody knows other e-mail lists where people discuss only about 
OSPF ?? 


Thank you very much, 


Beatriz 



-- 
__________________________________________________________ 
Sign-up for your own FREE Personalized E-mail at Mail.com 
http://www.mail.com/?sr=signup 


Save up to $160 by signing up for NetZero Platinum Internet service. 
http://www.netzero.net/?refcd=N2P0602NEP8 

--

_______________________________________________

Sign-up for your own FREE Personalized E-mail at Mail.com



Save up to $160 by signing up for NetZero Platinum Internet service.



From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Jun 19 10:20:58 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20147
	for ; Wed, 19 Jun 2002 10:20:58 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0065B862@cherry.ease.lsoft.com>; Wed, 19 Jun 2002 10:21:35 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 22158 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 19 Jun 2002 10:21:35 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 19 Jun 2002 10:21:34 -0400
Received: from redback.com (login003.redback.com [155.53.12.55]) by
          prattle.redback.com (Postfix) with ESMTP id E9089F2C51 for
          ; Wed, 19 Jun 2002 07:21:33 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <20020619140627.3242.qmail@mail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D1093AF.1060806@redback.com>
Date:         Wed, 19 Jun 2002 10:22:39 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: Acee Lindem 
Subject: Re: Multicast address OSPF
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Beatriz Silva wrote:

> Thanks Ruth.
>
> But what about if I am using Windows ?


Linux can easily be installed over a Windows. If for some
reason you want to keep your Windows, there is always
dual boot.


>
> Does anybody knows about any library for OSPF protocol ?


Check out John's GNU public license OSPF distribution at www.ospf.org.

>
> Thanks,
>
> Beatriz
>
>
>
>
>
>
>
>
>
> ----- Original Message -----
> From: Ruth Fax
> Date: Wed, 19 Jun 2002 09:03:29 -0400
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject:
>
>
> Content-Type: text/html; charset="iso-8859-1"
>
> Hi Beatriz,
>
> Your operating system will provide multicast services.
> If you are using the socket interface on a UNIX like OS, you can use a
> socket
> to listen on the multicast address and another socket to send
> to the multicast addresss.  See Stevens, "UNIX Network Programming".
>
> --Ruth
>
>
> -----Original Message-----
> From: Beatriz Silva [mailto:beatriz_hargrave@MAIL.COM]
> Sent: Wednesday, June 19, 2002 8:16 AM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject:
>
>
> Hi everybody !
>
> I just joined the list ...
>
>
> I would like to know if anybody knows how does the multicast address
> AllSPFrouters (224.0.0.5) works. Do I have to configure somewhere the
> computers who belong to this multicast group ? Or do I have to
> configure my computer to listen to packets with this multicast
> address ? And how do I do that ?
>
> Does anybody knows other e-mail lists where people discuss only about
> OSPF ??
>
> Thank you very much,
>
> Beatriz
>
>
> --
> __________________________________________________________
> Sign-up for your own FREE Personalized E-mail at Mail.com
> http://www.mail.com/?sr=signup
>
> Save up to $160 by signing up for NetZero Platinum Internet service.
> http://www.netzero.net/?refcd=N2P0602NEP8
>
> --
>
> _______________________________________________
> Sign-up for your own FREE Personalized E-mail at Mail.com
> 
>
> Save up to $160 by signing up for NetZero Platinum Internet service
> .
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Jun 19 10:36:03 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20754
	for ; Wed, 19 Jun 2002 10:36:03 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0065B8B0@cherry.ease.lsoft.com>; Wed, 19 Jun 2002 10:36:41 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 22206 for OSPF@DISCUSS.MICROSOFT.COM;
          Wed, 19 Jun 2002 10:36:40 -0400
Received: from 192.11.222.161 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Wed, 19 Jun 2002 10:36:40 -0400
Received: from ma8117exch001p.wins.lucent.com (h152-148-89-177.lucent.com
          [152.148.89.177]) by ihemail1.firewall.lucent.com
          (Switch-2.2.2/Switch-2.2.0) with ESMTP id g5JEadN22977 for
          ; Wed, 19 Jun 2002 10:36:39 -0400 (EDT)
Received: by ma8117exch001p.inse.lucent.com with Internet Mail Service
          (5.5.2653.19) id ; Wed, 19 Jun 2002 10:36:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Message-ID:  
Date:         Wed, 19 Jun 2002 10:36:35 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: "Joyal, Daniel R (Daniel)" 
Subject: Re: Multicast address OSPF
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Windows has it's own socket library, WinSock, which provides
functionality similar to UNIX sockets.

-Dan

-----Original Message-----
From: Acee Lindem [mailto:acee@REDBACK.COM]
Sent: Wednesday, June 19, 2002 10:23 AM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: Multicast address OSPF


Beatriz Silva wrote:

> Thanks Ruth.
>
> But what about if I am using Windows ?


Linux can easily be installed over a Windows. If for some
reason you want to keep your Windows, there is always
dual boot.


>
> Does anybody knows about any library for OSPF protocol ?


Check out John's GNU public license OSPF distribution at www.ospf.org.

>
> Thanks,
>
> Beatriz
>
>
>
>
>
>
>
>
>
> ----- Original Message -----
> From: Ruth Fax
> Date: Wed, 19 Jun 2002 09:03:29 -0400
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject:
>
>
> Content-Type: text/html; charset="iso-8859-1"
>
> Hi Beatriz,
>
> Your operating system will provide multicast services.
> If you are using the socket interface on a UNIX like OS, you can use a
> socket
> to listen on the multicast address and another socket to send
> to the multicast addresss.  See Stevens, "UNIX Network Programming".
>
> --Ruth
>
>
> -----Original Message-----
> From: Beatriz Silva [mailto:beatriz_hargrave@MAIL.COM]
> Sent: Wednesday, June 19, 2002 8:16 AM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject:
>
>
> Hi everybody !
>
> I just joined the list ...
>
>
> I would like to know if anybody knows how does the multicast address
> AllSPFrouters (224.0.0.5) works. Do I have to configure somewhere the
> computers who belong to this multicast group ? Or do I have to
> configure my computer to listen to packets with this multicast
> address ? And how do I do that ?
>
> Does anybody knows other e-mail lists where people discuss only about
> OSPF ??
>
> Thank you very much,
>
> Beatriz
>
>
> --
> __________________________________________________________
> Sign-up for your own FREE Personalized E-mail at Mail.com
> http://www.mail.com/?sr=signup
>
> Save up to $160 by signing up for NetZero Platinum Internet service.
> http://www.netzero.net/?refcd=N2P0602NEP8
>
> --
>
> _______________________________________________
> Sign-up for your own FREE Personalized E-mail at Mail.com
> 
>
> Save up to $160 by signing up for NetZero Platinum Internet service
> .
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Jun 20 00:53:34 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10932
	for ; Thu, 20 Jun 2002 00:53:34 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.0065D3AB@cherry.ease.lsoft.com>; Thu, 20 Jun 2002 0:54:02 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 24326 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 20 Jun 2002 00:54:02 -0400
Received: from 66.163.169.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 20 Jun 2002 00:54:01 -0400
Received: from [203.200.20.226] by web21505.mail.yahoo.com via HTTP; Wed, 19
          Jun 2002 21:54:00 PDT
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <20020620045401.97741.qmail@web21505.mail.yahoo.com>
Date:         Wed, 19 Jun 2002 21:54:00 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Amit Srivastava 
Subject: Re: OSPF Retransmission Doubt
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  
Precedence: list

Hi Vishwas,
   I have a small doubt .If u refer to section 2.2 and
2.3 of RFC 1765 it states that during flooding also
the variable count of non-default AS_external LSA is
incremented( if we receive a non-default AS-external
LSA during flooding).But if we have a common thresh
hold limit i.e variable ospfExtlsdbLimit is same for
all the router how come this condition will be
encountered???
Regards
Amit




--- "Manral, Vishwas"  wrote:
> Hi Amit,
>
> I do not think any RFC which talks about non-default
> type-3 LSA's exists.
> The RFC1765 only talks about type-5 LSA's however it
> could be extended for
> other type of LSA's i.e. type-7, type-11.
>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
> Sent: Wednesday, June 19, 2002 11:43 AM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Re: OSPF Retransmission Doubt
>
>
>
>  Hi Erblich and Vishwas,
>       Erblich I got your point but is there any
> Draft or RFC which
> states
> this??
>      And Vishwas thanks for your help i would also
> like to know if
> there is any draft which states that we can withdraw
> Summary 3 and 4
> non-default LSA.Because The RFC 2370 specks very
> little about it.
> Regards
> Amit
>
>
>
>   Amit Srivastava  wrote:
>
>
> Hi Vishwas!
>
>
>           Actually after reading the RFC 1765 only i
> got this doubt.Here i
> feel once the OSPFEXTLSDBLinit variable is exceeded
> the router should
> indicate other routers that its database is full and
> they should not keep on
> retransmitting the LSA which will clog the n/w
> bandwidth.Once the router
> comes out of the database overflow state it should
> indicate to the other
> router that now they should send the LSA.
>
>
>       What do you say about this??
>
>
> Regards
>
>
> Amit
>
>
>
>   "Manral, Vishwas"  wrote:
>
>
> Hi Amit,
>
> You may like to look at the RFC1765 - OSPF Database
> Overflow.
> http://www.ietf.org/rfc/rfc1765.txt This RFC tells a
> way to deal with such
> overflow when it occurs in OSPF.
>
> Also as the RFC lists as enhancements, if the number
> of summary LSA's
> increases we could as well flush type3/4 also and
> originate default routes
> in the domain instead, which could lead to
> suboptimal routing or blackholing
> however.
>
> However in ur case if a router does not accept and
> acknowledge an LSA, it
> will be continuously retransmitted as long as the
> adjacency is up. If this
> is not done, the databases would have no way to come
> back to synch as the
> adjacency itself would not be broken.
>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
> Sent: Tuesday, June 18, 2002 5:26 PM
> To: OSPF@DISCUSS.MICROSOFT.COM!
> Subject: OSPF Retransmission Doubt
>
>
> Hi All,
> I have the doubt which is described below:-
> Suppose a router is there whose database is full.Now
> it can send and receive hello packets but discards
> any
> new LSA coming to it(as database is full) and hence
> it
> will not ack that LSA.Now my doubt is that RFC 2328
> says the the retransmission will continue till the
> adjacency is broken.
> Does that mean if the database does not have space
> for accomodating the new LSA infinite number of
> retransmission would result???
> Regards
> Amit
>
>


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Jun 20 08:26:57 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27151
	for ; Thu, 20 Jun 2002 08:26:57 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0065DD02@cherry.ease.lsoft.com>; Thu, 20 Jun 2002 8:27:36 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 25412 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 20 Jun 2002 08:27:36 -0400
Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 20 Jun 2002 08:27:36 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id ; Thu, 20 Jun 2002 08:23:03 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  
Date:         Thu, 20 Jun 2002 08:27:16 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: "Manral, Vishwas" 
Subject: Re: OSPF Retransmission Doubt
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi Amit,

The case would not occur if all the routers would have the same value of
ExtLSDBLimit except in the transient condition. Section 2.2 first part would
only occur if the value is not the same this may be required. Its always
better to check the condition, if we are exceeding the limit and accordingly
take action to get over any such a case.

Section 2.3 states that the flooding modification would only be invoked
during a "short period of convergence" for same value of LSDBLimit. Such a
case would only occur say when two routers are symultaneously originating
AS-External LSA's. So when they are originating the LSA's the LSDB limit is
not exceeded however when they are receiving the LSA's from the other the
LSDB limit is exceeded. However as the RFC states this would be a transient
condition.

Thanks,
Vishwas

-----Original Message-----
From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
Sent: Thursday, June 20, 2002 10:24 AM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: OSPF Retransmission Doubt


Hi Vishwas,
   I have a small doubt .If u refer to section 2.2 and
2.3 of RFC 1765 it states that during flooding also
the variable count of non-default AS_external LSA is
incremented( if we receive a non-default AS-external
LSA during flooding).But if we have a common thresh
hold limit i.e variable ospfExtlsdbLimit is same for
all the router how come this condition will be
encountered???
Regards
Amit




--- "Manral, Vishwas"  wrote:
> Hi Amit,
>
> I do not think any RFC which talks about non-default
> type-3 LSA's exists.
> The RFC1765 only talks about type-5 LSA's however it
> could be extended for
> other type of LSA's i.e. type-7, type-11.
>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
> Sent: Wednesday, June 19, 2002 11:43 AM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Re: OSPF Retransmission Doubt
>
>
>
>  Hi Erblich and Vishwas,
>       Erblich I got your point but is there any
> Draft or RFC which
> states
> this??
>      And Vishwas thanks for your help i would also
> like to know if
> there is any draft which states that we can withdraw
> Summary 3 and 4
> non-default LSA.Because The RFC 2370 specks very
> little about it.
> Regards
> Amit
>
>
>
>   Amit Srivastava  wrote:
>
>
> Hi Vishwas!
>
>
>           Actually after reading the RFC 1765 only i
> got this doubt.Here i
> feel once the OSPFEXTLSDBLinit variable is exceeded
> the router should
> indicate other routers that its database is full and
> they should not keep on
> retransmitting the LSA which will clog the n/w
> bandwidth.Once the router
> comes out of the database overflow state it should
> indicate to the other
> router that now they should send the LSA.
>
>
>       What do you say about this??
>
>
> Regards
>
>
> Amit
>
>   "Manral, Vishwas"  wrote:
>
>
> Hi Amit,
>
> You may like to look at the RFC1765 - OSPF Database
> Overflow.
> http://www.ietf.org/rfc/rfc1765.txt This RFC tells a
> way to deal with such
> overflow when it occurs in OSPF.
>
> Also as the RFC lists as enhancements, if the number
> of summary LSA's
> increases we could as well flush type3/4 also and
> originate default routes
> in the domain instead, which could lead to
> suboptimal routing or blackholing
> however.
>
> However in ur case if a router does not accept and
> acknowledge an LSA, it
> will be continuously retransmitted as long as the
> adjacency is up. If this
> is not done, the databases would have no way to come
> back to synch as the
> adjacency itself would not be broken.
>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
> Sent: Tuesday, June 18, 2002 5:26 PM
> To: OSPF@DISCUSS.MICROSOFT.COM!
> Subject: OSPF Retransmission Doubt
>
>
> Hi All,
> I have the doubt which is described below:-
> Suppose a router is there whose database is full.Now
> it can send and receive hello packets but discards
> any
> new LSA coming to it(as database is full) and hence
> it
> will not ack that LSA.Now my doubt is that RFC 2328
> says the the retransmission will continue till the
> adjacency is broken.
> Does that mean if the database does not have space
> for accomodating the new LSA infinite number of
> retransmission would result???
> Regards
> Amit


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Jun 20 12:02:23 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04467
	for ; Thu, 20 Jun 2002 12:02:23 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.0065E1F1@cherry.ease.lsoft.com>; Thu, 20 Jun 2002 12:02:58 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 26069 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 20 Jun 2002 12:02:57 -0400
Received: from 207.217.120.49 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Thu, 20 Jun 2002 12:02:57 -0400
Received: from user-38lc1e3.dialup.mindspring.com ([209.86.5.195]
          helo=earthlink.net) by scaup.mail.pas.earthlink.net with esmtp (Exim
          3.33 #2) id 17L4Of-0004Xt-00 for ospf@discuss.microsoft.com; Thu, 20
          Jun 2002 09:02:57 -0700
X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified)
X-Mailer: Mozilla 4.72 [en]C-gatewaynet  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D11FF04.57ACAAEF@earthlink.net>
Date:         Thu, 20 Jun 2002 09:12:52 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Erblichs 
Subject: LSA Group Pacing
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Group,

        I was working on extensions to something like
        the LSA group pacing feature used by Cisco..

        However, I don't remember seeing this original feature
        documented in a RFC.

        Was this ever pulled from a Informational, Experimental,
        draft, or Standard RFC?

        Thanks,

                Mitchell Erblich


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Jun 20 13:16:10 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07223
	for ; Thu, 20 Jun 2002 13:16:10 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0065E431@cherry.ease.lsoft.com>; Thu, 20 Jun 2002 13:16:49 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 26335 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 20 Jun 2002 13:16:49 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 20 Jun 2002 13:16:49 -0400
Received: from redback.com (login003.redback.com [155.53.12.55]) by
          prattle.redback.com (Postfix) with ESMTP id 1186F1B8EF5 for
          ; Thu, 20 Jun 2002 10:16:47 -0700 (PDT)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508
            Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
References: <3D11FF04.57ACAAEF@earthlink.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID:  <3D120E31.1040408@redback.com>
Date:         Thu, 20 Jun 2002 13:17:37 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: Acee Lindem 
Subject: Re: LSA Group Pacing
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Erblichs wrote:

> Group,
>
>         I was working on extensions to something like
>         the LSA group pacing feature used by Cisco..
>
>         However, I don't remember seeing this original feature
>         documented in a RFC.
>
>         Was this ever pulled from a Informational, Experimental,
>         draft, or Standard RFC?


AFAIK, there is none. Most implementations stagger LSA refresh. In
fact, in one case I implemented a randomized initial age to assure
that a single event (e.g., an ATM or frame relay cloud flapping)
would not cause all your summary LSAs to be synchronized.


>
>         Thanks,
>
>                 Mitchell Erblich
>
>


--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Jun 20 13:55:07 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08252
	for ; Thu, 20 Jun 2002 13:55:07 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0065E3A3@cherry.ease.lsoft.com>; Thu, 20 Jun 2002 13:55:47 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 26430 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 20 Jun 2002 13:55:47 -0400
Received: from 64.4.37.126 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 20 Jun 2002 13:45:45 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu,
          20 Jun 2002 10:45:44 -0700
Received: from 65.192.41.10 by pv2fd.pav2.hotmail.msn.com with HTTP; Thu, 20
          Jun 2002 17:45:44 GMT
X-Originating-IP: [65.192.41.10]
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 20 Jun 2002 17:45:44.0734 (UTC)
                       FILETIME=[4DA613E0:01C21882]
Message-ID:  
Date:         Thu, 20 Jun 2002 10:45:44 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: prashant desai 
Subject: mtu in DD exchange.
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi,
Can anyone give me a good reason why OSPF routers have to agree on
the MTU size during DD exchange process..
As OSPF runs over IP..fragmentation or reassembly should not be its
concern..and they will be transparently handled by the IP layer..

Prashant

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail.
http://www.hotmail.com


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Jun 20 13:58:32 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08455
	for ; Thu, 20 Jun 2002 13:58:32 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.0065E574@cherry.ease.lsoft.com>; Thu, 20 Jun 2002 13:59:11 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 26501 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 20 Jun 2002 13:59:11 -0400
Received: from 64.211.218.216 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Thu, 20 Jun 2002 13:59:11 -0400
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id
          g5KHxAC13490 for ospf@discuss.microsoft.com; Thu, 20 Jun 2002
          13:59:10 -0400 (EDT) (envelope-from dang@nexthop.com)
Received: from marvin.nexthop.com (dang.nexthop.com [64.211.218.29]) by
          presque.djinesys.com (8.11.3/8.11.1) with SMTP id g5KHx7913483 for
          ; Thu, 20 Jun 2002 13:59:07 -0400 (EDT)
          (envelope-from dang@nexthop.com)
References: 
X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
X-Virus-Scanned: by AMaViS perl-11
X-MIME-Autoconverted: from 8bit to quoted-printable by presque.djinesys.com id
                      g5KHxAC13490
Message-ID:  <20020620135907.5a82797e.dang@nexthop.com>
Date:         Thu, 20 Jun 2002 13:59:07 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: Daniel Gryniewicz 
Organization: Nexthop Technology
Subject: Re: mtu in DD exchange.
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  
Precedence: list
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA08455

What fragments?  All OSPF (baring virtual links) traffic is only on one link. 
What the MTU agreement assures is that everyone on the link agrees what the
MTU *for that link* should be.  If I think the MTU is 9000, and you think the
MTU is 1500, you'll silently drop all my packets.  My IP layer won't fragment,
because it thinks the MTU is large enough.

Daniel

On Thu, 20 Jun 2002 10:45:44 -0700
prashant desai  wrote:

> Hi,
> Can anyone give me a good reason why OSPF routers have to agree on
> the MTU size during DD exchange process..
> As OSPF runs over IP..fragmentation or reassembly should not be its
> concern..and they will be transparently handled by the IP layer..
> 
> Prashant
> 
> _________________________________________________________________
> Join the world’s largest e-mail service with MSN Hotmail.
> http://www.hotmail.com


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Jun 20 14:27:17 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09473
	for ; Thu, 20 Jun 2002 14:27:16 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0065E6B0@cherry.ease.lsoft.com>; Thu, 20 Jun 2002 14:27:53 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 26596 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 20 Jun 2002 14:27:53 -0400
Received: from 64.4.37.119 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 20 Jun 2002 14:27:53 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu,
          20 Jun 2002 11:27:52 -0700
Received: from 65.192.41.10 by pv2fd.pav2.hotmail.msn.com with HTTP; Thu, 20
          Jun 2002 18:27:52 GMT
X-Originating-IP: [65.192.41.10]
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 20 Jun 2002 18:27:52.0289 (UTC)
                       FILETIME=[30305D10:01C21888]
Message-ID:  
Date:         Thu, 20 Jun 2002 11:27:52 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: prashant desai 
Subject: Re: mtu in DD exchange.
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

exactly..the ip layer should drop the packet..why should OSPF care about
it..dont you think its the ip layers job to check mtu conformance of
incomming packets ?


>From: Daniel Gryniewicz 
>Reply-To: Mailing List 
>To: OSPF@DISCUSS.MICROSOFT.COM
>Subject: Re: mtu in DD exchange.
>Date: Thu, 20 Jun 2002 13:59:07 -0400
>
>What fragments?  All OSPF (baring virtual links) traffic is only on one
>link.
>What the MTU agreement assures is that everyone on the link agrees what the
>MTU *for that link* should be.  If I think the MTU is 9000, and you think
>the
>MTU is 1500, you'll silently drop all my packets.  My IP layer won't
>fragment,
>because it thinks the MTU is large enough.
>
>Daniel
>
>On Thu, 20 Jun 2002 10:45:44 -0700
>prashant desai  wrote:
>
> > Hi,
> > Can anyone give me a good reason why OSPF routers have to agree on
> > the MTU size during DD exchange process..
> > As OSPF runs over IP..fragmentation or reassembly should not be its
> > concern..and they will be transparently handled by the IP layer..
> >
> > Prashant
> >
> > _________________________________________________________________
> > Join the world’s largest e-mail service with MSN Hotmail.
> > http://www.hotmail.com




_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail.
http://www.hotmail.com


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Jun 20 14:30:23 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09617
	for ; Thu, 20 Jun 2002 14:30:23 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0065E6BF@cherry.ease.lsoft.com>; Thu, 20 Jun 2002 14:31:03 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 26638 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 20 Jun 2002 14:31:03 -0400
Received: from 64.211.218.216 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Thu, 20 Jun 2002 14:31:02 -0400
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id
          g5KIV1U14919 for ospf@discuss.microsoft.com; Thu, 20 Jun 2002
          14:31:01 -0400 (EDT) (envelope-from dang@nexthop.com)
Received: from marvin.nexthop.com (dang.nexthop.com [64.211.218.29]) by
          presque.djinesys.com (8.11.3/8.11.1) with SMTP id g5KIUw914911 for
          ; Thu, 20 Jun 2002 14:30:58 -0400 (EDT)
          (envelope-from dang@nexthop.com)
References: 
X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
X-Virus-Scanned: by AMaViS perl-11
X-MIME-Autoconverted: from 8bit to quoted-printable by presque.djinesys.com id
                      g5KIV1U14919
Message-ID:  <20020620143058.30e94ba4.dang@nexthop.com>
Date:         Thu, 20 Jun 2002 14:30:58 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: Daniel Gryniewicz 
Organization: Nexthop Technology
Subject: Re: mtu in DD exchange.
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  
Precedence: list
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA09617

So, I send you the 9000 byte packet.  My IP layer thinks it's fine.  Your IP
layer drops it.  An adjacency never forms.  Or, worse yet, the adjacency
formed (the HELLOs and DDs were all small enough) and then I get and flood a
huge LSA from someone else.  You drop it, but I assume you have it.  My SPF
puts a route from this LSA through you, but you don't have it, so blackhole. 
I *have* to know that every packet I send to you can make it.  The MTU
agreement assures that packets won't get dropped because of MTU mismatch.

Daniel

On Thu, 20 Jun 2002 11:27:52 -0700
prashant desai  wrote:

> exactly..the ip layer should drop the packet..why should OSPF care about
> it..dont you think its the ip layers job to check mtu conformance of
> incomming packets ?
> 
> 
> >From: Daniel Gryniewicz 
> >Reply-To: Mailing List 
> >To: OSPF@DISCUSS.MICROSOFT.COM
> >Subject: Re: mtu in DD exchange.
> >Date: Thu, 20 Jun 2002 13:59:07 -0400
> >
> >What fragments?  All OSPF (baring virtual links) traffic is only on one
> >link.
> >What the MTU agreement assures is that everyone on the link agrees what the
> >MTU *for that link* should be.  If I think the MTU is 9000, and you think
> >the
> >MTU is 1500, you'll silently drop all my packets.  My IP layer won't
> >fragment,
> >because it thinks the MTU is large enough.
> >
> >Daniel
> >
> >On Thu, 20 Jun 2002 10:45:44 -0700
> >prashant desai  wrote:
> >
> > > Hi,
> > > Can anyone give me a good reason why OSPF routers have to agree on
> > > the MTU size during DD exchange process..
> > > As OSPF runs over IP..fragmentation or reassembly should not be its
> > > concern..and they will be transparently handled by the IP layer..
> > >
> > > Prashant
> > >
> > > _________________________________________________________________
> > > Join the world’s largest e-mail service with MSN Hotmail.
> > > http://www.hotmail.com
> 
> 
> 
> 
> _________________________________________________________________
> Join the world’s largest e-mail service with MSN Hotmail.
> http://www.hotmail.com


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Jun 20 14:34:44 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09763
	for ; Thu, 20 Jun 2002 14:34:44 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0065E6D2@cherry.ease.lsoft.com>; Thu, 20 Jun 2002 14:35:22 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 26669 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 20 Jun 2002 14:35:22 -0400
Received: from 64.4.37.155 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 20 Jun 2002 14:35:21 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu,
          20 Jun 2002 11:35:20 -0700
Received: from 65.192.41.10 by pv2fd.pav2.hotmail.msn.com with HTTP; Thu, 20
          Jun 2002 18:35:20 GMT
X-Originating-IP: [65.192.41.10]
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 20 Jun 2002 18:35:20.0832 (UTC)
                       FILETIME=[3B8A9800:01C21889]
Message-ID:  
Date:         Thu, 20 Jun 2002 11:35:20 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: prashant desai 
Subject: Re: mtu in DD exchange.
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

that makes sense :-)
but the drop lsa will not be acked....never reachd ospf

thanks
Prashant


>From: Daniel Gryniewicz 
>Reply-To: Mailing List 
>To: OSPF@DISCUSS.MICROSOFT.COM
>Subject: Re: mtu in DD exchange.
>Date: Thu, 20 Jun 2002 14:30:58 -0400
>
>So, I send you the 9000 byte packet.  My IP layer thinks it's fine.  Your
>IP
>layer drops it.  An adjacency never forms.  Or, worse yet, the adjacency
>formed (the HELLOs and DDs were all small enough) and then I get and flood
>a
>huge LSA from someone else.  You drop it, but I assume you have it.  My SPF
>puts a route from this LSA through you, but you don't have it, so
>blackhole.
>I *have* to know that every packet I send to you can make it.  The MTU
>agreement assures that packets won't get dropped because of MTU mismatch.
>
>Daniel
>
>On Thu, 20 Jun 2002 11:27:52 -0700
>prashant desai  wrote:
>
> > exactly..the ip layer should drop the packet..why should OSPF care about
> > it..dont you think its the ip layers job to check mtu conformance of
> > incomming packets ?
> >
> >
> > >From: Daniel Gryniewicz 
> > >Reply-To: Mailing List 
> > >To: OSPF@DISCUSS.MICROSOFT.COM
> > >Subject: Re: mtu in DD exchange.
> > >Date: Thu, 20 Jun 2002 13:59:07 -0400
> > >
> > >What fragments?  All OSPF (baring virtual links) traffic is only on one
> > >link.
> > >What the MTU agreement assures is that everyone on the link agrees what
>the
> > >MTU *for that link* should be.  If I think the MTU is 9000, and you
>think
> > >the
> > >MTU is 1500, you'll silently drop all my packets.  My IP layer won't
> > >fragment,
> > >because it thinks the MTU is large enough.
> > >
> > >Daniel
> > >
> > >On Thu, 20 Jun 2002 10:45:44 -0700
> > >prashant desai  wrote:
> > >
> > > > Hi,
> > > > Can anyone give me a good reason why OSPF routers have to agree on
> > > > the MTU size during DD exchange process..
> > > > As OSPF runs over IP..fragmentation or reassembly should not be its
> > > > concern..and they will be transparently handled by the IP layer..
> > > >
> > > > Prashant
> > > >
> > > > _________________________________________________________________
> > > > Join the world’s largest e-mail service with MSN Hotmail.
> > > > http://www.hotmail.com
> >
> >
> >
> >
> > _________________________________________________________________
> > Join the world’s largest e-mail service with MSN Hotmail.
> > http://www.hotmail.com




_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Jun 20 14:36:34 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09835
	for ; Thu, 20 Jun 2002 14:36:34 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0065E59E@cherry.ease.lsoft.com>; Thu, 20 Jun 2002 14:37:14 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 26697 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 20 Jun 2002 14:37:14 -0400
Received: from 64.211.218.216 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Thu, 20 Jun 2002 14:37:14 -0400
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id
          g5KIbDY15352 for ospf@discuss.microsoft.com; Thu, 20 Jun 2002
          14:37:13 -0400 (EDT) (envelope-from dang@nexthop.com)
Received: from marvin.nexthop.com (dang.nexthop.com [64.211.218.29]) by
          presque.djinesys.com (8.11.3/8.11.1) with SMTP id g5KIbA915342 for
          ; Thu, 20 Jun 2002 14:37:10 -0400 (EDT)
          (envelope-from dang@nexthop.com)
References: 
X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
X-Virus-Scanned: by AMaViS perl-11
X-MIME-Autoconverted: from 8bit to quoted-printable by presque.djinesys.com id
                      g5KIbDY15352
Message-ID:  <20020620143710.421b3577.dang@nexthop.com>
Date:         Thu, 20 Jun 2002 14:37:10 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: Daniel Gryniewicz 
Organization: Nexthop Technology
Subject: Re: mtu in DD exchange.
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  
Precedence: list
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA09835

True, and it'll be resent forever, taking 9000 bytes of bandwidth every time. 
:(  And I'll still use it in my SPF, and so the black hole will still occure.

Daniel

On Thu, 20 Jun 2002 11:35:20 -0700
prashant desai  wrote:

> that makes sense :-)
> but the drop lsa will not be acked....never reachd ospf
> 
> thanks
> Prashant
> 
> 
> >From: Daniel Gryniewicz 
> >Reply-To: Mailing List 
> >To: OSPF@DISCUSS.MICROSOFT.COM
> >Subject: Re: mtu in DD exchange.
> >Date: Thu, 20 Jun 2002 14:30:58 -0400
> >
> >So, I send you the 9000 byte packet.  My IP layer thinks it's fine.  Your
> >IP
> >layer drops it.  An adjacency never forms.  Or, worse yet, the adjacency
> >formed (the HELLOs and DDs were all small enough) and then I get and flood
> >a
> >huge LSA from someone else.  You drop it, but I assume you have it.  My SPF
> >puts a route from this LSA through you, but you don't have it, so
> >blackhole.
> >I *have* to know that every packet I send to you can make it.  The MTU
> >agreement assures that packets won't get dropped because of MTU mismatch.
> >
> >Daniel
> >
> >On Thu, 20 Jun 2002 11:27:52 -0700
> >prashant desai  wrote:
> >
> > > exactly..the ip layer should drop the packet..why should OSPF care about
> > > it..dont you think its the ip layers job to check mtu conformance of
> > > incomming packets ?
> > >
> > >
> > > >From: Daniel Gryniewicz 
> > > >Reply-To: Mailing List 
> > > >To: OSPF@DISCUSS.MICROSOFT.COM
> > > >Subject: Re: mtu in DD exchange.
> > > >Date: Thu, 20 Jun 2002 13:59:07 -0400
> > > >
> > > >What fragments?  All OSPF (baring virtual links) traffic is only on one
> > > >link.
> > > >What the MTU agreement assures is that everyone on the link agrees what
> >the
> > > >MTU *for that link* should be.  If I think the MTU is 9000, and you
> >think
> > > >the
> > > >MTU is 1500, you'll silently drop all my packets.  My IP layer won't
> > > >fragment,
> > > >because it thinks the MTU is large enough.
> > > >
> > > >Daniel
> > > >
> > > >On Thu, 20 Jun 2002 10:45:44 -0700
> > > >prashant desai  wrote:
> > > >
> > > > > Hi,
> > > > > Can anyone give me a good reason why OSPF routers have to agree on
> > > > > the MTU size during DD exchange process..
> > > > > As OSPF runs over IP..fragmentation or reassembly should not be its
> > > > > concern..and they will be transparently handled by the IP layer..
> > > > >
> > > > > Prashant
> > > > >
> > > > > _________________________________________________________________
> > > > > Join the world’s largest e-mail service with MSN Hotmail.
> > > > > http://www.hotmail.com
> > >
> > >
> > >
> > >
> > > _________________________________________________________________
> > > Join the world’s largest e-mail service with MSN Hotmail.
> > > http://www.hotmail.com
> 
> 
> 
> 
> _________________________________________________________________
> Send and receive Hotmail on your mobile device: http://mobile.msn.com


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Jun 20 15:26:56 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11150
	for ; Thu, 20 Jun 2002 15:26:56 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.0065E73A@cherry.ease.lsoft.com>; Thu, 20 Jun 2002 15:27:34 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 26940 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 20 Jun 2002 15:27:33 -0400
Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 20 Jun 2002 15:27:33 -0400
Received: from 12-234-73-224.client.attbi.com ([12.234.73.224]) by psg.com with
          esmtp (Exim 3.36 #1) id 17L7ad-000Jvc-00; Thu, 20 Jun 2002 12:27:32
          -0700
X-Mailer: The Bat! (v1.51) Personal
X-Priority: 3 (Normal)
References: <3D11FF04.57ACAAEF@earthlink.net> <3D120E31.1040408@redback.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <1232981628.20020620122604@psg.com>
Date:         Thu, 20 Jun 2002 12:26:04 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Alex Zinin 
Subject: Re: LSA Group Pacing
Comments: To: Acee Lindem 
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <3D120E31.1040408@redback.com>
Precedence: list
Content-Transfer-Encoding: 7bit

I had a draft on this that described what I did in Zebra.
It expired, but can still be found in the IETF proceedings.
Ostap Monkewich actually simulated the described approach.

http://www.ietf.org/proceedings/00dec/I-D/draft-ietf-ospf-refresh-guide-01.txt

--
Alex

Thursday, June 20, 2002, 10:17:37 AM, you wrote:
> Erblichs wrote:

>> Group,
>>
>>         I was working on extensions to something like
>>         the LSA group pacing feature used by Cisco..
>>
>>         However, I don't remember seeing this original feature
>>         documented in a RFC.
>>
>>         Was this ever pulled from a Informational, Experimental,
>>         draft, or Standard RFC?


> AFAIK, there is none. Most implementations stagger LSA refresh. In
> fact, in one case I implemented a randomized initial age to assure
> that a single event (e.g., an ATM or frame relay cloud flapping)
> would not cause all your summary LSAs to be synchronized.


>>
>>         Thanks,
>>
>>                 Mitchell Erblich
>>
>>


> --
> Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Jun 20 15:38:55 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11397
	for ; Thu, 20 Jun 2002 15:38:55 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.0065E7A7@cherry.ease.lsoft.com>; Thu, 20 Jun 2002 15:39:33 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 26984 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 20 Jun 2002 15:39:32 -0400
Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 20 Jun 2002 15:39:32 -0400
Received: from 12-234-73-224.client.attbi.com ([12.234.73.224]) by psg.com with
          esmtp (Exim 3.36 #1) id 17L7mE-000K5a-00; Thu, 20 Jun 2002 12:39:30
          -0700
X-Mailer: The Bat! (v1.51) Personal
X-Priority: 3 (Normal)
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Message-ID:  <563699733.20020620123802@psg.com>
Date:         Thu, 20 Jun 2002 12:38:02 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Alex Zinin 
Subject: Re: mtu in DD exchange.
Comments: To: prashant desai 
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  
Precedence: list
Content-Transfer-Encoding: 8bit

Prashant,

http://www.ietf.org/ietf/ospf/ospf-minutes-96dec.txt

--
Alex

Thursday, June 20, 2002, 10:45:44 AM, you wrote:
> Hi,
> Can anyone give me a good reason why OSPF routers have to agree on
> the MTU size during DD exchange process..
> As OSPF runs over IP..fragmentation or reassembly should not be its
> concern..and they will be transparently handled by the IP layer..

> Prashant

> _________________________________________________________________
> Join the world’s largest e-mail service with MSN Hotmail.
> http://www.hotmail.com


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Jun 21 05:58:58 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05837
	for ; Fri, 21 Jun 2002 05:58:58 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.0065FEE8@cherry.ease.lsoft.com>; Fri, 21 Jun 2002 5:59:31 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 28781 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 21 Jun 2002 05:59:27 -0400
Received: from 66.163.169.15 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 21 Jun 2002 05:59:16 -0400
Received: from [203.200.20.226] by web21504.mail.yahoo.com via HTTP; Fri, 21
          Jun 2002 02:59:00 PDT
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <20020621095900.48658.qmail@web21504.mail.yahoo.com>
Date:         Fri, 21 Jun 2002 02:59:00 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Amit Srivastava 
Subject: Re: OSPF Retransmission Doubt
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  
Precedence: list

Thanks Vishwas!!
         That was really a smart piece of thinking!!!
Regards
Amit


--- "Manral, Vishwas"  wrote:
> Hi Amit,
>
> The case would not occur if all the routers would
> have the same value of
> ExtLSDBLimit except in the transient condition.
> Section 2.2 first part would
> only occur if the value is not the same this may be
> required. Its always
> better to check the condition, if we are exceeding
> the limit and accordingly
> take action to get over any such a case.
>
> Section 2.3 states that the flooding modification
> would only be invoked
> during a "short period of convergence" for same
> value of LSDBLimit. Such a
> case would only occur say when two routers are
> symultaneously originating
> AS-External LSA's. So when they are originating the
> LSA's the LSDB limit is
> not exceeded however when they are receiving the
> LSA's from the other the
> LSDB limit is exceeded. However as the RFC states
> this would be a transient
> condition.
>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
> Sent: Thursday, June 20, 2002 10:24 AM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Re: OSPF Retransmission Doubt
>
>
> Hi Vishwas,
>    I have a small doubt .If u refer to section 2.2
> and
> 2.3 of RFC 1765 it states that during flooding also
> the variable count of non-default AS_external LSA is
> incremented( if we receive a non-default AS-external
> LSA during flooding).But if we have a common thresh
> hold limit i.e variable ospfExtlsdbLimit is same for
> all the router how come this condition will be
> encountered???
> Regards
> Amit
>
>
>
>
> --- "Manral, Vishwas"  wrote:
> > Hi Amit,
> >
> > I do not think any RFC which talks about
> non-default
> > type-3 LSA's exists.
> > The RFC1765 only talks about type-5 LSA's however
> it
> > could be extended for
> > other type of LSA's i.e. type-7, type-11.
> >
> > Thanks,
> > Vishwas
> >
> > -----Original Message-----
> > From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
> > Sent: Wednesday, June 19, 2002 11:43 AM
> > To: OSPF@DISCUSS.MICROSOFT.COM
> > Subject: Re: OSPF Retransmission Doubt
> >
> >
> >
> >  Hi Erblich and Vishwas,
> >       Erblich I got your point but is there any
> > Draft or RFC which
> > states
> > this??
> >      And Vishwas thanks for your help i would also
> > like to know if
> > there is any draft which states that we can
> withdraw
> > Summary 3 and 4
> > non-default LSA.Because The RFC 2370 specks very
> > little about it.
> > Regards
> > Amit
> >
> >
> >
> >   Amit Srivastava  wrote:
> >
> >
> > Hi Vishwas!
> >
> >
> >           Actually after reading the RFC 1765 only
> i
> > got this doubt.Here i
> > feel once the OSPFEXTLSDBLinit variable is
> exceeded
> > the router should
> > indicate other routers that its database is full
> and
> > they should not keep on
> > retransmitting the LSA which will clog the n/w
> > bandwidth.Once the router
> > comes out of the database overflow state it should
> > indicate to the other
> > router that now they should send the LSA.
> >
> >
> >       What do you say about this??
> >
> >
> > Regards
> >
> >
> > Amit
> >
> >   "Manral, Vishwas"  wrote:
> >
> >
> > Hi Amit,
> >
> > You may like to look at the RFC1765 - OSPF
> Database
> > Overflow.
> > http://www.ietf.org/rfc/rfc1765.txt This RFC tells
> a
> > way to deal with such
> > overflow when it occurs in OSPF.
> >
> > Also as the RFC lists as enhancements, if the
> number
> > of summary LSA's
> > increases we could as well flush type3/4 also and
> > originate default routes
> > in the domain instead, which could lead to
> > suboptimal routing or blackholing
> > however.
> >
> > However in ur case if a router does not accept and
> > acknowledge an LSA, it
> > will be continuously retransmitted as long as the
> > adjacency is up. If this
> > is not done, the databases would have no way to
> come
> > back to synch as the
> > adjacency itself would not be broken.
> >
> > Thanks,
> > Vishwas
> >
> > -----Original Message-----
> > From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
> > Sent: Tuesday, June 18, 2002 5:26 PM
> > To: OSPF@DISCUSS.MICROSOFT.COM!
> > Subject: OSPF Retransmission Doubt
> >
> >
> > Hi All,
> > I have the doubt which is described below:-
> > Suppose a router is there whose database is
> full.Now
> > it can send and receive hello packets but discards
> > any
> > new LSA coming to it(as database is full) and
> hence
> > it
> > will not ack that LSA.Now my doubt is that RFC
> 2328
> > says the the retransmission will continue till the
> > adjacency is broken.
> > Does that mean if the database does not have space
> > for accomodating the new LSA infinite number of
> > retransmission would result???
> > Regards
> > Amit


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Jun 21 07:03:58 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07129
	for ; Fri, 21 Jun 2002 07:03:58 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0065FF40@cherry.ease.lsoft.com>; Fri, 21 Jun 2002 7:04:37 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 29107 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 21 Jun 2002 07:04:36 -0400
Received: from 66.163.169.15 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 21 Jun 2002 07:04:36 -0400
Received: from [203.200.20.226] by web21504.mail.yahoo.com via HTTP; Fri, 21
          Jun 2002 04:04:35 PDT
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <20020621110435.68420.qmail@web21504.mail.yahoo.com>
Date:         Fri, 21 Jun 2002 04:04:35 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Amit Srivastava 
Subject: Re: OSPF Retransmission Doubt
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  
Precedence: list

 Hi Vishwas!!
      The RFC 1765 section 4 last point states that if
the administrator cannot incresase the value of
ospfExtlsdbLimit then he can make sure that more
important routes continue to be imported ; this is
accomplished by turning off the importing of less
important routes.
      Now my doubt is ->is it that the administrator
configures paticular n/w coming in the AS-external
packet as important or unimportant or does it mean
that routes learned by a paticular router-id are
important and will stay in the database while all the
others will be flushed or is it implementation
specific!!!
Regards
Amit




--- "Manral, Vishwas"  wrote:
> Hi Amit,
>
> The case would not occur if all the routers would
> have the same value of
> ExtLSDBLimit except in the transient condition.
> Section 2.2 first part would
> only occur if the value is not the same this may be
> required. Its always
> better to check the condition, if we are exceeding
> the limit and accordingly
> take action to get over any such a case.
>
> Section 2.3 states that the flooding modification
> would only be invoked
> during a "short period of convergence" for same
> value of LSDBLimit. Such a
> case would only occur say when two routers are
> symultaneously originating
> AS-External LSA's. So when they are originating the
> LSA's the LSDB limit is
> not exceeded however when they are receiving the
> LSA's from the other the
> LSDB limit is exceeded. However as the RFC states
> this would be a transient
> condition.
>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
> Sent: Thursday, June 20, 2002 10:24 AM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Re: OSPF Retransmission Doubt
>
>
> Hi Vishwas,
>    I have a small doubt .If u refer to section 2.2
> and
> 2.3 of RFC 1765 it states that during flooding also
> the variable count of non-default AS_external LSA is
> incremented( if we receive a non-default AS-external
> LSA during flooding).But if we have a common thresh
> hold limit i.e variable ospfExtlsdbLimit is same for
> all the router how come this condition will be
> encountered???
> Regards
> Amit
>
>
>
>
> --- "Manral, Vishwas"  wrote:
> > Hi Amit,
> >
> > I do not think any RFC which talks about
> non-default
> > type-3 LSA's exists.
> > The RFC1765 only talks about type-5 LSA's however
> it
> > could be extended for
> > other type of LSA's i.e. type-7, type-11.
> >
> > Thanks,
> > Vishwas
> >
> > -----Original Message-----
> > From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
> > Sent: Wednesday, June 19, 2002 11:43 AM
> > To: OSPF@DISCUSS.MICROSOFT.COM
> > Subject: Re: OSPF Retransmission Doubt
> >
> >
> >
> >  Hi Erblich and Vishwas,
> >       Erblich I got your point but is there any
> > Draft or RFC which
> > states
> > this??
> >      And Vishwas thanks for your help i would also
> > like to know if
> > there is any draft which states that we can
> withdraw
> > Summary 3 and 4
> > non-default LSA.Because The RFC 2370 specks very
> > little about it.
> > Regards
> > Amit
> >
> >
> >
> >   Amit Srivastava  wrote:
> >
> >
> > Hi Vishwas!
> >
> >
> >           Actually after reading the RFC 1765 only
> i
> > got this doubt.Here i
> > feel once the OSPFEXTLSDBLinit variable is
> exceeded
> > the router should
> > indicate other routers that its database is full
> and
> > they should not keep on
> > retransmitting the LSA which will clog the n/w
> > bandwidth.Once the router
> > comes out of the database overflow state it should
> > indicate to the other
> > router that now they should send the LSA.
> >
> >
> >       What do you say about this??
> >
> >
> > Regards
> >
> >
> > Amit
> >
> >   "Manral, Vishwas"  wrote:
> >
> >
> > Hi Amit,
> >
> > You may like to look at the RFC1765 - OSPF
> Database
> > Overflow.
> > http://www.ietf.org/rfc/rfc1765.txt This RFC tells
> a
> > way to deal with such
> > overflow when it occurs in OSPF.
> >
> > Also as the RFC lists as enhancements, if the
> number
> > of summary LSA's
> > increases we could as well flush type3/4 also and
> > originate default routes
> > in the domain instead, which could lead to
> > suboptimal routing or blackholing
> > however.
> >
> > However in ur case if a router does not accept and
> > acknowledge an LSA, it
> > will be continuously retransmitted as long as the
> > adjacency is up. If this
> > is not done, the databases would have no way to
> come
> > back to synch as the
> > adjacency itself would not be broken.
> >
> > Thanks,
> > Vishwas
> >
> > -----Original Message-----
> > From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
> > Sent: Tuesday, June 18, 2002 5:26 PM
> > To: OSPF@DISCUSS.MICROSOFT.COM!
> > Subject: OSPF Retransmission Doubt
> >
> >
> > Hi All,
> > I have the doubt which is described below:-
> > Suppose a router is there whose database is
> full.Now
> > it can send and receive hello packets but discards
> > any
> > new LSA coming to it(as database is full) and
> hence
> > it
> > will not ack that LSA.Now my doubt is that RFC
> 2328
> > says the the retransmission will continue till the
> > adjacency is broken.
> > Does that mean if the database does not have space
> > for accomodating the new LSA infinite number of
> > retransmission would result???
> > Regards
> > Amit


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Jun 21 08:05:33 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09010
	for ; Fri, 21 Jun 2002 08:05:33 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0066009F@cherry.ease.lsoft.com>; Fri, 21 Jun 2002 8:06:13 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 29253 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 21 Jun 2002 08:06:12 -0400
Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 21 Jun 2002 08:06:12 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id ; Fri, 21 Jun 2002 08:01:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  
Date:         Fri, 21 Jun 2002 08:05:39 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: "Manral, Vishwas" 
Subject: Re: mtu in DD exchange.
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Prashant/Daniel,

Besides what Alex has already sent you may like to have a look at the
discussions in the archives. This thing has been discussed a lot of times in
the past.

Check
http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0008&L=OSPF&P=R2394
and
http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0008&L=OSPF&P=R2279 .

Besides the MTU check is (from RFC2328)

        If the Interface MTU field in the Database Description packet
        indicates an IP datagram size that is larger than the router can
        accept on the receiving interface without fragmentation, the
        Database Description packet is rejected.

So if we did not want an MTU mismatch in any case, we could always send a
value 0 for the Interface MTU, as is done on virtual links.

Thanks,
Vishwas

-----Original Message-----
From: Daniel Gryniewicz [mailto:dang@NEXTHOP.COM]
Sent: Friday, June 21, 2002 12:07 AM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: mtu in DD exchange.


True, and it'll be resent forever, taking 9000 bytes of bandwidth every
time.
:(  And I'll still use it in my SPF, and so the black hole will still
occure.

Daniel

On Thu, 20 Jun 2002 11:35:20 -0700
prashant desai  wrote:

> that makes sense :-)
> but the drop lsa will not be acked....never reachd ospf
>
> thanks
> Prashant
>
>
> >From: Daniel Gryniewicz 
> >Reply-To: Mailing List 
> >To: OSPF@DISCUSS.MICROSOFT.COM
> >Subject: Re: mtu in DD exchange.
> >Date: Thu, 20 Jun 2002 14:30:58 -0400
> >
> >So, I send you the 9000 byte packet.  My IP layer thinks it's fine.  Your
> >IP
> >layer drops it.  An adjacency never forms.  Or, worse yet, the adjacency
> >formed (the HELLOs and DDs were all small enough) and then I get and
flood
> >a
> >huge LSA from someone else.  You drop it, but I assume you have it.  My
SPF
> >puts a route from this LSA through you, but you don't have it, so
> >blackhole.
> >I *have* to know that every packet I send to you can make it.  The MTU
> >agreement assures that packets won't get dropped because of MTU mismatch.
> >
> >Daniel
> >
> >On Thu, 20 Jun 2002 11:27:52 -0700
> >prashant desai  wrote:
> >
> > > exactly..the ip layer should drop the packet..why should OSPF care
about
> > > it..dont you think its the ip layers job to check mtu conformance of
> > > incomming packets ?
> > >
> > >
> > > >From: Daniel Gryniewicz 
> > > >Reply-To: Mailing List 
> > > >To: OSPF@DISCUSS.MICROSOFT.COM
> > > >Subject: Re: mtu in DD exchange.
> > > >Date: Thu, 20 Jun 2002 13:59:07 -0400
> > > >
> > > >What fragments?  All OSPF (baring virtual links) traffic is only on
one
> > > >link.
> > > >What the MTU agreement assures is that everyone on the link agrees
what
> >the
> > > >MTU *for that link* should be.  If I think the MTU is 9000, and you
> >think
> > > >the
> > > >MTU is 1500, you'll silently drop all my packets.  My IP layer won't
> > > >fragment,
> > > >because it thinks the MTU is large enough.
> > > >
> > > >Daniel
> > > >
> > > >On Thu, 20 Jun 2002 10:45:44 -0700
> > > >prashant desai  wrote:
> > > >
> > > > > Hi,
> > > > > Can anyone give me a good reason why OSPF routers have to agree on
> > > > > the MTU size during DD exchange process..
> > > > > As OSPF runs over IP..fragmentation or reassembly should not be
its
> > > > > concern..and they will be transparently handled by the IP layer..
> > > > >
> > > > > Prashant
> > > > >


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Jun 21 08:14:51 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09341
	for ; Fri, 21 Jun 2002 08:14:50 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.0066001B@cherry.ease.lsoft.com>; Fri, 21 Jun 2002 8:15:30 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 29332 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 21 Jun 2002 08:15:30 -0400
Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 21 Jun 2002 08:15:30 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id ; Fri, 21 Jun 2002 08:10:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  
Date:         Fri, 21 Jun 2002 08:14:47 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: "Manral, Vishwas" 
Subject: Re: OSPF Retransmission Doubt
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Amit,

When the administrator finds that a domain is getting "Overflows" he has to
change the policies so that the number of routes imported into the domain is
reduced. The routes to be imported are all an administrative
decision/policies and the OSPF packets etc do not come into picture at all.

The RFC in this point talks about importing routes from other domains and
not about received LSA's from other routers in the domain.

Thanks,
Vishwas

-----Original Message-----
From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
Sent: Friday, June 21, 2002 4:35 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: OSPF Retransmission Doubt


 Hi Vishwas!!
      The RFC 1765 section 4 last point states that if
the administrator cannot incresase the value of
ospfExtlsdbLimit then he can make sure that more
important routes continue to be imported ; this is
accomplished by turning off the importing of less
important routes.
      Now my doubt is ->is it that the administrator
configures paticular n/w coming in the AS-external
packet as important or unimportant or does it mean
that routes learned by a paticular router-id are
important and will stay in the database while all the
others will be flushed or is it implementation
specific!!!
Regards
Amit




--- "Manral, Vishwas"  wrote:
> Hi Amit,
>
> The case would not occur if all the routers would
> have the same value of
> ExtLSDBLimit except in the transient condition.
> Section 2.2 first part would
> only occur if the value is not the same this may be
> required. Its always
> better to check the condition, if we are exceeding
> the limit and accordingly
> take action to get over any such a case.
>
> Section 2.3 states that the flooding modification
> would only be invoked
> during a "short period of convergence" for same
> value of LSDBLimit. Such a
> case would only occur say when two routers are
> symultaneously originating
> AS-External LSA's. So when they are originating the
> LSA's the LSDB limit is
> not exceeded however when they are receiving the
> LSA's from the other the
> LSDB limit is exceeded. However as the RFC states
> this would be a transient
> condition.
>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
> Sent: Thursday, June 20, 2002 10:24 AM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Re: OSPF Retransmission Doubt
>
>
> Hi Vishwas,
>    I have a small doubt .If u refer to section 2.2
> and
> 2.3 of RFC 1765 it states that during flooding also
> the variable count of non-default AS_external LSA is
> incremented( if we receive a non-default AS-external
> LSA during flooding).But if we have a common thresh
> hold limit i.e variable ospfExtlsdbLimit is same for
> all the router how come this condition will be
> encountered???
> Regards
> Amit
>
>
>
>
> --- "Manral, Vishwas"  wrote:
> > Hi Amit,
> >
> > I do not think any RFC which talks about
> non-default
> > type-3 LSA's exists.
> > The RFC1765 only talks about type-5 LSA's however
> it
> > could be extended for
> > other type of LSA's i.e. type-7, type-11.
> >
> > Thanks,
> > Vishwas
> >
> > -----Original Message-----
> > From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
> > Sent: Wednesday, June 19, 2002 11:43 AM
> > To: OSPF@DISCUSS.MICROSOFT.COM
> > Subject: Re: OSPF Retransmission Doubt
> >
> >
> >
> >  Hi Erblich and Vishwas,
> >       Erblich I got your point but is there any
> > Draft or RFC which
> > states
> > this??
> >      And Vishwas thanks for your help i would also
> > like to know if
> > there is any draft which states that we can
> withdraw
> > Summary 3 and 4
> > non-default LSA.Because The RFC 2370 specks very
> > little about it.
> > Regards
> > Amit
> >
> >
> >
> >   Amit Srivastava  wrote:
> >
> >
> > Hi Vishwas!
> >
> >
> >           Actually after reading the RFC 1765 only
> i
> > got this doubt.Here i
> > feel once the OSPFEXTLSDBLinit variable is
> exceeded
> > the router should
> > indicate other routers that its database is full
> and
> > they should not keep on
> > retransmitting the LSA which will clog the n/w
> > bandwidth.Once the router
> > comes out of the database overflow state it should
> > indicate to the other
> > router that now they should send the LSA.
> >
> >
> >       What do you say about this??
> >
> >
> > Regards
> >
> >
> > Amit
> >
> >   "Manral, Vishwas"  wrote:
> >
> >
> > Hi Amit,
> >
> > You may like to look at the RFC1765 - OSPF
> Database
> > Overflow.
> > http://www.ietf.org/rfc/rfc1765.txt This RFC tells
> a
> > way to deal with such
> > overflow when it occurs in OSPF.
> >
> > Also as the RFC lists as enhancements, if the
> number
> > of summary LSA's
> > increases we could as well flush type3/4 also and
> > originate default routes
> > in the domain instead, which could lead to
> > suboptimal routing or blackholing
> > however.
> >
> > However in ur case if a router does not accept and
> > acknowledge an LSA, it
> > will be continuously retransmitted as long as the
> > adjacency is up. If this
> > is not done, the databases would have no way to
> come
> > back to synch as the
> > adjacency itself would not be broken.
> >
> > Thanks,
> > Vishwas
> >
> > -----Original Message-----
> > From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
> > Sent: Tuesday, June 18, 2002 5:26 PM
> > To: OSPF@DISCUSS.MICROSOFT.COM!
> > Subject: OSPF Retransmission Doubt
> >
> >
> > Hi All,
> > I have the doubt which is described below:-
> > Suppose a router is there whose database is
> full.Now
> > it can send and receive hello packets but discards
> > any
> > new LSA coming to it(as database is full) and
> hence
> > it
> > will not ack that LSA.Now my doubt is that RFC
> 2328
> > says the the retransmission will continue till the
> > adjacency is broken.
> > Does that mean if the database does not have space
> > for accomodating the new LSA infinite number of
> > retransmission would result???
> > Regards
> > Amit


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Jun 21 11:38:21 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17660
	for ; Fri, 21 Jun 2002 11:38:21 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.0066053D@cherry.ease.lsoft.com>; Fri, 21 Jun 2002 11:38:59 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 29832 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 21 Jun 2002 11:38:58 -0400
Received: from 207.217.120.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Fri, 21 Jun 2002 11:38:58 -0400
Received: from user-38lc11f.dialup.mindspring.com ([209.86.4.47]
          helo=earthlink.net) by goose.mail.pas.earthlink.net with esmtp (Exim
          3.33 #2) id 17LQUz-00010m-00 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 21
          Jun 2002 08:38:57 -0700
X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified)
X-Mailer: Mozilla 4.72 [en]C-gatewaynet  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D134AE6.24258EAA@earthlink.net>
Date:         Fri, 21 Jun 2002 08:48:54 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Erblichs 
Subject: Re: mtu in DD exchange.
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Group, my two cents..

This "problem" was actually fixed in another LS protocol, ISIS
with its HELLO PDU. The hellos were padded to within 1 byte/octet
of the MTU. This allowed the perspective link partners to
implictly specify their MTUs. Else, no link partners with less
of a chance that a DR won't be able to send the proper CSNPs..

This was a tradeoff of bandwidth consumption versus forming
an adjacency that possibly would drop PDUs/ LSAs in the
future due to different MTUs.

I actually always thought that the MTU matching in OSPF should
be done with the Hello packet. You may ask why. This would
increase the chance that all 2-ways that could then be involved in
a DR or BDR election can actually form full adjacencies...

Where currently it is done later with the OSPF dbase descr packet..

Or did I miss something?....

Mitchell Erblich
======================


"Manral, Vishwas" wrote:
>
> Prashant/Daniel,
>
> Besides what Alex has already sent you may like to have a look at the
> discussions in the archives. This thing has been discussed a lot of times in
> the past.
>
> Check
> http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0008&L=OSPF&P=R2394
> and
> http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0008&L=OSPF&P=R2279 .
>
> Besides the MTU check is (from RFC2328)
>
>         If the Interface MTU field in the Database Description packet
>         indicates an IP datagram size that is larger than the router can
>         accept on the receiving interface without fragmentation, the
>         Database Description packet is rejected.
>
> So if we did not want an MTU mismatch in any case, we could always send a
> value 0 for the Interface MTU, as is done on virtual links.
>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Daniel Gryniewicz [mailto:dang@NEXTHOP.COM]
> Sent: Friday, June 21, 2002 12:07 AM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Re: mtu in DD exchange.
>
> True, and it'll be resent forever, taking 9000 bytes of bandwidth every
> time.
> :(  And I'll still use it in my SPF, and so the black hole will still
> occure.
>
> Daniel
>
> On Thu, 20 Jun 2002 11:35:20 -0700
> prashant desai  wrote:
>
> > that makes sense :-)
> > but the drop lsa will not be acked....never reachd ospf
> >
> > thanks
> > Prashant
> >
> >
> > >From: Daniel Gryniewicz 
> > >Reply-To: Mailing List 
> > >To: OSPF@DISCUSS.MICROSOFT.COM
> > >Subject: Re: mtu in DD exchange.
> > >Date: Thu, 20 Jun 2002 14:30:58 -0400
> > >
> > >So, I send you the 9000 byte packet.  My IP layer thinks it's fine.  Your
> > >IP
> > >layer drops it.  An adjacency never forms.  Or, worse yet, the adjacency
> > >formed (the HELLOs and DDs were all small enough) and then I get and
> flood
> > >a
> > >huge LSA from someone else.  You drop it, but I assume you have it.  My
> SPF
> > >puts a route from this LSA through you, but you don't have it, so
> > >blackhole.
> > >I *have* to know that every packet I send to you can make it.  The MTU
> > >agreement assures that packets won't get dropped because of MTU mismatch.
> > >
> > >Daniel
> > >
> > >On Thu, 20 Jun 2002 11:27:52 -0700
> > >prashant desai  wrote:
> > >
> > > > exactly..the ip layer should drop the packet..why should OSPF care
> about
> > > > it..dont you think its the ip layers job to check mtu conformance of
> > > > incomming packets ?
> > > >
> > > >
> > > > >From: Daniel Gryniewicz 
> > > > >Reply-To: Mailing List 
> > > > >To: OSPF@DISCUSS.MICROSOFT.COM
> > > > >Subject: Re: mtu in DD exchange.
> > > > >Date: Thu, 20 Jun 2002 13:59:07 -0400
> > > > >
> > > > >What fragments?  All OSPF (baring virtual links) traffic is only on
> one
> > > > >link.
> > > > >What the MTU agreement assures is that everyone on the link agrees
> what
> > >the
> > > > >MTU *for that link* should be.  If I think the MTU is 9000, and you
> > >think
> > > > >the
> > > > >MTU is 1500, you'll silently drop all my packets.  My IP layer won't
> > > > >fragment,
> > > > >because it thinks the MTU is large enough.
> > > > >
> > > > >Daniel
> > > > >
> > > > >On Thu, 20 Jun 2002 10:45:44 -0700
> > > > >prashant desai  wrote:
> > > > >
> > > > > > Hi,
> > > > > > Can anyone give me a good reason why OSPF routers have to agree on
> > > > > > the MTU size during DD exchange process..
> > > > > > As OSPF runs over IP..fragmentation or reassembly should not be
> its
> > > > > > concern..and they will be transparently handled by the IP layer..
> > > > > >
> > > > > > Prashant
> > > > > >


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Jun 21 14:11:06 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25293
	for ; Fri, 21 Jun 2002 14:11:04 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.006607B9@cherry.ease.lsoft.com>; Fri, 21 Jun 2002 14:11:39 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 30304 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 21 Jun 2002 14:11:39 -0400
Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 21 Jun 2002 14:11:39 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id ; Fri, 21 Jun 2002 14:07:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  
Date:         Fri, 21 Jun 2002 14:11:12 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: "Manral, Vishwas" 
Subject: Re: mtu in DD exchange.
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Mitchell,

I would just like to add a few things now that you have raised the issue.
Firstly I guess you have a valid point of catching the MTU mismatch in
hellos.

However even in hellos we could as well do by just sending the value of MTU
and not padding, the reason we pad in ISIS is in case we have a bridged
sublink in between which has a lower MTU than the two ends. Also the Hello
padding does not solve the MTU problem in ISIS, as we require a globally
synched MTU in ISIS unlike in OSPF.

Thanks,
Vishwas

-----Original Message-----
From: Erblichs [mailto:erblichs@EARTHLINK.NET]
Sent: Friday, June 21, 2002 9:19 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: mtu in DD exchange.


Group, my two cents..

This "problem" was actually fixed in another LS protocol, ISIS
with its HELLO PDU. The hellos were padded to within 1 byte/octet
of the MTU. This allowed the perspective link partners to
implictly specify their MTUs. Else, no link partners with less
of a chance that a DR won't be able to send the proper CSNPs..

This was a tradeoff of bandwidth consumption versus forming
an adjacency that possibly would drop PDUs/ LSAs in the
future due to different MTUs.

I actually always thought that the MTU matching in OSPF should
be done with the Hello packet. You may ask why. This would
increase the chance that all 2-ways that could then be involved in
a DR or BDR election can actually form full adjacencies...

Where currently it is done later with the OSPF dbase descr packet..

Or did I miss something?....

Mitchell Erblich
======================


"Manral, Vishwas" wrote:
>
> Prashant/Daniel,
>
> Besides what Alex has already sent you may like to have a look at the
> discussions in the archives. This thing has been discussed a lot of times
in
> the past.
>
> Check
> http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0008&L=OSPF&P=R2394
> and
> http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0008&L=OSPF&P=R2279
.
>
> Besides the MTU check is (from RFC2328)
>
>         If the Interface MTU field in the Database Description packet
>         indicates an IP datagram size that is larger than the router can
>         accept on the receiving interface without fragmentation, the
>         Database Description packet is rejected.
>
> So if we did not want an MTU mismatch in any case, we could always send a
> value 0 for the Interface MTU, as is done on virtual links.
>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Daniel Gryniewicz [mailto:dang@NEXTHOP.COM]
> Sent: Friday, June 21, 2002 12:07 AM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Re: mtu in DD exchange.
>
> True, and it'll be resent forever, taking 9000 bytes of bandwidth every
> time.
> :(  And I'll still use it in my SPF, and so the black hole will still
> occure.
>
> Daniel
>
> On Thu, 20 Jun 2002 11:35:20 -0700
> prashant desai  wrote:
>
> > that makes sense :-)
> > but the drop lsa will not be acked....never reachd ospf
> >
> > thanks
> > Prashant
> >
> >
> > >From: Daniel Gryniewicz 
> > >Reply-To: Mailing List 
> > >To: OSPF@DISCUSS.MICROSOFT.COM
> > >Subject: Re: mtu in DD exchange.
> > >Date: Thu, 20 Jun 2002 14:30:58 -0400
> > >
> > >So, I send you the 9000 byte packet.  My IP layer thinks it's fine.
Your
> > >IP
> > >layer drops it.  An adjacency never forms.  Or, worse yet, the
adjacency
> > >formed (the HELLOs and DDs were all small enough) and then I get and
> flood
> > >a
> > >huge LSA from someone else.  You drop it, but I assume you have it.  My
> SPF
> > >puts a route from this LSA through you, but you don't have it, so
> > >blackhole.
> > >I *have* to know that every packet I send to you can make it.  The MTU
> > >agreement assures that packets won't get dropped because of MTU
mismatch.
> > >
> > >Daniel
> > >
> > >On Thu, 20 Jun 2002 11:27:52 -0700
> > >prashant desai  wrote:
> > >
> > > > exactly..the ip layer should drop the packet..why should OSPF care
> about
> > > > it..dont you think its the ip layers job to check mtu conformance of
> > > > incomming packets ?
> > > >
> > > >
> > > > >From: Daniel Gryniewicz 
> > > > >Reply-To: Mailing List 
> > > > >To: OSPF@DISCUSS.MICROSOFT.COM
> > > > >Subject: Re: mtu in DD exchange.
> > > > >Date: Thu, 20 Jun 2002 13:59:07 -0400
> > > > >
> > > > >What fragments?  All OSPF (baring virtual links) traffic is only on
> one
> > > > >link.
> > > > >What the MTU agreement assures is that everyone on the link agrees
> what
> > >the
> > > > >MTU *for that link* should be.  If I think the MTU is 9000, and you
> > >think
> > > > >the
> > > > >MTU is 1500, you'll silently drop all my packets.  My IP layer
won't
> > > > >fragment,
> > > > >because it thinks the MTU is large enough.
> > > > >
> > > > >Daniel
> > > > >
> > > > >On Thu, 20 Jun 2002 10:45:44 -0700
> > > > >prashant desai  wrote:
> > > > >
> > > > > > Hi,
> > > > > > Can anyone give me a good reason why OSPF routers have to agree
on
> > > > > > the MTU size during DD exchange process..
> > > > > > As OSPF runs over IP..fragmentation or reassembly should not be
> its
> > > > > > concern..and they will be transparently handled by the IP
layer..
> > > > > >
> > > > > > Prashant
> > > > > >


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Jun 24 02:01:47 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16474
	for ; Mon, 24 Jun 2002 02:01:46 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00664CBC@cherry.ease.lsoft.com>; Mon, 24 Jun 2002 2:02:20 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 40655 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 24 Jun 2002 02:02:20 -0400
Received: from 66.163.169.58 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Mon, 24 Jun 2002 02:02:19 -0400
Received: from [203.200.20.226] by web21509.mail.yahoo.com via HTTP; Sun, 23
          Jun 2002 23:02:19 PDT
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <20020624060219.86483.qmail@web21509.mail.yahoo.com>
Date:         Sun, 23 Jun 2002 23:02:19 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Amit Srivastava 
Subject: Database Over Flow Doubt
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  
Precedence: list

Hi Vishwas!!
  I have one more doubt the RFC 1765 say in example
(section 3) that when the OSPF timer expires then it
tries to come out of the database overflow state and
originates all the 400 non default AS-Exteranl LSA.Is
it that before flushing the LSA it keeps the LSA in a
linklist form and after the timer expires it
originates the LSA again!!If this is the case then i
have small doubt :-
             We have flushed the link state database
because we think that we cannot accomodate any other
LSA.Now keeping the log of all the flushed LSA would
not be a good idea what i feel!!!
What do u say??
Regards
Amit

--- "Manral, Vishwas"  wrote:
> Amit,
>
> When the administrator finds that a domain is
> getting "Overflows" he has to
> change the policies so that the number of routes
> imported into the domain is
> reduced. The routes to be imported are all an
> administrative
> decision/policies and the OSPF packets etc do not
> come into picture at all.
>
> The RFC in this point talks about importing routes
> from other domains and
> not about received LSA's from other routers in the
> domain.
>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
> Sent: Friday, June 21, 2002 4:35 PM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Re: OSPF Retransmission Doubt
>
>
>  Hi Vishwas!!
>       The RFC 1765 section 4 last point states that
> if
> the administrator cannot incresase the value of
> ospfExtlsdbLimit then he can make sure that more
> important routes continue to be imported ; this is
> accomplished by turning off the importing of less
> important routes.
>       Now my doubt is ->is it that the administrator
> configures paticular n/w coming in the AS-external
> packet as important or unimportant or does it mean
> that routes learned by a paticular router-id are
> important and will stay in the database while all
> the
> others will be flushed or is it implementation
> specific!!!
> Regards
> Amit
>
>
>
>
> --- "Manral, Vishwas"  wrote:
> > Hi Amit,
> >
> > The case would not occur if all the routers would
> > have the same value of
> > ExtLSDBLimit except in the transient condition.
> > Section 2.2 first part would
> > only occur if the value is not the same this may
> be
> > required. Its always
> > better to check the condition, if we are exceeding
> > the limit and accordingly
> > take action to get over any such a case.
> >
> > Section 2.3 states that the flooding modification
> > would only be invoked
> > during a "short period of convergence" for same
> > value of LSDBLimit. Such a
> > case would only occur say when two routers are
> > symultaneously originating
> > AS-External LSA's. So when they are originating
> the
> > LSA's the LSDB limit is
> > not exceeded however when they are receiving the
> > LSA's from the other the
> > LSDB limit is exceeded. However as the RFC states
> > this would be a transient
> > condition.
> >
> > Thanks,
> > Vishwas
> >
> > -----Original Message-----
> > From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
> > Sent: Thursday, June 20, 2002 10:24 AM
> > To: OSPF@DISCUSS.MICROSOFT.COM
> > Subject: Re: OSPF Retransmission Doubt
> >
> >
> > Hi Vishwas,
> >    I have a small doubt .If u refer to section 2.2
> > and
> > 2.3 of RFC 1765 it states that during flooding
> also
> > the variable count of non-default AS_external LSA
> is
> > incremented( if we receive a non-default
> AS-external
> > LSA during flooding).But if we have a common
> thresh
> > hold limit i.e variable ospfExtlsdbLimit is same
> for
> > all the router how come this condition will be
> > encountered???
> > Regards
> > Amit
> >
> >
> >
> >
> > --- "Manral, Vishwas" 
> wrote:
> > > Hi Amit,
> > >
> > > I do not think any RFC which talks about
> > non-default
> > > type-3 LSA's exists.
> > > The RFC1765 only talks about type-5 LSA's
> however
> > it
> > > could be extended for
> > > other type of LSA's i.e. type-7, type-11.
> > >
> > > Thanks,
> > > Vishwas
> > >
> > > -----Original Message-----
> > > From: Amit Srivastava
> [mailto:ospfisfun@YAHOO.COM]
> > > Sent: Wednesday, June 19, 2002 11:43 AM
> > > To: OSPF@DISCUSS.MICROSOFT.COM
> > > Subject: Re: OSPF Retransmission Doubt
> > >
> > >
> > >
> > >  Hi Erblich and Vishwas,
> > >       Erblich I got your point but is there any
> > > Draft or RFC which
> > > states
> > > this??
> > >      And Vishwas thanks for your help i would
> also
> > > like to know if
> > > there is any draft which states that we can
> > withdraw
> > > Summary 3 and 4
> > > non-default LSA.Because The RFC 2370 specks very
> > > little about it.
> > > Regards
> > > Amit
> > >
> > >
> > >
> > >   Amit Srivastava  wrote:
> > >
> > >
> > > Hi Vishwas!
> > >
> > >
> > >           Actually after reading the RFC 1765
> only
> > i
> > > got this doubt.Here i
> > > feel once the OSPFEXTLSDBLinit variable is
> > exceeded
> > > the router should
> > > indicate other routers that its database is full
> > and
> > > they should not keep on
> > > retransmitting the LSA which will clog the n/w
> > > bandwidth.Once the router
> > > comes out of the database overflow state it
> should
> > > indicate to the other
> > > router that now they should send the LSA.
> > >
> > >
> > >       What do you say about this??
> > >
> > >
> > > Regards
> > >
> > >
> > > Amit
> > >
> > >   "Manral, Vishwas" 
> wrote:
> > >
> > >
> > > Hi Amit,
> > >
> > > You may like to look at the RFC1765 - OSPF
> > Database
> > > Overflow.
> > > http://www.ietf.org/rfc/rfc1765.txt This RFC
> tells
> > a
> > > way to deal with such
> > > overflow when it occurs in OSPF.
> > >
> > > Also as the RFC lists as enhancements, if the
> > number
> > > of summary LSA's
>
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Jun 24 03:53:28 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24956
	for ; Mon, 24 Jun 2002 03:53:28 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00664D60@cherry.ease.lsoft.com>; Mon, 24 Jun 2002 3:54:09 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 40820 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 24 Jun 2002 03:54:07 -0400
Received: from 205.158.62.111 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Mon, 24 Jun 2002 03:54:07 -0400
Received: (qmail 71239 invoked by uid 1001); 24 Jun 2002 07:54:07 -0000
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-Mailer: MIME-tools 5.41 (Entity 5.404)
Received: from [129.187.222.168] by ws1-10.us4.outblaze.com with http for
          beatriz_hargrave@mail.com; Mon, 24 Jun 2002 02:54:07 -0500
X-Originating-Ip: 129.187.222.168
X-Originating-Server: ws1-10.us4.outblaze.com
Message-ID:  <20020624075407.71238.qmail@mail.com>
Date:         Mon, 24 Jun 2002 02:54:07 -0500
Reply-To: Mailing List 
Sender: Mailing List 
From: Beatriz Silva 
Subject: Multicast addresses AllSPFRouters, AllDRouters
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi !

I realized that as soon as I put one of the routers interfaces up, one of the first things that is done is to send a IGMP membership report message to AllSPFRouters and another to AllDRouters. Does anybody knows why ?? Does the router interface keeps a table including all of the member addresses of these multicast addresses ? Is there a mapping from the Ip multicast address to all of the destined mac addresses ?

Thank you very much,

Beatriz
--
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

Save up to $160 by signing up for NetZero Platinum Internet service.
http://www.netzero.net/?refcd=N2P0602NEP8


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Jun 24 05:41:43 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27313
	for ; Mon, 24 Jun 2002 05:41:42 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00665043@cherry.ease.lsoft.com>; Mon, 24 Jun 2002 5:41:35 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 41304 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 24 Jun 2002 05:41:35 -0400
Received: from 66.163.169.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Mon, 24 Jun 2002 05:41:34 -0400
Received: from [203.200.20.226] by web21508.mail.yahoo.com via HTTP; Mon, 24
          Jun 2002 02:41:34 PDT
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <20020624094134.98340.qmail@web21508.mail.yahoo.com>
Date:         Mon, 24 Jun 2002 02:41:34 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Amit Srivastava 
Subject: Re: Multicast addresses AllSPFRouters, AllDRouters
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <20020624075407.71238.qmail@mail.com>
Precedence: list

Hi Beatriz.
   As far as i could understand your problem the
answer to it is:-
           The Ip layer keeps a buffer(table) in which
it stores all the IP addresses it is listening to.So
when a packet is send on the net the Ip layer would
check the destination ip address from the buffer it is
holding and if the address is found then it will give
the packet to the other protocol otherwise it will
discard the packet.
Regards
Amit
--- Beatriz Silva  wrote:
> Hi !
>
> I realized that as soon as I put one of the routers
> interfaces up, one of the first things that is done
> is to send a IGMP membership report message to
> AllSPFRouters and another to AllDRouters. Does
> anybody knows why ?? Does the router interface keeps
> a table including all of the member addresses of
> these multicast addresses ? Is there a mapping from
> the Ip multicast address to all of the destined mac
> addresses ?
>
> Thank you very much,
>
> Beatriz
> --
>
__________________________________________________________
> Sign-up for your own FREE Personalized E-mail at
> Mail.com
> http://www.mail.com/?sr=signup
>
> Save up to $160 by signing up for NetZero Platinum
> Internet service.
> http://www.netzero.net/?refcd=N2P0602NEP8


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Jun 24 06:20:41 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28038
	for ; Mon, 24 Jun 2002 06:20:41 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00664F43@cherry.ease.lsoft.com>; Mon, 24 Jun 2002 6:21:22 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 41706 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 24 Jun 2002 06:21:22 -0400
Received: from 205.158.62.50 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Mon, 24 Jun 2002 06:21:22 -0400
Received: (qmail 20502 invoked by uid 1001); 24 Jun 2002 10:20:00 -0000
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-Mailer: MIME-tools 5.41 (Entity 5.404)
Received: from [129.187.222.168] by ws1-4.us4.outblaze.com with http for
          beatriz_hargrave@mail.com; Mon, 24 Jun 2002 05:20:00 -0500
X-Originating-Ip: 129.187.222.168
X-Originating-Server: ws1-4.us4.outblaze.com
Message-ID:  <20020624102000.20500.qmail@mail.com>
Date:         Mon, 24 Jun 2002 05:20:00 -0500
Reply-To: Mailing List 
Sender: Mailing List 
From: Beatriz Silva 
Subject: Re: Multicast addresses AllSPFRouters, AllDRouters
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Amit, thanks for the answer. But I still have some doubts ...

More specifically my question is:

When a packet to AllSPFRouters is sent, what is the MAC address written in the destination field of the Ethernet header ? Is it a mac multicast address or is there a mapping between the ip multicast address and the mac addresses of all of the routers that joined that multicast address ?
And what must be done in the router in order for it to be capable to liste to packets to multicast address AllSPFRouters and AllDRouters (if it is the case) ?
Why does the router have to send an IGMP membership report message to AllSPFaddress and to AllDRouters multicast addresses ?

I hope I am not too confusing ..

Thank you,

Beatriz
> > AllSPFRouters and another to AllDRouters
----- Original Message -----
From: Amit Srivastava 
Date:         Mon, 24 Jun 2002 02:41:34 -0700
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: Multicast addresses AllSPFRouters, AllDRouters


> Hi Beatriz.
>    As far as i could understand your problem the
> answer to it is:-
>            The Ip layer keeps a buffer(table) in which
> it stores all the IP addresses it is listening to.So
> when a packet is send on the net the Ip layer would
> check the destination ip address from the buffer it is
> holding and if the address is found then it will give
> the packet to the other protocol otherwise it will
> discard the packet.
> Regards
> Amit
> --- Beatriz Silva  wrote:
> > Hi !
> >
> > I realized that as soon as I put one of the routers
> > interfaces up, one of the first things that is done
> > is to send a IGMP membership report message to
> > AllSPFRouters and another to AllDRouters. Does
> > anybody knows why ?? Does the router interface keeps
> > a table including all of the member addresses of
> > these multicast addresses ? Is there a mapping from
> > the Ip multicast address to all of the destined mac
> > addresses ?
> >
> > Thank you very much,
> >
> > Beatriz
> > --
> >
> __________________________________________________________
> > Sign-up for your own FREE Personalized E-mail at
> > Mail.com
> > http://www.mail.com/?sr=signup
> >
> > Save up to $160 by signing up for NetZero Platinum
> > Internet service.
> > http://www.netzero.net/?refcd=N2P0602NEP8
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com
>

--
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

Save up to $160 by signing up for NetZero Platinum Internet service.
http://www.netzero.net/?refcd=N2P0602NEP8


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Jun 24 08:09:25 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02251
	for ; Mon, 24 Jun 2002 08:09:24 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.006650C0@cherry.ease.lsoft.com>; Mon, 24 Jun 2002 8:10:05 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 42137 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 24 Jun 2002 08:10:05 -0400
Received: from 66.163.169.58 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Mon, 24 Jun 2002 08:10:05 -0400
Received: from [203.200.20.226] by web21509.mail.yahoo.com via HTTP; Mon, 24
          Jun 2002 05:10:00 PDT
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <20020624121000.49807.qmail@web21509.mail.yahoo.com>
Date:         Mon, 24 Jun 2002 05:10:00 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Amit Srivastava 
Subject: Re: Multicast addresses AllSPFRouters, AllDRouters
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <20020624102000.20500.qmail@mail.com>
Precedence: list

Hi Beatriz,
      The mac address that is sent(as destination) is
the exact mapping of the multicast IP address.If you
are using the Linux system then by default it supports
Mac layer multicast support.
            So if your destination IP is 224.0.0.5
then your mac destination address will be 01 00 5e 00
00 05 in hex.
       The IGMP group joining is sent as a rule for
the IP multicaste which states that whenever you join
any group of multicaste address you have to send a
group join indiaction to your router.Study multicaste
general protocol to make picture more clear.
I hope i am clear!!
Regards
Amit
--- Beatriz Silva  wrote:
> Amit, thanks for the answer. But I still have some
> doubts ...
>
> More specifically my question is:
>
> When a packet to AllSPFRouters is sent, what is the
> MAC address written in the destination field of the
> Ethernet header ? Is it a mac multicast address or
> is there a mapping between the ip multicast address
> and the mac addresses of all of the routers that
> joined that multicast address ?
> And what must be done in the router in order for it
> to be capable to liste to packets to multicast
> address AllSPFRouters and AllDRouters (if it is the
> case) ?
> Why does the router have to send an IGMP membership
> report message to AllSPFaddress and to AllDRouters
> multicast addresses ?
>
> I hope I am not too confusing ..
>
> Thank you,
>
> Beatriz
> > > AllSPFRouters and another to AllDRouters
> ----- Original Message -----
> From: Amit Srivastava 
> Date:         Mon, 24 Jun 2002 02:41:34 -0700
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Re: Multicast addresses AllSPFRouters,
> AllDRouters
>
>
> > Hi Beatriz.
> >    As far as i could understand your problem the
> > answer to it is:-
> >            The Ip layer keeps a buffer(table) in
> which
> > it stores all the IP addresses it is listening
> to.So
> > when a packet is send on the net the Ip layer
> would
> > check the destination ip address from the buffer
> it is
> > holding and if the address is found then it will
> give
> > the packet to the other protocol otherwise it will
> > discard the packet.
> > Regards
> > Amit
> > --- Beatriz Silva 
> wrote:
> > > Hi !
> > >
> > > I realized that as soon as I put one of the
> routers
> > > interfaces up, one of the first things that is
> done
> > > is to send a IGMP membership report message to
> > > AllSPFRouters and another to AllDRouters. Does
> > > anybody knows why ?? Does the router interface
> keeps
> > > a table including all of the member addresses of
> > > these multicast addresses ? Is there a mapping
> from
> > > the Ip multicast address to all of the destined
> mac
> > > addresses ?
> > >
> > > Thank you very much,
> > >
> > > Beatriz
> > > --
> > >
> >
>
__________________________________________________________
> > > Sign-up for your own FREE Personalized E-mail at
> > > Mail.com
> > > http://www.mail.com/?sr=signup
> > >
> > > Save up to $160 by signing up for NetZero
> Platinum
> > > Internet service.
> > > http://www.netzero.net/?refcd=N2P0602NEP8
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! - Official partner of 2002 FIFA World Cup
> > http://fifaworldcup.yahoo.com
> >
>
> --
>
__________________________________________________________
> Sign-up for your own FREE Personalized E-mail at
> Mail.com
> http://www.mail.com/?sr=signup
>
> Save up to $160 by signing up for NetZero Platinum
> Internet service.
> http://www.netzero.net/?refcd=N2P0602NEP8


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Jun 24 12:06:42 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14647
	for ; Mon, 24 Jun 2002 12:06:41 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00665846@cherry.ease.lsoft.com>; Mon, 24 Jun 2002 12:07:13 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 43557 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 24 Jun 2002 12:07:12 -0400
Received: from 207.217.120.22 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Mon, 24 Jun 2002 12:07:12 -0400
Received: from user-2ivfk8v.dialup.mindspring.com ([165.247.209.31]
          helo=earthlink.net) by hawk.mail.pas.earthlink.net with esmtp (Exim
          3.33 #2) id 17MWMw-00073n-00 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 24
          Jun 2002 09:07:10 -0700
X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified)
X-Mailer: Mozilla 4.72 [en]C-gatewaynet  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D17460A.FED766E3@earthlink.net>
Date:         Mon, 24 Jun 2002 09:17:14 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Erblichs 
Subject: Re: mtu in DD exchange.
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Vishwas and group,

        A MTU comparison in the hellos is really
        what I was suggesting and didn't know why
        it wasn't done...

        Mitchell Erblich
        -----------------



"Manral, Vishwas" wrote:
>
> Mitchell,
>
> I would just like to add a few things now that you have raised the issue.
> Firstly I guess you have a valid point of catching the MTU mismatch in
> hellos.
>
> However even in hellos we could as well do by just sending the value of MTU
> and not padding, the reason we pad in ISIS is in case we have a bridged
> sublink in between which has a lower MTU than the two ends. Also the Hello
> padding does not solve the MTU problem in ISIS, as we require a globally
> synched MTU in ISIS unlike in OSPF.
>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Erblichs [mailto:erblichs@EARTHLINK.NET]
> Sent: Friday, June 21, 2002 9:19 PM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Re: mtu in DD exchange.
>
> Group, my two cents..
>
> This "problem" was actually fixed in another LS protocol, ISIS
> with its HELLO PDU. The hellos were padded to within 1 byte/octet
> of the MTU. This allowed the perspective link partners to
> implictly specify their MTUs. Else, no link partners with less
> of a chance that a DR won't be able to send the proper CSNPs..
>
> This was a tradeoff of bandwidth consumption versus forming
> an adjacency that possibly would drop PDUs/ LSAs in the
> future due to different MTUs.
>
> I actually always thought that the MTU matching in OSPF should
> be done with the Hello packet. You may ask why. This would
> increase the chance that all 2-ways that could then be involved in
> a DR or BDR election can actually form full adjacencies...
>
> Where currently it is done later with the OSPF dbase descr packet..
>
> Or did I miss something?....
>
> Mitchell Erblich
> ======================
>
> "Manral, Vishwas" wrote:
> >
> > Prashant/Daniel,
> >
> > Besides what Alex has already sent you may like to have a look at the
> > discussions in the archives. This thing has been discussed a lot of times
> in
> > the past.
> >
> > Check
> > http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0008&L=OSPF&P=R2394
> > and
> > http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0008&L=OSPF&P=R2279
> .
> >
> > Besides the MTU check is (from RFC2328)
> >
> >         If the Interface MTU field in the Database Description packet
> >         indicates an IP datagram size that is larger than the router can
> >         accept on the receiving interface without fragmentation, the
> >         Database Description packet is rejected.
> >
> > So if we did not want an MTU mismatch in any case, we could always send a
> > value 0 for the Interface MTU, as is done on virtual links.
> >
> > Thanks,
> > Vishwas
> >
> > -----Original Message-----
> > From: Daniel Gryniewicz [mailto:dang@NEXTHOP.COM]
> > Sent: Friday, June 21, 2002 12:07 AM
> > To: OSPF@DISCUSS.MICROSOFT.COM
> > Subject: Re: mtu in DD exchange.
> >
> > True, and it'll be resent forever, taking 9000 bytes of bandwidth every
> > time.
> > :(  And I'll still use it in my SPF, and so the black hole will still
> > occure.
> >
> > Daniel
> >
> > On Thu, 20 Jun 2002 11:35:20 -0700
> > prashant desai  wrote:
> >
> > > that makes sense :-)
> > > but the drop lsa will not be acked....never reachd ospf
> > >
> > > thanks
> > > Prashant
> > >
> > >
> > > >From: Daniel Gryniewicz 
> > > >Reply-To: Mailing List 
> > > >To: OSPF@DISCUSS.MICROSOFT.COM
> > > >Subject: Re: mtu in DD exchange.
> > > >Date: Thu, 20 Jun 2002 14:30:58 -0400
> > > >
> > > >So, I send you the 9000 byte packet.  My IP layer thinks it's fine.
> Your
> > > >IP
> > > >layer drops it.  An adjacency never forms.  Or, worse yet, the
> adjacency
> > > >formed (the HELLOs and DDs were all small enough) and then I get and
> > flood
> > > >a
> > > >huge LSA from someone else.  You drop it, but I assume you have it.  My
> > SPF
> > > >puts a route from this LSA through you, but you don't have it, so
> > > >blackhole.
> > > >I *have* to know that every packet I send to you can make it.  The MTU
> > > >agreement assures that packets won't get dropped because of MTU
> mismatch.
> > > >
> > > >Daniel
> > > >
> > > >On Thu, 20 Jun 2002 11:27:52 -0700
> > > >prashant desai  wrote:
> > > >
> > > > > exactly..the ip layer should drop the packet..why should OSPF care
> > about
> > > > > it..dont you think its the ip layers job to check mtu conformance of
> > > > > incomming packets ?
> > > > >
> > > > >
> > > > > >From: Daniel Gryniewicz 
> > > > > >Reply-To: Mailing List 
> > > > > >To: OSPF@DISCUSS.MICROSOFT.COM
> > > > > >Subject: Re: mtu in DD exchange.
> > > > > >Date: Thu, 20 Jun 2002 13:59:07 -0400
> > > > > >
> > > > > >What fragments?  All OSPF (baring virtual links) traffic is only on
> > one
> > > > > >link.
> > > > > >What the MTU agreement assures is that everyone on the link agrees
> > what
> > > >the
> > > > > >MTU *for that link* should be.  If I think the MTU is 9000, and you
> > > >think
> > > > > >the
> > > > > >MTU is 1500, you'll silently drop all my packets.  My IP layer
> won't
> > > > > >fragment,
> > > > > >because it thinks the MTU is large enough.
> > > > > >
> > > > > >Daniel
> > > > > >
> > > > > >On Thu, 20 Jun 2002 10:45:44 -0700
> > > > > >prashant desai  wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > > Can anyone give me a good reason why OSPF routers have to agree
> on
> > > > > > > the MTU size during DD exchange process..
> > > > > > > As OSPF runs over IP..fragmentation or reassembly should not be
> > its
> > > > > > > concern..and they will be transparently handled by the IP
> layer..
> > > > > > >
> > > > > > > Prashant
> > > > > > >


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Jun 24 12:13:10 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15021
	for ; Mon, 24 Jun 2002 12:13:10 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.006657A8@cherry.ease.lsoft.com>; Mon, 24 Jun 2002 12:13:51 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 43611 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 24 Jun 2002 12:13:50 -0400
Received: from 207.217.120.22 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Mon, 24 Jun 2002 12:13:50 -0400
Received: from user-2ivfk8v.dialup.mindspring.com ([165.247.209.31]
          helo=earthlink.net) by hawk.mail.pas.earthlink.net with esmtp (Exim
          3.33 #2) id 17MWTM-0001Ez-00 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 24
          Jun 2002 09:13:49 -0700
X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified)
X-Mailer: Mozilla 4.72 [en]C-gatewaynet  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <20020624060219.86483.qmail@web21509.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D174799.18EE09D0@earthlink.net>
Date:         Mon, 24 Jun 2002 09:23:53 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Erblichs 
Subject: Re: Database Over Flow Doubt
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Amit,

        Why don't you think a log of flushed LSAs
        is a good idea?

        - Are you concerned with the amount of memory
        consumed with the log?

        - Are you concerned that the log has a certain
        time frame that is valid and as time progresses
        the information becomes useless?

        - Are you concerned what you are going to do with
        the log after you create it?

        - Etc...

        Mitchell Erblich
        ================



Amit Srivastava wrote:
>
> Hi Vishwas!!
>   I have one more doubt the RFC 1765 say in example
> (section 3) that when the OSPF timer expires then it
> tries to come out of the database overflow state and
> originates all the 400 non default AS-Exteranl LSA.Is
> it that before flushing the LSA it keeps the LSA in a
> linklist form and after the timer expires it
> originates the LSA again!!If this is the case then i
> have small doubt :-
>              We have flushed the link state database
> because we think that we cannot accomodate any other
> LSA.Now keeping the log of all the flushed LSA would
> not be a good idea what i feel!!!
> What do u say??
> Regards
> Amit
>
> --- "Manral, Vishwas"  wrote:
> > Amit,
> >
> > When the administrator finds that a domain is
> > getting "Overflows" he has to
> > change the policies so that the number of routes
> > imported into the domain is
> > reduced. The routes to be imported are all an
> > administrative
> > decision/policies and the OSPF packets etc do not
> > come into picture at all.
> >
> > The RFC in this point talks about importing routes
> > from other domains and
> > not about received LSA's from other routers in the
> > domain.
> >
> > Thanks,
> > Vishwas
> >
> > -----Original Message-----
> > From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
> > Sent: Friday, June 21, 2002 4:35 PM
> > To: OSPF@DISCUSS.MICROSOFT.COM
> > Subject: Re: OSPF Retransmission Doubt
> >
> >
> >  Hi Vishwas!!
> >       The RFC 1765 section 4 last point states that
> > if
> > the administrator cannot incresase the value of
> > ospfExtlsdbLimit then he can make sure that more
> > important routes continue to be imported ; this is
> > accomplished by turning off the importing of less
> > important routes.
> >       Now my doubt is ->is it that the administrator
> > configures paticular n/w coming in the AS-external
> > packet as important or unimportant or does it mean
> > that routes learned by a paticular router-id are
> > important and will stay in the database while all
> > the
> > others will be flushed or is it implementation
> > specific!!!
> > Regards
> > Amit
> >
> >
> >
> >
> > --- "Manral, Vishwas"  wrote:
> > > Hi Amit,
> > >
> > > The case would not occur if all the routers would
> > > have the same value of
> > > ExtLSDBLimit except in the transient condition.
> > > Section 2.2 first part would
> > > only occur if the value is not the same this may
> > be
> > > required. Its always
> > > better to check the condition, if we are exceeding
> > > the limit and accordingly
> > > take action to get over any such a case.
> > >
> > > Section 2.3 states that the flooding modification
> > > would only be invoked
> > > during a "short period of convergence" for same
> > > value of LSDBLimit. Such a
> > > case would only occur say when two routers are
> > > symultaneously originating
> > > AS-External LSA's. So when they are originating
> > the
> > > LSA's the LSDB limit is
> > > not exceeded however when they are receiving the
> > > LSA's from the other the
> > > LSDB limit is exceeded. However as the RFC states
> > > this would be a transient
> > > condition.
> > >
> > > Thanks,
> > > Vishwas
> > >
> > > -----Original Message-----
> > > From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
> > > Sent: Thursday, June 20, 2002 10:24 AM
> > > To: OSPF@DISCUSS.MICROSOFT.COM
> > > Subject: Re: OSPF Retransmission Doubt
> > >
> > >
> > > Hi Vishwas,
> > >    I have a small doubt .If u refer to section 2.2
> > > and
> > > 2.3 of RFC 1765 it states that during flooding
> > also
> > > the variable count of non-default AS_external LSA
> > is
> > > incremented( if we receive a non-default
> > AS-external
> > > LSA during flooding).But if we have a common
> > thresh
> > > hold limit i.e variable ospfExtlsdbLimit is same
> > for
> > > all the router how come this condition will be
> > > encountered???
> > > Regards
> > > Amit
> > >
> > >
> > >
> > >
> > > --- "Manral, Vishwas" 
> > wrote:
> > > > Hi Amit,
> > > >
> > > > I do not think any RFC which talks about
> > > non-default
> > > > type-3 LSA's exists.
> > > > The RFC1765 only talks about type-5 LSA's
> > however
> > > it
> > > > could be extended for
> > > > other type of LSA's i.e. type-7, type-11.
> > > >
> > > > Thanks,
> > > > Vishwas
> > > >
> > > > -----Original Message-----
> > > > From: Amit Srivastava
> > [mailto:ospfisfun@YAHOO.COM]
> > > > Sent: Wednesday, June 19, 2002 11:43 AM
> > > > To: OSPF@DISCUSS.MICROSOFT.COM
> > > > Subject: Re: OSPF Retransmission Doubt
> > > >
> > > >
> > > >
> > > >  Hi Erblich and Vishwas,
> > > >       Erblich I got your point but is there any
> > > > Draft or RFC which
> > > > states
> > > > this??
> > > >      And Vishwas thanks for your help i would
> > also
> > > > like to know if
> > > > there is any draft which states that we can
> > > withdraw
> > > > Summary 3 and 4
> > > > non-default LSA.Because The RFC 2370 specks very
> > > > little about it.
> > > > Regards
> > > > Amit
> > > >
> > > >
> > > >
> > > >   Amit Srivastava  wrote:
> > > >
> > > >
> > > > Hi Vishwas!
> > > >
> > > >
> > > >           Actually after reading the RFC 1765
> > only
> > > i
> > > > got this doubt.Here i
> > > > feel once the OSPFEXTLSDBLinit variable is
> > > exceeded
> > > > the router should
> > > > indicate other routers that its database is full
> > > and
> > > > they should not keep on
> > > > retransmitting the LSA which will clog the n/w
> > > > bandwidth.Once the router
> > > > comes out of the database overflow state it
> > should
> > > > indicate to the other
> > > > router that now they should send the LSA.
> > > >
> > > >
> > > >       What do you say about this??
> > > >
> > > >
> > > > Regards
> > > >
> > > >
> > > > Amit
> > > >
> > > >   "Manral, Vishwas" 
> > wrote:
> > > >
> > > >
> > > > Hi Amit,
> > > >
> > > > You may like to look at the RFC1765 - OSPF
> > > Database
> > > > Overflow.
> > > > http://www.ietf.org/rfc/rfc1765.txt This RFC
> > tells
> > > a
> > > > way to deal with such
> > > > overflow when it occurs in OSPF.
> > > >
> > > > Also as the RFC lists as enhancements, if the
> > > number
> > > > of summary LSA's
> >
> === message truncated ===
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Jun 24 13:13:34 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18415
	for ; Mon, 24 Jun 2002 13:13:33 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00665855@cherry.ease.lsoft.com>; Mon, 24 Jun 2002 13:14:01 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 43917 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 24 Jun 2002 13:14:01 -0400
Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Mon, 24 Jun 2002 13:13:51 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id ; Mon, 24 Jun 2002 13:09:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  
Date:         Mon, 24 Jun 2002 13:16:23 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: "Manral, Vishwas" 
Subject: Re: Database Over Flow Doubt
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Amit,

You can do it either way, as long as you are somehow able to get back the
LSA's that you wanted to originate and that you could not originate, when
you come out of overflow state.

Thanks,
Vishwas

-----Original Message-----
From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
Sent: Monday, June 24, 2002 11:32 AM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Database Over Flow Doubt


Hi Vishwas!!
  I have one more doubt the RFC 1765 say in example
(section 3) that when the OSPF timer expires then it
tries to come out of the database overflow state and
originates all the 400 non default AS-Exteranl LSA.Is
it that before flushing the LSA it keeps the LSA in a
linklist form and after the timer expires it
originates the LSA again!!If this is the case then i
have small doubt :-
             We have flushed the link state database
because we think that we cannot accomodate any other
LSA.Now keeping the log of all the flushed LSA would
not be a good idea what i feel!!!
What do u say??
Regards
Amit

--- "Manral, Vishwas"  wrote:
> Amit,
>
> When the administrator finds that a domain is
> getting "Overflows" he has to
> change the policies so that the number of routes
> imported into the domain is
> reduced. The routes to be imported are all an
> administrative
> decision/policies and the OSPF packets etc do not
> come into picture at all.
>
> The RFC in this point talks about importing routes
> from other domains and
> not about received LSA's from other routers in the
> domain.
>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
> Sent: Friday, June 21, 2002 4:35 PM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Re: OSPF Retransmission Doubt
>
>
>  Hi Vishwas!!
>       The RFC 1765 section 4 last point states that
> if
> the administrator cannot incresase the value of
> ospfExtlsdbLimit then he can make sure that more
> important routes continue to be imported ; this is
> accomplished by turning off the importing of less
> important routes.
>       Now my doubt is ->is it that the administrator
> configures paticular n/w coming in the AS-external
> packet as important or unimportant or does it mean
> that routes learned by a paticular router-id are
> important and will stay in the database while all
> the
> others will be flushed or is it implementation
> specific!!!
> Regards
> Amit
>
>
>
>
> --- "Manral, Vishwas"  wrote:
> > Hi Amit,
> >
> > The case would not occur if all the routers would
> > have the same value of
> > ExtLSDBLimit except in the transient condition.
> > Section 2.2 first part would
> > only occur if the value is not the same this may
> be
> > required. Its always
> > better to check the condition, if we are exceeding
> > the limit and accordingly
> > take action to get over any such a case.
> >
> > Section 2.3 states that the flooding modification
> > would only be invoked
> > during a "short period of convergence" for same
> > value of LSDBLimit. Such a
> > case would only occur say when two routers are
> > symultaneously originating
> > AS-External LSA's. So when they are originating
> the
> > LSA's the LSDB limit is
> > not exceeded however when they are receiving the
> > LSA's from the other the
> > LSDB limit is exceeded. However as the RFC states
> > this would be a transient
> > condition.
> >
> > Thanks,
> > Vishwas
> >
> > -----Original Message-----
> > From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
> > Sent: Thursday, June 20, 2002 10:24 AM
> > To: OSPF@DISCUSS.MICROSOFT.COM
> > Subject: Re: OSPF Retransmission Doubt
> >
> >
> > Hi Vishwas,
> >    I have a small doubt .If u refer to section 2.2
> > and
> > 2.3 of RFC 1765 it states that during flooding
> also
> > the variable count of non-default AS_external LSA
> is
> > incremented( if we receive a non-default
> AS-external
> > LSA during flooding).But if we have a common
> thresh
> > hold limit i.e variable ospfExtlsdbLimit is same
> for
> > all the router how come this condition will be
> > encountered???
> > Regards
> > Amit
> >
> >
> >
> >
> > --- "Manral, Vishwas" 
> wrote:
> > > Hi Amit,
> > >
> > > I do not think any RFC which talks about
> > non-default
> > > type-3 LSA's exists.
> > > The RFC1765 only talks about type-5 LSA's
> however
> > it
> > > could be extended for
> > > other type of LSA's i.e. type-7, type-11.
> > >
> > > Thanks,
> > > Vishwas
> > >
> > > -----Original Message-----
> > > From: Amit Srivastava
> [mailto:ospfisfun@YAHOO.COM]
> > > Sent: Wednesday, June 19, 2002 11:43 AM
> > > To: OSPF@DISCUSS.MICROSOFT.COM
> > > Subject: Re: OSPF Retransmission Doubt
> > >
> > >
> > >
> > >  Hi Erblich and Vishwas,
> > >       Erblich I got your point but is there any
> > > Draft or RFC which
> > > states
> > > this??
> > >      And Vishwas thanks for your help i would
> also
> > > like to know if
> > > there is any draft which states that we can
> > withdraw
> > > Summary 3 and 4
> > > non-default LSA.Because The RFC 2370 specks very
> > > little about it.
> > > Regards
> > > Amit
> > >
> > >
> > >
> > >   Amit Srivastava  wrote:
> > >
> > >
> > > Hi Vishwas!
> > >
> > >
> > >           Actually after reading the RFC 1765
> only
> > i
> > > got this doubt.Here i
> > > feel once the OSPFEXTLSDBLinit variable is
> > exceeded
> > > the router should
> > > indicate other routers that its database is full
> > and
> > > they should not keep on
> > > retransmitting the LSA which will clog the n/w
> > > bandwidth.Once the router
> > > comes out of the database overflow state it
> should
> > > indicate to the other
> > > router that now they should send the LSA.
> > >
> > >
> > >       What do you say about this??
> > >
> > >
> > > Regards
> > >
> > >
> > > Amit
> > >
> > >   "Manral, Vishwas" 
> wrote:
> > >
> > >
> > > Hi Amit,
> > >
> > > You may like to look at the RFC1765 - OSPF
> > Database
> > > Overflow.
> > > http://www.ietf.org/rfc/rfc1765.txt This RFC
> tells
> > a
> > > way to deal with such
> > > overflow when it occurs in OSPF.
> > >
> > > Also as the RFC lists as enhancements, if the
> > number
> > > of summary LSA's
>


From owner-ospf@DISCUSS.MICROSOFT.COM  Mon Jun 24 20:52:46 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08514
	for ; Mon, 24 Jun 2002 20:52:45 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00666528@cherry.ease.lsoft.com>; Mon, 24 Jun 2002 20:53:27 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 45540 for OSPF@DISCUSS.MICROSOFT.COM;
          Mon, 24 Jun 2002 20:53:26 -0400
Received: from 216.32.181.91 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Mon, 24 Jun 2002 20:53:26 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon,
          24 Jun 2002 17:53:26 -0700
Received: from 211.99.77.6 by lw2fd.hotmail.msn.com with HTTP; Tue, 25 Jun 2002
          00:53:25 GMT
X-Originating-IP: [211.99.77.6]
Mime-Version: 1.0
Content-Type: text/html
X-OriginalArrivalTime: 25 Jun 2002 00:53:26.0024 (UTC)
                       FILETIME=[B69F3080:01C21BE2]
Message-ID:  
Date:         Tue, 25 Jun 2002 06:23:25 +0530
Reply-To: Mailing List 
Sender: Mailing List 
From: mohit gurnani 
Subject: Re: Database Over Flow Doubt
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list






Hi Amit,


    The external LSAs are originated by scanning through external (non-OSPF) routes and applying filtering policies to filter out routes which cannot be imported. All the routes that pass policies are imported in form of external LSAs.


    Now when the system goes into overflow, the non-default self-originated LSAs are flushed and subsequently deleted from the database. You are right when you say it is a bad idea to maintain the log. It will defeat the whole purpose of Overflow implementation which aims at clearing up memory.What is advisable instead to delete all LSAs once acknowledged, and when the Overflow Exit Timer expires, scan through all the external routes once again, apply policy rules and re-import routes that pass policy.


 


Regards


Mohit





>From: Amit Srivastava

>Reply-To: Mailing List

>To: OSPF@DISCUSS.MICROSOFT.COM

>Subject: Database Over Flow Doubt

>Date: Sun, 23 Jun 2002 23:02:19 -0700

>

>Hi Vishwas!!

> I have one more doubt the RFC 1765 say in example

>(section 3) that when the OSPF timer expires then it

>tries to come out of the database overflow state and

>originates all the 400 non default AS-Exteranl LSA.Is

>it that before flushing the LSA it keeps the LSA in a

>linklist form and after the timer expires it

>originates the LSA again!!If this is the case then i

>have small doubt :-

> We have flushed the link state database

>because we think that we cannot accomodate any other

>LSA.Now keeping the log of all the flushed LSA would

>not be a good idea what i feel!!!

>What do u say??

>Regards

>Amit

>

>--- "Manral, Vishwas" wrote:

> > Amit,

> >

> > When the administrator finds that a domain is

> > getting "Overflows" he has to

> > change the policies so that the number of routes

> > imported into the domain is

> > reduced. The routes to be imported are all an

> > administrative

> > decision/policies and the OSPF packets etc do not

> > come into picture at all.

> >

> > The RFC in this point talks about importing routes

> > from other domains and

> > not about received LSA's from other routers in the

> > domain.

> >

> > Thanks,

> > Vishwas

> >

> > -----Original Message-----

> > From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]

> > Sent: Friday, June 21, 2002 4:35 PM

> > To: OSPF@DISCUSS.MICROSOFT.COM

> > Subject: Re: OSPF Retransmission Doubt

> >

> >

> > Hi Vishwas!!

> > The RFC 1765 section 4 last point states that

> > if

> > the administrator cannot incresase the value of

> > ospfExtlsdbLimit then he can make sure that more

> > important routes continue to be imported ; this is

> > accomplished by turning off the importing of less

> > important routes.

> > Now my doubt is ->is it that the administrator

> > configures paticular n/w coming in the AS-external

> > packet as important or unimportant or does it mean

> > that routes learned by a paticular router-id are

> > important and will stay in the database while all

> > the

> > others will be flushed or is it implementation

> > specific!!!

> > Regards

> > Amit

> >

> >

> >

> >

> > --- "Manral, Vishwas" wrote:

> > > Hi Amit,

> > >

> > > The case would not occur if all the routers would

> > > have the same value of

> > > ExtLSDBLimit except in the transient condition.

> > > Section 2.2 first part would

> > > only occur if the value is not the same this may

> > be

> > > required. Its always

> > > better to check the condition, if we are exceeding

> > > the limit and accordingly

> > > take action to get over any such a case.

> > >

> > > Section 2.3 states that the flooding modification

> > > would only be invoked

> > > during a "short period of convergence" for same

> > > value of LSDBLimit. Such a

> > > case would only occur say when two routers are

> > > symultaneously originating

> > > AS-External LSA's. So when they are originating

> > the

> > > LSA's the LSDB limit is

> > > not exceeded however when they are receiving the

> > > LSA's from the other the

> > > LSDB limit is exceeded. However as the RFC states

> > > this would be a transient

> > > condition.

> > >

> > > Thanks,

> > > Vishwas

> > >

> > > -----Original Message-----

> > > From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]

> > > Sent: Thursday, June 20, 2002 10:24 AM

> > > To: OSPF@DISCUSS.MICROSOFT.COM

> > > Subject: Re: OSPF Retransmission Doubt

> > >

> > >

> > > Hi Vishwas,

> > > I have a small doubt .If u refer to section 2.2

> > > and

> > > 2.3 of RFC 1765 it states that during flooding

> > also

> > > the variable count of non-default AS_external LSA

> > is

> > > incremented( if we receive a non-default

> > AS-external

> > > LSA during flooding).But if we have a common

> > thresh

> > > hold limit i.e variable ospfExtlsdbLimit is same

> > for

> > > all the router how come this condition will be

> > > encountered???

> > > Regards

> > > Amit

> > >

> > >

> > >

> > >

> > > --- "Manral, Vishwas"

> > wrote:

> > > > Hi Amit,

> > > >

> > > > I do not think any RFC which talks about

> > > non-default

> > > > type-3 LSA's exists.

> > > > The RFC1765 only talks about type-5 LSA's

> > however

> > > it

> > > > could be extended for

> > > > other type of LSA's i.e. type-7, type-11.

> > > >

> > > > Thanks,

> > > > Vishwas

> > > >

> > > > -----Original Message-----

> > > > From: Amit Srivastava

> > [mailto:ospfisfun@YAHOO.COM]

> > > > Sent: Wednesday, June 19, 2002 11:43 AM

> > > > To: OSPF@DISCUSS.MICROSOFT.COM

> > > > Subject: Re: OSPF Retransmission Doubt

> > > >

> > > >

> > > >

> > > > Hi Erblich and Vishwas,

> > > > Erblich I got your point but is there any

> > > > Draft or RFC which

> > > > states

> > > > this??

> > > > And Vishwas thanks for your help i would

> > also

> > > > like to know if

> > > > there is any draft which states that we can

> > > withdraw

> > > > Summary 3 and 4

> > > > non-default LSA.Because The RFC 2370 specks very

> > > > little about it.

> > > > Regards

> > > > Amit

> > > >

> > > >

> > > >

> > > > Amit Srivastava wrote:

> > > >

> > > >

> > > > Hi Vishwas!

> > > >

> > > >

> > > > Actually after reading the RFC 1765

> > only

> > > i

> > > > got this doubt.Here i

> > > > feel once the OSPFEXTLSDBLinit variable is

> > > exceeded

> > > > the router should

> > > > indicate other routers that its database is full

> > > and

> > > > they should not keep on

> > > > retransmitting the LSA which will clog the n/w

> > > > bandwidth.Once the router

> > > > comes out of the database overflow state it

> > should

> > > > indicate to the other

> > > > router that now they should send the LSA.

> > > >

> > > >

> > > > What do you say about this??

> > > >

> > > >

> > > > Regards

> > > >

> > > >

> > > > Amit

> > > >

> > > > "Manral, Vishwas"

> > wrote:

> > > >

> > > >

> > > > Hi Amit,

> > > >

> > > > You may like to look at the RFC1765 - OSPF

> > > Database

> > > > Overflow.

> > > > http://www.ietf.org/rfc/rfc1765.txt This RFC

> > tells

> > > a

> > > > way to deal with such

> > > > overflow when it occurs in OSPF.

> > > >

> > > > Also as the RFC lists as enhancements, if the

> > > number

> > > > of summary LSA's

> >

>=== message truncated ===

>

>

>__________________________________________________

>Do You Yahoo!?

>Yahoo! - Official partner of 2002 FIFA World Cup

>http://fifaworldcup.yahoo.com


Get your FREE download of MSN Explorer at http://explorer.msn.com.



From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Jun 25 00:00:24 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12475
	for ; Tue, 25 Jun 2002 00:00:23 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00666D05@cherry.ease.lsoft.com>; Tue, 25 Jun 2002 0:01:03 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46214 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 25 Jun 2002 00:01:03 -0400
Received: from 66.163.169.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Tue, 25 Jun 2002 00:01:02 -0400
Received: from [203.200.20.226] by web21507.mail.yahoo.com via HTTP; Mon, 24
          Jun 2002 21:01:02 PDT
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <20020625040102.37780.qmail@web21507.mail.yahoo.com>
Date:         Mon, 24 Jun 2002 21:01:02 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Amit Srivastava 
Subject: Re: Database Over Flow Doubt
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  
Precedence: list

Hi Vishwas ,
        That is my point how can u store all the
LSA(400 in the example of RFC) when we are flushing
the LSA's from the database just bcoz we think that
there is no space for the other LSA's.
         The purpose of writing the RFC here itself is
being hamperred if we store the flushed alway LSA
again the same memory problem will persist!!
Hope i made my self clear!!
Regards
Amit
--- "Manral, Vishwas"  wrote:
> Amit,
>
> You can do it either way, as long as you are somehow
> able to get back the
> LSA's that you wanted to originate and that you
> could not originate, when
> you come out of overflow state.
>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
> Sent: Monday, June 24, 2002 11:32 AM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Database Over Flow Doubt
>
>
> Hi Vishwas!!
>   I have one more doubt the RFC 1765 say in example
> (section 3) that when the OSPF timer expires then it
> tries to come out of the database overflow state and
> originates all the 400 non default AS-Exteranl
> LSA.Is
> it that before flushing the LSA it keeps the LSA in
> a
> linklist form and after the timer expires it
> originates the LSA again!!If this is the case then i
> have small doubt :-
>              We have flushed the link state database
> because we think that we cannot accomodate any other
> LSA.Now keeping the log of all the flushed LSA would
> not be a good idea what i feel!!!
> What do u say??
> Regards
> Amit
>
> --- "Manral, Vishwas"  wrote:
> > Amit,
> >
> > When the administrator finds that a domain is
> > getting "Overflows" he has to
> > change the policies so that the number of routes
> > imported into the domain is
> > reduced. The routes to be imported are all an
> > administrative
> > decision/policies and the OSPF packets etc do not
> > come into picture at all.
> >
> > The RFC in this point talks about importing routes
> > from other domains and
> > not about received LSA's from other routers in the
> > domain.
> >
> > Thanks,
> > Vishwas
> >
> > -----Original Message-----
> > From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
> > Sent: Friday, June 21, 2002 4:35 PM
> > To: OSPF@DISCUSS.MICROSOFT.COM
> > Subject: Re: OSPF Retransmission Doubt
> >
> >
> >  Hi Vishwas!!
> >       The RFC 1765 section 4 last point states
> that
> > if
> > the administrator cannot incresase the value of
> > ospfExtlsdbLimit then he can make sure that more
> > important routes continue to be imported ; this is
> > accomplished by turning off the importing of less
> > important routes.
> >       Now my doubt is ->is it that the
> administrator
> > configures paticular n/w coming in the AS-external
> > packet as important or unimportant or does it mean
> > that routes learned by a paticular router-id are
> > important and will stay in the database while all
> > the
> > others will be flushed or is it implementation
> > specific!!!
> > Regards
> > Amit
> >
> >
> >
> >
> > --- "Manral, Vishwas" 
> wrote:
> > > Hi Amit,
> > >
> > > The case would not occur if all the routers
> would
> > > have the same value of
> > > ExtLSDBLimit except in the transient condition.
> > > Section 2.2 first part would
> > > only occur if the value is not the same this may
> > be
> > > required. Its always
> > > better to check the condition, if we are
> exceeding
> > > the limit and accordingly
> > > take action to get over any such a case.
> > >
> > > Section 2.3 states that the flooding
> modification
> > > would only be invoked
> > > during a "short period of convergence" for same
> > > value of LSDBLimit. Such a
> > > case would only occur say when two routers are
> > > symultaneously originating
> > > AS-External LSA's. So when they are originating
> > the
> > > LSA's the LSDB limit is
> > > not exceeded however when they are receiving the
> > > LSA's from the other the
> > > LSDB limit is exceeded. However as the RFC
> states
> > > this would be a transient
> > > condition.
> > >
> > > Thanks,
> > > Vishwas
> > >
> > > -----Original Message-----
> > > From: Amit Srivastava
> [mailto:ospfisfun@YAHOO.COM]
> > > Sent: Thursday, June 20, 2002 10:24 AM
> > > To: OSPF@DISCUSS.MICROSOFT.COM
> > > Subject: Re: OSPF Retransmission Doubt
> > >
> > >
> > > Hi Vishwas,
> > >    I have a small doubt .If u refer to section
> 2.2
> > > and
> > > 2.3 of RFC 1765 it states that during flooding
> > also
> > > the variable count of non-default AS_external
> LSA
> > is
> > > incremented( if we receive a non-default
> > AS-external
> > > LSA during flooding).But if we have a common
> > thresh
> > > hold limit i.e variable ospfExtlsdbLimit is same
> > for
> > > all the router how come this condition will be
> > > encountered???
> > > Regards
> > > Amit
> > >
> > >
> > >
> > >
> > > --- "Manral, Vishwas" 
> > wrote:
> > > > Hi Amit,
> > > >
> > > > I do not think any RFC which talks about
> > > non-default
> > > > type-3 LSA's exists.
> > > > The RFC1765 only talks about type-5 LSA's
> > however
> > > it
> > > > could be extended for
> > > > other type of LSA's i.e. type-7, type-11.
> > > >
> > > > Thanks,
> > > > Vishwas
> > > >
> > > > -----Original Message-----
> > > > From: Amit Srivastava
> > [mailto:ospfisfun@YAHOO.COM]
> > > > Sent: Wednesday, June 19, 2002 11:43 AM
> > > > To: OSPF@DISCUSS.MICROSOFT.COM
> > > > Subject: Re: OSPF Retransmission Doubt
> > > >
> > > >
> > > >
> > > >  Hi Erblich and Vishwas,
> > > >       Erblich I got your point but is there
> any
> > > > Draft or RFC which
> > > > states
> > > > this??
> > > >      And Vishwas thanks for your help i would
> > also
> > > > like to know if
> > > > there is any draft which states that we can
> > > withdraw
> > > > Summary 3 and 4
> > > > non-default LSA.Because The RFC 2370 specks
> very
> > > > little about it.
> > > > Regards
> > > > Amit
> > > >
> > > >
> > > >
>
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Jun 25 00:46:55 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13412
	for ; Tue, 25 Jun 2002 00:46:55 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00666E54@cherry.ease.lsoft.com>; Tue, 25 Jun 2002 0:47:35 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46346 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 25 Jun 2002 00:47:34 -0400
Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Tue, 25 Jun 2002 00:47:34 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id ; Tue, 25 Jun 2002 00:43:01 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  
Date:         Tue, 25 Jun 2002 00:50:06 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: "Manral, Vishwas" 
Subject: Re: Database Over Flow Doubt
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi Amit,

Yes, you made urself clear the first time around. However as I said its the
way you want to implement things. The RFC helps in preventing LSA's more
than Overflow from being injected in the domain however the way you manage
the internals of your OSPF instance is at your discretion.

Say you can store 500 LSA's or 400 LSA's + 100 External Information elements
in the router. You could set the DBOVerflow value to 400, and store any
additional External Information elements. However if the number of info
elements comes close to 100 you could set the DBoverflow timer to value
0(never come out of overload state), flush all originated LSA's and remove
all the information elements. The idea here is that we can allow at the most
400 LSA's in the domain however we have enough memory to originate 100 more
LSA's. This is just an example of how you could do things.

You can do internal things anyway you want, as long as you can achieve the
objectives of the RFC using the mechanisms in the RFC.

Thanks,
Vishwas

-----Original Message-----
From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
Sent: Tuesday, June 25, 2002 9:31 AM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: Database Over Flow Doubt


Hi Vishwas ,
        That is my point how can u store all the
LSA(400 in the example of RFC) when we are flushing
the LSA's from the database just bcoz we think that
there is no space for the other LSA's.
         The purpose of writing the RFC here itself is
being hamperred if we store the flushed alway LSA
again the same memory problem will persist!!
Hope i made my self clear!!
Regards
Amit
--- "Manral, Vishwas"  wrote:
> Amit,
>
> You can do it either way, as long as you are somehow
> able to get back the
> LSA's that you wanted to originate and that you
> could not originate, when
> you come out of overflow state.
>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
> Sent: Monday, June 24, 2002 11:32 AM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Database Over Flow Doubt
>
>
> Hi Vishwas!!
>   I have one more doubt the RFC 1765 say in example
> (section 3) that when the OSPF timer expires then it
> tries to come out of the database overflow state and
> originates all the 400 non default AS-Exteranl
> LSA.Is
> it that before flushing the LSA it keeps the LSA in
> a
> linklist form and after the timer expires it
> originates the LSA again!!If this is the case then i
> have small doubt :-
>              We have flushed the link state database
> because we think that we cannot accomodate any other
> LSA.Now keeping the log of all the flushed LSA would
> not be a good idea what i feel!!!
> What do u say??
> Regards
> Amit
>
> --- "Manral, Vishwas"  wrote:
> > Amit,
> >
> > When the administrator finds that a domain is
> > getting "Overflows" he has to
> > change the policies so that the number of routes
> > imported into the domain is
> > reduced. The routes to be imported are all an
> > administrative
> > decision/policies and the OSPF packets etc do not
> > come into picture at all.
> >
> > The RFC in this point talks about importing routes
> > from other domains and
> > not about received LSA's from other routers in the
> > domain.
> >
> > Thanks,
> > Vishwas
> >
> > -----Original Message-----
> > From: Amit Srivastava [mailto:ospfisfun@YAHOO.COM]
> > Sent: Friday, June 21, 2002 4:35 PM
> > To: OSPF@DISCUSS.MICROSOFT.COM
> > Subject: Re: OSPF Retransmission Doubt
> >
> >
> >  Hi Vishwas!!
> >       The RFC 1765 section 4 last point states
> that
> > if
> > the administrator cannot incresase the value of
> > ospfExtlsdbLimit then he can make sure that more
> > important routes continue to be imported ; this is
> > accomplished by turning off the importing of less
> > important routes.
> >       Now my doubt is ->is it that the
> administrator
> > configures paticular n/w coming in the AS-external
> > packet as important or unimportant or does it mean
> > that routes learned by a paticular router-id are
> > important and will stay in the database while all
> > the
> > others will be flushed or is it implementation
> > specific!!!
> > Regards
> > Amit
> >
> >
> >
> >
> > --- "Manral, Vishwas" 
> wrote:
> > > Hi Amit,
> > >
> > > The case would not occur if all the routers
> would
> > > have the same value of
> > > ExtLSDBLimit except in the transient condition.
> > > Section 2.2 first part would
> > > only occur if the value is not the same this may
> > be
> > > required. Its always
> > > better to check the condition, if we are
> exceeding
> > > the limit and accordingly
> > > take action to get over any such a case.
> > >
> > > Section 2.3 states that the flooding
> modification
> > > would only be invoked
> > > during a "short period of convergence" for same
> > > value of LSDBLimit. Such a
> > > case would only occur say when two routers are
> > > symultaneously originating
> > > AS-External LSA's. So when they are originating
> > the
> > > LSA's the LSDB limit is
> > > not exceeded however when they are receiving the
> > > LSA's from the other the
> > > LSDB limit is exceeded. However as the RFC
> states
> > > this would be a transient
> > > condition.
> > >
> > > Thanks,
> > > Vishwas
> > >
> > > -----Original Message-----
> > > From: Amit Srivastava
> [mailto:ospfisfun@YAHOO.COM]
> > > Sent: Thursday, June 20, 2002 10:24 AM
> > > To: OSPF@DISCUSS.MICROSOFT.COM
> > > Subject: Re: OSPF Retransmission Doubt
> > >
> > >
> > > Hi Vishwas,
> > >    I have a small doubt .If u refer to section
> 2.2
> > > and
> > > 2.3 of RFC 1765 it states that during flooding
> > also
> > > the variable count of non-default AS_external
> LSA
> > is
> > > incremented( if we receive a non-default
> > AS-external
> > > LSA during flooding).But if we have a common
> > thresh
> > > hold limit i.e variable ospfExtlsdbLimit is same
> > for
> > > all the router how come this condition will be
> > > encountered???
> > > Regards
> > > Amit
> > >
> > >
> > >
> > >
> > > --- "Manral, Vishwas" 
> > wrote:
> > > > Hi Amit,
> > > >
> > > > I do not think any RFC which talks about
> > > non-default
> > > > type-3 LSA's exists.
> > > > The RFC1765 only talks about type-5 LSA's
> > however
> > > it
> > > > could be extended for
> > > > other type of LSA's i.e. type-7, type-11.
> > > >
> > > > Thanks,
> > > > Vishwas
> > > >
> > > > -----Original Message-----
> > > > From: Amit Srivastava
> > [mailto:ospfisfun@YAHOO.COM]
> > > > Sent: Wednesday, June 19, 2002 11:43 AM
> > > > To: OSPF@DISCUSS.MICROSOFT.COM
> > > > Subject: Re: OSPF Retransmission Doubt
> > > >
> > > >
> > > >
> > > >  Hi Erblich and Vishwas,
> > > >       Erblich I got your point but is there
> any
> > > > Draft or RFC which
> > > > states
> > > > this??
> > > >      And Vishwas thanks for your help i would
> > also
> > > > like to know if
> > > > there is any draft which states that we can
> > > withdraw
> > > > Summary 3 and 4
> > > > non-default LSA.Because The RFC 2370 specks
> very
> > > > little about it.
> > > > Regards
> > > > Amit


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Jun 25 01:04:55 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13780
	for ; Tue, 25 Jun 2002 01:04:55 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00667021@cherry.ease.lsoft.com>; Tue, 25 Jun 2002 1:05:36 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46384 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 25 Jun 2002 01:05:35 -0400
Received: from 66.163.169.14 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Tue, 25 Jun 2002 01:05:35 -0400
Received: from [203.200.20.226] by web21503.mail.yahoo.com via HTTP; Mon, 24
          Jun 2002 22:05:35 PDT
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <20020625050535.13526.qmail@web21503.mail.yahoo.com>
Date:         Mon, 24 Jun 2002 22:05:35 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Amit Srivastava 
Subject: Re: Database Over Flow Doubt
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <3D174799.18EE09D0@earthlink.net>
Precedence: list

Hi Erblich,
     Ya i am concern about the amount of memory
consumed in the log!! The pupose of flushing the LSA
is to make space for the other LSA (flushing is done
basically to have memory available for the other LSA
if you have log for 400 LSA then again you are in same
trouble of less memory so what is the use??)
What do you say!!
Regards
Amit
--- Erblichs  wrote:
> Amit,
>
>         Why don't you think a log of flushed LSAs
>         is a good idea?
>
>         - Are you concerned with the amount of
> memory
>         consumed with the log?
>
>         - Are you concerned that the log has a
> certain
>         time frame that is valid and as time
> progresses
>         the information becomes useless?
>
>         - Are you concerned what you are going to do
> with
>         the log after you create it?
>
>         - Etc...
>
>         Mitchell Erblich
>         ================
>
>
>
> Amit Srivastava wrote:
> >
> > Hi Vishwas!!
> >   I have one more doubt the RFC 1765 say in
> example
> > (section 3) that when the OSPF timer expires then
> it
> > tries to come out of the database overflow state
> and
> > originates all the 400 non default AS-Exteranl
> LSA.Is
> > it that before flushing the LSA it keeps the LSA
> in a
> > linklist form and after the timer expires it
> > originates the LSA again!!If this is the case then
> i
> > have small doubt :-
> >              We have flushed the link state
> database
> > because we think that we cannot accomodate any
> other
> > LSA.Now keeping the log of all the flushed LSA
> would
> > not be a good idea what i feel!!!
> > What do u say??
> > Regards
> > Amit
> >
> > --- "Manral, Vishwas" 
> wrote:
> > > Amit,
> > >
> > > When the administrator finds that a domain is
> > > getting "Overflows" he has to
> > > change the policies so that the number of routes
> > > imported into the domain is
> > > reduced. The routes to be imported are all an
> > > administrative
> > > decision/policies and the OSPF packets etc do
> not
> > > come into picture at all.
> > >
> > > The RFC in this point talks about importing
> routes
> > > from other domains and
> > > not about received LSA's from other routers in
> the
> > > domain.
> > >
> > > Thanks,
> > > Vishwas
> > >
> > > -----Original Message-----
> > > From: Amit Srivastava
> [mailto:ospfisfun@YAHOO.COM]
> > > Sent: Friday, June 21, 2002 4:35 PM
> > > To: OSPF@DISCUSS.MICROSOFT.COM
> > > Subject: Re: OSPF Retransmission Doubt
> > >
> > >
> > >  Hi Vishwas!!
> > >       The RFC 1765 section 4 last point states
> that
> > > if
> > > the administrator cannot incresase the value of
> > > ospfExtlsdbLimit then he can make sure that more
> > > important routes continue to be imported ; this
> is
> > > accomplished by turning off the importing of
> less
> > > important routes.
> > >       Now my doubt is ->is it that the
> administrator
> > > configures paticular n/w coming in the
> AS-external
> > > packet as important or unimportant or does it
> mean
> > > that routes learned by a paticular router-id are
> > > important and will stay in the database while
> all
> > > the
> > > others will be flushed or is it implementation
> > > specific!!!
> > > Regards
> > > Amit
> > >
> > >
> > >
> > >
> > > --- "Manral, Vishwas" 
> wrote:
> > > > Hi Amit,
> > > >
> > > > The case would not occur if all the routers
> would
> > > > have the same value of
> > > > ExtLSDBLimit except in the transient
> condition.
> > > > Section 2.2 first part would
> > > > only occur if the value is not the same this
> may
> > > be
> > > > required. Its always
> > > > better to check the condition, if we are
> exceeding
> > > > the limit and accordingly
> > > > take action to get over any such a case.
> > > >
> > > > Section 2.3 states that the flooding
> modification
> > > > would only be invoked
> > > > during a "short period of convergence" for
> same
> > > > value of LSDBLimit. Such a
> > > > case would only occur say when two routers are
> > > > symultaneously originating
> > > > AS-External LSA's. So when they are
> originating
> > > the
> > > > LSA's the LSDB limit is
> > > > not exceeded however when they are receiving
> the
> > > > LSA's from the other the
> > > > LSDB limit is exceeded. However as the RFC
> states
> > > > this would be a transient
> > > > condition.
> > > >
> > > > Thanks,
> > > > Vishwas
> > > >
> > > > -----Original Message-----
> > > > From: Amit Srivastava
> [mailto:ospfisfun@YAHOO.COM]
> > > > Sent: Thursday, June 20, 2002 10:24 AM
> > > > To: OSPF@DISCUSS.MICROSOFT.COM
> > > > Subject: Re: OSPF Retransmission Doubt
> > > >
> > > >
> > > > Hi Vishwas,
> > > >    I have a small doubt .If u refer to section
> 2.2
> > > > and
> > > > 2.3 of RFC 1765 it states that during flooding
> > > also
> > > > the variable count of non-default AS_external
> LSA
> > > is
> > > > incremented( if we receive a non-default
> > > AS-external
> > > > LSA during flooding).But if we have a common
> > > thresh
> > > > hold limit i.e variable ospfExtlsdbLimit is
> same
> > > for
> > > > all the router how come this condition will be
> > > > encountered???
> > > > Regards
> > > > Amit
> > > >
> > > >
> > > >
> > > >
> > > > --- "Manral, Vishwas" 
> > > wrote:
> > > > > Hi Amit,
> > > > >
> > > > > I do not think any RFC which talks about
> > > > non-default
> > > > > type-3 LSA's exists.
> > > > > The RFC1765 only talks about type-5 LSA's
> > > however
> > > > it
> > > > > could be extended for
> > > > > other type of LSA's i.e. type-7, type-11.
>
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Jun 25 01:09:03 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13854
	for ; Tue, 25 Jun 2002 01:09:03 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00667026@cherry.ease.lsoft.com>; Tue, 25 Jun 2002 1:09:44 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 46420 for OSPF@DISCUSS.MICROSOFT.COM;
          Tue, 25 Jun 2002 01:09:44 -0400
Received: from 66.163.169.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Tue, 25 Jun 2002 01:09:43 -0400
Received: from [203.200.20.226] by web21508.mail.yahoo.com via HTTP; Mon, 24
          Jun 2002 22:09:42 PDT
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <20020625050942.45873.qmail@web21508.mail.yahoo.com>
Date:         Mon, 24 Jun 2002 22:09:42 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Amit Srivastava 
Subject: Re: Database Over Flow Doubt
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  
Precedence: list

Hi Mohit!!
     could you please explain your answer (i mean the
last two lines).Sorry i could not get you!!
Regards
Amit
--- mohit gurnani  wrote:








Hi Amit,


    The external LSAs are originated
by scanning through external (non-OSPF) routes and
applying filtering policies to filter out routes which
cannot be imported. All the routes that pass policies
are imported in form of external LSAs.


    Now when the system goes into
overflow, the non-default self-originated LSAs are
flushed and subsequently deleted from the database.
You are right when you say it is a bad idea to
maintain the log. It will defeat the whole purpose of
Overflow implementation which aims at clearing up
memory.What is advisable instead to delete all LSAs
once acknowledged, and when the Overflow Exit Timer
expires, scan through all the external routes once
again, apply policy rules and re-import routes that
pass policy.


 


Regards


Mohit





>From: Amit
Srivastava

>Reply-To: Mailing
List

>To: OSPF@DISCUSS.MICROSOFT.COM

>Subject: Database Over Flow Doubt

>Date: Sun, 23 Jun 2002 23:02:19 -0700

>

>Hi Vishwas!!

> I have one more doubt the RFC 1765 say
in example

>(section 3) that when the OSPF timer
expires then it

>tries to come out of the database
overflow state and

>originates all the 400 non default
AS-Exteranl LSA.Is

>it that before flushing the LSA it
keeps the LSA in a

>linklist form and after the timer
expires it

>originates the LSA again!!If this is
the case then i

>have small doubt :-

> We have flushed the link state
database

>because we think that we cannot
accomodate any other

>LSA.Now keeping the log of all the
flushed LSA would

>not be a good idea what i feel!!!

>What do u say??

>Regards

>Amit

>

>--- "Manral,
Vishwas" wrote:

> > Amit,

> >

> > When the administrator finds that
a domain is

> > getting "Overflows" he
has to

> > change the policies so that the
number of routes

> > imported into the domain is

> > reduced. The routes to be
imported are all an

> > administrative

> > decision/policies and the OSPF
packets etc do not

> > come into picture at all.

> >

> > The RFC in this point talks about
importing routes

> > from other domains and

> > not about received LSA's from
other routers in the

> > domain.

> >

> > Thanks,

> > Vishwas

> >

> > -----Original Message-----

> > From: Amit Srivastava
[mailto:ospfisfun@YAHOO.COM]

> > Sent: Friday, June 21, 2002 4:35
PM

> > To: OSPF@DISCUSS.MICROSOFT.COM

> > Subject: Re: OSPF Retransmission
Doubt

> >

> >

> > Hi Vishwas!!

> > The RFC 1765 section 4 last point
states that

> > if

> > the administrator cannot
incresase the value of

> > ospfExtlsdbLimit then he can make
sure that more

> > important routes continue to be
imported ; this is

> > accomplished by turning off the
importing of less

> > important routes.

> > Now my doubt is ->is it that
the administrator

> > configures paticular n/w coming
in the AS-external

> > packet as important or
unimportant or does it mean

> > that routes learned by a
paticular router-id are

> > important and will stay in the
database while all

> > the

> > others will be flushed or is it
implementation

> > specific!!!

> > Regards

> > Amit

> >

> >

> >

> >

> > --- "Manral,
Vishwas" wrote:

> > > Hi Amit,

> > >

> > > The case would not occur if
all the routers would

> > > have the same value of

> > > ExtLSDBLimit except in the
transient condition.

> > > Section 2.2 first part would

> > > only occur if the value is
not the same this may

> > be

> > > required. Its always

> > > better to check the
condition, if we are exceeding

> > > the limit and accordingly

> > > take action to get over any
such a case.

> > >

> > > Section 2.3 states that the
flooding modification

> > > would only be invoked

> > > during a "short period
of convergence" for same

> > > value of LSDBLimit. Such a

> > > case would only occur say
when two routers are

> > > symultaneously originating

> > > AS-External LSA's. So when
they are originating

> > the

> > > LSA's the LSDB limit is

> > > not exceeded however when
they are receiving the

> > > LSA's from the other the

> > > LSDB limit is exceeded.
However as the RFC states

> > > this would be a transient

> > > condition.

> > >

> > > Thanks,

> > > Vishwas

> > >

> > > -----Original Message-----

> > > From: Amit Srivastava
[mailto:ospfisfun@YAHOO.COM]

> > > Sent: Thursday, June 20,
2002 10:24 AM

> > > To:
OSPF@DISCUSS.MICROSOFT.COM

> > > Subject: Re: OSPF
Retransmission Doubt

> > >

> > >

> > > Hi Vishwas,

> > > I have a small doubt .If u
refer to section 2.2

> > > and

> > > 2.3 of RFC 1765 it states
that during flooding

> > also

> > > the variable count of
non-default AS_external LSA

> > is

> > > incremented( if we receive a
non-default

> > AS-external

> > > LSA during flooding).But if
we have a common

> > thresh

> > > hold limit i.e variable
ospfExtlsdbLimit is same

> > for

> > > all the router how come this
condition will be

> > > encountered???

> > > Regards

> > > Amit

> > >

> > >

> > >

> > >

> > > --- "Manral,
Vishwas"

> > wrote:

> > > > Hi Amit,

> > > >

> > > > I do not think any RFC
which talks about

> > > non-default

> > > > type-3 LSA's exists.

> > > > The RFC1765 only talks
about type-5 LSA's

> > however

> > > it

> > > > could be extended for

> > > > other type of LSA's
i.e. type-7, type-11.

> > > >

> > > > Thanks,

> > > > Vishwas

> > > >

> > > > -----Original
Message-----

> > > > From: Amit Srivastava

> > [mailto:ospfisfun@YAHOO.COM]

> > > > Sent: Wednesday, June
19, 2002 11:43 AM

> > > > To:
OSPF@DISCUSS.MICROSOFT.COM

> > > > Subject: Re: OSPF
Retransmission Doubt

> > > >

> > > >

> > > >

> > > > Hi Erblich and Vishwas,

> > > > Erblich I got your
point but is there any

> > > > Draft or RFC which

> > > > states

> > > > this??

> > > > And Vishwas thanks for
your help i would

> > also

> > > > like to know if

> > > > there is any draft
which states that we can

> > > withdraw

> > > > Summary 3 and 4

> > > > non-default LSA.Because
The RFC 2370 specks very

> > > > little about it.

> > > > Regards

> > > > Amit

> > > >

> > > >

> > > >

> > > > Amit
Srivastava wrote:

> > > >

> > > >

> > > > Hi Vishwas!

> > > >

> > > >

> > > > Actually after reading
the RFC 1765

> > only

> > > i

> > > > got this doubt.Here i

> > > > feel once the
OSPFEXTLSDBLinit variable is

> > > exceeded

> > > > the router should

> > > > indicate other routers
that its database is full

> > > and

> > > > they should not keep on

> > > > retransmitting the LSA
which will clog the n/w

> > > > bandwidth.Once the
router

> > > > comes out of the
database overflow state it

> > should

> > > > indicate to the other

> > > > router that now they
should send the LSA.

> > > >

> > > >

> > > > What do you say about
this??

> > > >

> > > >

> > > > Regards

> > > >

> > > >

> > > > Amit

> > > >

> > > > "Manral,
Vishwas"

> > wrote:

> > > >

> > > >

> > > > Hi Amit,

> > > >

> > > > You may like to look at
the RFC1765 - OSPF

> > > Database

> > > > Overflow.

> > > >
http://www.ietf.org/rfc/rfc1765.txt This RFC

> > tells

> > > a

> > > > way to deal with such

> > > > overflow when it occurs
in OSPF.

> > > >

> > > > Also as the RFC lists
as enhancements, if the

> > > number

> > > > of summary LSA's

> >

>=== message truncated ===

>

>

>__________________________________________________

>Do You Yahoo!?

>Yahoo! - Official partner of 2002 FIFA
World Cup

>http://fifaworldcup.yahoo.com


Get your FREE
download of MSN Explorer at http://explorer.msn.com.



__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Jun 25 19:31:19 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03235
	for ; Tue, 25 Jun 2002 19:31:19 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.006688C4@cherry.ease.lsoft.com>; Tue, 25 Jun 2002 19:32:00 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 1495 for OSPF@DISCUSS.MICROSOFT.COM; Tue,
          25 Jun 2002 19:32:00 -0400
Received: from 64.4.37.97 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Tue, 25 Jun 2002 19:32:00 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue,
          25 Jun 2002 16:31:59 -0700
Received: from 65.192.41.10 by pv2fd.pav2.hotmail.msn.com with HTTP; Tue, 25
          Jun 2002 23:31:59 GMT
X-Originating-IP: [65.192.41.10]
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 25 Jun 2002 23:31:59.0929 (UTC)
                       FILETIME=[80B20290:01C21CA0]
Message-ID:  
Date:         Tue, 25 Jun 2002 16:31:59 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: prashant desai 
Subject: DR change.
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

In case of a DR going down, BDR becomming DR and a new network lsa being
originated..
What should other routers in the domain do with the old network lsa ?
It can lie around(age out) in the lsdb or can be purged explicitly ...
Cisco seems to purge it..Is it an implementation issue.

Thanks
Prashant

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Jun 25 20:19:49 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04182
	for ; Tue, 25 Jun 2002 20:19:49 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.006688FF@cherry.ease.lsoft.com>; Tue, 25 Jun 2002 20:20:31 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 1580 for OSPF@DISCUSS.MICROSOFT.COM; Tue,
          25 Jun 2002 20:20:31 -0400
Received: from 135.207.30.102 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Tue, 25 Jun 2002 20:20:30 -0400
Received: from alliance.research.att.com (alliance.research.att.com
          [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP
          id F23104CE11 for ; Tue, 25 Jun 2002
          20:20:30 -0400 (EDT)
Received: from windsor.research.att.com (windsor.research.att.com
          [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with
          ESMTP id UAA16346 for ; Tue, 25 Jun 2002
          20:20:29 -0400 (EDT)
Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5)
          id RAA02756; Tue, 25 Jun 2002 17:20:30 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Versions: dmail (solaris) 2.4c/makemail 2.9d
Message-ID:  <200206260020.RAA02756@windsor.research.att.com>
Date:         Tue, 25 Jun 2002 17:20:30 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Bill Fenner 
Subject: OSPF WG meeting in Yokohama
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Dear OSPF WG,

  Since we're encouraging all working groups to meet in Yokohama, I've
scheduled an OSPF WG meeting, on July 17th at 15:30-17:30.  I can act as
a proxy temporary chair (i.e. creating an agenda, running the meeting,
generating minutes).

  Please send me and John any agenda items you may have.  I'll give
a brief summary of the state of the WG documents that have been submitted
to the IESG.

Thanks,
  Bill


From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Jun 25 21:10:44 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05195
	for ; Tue, 25 Jun 2002 21:10:44 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0066895A@cherry.ease.lsoft.com>; Tue, 25 Jun 2002 21:10:25 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 1672 for OSPF@DISCUSS.MICROSOFT.COM; Tue,
          25 Jun 2002 21:10:24 -0400
Received: from 216.32.181.47 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Tue, 25 Jun 2002 21:10:24 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue,
          25 Jun 2002 18:10:24 -0700
Received: from 211.99.77.6 by lw2fd.hotmail.msn.com with HTTP; Wed, 26 Jun 2002
          01:10:23 GMT
X-Originating-IP: [211.99.77.6]
Mime-Version: 1.0
Content-Type: text/html
X-OriginalArrivalTime: 26 Jun 2002 01:10:24.0117 (UTC)
                       FILETIME=[3FDD9A50:01C21CAE]
Message-ID:  
Date:         Wed, 26 Jun 2002 06:40:23 +0530
Reply-To: Mailing List 
Sender: Mailing List 
From: mohit gurnani 
Subject: Re: Database Over Flow Doubt
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list




Hi Amit,


   What I want to say, in as little words as possibe, is that delete every flushed LSA that is acknowledged and donot maintain a log.


   The router must maintain all the routes (OSPF or otherwise) in some sort of a routing table. This routing table must provide an interface by means of which you can pick routes one by one (maybe some sort of get, get-first, get-next kind of interface). So what you do is pick first route, check if it is an active route (maybe even check if  it is not an OSPF route because a router cannot import its own OSPF routes), check if the router allows you to import it by means of policy filters. Import policies like distribute-out and redistribute  can be configured on the system. eg. if you have only Redistribute BGP configured, you are allowed to import all BGP routes and no other routes. And if the route can be imported, use its fields to construct a new external LSA, update your database and flood the LSA. You do this for all the routes in the routing table once the OverflowExitTimer expires. 


   And it is advisable that you do import of routes in batches (say 500 routes a second) and not all in one go because the process is long and might affect system overall performance.


Regards


Mohit





>From: Amit Srivastava 

>Reply-To: Mailing List 

>To: OSPF@DISCUSS.MICROSOFT.COM

>Subject: Re: Database Over Flow Doubt

>Date: Mon, 24 Jun 2002 22:09:42 -0700

>

>Hi Mohit!!

> could you please explain your answer (i mean the

>last two lines).Sorry i could not get you!!

>Regards

>Amit

>--- mohit gurnani wrote:

>

>




>

>

>

Hi Amit,


>

    The external LSAs are originated

>by scanning through external (non-OSPF) routes and

>applying filtering policies to filter out routes which

>cannot be imported. All the routes that pass policies

>are imported in form of external LSAs.



>

    Now when the system goes into

>overflow, the non-default self-originated LSAs are

>flushed and subsequently deleted from the database.

>You are right when you say it is a bad idea to

>maintain the log. It will defeat the whole purpose of

>Overflow implementation which aims at clearing up

>memory.What is advisable instead to delete all LSAs

>once acknowledged, and when the Overflow Exit Timer

>expires, scan through all the external routes once

>again, apply policy rules and re-import routes that

>pass policy.



>

 


>

Regards


>

Mohit





>



>

>From: Amit

>Srivastava

>

>Reply-To: Mailing

>List

>

>To: OSPF@DISCUSS.MICROSOFT.COM

>

>Subject: Database Over Flow Doubt

>

>Date: Sun, 23 Jun 2002 23:02:19 -0700

>

>

>

>Hi Vishwas!!

>

> I have one more doubt the RFC 1765 say

>in example

>

>(section 3) that when the OSPF timer

>expires then it

>

>tries to come out of the database

>overflow state and

>

>originates all the 400 non default

>AS-Exteranl LSA.Is

>

>it that before flushing the LSA it

>keeps the LSA in a

>

>linklist form and after the timer

>expires it

>

>originates the LSA again!!If this is

>the case then i

>

>have small doubt :-

>

> We have flushed the link state

>database

>

>because we think that we cannot

>accomodate any other

>

>LSA.Now keeping the log of all the

>flushed LSA would

>

>not be a good idea what i feel!!!

>

>What do u say??

>

>Regards

>

>Amit

>

>

>

>--- "Manral,

>Vishwas" wrote:

>

> > Amit,

>

> >

>

> > When the administrator finds that

>a domain is

>

> > getting "Overflows" he

>has to

>

> > change the policies so that the

>number of routes

>

> > imported into the domain is

>

> > reduced. The routes to be

>imported are all an

>

> > administrative

>

> > decision/policies and the OSPF

>packets etc do not

>

> > come into picture at all.

>

> >

>

> > The RFC in this point talks about

>importing routes

>

> > from other domains and

>

> > not about received LSA's from

>other routers in the

>

> > domain.

>

> >

>

> > Thanks,

>

> > Vishwas

>

> >

>

> > -----Original Message-----

>

> > From: Amit Srivastava

>[mailto:ospfisfun@YAHOO.COM]

>

> > Sent: Friday, June 21, 2002 4:35

>PM

>

> > To: OSPF@DISCUSS.MICROSOFT.COM

>

> > Subject: Re: OSPF Retransmission

>Doubt

>

> >

>

> >

>

> > Hi Vishwas!!

>

> > The RFC 1765 section 4 last point

>states that

>

> > if

>

> > the administrator cannot

>incresase the value of

>

> > ospfExtlsdbLimit then he can make

>sure that more

>

> > important routes continue to be

>imported ; this is

>

> > accomplished by turning off the

>importing of less

>

> > important routes.

>

> > Now my doubt is ->is it that

>the administrator

>

> > configures paticular n/w coming

>in the AS-external

>

> > packet as important or

>unimportant or does it mean

>

> > that routes learned by a

>paticular router-id are

>

> > important and will stay in the

>database while all

>

> > the

>

> > others will be flushed or is it

>implementation

>

> > specific!!!

>

> > Regards

>

> > Amit

>

> >

>

> >

>

> >

>

> >

>

> > --- "Manral,

>Vishwas" wrote:

>

> > > Hi Amit,

>

> > >

>

> > > The case would not occur if

>all the routers would

>

> > > have the same value of

>

> > > ExtLSDBLimit except in the

>transient condition.

>

> > > Section 2.2 first part would

>

> > > only occur if the value is

>not the same this may

>

> > be

>

> > > required. Its always

>

> > > better to check the

>condition, if we are exceeding

>

> > > the limit and accordingly

>

> > > take action to get over any

>such a case.

>

> > >

>

> > > Section 2.3 states that the

>flooding modification

>

> > > would only be invoked

>

> > > during a "short period

>of convergence" for same

>

> > > value of LSDBLimit. Such a

>

> > > case would only occur say

>when two routers are

>

> > > symultaneously originating

>

> > > AS-External LSA's. So when

>they are originating

>

> > the

>

> > > LSA's the LSDB limit is

>

> > > not exceeded however when

>they are receiving the

>

> > > LSA's from the other the

>

> > > LSDB limit is exceeded.

>However as the RFC states

>

> > > this would be a transient

>

> > > condition.

>

> > >

>

> > > Thanks,

>

> > > Vishwas

>

> > >

>

> > > -----Original Message-----

>

> > > From: Amit Srivastava

>[mailto:ospfisfun@YAHOO.COM]

>

> > > Sent: Thursday, June 20,

>2002 10:24 AM

>

> > > To:

>OSPF@DISCUSS.MICROSOFT.COM

>

> > > Subject: Re: OSPF

>Retransmission Doubt

>

> > >

>

> > >

>

> > > Hi Vishwas,

>

> > > I have a small doubt .If u

>refer to section 2.2

>

> > > and

>

> > > 2.3 of RFC 1765 it states

>that during flooding

>

> > also

>

> > > the variable count of

>non-default AS_external LSA

>

> > is

>

> > > incremented( if we receive a

>non-default

>

> > AS-external

>

> > > LSA during flooding).But if

>we have a common

>

> > thresh

>

> > > hold limit i.e variable

>ospfExtlsdbLimit is same

>

> > for

>

> > > all the router how come this

>condition will be

>

> > > encountered???

>

> > > Regards

>

> > > Amit

>

> > >

>

> > >

>

> > >

>

> > >

>

> > > --- "Manral,

>Vishwas"

>

> > wrote:

>

> > > > Hi Amit,

>

> > > >

>

> > > > I do not think any RFC

>which talks about

>

> > > non-default

>

> > > > type-3 LSA's exists.

>

> > > > The RFC1765 only talks

>about type-5 LSA's

>

> > however

>

> > > it

>

> > > > could be extended for

>

> > > > other type of LSA's

>i.e. type-7, type-11.

>

> > > >

>

> > > > Thanks,

>

> > > > Vishwas

>

> > > >

>

> > > > -----Original

>Message-----

>

> > > > From: Amit Srivastava

>

> > [mailto:ospfisfun@YAHOO.COM]

>

> > > > Sent: Wednesday, June

>19, 2002 11:43 AM

>

> > > > To:

>OSPF@DISCUSS.MICROSOFT.COM

>

> > > > Subject: Re: OSPF

>Retransmission Doubt

>

> > > >

>

> > > >

>

> > > >

>

> > > > Hi Erblich and Vishwas,

>

> > > > Erblich I got your

>point but is there any

>

> > > > Draft or RFC which

>

> > > > states

>

> > > > this??

>

> > > > And Vishwas thanks for

>your help i would

>

> > also

>

> > > > like to know if

>

> > > > there is any draft

>which states that we can

>

> > > withdraw

>

> > > > Summary 3 and 4

>

> > > > non-default LSA.Because

>The RFC 2370 specks very

>

> > > > little about it.

>

> > > > Regards

>

> > > > Amit

>

> > > >

>

> > > >

>

> > > >

>

> > > > Amit

>Srivastava wrote:

>

> > > >

>

> > > >

>

> > > > Hi Vishwas!

>

> > > >

>

> > > >

>

> > > > Actually after reading

>the RFC 1765

>

> > only

>

> > > i

>

> > > > got this doubt.Here i

>

> > > > feel once the

>OSPFEXTLSDBLinit variable is

>

> > > exceeded

>

> > > > the router should

>

> > > > indicate other routers

>that its database is full

>

> > > and

>

> > > > they should not keep on

>

> > > > retransmitting the LSA

>which will clog the n/w

>

> > > > bandwidth.Once the

>router

>

> > > > comes out of the

>database overflow state it

>

> > should

>

> > > > indicate to the other

>

> > > > router that now they

>should send the LSA.

>

> > > >

>

> > > >

>

> > > > What do you say about

>this??

>

> > > >

>

> > > >

>

> > > > Regards

>

> > > >

>

> > > >

>

> > > > Amit

>

> > > >

>

> > > > "Manral,

>Vishwas"

>

> > wrote:

>

> > > >

>

> > > >

>

> > > > Hi Amit,

>

> > > >

>

> > > > You may like to look at

>the RFC1765 - OSPF

>

> > > Database

>

> > > > Overflow.

>

> > > >

>http://www.ietf.org/rfc/rfc1765.txt This RFC

>

> > tells

>

> > > a

>

> > > > way to deal with such

>

> > > > overflow when it occurs

>in OSPF.

>

> > > >

>

> > > > Also as the RFC lists

>as enhancements, if the

>

> > > number

>

> > > > of summary LSA's

>

> >

>

>=== message truncated ===

>

>

>

>

>

>__________________________________________________

>

>Do You Yahoo!?

>

>Yahoo! - Official partner of 2002 FIFA

>World Cup

>

>http://fifaworldcup.yahoo.com

>







Get your FREE

>download of MSN Explorer at >href='http://g.msn.com/1HM503401/37'>http://explorer.msn.com.


>

>

>__________________________________________________

>Do You Yahoo!?

>Yahoo! - Official partner of 2002 FIFA World Cup

>http://fifaworldcup.yahoo.com


MSN Photos is the easiest way to share and print your photos: Click Here



From owner-ospf@DISCUSS.MICROSOFT.COM  Tue Jun 25 22:50:53 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07678
	for ; Tue, 25 Jun 2002 22:50:53 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00668C1B@cherry.ease.lsoft.com>; Tue, 25 Jun 2002 22:51:35 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 1831 for OSPF@DISCUSS.MICROSOFT.COM; Tue,
          25 Jun 2002 22:51:35 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Tue, 25 Jun 2002 22:51:35 -0400
Received: from redback.com (jagged.redback.com [155.53.36.195]) by
          prattle.redback.com (Postfix) with ESMTP id 0DB0D449A39 for
          ; Tue, 25 Jun 2002 19:51:33 -0700 (PDT)
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.0.38 i386)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D192C34.DBDC2BA7@redback.com>
Date:         Tue, 25 Jun 2002 19:51:32 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Acee Lindem 
Organization: Redback Networks, Inc
Subject: Extended Hitless OSPF Restart
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

FYI - Ultimately, this would be an informational RFC or better yet
folded into the base "OSPF Hitless Restart" specification (although
this has not been discussed as of yet).

Thanks,
Acee

Date: Tue, 25 Jun 2002 07:01:53 -0400
From: Internet-Drafts@ietf.org
To: IETF-Announce:  ;
Subject: I-D ACTION:draft-lindem-ospf-hitless-extended-restart-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.


        Title           : Extended Hitless OSPF Restart
        Author(s)       : A. Lindem, A. Oswal
        Filename        :
draft-lindem-ospf-hitless-extended-restart-00.txt
        Pages           : 3
        Date            : 24-Jun-02

This memo documents an enhancement to OSPF 'hitless restart' whereby
an OSPF router can request that its forwarding state be maintained
longer that the router dead interval on one or more router
interfaces.  This is useful when the OSPF software is being
updated and the router dead interval on one or more interfaces is
configured to a small value.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lindem-ospf-hitless-extended-restart-00.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the
message.

Internet-Drafts are also available by anonymous FTP. Login with the
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-lindem-ospf-hitless-extended-restart-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE
/internet-drafts/draft-lindem-ospf-hitless-extended-restart-00.txt".

NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail
readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Jun 26 02:09:05 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20572
	for ; Wed, 26 Jun 2002 02:09:05 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.006693AA@cherry.ease.lsoft.com>; Wed, 26 Jun 2002 2:09:32 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 2599 for OSPF@DISCUSS.MICROSOFT.COM; Wed,
          26 Jun 2002 02:09:31 -0400
Received: from 66.218.78.84 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 26 Jun 2002 02:09:31 -0400
Received: from [203.200.20.226] by web40305.mail.yahoo.com via HTTP; Tue, 25
          Jun 2002 23:09:31 PDT
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <20020626060931.26238.qmail@web40305.mail.yahoo.com>
Date:         Tue, 25 Jun 2002 23:09:31 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Amit Srivastava 
Subject: Re: Database Over Flow Doubt
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  
Precedence: list

Hi mohit,
  Even this method seems to be prone to
errors.Consider the case:-
          At time 12:40 PM the administartor gave the
command redistribute bgp.This will put all the bgp
routes in the ospf domain.Now due to this the ospf
router goes in to the Overflow state.Now at 1:40 PM it
recovers(when the timer expires)and would try to
originate the LSA .To do so, from programme only he
would call redistribute bgp.
          Now the problem is by this time BGP would
have learned lot more routes which administrator would
not like to flood them to ospf domain!!But as the
redistribute bgp is called from the program this
condition is unavoidable!!
          So i feel making log is better idea!!
What do you say!!
Regards
Amit
--- mohit gurnani  wrote:






Hi Amit,


   What I want to say, in as little words
as possibe, is that delete every flushed LSA that is
acknowledged and donot maintain a log.


   The router must maintain all the
routes (OSPF or otherwise) in some sort of a routing
table. This routing table must provide an interface by
means of which you can pick routes one by one (maybe
some sort of get, get-first, get-next kind of
interface). So what you do is pick first route, check
if it is an active route (maybe even check if  it
is not an OSPF route because a router cannot import
its own OSPF routes), check if the router allows you
to import it by means of policy filters. Import
policies like distribute-out and redistribute 
can be configured on the system. eg. if you have only
Redistribute BGP configured, you are allowed to import
all BGP routes and no other routes. And if the route
can be imported, use its fields to construct a new
external LSA, update your database and flood the LSA.
You do this for all the routes in the routing table
once the OverflowExitTimer expires. 


   And it is advisable that you
do import of routes in batches (say 500
routes a second) and not all in one go because the
process is long and might affect system overall
performance.


Regards


Mohit





>From: Amit Srivastava


>Reply-To: Mailing List


>To: OSPF@DISCUSS.MICROSOFT.COM

>Subject: Re: Database Over Flow Doubt

>Date: Mon, 24 Jun 2002 22:09:42 -0700

>

>Hi Mohit!!

> could you please explain your answer
(i mean the

>last two lines).Sorry i could not get
you!!

>Regards

>Amit

>--- mohit gurnani
wrote:

>

>




>

>

>

Hi Amit,


>

    The external LSAs are originated

>by scanning through external (non-OSPF)
routes and

>applying filtering policies to filter
out routes which

>cannot be imported. All the routes that
pass policies

>are imported in form of external LSAs.



>

    Now when the system goes into

>overflow, the non-default
self-originated LSAs are

>flushed and subsequently deleted from
the database.

>You are right when you say it is a bad
idea to

>maintain the log. It will defeat the
whole purpose of

>Overflow implementation which aims at
clearing up

>memory.What is advisable instead to
delete all LSAs

>once acknowledged, and when the
Overflow Exit Timer

>expires, scan through all the external
routes once

>again, apply policy rules and re-import
routes that

>pass policy.



>

 


>

Regards


>

Mohit





>



>

>From: Amit

>Srivastava

>

>Reply-To: Mailing

>List

>

>To: OSPF@DISCUSS.MICROSOFT.COM

>

>Subject: Database Over Flow Doubt

>

>Date: Sun, 23 Jun 2002 23:02:19 -0700

>

>

>

>Hi Vishwas!!

>

> I have one more doubt the RFC 1765 say

>in example

>

>(section 3) that when the OSPF timer

>expires then it

>

>tries to come out of the database

>overflow state and

>

>originates all the 400 non default

>AS-Exteranl LSA.Is

>

>it that before flushing the LSA it

>keeps the LSA in a

>

>linklist form and after the timer

>expires it

>

>originates the LSA again!!If this is

>the case then i

>

>have small doubt :-

>

> We have flushed the link state

>database

>

>because we think that we cannot

>accomodate any other

>

>LSA.Now keeping the log of all the

>flushed LSA would

>

>not be a good idea what i feel!!!

>

>What do u say??

>

>Regards

>

>Amit

>

>

>

>--- "Manral,

>Vishwas" wrote:

>

> > Amit,

>

> >

>

> > When the administrator finds that

>a domain is

>

> > getting "Overflows" he

>has to

>

> > change the policies so that the

>number of routes

>

> > imported into the domain is

>

> > reduced. The routes to be

>imported are all an

>

> > administrative

>

> > decision/policies and the OSPF

>packets etc do not

>

> > come into picture at all.

>

> >

>

> > The RFC in this point talks about

>importing routes

>

> > from other domains and

>

> > not about received LSA's from

>other routers in the

>

> > domain.

>

> >

>

> > Thanks,

>

> > Vishwas

>

> >

>

> > -----Original Message-----

>

> > From: Amit Srivastava

>[mailto:ospfisfun@YAHOO.COM]

>

> > Sent: Friday, June 21, 2002 4:35

>PM

>

> > To: OSPF@DISCUSS.MICROSOFT.COM

>

> > Subject: Re: OSPF Retransmission

>Doubt

>

> >

>

> >

>

> > Hi Vishwas!!

>

> > The RFC 1765 section 4 last point

>states that

>

> > if

>

> > the administrator cannot

>incresase the value of

>

> > ospfExtlsdbLimit then he can make

>sure that more

>

> > important routes continue to be

>imported ; this is

>

> > accomplished by turning off the

>importing of less

>

> > important routes.

>

> > Now my doubt is ->is it that

>the administrator

>

> > configures paticular n/w coming

>in the AS-external

>

> > packet as important or

>unimportant or does it mean

>

> > that routes learned by a

>paticular router-id are

>

> > important and will stay in the

>database while all

>

> > the

>

> > others will be flushed or is it

>implementation

>

> > specific!!!

>

> > Regards

>

> > Amit

>

> >

>

> >

>

> >

>

> >

>

> > --- "Manral,

>Vishwas" wrote:

>

> > > Hi Amit,

>

> > >

>

> > > The case would not occur if

>all the routers would

>

> > > have the same value of

>

> > > ExtLSDBLimit except in the

>transient condition.

>

> > > Section 2.2 first part would

>

> > > only occur if the value is

>not the same this may

>

> > be

>

> > > required. Its always

>

> > > better to check the

>condition, if we are exceeding

>

> > > the limit and accordingly

>

> > > take action to get over any

>such a case.

>

> > >

>

> > > Section 2.3 states that the

>flooding modification

>

> > > would only be invoked

>

> > > during a "short period

>of convergence" for same

>

> > > value of LSDBLimit. Such a

>

> > > case would only occur say

>when two routers are

>

> > > symultaneously originating

>

> > > AS-External LSA's. So when

>they are originating

>

> > the

>

> > > LSA's the LSDB limit is

>

> > > not exceeded however when

>they are receiving the

>

> > > LSA's from the other the

>

> > > LSDB limit is exceeded.

>However as the RFC states

>

> > > this would be a transient

>

> > > condition.

>

> > >

>

> > > Thanks,

>

> > > Vishwas

>

> > >

>

> > > -----Original Message-----

>

> > > From: Amit Srivastava

>[mailto:ospfisfun@YAHOO.COM]

>

> > > Sent: Thursday, June 20,

>2002 10:24 AM

>

> > > To:

>OSPF@DISCUSS.MICROSOFT.COM

>

> > > Subject: Re: OSPF

>Retransmission Doubt

>

> > >

>

> > >

>

> > > Hi Vishwas,

>

> > > I have a small doubt .If u

>refer to section 2.2

>

> > > and

>

> > > 2.3 of RFC 1765 it states

>that during flooding

>

> > also

>

> > > the variable count of

>non-default AS_external LSA

>

> > is

>

> > > incremented( if we receive a

>non-default

>

> > AS-external

>

> > > LSA during flooding).But if

>we have a common

>

> > thresh

>

> > > hold limit i.e variable

>ospfExtlsdbLimit is same

>

> > for

>

> > > all the router how come this

>condition will be

>

> > > encountered???

>

> > > Regards

>

> > > Amit

>

> > >

>

> > >

>

> > >

>

> > >

>

> > > --- "Manral,

>Vishwas"

>

> > wrote:

>

> > > > Hi Amit,

>

> > > >

>

> > > > I do not think any RFC

>which talks about

>

> > > non-default

>

> > > > type-3 LSA's exists.

>

> > > > The RFC1765 only talks

>about type-5 LSA's

>

> > however

>

> > > it

>

> > > > could be extended for

>

> > > > other type of LSA's

>i.e. type-7, type-11.

>

> > > >

>

> > > > Thanks,

>

> > > > Vishwas

>

> > > >

>

> > > > -----Original

>Message-----

>

> > > > From: Amit Srivastava

>

> > [mailto:ospfisfun@YAHOO.COM]

>

> > > > Sent: Wednesday, June

>19, 2002 11:43 AM

>

> > > > To:

>OSPF@DISCUSS.MICROSOFT.COM

>

> > > > Subject: Re: OSPF

>Retransmission Doubt

>

> > > >

>

> > > >

>

> > > >

>

> > > > Hi Erblich and Vishwas,

>

> > > > Erblich I got your

>point but is there any

>

> > > > Draft or RFC which

>

> > > > states

>

> > > > this??

>

> > > > And Vishwas thanks for

>your help i would

>

> > also

>

> > > > like to know if

>

> > > > there is any draft

>which states that we can

>

> > > withdraw

>

> > > > Summary 3 and 4

>

> > > > non-default LSA.Because

>The RFC 2370 specks very

>

> > > > little about it.

>

> > > > Regards

>

> > > > Amit

>

> > > >

>

> > > >

>

> > > >

>

> > > > Amit

>Srivastava wrote:

>

> > > >

>

> > > >

>

> > > > Hi Vishwas!

>

> > > >

>

> > > >

>

> > > > Actually after reading

>the RFC 1765

>

> > only

>

> > > i

>

> > > > got this doubt.Here i

>

> > > > feel once the

>OSPFEXTLSDBLinit variable is

>

> > > exceeded

>

> > > > the router should

>

> > > > indicate other routers

>that its database is full

>

> > > and

>

> > > > they should not keep on

>

> > > > retransmitting the LSA

>which will clog the n/w

>

> > > > bandwidth.Once the

>router

>

> > > > comes out of the

>database overflow state it

>

> > should

>

> > > > indicate to the other

>

> > > > router that now they

>should send the LSA.

>

> > > >

>

> > > >

>

> > > > What do you say about

>this??

>

> > > >

>

> > > >

>

> > > > Regards

>

> > > >

>

> > > >

>

> > > > Amit

>

> > > >

>

> > > > "Manral,

>Vishwas"

>

> > wrote:

>

> > > >

>

> > > >

>

> > > > Hi Amit,

>

> > > >

>

> > > > You may like to look at

>the RFC1765 - OSPF

>

> > > Database

>

> > > > Overflow.

>

> > > >

>http://www.ietf.org/rfc/rfc1765.txt
This RFC

>

> > tells

>

> > > a

>

> > > > way to deal with such

>

> > > > overflow when it occurs

>in OSPF.

>

> > > >

>

> > > > Also as the RFC lists

>as enhancements, if the

>

> > > number

>

> > > > of summary LSA's

>

> >

>

>=== message truncated ===

>

>

>

>

>

>__________________________________________________

>

>Do You Yahoo!?

>

>Yahoo! - Official partner of 2002 FIFA

>World Cup

>

>http://fifaworldcup.yahoo.com

>







Get your FREE

>download of MSN Explorer at >href='http://g.msn.com/1HM503401/37'>http://explorer.msn.com.


>

>

>__________________________________________________

>Do You Yahoo!?

>Yahoo! - Official partner of 2002 FIFA
World Cup

>http://fifaworldcup.yahoo.com


MSN Photos is the
easiest way to share and print your photos: Click
Here



__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Jun 26 04:15:53 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07402
	for ; Wed, 26 Jun 2002 04:15:52 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.0066952F@cherry.ease.lsoft.com>; Wed, 26 Jun 2002 4:16:32 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 3201 for OSPF@DISCUSS.MICROSOFT.COM; Wed,
          26 Jun 2002 04:16:32 -0400
Received: from 216.32.181.144 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Wed, 26 Jun 2002 04:16:31 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed,
          26 Jun 2002 01:16:31 -0700
Received: from 211.99.77.6 by lw2fd.hotmail.msn.com with HTTP; Wed, 26 Jun 2002
          08:16:30 GMT
X-Originating-IP: [211.99.77.6]
Mime-Version: 1.0
Content-Type: text/html
X-OriginalArrivalTime: 26 Jun 2002 08:16:31.0576 (UTC)
                       FILETIME=[C7423D80:01C21CE9]
Message-ID:  
Date:         Wed, 26 Jun 2002 13:46:30 +0530
Reply-To: Mailing List 
Sender: Mailing List 
From: mohit gurnani 
Subject: Re: Database Over Flow Doubt
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list


Hi Amit,



You are right in saying that rotuer will keep on going into overflow unless the number routes do not get reduced, or unless the administrator does not remove a few (less important) redistributes or some other corrective action is taken.


  The RFC recognoses the problem that the router may go into Overflow again and again.See RFC-1765 point 4 
Administrative response to database overflow.


I am not sure how much effective the log will be (how much memory will it be able to clear up). Also if you rely on the log only, when the router comes out of overflow, you will have to ensure that all the log entries are still valid. Because some routes might have been deleted from the routing table while the router was in overflow. Also during Overflow state you cannot import any new routes that may get added into the routing table. All the new routes that get added into the routing table and can be imported will also need to be put into the log.


Regards


Mohit


 


>From: Amit Srivastava 


>Reply-To: Mailing List

>To: OSPF@DISCUSS.MICROSOFT.COM

>Subject: Re: Database Over Flow Doubt

>Date: Tue, 25 Jun 2002 23:09:31 -0700

>

>Hi mohit,

> Even this method seems to be prone to

>errors.Consider the case:-

> At time 12:40 PM the administartor gave the

>command redistribute bgp.This will put all the bgp

>routes in the ospf domain.Now due to this the ospf

>router goes in to the Overflow state.Now at 1:40 PM it

>recovers(when the timer expires)and would try to

>originate the LSA .To do so, from programme only he

>would call redistribute bgp.

> Now the problem is by this time BGP would

>have learned lot more routes which administrator would

>not like to flood them to ospf domain!!But as the

>redistribute bgp is called from the program this

>condition is unavoidable!!

> So i feel making log is better idea!!

>What do you say!!

>Regards

>Amit

>--- mohit gurnani wrote:

>

>




>



>

Hi Amit,
>

   What I want to say, in as little words

>as possibe, is that delete every flushed LSA that is

>acknowledged and donot maintain a log.



>

   The router must maintain all the

>routes (OSPF or otherwise) in some sort of a routing

>table. This routing table must provide an interface by

>means of which you can pick routes one by one (maybe

>some sort of get, get-first, get-next kind of

>interface). So what you do is pick first route, check

>if it is an active route (maybe even check if  it

>is not an OSPF route because a router cannot import

>its own OSPF routes), check if the router allows you

>to import it by means of policy filters. Import

>policies like distribute-out and redistribute 

>can be configured on the system. eg. if you have only

>Redistribute BGP configured, you are allowed to import

>all BGP routes and no other routes. And if the route

>can be imported, use its fields to construct a new

>external LSA, update your database and flood the LSA.

>You do this for all the routes in the routing table

>once the OverflowExitTimer expires.



>

   And it is advisable that you

>do import of routes in batches (say 500

>routes a second) and not all in one go because the

>process is long and might affect system overall

>performance.



>

Regards


>

Mohit





>



>

>From: Amit Srivastava

>

>

>Reply-To: Mailing List

>

>

>To: OSPF@DISCUSS.MICROSOFT.COM

>

>Subject: Re: Database Over Flow Doubt

>

>Date: Mon, 24 Jun 2002 22:09:42 -0700

>

>

>

>Hi Mohit!!

>

> could you please explain your answer

>(i mean the

>

>last two lines).Sorry i could not get

>you!!

>

>Regards

>

>Amit

>

>--- mohit gurnani

>wrote:

>

>

>

>

>




>

>

>

>

>

>

>

>

Hi Amit,


>

>

>

    The external LSAs are originated

>

>by scanning through external (non-OSPF)

>routes and

>

>applying filtering policies to filter

>out routes which

>

>cannot be imported. All the routes that

>pass policies

>

>are imported in form of external LSAs.

>



>

>

>

    Now when the system goes into

>

>overflow, the non-default

>self-originated LSAs are

>

>flushed and subsequently deleted from

>the database.

>

>You are right when you say it is a bad

>idea to

>

>maintain the log. It will defeat the

>whole purpose of

>

>Overflow implementation which aims at

>clearing up

>

>memory.What is advisable instead to

>delete all LSAs

>

>once acknowledged, and when the

>Overflow Exit Timer

>

>expires, scan through all the external

>routes once

>

>again, apply policy rules and re-import

>routes that

>

>pass policy.

>



>

>

>

 


>

>

>

Regards


>

>

>

Mohit



>



>

>

>



>

>

>

>From: Amit

>

>Srivastava

>

>

>

>Reply-To: Mailing

>

>List

>

>

>

>To: OSPF@DISCUSS.MICROSOFT.COM

>

>

>

>Subject: Database Over Flow Doubt

>

>

>

>Date: Sun, 23 Jun 2002 23:02:19 -0700

>

>

>

>

>

>

>

>Hi Vishwas!!

>

>

>

> I have one more doubt the RFC 1765 say

>

>in example

>

>

>

>(section 3) that when the OSPF timer

>

>expires then it

>

>

>

>tries to come out of the database

>

>overflow state and

>

>

>

>originates all the 400 non default

>

>AS-Exteranl LSA.Is

>

>

>

>it that before flushing the LSA it

>

>keeps the LSA in a

>

>

>

>linklist form and after the timer

>

>expires it

>

>

>

>originates the LSA again!!If this is

>

>the case then i

>

>

>

>have small doubt :-

>

>

>

> We have flushed the link state

>

>database

>

>

>

>because we think that we cannot

>

>accomodate any other

>

>

>

>LSA.Now keeping the log of all the

>

>flushed LSA would

>

>

>

>not be a good idea what i feel!!!

>

>

>

>What do u say??

>

>

>

>Regards

>

>

>

>Amit

>

>

>

>

>

>

>

>--- "Manral,

>

>Vishwas" wrote:

>

>

>

> > Amit,

>

>

>

> >

>

>

>

> > When the administrator finds that

>

>a domain is

>

>

>

> > getting "Overflows" he

>

>has to

>

>

>

> > change the policies so that the

>

>number of routes

>

>

>

> > imported into the domain is

>

>

>

> > reduced. The routes to be

>

>imported are all an

>

>

>

> > administrative

>

>

>

> > decision/policies and the OSPF

>

>packets etc do not

>

>

>

> > come into picture at all.

>

>

>

> >

>

>

>

> > The RFC in this point talks about

>

>importing routes

>

>

>

> > from other domains and

>

>

>

> > not about received LSA's from

>

>other routers in the

>

>

>

> > domain.

>

>

>

> >

>

>

>

> > Thanks,

>

>

>

> > Vishwas

>

>

>

> >

>

>

>

> > -----Original Message-----

>

>

>

> > From: Amit Srivastava

>

>[mailto:ospfisfun@YAHOO.COM]

>

>

>

> > Sent: Friday, June 21, 2002 4:35

>

>PM

>

>

>

> > To: OSPF@DISCUSS.MICROSOFT.COM

>

>

>

> > Subject: Re: OSPF Retransmission

>

>Doubt

>

>

>

> >

>

>

>

> >

>

>

>

> > Hi Vishwas!!

>

>

>

> > The RFC 1765 section 4 last point

>

>states that

>

>

>

> > if

>

>

>

> > the administrator cannot

>

>incresase the value of

>

>

>

> > ospfExtlsdbLimit then he can make

>

>sure that more

>

>

>

> > important routes continue to be

>

>imported ; this is

>

>

>

> > accomplished by turning off the

>

>importing of less

>

>

>

> > important routes.

>

>

>

> > Now my doubt is ->is it that

>

>the administrator

>

>

>

> > configures paticular n/w coming

>

>in the AS-external

>

>

>

> > packet as important or

>

>unimportant or does it mean

>

>

>

> > that routes learned by a

>

>paticular router-id are

>

>

>

> > important and will stay in the

>

>database while all

>

>

>

> > the

>

>

>

> > others will be flushed or is it

>

>implementation

>

>

>

> > specific!!!

>

>

>

> > Regards

>

>

>

> > Amit

>

>

>

> >

>

>

>

> >

>

>

>

> >

>

>

>

> >

>

>

>

> > --- "Manral,

>

>Vishwas" wrote:

>

>

>

> > > Hi Amit,

>

>

>

> > >

>

>

>

> > > The case would not occur if

>

>all the routers would

>

>

>

> > > have the same value of

>

>

>

> > > ExtLSDBLimit except in the

>

>transient condition.

>

>

>

> > > Section 2.2 first part would

>

>

>

> > > only occur if the value is

>

>not the same this may

>

>

>

> > be

>

>

>

> > > required. Its always

>

>

>

> > > better to check the

>

>condition, if we are exceeding

>

>

>

> > > the limit and accordingly

>

>

>

> > > take action to get over any

>

>such a case.

>

>

>

> > >

>

>

>

> > > Section 2.3 states that the

>

>flooding modification

>

>

>

> > > would only be invoked

>

>

>

> > > during a "short period

>

>of convergence" for same

>

>

>

> > > value of LSDBLimit. Such a

>

>

>

> > > case would only occur say

>

>when two routers are

>

>

>

> > > symultaneously originating

>

>

>

> > > AS-External LSA's. So when

>

>they are originating

>

>

>

> > the

>

>

>

> > > LSA's the LSDB limit is

>

>

>

> > > not exceeded however when

>

>they are receiving the

>

>

>

> > > LSA's from the other the

>

>

>

> > > LSDB limit is exceeded.

>

>However as the RFC states

>

>

>

> > > this would be a transient

>

>

>

> > > condition.

>

>

>

> > >

>

>

>

> > > Thanks,

>

>

>

> > > Vishwas

>

>

>

> > >

>

>

>

> > > -----Original Message-----

>

>

>

> > > From: Amit Srivastava

>

>[mailto:ospfisfun@YAHOO.COM]

>

>

>

> > > Sent: Thursday, June 20,

>

>2002 10:24 AM

>

>

>

> > > To:

>

>OSPF@DISCUSS.MICROSOFT.COM

>

>

>

> > > Subject: Re: OSPF

>

>Retransmission Doubt

>

>

>

> > >

>

>

>

> > >

>

>

>

> > > Hi Vishwas,

>

>

>

> > > I have a small doubt .If u

>

>refer to section 2.2

>

>

>

> > > and

>

>

>

> > > 2.3 of RFC 1765 it states

>

>that during flooding

>

>

>

> > also

>

>

>

> > > the variable count of

>

>non-default AS_external LSA

>

>

>

> > is

>

>

>

> > > incremented( if we receive a

>

>non-default

>

>

>

> > AS-external

>

>

>

> > > LSA during flooding).But if

>

>we have a common

>

>

>

> > thresh

>

>

>

> > > hold limit i.e variable

>

>ospfExtlsdbLimit is same

>

>

>

> > for

>

>

>

> > > all the router how come this

>

>condition will be

>

>

>

> > > encountered???

>

>

>

> > > Regards

>

>

>

> > > Amit

>

>

>

> > >

>

>

>

> > >

>

>

>

> > >

>

>

>

> > >

>

>

>

> > > --- "Manral,

>

>Vishwas"

>

>

>

> > wrote:

>

>

>

> > > > Hi Amit,

>

>

>

> > > >

>

>

>

> > > > I do not think any RFC

>

>which talks about

>

>

>

> > > non-default

>

>

>

> > > > type-3 LSA's exists.

>

>

>

> > > > The RFC1765 only talks

>

>about type-5 LSA's

>

>

>

> > however

>

>

>

> > > it

>

>

>

> > > > could be extended for

>

>

>

> > > > other type of LSA's

>

>i.e. type-7, type-11.

>

>

>

> > > >

>

>

>

> > > > Thanks,

>

>

>

> > > > Vishwas

>

>

>

> > > >

>

>

>

> > > > -----Original

>

>Message-----

>

>

>

> > > > From: Amit Srivastava

>

>

>

> > [mailto:ospfisfun@YAHOO.COM]

>

>

>

> > > > Sent: Wednesday, June

>

>19, 2002 11:43 AM

>

>

>

> > > > To:

>

>OSPF@DISCUSS.MICROSOFT.COM

>

>

>

> > > > Subject: Re: OSPF

>

>Retransmission Doubt

>

>

>

> > > >

>

>

>

> > > >

>

>

>

> > > >

>

>

>

> > > > Hi Erblich and Vishwas,

>

>

>

> > > > Erblich I got your

>

>point but is there any

>

>

>

> > > > Draft or RFC which

>

>

>

> > > > states

>

>

>

> > > > this??

>

>

>

> > > > And Vishwas thanks for

>

>your help i would

>

>

>

> > also

>

>

>

> > > > like to know if

>

>

>

> > > > there is any draft

>

>which states that we can

>

>

>

> > > withdraw

>

>

>

> > > > Summary 3 and 4

>

>

>

> > > > non-default LSA.Because

>

>The RFC 2370 specks very

>

>

>

> > > > little about it.

>

>

>

> > > > Regards

>

>

>

> > > > Amit

>

>

>

> > > >

>

>

>

> > > >

>

>

>

> > > >

>

>

>

> > > > Amit

>

>Srivastava wrote:

>

>

>

> > > >

>

>

>

> > > >

>

>

>

> > > > Hi Vishwas!

>

>

>

> > > >

>

>

>

> > > >

>

>

>

> > > > Actually after reading

>

>the RFC 1765

>

>

>

> > only

>

>

>

> > > i

>

>

>

> > > > got this doubt.Here i

>

>

>

> > > > feel once the

>

>OSPFEXTLSDBLinit variable is

>

>

>

> > > exceeded

>

>

>

> > > > the router should

>

>

>

> > > > indicate other routers

>

>that its database is full

>

>

>

> > > and

>

>

>

> > > > they should not keep on

>

>

>

> > > > retransmitting the LSA

>

>which will clog the n/w

>

>

>

> > > > bandwidth.Once the

>

>router

>

>

>

> > > > comes out of the

>

>database overflow state it

>

>

>

> > should

>

>

>

> > > > indicate to the other

>

>

>

> > > > router that now they

>

>should send the LSA.

>

>

>

> > > >

>

>

>

> > > >

>

>

>

> > > > What do you say about

>

>this??

>

>

>

> > > >

>

>

>

> > > >

>

>

>

> > > > Regards

>

>

>

> > > >

>

>

>

> > > >

>

>

>

> > > > Amit

>

>

>

> > > >

>

>

>

> > > > "Manral,

>

>Vishwas"

>

>

>

> > wrote:

>

>

>

> > > >

>

>

>

> > > >

>

>

>

> > > > Hi Amit,

>

>

>

> > > >

>

>

>

> > > > You may like to look at

>

>the RFC1765 - OSPF

>

>

>

> > > Database

>

>

>

> > > > Overflow.

>

>

>

> > > >

>

>http://www.ietf.org/rfc/rfc1765.txt

>This RFC

>

>

>

> > tells

>

>

>

> > > a

>

>

>

> > > > way to deal with such

>

>

>

> > > > overflow when it occurs

>

>in OSPF.

>

>

>

> > > >

>

>

>

> > > > Also as the RFC lists

>

>as enhancements, if the

>

>

>

> > > number

>

>

>

> > > > of summary LSA's

>

>

>

> >

>

>

>

>=== message truncated ===

>

>

>

>

>

>

>

>

>

>

>

>__________________________________________________

>

>

>

>Do You Yahoo!?

>

>

>

>Yahoo! - Official partner of 2002 FIFA

>

>World Cup

>

>

>

>http://fifaworldcup.yahoo.com

>

>

>



>




>




>Get your FREE

>

>download of MSN Explorer at ><>>href='http://g.msn.com/1HM503401/37'>http://explorer.msn.com.


>

>

>

>

>

>__________________________________________________

>

>Do You Yahoo!?

>

>Yahoo! - Official partner of 2002 FIFA

>World Cup

>

>http://fifaworldcup.yahoo.com

>







MSN Photos is the

>easiest way to share and print your photos: >href='http://g.msn.com/1HM1ENIN/c156??PI=44344'>Click

>Here


>

>

>__________________________________________________

>Do You Yahoo!?

>Yahoo! - Official partner of 2002 FIFA World Cup

>http://fifaworldcup.yahoo.com


Send and receive Hotmail on your mobile device: Click Here



From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Jun 26 04:54:25 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08117
	for ; Wed, 26 Jun 2002 04:54:24 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.006695C9@cherry.ease.lsoft.com>; Wed, 26 Jun 2002 4:55:08 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 3362 for OSPF@DISCUSS.MICROSOFT.COM; Wed,
          26 Jun 2002 04:55:07 -0400
Received: from 171.68.227.69 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 26 Jun 2002 04:55:07 -0400
Received: from cisco.com (sjc-vpn1-337.cisco.com [10.21.97.81]) by
          ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id BAA06037 for
          ; Wed, 26 Jun 2002 01:55:05 -0700 (PDT)
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D198167.F2FD836B@cisco.com>
Date:         Wed, 26 Jun 2002 01:55:04 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Sina Mirtorabi 
Subject: Re: DR change.
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Prashant,

prashant desai wrote:

> In case of a DR going down, BDR becomming DR and a new network lsa being
> originated..
> What should other routers in the domain do with the old network lsa ?
> It can lie around(age out) in the lsdb or can be purged explicitly ...
> Cisco seems to purge it..Is it an implementation issue.

It is actually mentioned in RFC

------
        A router may only prematurely age its own self-originated LSAs.
        The router may not prematurely age LSAs that have been
        originated by other routers.
------

----
            A router that has formerly been the Designated Router for a
            network, but is no longer, should flush the network-LSA that
            it had previously originated.  This LSA is no longer used in
            the routing table calculation.  It is flushed by prematurely
            incrementing the LSA's age to MaxAge and reflooding (see
            Section 14.1). In addition, in those rare cases where a
            router's Router ID has changed, any network-LSAs that were
            originated with the router's previous Router ID must be
            flushed. Since the router may have no idea what it's
            previous Router ID might have been, these network-LSAs are
            indicated by having their Link State ID equal to one of the
            router's IP interface addresses and their Advertising Router
            equal to some value other than the router's current Router
            ID (see Section 13.4 for more details).

-----

Sina

>
> Thanks
> Prashant
>
> _________________________________________________________________
> MSN Photos is the easiest way to share and print your photos:
> http://photos.msn.com/support/worldwide.aspx


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Jun 26 06:34:37 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10045
	for ; Wed, 26 Jun 2002 06:34:36 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.006697A2@cherry.ease.lsoft.com>; Wed, 26 Jun 2002 6:35:18 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 3908 for OSPF@DISCUSS.MICROSOFT.COM; Wed,
          26 Jun 2002 06:35:18 -0400
Received: from 66.218.78.81 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 26 Jun 2002 06:35:18 -0400
Received: from [203.200.20.226] by web40302.mail.yahoo.com via HTTP; Wed, 26
          Jun 2002 03:35:17 PDT
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <20020626103517.67391.qmail@web40302.mail.yahoo.com>
Date:         Wed, 26 Jun 2002 03:35:17 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Amit Srivastava 
Subject: Re: DR change.
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  
Precedence: list

Hi prashant!!
     There can be two parts to your problem i try to
discuss both of them

Part 1) Suppose the DR crashes and another router
becomes the DR fatre some time if the crashed router
restart it would flush its own self originated LSA.

Part 2) If the crash router does not restarts then the
LSA has to be there till the MAX age i don't think you
can do any thing for that!!!

Regards
Amit



--- prashant desai 
wrote:
> In case of a DR going down, BDR becomming DR and a
> new network lsa being
> originated..
> What should other routers in the domain do with the
> old network lsa ?
> It can lie around(age out) in the lsdb or can be
> purged explicitly ...
> Cisco seems to purge it..Is it an implementation
> issue.
>
> Thanks
> Prashant
>
>
_________________________________________________________________
> MSN Photos is the easiest way to share and print
> your photos:
> http://photos.msn.com/support/worldwide.aspx


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Jun 26 10:08:33 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19426
	for ; Wed, 26 Jun 2002 10:08:32 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00669FDC@cherry.ease.lsoft.com>; Wed, 26 Jun 2002 10:07:07 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 4989 for OSPF@DISCUSS.MICROSOFT.COM; Wed,
          26 Jun 2002 10:07:07 -0400
Received: from 205.226.5.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 26 Jun 2002 10:07:07 -0400
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
          by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA23112
          for ; Wed, 26 Jun 2002 07:07:06 -0700
          (PDT)
X-Delivered-For: 
Received: (from root@localhost) by darkstar.iprg.nokia.com
          (8.11.0/8.11.0-DARKSTAR) id g5QE76128515 for
          ; Wed, 26 Jun 2002 07:07:06 -0700
X-mProtect: <200206261407> Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (205.226.7.90,
          claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com
          smtpdb5Rhtj; Wed, 26 Jun 2002 07:07:04 PDT
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <200206260020.RAA02756@windsor.research.att.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D19CADA.832B37E8@iprg.nokia.com>
Date:         Wed, 26 Jun 2002 07:08:26 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Mukesh Gupta 
Organization: Nokia IPRG
Subject: Draft available: Authentication/Confidentiality for OSPFv3
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi All,

There is a draft available at
http://www.ietf.org/internet-drafts/draft-gupta-ospf-ospfv3-auth-00.txt on
Authentication/Confidentiality for OSPFv3.

Abstract: This document describes means/mechanisms to provide
authentication/confidentiality to OSPFv3 using IPv6 AH/ESP Extension Header.

I will be presenting this in the Yokohama meeting. I would appreciate
everyone's comments on this.

regards
Mukesh


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Jun 26 13:14:43 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00146
	for ; Wed, 26 Jun 2002 13:14:43 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0066A3F3@cherry.ease.lsoft.com>; Wed, 26 Jun 2002 13:15:24 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 5736 for OSPF@DISCUSS.MICROSOFT.COM; Wed,
          26 Jun 2002 13:15:24 -0400
Received: from 64.4.37.83 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 26 Jun 2002 13:15:24 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed,
          26 Jun 2002 10:15:23 -0700
Received: from 65.192.41.10 by pv2fd.pav2.hotmail.msn.com with HTTP; Wed, 26
          Jun 2002 17:15:23 GMT
X-Originating-IP: [65.192.41.10]
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 26 Jun 2002 17:15:23.0875 (UTC)
                       FILETIME=[0ECF8B30:01C21D35]
Message-ID:  
Date:         Wed, 26 Jun 2002 10:15:23 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: prashant desai 
Subject: Fwd: DR change.
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Regarding the DR change,
If on Cisco router I remove the DR from the routing domain by a 'no network
statement' , the BDR becomes the DR..
immediately doing 'show ip ospf database network' on the new DR will not
show
the network lsa by the old DR...note there was no explicit max aging of any
lsa by the old DR....atleast the version of IOS its running..
verfied by tcpdump...
I looked at zebra code and I feel even zebra seems to be maxaging the old DR
lsa though it did not orginate it...
Is this RFC compliant..or have I misunderstood something...

Thanks
Prashant


>From: prashant desai 
>Reply-To: Mailing List 
>To: OSPF@DISCUSS.MICROSOFT.COM
>Subject: DR change.
>Date: Tue, 25 Jun 2002 16:31:59 -0700
>
>In case of a DR going down, BDR becomming DR and a new network lsa being
>originated..
>What should other routers in the domain do with the old network lsa ?
>It can lie around(age out) in the lsdb or can be purged explicitly ...
>Cisco seems to purge it..Is it an implementation issue.
>
>Thanks
>Prashant
>
>_________________________________________________________________
>MSN Photos is the easiest way to share and print your photos:
>http://photos.msn.com/support/worldwide.aspx




_________________________________________________________________
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Jun 26 13:30:05 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01183
	for ; Wed, 26 Jun 2002 13:30:04 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0066A1EB@cherry.ease.lsoft.com>; Wed, 26 Jun 2002 13:30:46 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 5821 for OSPF@DISCUSS.MICROSOFT.COM; Wed,
          26 Jun 2002 13:30:46 -0400
Received: from 64.4.37.74 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 26 Jun 2002 13:30:46 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed,
          26 Jun 2002 10:30:45 -0700
Received: from 65.192.41.10 by pv2fd.pav2.hotmail.msn.com with HTTP; Wed, 26
          Jun 2002 17:30:45 GMT
X-Originating-IP: [65.192.41.10]
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 26 Jun 2002 17:30:45.0417 (UTC)
                       FILETIME=[3417B190:01C21D37]
Message-ID:  
Date:         Wed, 26 Jun 2002 10:30:45 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: prashant desai 
Subject: DR change..
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Sorry..seems I got the zebra code wrong..
it only deletes old net lsa if its already maxaged otherwise set a flag
saying
DISCARD_LSA..ie not use it..I belive cisco does the same and hence it does
not
appear in 'show ip ospf database'

Thanks
Prashant


_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail.
http://www.hotmail.com


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Jun 26 15:35:58 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07587
	for ; Wed, 26 Jun 2002 15:35:58 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.0066A60B@cherry.ease.lsoft.com>; Wed, 26 Jun 2002 15:36:40 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 6191 for OSPF@DISCUSS.MICROSOFT.COM; Wed,
          26 Jun 2002 15:36:40 -0400
Received: from 64.211.218.216 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Wed, 26 Jun 2002 15:36:40 -0400
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id
          g5QJadU39000 for ospf@discuss.microsoft.com; Wed, 26 Jun 2002
          15:36:39 -0400 (EDT) (envelope-from dang@nexthop.com)
Received: from marvin.nexthop.com (dang.nexthop.com [64.211.218.29]) by
          presque.djinesys.com (8.11.3/8.11.1) with SMTP id g5QJaa938993 for
          ; Wed, 26 Jun 2002 15:36:36 -0400 (EDT)
          (envelope-from dang@nexthop.com)
References: <3D192C34.DBDC2BA7@redback.com>
X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS perl-11
Message-ID:  <20020626153636.0cb8b652.dang@nexthop.com>
Date:         Wed, 26 Jun 2002 15:36:36 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: Daniel Gryniewicz 
Organization: Nexthop Technology
Subject: Re: Extended Hitless OSPF Restart
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <3D192C34.DBDC2BA7@redback.com>
Precedence: list
Content-Transfer-Encoding: 7bit

Hi.

Could someone please explain to me why this is necessary?  My reading of
draft-ietf-ospf-hitless-restart-02 indicates that an implementation should
*not* exit helper status because a router dead interval expired.  Please
enlighten me.

Daniel

On Tue, 25 Jun 2002 19:51:32 -0700
Acee Lindem  wrote:

> FYI - Ultimately, this would be an informational RFC or better yet
> folded into the base "OSPF Hitless Restart" specification (although
> this has not been discussed as of yet).
>
> Thanks,
> Acee
>
> Date: Tue, 25 Jun 2002 07:01:53 -0400
> From: Internet-Drafts@ietf.org
> To: IETF-Announce:  ;
> Subject: I-D ACTION:draft-lindem-ospf-hitless-extended-restart-00.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>         Title           : Extended Hitless OSPF Restart
>         Author(s)       : A. Lindem, A. Oswal
>         Filename        :
> draft-lindem-ospf-hitless-extended-restart-00.txt
>         Pages           : 3
>         Date            : 24-Jun-02
>



From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Jun 26 16:20:35 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09273
	for ; Wed, 26 Jun 2002 16:20:34 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0066A726@cherry.ease.lsoft.com>; Wed, 26 Jun 2002 16:21:17 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 6338 for OSPF@DISCUSS.MICROSOFT.COM; Wed,
          26 Jun 2002 16:21:17 -0400
Received: from 207.217.120.123 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Wed, 26 Jun 2002 16:21:17 -0400
Received: from user-2ivfmpc.dialup.mindspring.com ([165.247.219.44]
          helo=earthlink.net) by swan.mail.pas.earthlink.net with esmtp (Exim
          3.33 #2) id 17NJHv-0003Ux-00 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 26
          Jun 2002 13:21:16 -0700
X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified)
X-Mailer: Mozilla 4.72 [en]C-gatewaynet  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <3D192C34.DBDC2BA7@redback.com>
            <20020626153636.0cb8b652.dang@nexthop.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D1A249C.D6F41C44@earthlink.net>
Date:         Wed, 26 Jun 2002 13:31:24 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Erblichs 
Subject: Re: Extended Hitless OSPF Restart
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Group,

        This really goes back to the original doc..

        Shouldn't there be a limit of say 1 hour for the grace period.

        After that time, work that the proposed router's/helpers
        should almost ignore that the hitless restart functionality
        was originally requested and age out the LSAs that were
        originated by the by the restarting router.

        Mitchell Erblich
        =======================



Daniel Gryniewicz wrote:
>
> Hi.
>
> Could someone please explain to me why this is necessary?  My reading of
> draft-ietf-ospf-hitless-restart-02 indicates that an implementation should
> *not* exit helper status because a router dead interval expired.  Please
> enlighten me.
>
> Daniel
>
> On Tue, 25 Jun 2002 19:51:32 -0700
> Acee Lindem  wrote:
>
> > FYI - Ultimately, this would be an informational RFC or better yet
> > folded into the base "OSPF Hitless Restart" specification (although
> > this has not been discussed as of yet).
> >
> > Thanks,
> > Acee
> >
> > Date: Tue, 25 Jun 2002 07:01:53 -0400
> > From: Internet-Drafts@ietf.org
> > To: IETF-Announce:  ;
> > Subject: I-D ACTION:draft-lindem-ospf-hitless-extended-restart-00.txt
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >
> >
> >         Title           : Extended Hitless OSPF Restart
> >         Author(s)       : A. Lindem, A. Oswal
> >         Filename        :
> > draft-lindem-ospf-hitless-extended-restart-00.txt
> >         Pages           : 3
> >         Date            : 24-Jun-02
> >
> 


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Jun 26 16:23:23 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09375
	for ; Wed, 26 Jun 2002 16:23:23 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.0066A765@cherry.ease.lsoft.com>; Wed, 26 Jun 2002 16:24:07 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 6365 for OSPF@DISCUSS.MICROSOFT.COM; Wed,
          26 Jun 2002 16:24:07 -0400
Received: from 207.217.120.123 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Wed, 26 Jun 2002 16:24:07 -0400
Received: from user-2ivfmpc.dialup.mindspring.com ([165.247.219.44]
          helo=earthlink.net) by swan.mail.pas.earthlink.net with esmtp (Exim
          3.33 #2) id 17NJKf-0007gy-00 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 26
          Jun 2002 13:24:05 -0700
X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified)
X-Mailer: Mozilla 4.72 [en]C-gatewaynet  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <3D192C34.DBDC2BA7@redback.com>
            <20020626153636.0cb8b652.dang@nexthop.com>
            <3D1A249C.D6F41C44@earthlink.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D1A2545.7F831F14@earthlink.net>
Date:         Wed, 26 Jun 2002 13:34:13 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Erblichs 
Subject: Re: Extended Hitless OSPF Restart
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Sorry group,

        For this document...

        For the restarting router.. If it was the DR or BDR, do
        we keep him as the old DR/BDR or re-elect after router
        dead interval?


        Mitchell Erblich
        ==================





Erblichs wrote:
>
> Group,
>
>         This really goes back to the original doc..
>
>         Shouldn't there be a limit of say 1 hour for the grace period.
>
>         After that time, work that the proposed router's/helpers
>         should almost ignore that the hitless restart functionality
>         was originally requested and age out the LSAs that were
>         originated by the by the restarting router.
>
>         Mitchell Erblich
>         =======================
>
> Daniel Gryniewicz wrote:
> >
> > Hi.
> >
> > Could someone please explain to me why this is necessary?  My reading of
> > draft-ietf-ospf-hitless-restart-02 indicates that an implementation should
> > *not* exit helper status because a router dead interval expired.  Please
> > enlighten me.
> >
> > Daniel
> >
> > On Tue, 25 Jun 2002 19:51:32 -0700
> > Acee Lindem  wrote:
> >
> > > FYI - Ultimately, this would be an informational RFC or better yet
> > > folded into the base "OSPF Hitless Restart" specification (although
> > > this has not been discussed as of yet).
> > >
> > > Thanks,
> > > Acee
> > >
> > > Date: Tue, 25 Jun 2002 07:01:53 -0400
> > > From: Internet-Drafts@ietf.org
> > > To: IETF-Announce:  ;
> > > Subject: I-D ACTION:draft-lindem-ospf-hitless-extended-restart-00.txt
> > >
> > > A New Internet-Draft is available from the on-line Internet-Drafts
> > > directories.
> > >
> > >
> > >         Title           : Extended Hitless OSPF Restart
> > >         Author(s)       : A. Lindem, A. Oswal
> > >         Filename        :
> > > draft-lindem-ospf-hitless-extended-restart-00.txt
> > >         Pages           : 3
> > >         Date            : 24-Jun-02
> > >
> > 


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Jun 26 16:23:40 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09394
	for ; Wed, 26 Jun 2002 16:23:40 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0066A805@cherry.ease.lsoft.com>; Wed, 26 Jun 2002 16:24:24 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 6377 for OSPF@DISCUSS.MICROSOFT.COM; Wed,
          26 Jun 2002 16:24:24 -0400
Received: from 64.211.218.216 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Wed, 26 Jun 2002 16:24:24 -0400
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id
          g5QKOLF41825 for ospf@discuss.microsoft.com; Wed, 26 Jun 2002
          16:24:21 -0400 (EDT) (envelope-from dang@nexthop.com)
Received: from marvin.nexthop.com (dang.nexthop.com [64.211.218.29]) by
          presque.djinesys.com (8.11.3/8.11.1) with SMTP id g5QKO9941786 for
          ; Wed, 26 Jun 2002 16:24:09 -0400 (EDT)
          (envelope-from dang@nexthop.com)
References: <3D192C34.DBDC2BA7@redback.com>
            <20020626153636.0cb8b652.dang@nexthop.com>
            <3D1A249C.D6F41C44@earthlink.net>
X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS perl-11
Message-ID:  <20020626162409.3d0fb888.dang@nexthop.com>
Date:         Wed, 26 Jun 2002 16:24:09 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: Daniel Gryniewicz 
Organization: Nexthop Technology
Subject: Re: Extended Hitless OSPF Restart
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <3D1A249C.D6F41C44@earthlink.net>
Precedence: list
Content-Transfer-Encoding: 7bit

Well, the draft allows local policy to specify not entering helper mode if,
for example, the requested grace period exceeds time T.

Daniel

On Wed, 26 Jun 2002 13:31:24 -0700
Erblichs  wrote:

> Group,
>
>         This really goes back to the original doc..
>
>         Shouldn't there be a limit of say 1 hour for the grace period.
>
>         After that time, work that the proposed router's/helpers
>         should almost ignore that the hitless restart functionality
>         was originally requested and age out the LSAs that were
>         originated by the by the restarting router.
>
>         Mitchell Erblich
>         =======================
>
>
>
> Daniel Gryniewicz wrote:
> >
> > Hi.
> >
> > Could someone please explain to me why this is necessary?  My reading of
> > draft-ietf-ospf-hitless-restart-02 indicates that an implementation should
> > *not* exit helper status because a router dead interval expired.  Please
> > enlighten me.
> >
> > Daniel
> >
> > On Tue, 25 Jun 2002 19:51:32 -0700
> > Acee Lindem  wrote:
> >
> > > FYI - Ultimately, this would be an informational RFC or better yet
> > > folded into the base "OSPF Hitless Restart" specification (although
> > > this has not been discussed as of yet).
> > >
> > > Thanks,
> > > Acee
> > >
> > > Date: Tue, 25 Jun 2002 07:01:53 -0400
> > > From: Internet-Drafts@ietf.org
> > > To: IETF-Announce:  ;
> > > Subject: I-D ACTION:draft-lindem-ospf-hitless-extended-restart-00.txt
> > >
> > > A New Internet-Draft is available from the on-line Internet-Drafts
> > > directories.
> > >
> > >
> > >         Title           : Extended Hitless OSPF Restart
> > >         Author(s)       : A. Lindem, A. Oswal
> > >         Filename        :
> > > draft-lindem-ospf-hitless-extended-restart-00.txt
> > >         Pages           : 3
> > >         Date            : 24-Jun-02
> > >
> > 


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Jun 26 17:13:45 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11290
	for ; Wed, 26 Jun 2002 17:13:45 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0066AB07@cherry.ease.lsoft.com>; Wed, 26 Jun 2002 17:14:29 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 6527 for OSPF@DISCUSS.MICROSOFT.COM; Wed,
          26 Jun 2002 17:14:29 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 26 Jun 2002 17:14:28 -0400
Received: from redback.com (jagged.redback.com [155.53.36.195]) by
          prattle.redback.com (Postfix) with ESMTP id 347B91531C7 for
          ; Wed, 26 Jun 2002 14:14:27 -0700 (PDT)
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.0.38 i386)
X-Accept-Language: en
MIME-Version: 1.0
References: <3D192C34.DBDC2BA7@redback.com>
            <20020626153636.0cb8b652.dang@nexthop.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D1A2EB3.3226CFCC@redback.com>
Date:         Wed, 26 Jun 2002 14:14:27 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Acee Lindem 
Organization: Redback Networks, Inc
Subject: Re: Extended Hitless OSPF Restart
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Daniel Gryniewicz wrote:
>
> Hi.
>
> Could someone please explain to me why this is necessary?  My reading of
> draft-ietf-ospf-hitless-restart-02 indicates that an implementation should
> *not* exit helper status because a router dead interval expired.  Please
> enlighten me.

This not what I've implemented. A router acting as a helper will exit
helper mode when:

    1. The inactivity timer expires.
    2. The interface goes down (which will also cause an LSA change). However,
       I've made it a configurable option whether or not a given router acting
       as a helper exits graceful restart when there is a change to an LSA which
       will be flooded to the restarting router.
    3. Certain sequence mismatch conditions (but not the obvious ones that occur
       naturally during graceful restart).

I'd be interested in what others have implemented.

Thanks,
Acee


>
> Daniel
>
> On Tue, 25 Jun 2002 19:51:32 -0700
> Acee Lindem  wrote:
>
> > FYI - Ultimately, this would be an informational RFC or better yet
> > folded into the base "OSPF Hitless Restart" specification (although
> > this has not been discussed as of yet).
> >
> > Thanks,
> > Acee
> >
> > Date: Tue, 25 Jun 2002 07:01:53 -0400
> > From: Internet-Drafts@ietf.org
> > To: IETF-Announce:  ;
> > Subject: I-D ACTION:draft-lindem-ospf-hitless-extended-restart-00.txt
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >
> >
> >         Title           : Extended Hitless OSPF Restart
> >         Author(s)       : A. Lindem, A. Oswal
> >         Filename        :
> > draft-lindem-ospf-hitless-extended-restart-00.txt
> >         Pages           : 3
> >         Date            : 24-Jun-02
> >
> 

--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Jun 26 17:22:08 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11565
	for ; Wed, 26 Jun 2002 17:22:08 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0066A995@cherry.ease.lsoft.com>; Wed, 26 Jun 2002 17:22:52 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 6547 for OSPF@DISCUSS.MICROSOFT.COM; Wed,
          26 Jun 2002 17:22:52 -0400
Received: from 64.211.218.216 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Wed, 26 Jun 2002 17:22:51 -0400
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id
          g5QLMpX44571 for ospf@discuss.microsoft.com; Wed, 26 Jun 2002
          17:22:51 -0400 (EDT) (envelope-from dang@nexthop.com)
Received: from marvin.nexthop.com (dang.nexthop.com [64.211.218.29]) by
          presque.djinesys.com (8.11.3/8.11.1) with SMTP id g5QLMj944553 for
          ; Wed, 26 Jun 2002 17:22:45 -0400 (EDT)
          (envelope-from dang@nexthop.com)
References: <3D192C34.DBDC2BA7@redback.com>
            <20020626153636.0cb8b652.dang@nexthop.com>
            <3D1A2EB3.3226CFCC@redback.com>
X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS perl-11
Message-ID:  <20020626172245.57632177.dang@nexthop.com>
Date:         Wed, 26 Jun 2002 17:22:45 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: Daniel Gryniewicz 
Organization: Nexthop Technology
Subject: Re: Extended Hitless OSPF Restart
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <3D1A2EB3.3226CFCC@redback.com>
Precedence: list
Content-Transfer-Encoding: 7bit

Isn't the whole point of a grace period that you want to exceed a router dead
interval?  If you are not going to exceed it, you can just do an ISIS restart,
which does not need a grace period at all.

Daniel

On Wed, 26 Jun 2002 14:14:27 -0700
Acee Lindem  wrote:

> Daniel Gryniewicz wrote:
> >
> > Hi.
> >
> > Could someone please explain to me why this is necessary?  My reading of
> > draft-ietf-ospf-hitless-restart-02 indicates that an implementation should
> > *not* exit helper status because a router dead interval expired.  Please
> > enlighten me.
>
> This not what I've implemented. A router acting as a helper will exit
> helper mode when:
>
>     1. The inactivity timer expires.
>     2. The interface goes down (which will also cause an LSA change).
However,>        I've made it a configurable option whether or not a given
router acting>        as a helper exits graceful restart when there is a
change to an LSA which>        will be flooded to the restarting router.
>     3. Certain sequence mismatch conditions (but not the obvious ones that
occur>        naturally during graceful restart).
>
> I'd be interested in what others have implemented.
>
> Thanks,
> Acee
>
>
> >
> > Daniel
> >
> > On Tue, 25 Jun 2002 19:51:32 -0700
> > Acee Lindem  wrote:
> >
> > > FYI - Ultimately, this would be an informational RFC or better yet
> > > folded into the base "OSPF Hitless Restart" specification (although
> > > this has not been discussed as of yet).
> > >
> > > Thanks,
> > > Acee
> > >
> > > Date: Tue, 25 Jun 2002 07:01:53 -0400
> > > From: Internet-Drafts@ietf.org
> > > To: IETF-Announce:  ;
> > > Subject: I-D ACTION:draft-lindem-ospf-hitless-extended-restart-00.txt
> > >
> > > A New Internet-Draft is available from the on-line Internet-Drafts
> > > directories.
> > >
> > >
> > >         Title           : Extended Hitless OSPF Restart
> > >         Author(s)       : A. Lindem, A. Oswal
> > >         Filename        :
> > > draft-lindem-ospf-hitless-extended-restart-00.txt
> > >         Pages           : 3
> > >         Date            : 24-Jun-02
> > >
> > 
>
> --
> Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Jun 26 17:59:58 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13039
	for ; Wed, 26 Jun 2002 17:59:58 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0066AA52@cherry.ease.lsoft.com>; Wed, 26 Jun 2002 18:00:42 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 6671 for OSPF@DISCUSS.MICROSOFT.COM; Wed,
          26 Jun 2002 18:00:41 -0400
Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 26 Jun 2002 18:00:41 -0400
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id SAA05324 for ; Wed, 26 Jun 2002
          18:00:38 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com
          (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by
          mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA08171
          for ; Wed, 26 Jun 2002 18:00:40 -0400
          (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id ; Wed, 26 Jun 2002 18:00:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <39469E08BD83D411A3D900204840EC5576322D@vie-msgusr-01.dc.fore.com>
Date:         Wed, 26 Jun 2002 18:00:39 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: "Naidu, Venkata" 
Subject: Re: Extended Hitless OSPF Restart
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Acee,

  Here is what I think.

-> This not what I've implemented. A router acting as a helper will exit
-> helper mode when:
->
->     1. The inactivity timer expires.

  No, any hello related, packet exchange timers related, to
  that interface, should not bring down helper mode.

->     2. The interface goes down (which will also cause an LSA
-> change).

  Do you mean, operational state of interface going down?
  In other words, forwarding plane on that interface goes down ?

->     3. Certain sequence mismatch conditions (but not the
-> obvious ones that occur
->        naturally during graceful restart).

  Again, any change in the LSDB which the restart router
  might want to know, should trigger helper exit.

  More precisely, some changes in LSAs might not affect
  forwarding plane at all. In all those cases, there is no
  need to exit from helper mode.

--
Venkata.


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Jun 26 18:06:21 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13247
	for ; Wed, 26 Jun 2002 18:06:20 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.0066ABA0@cherry.ease.lsoft.com>; Wed, 26 Jun 2002 18:07:04 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 6728 for OSPF@DISCUSS.MICROSOFT.COM; Wed,
          26 Jun 2002 18:07:04 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 26 Jun 2002 18:07:04 -0400
Received: from redback.com (jagged.redback.com [155.53.36.195]) by
          prattle.redback.com (Postfix) with ESMTP id 26817262817 for
          ; Wed, 26 Jun 2002 15:07:02 -0700 (PDT)
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.0.38 i386)
X-Accept-Language: en
MIME-Version: 1.0
References: <39469E08BD83D411A3D900204840EC5576322D@vie-msgusr-01.dc.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D1A3B06.49D82167@redback.com>
Date:         Wed, 26 Jun 2002 15:07:02 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Acee Lindem 
Organization: Redback Networks, Inc
Subject: Re: Extended Hitless OSPF Restart
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

"Naidu, Venkata" wrote:
>
> Acee,
>
>   Here is what I think.
>
> -> This not what I've implemented. A router acting as a helper will exit
> -> helper mode when:
> ->
> ->     1. The inactivity timer expires.
>
>   No, any hello related, packet exchange timers related, to
>   that interface, should not bring down helper mode.
>
> ->     2. The interface goes down (which will also cause an LSA
> -> change).
>
>   Do you mean, operational state of interface going down?
>   In other words, forwarding plane on that interface goes down ?

Yes.

>
> ->     3. Certain sequence mismatch conditions (but not the
> -> obvious ones that occur
> ->        naturally during graceful restart).
>
>   Again, any change in the LSDB which the restart router
>   might want to know, should trigger helper exit.
>
>   More precisely, some changes in LSAs might not affect
>   forwarding plane at all. In all those cases, there is no
>   need to exit from helper mode.

Sequence mismatch is a neighbor event. What I'm saying is that
if there is an error in the database exchange after the initial
unexpected transition from full to exchange start, I will exit
helper mode and restart the database exchange.

>
> --
> Venkata.

--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Wed Jun 26 18:09:29 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13402
	for ; Wed, 26 Jun 2002 18:09:29 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.0066ABE8@cherry.ease.lsoft.com>; Wed, 26 Jun 2002 18:10:12 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 6766 for OSPF@DISCUSS.MICROSOFT.COM; Wed,
          26 Jun 2002 18:10:12 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Wed, 26 Jun 2002 18:10:11 -0400
Received: from redback.com (jagged.redback.com [155.53.36.195]) by
          prattle.redback.com (Postfix) with ESMTP id ECF1B262817 for
          ; Wed, 26 Jun 2002 15:10:10 -0700 (PDT)
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.0.38 i386)
X-Accept-Language: en
MIME-Version: 1.0
References: <3D192C34.DBDC2BA7@redback.com>
            <20020626153636.0cb8b652.dang@nexthop.com>
            <3D1A2EB3.3226CFCC@redback.com>
            <20020626172245.57632177.dang@nexthop.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D1A3BC2.F3D9380F@redback.com>
Date:         Wed, 26 Jun 2002 15:10:10 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Acee Lindem 
Organization: Redback Networks, Inc
Subject: Re: Extended Hitless OSPF Restart
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Daniel Gryniewicz wrote:
>
> Isn't the whole point of a grace period that you want to exceed a router dead
> interval?  If you are not going to exceed it, you can just do an ISIS restart,
> which does not need a grace period at all.

The main differenence is that without graceful restart, OSPF offers no mechanism
for learning the link state database without transitioning out of full state and
re-originating router/neighbors LSAs, etc.


>
> Daniel
>
> On Wed, 26 Jun 2002 14:14:27 -0700
> Acee Lindem  wrote:
>
> > Daniel Gryniewicz wrote:
> > >
> > > Hi.
> > >
> > > Could someone please explain to me why this is necessary?  My reading of
> > > draft-ietf-ospf-hitless-restart-02 indicates that an implementation should
> > > *not* exit helper status because a router dead interval expired.  Please
> > > enlighten me.
> >
> > This not what I've implemented. A router acting as a helper will exit
> > helper mode when:
> >
> >     1. The inactivity timer expires.
> >     2. The interface goes down (which will also cause an LSA change).
> However,>        I've made it a configurable option whether or not a given
> router acting>        as a helper exits graceful restart when there is a
> change to an LSA which>        will be flooded to the restarting router.
> >     3. Certain sequence mismatch conditions (but not the obvious ones that
> occur>        naturally during graceful restart).
> >
> > I'd be interested in what others have implemented.
> >
> > Thanks,
> > Acee
> >
> >
> > >
> > > Daniel
> > >
> > > On Tue, 25 Jun 2002 19:51:32 -0700
> > > Acee Lindem  wrote:
> > >
> > > > FYI - Ultimately, this would be an informational RFC or better yet
> > > > folded into the base "OSPF Hitless Restart" specification (although
> > > > this has not been discussed as of yet).
> > > >
> > > > Thanks,
> > > > Acee
> > > >
> > > > Date: Tue, 25 Jun 2002 07:01:53 -0400
> > > > From: Internet-Drafts@ietf.org
> > > > To: IETF-Announce:  ;
> > > > Subject: I-D ACTION:draft-lindem-ospf-hitless-extended-restart-00.txt
> > > >
> > > > A New Internet-Draft is available from the on-line Internet-Drafts
> > > > directories.
> > > >
> > > >
> > > >         Title           : Extended Hitless OSPF Restart
> > > >         Author(s)       : A. Lindem, A. Oswal
> > > >         Filename        :
> > > > draft-lindem-ospf-hitless-extended-restart-00.txt
> > > >         Pages           : 3
> > > >         Date            : 24-Jun-02
> > > >
> > > 
> >
> > --
> > Acee

--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Jun 27 00:34:08 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22568
	for ; Thu, 27 Jun 2002 00:34:08 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.0066B7B1@cherry.ease.lsoft.com>; Thu, 27 Jun 2002 0:34:41 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 8176 for OSPF@DISCUSS.MICROSOFT.COM; Thu,
          27 Jun 2002 00:34:41 -0400
Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 27 Jun 2002 00:34:41 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id ; Thu, 27 Jun 2002 00:30:07 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  
Date:         Thu, 27 Jun 2002 00:37:06 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: "Manral, Vishwas" 
Subject: Re: Extended Hitless OSPF Restart
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Acee,

I agree to your point, however I guess the draft
http://www.ietf.org/internet-drafts/draft-nguyen-ospf-oob-resync-00.txt
though not a working group item does allow Out of Band resynch, something
like the functionality you talk about below.

Thanks,
Vishwas

-----Original Message-----
From: Acee Lindem [mailto:acee@REDBACK.COM]
Sent: Thursday, June 27, 2002 3:40 AM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: Extended Hitless OSPF Restart


Daniel Gryniewicz wrote:
>
> Isn't the whole point of a grace period that you want to exceed a router
dead
> interval?  If you are not going to exceed it, you can just do an ISIS
restart,
> which does not need a grace period at all.

The main differenence is that without graceful restart, OSPF offers no
mechanism
for learning the link state database without transitioning out of full state
and
re-originating router/neighbors LSAs, etc.


>
> Daniel
>
> On Wed, 26 Jun 2002 14:14:27 -0700
> Acee Lindem  wrote:
>
> > Daniel Gryniewicz wrote:
> > >
> > > Hi.
> > >
> > > Could someone please explain to me why this is necessary?  My reading
of
> > > draft-ietf-ospf-hitless-restart-02 indicates that an implementation
should
> > > *not* exit helper status because a router dead interval expired.
Please
> > > enlighten me.
> >
> > This not what I've implemented. A router acting as a helper will exit
> > helper mode when:
> >
> >     1. The inactivity timer expires.
> >     2. The interface goes down (which will also cause an LSA change).
> However,>        I've made it a configurable option whether or not a given
> router acting>        as a helper exits graceful restart when there is a
> change to an LSA which>        will be flooded to the restarting router.
> >     3. Certain sequence mismatch conditions (but not the obvious ones
that
> occur>        naturally during graceful restart).
> >
> > I'd be interested in what others have implemented.
> >
> > Thanks,
> > Acee
> >
> >
> > >
> > > Daniel
> > >
> > > On Tue, 25 Jun 2002 19:51:32 -0700
> > > Acee Lindem  wrote:
> > >
> > > > FYI - Ultimately, this would be an informational RFC or better yet
> > > > folded into the base "OSPF Hitless Restart" specification (although
> > > > this has not been discussed as of yet).
> > > >
> > > > Thanks,
> > > > Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Jun 27 01:02:20 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23048
	for ; Thu, 27 Jun 2002 01:02:19 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0066B75D@cherry.ease.lsoft.com>; Thu, 27 Jun 2002 1:03:01 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 8444 for OSPF@DISCUSS.MICROSOFT.COM; Thu,
          27 Jun 2002 01:03:01 -0400
Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 27 Jun 2002 01:03:01 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id ; Thu, 27 Jun 2002 00:58:27 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  
Date:         Thu, 27 Jun 2002 01:02:18 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: "Manral, Vishwas" 
Subject: Re: Extended Hitless OSPF Restart
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi Mitchell,

Please look at the draft
https://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-02.txt
this draft clearly states the DR role stays after across a hitless restart,
while we do not keep the BDR role.

As long as we do not reset adjacencies(neighbor change event) with the
restarting router we will not do a DR election at all.

Thanks,
Vishwas

-----Original Message-----
From: Erblichs [mailto:erblichs@EARTHLINK.NET]
Sent: Thursday, June 27, 2002 2:04 AM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: Extended Hitless OSPF Restart


Sorry group,

        For this document...

        For the restarting router.. If it was the DR or BDR, do
        we keep him as the old DR/BDR or re-elect after router
        dead interval?


        Mitchell Erblich
        ==================


Erblichs wrote:
>
> Group,
>
>         This really goes back to the original doc..
>
>         Shouldn't there be a limit of say 1 hour for the grace period.
>
>         After that time, work that the proposed router's/helpers
>         should almost ignore that the hitless restart functionality
>         was originally requested and age out the LSAs that were
>         originated by the by the restarting router.
>
>         Mitchell Erblich
>         =======================
>
> Daniel Gryniewicz wrote:
> >
> > Hi.
> >
> > Could someone please explain to me why this is necessary?  My reading of
> > draft-ietf-ospf-hitless-restart-02 indicates that an implementation
should
> > *not* exit helper status because a router dead interval expired.  Please
> > enlighten me.
> >
> > Daniel
> >
> > On Tue, 25 Jun 2002 19:51:32 -0700
> > Acee Lindem  wrote:
> >
> > > FYI - Ultimately, this would be an informational RFC or better yet
> > > folded into the base "OSPF Hitless Restart" specification (although
> > > this has not been discussed as of yet).
> > >
> > > Thanks,
> > > Acee
> > >


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Jun 27 06:17:42 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08323
	for ; Thu, 27 Jun 2002 06:17:42 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.0066BD65@cherry.ease.lsoft.com>; Thu, 27 Jun 2002 6:18:26 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 10084 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 27 Jun 2002 06:18:25 -0400
Received: from 205.158.62.50 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 27 Jun 2002 06:18:25 -0400
Received: (qmail 22890 invoked by uid 1001); 27 Jun 2002 10:18:25 -0000
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-Mailer: MIME-tools 5.41 (Entity 5.404)
Received: from [129.187.222.168] by ws1-4.us4.outblaze.com with http for
          beatriz_hargrave@mail.com; Thu, 27 Jun 2002 05:18:25 -0500
X-Originating-Ip: 129.187.222.168
X-Originating-Server: ws1-4.us4.outblaze.com
Message-ID:  <20020627101825.22888.qmail@mail.com>
Date:         Thu, 27 Jun 2002 05:18:25 -0500
Reply-To: Mailing List 
Sender: Mailing List 
From: Beatriz Silva 
Subject: broadcas network definition
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi !

According to RFC 2328 broadcast networks are defined as follows:

Broadcast networks
Networks supporting many (more than two) attached routers,
together with the capability to address a single physical
message to all of the attached routers (broadcast).
Neighboring routers are discovered dynamically on these nets
using OSPF's Hello Protocol.  The Hello Protocol itself
takes advantage of the broadcast capability.  The OSPF
protocol makes further use of multicast capabilities, if
they exist.  Each pair of routers on a broadcast network is
assumed to be able to communicate directly. An ethernet is
an example of a broadcast network.

And there is also a drawing example where, as far as I understood N3 could be a broadcast network.


                 +
                 | 3+---+                     N12      N14
               N1|--|RT1|\ 1                    \ N13 /
                 |  +---+ \                     8\ |8/8
                 +         \ ____                 \|/
                            /    \   1+---+8    8+---+6
                           *  N3  *---|RT4|------|RT5|--------+
                            \____/    +---+      +---+        |
                  +         /   |                  |7         |
                  | 3+---+ /    |                  |          |
                N2|--|RT2|/1    |1                 |6         |
                  |  +---+    +---+8            6+---+        |
                  +           |RT3|--------------|RT6|        |
                              +---+              +---+        |


My question is what physically would be a broadcast network (or what could be inside N3 ?)?

I understand that only one ethernet cable (or ethernet cables connected through hubs) with some computers connected to it would be a broadcast network: every message sent on this network could be listenned by any computer and router. But, what if there are some switches connecting the ethernet cables ? In that case some ethernet segments might not receive the packet sent to hosts in other segments. It still an broadcast network ?

Obs: As far as I understood, N3 is a broadcast network containing only 4 routers: RT1, RT2, RT3 and RT4. Inside the hexagon written N3 would exit only ethernet cables connected by switches (?) or hubs. Is that right ?

I would really appreciate if somebody could answer my question.

Thanks,
Beatriz







--
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

Save up to $160 by signing up for NetZero Platinum Internet service.
http://www.netzero.net/?refcd=N2P0602NEP8


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Jun 27 10:03:55 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19123
	for ; Thu, 27 Jun 2002 10:03:55 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0066C16E@cherry.ease.lsoft.com>; Thu, 27 Jun 2002 10:04:38 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 10956 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 27 Jun 2002 10:04:37 -0400
Received: from 47.129.242.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 27 Jun 2002 10:04:37 -0400
Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com
          [132.245.205.62]) by zcars04f.ca.nortel.com
          (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5RE4Zv17547 for
          ; Thu, 27 Jun 2002 10:04:36 -0400 (EDT)
Received: by zbl6c012.corpeast.baynetworks.com with Internet Mail Service
          (5.5.2653.19) id ; Thu, 27 Jun 2002 10:04:35 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C21DE3.904F1A00"
Message-ID:  <8B888AAAAB0FD31189590008C79184430B507DFF@zbl6c002.corpeast.baynetworks.com>
Date:         Thu, 27 Jun 2002 10:04:33 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: Ruth Fax 
Subject: Re: broadcas network definition
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C21DE3.904F1A00
Content-Type: text/plain;
        charset="iso-8859-1"

Hi Beatriz,

Broadcast packets are not forwarded off subnets.  With broadcast
you reach all the hosts on your subnet.
A broadcast network can be implemented in H/W or S/W.  Within N3
all hosts on the same subnet should receive broadcasts that originate on
that subnet.

--Ruth


-----Original Message-----
From: Beatriz Silva [mailto:beatriz_hargrave@MAIL.COM]
Sent: Thursday, June 27, 2002 6:18 AM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: broadcas network definition


Hi !

According to RFC 2328 broadcast networks are defined as follows:

Broadcast networks
Networks supporting many (more than two) attached routers,
together with the capability to address a single physical
message to all of the attached routers (broadcast).
Neighboring routers are discovered dynamically on these nets
using OSPF's Hello Protocol.  The Hello Protocol itself
takes advantage of the broadcast capability.  The OSPF
protocol makes further use of multicast capabilities, if
they exist.  Each pair of routers on a broadcast network is
assumed to be able to communicate directly. An ethernet is
an example of a broadcast network.

And there is also a drawing example where, as far as I understood N3 could
be a broadcast network.


                 +
                 | 3+---+                     N12      N14
               N1|--|RT1|\ 1                    \ N13 /
                 |  +---+ \                     8\ |8/8
                 +         \ ____                 \|/
                            /    \   1+---+8    8+---+6
                           *  N3  *---|RT4|------|RT5|--------+
                            \____/    +---+      +---+        |
                  +         /   |                  |7         |
                  | 3+---+ /    |                  |          |
                N2|--|RT2|/1    |1                 |6         |
                  |  +---+    +---+8            6+---+        |
                  +           |RT3|--------------|RT6|        |
                              +---+              +---+        |


My question is what physically would be a broadcast network (or what could
be inside N3 ?)?

I understand that only one ethernet cable (or ethernet cables connected
through hubs) with some computers connected to it would be a broadcast
network: every message sent on this network could be listenned by any
computer and router. But, what if there are some switches connecting the
ethernet cables ? In that case some ethernet segments might not receive the
packet sent to hosts in other segments. It still an broadcast network ?

Obs: As far as I understood, N3 is a broadcast network containing only 4
routers: RT1, RT2, RT3 and RT4. Inside the hexagon written N3 would exit
only ethernet cables connected by switches (?) or hubs. Is that right ?

I would really appreciate if somebody could answer my question.

Thanks,
Beatriz







--
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

Save up to $160 by signing up for NetZero Platinum Internet service.
http://www.netzero.net/?refcd=N2P0602NEP8

------_=_NextPart_001_01C21DE3.904F1A00
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: broadcas network definition




Hi Beatriz,




Broadcast packets are not forwarded off =
subnets.  With broadcast

you reach all the hosts on your subnet.

A broadcast network can be implemented in H/W or =
S/W.  Within N3

all hosts on the same subnet should receive =
broadcasts that originate on

that subnet.




--Ruth






-----Original Message-----

From: Beatriz Silva [mailto:beatriz_hargrave@MAIL.C=
OM]

Sent: Thursday, June 27, 2002 6:18 AM

To: OSPF@DISCUSS.MICROSOFT.COM

Subject: broadcas network definition






Hi !




According to RFC 2328 broadcast networks are defined =
as follows:




Broadcast networks

Networks supporting many (more than two) attached =
routers,

together with the capability to address a single =
physical

message to all of the attached routers =
(broadcast).

Neighboring routers are discovered dynamically on =
these nets

using OSPF's Hello Protocol.  The Hello =
Protocol itself

takes advantage of the broadcast capability.  =
The OSPF

protocol makes further use of multicast =
capabilities, if

they exist.  Each pair of routers on a =
broadcast network is

assumed to be able to communicate directly. An =
ethernet is

an example of a broadcast network.




And there is also a drawing example where, as far as =
I understood N3 could be a broadcast network.






          &nb=
sp;      +

          &nb=
sp;      | =
3+---+           =
          =
N12      N14

          &nb=
sp;    N1|--|RT1|\ =
1            =
;        \ N13 /

          &nb=
sp;      |  +---+ =
\            =
;         8\ |8/8

          &nb=
sp;      =
+         \ =
____           &n=
bsp;     \|/

          &nb=
sp;           &nb=
sp;     /    \   =
1+---+8    8+---+6

          &nb=
sp;           &nb=
sp;    *  N3  =
*---|RT4|------|RT5|--------+

          &nb=
sp;           &nb=
sp;     \____/    =
+---+      =
+---+        |

          &nb=
sp;       =
+         /   =
|            =
;      =
|7         |

          &nb=
sp;       | 3+---+ /    =
|            =
;      =
|          |

          &nb=
sp;     N2|--|RT2|/1    =
|1           &nbs=
p;     =
|6         |

          &nb=
sp;       |  +---+    =
+---+8           =
 6+---+        |

          &nb=
sp;       =
+           =
|RT3|--------------|RT6|        =
|

          &nb=
sp;           &nb=
sp;       =
+---+           &=
nbsp;  +---+        |






My question is what physically would be a broadcast =
network (or what could be inside N3 ?)?




I understand that only one ethernet cable (or =
ethernet cables connected through hubs) with some computers connected =
to it would be a broadcast network: every message sent on this network =
could be listenned by any computer and router. But, what if there are =
some switches connecting the ethernet cables ? In that case some =
ethernet segments might not receive the packet sent to hosts in other =
segments. It still an broadcast network ?



Obs: As far as I understood, N3 is a broadcast =
network containing only 4 routers: RT1, RT2, RT3 and RT4. Inside the =
hexagon written N3 would exit only ethernet cables connected by =
switches (?) or hubs. Is that right ?



I would really appreciate if somebody could answer my =
question.




Thanks,

Beatriz
















--

__________________________________________________________

Sign-up for your own FREE Personalized E-mail at =
Mail.com

http://www.mail.com/?sr=3Dsignup




Save up to $160 by signing up for NetZero Platinum =
Internet service.

http://www.netzero.net/?refcd=3DN2P0602NEP8=






------_=_NextPart_001_01C21DE3.904F1A00--


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Jun 27 14:37:27 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07719
	for ; Thu, 27 Jun 2002 14:37:26 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.0066CA8F@cherry.ease.lsoft.com>; Thu, 27 Jun 2002 14:38:03 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 11857 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 27 Jun 2002 14:38:03 -0400
Received: from 207.217.120.122 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Thu, 27 Jun 2002 14:38:03 -0400
Received: from user-2ivfkbb.dialup.mindspring.com ([165.247.209.107]
          helo=earthlink.net) by pintail.mail.pas.earthlink.net with esmtp
          (Exim 3.33 #2) id 17Ne9Y-0007d8-00 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 27 Jun 2002 11:38:01 -0700
X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified)
X-Mailer: Mozilla 4.72 [en]C-gatewaynet  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D1B5DEA.E66343D2@earthlink.net>
Date:         Thu, 27 Jun 2002 11:48:10 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Erblichs 
Subject: Re: Extended Hitless OSPF Restart
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Vishwas,

        Looooong....

        Here are what I percieve as real weaknesses in the two docs..

        Actually no it doesn't state that the DR is kept between restarts.
        It implicitly states that the DR is kept if the router was down for
        less than router dead interval. Actually down for time of ( router
        dead interval - waiting time) or less, by seeing a hello with the
        restart router being specified as the DR. But then there is a
conflicting
        statement, which I will point to later..

        And I am going blind, I see no mention of how a BDR is treated
        in either restart doc. So, it is unstated operation. What happens
        if the BDR is a helper, should it not re-elect itself due to
        section 3 as a helper to maintain the X router as the DR? If
        the BDR isn't a helper (router did not want to verify that the
        grace-LSAs were recieved), does the BDR then ignore the helper's hellos
        (assuming that DRothers are helpers and the restart was the DR) sees
that
        there is no DR hellos, his router dead interval expires, and elect
himself?
        Now lets assume that the BDR came up after the DR, but really has
higher
        priority. Again the interaction is unspecified when the restart router
        comes back. However, between the time that the BDR elected himself, and
        the helpers keep the restart as the DR, we will have two DRs specified
        in hellos... ummm Now to make things worse, a new router comes up and
        looks for a DR and sees different routers, continually announcing
different
        routers as the DR..

        Justification for the problems are stated in long form below...

        Please note that point 1 below identifies a statement, identifies
        problems with it, and then sees that in point 2 a conflicting
        statement that implictly specifies increasing the router-dead-interval
        to the grace interval.

        New Point 1
        ============

        Sect. 2 After the router restarts ...(3) If the restarting router...

        "an Hello packet is
           received from a neighbor listing the router as Designated
           Router."

        But if the restarting router is down for more than the dead router
        interval., will hellos still specifiy that the restarting router
        is the DR? They shouldn't. Why can't the router see that a DR
        is Y, and Y's hellos specify that its priority is Z, then specify
        its own priority as Z+1, and act that it is the DR. And force a
        re-election back to itself as the DR? Why wouldn't it want to do
        that? Should this last item be a "MAY", meaning a DR restarting
        for longer than router dead interval may relect itself by doing
        the following..

        Orig Doc,..
        If the restarting router is kept as the DR, then what happens to the
        routers that come up sometime
        before it re-elects itself? I am concerned most where a BDR doesn't
        exist. They are effectively dead. They can't form adjacencies until
        there is a live DR.

        This problem is worse with the "extended hitless" . Section 3. Changes
        to helper neighbor operation

        Where the router dead interval is reset to the grace period.... Wow..
        What happens if that time is 1 hour and there is no BDR, and other
        routers come up, no adjs are formed. Why can't you just keep the
        original router dead interval time, mark the router in a restart state,
        and if the router doesn't come back in say 1 hr, then cleanup.. Restart
        state says don't send him anything other than hellos, suspend your
        re-xmits to that router, etc...
        This would decrease the load on the routers that stay up.

        extend doc..If the restarting router is the DR.......
        At least there should be a BDR verified for the interfaces where there
        there is a DR, else.. it should NOT be extended in my opinion. If there
        is a BDR and the BDR goes down the helpers should revert to their
        previous dead interval times, and re-elect.
        extend doc.. And what happens to the negotiated hello dead interval
        time value with exchange of hellos pdus?


        New Point 2
        ================
        But after all of that...
        We know have a conflicting statement... of section 2... with hellos..
        3. Operations of helper neighbor..

        "Also, if X was the Designated Router on network segment S when the
    helping relationship began, Y maintains X as Designated router until
    the helping relationship is terminated."

        This is for the grace period...

        Or does this implictly state that "dead router interval" is automaticly
        extended to the grace period", by the helpers. IT should now be sending
        hellos out with the restart system as the DR...

        If that was so, then why would the extended doc need to explicitly
        state that???????

        Why is there a conflict with the two docs..


        OLD POINTS
        ==================

        And back to a question that I had over a month ago.
        2.1 Entering hitless restart...

        "If Router X wants to ensure that its neighbors
        receive the grace-LSAs, it should retransmit the grace-LSAs
        until they are acknowledged (i.e, perform standard OSPF reliable
        flooding of the grace-LSAs). If one or more fully adjacent
        neighbors do not receive grace-LSAs, they will more than likely
        cause premature termination of the hitless restart procedure
        (see Section 4)."

        1st: Is "wants" a SHOULD, MUST, ...??


            Sub item
            ========
            Lets assume it is a must. What happens if just one nbr has a late
ack?
            And now that the late ack, now shortens the time allocated for
            "requested grace period"? I assume he can extended it by
            "There is one exception to the above requirements. If Y was
            already helping X on the associated network segment, the new
            grace-LSA should be accepted and the grace period should be
            updated accordingly."
               ***But how does he withdraw it?
                   Should he send a grace-LSA with a grace-period of 0?


        2nd: Is "recieve", acked?

        This one paragraph is a conflict in itself.

        First if we see "wants" as
        a MUST, then we don't get acks from an adj nbr, then we prematurely
        terminate if we don't get back acks.

        2nd if we see "wants" as optional, and we don't verify that they recv
        the grace-LSA, then then we we don't care that some systems are unaware
        of what we are doing?

        If he thinks that all of our router neighbors should agree with us,
        and there is a router neighbor addition, then his implied statement
        should prematurely end the helper agreement? Else, not..

        So, what is he saying, again...
        If we look at section 4. Backward compatibility
        Then he states
        "If one or more
    neighbors of a router requesting hitless restart are unmodified, or
    if they do not received the grace-LSA, the hitless restart converts
    to a normal OSPF restart."

        Which is no longer a want... because of "recvieved the grace-LSAs"?
        *** But what happens if a router doesn't want to verify that his
grace-LSAs
        are recvd?



        Mitchell Erblich
        ==================



"Manral, Vishwas" wrote:
>
> Hi Mitchell,
>
> Please look at the draft
> https://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-02.txt
> this draft clearly states the DR role stays after across a hitless restart,
> while we do not keep the BDR role.
>
> As long as we do not reset adjacencies(neighbor change event) with the
> restarting router we will not do a DR election at all.
>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Erblichs [mailto:erblichs@EARTHLINK.NET]
> Sent: Thursday, June 27, 2002 2:04 AM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Re: Extended Hitless OSPF Restart
>
> Sorry group,
>
>         For this document...
>
>         For the restarting router.. If it was the DR or BDR, do
>         we keep him as the old DR/BDR or re-elect after router
>         dead interval?
>
>         Mitchell Erblich
>         ==================
>
> Erblichs wrote:
> >
> > Group,
> >
> >         This really goes back to the original doc..
> >
> >         Shouldn't there be a limit of say 1 hour for the grace period.
> >
> >         After that time, work that the proposed router's/helpers
> >         should almost ignore that the hitless restart functionality
> >         was originally requested and age out the LSAs that were
> >         originated by the by the restarting router.
> >
> >         Mitchell Erblich
> >         =======================
> >
> > Daniel Gryniewicz wrote:
> > >
> > > Hi.
> > >
> > > Could someone please explain to me why this is necessary?  My reading of
> > > draft-ietf-ospf-hitless-restart-02 indicates that an implementation
> should
> > > *not* exit helper status because a router dead interval expired.  Please
> > > enlighten me.
> > >
> > > Daniel
> > >
> > > On Tue, 25 Jun 2002 19:51:32 -0700
> > > Acee Lindem  wrote:
> > >
> > > > FYI - Ultimately, this would be an informational RFC or better yet
> > > > folded into the base "OSPF Hitless Restart" specification (although
> > > > this has not been discussed as of yet).
> > > >
> > > > Thanks,
> > > > Acee
> > > >


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Jun 27 15:14:59 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10197
	for ; Thu, 27 Jun 2002 15:14:59 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0066CCB5@cherry.ease.lsoft.com>; Thu, 27 Jun 2002 15:15:42 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 11974 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 27 Jun 2002 15:15:42 -0400
Received: from 216.32.171.82 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 27 Jun 2002 15:15:42 -0400
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id
          MAA17369 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 27 Jun 2002 12:12:58
          -0700 (PDT)
References: <8B888AAAAB0FD31189590008C79184430B507DFF@zbl6c002.corpeast.baynetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Message-ID:  <20020627121258.H14986@demiurge.exodus.net>
Date:         Thu, 27 Jun 2002 12:12:58 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Andrew Lange 
Subject: Re: broadcas network definition
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <8B888AAAAB0FD31189590008C79184430B507DFF@zbl6c002.corpeast.baynetworks.com>; from
              rfax@NORTELNETWORKS.COM on Thu, Jun 27, 2002 at 10:04:33AM -0400
Precedence: list

Beatriz,

To follow up on your switch question, if a frame is forwarded to a switch
with a broadcast destination, it is forwarded out all ports on the switch.
This assumes that there are no vlans configured.  If there are vlans,
then the frame is only forwarded out all ports in the vlan.

Andrew

On Thu, Jun 27, 2002 at 10:04:33AM -0400, Ruth Fax wrote:
> X-Mailer: Internet Mail Service (5.5.2653.19)
> Date:         Thu, 27 Jun 2002 10:04:33 -0400
> Reply-To: Mailing List 
> From: Ruth Fax 
> Subject: Re: broadcas network definition
> To: OSPF@DISCUSS.MICROSOFT.COM
> Precedence: list
> X-OriginalArrivalTime: 27 Jun 2002 14:05:37.0264 (UTC) FILETIME=[B6465700:01C21DE3]
>
> Hi Beatriz,
>
> Broadcast packets are not forwarded off subnets.  With broadcast
> you reach all the hosts on your subnet.
> A broadcast network can be implemented in H/W or S/W.  Within N3
> all hosts on the same subnet should receive broadcasts that originate on
> that subnet.
>
> --Ruth
>
>
> -----Original Message-----
> From: Beatriz Silva [mailto:beatriz_hargrave@MAIL.COM]
> Sent: Thursday, June 27, 2002 6:18 AM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: broadcas network definition
>
>
> Hi !
>
> According to RFC 2328 broadcast networks are defined as follows:
>
> Broadcast networks
> Networks supporting many (more than two) attached routers,
> together with the capability to address a single physical
> message to all of the attached routers (broadcast).
> Neighboring routers are discovered dynamically on these nets
> using OSPF's Hello Protocol.  The Hello Protocol itself
> takes advantage of the broadcast capability.  The OSPF
> protocol makes further use of multicast capabilities, if
> they exist.  Each pair of routers on a broadcast network is
> assumed to be able to communicate directly. An ethernet is
> an example of a broadcast network.
>
> And there is also a drawing example where, as far as I understood N3 could
> be a broadcast network.
>
>
>                  +
>                  | 3+---+                     N12      N14
>                N1|--|RT1|\ 1                    \ N13 /
>                  |  +---+ \                     8\ |8/8
>                  +         \ ____                 \|/
>                             /    \   1+---+8    8+---+6
>                            *  N3  *---|RT4|------|RT5|--------+
>                             \____/    +---+      +---+        |
>                   +         /   |                  |7         |
>                   | 3+---+ /    |                  |          |
>                 N2|--|RT2|/1    |1                 |6         |
>                   |  +---+    +---+8            6+---+        |
>                   +           |RT3|--------------|RT6|        |
>                               +---+              +---+        |
>
>
> My question is what physically would be a broadcast network (or what could
> be inside N3 ?)?
>
> I understand that only one ethernet cable (or ethernet cables connected
> through hubs) with some computers connected to it would be a broadcast
> network: every message sent on this network could be listenned by any
> computer and router. But, what if there are some switches connecting the
> ethernet cables ? In that case some ethernet segments might not receive the
> packet sent to hosts in other segments. It still an broadcast network ?
>
> Obs: As far as I understood, N3 is a broadcast network containing only 4
> routers: RT1, RT2, RT3 and RT4. Inside the hexagon written N3 would exit
> only ethernet cables connected by switches (?) or hubs. Is that right ?
>
> I would really appreciate if somebody could answer my question.
>
> Thanks,
> Beatriz
>
>
>
>
>
>
>
> --
> __________________________________________________________
> Sign-up for your own FREE Personalized E-mail at Mail.com
> http://www.mail.com/?sr=signup
>
> Save up to $160 by signing up for NetZero Platinum Internet service.
> http://www.netzero.net/?refcd=N2P0602NEP8


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Jun 27 16:20:59 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13918
	for ; Thu, 27 Jun 2002 16:20:59 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0066CE22@cherry.ease.lsoft.com>; Thu, 27 Jun 2002 16:21:42 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 12213 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 27 Jun 2002 16:21:42 -0400
Received: from 66.122.42.228 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 27 Jun 2002 16:21:42 -0400
Received: from sanjose.futsoft.com (unverified) by fcs-nt1.futsoft.com (Content
          Technologies SMTPRS 2.0.15) with SMTP id
           for ;
          Thu, 27 Jun 2002 13:21:18 -0700
Received: from fcslabmc4 (adsl-66-122-42-243.futsoft.com [66.122.42.243] (may
          be forged)) by sanjose.futsoft.com (8.9.3/8.8.7) with SMTP id
          MAA08230 for ; Thu, 27 Jun 2002 12:03:18
          -0700
References:  <20020624121000.49807.qmail@web21509.mail.yahoo.com>
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-ID:  <00d901c21e18$4fca94c0$030110ac@futsoft.com>
Date:         Thu, 27 Jun 2002 13:22:07 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Samvid Shah 
Subject: Re: Multicast addresses AllSPFRouters, AllDRouters
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi Group,
        Sorry for the late reply.

        my 2 cents to this discussion.

        first regarding mapping IP address to MAC address,
        as per RFC 1112
        "An IP host group address is mapped to an Ethernet multicast address
   by placing the low-order 23-bits of the IP address into the low-order
   23 bits of the Ethernet multicast address 01-00-5E-00-00-00 (hex).
   Because there are 28 significant bits in an IP host group address,
   more than one host group address may map to the same Ethernet
   multicast address."

       now coming to membership reports generated by OSPF router,
       as per RFC 2328, section 4.4 (page 44)

       "IP multicast
            Certain OSPF packets take the form of IP multicast
            datagrams.  Support for receiving and sending IP multicast
            datagrams, along with the appropriate lower-level protocol
            support, is required.  The IP multicast datagrams used by
            OSPF never travel more than one hop. For this reason, the
            ability to forward IP multicast datagrams is not required.
            For information on IP multicast, see [Ref7]."

       since, IGMP (along with multicast routing protocols) is typically
used for multicast data transfer across multiple hops,  I think It is not
required to send group memberships for allSPFRouters  and allDRouters .
Also, since  IGMP is designed for interactions between host and router,   I
think, sending membership report  is not required.

        but if your question is,
                  if by sending this membership report, are we breaking any
thing here ?

                  I have to say , I could not find any reference that says
IGMP membership report *must not* be sent by OSPF router. (May be more
knowledgeable soul can throw a light here.)

      Thanks.
                               -Samvid

----- Original Message -----
From: "Amit Srivastava" 
To: 
Sent: Monday, June 24, 2002 5:10 AM
Subject: Re: Multicast addresses AllSPFRouters, AllDRouters


> Hi Beatriz,
>       The mac address that is sent(as destination) is
> the exact mapping of the multicast IP address.If you
> are using the Linux system then by default it supports
> Mac layer multicast support.
>             So if your destination IP is 224.0.0.5
> then your mac destination address will be 01 00 5e 00
> 00 05 in hex.
>        The IGMP group joining is sent as a rule for
> the IP multicaste which states that whenever you join
> any group of multicaste address you have to send a
> group join indiaction to your router.Study multicaste
> general protocol to make picture more clear.
> I hope i am clear!!
> Regards
> Amit
> --- Beatriz Silva  wrote:
> > Amit, thanks for the answer. But I still have some
> > doubts ...
> >
> > More specifically my question is:
> >
> > When a packet to AllSPFRouters is sent, what is the
> > MAC address written in the destination field of the
> > Ethernet header ? Is it a mac multicast address or
> > is there a mapping between the ip multicast address
> > and the mac addresses of all of the routers that
> > joined that multicast address ?
> > And what must be done in the router in order for it
> > to be capable to liste to packets to multicast
> > address AllSPFRouters and AllDRouters (if it is the
> > case) ?
> > Why does the router have to send an IGMP membership
> > report message to AllSPFaddress and to AllDRouters
> > multicast addresses ?
> >
> > I hope I am not too confusing ..
> >
> > Thank you,
> >
> > Beatriz
> > > > AllSPFRouters and another to AllDRouters
> > ----- Original Message -----
> > From: Amit Srivastava 
> > Date:         Mon, 24 Jun 2002 02:41:34 -0700
> > To: OSPF@DISCUSS.MICROSOFT.COM
> > Subject: Re: Multicast addresses AllSPFRouters,
> > AllDRouters
> >
> >
> > > Hi Beatriz.
> > >    As far as i could understand your problem the
> > > answer to it is:-
> > >            The Ip layer keeps a buffer(table) in
> > which
> > > it stores all the IP addresses it is listening
> > to.So
> > > when a packet is send on the net the Ip layer
> > would
> > > check the destination ip address from the buffer
> > it is
> > > holding and if the address is found then it will
> > give
> > > the packet to the other protocol otherwise it will
> > > discard the packet.
> > > Regards
> > > Amit
> > > --- Beatriz Silva 
> > wrote:
> > > > Hi !
> > > >
> > > > I realized that as soon as I put one of the
> > routers
> > > > interfaces up, one of the first things that is
> > done
> > > > is to send a IGMP membership report message to
> > > > AllSPFRouters and another to AllDRouters. Does
> > > > anybody knows why ?? Does the router interface
> > keeps
> > > > a table including all of the member addresses of
> > > > these multicast addresses ? Is there a mapping
> > from
> > > > the Ip multicast address to all of the destined
> > mac
> > > > addresses ?
> > > >
> > > > Thank you very much,
> > > >
> > > > Beatriz
> > > > --
> > > >
> > >
> >
> __________________________________________________________
> > > > Sign-up for your own FREE Personalized E-mail at
> > > > Mail.com
> > > > http://www.mail.com/?sr=signup
> > > >
> > > > Save up to $160 by signing up for NetZero
> > Platinum
> > > > Internet service.
> > > > http://www.netzero.net/?refcd=N2P0602NEP8
> > >
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Yahoo! - Official partner of 2002 FIFA World Cup
> > > http://fifaworldcup.yahoo.com
> > >
> >
> > --
> >
> __________________________________________________________
> > Sign-up for your own FREE Personalized E-mail at
> > Mail.com
> > http://www.mail.com/?sr=signup
> >
> > Save up to $160 by signing up for NetZero Platinum
> > Internet service.
> > http://www.netzero.net/?refcd=N2P0602NEP8
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com
>


From owner-ospf@DISCUSS.MICROSOFT.COM  Thu Jun 27 19:58:00 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23215
	for ; Thu, 27 Jun 2002 19:57:59 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0066D5C1@cherry.ease.lsoft.com>; Thu, 27 Jun 2002 19:58:42 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 12737 for OSPF@DISCUSS.MICROSOFT.COM;
          Thu, 27 Jun 2002 19:58:41 -0400
Received: from 131.241.15.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Thu, 27 Jun 2002 19:58:41 -0400
Received: from netkeeper2.sj.nec.com (netkeeper2.sj.nec.com [131.241.31.10]) by
          mail4.nec.com (/) with ESMTP id g5RNw4K13975 for
          ; Thu, 27 Jun 2002 16:58:04 -0700 (PDT)
Received: from necsun.tdd.sj.nec.com (localhost [127.0.0.1]) by
          netkeeper2.sj.nec.com (8.9.1a/8.9.1) with ESMTP id QAA18996 for
          ; Thu, 27 Jun 2002 16:57:57 -0700 (PDT)
Received: from bunny.tdd.sj.nec.com by necsun.tdd.sj.nec.com  with ESMTP id
          g5RNpce7018477 for ; Thu, 27 Jun 2002
          16:51:38 -0700 (PDT)
Received: from ems12 (ems12 [131.241.5.17]) by bunny.tdd.sj.nec.com  with SMTP
          id g5RNpbJv013817 for ; Thu, 27 Jun 2002
          16:51:37 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Message-ID:  <010e01c21e36$ac6f5580$1105f183@b90.tdd.sj.nec.com>
Date:         Thu, 27 Jun 2002 16:59:28 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: kamatchi soundaram 
Subject: Importance of Identifier field in IP header in sending OSPF packet.
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi all,

   I need some clarification for the requirement of assigning the Identifier
feild of IP header in the case of OSPF packet sending.

Basically IP uses an Identifier field in its IP Header, which will be
uniquely assigned for the all IP packets generated by a particular source to
a particular destination (RFC 791 says this). May be the assigning will be
based on the source and destination address pair or a meger unique number
starting from 1 to 2 power 16. This identifier is significant in the case of
fragmentation and reassembly.

Now the following four are my questions.
1) In the case of OSPF all packets except the packets to virtual links will
be transmitted maximum one hop. And since OSPF itself takes care about the
outgoing interface MTU size when the packet is constructed, then there won't
be any fragmentation at IP level. So, in that case, will the IP identifier
field is still updated by IP with an unique value.

2) And what is general implementation? whether ip identifier is updated or
not given any preference in the case of OSPF packet?

3) In the case of OSPF packets to virtual links, it goes to many hops from
source to destination as a unicast packet. So, in that case, the identifier
field seems to be needed, for ressembly and fragmentation. So, what will be
the case in this scenario?

4) Can i send identifier field as zero always  irrespective of whether the
packet is going through virtual links or other links??

It would be highly appreciable if i get some valuable explanations for the
above questions.

thanks,
--sundar--


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Jun 28 04:03:47 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13684
	for ; Fri, 28 Jun 2002 04:03:46 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0066E062@cherry.ease.lsoft.com>; Fri, 28 Jun 2002 4:04:27 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 13607 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 28 Jun 2002 04:04:27 -0400
Received: from 144.254.15.118 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Fri, 28 Jun 2002 04:04:26 -0400
Received: from ASMIRNOVW2K (dhcp-bru-peg2-vl26-144-254-9-171.cisco.com
          [144.254.9.171]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with
          SMTP id g5S84Qh13698 for ; Fri, 28 Jun
          2002 10:04:26 +0200 (CEST)
References:  <010e01c21e36$ac6f5580$1105f183@b90.tdd.sj.nec.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Message-ID:  <052e01c21e7a$8ed36fe0$ab09fe90@cisco.com>
Date:         Fri, 28 Jun 2002 10:05:24 +0200
Reply-To: Mailing List 
Sender: Mailing List 
From: Anton Smirnov 
Organization: Cisco Systems, Inc.
Subject: Re: Importance of Identifier field in IP header in sending OSPF       
         packet.
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

   Sundar,

> Now the following four are my questions.
> 1) In the case of OSPF all packets except the packets to virtual links
will
> be transmitted maximum one hop. And since OSPF itself takes care about the
> outgoing interface MTU size when the packet is constructed, then there
won't
> be any fragmentation at IP level. So, in that case, will the IP identifier
> field is still updated by IP with an unique value.
>
generally speaking, this is incorrect. Better say that good implementation
might try to follow this approach but even then it is not always possible.
One example is if router LSA (of any router in the area) is bigger than MTU
on the link. It is not something very common but happens in some designs. In
this case Update packet by definition cannot fit into MTU without
fragmentation.

> 2) And what is general implementation? whether ip identifier is updated or
> not given any preference in the case of OSPF packet?
>
general implementation is to separate IP I/O subsystem and OSPF subsystem as
one of its users. IP Identifier field is not something OSPF should worry
about at all. It should send whatever datagrams it wants (though it should
consult outgoing interface MTU and make informed decision) and receive
already reassembled datagrams.

> 3) In the case of OSPF packets to virtual links, it goes to many hops from
> source to destination as a unicast packet. So, in that case, the
identifier
> field seems to be needed, for ressembly and fragmentation. So, what will
be
> the case in this scenario?
>
> 4) Can i send identifier field as zero always  irrespective of whether the
> packet is going through virtual links or other links??
>
I would say no.


> It would be highly appreciable if i get some valuable explanations for the
> above questions.
>
> thanks,
> --sundar--
>


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Jun 28 04:23:20 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14227
	for ; Fri, 28 Jun 2002 04:23:20 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0066E16B@cherry.ease.lsoft.com>; Fri, 28 Jun 2002 4:24:04 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 13655 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 28 Jun 2002 04:24:03 -0400
Received: from 66.218.78.90 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 28 Jun 2002 04:24:03 -0400
Received: from [203.200.20.226] by web40311.mail.yahoo.com via HTTP; Fri, 28
          Jun 2002 01:24:03 PDT
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <20020628082403.95665.qmail@web40311.mail.yahoo.com>
Date:         Fri, 28 Jun 2002 01:24:03 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Amit Srivastava 
Subject: Re: Multicast addresses AllSPFRouters, AllDRouters
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  <00d901c21e18$4fca94c0$030110ac@futsoft.com>
Precedence: list

Hi samvid!!
      When you say that all the ospf packet do not
travel more than one hop away then i think you are not
considering the virtual links!!!
             Plz think on that aspect and the picture
would be more clear!!
Regards
Amit

--- Samvid Shah  wrote:
> Hi Group,
>         Sorry for the late reply.
>
>         my 2 cents to this discussion.
>
>         first regarding mapping IP address to MAC
> address,
>         as per RFC 1112
>         "An IP host group address is mapped to an
> Ethernet multicast address
>    by placing the low-order 23-bits of the IP
> address into the low-order
>    23 bits of the Ethernet multicast address
> 01-00-5E-00-00-00 (hex).
>    Because there are 28 significant bits in an IP
> host group address,
>    more than one host group address may map to the
> same Ethernet
>    multicast address."
>
>        now coming to membership reports generated by
> OSPF router,
>        as per RFC 2328, section 4.4 (page 44)
>
>        "IP multicast
>             Certain OSPF packets take the form of IP
> multicast
>             datagrams.  Support for receiving and
> sending IP multicast
>             datagrams, along with the appropriate
> lower-level protocol
>             support, is required.  The IP multicast
> datagrams used by
>             OSPF never travel more than one hop. For
> this reason, the
>             ability to forward IP multicast
> datagrams is not required.
>             For information on IP multicast, see
> [Ref7]."
>
>        since, IGMP (along with multicast routing
> protocols) is typically
> used for multicast data transfer across multiple
> hops,  I think It is not
> required to send group memberships for allSPFRouters
>  and allDRouters .
> Also, since  IGMP is designed for interactions
> between host and router,   I
> think, sending membership report  is not required.
>
>         but if your question is,
>                   if by sending this membership
> report, are we breaking any
> thing here ?
>
>                   I have to say , I could not find
> any reference that says
> IGMP membership report *must not* be sent by OSPF
> router. (May be more
> knowledgeable soul can throw a light here.)
>
>       Thanks.
>                                -Samvid
>
> ----- Original Message -----
> From: "Amit Srivastava" 
> To: 
> Sent: Monday, June 24, 2002 5:10 AM
> Subject: Re: Multicast addresses AllSPFRouters,
> AllDRouters
>
>
> > Hi Beatriz,
> >       The mac address that is sent(as destination)
> is
> > the exact mapping of the multicast IP address.If
> you
> > are using the Linux system then by default it
> supports
> > Mac layer multicast support.
> >             So if your destination IP is 224.0.0.5
> > then your mac destination address will be 01 00 5e
> 00
> > 00 05 in hex.
> >        The IGMP group joining is sent as a rule
> for
> > the IP multicaste which states that whenever you
> join
> > any group of multicaste address you have to send a
> > group join indiaction to your router.Study
> multicaste
> > general protocol to make picture more clear.
> > I hope i am clear!!
> > Regards
> > Amit
> > --- Beatriz Silva 
> wrote:
> > > Amit, thanks for the answer. But I still have
> some
> > > doubts ...
> > >
> > > More specifically my question is:
> > >
> > > When a packet to AllSPFRouters is sent, what is
> the
> > > MAC address written in the destination field of
> the
> > > Ethernet header ? Is it a mac multicast address
> or
> > > is there a mapping between the ip multicast
> address
> > > and the mac addresses of all of the routers that
> > > joined that multicast address ?
> > > And what must be done in the router in order for
> it
> > > to be capable to liste to packets to multicast
> > > address AllSPFRouters and AllDRouters (if it is
> the
> > > case) ?
> > > Why does the router have to send an IGMP
> membership
> > > report message to AllSPFaddress and to
> AllDRouters
> > > multicast addresses ?
> > >
> > > I hope I am not too confusing ..
> > >
> > > Thank you,
> > >
> > > Beatriz
> > > > > AllSPFRouters and another to AllDRouters
> > > ----- Original Message -----
> > > From: Amit Srivastava 
> > > Date:         Mon, 24 Jun 2002 02:41:34 -0700
> > > To: OSPF@DISCUSS.MICROSOFT.COM
> > > Subject: Re: Multicast addresses AllSPFRouters,
> > > AllDRouters
> > >
> > >
> > > > Hi Beatriz.
> > > >    As far as i could understand your problem
> the
> > > > answer to it is:-
> > > >            The Ip layer keeps a buffer(table)
> in
> > > which
> > > > it stores all the IP addresses it is listening
> > > to.So
> > > > when a packet is send on the net the Ip layer
> > > would
> > > > check the destination ip address from the
> buffer
> > > it is
> > > > holding and if the address is found then it
> will
> > > give
> > > > the packet to the other protocol otherwise it
> will
> > > > discard the packet.
> > > > Regards
> > > > Amit
> > > > --- Beatriz Silva 
> > > wrote:
> > > > > Hi !
> > > > >
> > > > > I realized that as soon as I put one of the
> > > routers
> > > > > interfaces up, one of the first things that
> is
> > > done
> > > > > is to send a IGMP membership report message
> to
> > > > > AllSPFRouters and another to AllDRouters.
> Does
> > > > > anybody knows why ?? Does the router
> interface
> > > keeps
> > > > > a table including all of the member
> addresses of
> > > > > these multicast addresses ? Is there a
> mapping
> > > from
> > > > > the Ip multicast address to all of the
> destined
> > > mac
> > > > > addresses ?
> > > > >
> > > > > Thank you very much,
> > > > >
> > > > > Beatriz
> > > > > --
> > > > >
> > > >
> > >
> >
>
__________________________________________________________
> > > > > Sign-up for your own FREE Personalized
> E-mail at
> > > > > Mail.com
> > > > > http://www.mail.com/?sr=signup
> > > > >
>
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Jun 28 05:54:59 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16153
	for ; Fri, 28 Jun 2002 05:54:59 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0066E3A1@cherry.ease.lsoft.com>; Fri, 28 Jun 2002 5:55:41 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 14024 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 28 Jun 2002 05:55:40 -0400
Received: from 205.158.62.37 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 28 Jun 2002 05:55:40 -0400
Received: (qmail 48533 invoked by uid 1001); 28 Jun 2002 09:55:40 -0000
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-Mailer: MIME-tools 5.41 (Entity 5.404)
Received: from [129.187.222.168] by ws1-9.us4.outblaze.com with http for
          beatriz_hargrave@mail.com; Fri, 28 Jun 2002 04:55:40 -0500
X-Originating-Ip: 129.187.222.168
X-Originating-Server: ws1-9.us4.outblaze.com
Message-ID:  <20020628095540.48531.qmail@mail.com>
Date:         Fri, 28 Jun 2002 04:55:40 -0500
Reply-To: Mailing List 
Sender: Mailing List 
From: Beatriz Silva 
Subject: Re: Multicast addresses AllSPFRouters, AllDRouters
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Thanks Amir.

But I just have one more doubt...

In my scenario I do not have any multicast routers. Therefore, it would not be necessary to send a group join indiacation to the multicast address of the group. The normal routers I have and the host do not do anything with this message I guess. Am I right ?
And if there were a multicast router in my local network, would this join indication be sent to the ethernet multicast address of the group or directly to the mac address of the Multicast router ?

Thanks.

Beatriz


----- Original Message -----
From: Amit Srivastava 
Date:         Mon, 24 Jun 2002 05:10:00 -0700
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: Multicast addresses AllSPFRouters, AllDRouters


> Hi Beatriz,
>       The mac address that is sent(as destination) is
> the exact mapping of the multicast IP address.If you
> are using the Linux system then by default it supports
> Mac layer multicast support.
>             So if your destination IP is 224.0.0.5
> then your mac destination address will be 01 00 5e 00
> 00 05 in hex.
>        The IGMP group joining is sent as a rule for
> the IP multicaste which states that whenever you join
> any group of multicaste address you have to send a
> group join indiaction to your router.Study multicaste
> general protocol to make picture more clear.
> I hope i am clear!!
> Regards
> Amit
> --- Beatriz Silva  wrote:
> > Amit, thanks for the answer. But I still have some
> > doubts ...
> >
> > More specifically my question is:
> >
> > When a packet to AllSPFRouters is sent, what is the
> > MAC address written in the destination field of the
> > Ethernet header ? Is it a mac multicast address or
> > is there a mapping between the ip multicast address
> > and the mac addresses of all of the routers that
> > joined that multicast address ?
> > And what must be done in the router in order for it
> > to be capable to liste to packets to multicast
> > address AllSPFRouters and AllDRouters (if it is the
> > case) ?
> > Why does the router have to send an IGMP membership
> > report message to AllSPFaddress and to AllDRouters
> > multicast addresses ?
> >
> > I hope I am not too confusing ..
> >
> > Thank you,
> >
> > Beatriz
> > > > AllSPFRouters and another to AllDRouters
> > ----- Original Message -----
> > From: Amit Srivastava 
> > Date:         Mon, 24 Jun 2002 02:41:34 -0700
> > To: OSPF@DISCUSS.MICROSOFT.COM
> > Subject: Re: Multicast addresses AllSPFRouters,
> > AllDRouters
> >
> >
> > > Hi Beatriz.
> > >    As far as i could understand your problem the
> > > answer to it is:-
> > >            The Ip layer keeps a buffer(table) in
> > which
> > > it stores all the IP addresses it is listening
> > to.So
> > > when a packet is send on the net the Ip layer
> > would
> > > check the destination ip address from the buffer
> > it is
> > > holding and if the address is found then it will
> > give
> > > the packet to the other protocol otherwise it will
> > > discard the packet.
> > > Regards
> > > Amit
> > > --- Beatriz Silva 
> > wrote:
> > > > Hi !
> > > >
> > > > I realized that as soon as I put one of the
> > routers
> > > > interfaces up, one of the first things that is
> > done
> > > > is to send a IGMP membership report message to
> > > > AllSPFRouters and another to AllDRouters. Does
> > > > anybody knows why ?? Does the router interface
> > keeps
> > > > a table including all of the member addresses of
> > > > these multicast addresses ? Is there a mapping
> > from
> > > > the Ip multicast address to all of the destined
> > mac
> > > > addresses ?
> > > >
> > > > Thank you very much,
> > > >
> > > > Beatriz
> > > > --
> > > >
> > >
> >
> __________________________________________________________
> > > > Sign-up for your own FREE Personalized E-mail at
> > > > Mail.com
> > > > http://www.mail.com/?sr=signup
> > > >
> > > > Save up to $160 by signing up for NetZero
> > Platinum
> > > > Internet service.
> > > > http://www.netzero.net/?refcd=N2P0602NEP8
> > >
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Yahoo! - Official partner of 2002 FIFA World Cup
> > > http://fifaworldcup.yahoo.com
> > >
> >
> > --
> >
> __________________________________________________________
> > Sign-up for your own FREE Personalized E-mail at
> > Mail.com
> > http://www.mail.com/?sr=signup
> >
> > Save up to $160 by signing up for NetZero Platinum
> > Internet service.
> > http://www.netzero.net/?refcd=N2P0602NEP8
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com
>

--
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

Save up to $160 by signing up for NetZero Platinum Internet service.
http://www.netzero.net/?refcd=N2P0602NEP8


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Jun 28 07:29:16 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20311
	for ; Fri, 28 Jun 2002 07:29:16 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.0066E72B@cherry.ease.lsoft.com>; Fri, 28 Jun 2002 7:29:59 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 14649 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 28 Jun 2002 07:29:58 -0400
Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 28 Jun 2002 07:29:58 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service
          (5.5.2653.19) id ; Fri, 28 Jun 2002 07:29:57 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  
Date:         Fri, 28 Jun 2002 07:32:28 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: "Manral, Vishwas" 
Subject: Re: Extended Hitless OSPF Restart
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi Mitchell,

1. When something is not stated in a draft like the BDR operation, it means
there is no change in the way we need to work. John has stated in previous
mails.

2. It is assumed when the BDR or any other router isn't a helper, the
non-helper router would cause the hitless restart to exit when the
restarting router comes up. So the operation from there is the same as
specified in the base RFC.

3. The grace period will never be one hour(atleast as I see it).

4. I agree to the assumption that the DR is kept is not explicitly stated.
However in Section 2 it is stated that the restarting router will re-elect
itself the DR if it was the DR before restart. Also the assumption that a
high hitless restart interval would be of no use if we had a small router
dead interval in which we could not even send hellos and we broke
adjacencies because of that, can lead to the conclusion that we will not
break adjacencies.

5. As stated above we need to send a hello before the router dead interval,
so the router dead interval needs to be large enough that we are able to do
restart and send a hello even if we do not complete the hitless restart by
then.

Acee,

So would we want a different TLV for this, rather than a different reason(as
the times we are talking about are different. Point 5. above), if we assume
that the draft assumption of strict checking and not resetting the
inactivity timer.

Thanks,
Vishwas

-----Original Message-----
From: Erblichs [mailto:erblichs@EARTHLINK.NET]
Sent: Friday, June 28, 2002 12:18 AM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: Re: Extended Hitless OSPF Restart


Vishwas,

        Looooong....

        Here are what I percieve as real weaknesses in the two docs..

        Actually no it doesn't state that the DR is kept between restarts.
        It implicitly states that the DR is kept if the router was down for
        less than router dead interval. Actually down for time of ( router
        dead interval - waiting time) or less, by seeing a hello with the
        restart router being specified as the DR. But then there is a
conflicting
        statement, which I will point to later..

        And I am going blind, I see no mention of how a BDR is treated
        in either restart doc. So, it is unstated operation. What happens
        if the BDR is a helper, should it not re-elect itself due to
        section 3 as a helper to maintain the X router as the DR? If
        the BDR isn't a helper (router did not want to verify that the
        grace-LSAs were recieved), does the BDR then ignore the helper's
hellos
        (assuming that DRothers are helpers and the restart was the DR) sees
that
        there is no DR hellos, his router dead interval expires, and elect
himself?
        Now lets assume that the BDR came up after the DR, but really has
higher
        priority. Again the interaction is unspecified when the restart
router
        comes back. However, between the time that the BDR elected himself,
and
        the helpers keep the restart as the DR, we will have two DRs
specified
        in hellos... ummm Now to make things worse, a new router comes up
and
        looks for a DR and sees different routers, continually announcing
different
        routers as the DR..

        Justification for the problems are stated in long form below...

        Please note that point 1 below identifies a statement, identifies
        problems with it, and then sees that in point 2 a conflicting
        statement that implictly specifies increasing the
router-dead-interval
        to the grace interval.

        New Point 1
        ============

        Sect. 2 After the router restarts ...(3) If the restarting router...

        "an Hello packet is
           received from a neighbor listing the router as Designated
           Router."

        But if the restarting router is down for more than the dead router
        interval., will hellos still specifiy that the restarting router
        is the DR? They shouldn't. Why can't the router see that a DR
        is Y, and Y's hellos specify that its priority is Z, then specify
        its own priority as Z+1, and act that it is the DR. And force a
        re-election back to itself as the DR? Why wouldn't it want to do
        that? Should this last item be a "MAY", meaning a DR restarting
        for longer than router dead interval may relect itself by doing
        the following..

        Orig Doc,..
        If the restarting router is kept as the DR, then what happens to the
        routers that come up sometime
        before it re-elects itself? I am concerned most where a BDR doesn't
        exist. They are effectively dead. They can't form adjacencies until
        there is a live DR.

        This problem is worse with the "extended hitless" . Section 3.
Changes
        to helper neighbor operation

        Where the router dead interval is reset to the grace period....
Wow..
        What happens if that time is 1 hour and there is no BDR, and other
        routers come up, no adjs are formed. Why can't you just keep the
        original router dead interval time, mark the router in a restart
state,
        and if the router doesn't come back in say 1 hr, then cleanup..
Restart
        state says don't send him anything other than hellos, suspend your
        re-xmits to that router, etc...
        This would decrease the load on the routers that stay up.

        extend doc..If the restarting router is the DR.......
        At least there should be a BDR verified for the interfaces where
there
        there is a DR, else.. it should NOT be extended in my opinion. If
there
        is a BDR and the BDR goes down the helpers should revert to their
        previous dead interval times, and re-elect.
        extend doc.. And what happens to the negotiated hello dead interval
        time value with exchange of hellos pdus?


        New Point 2
        ================
        But after all of that...
        We know have a conflicting statement... of section 2... with
hellos..
        3. Operations of helper neighbor..

        "Also, if X was the Designated Router on network segment S when the
    helping relationship began, Y maintains X as Designated router until
    the helping relationship is terminated."

        This is for the grace period...

        Or does this implictly state that "dead router interval" is
automaticly
        extended to the grace period", by the helpers. IT should now be
sending
        hellos out with the restart system as the DR...

        If that was so, then why would the extended doc need to explicitly
        state that???????

        Why is there a conflict with the two docs..


        OLD POINTS
        ==================

        And back to a question that I had over a month ago.
        2.1 Entering hitless restart...

        "If Router X wants to ensure that its neighbors
        receive the grace-LSAs, it should retransmit the grace-LSAs
        until they are acknowledged (i.e, perform standard OSPF reliable
        flooding of the grace-LSAs). If one or more fully adjacent
        neighbors do not receive grace-LSAs, they will more than likely
        cause premature termination of the hitless restart procedure
        (see Section 4)."

        1st: Is "wants" a SHOULD, MUST, ...??


            Sub item
            ========
            Lets assume it is a must. What happens if just one nbr has a
late
ack?
            And now that the late ack, now shortens the time allocated for
            "requested grace period"? I assume he can extended it by
            "There is one exception to the above requirements. If Y was
            already helping X on the associated network segment, the new
            grace-LSA should be accepted and the grace period should be
            updated accordingly."
               ***But how does he withdraw it?
                   Should he send a grace-LSA with a grace-period of 0?


        2nd: Is "recieve", acked?

        This one paragraph is a conflict in itself.

        First if we see "wants" as
        a MUST, then we don't get acks from an adj nbr, then we prematurely
        terminate if we don't get back acks.

        2nd if we see "wants" as optional, and we don't verify that they
recv
        the grace-LSA, then then we we don't care that some systems are
unaware
        of what we are doing?

        If he thinks that all of our router neighbors should agree with us,
        and there is a router neighbor addition, then his implied statement
        should prematurely end the helper agreement? Else, not..

        So, what is he saying, again...
        If we look at section 4. Backward compatibility
        Then he states
        "If one or more
    neighbors of a router requesting hitless restart are unmodified, or
    if they do not received the grace-LSA, the hitless restart converts
    to a normal OSPF restart."

        Which is no longer a want... because of "recvieved the grace-LSAs"?
        *** But what happens if a router doesn't want to verify that his
grace-LSAs
        are recvd?



        Mitchell Erblich
        ==================



"Manral, Vishwas" wrote:
>
> Hi Mitchell,
>
> Please look at the draft
>
https://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-02.txt
> this draft clearly states the DR role stays after across a hitless
restart,
> while we do not keep the BDR role.
>
> As long as we do not reset adjacencies(neighbor change event) with the
> restarting router we will not do a DR election at all.
>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Erblichs [mailto:erblichs@EARTHLINK.NET]
> Sent: Thursday, June 27, 2002 2:04 AM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Re: Extended Hitless OSPF Restart
>
> Sorry group,
>
>         For this document...
>
>         For the restarting router.. If it was the DR or BDR, do
>         we keep him as the old DR/BDR or re-elect after router
>         dead interval?
>
>         Mitchell Erblich
>         ==================
>
> Erblichs wrote:
> >
> > Group,
> >
> >         This really goes back to the original doc..
> >
> >         Shouldn't there be a limit of say 1 hour for the grace period.
> >
> >         After that time, work that the proposed router's/helpers
> >         should almost ignore that the hitless restart functionality
> >         was originally requested and age out the LSAs that were
> >         originated by the by the restarting router.
> >
> >         Mitchell Erblich
> >         =======================
> >
> > Daniel Gryniewicz wrote:
> > >
> > > Hi.
> > >
> > > Could someone please explain to me why this is necessary?  My reading
of
> > > draft-ietf-ospf-hitless-restart-02 indicates that an implementation
> should
> > > *not* exit helper status because a router dead interval expired.
Please
> > > enlighten me.
> > >
> > > Daniel
> > >
> > > On Tue, 25 Jun 2002 19:51:32 -0700
> > > Acee Lindem  wrote:
> > >
> > > > FYI - Ultimately, this would be an informational RFC or better yet
> > > > folded into the base "OSPF Hitless Restart" specification (although
> > > > this has not been discussed as of yet).
> > > >
> > > > Thanks,
> > > > Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Jun 28 12:26:40 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04955
	for ; Fri, 28 Jun 2002 12:26:40 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0066EF7A@cherry.ease.lsoft.com>; Fri, 28 Jun 2002 12:27:24 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 16003 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 28 Jun 2002 12:27:24 -0400
Received: from 64.211.218.216 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Fri, 28 Jun 2002 12:27:23 -0400
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id
          g5SGRNV47303 for ospf@discuss.microsoft.com; Fri, 28 Jun 2002
          12:27:23 -0400 (EDT) (envelope-from dang@nexthop.com)
Received: from marvin.nexthop.com (dang.nexthop.com [64.211.218.29]) by
          presque.djinesys.com (8.11.3/8.11.1) with SMTP id g5SGRK947296 for
          ; Fri, 28 Jun 2002 12:27:20 -0400 (EDT)
          (envelope-from dang@nexthop.com)
References: 
X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS perl-11
Message-ID:  <20020628122720.37201668.dang@nexthop.com>
Date:         Fri, 28 Jun 2002 12:27:20 -0400
Reply-To: Mailing List 
Sender: Mailing List 
From: Daniel Gryniewicz 
Organization: Nexthop Technology
Subject: Re: Extended Hitless OSPF Restart
To: OSPF@DISCUSS.MICROSOFT.COM
In-Reply-To:  
Precedence: list
Content-Transfer-Encoding: 7bit

Hi.

The draft says:

    The helper relationship is per network segment.  As a "helper
    neighbor" on a segment S for a restarting router X, router Y has
    several duties. It monitors the network for topology changes, and as
    long as there are none, continues to its advertise its LSAs as if X
    had remained in continuous OSPF operation. This means that Y's LSAs
    continue to list an adjacency to X over network segment S,
    regardless of the adjacency's current synchronization state. This
    logic affects the contents of both router-LSAs and network-LSAs, and
    also depends on the type of network segment S (see Sections 12.4.1.1
    through 12.4.1.5 and Section 12.4.2 of [Ref1]). When helping over a
    virtual link, the helper must also continue to set bit V in its
    router-LSA for the virtual link's transit area (Section 12.4.1 of
    [Ref1]).

    Also, if X was the Designated Router on network segment S when the
    helping relationship began, Y maintains X as Designated router until
    the helping relationship is terminated.

This implies to me that the adjacency *SHOULD NOT TIME OUT* regardless of the
lack of hellos until the grace period is over.  Am I wrong in this?  If I'm
right, then the extension is unnessary.  If I'm wrong, the draft should
probably say so.  What I interpret a Grace LSA to mean is: "Put the adjacency
on hold for X seconds.  Please."  If you time out the adjacency, but don't
tell anyone, then do you un-time-out the adjacnecy when the router comes back
up?  Do you exit the helper mode when the hold timer expires even though the
grace timer has not expired?  That's a violation of the draft, certainly.

Daniel

On Fri, 28 Jun 2002 07:32:28 -0400
"Manral, Vishwas"  wrote:

> Hi Mitchell,
>
> 1. When something is not stated in a draft like the BDR operation, it means
> there is no change in the way we need to work. John has stated in previous
> mails.
>
> 2. It is assumed when the BDR or any other router isn't a helper, the
> non-helper router would cause the hitless restart to exit when the
> restarting router comes up. So the operation from there is the same as
> specified in the base RFC.
>
> 3. The grace period will never be one hour(atleast as I see it).
>
> 4. I agree to the assumption that the DR is kept is not explicitly stated.
> However in Section 2 it is stated that the restarting router will re-elect
> itself the DR if it was the DR before restart. Also the assumption that a
> high hitless restart interval would be of no use if we had a small router
> dead interval in which we could not even send hellos and we broke
> adjacencies because of that, can lead to the conclusion that we will not
> break adjacencies.
>
> 5. As stated above we need to send a hello before the router dead interval,
> so the router dead interval needs to be large enough that we are able to do
> restart and send a hello even if we do not complete the hitless restart by
> then.
>
> Acee,
>
> So would we want a different TLV for this, rather than a different reason(as
> the times we are talking about are different. Point 5. above), if we assume
> that the draft assumption of strict checking and not resetting the
> inactivity timer.
>
> Thanks,
> Vishwas
>
> -----Original Message-----
> From: Erblichs [mailto:erblichs@EARTHLINK.NET]
> Sent: Friday, June 28, 2002 12:18 AM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Re: Extended Hitless OSPF Restart
>
>
> Vishwas,
>
>         Looooong....
>
>         Here are what I percieve as real weaknesses in the two docs..
>
>         Actually no it doesn't state that the DR is kept between restarts.
>         It implicitly states that the DR is kept if the router was down for
>         less than router dead interval. Actually down for time of ( router
>         dead interval - waiting time) or less, by seeing a hello with the
>         restart router being specified as the DR. But then there is a
> conflicting
>         statement, which I will point to later..
>
>         And I am going blind, I see no mention of how a BDR is treated
>         in either restart doc. So, it is unstated operation. What happens
>         if the BDR is a helper, should it not re-elect itself due to
>         section 3 as a helper to maintain the X router as the DR? If
>         the BDR isn't a helper (router did not want to verify that the
>         grace-LSAs were recieved), does the BDR then ignore the helper's
> hellos
>         (assuming that DRothers are helpers and the restart was the DR) sees
> that
>         there is no DR hellos, his router dead interval expires, and elect
> himself?
>         Now lets assume that the BDR came up after the DR, but really has
> higher
>         priority. Again the interaction is unspecified when the restart
> router
>         comes back. However, between the time that the BDR elected himself,
> and
>         the helpers keep the restart as the DR, we will have two DRs
> specified
>         in hellos... ummm Now to make things worse, a new router comes up
> and
>         looks for a DR and sees different routers, continually announcing
> different
>         routers as the DR..
>
>         Justification for the problems are stated in long form below...
>
>         Please note that point 1 below identifies a statement, identifies
>         problems with it, and then sees that in point 2 a conflicting
>         statement that implictly specifies increasing the
> router-dead-interval
>         to the grace interval.
>
>         New Point 1
>         ============
>
>         Sect. 2 After the router restarts ...(3) If the restarting router...
>
>         "an Hello packet is
>            received from a neighbor listing the router as Designated
>            Router."
>
>         But if the restarting router is down for more than the dead router
>         interval., will hellos still specifiy that the restarting router
>         is the DR? They shouldn't. Why can't the router see that a DR
>         is Y, and Y's hellos specify that its priority is Z, then specify
>         its own priority as Z+1, and act that it is the DR. And force a
>         re-election back to itself as the DR? Why wouldn't it want to do
>         that? Should this last item be a "MAY", meaning a DR restarting
>         for longer than router dead interval may relect itself by doing
>         the following..
>
>         Orig Doc,..
>         If the restarting router is kept as the DR, then what happens to the
>         routers that come up sometime
>         before it re-elects itself? I am concerned most where a BDR doesn't
>         exist. They are effectively dead. They can't form adjacencies until
>         there is a live DR.
>
>         This problem is worse with the "extended hitless" . Section 3.
> Changes
>         to helper neighbor operation
>
>         Where the router dead interval is reset to the grace period....
> Wow..
>         What happens if that time is 1 hour and there is no BDR, and other
>         routers come up, no adjs are formed. Why can't you just keep the
>         original router dead interval time, mark the router in a restart
> state,
>         and if the router doesn't come back in say 1 hr, then cleanup..
> Restart
>         state says don't send him anything other than hellos, suspend your
>         re-xmits to that router, etc...
>         This would decrease the load on the routers that stay up.
>
>         extend doc..If the restarting router is the DR.......
>         At least there should be a BDR verified for the interfaces where
> there
>         there is a DR, else.. it should NOT be extended in my opinion. If
> there
>         is a BDR and the BDR goes down the helpers should revert to their
>         previous dead interval times, and re-elect.
>         extend doc.. And what happens to the negotiated hello dead interval
>         time value with exchange of hellos pdus?
>
>
>         New Point 2
>         ================
>         But after all of that...
>         We know have a conflicting statement... of section 2... with
> hellos..
>         3. Operations of helper neighbor..
>
>         "Also, if X was the Designated Router on network segment S when the
>     helping relationship began, Y maintains X as Designated router until
>     the helping relationship is terminated."
>
>         This is for the grace period...
>
>         Or does this implictly state that "dead router interval" is
> automaticly
>         extended to the grace period", by the helpers. IT should now be
> sending
>         hellos out with the restart system as the DR...
>
>         If that was so, then why would the extended doc need to explicitly
>         state that???????
>
>         Why is there a conflict with the two docs..
>
>
>         OLD POINTS
>         ==================
>
>         And back to a question that I had over a month ago.
>         2.1 Entering hitless restart...
>
>         "If Router X wants to ensure that its neighbors
>         receive the grace-LSAs, it should retransmit the grace-LSAs
>         until they are acknowledged (i.e, perform standard OSPF reliable
>         flooding of the grace-LSAs). If one or more fully adjacent
>         neighbors do not receive grace-LSAs, they will more than likely
>         cause premature termination of the hitless restart procedure
>         (see Section 4)."
>
>         1st: Is "wants" a SHOULD, MUST, ...??
>
>
>             Sub item
>             ========
>             Lets assume it is a must. What happens if just one nbr has a
> late
> ack?
>             And now that the late ack, now shortens the time allocated for
>             "requested grace period"? I assume he can extended it by
>             "There is one exception to the above requirements. If Y was
>             already helping X on the associated network segment, the new
>             grace-LSA should be accepted and the grace period should be
>             updated accordingly."
>                ***But how does he withdraw it?
>                    Should he send a grace-LSA with a grace-period of 0?
>
>
>         2nd: Is "recieve", acked?
>
>         This one paragraph is a conflict in itself.
>
>         First if we see "wants" as
>         a MUST, then we don't get acks from an adj nbr, then we prematurely
>         terminate if we don't get back acks.
>
>         2nd if we see "wants" as optional, and we don't verify that they
> recv
>         the grace-LSA, then then we we don't care that some systems are
> unaware
>         of what we are doing?
>
>         If he thinks that all of our router neighbors should agree with us,
>         and there is a router neighbor addition, then his implied statement
>         should prematurely end the helper agreement? Else, not..
>
>         So, what is he saying, again...
>         If we look at section 4. Backward compatibility
>         Then he states
>         "If one or more
>     neighbors of a router requesting hitless restart are unmodified, or
>     if they do not received the grace-LSA, the hitless restart converts
>     to a normal OSPF restart."
>
>         Which is no longer a want... because of "recvieved the grace-LSAs"?
>         *** But what happens if a router doesn't want to verify that his
> grace-LSAs
>         are recvd?
>
>
>
>         Mitchell Erblich
>         ==================
>
>
>
> "Manral, Vishwas" wrote:
> >
> > Hi Mitchell,
> >
> > Please look at the draft
> >
> https://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-02.txt
> > this draft clearly states the DR role stays after across a hitless
> restart,
> > while we do not keep the BDR role.
> >
> > As long as we do not reset adjacencies(neighbor change event) with the
> > restarting router we will not do a DR election at all.
> >
> > Thanks,
> > Vishwas
> >
> > -----Original Message-----
> > From: Erblichs [mailto:erblichs@EARTHLINK.NET]
> > Sent: Thursday, June 27, 2002 2:04 AM
> > To: OSPF@DISCUSS.MICROSOFT.COM
> > Subject: Re: Extended Hitless OSPF Restart
> >
> > Sorry group,
> >
> >         For this document...
> >
> >         For the restarting router.. If it was the DR or BDR, do
> >         we keep him as the old DR/BDR or re-elect after router
> >         dead interval?
> >
> >         Mitchell Erblich
> >         ==================
> >
> > Erblichs wrote:
> > >
> > > Group,
> > >
> > >         This really goes back to the original doc..
> > >
> > >         Shouldn't there be a limit of say 1 hour for the grace period.
> > >
> > >         After that time, work that the proposed router's/helpers
> > >         should almost ignore that the hitless restart functionality
> > >         was originally requested and age out the LSAs that were
> > >         originated by the by the restarting router.
> > >
> > >         Mitchell Erblich
> > >         =======================
> > >
> > > Daniel Gryniewicz wrote:
> > > >
> > > > Hi.
> > > >
> > > > Could someone please explain to me why this is necessary?  My reading
> of
> > > > draft-ietf-ospf-hitless-restart-02 indicates that an implementation
> > should
> > > > *not* exit helper status because a router dead interval expired.
> Please
> > > > enlighten me.
> > > >
> > > > Daniel
> > > >
> > > > On Tue, 25 Jun 2002 19:51:32 -0700
> > > > Acee Lindem  wrote:
> > > >
> > > > > FYI - Ultimately, this would be an informational RFC or better yet
> > > > > folded into the base "OSPF Hitless Restart" specification (although
> > > > > this has not been discussed as of yet).
> > > > >
> > > > > Thanks,
> > > > > Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Jun 28 12:27:11 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04983
	for ; Fri, 28 Jun 2002 12:27:10 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0066EF86@cherry.ease.lsoft.com>; Fri, 28 Jun 2002 12:27:55 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 16027 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 28 Jun 2002 12:27:55 -0400
Received: from 66.122.42.228 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 28 Jun 2002 12:27:54 -0400
Received: from sanjose.futsoft.com (unverified) by fcs-nt1.futsoft.com (Content
          Technologies SMTPRS 2.0.15) with SMTP id
           for ;
          Fri, 28 Jun 2002 09:27:28 -0700
Received: from fcslabmc4 (adsl-66-122-42-243.futsoft.com [66.122.42.243] (may
          be forged)) by sanjose.futsoft.com (8.9.3/8.8.7) with SMTP id
          IAA13192 for ; Fri, 28 Jun 2002 08:09:24
          -0700
References:  <20020628082403.95665.qmail@web40311.mail.yahoo.com>
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-ID:  <024f01c21ec0$d1c1fa60$030110ac@futsoft.com>
Date:         Fri, 28 Jun 2002 09:28:20 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Samvid Shah 
Subject: Re: Multicast addresses AllSPFRouters, AllDRouters
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Hi ,
  as per my understanding,  on virtual links packets are sent as unicasts.

  I am also attaching part of RFC 2328 section 8.1  Sending protocol
packets.

"The IP destination address for the packet is selected as
        follows.  On physical point-to-point networks, the IP
        destination is always set to the address AllSPFRouters.  On all
        other network types (including virtual links), the majority of
        OSPF packets are sent as unicasts, i.e., sent directly to the
        other end of the adjacency. "

  Thanks.
                          -Samvid

----- Original Message -----
From: "Amit Srivastava" 
To: 
Sent: Friday, June 28, 2002 1:24 AM
Subject: Re: Multicast addresses AllSPFRouters, AllDRouters


> Hi samvid!!
>       When you say that all the ospf packet do not
> travel more than one hop away then i think you are not
> considering the virtual links!!!
>              Plz think on that aspect and the picture
> would be more clear!!
> Regards
> Amit
>
> --- Samvid Shah  wrote:
> > Hi Group,
> >         Sorry for the late reply.
> >
> >         my 2 cents to this discussion.
> >
> >         first regarding mapping IP address to MAC
> > address,
> >         as per RFC 1112
> >         "An IP host group address is mapped to an
> > Ethernet multicast address
> >    by placing the low-order 23-bits of the IP
> > address into the low-order
> >    23 bits of the Ethernet multicast address
> > 01-00-5E-00-00-00 (hex).
> >    Because there are 28 significant bits in an IP
> > host group address,
> >    more than one host group address may map to the
> > same Ethernet
> >    multicast address."
> >
> >        now coming to membership reports generated by
> > OSPF router,
> >        as per RFC 2328, section 4.4 (page 44)
> >
> >        "IP multicast
> >             Certain OSPF packets take the form of IP
> > multicast
> >             datagrams.  Support for receiving and
> > sending IP multicast
> >             datagrams, along with the appropriate
> > lower-level protocol
> >             support, is required.  The IP multicast
> > datagrams used by
> >             OSPF never travel more than one hop. For
> > this reason, the
> >             ability to forward IP multicast
> > datagrams is not required.
> >             For information on IP multicast, see
> > [Ref7]."
> >
> >        since, IGMP (along with multicast routing
> > protocols) is typically
> > used for multicast data transfer across multiple
> > hops,  I think It is not
> > required to send group memberships for allSPFRouters
> >  and allDRouters .
> > Also, since  IGMP is designed for interactions
> > between host and router,   I
> > think, sending membership report  is not required.
> >
> >         but if your question is,
> >                   if by sending this membership
> > report, are we breaking any
> > thing here ?
> >
> >                   I have to say , I could not find
> > any reference that says
> > IGMP membership report *must not* be sent by OSPF
> > router. (May be more
> > knowledgeable soul can throw a light here.)
> >
> >       Thanks.
> >                                -Samvid
> >
> > ----- Original Message -----
> > From: "Amit Srivastava" 
> > To: 
> > Sent: Monday, June 24, 2002 5:10 AM
> > Subject: Re: Multicast addresses AllSPFRouters,
> > AllDRouters
> >
> >
> > > Hi Beatriz,
> > >       The mac address that is sent(as destination)
> > is
> > > the exact mapping of the multicast IP address.If
> > you
> > > are using the Linux system then by default it
> > supports
> > > Mac layer multicast support.
> > >             So if your destination IP is 224.0.0.5
> > > then your mac destination address will be 01 00 5e
> > 00
> > > 00 05 in hex.
> > >        The IGMP group joining is sent as a rule
> > for
> > > the IP multicaste which states that whenever you
> > join
> > > any group of multicaste address you have to send a
> > > group join indiaction to your router.Study
> > multicaste
> > > general protocol to make picture more clear.
> > > I hope i am clear!!
> > > Regards
> > > Amit
> > > --- Beatriz Silva 
> > wrote:
> > > > Amit, thanks for the answer. But I still have
> > some
> > > > doubts ...
> > > >
> > > > More specifically my question is:
> > > >
> > > > When a packet to AllSPFRouters is sent, what is
> > the
> > > > MAC address written in the destination field of
> > the
> > > > Ethernet header ? Is it a mac multicast address
> > or
> > > > is there a mapping between the ip multicast
> > address
> > > > and the mac addresses of all of the routers that
> > > > joined that multicast address ?
> > > > And what must be done in the router in order for
> > it
> > > > to be capable to liste to packets to multicast
> > > > address AllSPFRouters and AllDRouters (if it is
> > the
> > > > case) ?
> > > > Why does the router have to send an IGMP
> > membership
> > > > report message to AllSPFaddress and to
> > AllDRouters
> > > > multicast addresses ?
> > > >
> > > > I hope I am not too confusing ..
> > > >
> > > > Thank you,
> > > >
> > > > Beatriz
> > > > > > AllSPFRouters and another to AllDRouters
> > > > ----- Original Message -----
> > > > From: Amit Srivastava 
> > > > Date:         Mon, 24 Jun 2002 02:41:34 -0700
> > > > To: OSPF@DISCUSS.MICROSOFT.COM
> > > > Subject: Re: Multicast addresses AllSPFRouters,
> > > > AllDRouters
> > > >
> > > >
> > > > > Hi Beatriz.
> > > > >    As far as i could understand your problem
> > the
> > > > > answer to it is:-
> > > > >            The Ip layer keeps a buffer(table)
> > in
> > > > which
> > > > > it stores all the IP addresses it is listening
> > > > to.So
> > > > > when a packet is send on the net the Ip layer
> > > > would
> > > > > check the destination ip address from the
> > buffer
> > > > it is
> > > > > holding and if the address is found then it
> > will
> > > > give
> > > > > the packet to the other protocol otherwise it
> > will
> > > > > discard the packet.
> > > > > Regards
> > > > > Amit
> > > > > --- Beatriz Silva 
> > > > wrote:
> > > > > > Hi !
> > > > > >
> > > > > > I realized that as soon as I put one of the
> > > > routers
> > > > > > interfaces up, one of the first things that
> > is
> > > > done
> > > > > > is to send a IGMP membership report message
> > to
> > > > > > AllSPFRouters and another to AllDRouters.
> > Does
> > > > > > anybody knows why ?? Does the router
> > interface
> > > > keeps
> > > > > > a table including all of the member
> > addresses of
> > > > > > these multicast addresses ? Is there a
> > mapping
> > > > from
> > > > > > the Ip multicast address to all of the
> > destined
> > > > mac
> > > > > > addresses ?
> > > > > >
> > > > > > Thank you very much,
> > > > > >
> > > > > > Beatriz
> > > > > > --
> > > > > >
> > > > >
> > > >
> > >
> >
> __________________________________________________________
> > > > > > Sign-up for your own FREE Personalized
> > E-mail at
> > > > > > Mail.com
> > > > > > http://www.mail.com/?sr=signup
> > > > > >
> >
> === message truncated ===
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com
>


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Jun 28 19:18:13 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27835
	for ; Fri, 28 Jun 2002 19:18:12 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.0066F59D@cherry.ease.lsoft.com>; Fri, 28 Jun 2002 19:18:55 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 17184 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 28 Jun 2002 19:18:54 -0400
Received: from 207.217.120.232 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Fri, 28 Jun 2002 19:18:54 -0400
Received: from user-2ivfk54.dialup.mindspring.com ([165.247.208.164]
          helo=earthlink.net) by flamingo.mail.pas.earthlink.net with esmtp
          (Exim 3.33 #2) id 17O50r-0006z0-00 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 28 Jun 2002 16:18:50 -0700
X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified)
X-Mailer: Mozilla 4.72 [en]C-gatewaynet  (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
            <20020628122720.37201668.dang@nexthop.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D1CF139.614B312A@earthlink.net>
Date:         Fri, 28 Jun 2002 16:28:57 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Erblichs 
Subject: Re: Extended Hitless OSPF Restart
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Daniel,

        I completely agree with Daniel's statement that the extension is
        unnecessary..

        However, "the helping relationship" could be considered
        ambiguous..

        Vishwas,

        1) Yes. I understand that was the orignal intent.

        However, if
        we go back into the "wants" wording of that one section. And
        the restarting router does not want, and the BDR does not
        acknowledge, then the BDR after not seeing hellos from the
        DR will do a re-election. In my opinion, if I understand the
        doc, wants should be changed to a MUST and if all neigbors
        (full adjs) do not ack, then the hitless restart must be
        terminated...

        2) No. Again, if the restart router does not "want". Please
          READ what it says in section 2.1, with the line "If
        Router X wants to ensure that .... Then the BDR does
        not have to ack the grace-LSAs..

        If we look at section 4, we don't know if the grace-LSA
        was ever recv'd because we could have gone down before
        we recv'd the ack. Because we didn't want to re-xmit.

        If the restart router restarts before the router-dead interval has
        expired, then the section's 4, will still be valid. And
        we will still see the the links to X. See section 4. So,
        again, this invalidates the requirement of it being a
        required helper.

        3) What.... The only limit is... 3.1 Local policy..
          "b) never allow the grace period to exceed", how
          many bits do we have to specify a grace period?
          Where does the grace-LSA's TLV limit us to 1 hr
          as a magical value? I see 4 bytes of length specified
          as a limit for the grace period. I think that limit
          is bit more than 1hr...


        4. skip 4.. You agree... :-)

        5). Nooo... "this goes back to the understanding of
           "the helping relationship". I see it for the
           full grace period of a max 32 bits of seconds.
           Years... I just asked to limit it to 1 hr..
           So, a length of 2 bytes should be more than
           sufficent as a max of I think 18 hours or so..

        Mitchell Erblich
        ================================


Daniel Gryniewicz wrote:
>
> Hi.
>
> The draft says:
>
>     The helper relationship is per network segment.  As a "helper
>     neighbor" on a segment S for a restarting router X, router Y has
>     several duties. It monitors the network for topology changes, and as
>     long as there are none, continues to its advertise its LSAs as if X
>     had remained in continuous OSPF operation. This means that Y's LSAs
>     continue to list an adjacency to X over network segment S,
>     regardless of the adjacency's current synchronization state. This
>     logic affects the contents of both router-LSAs and network-LSAs, and
>     also depends on the type of network segment S (see Sections 12.4.1.1
>     through 12.4.1.5 and Section 12.4.2 of [Ref1]). When helping over a
>     virtual link, the helper must also continue to set bit V in its
>     router-LSA for the virtual link's transit area (Section 12.4.1 of
>     [Ref1]).
>
>     Also, if X was the Designated Router on network segment S when the
>     helping relationship began, Y maintains X as Designated router until
>     the helping relationship is terminated.
>
> This implies to me that the adjacency *SHOULD NOT TIME OUT* regardless of the
> lack of hellos until the grace period is over.  Am I wrong in this?  If I'm
> right, then the extension is unnessary.  If I'm wrong, the draft should
> probably say so.  What I interpret a Grace LSA to mean is: "Put the adjacency
> on hold for X seconds.  Please."  If you time out the adjacency, but don't
> tell anyone, then do you un-time-out the adjacnecy when the router comes back
> up?  Do you exit the helper mode when the hold timer expires even though the
> grace timer has not expired?  That's a violation of the draft, certainly.
>
> Daniel
>
> On Fri, 28 Jun 2002 07:32:28 -0400
> "Manral, Vishwas"  wrote:
>
> > Hi Mitchell,
> >
> > 1. When something is not stated in a draft like the BDR operation, it means
> > there is no change in the way we need to work. John has stated in previous
> > mails.
> >
> > 2. It is assumed when the BDR or any other router isn't a helper, the
> > non-helper router would cause the hitless restart to exit when the
> > restarting router comes up. So the operation from there is the same as
> > specified in the base RFC.
> >
> > 3. The grace period will never be one hour(atleast as I see it).
> >
> > 4. I agree to the assumption that the DR is kept is not explicitly stated.
> > However in Section 2 it is stated that the restarting router will re-elect
> > itself the DR if it was the DR before restart. Also the assumption that a
> > high hitless restart interval would be of no use if we had a small router
> > dead interval in which we could not even send hellos and we broke
> > adjacencies because of that, can lead to the conclusion that we will not
> > break adjacencies.
> >
> > 5. As stated above we need to send a hello before the router dead interval,
> > so the router dead interval needs to be large enough that we are able to do
> > restart and send a hello even if we do not complete the hitless restart by
> > then.
> >
> > Acee,
> >
> > So would we want a different TLV for this, rather than a different reason(as
> > the times we are talking about are different. Point 5. above), if we assume
> > that the draft assumption of strict checking and not resetting the
> > inactivity timer.
> >
> > Thanks,
> > Vishwas
> >
> > -----Original Message-----
> > From: Erblichs [mailto:erblichs@EARTHLINK.NET]
> > Sent: Friday, June 28, 2002 12:18 AM
> > To: OSPF@DISCUSS.MICROSOFT.COM
> > Subject: Re: Extended Hitless OSPF Restart
> >
> >
> > Vishwas,
> >
> >         Looooong....
> >
> >         Here are what I percieve as real weaknesses in the two docs..
> >
> >         Actually no it doesn't state that the DR is kept between restarts.
> >         It implicitly states that the DR is kept if the router was down for
> >         less than router dead interval. Actually down for time of ( router
> >         dead interval - waiting time) or less, by seeing a hello with the
> >         restart router being specified as the DR. But then there is a
> > conflicting
> >         statement, which I will point to later..
> >
> >         And I am going blind, I see no mention of how a BDR is treated
> >         in either restart doc. So, it is unstated operation. What happens
> >         if the BDR is a helper, should it not re-elect itself due to
> >         section 3 as a helper to maintain the X router as the DR? If
> >         the BDR isn't a helper (router did not want to verify that the
> >         grace-LSAs were recieved), does the BDR then ignore the helper's
> > hellos
> >         (assuming that DRothers are helpers and the restart was the DR) sees
> > that
> >         there is no DR hellos, his router dead interval expires, and elect
> > himself?
> >         Now lets assume that the BDR came up after the DR, but really has
> > higher
> >         priority. Again the interaction is unspecified when the restart
> > router
> >         comes back. However, between the time that the BDR elected himself,
> > and
> >         the helpers keep the restart as the DR, we will have two DRs
> > specified
> >         in hellos... ummm Now to make things worse, a new router comes up
> > and
> >         looks for a DR and sees different routers, continually announcing
> > different
> >         routers as the DR..
> >
> >         Justification for the problems are stated in long form below...
> >
> >         Please note that point 1 below identifies a statement, identifies
> >         problems with it, and then sees that in point 2 a conflicting
> >         statement that implictly specifies increasing the
> > router-dead-interval
> >         to the grace interval.
> >
> >         New Point 1
> >         ============
> >
> >         Sect. 2 After the router restarts ...(3) If the restarting router...
> >
> >         "an Hello packet is
> >            received from a neighbor listing the router as Designated
> >            Router."
> >
> >         But if the restarting router is down for more than the dead router
> >         interval., will hellos still specifiy that the restarting router
> >         is the DR? They shouldn't. Why can't the router see that a DR
> >         is Y, and Y's hellos specify that its priority is Z, then specify
> >         its own priority as Z+1, and act that it is the DR. And force a
> >         re-election back to itself as the DR? Why wouldn't it want to do
> >         that? Should this last item be a "MAY", meaning a DR restarting
> >         for longer than router dead interval may relect itself by doing
> >         the following..
> >
> >         Orig Doc,..
> >         If the restarting router is kept as the DR, then what happens to the
> >         routers that come up sometime
> >         before it re-elects itself? I am concerned most where a BDR doesn't
> >         exist. They are effectively dead. They can't form adjacencies until
> >         there is a live DR.
> >
> >         This problem is worse with the "extended hitless" . Section 3.
> > Changes
> >         to helper neighbor operation
> >
> >         Where the router dead interval is reset to the grace period....
> > Wow..
> >         What happens if that time is 1 hour and there is no BDR, and other
> >         routers come up, no adjs are formed. Why can't you just keep the
> >         original router dead interval time, mark the router in a restart
> > state,
> >         and if the router doesn't come back in say 1 hr, then cleanup..
> > Restart
> >         state says don't send him anything other than hellos, suspend your
> >         re-xmits to that router, etc...
> >         This would decrease the load on the routers that stay up.
> >
> >         extend doc..If the restarting router is the DR.......
> >         At least there should be a BDR verified for the interfaces where
> > there
> >         there is a DR, else.. it should NOT be extended in my opinion. If
> > there
> >         is a BDR and the BDR goes down the helpers should revert to their
> >         previous dead interval times, and re-elect.
> >         extend doc.. And what happens to the negotiated hello dead interval
> >         time value with exchange of hellos pdus?
> >
> >
> >         New Point 2
> >         ================
> >         But after all of that...
> >         We know have a conflicting statement... of section 2... with
> > hellos..
> >         3. Operations of helper neighbor..
> >
> >         "Also, if X was the Designated Router on network segment S when the
> >     helping relationship began, Y maintains X as Designated router until
> >     the helping relationship is terminated."
> >
> >         This is for the grace period...
> >
> >         Or does this implictly state that "dead router interval" is
> > automaticly
> >         extended to the grace period", by the helpers. IT should now be
> > sending
> >         hellos out with the restart system as the DR...
> >
> >         If that was so, then why would the extended doc need to explicitly
> >         state that???????
> >
> >         Why is there a conflict with the two docs..
> >
> >
> >         OLD POINTS
> >         ==================
> >
> >         And back to a question that I had over a month ago.
> >         2.1 Entering hitless restart...
> >
> >         "If Router X wants to ensure that its neighbors
> >         receive the grace-LSAs, it should retransmit the grace-LSAs
> >         until they are acknowledged (i.e, perform standard OSPF reliable
> >         flooding of the grace-LSAs). If one or more fully adjacent
> >         neighbors do not receive grace-LSAs, they will more than likely
> >         cause premature termination of the hitless restart procedure
> >         (see Section 4)."
> >
> >         1st: Is "wants" a SHOULD, MUST, ...??
> >
> >
> >             Sub item
> >             ========
> >             Lets assume it is a must. What happens if just one nbr has a
> > late
> > ack?
> >             And now that the late ack, now shortens the time allocated for
> >             "requested grace period"? I assume he can extended it by
> >             "There is one exception to the above requirements. If Y was
> >             already helping X on the associated network segment, the new
> >             grace-LSA should be accepted and the grace period should be
> >             updated accordingly."
> >                ***But how does he withdraw it?
> >                    Should he send a grace-LSA with a grace-period of 0?
> >
> >
> >         2nd: Is "recieve", acked?
> >
> >         This one paragraph is a conflict in itself.
> >
> >         First if we see "wants" as
> >         a MUST, then we don't get acks from an adj nbr, then we prematurely
> >         terminate if we don't get back acks.
> >
> >         2nd if we see "wants" as optional, and we don't verify that they
> > recv
> >         the grace-LSA, then then we we don't care that some systems are
> > unaware
> >         of what we are doing?
> >
> >         If he thinks that all of our router neighbors should agree with us,
> >         and there is a router neighbor addition, then his implied statement
> >         should prematurely end the helper agreement? Else, not..
> >
> >         So, what is he saying, again...
> >         If we look at section 4. Backward compatibility
> >         Then he states
> >         "If one or more
> >     neighbors of a router requesting hitless restart are unmodified, or
> >     if they do not received the grace-LSA, the hitless restart converts
> >     to a normal OSPF restart."
> >
> >         Which is no longer a want... because of "recvieved the grace-LSAs"?
> >         *** But what happens if a router doesn't want to verify that his
> > grace-LSAs
> >         are recvd?
> >
> >
> >
> >         Mitchell Erblich
> >         ==================
> >
> >
> >
> > "Manral, Vishwas" wrote:
> > >
> > > Hi Mitchell,
> > >
> > > Please look at the draft
> > >
> > https://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-02.txt
> > > this draft clearly states the DR role stays after across a hitless
> > restart,
> > > while we do not keep the BDR role.
> > >
> > > As long as we do not reset adjacencies(neighbor change event) with the
> > > restarting router we will not do a DR election at all.
> > >
> > > Thanks,
> > > Vishwas
> > >
> > > -----Original Message-----
> > > From: Erblichs [mailto:erblichs@EARTHLINK.NET]
> > > Sent: Thursday, June 27, 2002 2:04 AM
> > > To: OSPF@DISCUSS.MICROSOFT.COM
> > > Subject: Re: Extended Hitless OSPF Restart
> > >
> > > Sorry group,
> > >
> > >         For this document...
> > >
> > >         For the restarting router.. If it was the DR or BDR, do
> > >         we keep him as the old DR/BDR or re-elect after router
> > >         dead interval?
> > >
> > >         Mitchell Erblich
> > >         ==================
> > >
> > > Erblichs wrote:
> > > >
> > > > Group,
> > > >
> > > >         This really goes back to the original doc..
> > > >
> > > >         Shouldn't there be a limit of say 1 hour for the grace period.
> > > >
> > > >         After that time, work that the proposed router's/helpers
> > > >         should almost ignore that the hitless restart functionality
> > > >         was originally requested and age out the LSAs that were
> > > >         originated by the by the restarting router.
> > > >
> > > >         Mitchell Erblich
> > > >         =======================
> > > >
> > > > Daniel Gryniewicz wrote:
> > > > >
> > > > > Hi.
> > > > >
> > > > > Could someone please explain to me why this is necessary?  My reading
> > of
> > > > > draft-ietf-ospf-hitless-restart-02 indicates that an implementation
> > > should
> > > > > *not* exit helper status because a router dead interval expired.
> > Please
> > > > > enlighten me.
> > > > >
> > > > > Daniel
> > > > >
> > > > > On Tue, 25 Jun 2002 19:51:32 -0700
> > > > > Acee Lindem  wrote:
> > > > >
> > > > > > FYI - Ultimately, this would be an informational RFC or better yet
> > > > > > folded into the base "OSPF Hitless Restart" specification (although
> > > > > > this has not been discussed as of yet).
> > > > > >
> > > > > > Thanks,
> > > > > > Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Fri Jun 28 19:37:11 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28566
	for ; Fri, 28 Jun 2002 19:37:10 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.0066F719@cherry.ease.lsoft.com>; Fri, 28 Jun 2002 19:37:53 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 17231 for OSPF@DISCUSS.MICROSOFT.COM;
          Fri, 28 Jun 2002 19:37:53 -0400
Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with
          TCP; Fri, 28 Jun 2002 19:37:53 -0400
Received: from redback.com (jagged.redback.com [155.53.36.195]) by
          prattle.redback.com (Postfix) with ESMTP id 45F6539B5BF for
          ; Fri, 28 Jun 2002 16:37:52 -0700 (PDT)
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.0.38 i386)
X-Accept-Language: en
MIME-Version: 1.0
References: 
            <20020628122720.37201668.dang@nexthop.com>
            <3D1CF139.614B312A@earthlink.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3D1CF350.B0F41BC3@redback.com>
Date:         Fri, 28 Jun 2002 16:37:52 -0700
Reply-To: Mailing List 
Sender: Mailing List 
From: Acee Lindem 
Organization: Redback Networks, Inc
Subject: Re: Extended Hitless OSPF Restart
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
Content-Transfer-Encoding: 7bit

Daniel, Michell,

I'll take a look at John's public domain implementation to see
what he does. Perhaps, the intent is to allow the neighbor
relationship to go all the way down but preserve the
neighbor and continue advertising it as if it were full. If that is
the case,  I agree that it is unnecessary. I will probably maintain
the local policy to allow one to configure helper mode rejection if
the grace-period strictly exceeds the router-dead interval.

Thanks,
Acee

Erblichs wrote:
>
> Daniel,
>
>         I completely agree with Daniel's statement that the extension is
>         unnecessary..
>
>         However, "the helping relationship" could be considered
>         ambiguous..
>
>         Vishwas,
>
>         1) Yes. I understand that was the orignal intent.
>
>         However, if
>         we go back into the "wants" wording of that one section. And
>         the restarting router does not want, and the BDR does not
>         acknowledge, then the BDR after not seeing hellos from the
>         DR will do a re-election. In my opinion, if I understand the
>         doc, wants should be changed to a MUST and if all neigbors
>         (full adjs) do not ack, then the hitless restart must be
>         terminated...
>
>         2) No. Again, if the restart router does not "want". Please
>           READ what it says in section 2.1, with the line "If
>         Router X wants to ensure that .... Then the BDR does
>         not have to ack the grace-LSAs..
>
>         If we look at section 4, we don't know if the grace-LSA
>         was ever recv'd because we could have gone down before
>         we recv'd the ack. Because we didn't want to re-xmit.
>
>         If the restart router restarts before the router-dead interval has
>         expired, then the section's 4, will still be valid. And
>         we will still see the the links to X. See section 4. So,
>         again, this invalidates the requirement of it being a
>         required helper.
>
>         3) What.... The only limit is... 3.1 Local policy..
>           "b) never allow the grace period to exceed", how
>           many bits do we have to specify a grace period?
>           Where does the grace-LSA's TLV limit us to 1 hr
>           as a magical value? I see 4 bytes of length specified
>           as a limit for the grace period. I think that limit
>           is bit more than 1hr...
>
>         4. skip 4.. You agree... :-)
>
>         5). Nooo... "this goes back to the understanding of
>            "the helping relationship". I see it for the
>            full grace period of a max 32 bits of seconds.
>            Years... I just asked to limit it to 1 hr..
>            So, a length of 2 bytes should be more than
>            sufficent as a max of I think 18 hours or so..
>
>         Mitchell Erblich
>         ================================
>
> Daniel Gryniewicz wrote:
> >
> > Hi.
> >
> > The draft says:
> >
> >     The helper relationship is per network segment.  As a "helper
> >     neighbor" on a segment S for a restarting router X, router Y has
> >     several duties. It monitors the network for topology changes, and as
> >     long as there are none, continues to its advertise its LSAs as if X
> >     had remained in continuous OSPF operation. This means that Y's LSAs
> >     continue to list an adjacency to X over network segment S,
> >     regardless of the adjacency's current synchronization state. This
> >     logic affects the contents of both router-LSAs and network-LSAs, and
> >     also depends on the type of network segment S (see Sections 12.4.1.1
> >     through 12.4.1.5 and Section 12.4.2 of [Ref1]). When helping over a
> >     virtual link, the helper must also continue to set bit V in its
> >     router-LSA for the virtual link's transit area (Section 12.4.1 of
> >     [Ref1]).
> >
> >     Also, if X was the Designated Router on network segment S when the
> >     helping relationship began, Y maintains X as Designated router until
> >     the helping relationship is terminated.
> >
> > This implies to me that the adjacency *SHOULD NOT TIME OUT* regardless of the
> > lack of hellos until the grace period is over.  Am I wrong in this?  If I'm
> > right, then the extension is unnessary.  If I'm wrong, the draft should
> > probably say so.  What I interpret a Grace LSA to mean is: "Put the adjacency
> > on hold for X seconds.  Please."  If you time out the adjacency, but don't
> > tell anyone, then do you un-time-out the adjacnecy when the router comes back
> > up?  Do you exit the helper mode when the hold timer expires even though the
> > grace timer has not expired?  That's a violation of the draft, certainly.
> >
> > Daniel
> >
> > On Fri, 28 Jun 2002 07:32:28 -0400
> > "Manral, Vishwas"  wrote:
> >
> > > Hi Mitchell,
> > >
> > > 1. When something is not stated in a draft like the BDR operation, it means
> > > there is no change in the way we need to work. John has stated in previous
> > > mails.
> > >
> > > 2. It is assumed when the BDR or any other router isn't a helper, the
> > > non-helper router would cause the hitless restart to exit when the
> > > restarting router comes up. So the operation from there is the same as
> > > specified in the base RFC.
> > >
> > > 3. The grace period will never be one hour(atleast as I see it).
> > >
> > > 4. I agree to the assumption that the DR is kept is not explicitly stated.
> > > However in Section 2 it is stated that the restarting router will re-elect
> > > itself the DR if it was the DR before restart. Also the assumption that a
> > > high hitless restart interval would be of no use if we had a small router
> > > dead interval in which we could not even send hellos and we broke
> > > adjacencies because of that, can lead to the conclusion that we will not
> > > break adjacencies.
> > >
> > > 5. As stated above we need to send a hello before the router dead interval,
> > > so the router dead interval needs to be large enough that we are able to do
> > > restart and send a hello even if we do not complete the hitless restart by
> > > then.
> > >
> > > Acee,
> > >
> > > So would we want a different TLV for this, rather than a different reason(as
> > > the times we are talking about are different. Point 5. above), if we assume
> > > that the draft assumption of strict checking and not resetting the
> > > inactivity timer.
> > >
> > > Thanks,
> > > Vishwas
> > >
> > > -----Original Message-----
> > > From: Erblichs [mailto:erblichs@EARTHLINK.NET]
> > > Sent: Friday, June 28, 2002 12:18 AM
> > > To: OSPF@DISCUSS.MICROSOFT.COM
> > > Subject: Re: Extended Hitless OSPF Restart
> > >
> > >
> > > Vishwas,
> > >
> > >         Looooong....
> > >
> > >         Here are what I percieve as real weaknesses in the two docs..
> > >
> > >         Actually no it doesn't state that the DR is kept between restarts.
> > >         It implicitly states that the DR is kept if the router was down for
> > >         less than router dead interval. Actually down for time of ( router
> > >         dead interval - waiting time) or less, by seeing a hello with the
> > >         restart router being specified as the DR. But then there is a
> > > conflicting
> > >         statement, which I will point to later..
> > >
> > >         And I am going blind, I see no mention of how a BDR is treated
> > >         in either restart doc. So, it is unstated operation. What happens
> > >         if the BDR is a helper, should it not re-elect itself due to
> > >         section 3 as a helper to maintain the X router as the DR? If
> > >         the BDR isn't a helper (router did not want to verify that the
> > >         grace-LSAs were recieved), does the BDR then ignore the helper's
> > > hellos
> > >         (assuming that DRothers are helpers and the restart was the DR) sees
> > > that
> > >         there is no DR hellos, his router dead interval expires, and elect
> > > himself?
> > >         Now lets assume that the BDR came up after the DR, but really has
> > > higher
> > >         priority. Again the interaction is unspecified when the restart
> > > router
> > >         comes back. However, between the time that the BDR elected himself,
> > > and
> > >         the helpers keep the restart as the DR, we will have two DRs
> > > specified
> > >         in hellos... ummm Now to make things worse, a new router comes up
> > > and
> > >         looks for a DR and sees different routers, continually announcing
> > > different
> > >         routers as the DR..
> > >
> > >         Justification for the problems are stated in long form below...
> > >
> > >         Please note that point 1 below identifies a statement, identifies
> > >         problems with it, and then sees that in point 2 a conflicting
> > >         statement that implictly specifies increasing the
> > > router-dead-interval
> > >         to the grace interval.
> > >
> > >         New Point 1
> > >         ============
> > >
> > >         Sect. 2 After the router restarts ...(3) If the restarting router...
> > >
> > >         "an Hello packet is
> > >            received from a neighbor listing the router as Designated
> > >            Router."
> > >
> > >         But if the restarting router is down for more than the dead router
> > >         interval., will hellos still specifiy that the restarting router
> > >         is the DR? They shouldn't. Why can't the router see that a DR
> > >         is Y, and Y's hellos specify that its priority is Z, then specify
> > >         its own priority as Z+1, and act that it is the DR. And force a
> > >         re-election back to itself as the DR? Why wouldn't it want to do
> > >         that? Should this last item be a "MAY", meaning a DR restarting
> > >         for longer than router dead interval may relect itself by doing
> > >         the following..
> > >
> > >         Orig Doc,..
> > >         If the restarting router is kept as the DR, then what happens to the
> > >         routers that come up sometime
> > >         before it re-elects itself? I am concerned most where a BDR doesn't
> > >         exist. They are effectively dead. They can't form adjacencies until
> > >         there is a live DR.
> > >
> > >         This problem is worse with the "extended hitless" . Section 3.
> > > Changes
> > >         to helper neighbor operation
> > >
> > >         Where the router dead interval is reset to the grace period....
> > > Wow..
> > >         What happens if that time is 1 hour and there is no BDR, and other
> > >         routers come up, no adjs are formed. Why can't you just keep the
> > >         original router dead interval time, mark the router in a restart
> > > state,
> > >         and if the router doesn't come back in say 1 hr, then cleanup..
> > > Restart
> > >         state says don't send him anything other than hellos, suspend your
> > >         re-xmits to that router, etc...
> > >         This would decrease the load on the routers that stay up.
> > >
> > >         extend doc..If the restarting router is the DR.......
> > >         At least there should be a BDR verified for the interfaces where
> > > there
> > >         there is a DR, else.. it should NOT be extended in my opinion. If
> > > there
> > >         is a BDR and the BDR goes down the helpers should revert to their
> > >         previous dead interval times, and re-elect.
> > >         extend doc.. And what happens to the negotiated hello dead interval
> > >         time value with exchange of hellos pdus?
> > >
> > >
> > >         New Point 2
> > >         ================
> > >         But after all of that...
> > >         We know have a conflicting statement... of section 2... with
> > > hellos..
> > >         3. Operations of helper neighbor..
> > >
> > >         "Also, if X was the Designated Router on network segment S when the
> > >     helping relationship began, Y maintains X as Designated router until
> > >     the helping relationship is terminated."
> > >
> > >         This is for the grace period...
> > >
> > >         Or does this implictly state that "dead router interval" is
> > > automaticly
> > >         extended to the grace period", by the helpers. IT should now be
> > > sending
> > >         hellos out with the restart system as the DR...
> > >
> > >         If that was so, then why would the extended doc need to explicitly
> > >         state that???????
> > >
> > >         Why is there a conflict with the two docs..
> > >
> > >
> > >         OLD POINTS
> > >         ==================
> > >
> > >         And back to a question that I had over a month ago.
> > >         2.1 Entering hitless restart...
> > >
> > >         "If Router X wants to ensure that its neighbors
> > >         receive the grace-LSAs, it should retransmit the grace-LSAs
> > >         until they are acknowledged (i.e, perform standard OSPF reliable
> > >         flooding of the grace-LSAs). If one or more fully adjacent
> > >         neighbors do not receive grace-LSAs, they will more than likely
> > >         cause premature termination of the hitless restart procedure
> > >         (see Section 4)."
> > >
> > >         1st: Is "wants" a SHOULD, MUST, ...??
> > >
> > >
> > >             Sub item
> > >             ========
> > >             Lets assume it is a must. What happens if just one nbr has a
> > > late
> > > ack?
> > >             And now that the late ack, now shortens the time allocated for
> > >             "requested grace period"? I assume he can extended it by
> > >             "There is one exception to the above requirements. If Y was
> > >             already helping X on the associated network segment, the new
> > >             grace-LSA should be accepted and the grace period should be
> > >             updated accordingly."
> > >                ***But how does he withdraw it?
> > >                    Should he send a grace-LSA with a grace-period of 0?
> > >
> > >
> > >         2nd: Is "recieve", acked?
> > >
> > >         This one paragraph is a conflict in itself.
> > >
> > >         First if we see "wants" as
> > >         a MUST, then we don't get acks from an adj nbr, then we prematurely
> > >         terminate if we don't get back acks.
> > >
> > >         2nd if we see "wants" as optional, and we don't verify that they
> > > recv
> > >         the grace-LSA, then then we we don't care that some systems are
> > > unaware
> > >         of what we are doing?
> > >
> > >         If he thinks that all of our router neighbors should agree with us,
> > >         and there is a router neighbor addition, then his implied statement
> > >         should prematurely end the helper agreement? Else, not..
> > >
> > >         So, what is he saying, again...
> > >         If we look at section 4. Backward compatibility
> > >         Then he states
> > >         "If one or more
> > >     neighbors of a router requesting hitless restart are unmodified, or
> > >     if they do not received the grace-LSA, the hitless restart converts
> > >     to a normal OSPF restart."
> > >
> > >         Which is no longer a want... because of "recvieved the grace-LSAs"?
> > >         *** But what happens if a router doesn't want to verify that his
> > > grace-LSAs
> > >         are recvd?
> > >
> > >
> > >
> > >         Mitchell Erblich
> > >         ==================
> > >
> > >
> > >
> > > "Manral, Vishwas" wrote:
> > > >
> > > > Hi Mitchell,
> > > >
> > > > Please look at the draft
> > > >
> > > https://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-02.txt
> > > > this draft clearly states the DR role stays after across a hitless
> > > restart,
> > > > while we do not keep the BDR role.
> > > >
> > > > As long as we do not reset adjacencies(neighbor change event) with the
> > > > restarting router we will not do a DR election at all.
> > > >
> > > > Thanks,
> > > > Vishwas
> > > >
> > > > -----Original Message-----
> > > > From: Erblichs [mailto:erblichs@EARTHLINK.NET]
> > > > Sent: Thursday, June 27, 2002 2:04 AM
> > > > To: OSPF@DISCUSS.MICROSOFT.COM
> > > > Subject: Re: Extended Hitless OSPF Restart
> > > >
> > > > Sorry group,
> > > >
> > > >         For this document...
> > > >
> > > >         For the restarting router.. If it was the DR or BDR, do
> > > >         we keep him as the old DR/BDR or re-elect after router
> > > >         dead interval?
> > > >
> > > >         Mitchell Erblich
> > > >         ==================
> > > >
> > > > Erblichs wrote:
> > > > >
> > > > > Group,
> > > > >
> > > > >         This really goes back to the original doc..
> > > > >
> > > > >         Shouldn't there be a limit of say 1 hour for the grace period.
> > > > >
> > > > >         After that time, work that the proposed router's/helpers
> > > > >         should almost ignore that the hitless restart functionality
> > > > >         was originally requested and age out the LSAs that were
> > > > >         originated by the by the restarting router.
> > > > >
> > > > >         Mitchell Erblich
> > > > >         =======================
> > > > >
> > > > > Daniel Gryniewicz wrote:
> > > > > >
> > > > > > Hi.
> > > > > >
> > > > > > Could someone please explain to me why this is necessary?  My reading
> > > of
> > > > > > draft-ietf-ospf-hitless-restart-02 indicates that an implementation
> > > > should
> > > > > > *not* exit helper status because a router dead interval expired.
> > > Please
> > > > > > enlighten me.
> > > > > >
> > > > > > Daniel
> > > > > >
> > > > > > On Tue, 25 Jun 2002 19:51:32 -0700
> > > > > > Acee Lindem  wrote:
> > > > > >
> > > > > > > FYI - Ultimately, this would be an informational RFC or better yet
> > > > > > > folded into the base "OSPF Hitless Restart" specification (although
> > > > > > > this has not been discussed as of yet).
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Acee

--
Acee


From owner-ospf@DISCUSS.MICROSOFT.COM  Sun Jun 30 22:29:11 2002
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17354
	for ; Sun, 30 Jun 2002 22:29:11 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00676E47@cherry.ease.lsoft.com>; Mon, 1 Jul 2002 22:29:55 +2000
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP
          release 1.8e) with spool id 27185 for OSPF@DISCUSS.MICROSOFT.COM;
          Sun, 30 Jun 2002 22:29:55 -0400
Received: from 216.33.236.139 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f)
          with TCP; Sun, 30 Jun 2002 22:29:54 -0400
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun,
          30 Jun 2002 19:29:53 -0700
Received: from 216.175.98.199 by lw7fd.law7.hotmail.msn.com with HTTP; Mon, 01
          Jul 2002 02:29:53 GMT
X-Originating-IP: [216.175.98.199]
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 01 Jul 2002 02:29:53.0960 (UTC)
                       FILETIME=[2EFAA280:01C220A7]
Message-ID:  
Date:         Mon, 1 Jul 2002 02:29:53 +0000
Reply-To: Mailing List 
Sender: Mailing List 
From: Kent Wong 
Subject: Re: Extended Hitless OSPF Restart
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list

Hi Acee,

From what I understand about John's implementation,
helper neighbor should not exit helper mode even though
restarting router's dead interval expires. It should continue
to list restarting router in its LSA as if the adjacency is full.
The only case it should exit helper mode is when grace period
expires, topology changes or if it receives max-age grace LSA
from the restarting router. Thanks.

Kent Wong

>From: Acee Lindem 
>Reply-To: Mailing List 
>To: OSPF@DISCUSS.MICROSOFT.COM
>Subject: Re: Extended Hitless OSPF Restart
>Date: Fri, 28 Jun 2002 16:37:52 -0700
>
>Daniel, Michell,
>
>I'll take a look at John's public domain implementation to see
>what he does. Perhaps, the intent is to allow the neighbor
>relationship to go all the way down but preserve the
>neighbor and continue advertising it as if it were full. If that is
>the case,  I agree that it is unnecessary. I will probably maintain
>the local policy to allow one to configure helper mode rejection if
>the grace-period strictly exceeds the router-dead interval.
>
>Thanks,
>Acee
>
>Erblichs wrote:
> >
> > Daniel,
> >
> >         I completely agree with Daniel's statement that the extension is
> >         unnecessary..
> >
> >         However, "the helping relationship" could be considered
> >         ambiguous..
> >
> >         Vishwas,
> >
> >         1) Yes. I understand that was the orignal intent.
> >
> >         However, if
> >         we go back into the "wants" wording of that one section. And
> >         the restarting router does not want, and the BDR does not
> >         acknowledge, then the BDR after not seeing hellos from the
> >         DR will do a re-election. In my opinion, if I understand the
> >         doc, wants should be changed to a MUST and if all neigbors
> >         (full adjs) do not ack, then the hitless restart must be
> >         terminated...
> >
> >         2) No. Again, if the restart router does not "want". Please
> >           READ what it says in section 2.1, with the line "If
> >         Router X wants to ensure that .... Then the BDR does
> >         not have to ack the grace-LSAs..
> >
> >         If we look at section 4, we don't know if the grace-LSA
> >         was ever recv'd because we could have gone down before
> >         we recv'd the ack. Because we didn't want to re-xmit.
> >
> >         If the restart router restarts before the router-dead interval
>has
> >         expired, then the section's 4, will still be valid. And
> >         we will still see the the links to X. See section 4. So,
> >         again, this invalidates the requirement of it being a
> >         required helper.
> >
> >         3) What.... The only limit is... 3.1 Local policy..
> >           "b) never allow the grace period to exceed", how
> >           many bits do we have to specify a grace period?
> >           Where does the grace-LSA's TLV limit us to 1 hr
> >           as a magical value? I see 4 bytes of length specified
> >           as a limit for the grace period. I think that limit
> >           is bit more than 1hr...
> >
> >         4. skip 4.. You agree... :-)
> >
> >         5). Nooo... "this goes back to the understanding of
> >            "the helping relationship". I see it for the
> >            full grace period of a max 32 bits of seconds.
> >            Years... I just asked to limit it to 1 hr..
> >            So, a length of 2 bytes should be more than
> >            sufficent as a max of I think 18 hours or so..
> >
> >         Mitchell Erblich
> >         ================================
> >
> > Daniel Gryniewicz wrote:
> > >
> > > Hi.
> > >
> > > The draft says:
> > >
> > >     The helper relationship is per network segment.  As a "helper
> > >     neighbor" on a segment S for a restarting router X, router Y has
> > >     several duties. It monitors the network for topology changes, and
>as
> > >     long as there are none, continues to its advertise its LSAs as if
>X
> > >     had remained in continuous OSPF operation. This means that Y's
>LSAs
> > >     continue to list an adjacency to X over network segment S,
> > >     regardless of the adjacency's current synchronization state. This
> > >     logic affects the contents of both router-LSAs and network-LSAs,
>and
> > >     also depends on the type of network segment S (see Sections
>12.4.1.1
> > >     through 12.4.1.5 and Section 12.4.2 of [Ref1]). When helping over
>a
> > >     virtual link, the helper must also continue to set bit V in its
> > >     router-LSA for the virtual link's transit area (Section 12.4.1 of
> > >     [Ref1]).
> > >
> > >     Also, if X was the Designated Router on network segment S when the
> > >     helping relationship began, Y maintains X as Designated router
>until
> > >     the helping relationship is terminated.
> > >
> > > This implies to me that the adjacency *SHOULD NOT TIME OUT* regardless
>of the
> > > lack of hellos until the grace period is over.  Am I wrong in this?
>If I'm
> > > right, then the extension is unnessary.  If I'm wrong, the draft
>should
> > > probably say so.  What I interpret a Grace LSA to mean is: "Put the
>adjacency
> > > on hold for X seconds.  Please."  If you time out the adjacency, but
>don't
> > > tell anyone, then do you un-time-out the adjacnecy when the router
>comes back
> > > up?  Do you exit the helper mode when the hold timer expires even
>though the
> > > grace timer has not expired?  That's a violation of the draft,
>certainly.
> > >
> > > Daniel
> > >
> > > On Fri, 28 Jun 2002 07:32:28 -0400
> > > "Manral, Vishwas"  wrote:
> > >
> > > > Hi Mitchell,
> > > >
> > > > 1. When something is not stated in a draft like the BDR operation,
>it means
> > > > there is no change in the way we need to work. John has stated in
>previous
> > > > mails.
> > > >
> > > > 2. It is assumed when the BDR or any other router isn't a helper,
>the
> > > > non-helper router would cause the hitless restart to exit when the
> > > > restarting router comes up. So the operation from there is the same
>as
> > > > specified in the base RFC.
> > > >
> > > > 3. The grace period will never be one hour(atleast as I see it).
> > > >
> > > > 4. I agree to the assumption that the DR is kept is not explicitly
>stated.
> > > > However in Section 2 it is stated that the restarting router will
>re-elect
> > > > itself the DR if it was the DR before restart. Also the assumption
>that a
> > > > high hitless restart interval would be of no use if we had a small
>router
> > > > dead interval in which we could not even send hellos and we broke
> > > > adjacencies because of that, can lead to the conclusion that we will
>not
> > > > break adjacencies.
> > > >
> > > > 5. As stated above we need to send a hello before the router dead
>interval,
> > > > so the router dead interval needs to be large enough that we are
>able to do
> > > > restart and send a hello even if we do not complete the hitless
>restart by
> > > > then.
> > > >
> > > > Acee,
> > > >
> > > > So would we want a different TLV for this, rather than a different
>reason(as
> > > > the times we are talking about are different. Point 5. above), if we
>assume
> > > > that the draft assumption of strict checking and not resetting the
> > > > inactivity timer.
> > > >
> > > > Thanks,
> > > > Vishwas
> > > >
> > > > -----Original Message-----
> > > > From: Erblichs [mailto:erblichs@EARTHLINK.NET]
> > > > Sent: Friday, June 28, 2002 12:18 AM
> > > > To: OSPF@DISCUSS.MICROSOFT.COM
> > > > Subject: Re: Extended Hitless OSPF Restart
> > > >
> > > >
> > > > Vishwas,
> > > >
> > > >         Looooong....
> > > >
> > > >         Here are what I percieve as real weaknesses in the two
>docs..
> > > >
> > > >         Actually no it doesn't state that the DR is kept between
>restarts.
> > > >         It implicitly states that the DR is kept if the router was
>down for
> > > >         less than router dead interval. Actually down for time of (
>router
> > > >         dead interval - waiting time) or less, by seeing a hello
>with the
> > > >         restart router being specified as the DR. But then there is
>a
> > > > conflicting
> > > >         statement, which I will point to later..
> > > >
> > > >         And I am going blind, I see no mention of how a BDR is
>treated
> > > >         in either restart doc. So, it is unstated operation. What
>happens
> > > >         if the BDR is a helper, should it not re-elect itself due to
> > > >         section 3 as a helper to maintain the X router as the DR? If
> > > >         the BDR isn't a helper (router did not want to verify that
>the
> > > >         grace-LSAs were recieved), does the BDR then ignore the
>helper's
> > > > hellos
> > > >         (assuming that DRothers are helpers and the restart was the
>DR) sees
> > > > that
> > > >         there is no DR hellos, his router dead interval expires, and
>elect
> > > > himself?
> > > >         Now lets assume that the BDR came up after the DR, but
>really has
> > > > higher
> > > >         priority. Again the interaction is unspecified when the
>restart
> > > > router
> > > >         comes back. However, between the time that the BDR elected
>himself,
> > > > and
> > > >         the helpers keep the restart as the DR, we will have two DRs
> > > > specified
> > > >         in hellos... ummm Now to make things worse, a new router
>comes up
> > > > and
> > > >         looks for a DR and sees different routers, continually
>announcing
> > > > different
> > > >         routers as the DR..
> > > >
> > > >         Justification for the problems are stated in long form
>below...
> > > >
> > > >         Please note that point 1 below identifies a statement,
>identifies
> > > >         problems with it, and then sees that in point 2 a
>conflicting
> > > >         statement that implictly specifies increasing the
> > > > router-dead-interval
> > > >         to the grace interval.
> > > >
> > > >         New Point 1
> > > >         ============
> > > >
> > > >         Sect. 2 After the router restarts ...(3) If the restarting
>router...
> > > >
> > > >         "an Hello packet is
> > > >            received from a neighbor listing the router as Designated
> > > >            Router."
> > > >
> > > >         But if the restarting router is down for more than the dead
>router
> > > >         interval., will hellos still specifiy that the restarting
>router
> > > >         is the DR? They shouldn't. Why can't the router see that a
>DR
> > > >         is Y, and Y's hellos specify that its priority is Z, then
>specify
> > > >         its own priority as Z+1, and act that it is the DR. And
>force a
> > > >         re-election back to itself as the DR? Why wouldn't it want
>to do
> > > >         that? Should this last item be a "MAY", meaning a DR
>restarting
> > > >         for longer than router dead interval may relect itself by
>doing
> > > >         the following..
> > > >
> > > >         Orig Doc,..
> > > >         If the restarting router is kept as the DR, then what
>happens to the
> > > >         routers that come up sometime
> > > >         before it re-elects itself? I am concerned most where a BDR
>doesn't
> > > >         exist. They are effectively dead. They can't form
>adjacencies until
> > > >         there is a live DR.
> > > >
> > > >         This problem is worse with the "extended hitless" . Section
>3.
> > > > Changes
> > > >         to helper neighbor operation
> > > >
> > > >         Where the router dead interval is reset to the grace
>period....
> > > > Wow..
> > > >         What happens if that time is 1 hour and there is no BDR, and
>other
> > > >         routers come up, no adjs are formed. Why can't you just keep
>the
> > > >         original router dead interval time, mark the router in a
>restart
> > > > state,
> > > >         and if the router doesn't come back in say 1 hr, then
>cleanup..
> > > > Restart
> > > >         state says don't send him anything other than hellos,
>suspend your
> > > >         re-xmits to that router, etc...
> > > >         This would decrease the load on the routers that stay up.
> > > >
> > > >         extend doc..If the restarting router is the DR.......
> > > >         At least there should be a BDR verified for the interfaces
>where
> > > > there
> > > >         there is a DR, else.. it should NOT be extended in my
>opinion. If
> > > > there
> > > >         is a BDR and the BDR goes down the helpers should revert to
>their
> > > >         previous dead interval times, and re-elect.
> > > >         extend doc.. And what happens to the negotiated hello dead
>interval
> > > >         time value with exchange of hellos pdus?
> > > >
> > > >
> > > >         New Point 2
> > > >         ================
> > > >         But after all of that...
> > > >         We know have a conflicting statement... of section 2... with
> > > > hellos..
> > > >         3. Operations of helper neighbor..
> > > >
> > > >         "Also, if X was the Designated Router on network segment S
>when the
> > > >     helping relationship began, Y maintains X as Designated router
>until
> > > >     the helping relationship is terminated."
> > > >
> > > >         This is for the grace period...
> > > >
> > > >         Or does this implictly state that "dead router interval" is
> > > > automaticly
> > > >         extended to the grace period", by the helpers. IT should now
>be
> > > > sending
> > > >         hellos out with the restart system as the DR...
> > > >
> > > >         If that was so, then why would the extended doc need to
>explicitly
> > > >         state that???????
> > > >
> > > >         Why is there a conflict with the two docs..
> > > >
> > > >
> > > >         OLD POINTS
> > > >         ==================
> > > >
> > > >         And back to a question that I had over a month ago.
> > > >         2.1 Entering hitless restart...
> > > >
> > > >         "If Router X wants to ensure that its neighbors
> > > >         receive the grace-LSAs, it should retransmit the grace-LSAs
> > > >         until they are acknowledged (i.e, perform standard OSPF
>reliable
> > > >         flooding of the grace-LSAs). If one or more fully adjacent
> > > >         neighbors do not receive grace-LSAs, they will more than
>likely
> > > >         cause premature termination of the hitless restart procedure
> > > >         (see Section 4)."
> > > >
> > > >         1st: Is "wants" a SHOULD, MUST, ...??
> > > >
> > > >
> > > >             Sub item
> > > >             ========
> > > >             Lets assume it is a must. What happens if just one nbr
>has a
> > > > late
> > > > ack?
> > > >             And now that the late ack, now shortens the time
>allocated for
> > > >             "requested grace period"? I assume he can extended it by
> > > >             "There is one exception to the above requirements. If Y
>was
> > > >             already helping X on the associated network segment, the
>new
> > > >             grace-LSA should be accepted and the grace period should
>be
> > > >             updated accordingly."
> > > >                ***But how does he withdraw it?
> > > >                    Should he send a grace-LSA with a grace-period of
>0?
> > > >
> > > >
> > > >         2nd: Is "recieve", acked?
> > > >
> > > >         This one paragraph is a conflict in itself.
> > > >
> > > >         First if we see "wants" as
> > > >         a MUST, then we don't get acks from an adj nbr, then we
>prematurely
> > > >         terminate if we don't get back acks.
> > > >
> > > >         2nd if we see "wants" as optional, and we don't verify that
>they
> > > > recv
> > > >         the grace-LSA, then then we we don't care that some systems
>are
> > > > unaware
> > > >         of what we are doing?
> > > >
> > > >         If he thinks that all of our router neighbors should agree
>with us,
> > > >         and there is a router neighbor addition, then his implied
>statement
> > > >         should prematurely end the helper agreement? Else, not..
> > > >
> > > >         So, what is he saying, again...
> > > >         If we look at section 4. Backward compatibility
> > > >         Then he states
> > > >         "If one or more
> > > >     neighbors of a router requesting hitless restart are unmodified,
>or
> > > >     if they do not received the grace-LSA, the hitless restart
>converts
> > > >     to a normal OSPF restart."
> > > >
> > > >         Which is no longer a want... because of "recvieved the
>grace-LSAs"?
> > > >         *** But what happens if a router doesn't want to verify that
>his
> > > > grace-LSAs
> > > >         are recvd?
> > > >
> > > >
> > > >
> > > >         Mitchell Erblich
> > > >         ==================
> > > >
> > > >
> > > >
> > > > "Manral, Vishwas" wrote:
> > > > >
> > > > > Hi Mitchell,
> > > > >
> > > > > Please look at the draft
> > > > >
> > > >
>https://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-02.txt
> > > > > this draft clearly states the DR role stays after across a hitless
> > > > restart,
> > > > > while we do not keep the BDR role.
> > > > >
> > > > > As long as we do not reset adjacencies(neighbor change event) with
>the
> > > > > restarting router we will not do a DR election at all.
> > > > >
> > > > > Thanks,
> > > > > Vishwas
> > > > >
> > > > > -----Original Message-----
> > > > > From: Erblichs [mailto:erblichs@EARTHLINK.NET]
> > > > > Sent: Thursday, June 27, 2002 2:04 AM
> > > > > To: OSPF@DISCUSS.MICROSOFT.COM
> > > > > Subject: Re: Extended Hitless OSPF Restart
> > > > >
> > > > > Sorry group,
> > > > >
> > > > >         For this document...
> > > > >
> > > > >         For the restarting router.. If it was the DR or BDR, do
> > > > >         we keep him as the old DR/BDR or re-elect after router
> > > > >         dead interval?
> > > > >
> > > > >         Mitchell Erblich
> > > > >         ==================
> > > > >
> > > > > Erblichs wrote:
> > > > > >
> > > > > > Group,
> > > > > >
> > > > > >         This really goes back to the original doc..
> > > > > >
> > > > > >         Shouldn't there be a limit of say 1 hour for the grace
>period.
> > > > > >
> > > > > >         After that time, work that the proposed router's/helpers
> > > > > >         should almost ignore that the hitless restart
>functionality
> > > > > >         was originally requested and age out the LSAs that were
> > > > > >         originated by the by the restarting router.
> > > > > >
> > > > > >         Mitchell Erblich
> > > > > >         =======================
> > > > > >
> > > > > > Daniel Gryniewicz wrote:
> > > > > > >
> > > > > > > Hi.
> > > > > > >
> > > > > > > Could someone please explain to me why this is necessary?  My
>reading
> > > > of
> > > > > > > draft-ietf-ospf-hitless-restart-02 indicates that an
>implementation
> > > > > should
> > > > > > > *not* exit helper status because a router dead interval
>expired.
> > > > Please
> > > > > > > enlighten me.
> > > > > > >
> > > > > > > Daniel
> > > > > > >
> > > > > > > On Tue, 25 Jun 2002 19:51:32 -0700
> > > > > > > Acee Lindem  wrote:
> > > > > > >
> > > > > > > > FYI - Ultimately, this would be an informational RFC or
>better yet
> > > > > > > > folded into the base "OSPF Hitless Restart" specification
>(although
> > > > > > > > this has not been discussed as of yet).
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Acee
>
>--
>Acee




_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com