From owner-ospf@DISCUSS.MICROSOFT.COM Mon Jul 1 08:49: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 IAA01871 for ; Mon, 1 Jul 2002 08:49:46 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00677AD3@cherry.ease.lsoft.com>; Mon, 1 Jul 2002 8:50:30 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 31400 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 1 Jul 2002 08:50:30 -0400 Received: from 63.150.151.36 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 1 Jul 2002 08:50:30 -0400 Received: from www23.ureach.com (www23.ureach.com [172.16.2.51]) by ureach.com (8.9.1/8.8.5) with ESMTP id IAA11302 for ; Mon, 1 Jul 2002 08:50:29 -0400 Received: (from nobody@localhost) by www23.ureach.com (8.9.3/8.9.1) id IAA27383; Mon, 1 Jul 2002 08:50:29 -0400 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-vsuite-type: e Message-ID: <200207011250.IAA27383@www23.ureach.com> Date: Mon, 1 Jul 2002 08:50:29 -0400 Reply-To: Mailing List Sender: Mailing List From: Long Subject: unsubscribed To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit unsubscribed ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag From owner-ospf@DISCUSS.MICROSOFT.COM Mon Jul 1 09:03: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 JAA02651 for ; Mon, 1 Jul 2002 09:03:51 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00677B52@cherry.ease.lsoft.com>; Mon, 1 Jul 2002 9:04:38 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 31444 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 1 Jul 2002 09:04:38 -0400 Received: from 32.97.182.101 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 1 Jul 2002 08:54:38 -0400 Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g61Csbg5124220 for ; Mon, 1 Jul 2002 08:54:37 -0400 Received: from d03nm121.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.203.135]) by northrelay01.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g61CsaU78144 for ; Mon, 1 Jul 2002 08:54:36 -0400 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 5.0.10 |March 22, 2002) at 07/01/2002 06:54:37 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Message-ID: Date: Mon, 1 Jul 2002 06:54:36 -0600 Reply-To: Mailing List Sender: Mailing List From: GM Kump Subject: GM Kump/Raleigh/IBM is on Vacation! To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list I will be out of the office starting July 1, 2002 and will not return until July 8, 2002. I will return on July 8, 2002. From owner-ospf@DISCUSS.MICROSOFT.COM Mon Jul 1 13:20: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 NAA20066 for ; Mon, 1 Jul 2002 13:20:22 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.006781BB@cherry.ease.lsoft.com>; Mon, 1 Jul 2002 13:21:02 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 32260 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 1 Jul 2002 13:21:02 -0400 Received: from 12.145.55.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 1 Jul 2002 13:21:02 -0400 Received: from wtn10068 (wtn10068.opnet.com) by smtp2.opnet.com (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Mon, 1 Jul 2002 13:20:19 -0400 X-Sender: azalani@mail.opnet.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.2.1.20020701125607.00bb52e0@mail.opnet.com> Date: Mon, 1 Jul 2002 13:17:56 -0400 Reply-To: Mailing List Sender: Mailing List From: Ashish Zalani Subject: ASE/Network LSAs with same LS ID but different masks To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Suppose a router is advertising two AS External (or Network Summary) LSAs for networks 192.168.0.0/16 and 192.168.0.0/24. Then the two LSAs it will create will have the same Link State ID (192.168.0.0) but different Network Masks. My question is, how does a receiving router distinguish between the two LSAs? AFAIK, any router that receives those two LSAs will use the Link State ID and Advertising Router fields to check if it already has an instance of the LSA in its database. Since both the LS ID and the Advertising Router are the same for both LSAs, it will determine that one of the LSAs is just another instance of the other one and discard one or the other LSA. I looked through the RFC but could not find any information on how to handle this situation. Am I missing something? TIA, -Ashish. Ashish Zalani Modeling Engineer OPNET Technologies, Inc. ========================================== Register for OPNET's Online Technology Workshops (http://www.opnet.com/TechWorkshops/) ========================================== Register for OPNETWORK 2002 (August 26-30 2002) (http://www.opnet.com/opnetwork2002/) ========================================== From owner-ospf@DISCUSS.MICROSOFT.COM Mon Jul 1 13:28: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 NAA20530 for ; Mon, 1 Jul 2002 13:28:08 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0067820F@cherry.ease.lsoft.com>; Mon, 1 Jul 2002 13:28:55 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 32282 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 1 Jul 2002 13:28:55 -0400 Received: from 192.11.226.161 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 1 Jul 2002 13:28:55 -0400 Received: from ma8117exch001p.wins.lucent.com (h152-148-89-177.lucent.com [152.148.89.177]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g61HSrl03426 for ; Mon, 1 Jul 2002 13:28:54 -0400 (EDT) Received: by ma8117exch001p.inse.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 13:28:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Message-ID: Date: Mon, 1 Jul 2002 13:28:47 -0400 Reply-To: Mailing List Sender: Mailing List From: "Joyal, Daniel R (Daniel)" Subject: Re: ASE/Network LSAs with same LS ID but different masks To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Look at Appendix E in the OSPFv2 RFC. -Dan -----Original Message----- From: Ashish Zalani [mailto:azalani@OPNET.COM] Sent: Monday, July 01, 2002 1:18 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: ASE/Network LSAs with same LS ID but different masks Suppose a router is advertising two AS External (or Network Summary) LSAs for networks 192.168.0.0/16 and 192.168.0.0/24. Then the two LSAs it will create will have the same Link State ID (192.168.0.0) but different Network Masks. My question is, how does a receiving router distinguish between the two LSAs? AFAIK, any router that receives those two LSAs will use the Link State ID and Advertising Router fields to check if it already has an instance of the LSA in its database. Since both the LS ID and the Advertising Router are the same for both LSAs, it will determine that one of the LSAs is just another instance of the other one and discard one or the other LSA. I looked through the RFC but could not find any information on how to handle this situation. Am I missing something? TIA, -Ashish. Ashish Zalani Modeling Engineer OPNET Technologies, Inc. ========================================== Register for OPNET's Online Technology Workshops (http://www.opnet.com/TechWorkshops/) ========================================== Register for OPNETWORK 2002 (August 26-30 2002) (http://www.opnet.com/opnetwork2002/) ========================================== From owner-ospf@DISCUSS.MICROSOFT.COM Mon Jul 1 19:43: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 TAA09927 for ; Mon, 1 Jul 2002 19:43:21 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00678D13@cherry.ease.lsoft.com>; Mon, 1 Jul 2002 19:44:07 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 33192 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 1 Jul 2002 19:44:08 -0400 Received: from 207.217.120.120 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 1 Jul 2002 19:44:07 -0400 Received: from user-2ivfjgr.dialup.mindspring.com ([165.247.206.27] helo=earthlink.net) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 17PApx-0005Ro-00 for ospf@discuss.microsoft.com; Mon, 01 Jul 2002 19:44:06 -0400 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: <3D20EBB1.F861C2ED@earthlink.net> Date: Mon, 1 Jul 2002 16:54:25 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: draft-gupta-ospf-ospfv3-auth.00-txt : editorial comments To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Sorry, I did some work with IPv6 years ago... Simple items first: On my text printed copy: 1) There are unusual characters being printed. I believe the first time they show up is in section 3. The first prints as a box before the word "ESP", and the second backward "P" character appears after the word "encryption" of the first line in the second paragraph. This pairing of unusual characters appears numerous times. 4 Somewhat major comments... 1) Does't this document actually refer to IPSec? 2) IPSec can be supported on IPv4 and IPv6. IPSec is a must for IPv6. IKE, I believe is only supported in IPv4. Thus, v6-v4 tunnels allow v6 pkts/datagrams to be inserted/encap within v4 packets. I believe your document implies something else.. At least to me.. Or are you stating that Nokia only supports IPSec with v6? 3) 3. Authentication.. I expected something about support of HMAC-MD5 and HMAC-SHA-1. 4) 3. Authentication.. Tunnels : What is inside the IPSec headers is protected, but but the outer IP header is unprotected.. Other than this, I have no comments on the contents of this Draft RFC.. Mitchell Erblich -================= From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jul 2 03:11: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 DAA27232 for ; Tue, 2 Jul 2002 03:11:45 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.0067982C@cherry.ease.lsoft.com>; Tue, 2 Jul 2002 3:12:29 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 34397 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 2 Jul 2002 03:12:29 -0400 Received: from 205.226.5.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 2 Jul 2002 03:12:28 -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 AAA16298 for ; Tue, 2 Jul 2002 00:12:16 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g627CGY11623; Tue, 2 Jul 2002 00:12:16 -0700 X-mProtect: <200207020712> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.7.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdImeZPu; Tue, 02 Jul 2002 00:12:14 PDT X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <3D20EBB1.F861C2ED@earthlink.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3D21529B.EC109D9C@iprg.nokia.com> Date: Tue, 2 Jul 2002 00:13:31 -0700 Reply-To: Mailing List Sender: Mailing List From: Mukesh Gupta Organization: Nokia IPRG Subject: Re: draft-gupta-ospf-ospfv3-auth.00-txt : editorial comments Comments: To: nmelam@iprg.nokia.com To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Thanks for the comments. Please see my comments inline. > On my text printed copy: > 1) There are unusual characters being printed. I believe > the first time they show up is in section 3. The first > prints as a box before the word "ESP", and the second > backward "P" character appears after the word "encryption" > of the first line in the second paragraph. > > This pairing of unusual characters appears numerous times. I used the word template and crlf.exe to create this :-( I will try to fix them in the next update. Thanks for pointing this out.. > 1) Does't this document actually refer to IPSec? I am not sure about what exactly do you mean here. If you mean that this document should belong to IPsec instead of OSPF then here is the explaination. IPsec is a generic way to provide security to any higher layer IP protocol. As OSPF has specific needs for affording the security provided by IPsec and the document provides appropriate means/mechanisms to fulfill those specific security needs, I think, this document should belong to OSPF. > 2) IPSec can be supported on IPv4 and IPv6. IPSec is a must > for IPv6. IKE, I believe is only supported in IPv4. Thus, > v6-v4 tunnels allow v6 pkts/datagrams to be inserted/encap > within v4 packets. > > I believe your document implies something else.. At least to me.. > Or are you stating that Nokia only supports IPSec with v6? Nokia supports IPsec for IPv4 and will be releasing IPsec for IPv6 soon (or it may already be released). Nokia will also support IKE for IPv6 IPsec. I am not sure how correct you are in saying that IKE is only supported in IPv4. Kame and FreeSwan also support IPv6 IPsec with IKE. > 3) 3. Authentication.. > I expected something about support of HMAC-MD5 and HMAC-SHA-1. You are right. HMAC-MD5 and HMAC-SHA1 will be used as the authentication algorithms while calculating the ICV for AH header. > 4) 3. Authentication.. > Tunnels : What is inside the IPSec headers is protected, but > but the outer IP header is unprotected.. I am sorry but I am not clear about what you are trying to say here. Tunnels encapsulate the entire IP packet inside another IP header. So, the original IP packet is completely protected. regards Mukesh From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jul 2 03:51: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 DAA27924 for ; Tue, 2 Jul 2002 03:51:25 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00679B41@cherry.ease.lsoft.com>; Tue, 2 Jul 2002 3:52:10 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 34578 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 2 Jul 2002 03:52:10 -0400 Received: from 144.189.100.102 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 2 Jul 2002 03:42:10 -0400 Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id AAA09466 for ; Tue, 2 Jul 2002 00:42:09 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id AAA24863 for ; Tue, 2 Jul 2002 00:42:07 -0700 (MST)] Received: from arc.corp.mot.com (arthurd.arc.corp.mot.com [10.238.80.59]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id g627g6nw027189 for ; Tue, 2 Jul 2002 17:42:06 +1000 (EST) X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3D21594E.97D83D08@arc.corp.mot.com> Date: Tue, 2 Jul 2002 17:42:06 +1000 Reply-To: Mailing List Sender: Mailing List From: Arthur Dimitrelis Subject: Designated routers & stub networks To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hello all, I'm trying to figure out the role of a designated router in a stub network. Consider a broadcast segment N with a single router X attached. Firstly, can a stub network have a designated router? (a previous post of John Moy's hints that a stub need not have a DR: http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0201&L=ospf&T=0&F=&S=&P=11786) Here's why I think a stub network _can_ have a DR: - The last paragraph of section 9.4 of rfc2328 implies that X will become the DR for N: "Note also that if Router X is the only attached router that is eligible to become Designated Router, it will select itself as Designated Router and there will be no Backup Designated Router for the network." So, as long as X's priority is not set to 0, it will elect itself the DR of network N. I have not been able to find anything in 2328 that mandates setting the priority of a router connected to a stub network to zero. The only description of a stub I've been able to find is that it has only one router (e.g. 2nd paragraph of page 15). Note that John's January post shows that a broadcast segment with multiple routers can still be considered a "stub" area so long as none of the routers are elected DR). So, if a stub network has a DR, what does that DR do? Again referring to rfc2328, section 7.3 states: --- 7.3. The Designated Router Every broadcast and NBMA network has a Designated Router. The Designated Router performs two main functions for the routing protocol: o The Designated Router originates a network-LSA on behalf of the network. --- - So the designated router of a stub network must originate a network-LSA for that stub network. But sect. 12.4.2 says: 12.4.2. Network-LSAs A network-LSA is generated for every transit broadcast or NBMA network. (A transit network is a network having two or more attached routers). The network-LSA describes all the routers that are attached to the network. --- - The stub network N is not a transit network. Should sec. 7.3 specify that "every transit broadcast and NBMA network has a Designated Router." ? Any thoughts and opinions are appreciated. cheers, Arthur From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jul 2 04:05: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 EAA28164 for ; Tue, 2 Jul 2002 04:05:43 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00679AF3@cherry.ease.lsoft.com>; Tue, 2 Jul 2002 4:06:29 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 34711 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 2 Jul 2002 04:06:29 -0400 Received: from 144.254.15.118 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 2 Jul 2002 04:06:29 -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 g6286Sh12043 for ; Tue, 2 Jul 2002 10:06:28 +0200 (CEST) References: <3D21594E.97D83D08@arc.corp.mot.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: <014c01c2219f$6a795b50$ab09fe90@cisco.com> Date: Tue, 2 Jul 2002 10:06:48 +0200 Reply-To: Mailing List Sender: Mailing List From: Anton Smirnov Organization: Cisco Systems, Inc. Subject: Re: Designated routers & stub networks To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Arthur, don't mix two completely different things - network which is configured to be transit but has only 1 OSPF speaker at present and network which is 'configured stub'. Both cases will be announced in LSAs same way. But in second case router(s) do not usually even produce any OSPF traffic on the network segment (Hellos in a first place), they just include reachability information about the network in their LSAs. Apparently, in second case there can be no DR even if multiple routers connected to the segment and advertise it as stub. Anton ----- Original Message ----- From: "Arthur Dimitrelis" To: Sent: Tuesday, July 02, 2002 09:42 Subject: [OSPF] Designated routers & stub networks > Hello all, > > I'm trying to figure out the role of a designated router in a stub > network. > > Consider a broadcast segment N with a single router X attached. > > Firstly, can a stub network have a designated router? (a previous post > of John Moy's hints that a stub need not have a DR: > http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0201&L=ospf&T=0&F=&S=& P=11786) > > Here's why I think a stub network _can_ have a DR: > > - The last paragraph of section 9.4 of rfc2328 implies that X will > become the DR for N: > > "Note also that if Router X is the only attached router that is > eligible to become Designated Router, it will select itself as > Designated Router and there will be no Backup Designated Router > for the network." > > So, as long as X's priority is not set to 0, it will elect itself the DR > of network N. I have not been able to find anything in 2328 that > mandates setting the priority of a router connected to a stub network to > zero. The only description of a stub I've been able to find is that it > has only one router (e.g. 2nd paragraph of page 15). Note that John's > January post shows that a broadcast segment with multiple routers can > still be considered a "stub" area so long as none of the routers are > elected DR). > > So, if a stub network has a DR, what does that DR do? Again referring to > rfc2328, section 7.3 states: > --- > 7.3. The Designated Router > > Every broadcast and NBMA network has a Designated Router. The > Designated Router performs two main functions for the routing > protocol: > > o The Designated Router originates a network-LSA on behalf of > the network. > --- > > - So the designated router of a stub network must originate a > network-LSA for that stub network. But sect. 12.4.2 says: > > 12.4.2. Network-LSAs > > A network-LSA is generated for every transit broadcast or > NBMA network. (A transit network is a network having two or > > more attached routers). The network-LSA describes all the > routers that are attached to the network. > --- > > - The stub network N is not a transit network. Should sec. 7.3 specify > that "every transit broadcast and NBMA network has a Designated Router." > ? > > Any thoughts and opinions are appreciated. > > cheers, > Arthur > From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jul 2 06:55: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 GAA02838 for ; Tue, 2 Jul 2002 06:55:47 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00679CA9@cherry.ease.lsoft.com>; Tue, 2 Jul 2002 6:56:34 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 36746 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 2 Jul 2002 06:56:34 -0400 Received: from 216.136.226.60 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 2 Jul 2002 06:56:34 -0400 Received: from [203.200.20.226] by web20205.mail.yahoo.com via HTTP; Tue, 02 Jul 2002 03:56:33 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20020702105633.35553.qmail@web20205.mail.yahoo.com> Date: Tue, 2 Jul 2002 03:56:33 -0700 Reply-To: Mailing List Sender: Mailing List From: Swati Rastogi Subject: Link Flap Damping To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, We have this concept of route flap damping in BGP while no such equivalent exists in OSPF. If we have a neighbor which is constantly flapping then we must give preference to another router if it is more stable. We must tolerate flapping for some time but if the figure of merit (it is increased by a fixed value each time router flaps) goes beyond some pre defined threshold then all the LSAs originated by the offending router should be suppressed. What do others think on this? Why isnt a feature similiar to this supported by OSPF? Is it because we want faster convergence in IGPs? Regards, Swati __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jul 2 09:47: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 JAA09512 for ; Tue, 2 Jul 2002 09:47:00 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0067A071@cherry.ease.lsoft.com>; Tue, 2 Jul 2002 9:47:41 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 37317 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 2 Jul 2002 09:47:41 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 2 Jul 2002 09:47:41 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 9F5BF449A37 for ; Tue, 2 Jul 2002 06:47:39 -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: <3D21594E.97D83D08@arc.corp.mot.com> <014c01c2219f$6a795b50$ab09fe90@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D21AF40.5070407@redback.com> Date: Tue, 2 Jul 2002 09:48:48 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Designated routers & stub networks To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Anton Smirnov wrote: > Arthur, > don't mix two completely different things - network which is configured > to be transit but has only 1 OSPF speaker at present and network which is > 'configured stub'. Arthur, Also note that the former is part of the OSPF standard (RFC 2328) while the latter is not. In the former case, the router with non-zero priority will elect itself DR but it will not originate a network LSA nor will it have any additional flooding duties (since there are no other OSPF routers on the network). Anton, By configured as a stub do you mean the interface is configured as 'passive'? > Both cases will be announced in LSAs same way. But in > second case router(s) do not usually even produce any OSPF traffic on the > network segment (Hellos in a first place), they just include reachability > information about the network in their LSAs. Apparently, in second case > there can be no DR even if multiple routers connected to the segment and > advertise it as stub. > > Anton > > > ----- Original Message ----- > From: "Arthur Dimitrelis" > To: > Sent: Tuesday, July 02, 2002 09:42 > Subject: [OSPF] Designated routers & stub networks > > > >>Hello all, >> >>I'm trying to figure out the role of a designated router in a stub >>network. >> >>Consider a broadcast segment N with a single router X attached. >> >>Firstly, can a stub network have a designated router? (a previous post >>of John Moy's hints that a stub need not have a DR: >> >> > http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0201&L=ospf&T=0&F=&S=& > P=11786) > >>Here's why I think a stub network _can_ have a DR: >> >>- The last paragraph of section 9.4 of rfc2328 implies that X will >>become the DR for N: >> >> "Note also that if Router X is the only attached router that is >> eligible to become Designated Router, it will select itself as >> Designated Router and there will be no Backup Designated Router >> for the network." >> >>So, as long as X's priority is not set to 0, it will elect itself the DR >>of network N. I have not been able to find anything in 2328 that >>mandates setting the priority of a router connected to a stub network to >>zero. The only description of a stub I've been able to find is that it >>has only one router (e.g. 2nd paragraph of page 15). Note that John's >>January post shows that a broadcast segment with multiple routers can >>still be considered a "stub" area so long as none of the routers are >>elected DR). >> >>So, if a stub network has a DR, what does that DR do? Again referring to >>rfc2328, section 7.3 states: >>--- >> 7.3. The Designated Router >> >> Every broadcast and NBMA network has a Designated Router. The >> Designated Router performs two main functions for the routing >> protocol: >> >> o The Designated Router originates a network-LSA on behalf of >> the network. >>--- >> >>- So the designated router of a stub network must originate a >>network-LSA for that stub network. But sect. 12.4.2 says: >> >> 12.4.2. Network-LSAs >> >> A network-LSA is generated for every transit broadcast or >> NBMA network. (A transit network is a network having two or >> >> more attached routers). The network-LSA describes all the >> routers that are attached to the network. >>--- >> >>- The stub network N is not a transit network. Should sec. 7.3 specify >>that "every transit broadcast and NBMA network has a Designated Router." >>? >> >>Any thoughts and opinions are appreciated. >> >>cheers, >>Arthur >> >> > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jul 2 11:21: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 LAA21414 for ; Tue, 2 Jul 2002 11:21:31 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.0067A2A6@cherry.ease.lsoft.com>; Tue, 2 Jul 2002 11:22:16 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 37980 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 2 Jul 2002 11:22:16 -0400 Received: from 144.254.15.118 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 2 Jul 2002 11:22:16 -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 g62FMFh00440 for ; Tue, 2 Jul 2002 17:22:15 +0200 (CEST) References: <3D21594E.97D83D08@arc.corp.mot.com> <014c01c2219f$6a795b50$ab09fe90@cisco.com> <3D21AF40.5070407@redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: <02a301c221dc$49776b80$ab09fe90@cisco.com> Date: Tue, 2 Jul 2002 17:22:32 +0200 Reply-To: Mailing List Sender: Mailing List From: Anton Smirnov Organization: Cisco Systems, Inc. Subject: Re: Designated routers & stub networks To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Acee, > By configured as a stub do you mean the interface is configured > as 'passive'? yes, in Cisco wording that would be 'passive interface'. I used term 'interface, configured as stub' considering that it is clear enough and implementation-independent enough to suit generic answer on generic question. Term is not something widely accepted, so I put it in quotation. > Also note that the former is part of the OSPF standard (RFC 2328) while the > latter is not. This is discussible point (that is, I don't agree :-). The first, standard clearly discusses ways to handle during SPF multiple paths to stub networks and their appearance in multiple Router LSAs. That is the only thing required from standard to make above mentioned behavior standardized and correct. The only other case when multiple paths to stub network can happen is L2 partitioning of formerly transit network. Apparently, nothing can help in latter case and I hope you agree that this wasn't primary goal of that part of standard. The second, much more generic point. Industry standard cares (and states this on more than one occasion) only about things which are transmitted on the wire (being put in a very broad sense). If two behaviors of the box - first described in standard and another is what actually happening inside the box - are indistinguishable from other network devices, then both behaviors are standard compliant. Anton ----- Original Message ----- From: "Acee Lindem" To: Sent: Tuesday, July 02, 2002 15:48 Subject: Re: [OSPF] Designated routers & stub networks > Anton Smirnov wrote: > > > Arthur, > > don't mix two completely different things - network which is configured > > to be transit but has only 1 OSPF speaker at present and network which is > > 'configured stub'. > > > Arthur, > > Also note that the former is part of the OSPF standard (RFC 2328) while the > latter is not. In the former case, the router with non-zero priority will elect > itself DR but it will not originate a network LSA nor will it have any > additional flooding duties (since there are no other OSPF routers on > the network). > > Anton, > > By configured as a stub do you mean the interface is configured > as 'passive'? > > > Both cases will be announced in LSAs same way. But in > > second case router(s) do not usually even produce any OSPF traffic on the > > network segment (Hellos in a first place), they just include reachability > > information about the network in their LSAs. Apparently, in second case > > there can be no DR even if multiple routers connected to the segment and > > advertise it as stub. > > > > Anton > > > > > > ----- Original Message ----- > > From: "Arthur Dimitrelis" > > To: > > Sent: Tuesday, July 02, 2002 09:42 > > Subject: [OSPF] Designated routers & stub networks > > > > > > > >>Hello all, > >> > >>I'm trying to figure out the role of a designated router in a stub > >>network. > >> > >>Consider a broadcast segment N with a single router X attached. > >> > >>Firstly, can a stub network have a designated router? (a previous post > >>of John Moy's hints that a stub need not have a DR: > >> > >> > > http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0201&L=ospf&T=0&F=&S=& > > P=11786) > > > >>Here's why I think a stub network _can_ have a DR: > >> > >>- The last paragraph of section 9.4 of rfc2328 implies that X will > >>become the DR for N: > >> > >> "Note also that if Router X is the only attached router that is > >> eligible to become Designated Router, it will select itself as > >> Designated Router and there will be no Backup Designated Router > >> for the network." > >> > >>So, as long as X's priority is not set to 0, it will elect itself the DR > >>of network N. I have not been able to find anything in 2328 that > >>mandates setting the priority of a router connected to a stub network to > >>zero. The only description of a stub I've been able to find is that it > >>has only one router (e.g. 2nd paragraph of page 15). Note that John's > >>January post shows that a broadcast segment with multiple routers can > >>still be considered a "stub" area so long as none of the routers are > >>elected DR). > >> > >>So, if a stub network has a DR, what does that DR do? Again referring to > >>rfc2328, section 7.3 states: > >>--- > >> 7.3. The Designated Router > >> > >> Every broadcast and NBMA network has a Designated Router. The > >> Designated Router performs two main functions for the routing > >> protocol: > >> > >> o The Designated Router originates a network-LSA on behalf of > >> the network. > >>--- > >> > >>- So the designated router of a stub network must originate a > >>network-LSA for that stub network. But sect. 12.4.2 says: > >> > >> 12.4.2. Network-LSAs > >> > >> A network-LSA is generated for every transit broadcast or > >> NBMA network. (A transit network is a network having two or > >> > >> more attached routers). The network-LSA describes all the > >> routers that are attached to the network. > >>--- > >> > >>- The stub network N is not a transit network. Should sec. 7.3 specify > >>that "every transit broadcast and NBMA network has a Designated Router." > >>? > >> > >>Any thoughts and opinions are appreciated. > >> > >>cheers, > >>Arthur > >> > >> > > > > > -- > Acee > From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jul 2 11:36:02 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 LAA22905 for ; Tue, 2 Jul 2002 11:36:01 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.0067A1E8@cherry.ease.lsoft.com>; Tue, 2 Jul 2002 11:36:46 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 38032 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 2 Jul 2002 11:36:46 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 2 Jul 2002 11:36:46 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id CBEEB1531C2 for ; Tue, 2 Jul 2002 08:36:44 -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: <3D21594E.97D83D08@arc.corp.mot.com> <014c01c2219f$6a795b50$ab09fe90@cisco.com> <3D21AF40.5070407@redback.com> <02a301c221dc$49776b80$ab09fe90@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D21C8D1.1080202@redback.com> Date: Tue, 2 Jul 2002 11:37:53 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Designated routers & stub networks To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Anton Smirnov wrote: > Acee, > > >>By configured as a stub do you mean the interface is configured >>as 'passive'? >> > yes, in Cisco wording that would be 'passive interface'. I used term > 'interface, configured as stub' considering that it is clear enough and > implementation-independent enough to suit generic answer on generic > question. Term is not something widely accepted, so I put it in quotation. We use the same terminology. I think most vendors do. > > > >>Also note that the former is part of the OSPF standard (RFC 2328) while >> > the > >>latter is not. >> > This is discussible point (that is, I don't agree :-). > The first, standard clearly discusses ways to handle during SPF multiple > paths to stub networks and their appearance in multiple Router LSAs. That is > the only thing required from standard to make above mentioned behavior > standardized and correct. The only other case when multiple paths to stub > network can happen is L2 partitioning of formerly transit network. > Apparently, nothing can help in latter case and I hope you agree that this > wasn't primary goal of that part of standard. > The second, much more generic point. Industry standard cares (and states > this on more than one occasion) only about things which are transmitted on > the wire (being put in a very broad sense). If two behaviors of the box - > first described in standard and another is what actually happening inside > the box - are indistinguishable from other network devices, then both > behaviors are standard compliant. I did *not* say implementing the 'passive' option was not standards compliant. What I said was that it is not part of RFC 2328 - you won't find a description on the appropriate behavior for a passive interface and the 'passive' attribute is not explicitly listed in the configurable constants included in Appendix C. I included this since Arthur's original question related DR operation as defined in RFC 2328. > > Anton > > > ----- Original Message ----- > From: "Acee Lindem" > To: > Sent: Tuesday, July 02, 2002 15:48 > Subject: Re: [OSPF] Designated routers & stub networks > > > >>Anton Smirnov wrote: >> >> >>> Arthur, >>> don't mix two completely different things - network which is >>> > configured > >>>to be transit but has only 1 OSPF speaker at present and network which >>> > is > >>>'configured stub'. >>> >> >>Arthur, >> >>Also note that the former is part of the OSPF standard (RFC 2328) while >> > the > >>latter is not. In the former case, the router with non-zero priority will >> > elect > >>itself DR but it will not originate a network LSA nor will it have any >>additional flooding duties (since there are no other OSPF routers on >>the network). >> >>Anton, >> >>By configured as a stub do you mean the interface is configured >>as 'passive'? >> >> >>>Both cases will be announced in LSAs same way. But in >>>second case router(s) do not usually even produce any OSPF traffic on >>> > the > >>>network segment (Hellos in a first place), they just include >>> > reachability > >>>information about the network in their LSAs. Apparently, in second case >>>there can be no DR even if multiple routers connected to the segment and >>>advertise it as stub. >>> >>>Anton >>> >>> >>>----- Original Message ----- >>>From: "Arthur Dimitrelis" >>>To: >>>Sent: Tuesday, July 02, 2002 09:42 >>>Subject: [OSPF] Designated routers & stub networks >>> >>> >>> >>> >>>>Hello all, >>>> >>>>I'm trying to figure out the role of a designated router in a stub >>>>network. >>>> >>>>Consider a broadcast segment N with a single router X attached. >>>> >>>>Firstly, can a stub network have a designated router? (a previous post >>>>of John Moy's hints that a stub need not have a DR: >>>> >>>> >>>> > http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0201&L=ospf&T=0&F=&S=& > >>>P=11786) >>> >>> >>>>Here's why I think a stub network _can_ have a DR: >>>> >>>>- The last paragraph of section 9.4 of rfc2328 implies that X will >>>>become the DR for N: >>>> >>>> "Note also that if Router X is the only attached router that is >>>> eligible to become Designated Router, it will select itself as >>>> Designated Router and there will be no Backup Designated Router >>>> for the network." >>>> >>>>So, as long as X's priority is not set to 0, it will elect itself the DR >>>>of network N. I have not been able to find anything in 2328 that >>>>mandates setting the priority of a router connected to a stub network to >>>>zero. The only description of a stub I've been able to find is that it >>>>has only one router (e.g. 2nd paragraph of page 15). Note that John's >>>>January post shows that a broadcast segment with multiple routers can >>>>still be considered a "stub" area so long as none of the routers are >>>>elected DR). >>>> >>>>So, if a stub network has a DR, what does that DR do? Again referring to >>>>rfc2328, section 7.3 states: >>>>--- >>>> 7.3. The Designated Router >>>> >>>> Every broadcast and NBMA network has a Designated Router. The >>>> Designated Router performs two main functions for the routing >>>> protocol: >>>> >>>> o The Designated Router originates a network-LSA on behalf of >>>> the network. >>>>--- >>>> >>>>- So the designated router of a stub network must originate a >>>>network-LSA for that stub network. But sect. 12.4.2 says: >>>> >>>> 12.4.2. Network-LSAs >>>> >>>> A network-LSA is generated for every transit broadcast or >>>> NBMA network. (A transit network is a network having two or >>>> >>>> more attached routers). The network-LSA describes all the >>>> routers that are attached to the network. >>>>--- >>>> >>>>- The stub network N is not a transit network. Should sec. 7.3 specify >>>>that "every transit broadcast and NBMA network has a Designated Router." >>>>? >>>> >>>>Any thoughts and opinions are appreciated. >>>> >>>>cheers, >>>>Arthur >>>> >>>> >>>> >> >>-- >>Acee >> >> > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jul 2 13: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 NAA03361 for ; Tue, 2 Jul 2002 13: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 <18.0067A638@cherry.ease.lsoft.com>; Tue, 2 Jul 2002 13:39:42 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 38514 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 2 Jul 2002 13:39:42 -0400 Received: from 207.217.120.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 2 Jul 2002 13:39:42 -0400 Received: from user-2ivfncu.dialup.mindspring.com ([165.247.221.158] helo=earthlink.net) by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17PRcq-00045d-00 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 02 Jul 2002 13:39:40 -0400 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: <3D20EBB1.F861C2ED@earthlink.net> <3D21529B.EC109D9C@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3D21E7C7.B95E8AB1@earthlink.net> Date: Tue, 2 Jul 2002 10:49:59 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: draft-gupta-ospf-ospfv3-auth.00-txt : editorial comments To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit We will try inline comments... Mitchell Erblich ===================== ================= Mukesh Gupta wrote: > > Thanks for the comments. Please see my comments inline. > > > On my text printed copy: > > 1) There are unusual characters being printed. I believe > > the first time they show up is in section 3. The first > > prints as a box before the word "ESP", and the second > > backward "P" character appears after the word "encryption" > > of the first line in the second paragraph. > > > > This pairing of unusual characters appears numerous times. > > I used the word template and crlf.exe to create this :-( I will try to fix them in the next > update. Thanks for pointing this out.. > > > 1) Does't this document actually refer to IPSec? > > I am not sure about what exactly do you mean here. If you mean that this document should belong > to IPsec instead of OSPF then here is the explaination. IPsec is a generic way to provide > security to any higher layer IP protocol. As OSPF has specific needs for affording the security > provided by IPsec and the document provides appropriate means/mechanisms to fulfill those > specific security needs, I think, this document should belong to OSPF. > I agree with this last statement. > > 2) IPSec can be supported on IPv4 and IPv6. IPSec is a must > > for IPv6. IKE, I believe is only supported in IPv4. Thus, > > v6-v4 tunnels allow v6 pkts/datagrams to be inserted/encap > > within v4 packets. > > > > I believe your document implies something else.. At least to me.. > > Or are you stating that Nokia only supports IPSec with v6? > > Nokia supports IPsec for IPv4 and will be releasing IPsec for IPv6 soon (or it may already be > released). Nokia will also support IKE for IPv6 IPsec. I am not sure how correct you are in > saying that IKE is only supported in IPv4. Kame and FreeSwan also support IPv6 IPsec with IKE. > I will check out my pre-inclination issues with IKE later.. (have a short 4th trip) No, in my opinion, you give the impression that these items are IPv6 specific in this doc. Where did you state that what items apply to IPv4 here? They are IPSec items and IPSec can also be used with IPv4.. I would expect at least a statement in the intro that your sections also apply to IPv4. And thus could also effect OSPFv2.. > > 3) 3. Authentication.. > > I expected something about support of HMAC-MD5 and HMAC-SHA-1. > > You are right. HMAC-MD5 and HMAC-SHA1 will be used as the authentication algorithms while > calculating the ICV for AH header. > > > 4) 3. Authentication.. > > Tunnels : What is inside the IPSec headers is protected, but > > but the outer IP header is unprotected.. > > I am sorry but I am not clear about what you are trying to say here. Tunnels encapsulate the > entire IP packet inside another IP header. So, the original IP packet is completely protected. > This is a rough "tunnel mode" description. Maybe something clearer would be. Tunnel mode is when the datagram is protected by the IPSec headers, but the outer IP header is unprotected... This is normally used in ESP. The outer IP header will normally have different src and dst addresses than the inner IP header. Maybe I should also suggest a short description of "transport mode"? Just trying to fill in some of my percieved holes within your doc. However, if this was a FS doc and you were discussing sparse files, then holes would be expected. :-) Add: ESP is a header, thus I would add the word "header" after "(ESP)" in your 1. Introduction. > regards > Mukesh From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jul 2 14:12: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 OAA05353 for ; Tue, 2 Jul 2002 14:12:43 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0067A93F@cherry.ease.lsoft.com>; Tue, 2 Jul 2002 14:13:31 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 38703 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 2 Jul 2002 14:13:31 -0400 Received: from 205.226.5.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 2 Jul 2002 14:03:31 -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 LAA11119 for ; Tue, 2 Jul 2002 11:03:30 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g62I3T009097; Tue, 2 Jul 2002 11:03:29 -0700 X-mProtect: <200207021803> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.115, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdepIhqa; Tue, 02 Jul 2002 11:03:27 PDT X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 References: <3D20EBB1.F861C2ED@earthlink.net> <3D21529B.EC109D9C@iprg.nokia.com> <3D21E7C7.B95E8AB1@earthlink.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3D21EAEF.EC6E6FCB@iprg.nokia.com> Date: Tue, 2 Jul 2002 11:03:27 -0700 Reply-To: Mailing List Sender: Mailing List From: Mukesh Gupta Organization: Nokia IPRG Subject: Re: draft-gupta-ospf-ospfv3-auth.00-txt : editorial comments Comments: To: nmelam@iprg.nokia.com To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit > > Nokia supports IPsec for IPv4 and will be releasing IPsec for IPv6 soon (or it may already be > > released). Nokia will also support IKE for IPv6 IPsec. I am not sure how correct you are in > > saying that IKE is only supported in IPv4. Kame and FreeSwan also support IPv6 IPsec with IKE. > > > > I will check out my pre-inclination issues with IKE later.. (have a > short 4th trip) > > No, in my opinion, you give the impression that these items are IPv6 > specific > in this doc. > Where did you state that what items apply to IPv4 here? > They are IPSec items and IPSec can also be used with IPv4.. I would > expect at > least a statement in the intro that your sections also apply to IPv4. > And thus could also effect OSPFv2.. OSPFv2 (for IPv4) has its own authentication mechanisms inbuilt in OSPFv2 protocol headers. RFC 2740 (OSPFv3 for IPv6) suggests using IPv6 ESP/AH extension headers for providing security to OSPFv3 (just v3 and *not* v2). So you are getting the right impression that we are just talking about IPv6 IPsec here. Nothing in the draft relates to IPv4 IPsec or OSPFv2. That's why we are not talking about IPv4 IPsec in the draft. > Tunnel mode is when the datagram is protected by the IPSec headers, but > the outer > IP header is unprotected... This is normally used in ESP. The outer IP > header will > normally have different src and dst addresses than the inner IP header. > > Maybe I should also suggest a short description of "transport mode"? > > Just trying to fill in some of my percieved holes within your doc. > However, > if this was a FS doc and you were discussing sparse files, then holes > would > be expected. :-) > > Add: ESP is a header, thus I would add the word "header" after "(ESP)" > in your > 1. Introduction. If everyone wants I can add more description about tunnel/transport mode and ESP/AH headers but I am assuming that people have read about them from the specified references and the assumption is clearly stated in the introduction. regards Mukesh -- ****************************************************************** The only gracious way to accept an insult is to ignore it; if you can't ignore it, top it; if you can't top it, laugh at it; if you can't laugh at it, it's probably deserved ****************************************************************** Mukesh Gupta Phone: (650) 625-2264 Cell : (650) 868-9111 http://www.iprg.nokia.com/~mgupta ****************************************************************** From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jul 2 16:44: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 QAA14339 for ; Tue, 2 Jul 2002 16:44:22 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0067AD0B@cherry.ease.lsoft.com>; Tue, 2 Jul 2002 16:45:07 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 39174 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 2 Jul 2002 16:45:07 -0400 Received: from 203.178.142.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 2 Jul 2002 16:45:07 -0400 Received: from localhost (page.sfc.wide.ad.jp [203.178.143.89]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id D83775D01A; Wed, 3 Jul 2002 05:45:05 +0900 (JST) References: <20020702105633.35553.qmail@web20205.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=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20020703.053753.100277647.yasu@sfc.wide.ad.jp> Date: Wed, 3 Jul 2002 05:37:53 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: Link Flap Damping Comments: To: swatirstogi@YAHOO.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20020702105633.35553.qmail@web20205.mail.yahoo.com> Precedence: list Content-Transfer-Encoding: 7bit I also thought that the feature similar to BGP flap dampenning can be added to OSPF. What I don't agree with you is to suppress LSA or to suppress link description. It may be the only link to the router/network. In the case we (at least I) want the connectivity to there *up* even if the link is flapping or congesting. It maybe better to keep the link description available (while link is flapping). By doing so we can reduce LSA changes and route/topology computation on all routers in OSPF domain. # I think it is too heavy to check if the link is the only path to # some networks from others... Another idea is a route preference for multi-path route. Which path to prefer in a equal cost multi path is left to the calculating router's own. If we have enough multi path, it will be a great help for stability of the network. Is there any feature for this already ? Waiting for a following. thanks. yasu swatirstogi> Hi, swatirstogi> We have this concept of route flap damping in BGP swatirstogi> while no such equivalent exists in OSPF. If we have a swatirstogi> neighbor which is constantly flapping then we must swatirstogi> give preference to another router if it is more swatirstogi> stable. We must tolerate flapping for some time but if swatirstogi> the figure of merit (it is increased by a fixed value swatirstogi> each time router flaps) goes beyond some pre defined swatirstogi> threshold then all the LSAs originated by the swatirstogi> offending router should be suppressed. swatirstogi> swatirstogi> What do others think on this? Why isnt a feature swatirstogi> similiar to this supported by OSPF? swatirstogi> swatirstogi> Is it because we want faster convergence in IGPs? swatirstogi> swatirstogi> Regards, swatirstogi> Swati swatirstogi> swatirstogi> swatirstogi> swatirstogi> swatirstogi> __________________________________________________ swatirstogi> Do You Yahoo!? swatirstogi> Sign up for SBC Yahoo! Dial - First Month Free swatirstogi> http://sbc.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jul 2 23:56: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 XAA02656 for ; Tue, 2 Jul 2002 23:56:15 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0067B853@cherry.ease.lsoft.com>; Tue, 2 Jul 2002 23:57:01 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 40238 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 2 Jul 2002 23:57:01 -0400 Received: from 204.147.80.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 2 Jul 2002 23:57:01 -0400 Received: (qmail 61168 invoked from network); 3 Jul 2002 03:56:57 -0000 Received: from unknown (HELO KasiViswanath) (61.11.55.252) by mplspop5.mpls.uswest.net with SMTP; 3 Jul 2002 03:56:57 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C22273.54DDCA40" 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: <001801c22245$3dcc9260$0401a8c0@KasiViswanath> Date: Wed, 3 Jul 2002 09:23:45 +0530 Reply-To: Mailing List Sender: Mailing List From: Kasi Viswanath Subject: query To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C22273.54DDCA40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi, I found there are some changes in rfc documents from 1247 and 2328, but there are some incompatibilities are found. Does ospf implementation should allow both methods? (I mean backward = compatibility?) And, I found that there is =20 University of maryland's free distribution of OSPF earlier = implementation, but I do n't know where can I get that distribution. (send mail to Mr. Rob coltun but failure reply :| ) Thirteenth & Sixteenth Proceedings of IETF online version? can any one please help me to get this. Thanks In Advance. with regards kasi viswanath.N.J ------=_NextPart_000_0013_01C22273.54DDCA40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi,
 
I found there are some changes in rfc = documents=20 from 1247 and 2328,
but there are some incompatibilities = are=20 found.
Does ospf implementation should allow = both methods?=20 (I mean backward compatibility?)
 
And, I found that there is =  
 
University of maryland's free = distribution of OSPF=20 earlier implementation,
but I do n't know where can I get that=20 distribution.
(send mail to Mr. Rob coltun but = failure reply :|=20 )
 
Thirteenth & Sixteenth Proceedings = of IETF=20 online version?
 
 
can any one please help me to get=20 this.
 
 
Thanks In Advance.
 
with regards
kasi viswanath.N.J
 
 
 
 
------=_NextPart_000_0013_01C22273.54DDCA40-- From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jul 3 00:16: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 AAA03242 for ; Wed, 3 Jul 2002 00:16: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.0067BB4B@cherry.ease.lsoft.com>; Wed, 3 Jul 2002 0:17:46 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 40498 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 3 Jul 2002 00:17:46 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 3 Jul 2002 00:17:46 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id C0DDE262819 for ; Tue, 2 Jul 2002 21:17:44 -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: <001801c22245$3dcc9260$0401a8c0@KasiViswanath> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D227B26.4070008@redback.com> Date: Wed, 3 Jul 2002 00:18:46 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: query To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Kasi Viswanath wrote: > hi, > > > > I found there are some changes in rfc documents from 1247 and 2328, > > but there are some incompatibilities are found. > > Does ospf implementation should allow both methods? (I mean backward > compatibility?) Specifically what incompatibilities are you talking about? AFAIK, the only one which is not backward compatible is the ASBR preference in AS external route computation. Hence, there is a configuration flag to support backward compatibility. > > > > And, I found that there is > > > > University of maryland's free distribution of OSPF earlier implementation, > > but I do n't know where can I get that distribution. This is still exant in the public domain version of gated (3.5.11). However, it doesn't seem to be available for Nexthop technologies (a commercial spin-off of the gated consortium). John Moy's GPL version at www.ospf.org is a more current reference implementation. > > (send mail to Mr. Rob coltun but failure reply :| ) > > > > Thirteenth & Sixteenth Proceedings of IETF online version? > > > > > > can any one please help me to get this. > > > > > > Thanks In Advance. > > > > with regards > > kasi viswanath.N.J > > > > > > > > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jul 3 01:04: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 BAA04852 for ; Wed, 3 Jul 2002 01:04:23 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.0067BCFB@cherry.ease.lsoft.com>; Wed, 3 Jul 2002 1:05:10 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 40753 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 3 Jul 2002 01:05:10 -0400 Received: from 216.136.226.58 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 3 Jul 2002 01:05:09 -0400 Received: from [203.200.20.226] by web20203.mail.yahoo.com via HTTP; Tue, 02 Jul 2002 22:05:09 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20020703050509.80550.qmail@web20203.mail.yahoo.com> Date: Tue, 2 Jul 2002 22:05:09 -0700 Reply-To: Mailing List Sender: Mailing List From: Swati Rastogi Subject: Re: Link Flap Damping Comments: To: Yasuhiro Ohara To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20020703.053753.100277647.yasu@sfc.wide.ad.jp> Precedence: list Hi Yasu, > What I don't agree with you is to suppress LSA or to > suppress link > description. It may be the only link to the > router/network. In the > case we (at least I) want the connectivity to there > *up* even if the > link is flapping or congesting. It maybe better to > keep the link > description available (while link is flapping). By > doing so we can > reduce LSA changes and route/topology computation on > all routers in > OSPF domain. You are reducing LSA changes at the cost of providing sub-optimal (and in the worst case incorrect and false) routing. You still claim reachability to a router which you are no longer are connected to (during the period when the link is down) The downstream peers will falsely assume that u still have reachability to some networks and they will in turn advertise this to their peers. This will create havoc if one of the OSPF routers is redistributing routes into BGP One of the most fundamental rules of routing which i learnt long back was that we must advertise the bad news at the earliest. The same happens in BGP. Certain implementations maintain a MinAdvertismentInterval timer which when triggers causes a BGP speaker to advertise all its UPDATE messages to its peers. This timer is not honoured in case of sending UPDATE messages containing withdrawn/non feasible routes. The same should hold true for OSPF. Why should one router keep the link description up when it knows that it is down? Your comments please. > > # I think it is too heavy to check if the link is > the only path to > # some networks from others... > > Another idea is a route preference for multi-path > route. Which path to > prefer in a equal cost multi path is left to the > calculating router's > own. If we have enough multi path, it will be a > great help for > stability of the network. Is there any feature for > this already ? THis is another issue as to what the behaviour should be when we have multipath routes. I strongly recommend using a path which i know has been more stable in the past. I may (given some suitable metrics) also select a route which i know is of more cost if i know that it is more stable than a route/link which i know is *highly* unreliable. How we determine whether the route/link is unreliable or not is left on the implementation. What do others say? Regards, Swati Rastogi __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jul 3 03:35: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 DAA00747 for ; Wed, 3 Jul 2002 03:35:28 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.0067BFD3@cherry.ease.lsoft.com>; Wed, 3 Jul 2002 3:36:15 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 40984 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 3 Jul 2002 03:36:15 -0400 Received: from 203.178.142.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 3 Jul 2002 03:36:14 -0400 Received: from localhost (page.sfc.wide.ad.jp [203.178.143.89]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id CCCC05D01A; Wed, 3 Jul 2002 16:36:12 +0900 (JST) References: <20020703.053753.100277647.yasu@sfc.wide.ad.jp> <20020703050509.80550.qmail@web20203.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=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20020703.162859.03882168.yasu@sfc.wide.ad.jp> Date: Wed, 3 Jul 2002 16:28:59 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: Link Flap Damping Comments: To: swatirstogi@yahoo.com To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20020703050509.80550.qmail@web20203.mail.yahoo.com> Precedence: list Content-Transfer-Encoding: 7bit swatirstogi> You are reducing LSA changes at the cost of providing swatirstogi> sub-optimal (and in the worst case incorrect and swatirstogi> false) routing. You still claim reachability to a swatirstogi> router which you are no longer are connected to swatirstogi> (during the period when the link is down) swatirstogi> swatirstogi> The downstream peers will falsely assume that u still swatirstogi> have reachability to some networks and they will in swatirstogi> turn advertise this to their peers. This will create swatirstogi> havoc if one of the OSPF routers is redistributing swatirstogi> routes into BGP swatirstogi> swatirstogi> One of the most fundamental rules of routing which i swatirstogi> learnt long back was that we must advertise the bad swatirstogi> news at the earliest. The same happens in BGP. Certain swatirstogi> implementations maintain a MinAdvertismentInterval swatirstogi> timer which when triggers causes a BGP speaker to swatirstogi> advertise all its UPDATE messages to its peers. This swatirstogi> timer is not honoured in case of sending UPDATE swatirstogi> messages containing withdrawn/non feasible routes. swatirstogi> swatirstogi> The same should hold true for OSPF. Why should one swatirstogi> router keep the link description up when it knows that swatirstogi> it is down? swatirstogi> swatirstogi> Your comments please. I believe IGP has different logic from EGP's. - about "providing sub-optimal" and "why link description up": I'm thinking about link flapping caused by congestion. If a link flaps, your feature will not allow OSPF to route any traffics to the link entirely. We still have a lot of links which do not have alternatives. In case no alternatives, I think that we prefer to deactivate the feature and let the traffic thru the link by "best effort" until we upgrade the link or prepare alternatives. [a little bit off topic: I once thought that "we should not worry about congestions, because we have Diffserv technology and link monitor packet (such as Hello in OSPF) should go beyond the others priority". But now I wonder if this is true: in Diffserv world, some class's packet go through normally and the other class's packet may not. What is that the hello monitors ? Do we really want to keep the reachability in that case ? Hello should monitor each class's link path separately ... ] - about "bad news earlier": The "bad news earlier" logic is from that EGP is more severe than IGP about inactive route. If an AS advertise unavailable route then the AS doing illegal by consuming other AS's network, by calling meaningless traffic in. It is entire Internet's implied policy. In intra-AS/IGP, (I think) there's no such consideration for others exists: just fast convergence. I mean I have a little bit different feeling in your words "The same should hold true for OSPF". - about "havoc case": Do we advertise BGP route directly created by an OSPF route in general ? Should we advertise some aggregated route ? Even in the case directly advertised, BGP flap dampening will do something ... But I'm not confident I'm a little short in operations ... :p) swatirstogi> THis is another issue as to what the behaviour should swatirstogi> be when we have multipath routes. I strongly recommend swatirstogi> using a path which i know has been more stable in the swatirstogi> past. I may (given some suitable metrics) also select swatirstogi> a route which i know is of more cost if i know that it swatirstogi> is more stable than a route/link which i know is swatirstogi> *highly* unreliable. How we determine whether the swatirstogi> route/link is unreliable or not is left on the swatirstogi> implementation. I read on the Internet that we have failed at changing OSPF cost dynamically because it will not be stable due to traffic shift over some paths. So your approach can not be applied by dynamic way. I am just trying to save the duration between errors and human repairs which is some pathological. regards. yasu From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jul 3 05:32: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 FAA02494 for ; Wed, 3 Jul 2002 05:32: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.0067C227@cherry.ease.lsoft.com>; Wed, 3 Jul 2002 5:33:44 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 41359 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 3 Jul 2002 05:33:44 -0400 Received: from 203.178.142.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 3 Jul 2002 05:33:44 -0400 Received: from localhost (page.sfc.wide.ad.jp [203.178.143.89]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 4BD545D022; Wed, 3 Jul 2002 18:33:42 +0900 (JST) X-Mailer: Mew version 2.1 on XEmacs 21.1.14 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Wed_Jul__3_18:26:29_2002_263)--" Content-Transfer-Encoding: 7bit Message-ID: <20020703.182629.129013597.yasu@sfc.wide.ad.jp> Date: Wed, 3 Jul 2002 18:26:29 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Fw: Link Flap Damping Comments: To: swatirstogi@yahoo.com To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list ----Next_Part(Wed_Jul__3_18:26:29_2002_263)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Swati, it seems you failed to post this mail to ML. And the link to the document: http://www.fictitious.org/ospf-omp/ospf-omp.txt http://www.fictitious.org/omp/ regards. yasu ----Next_Part(Wed_Jul__3_18:26:29_2002_263)-- Content-Type: Message/Rfc822 Content-Disposition: inline X-Sieve: cmu-sieve 2.0 Return-Path: Received: from web20206.mail.yahoo.com (web20206.mail.yahoo.com [216.136.226.61]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id E79DD5D021 for ; Wed, 3 Jul 2002 18:01:33 +0900 (JST) Message-ID: <20020703090132.10365.qmail@web20206.mail.yahoo.com> Received: from [203.200.20.226] by web20206.mail.yahoo.com via HTTP; Wed, 03 Jul 2002 02:01:32 PDT Date: Wed, 3 Jul 2002 02:01:32 -0700 (PDT) From: Swati Rastogi Subject: Re: Link Flap Damping To: Yasuhiro Ohara In-Reply-To: <20020703.162859.03882168.yasu@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > swatirstogi> Your comments please. > > I believe IGP has different logic from EGP's. > > - about "providing sub-optimal" and "why link > description up": > > I'm thinking about link flapping caused by > congestion. > If a link flaps, your feature will not allow > OSPF to route any > traffics to the link entirely. OSPF will stop using a particular link/route only if it finds that the particular link/router is *very* unstable. This is the same as that followed by BGP. Each time a link/router flaps there is a figure of merit (call it penalty) associated with the link/router which should be increased. If it goes beyond one threshold we know that the link is really really BAD and that we mustn't use it. Otherwise if the frequency of flapping is not much then OSPF will still recognize it and use it. With time the Fig of Merit will reduce (say exponentially). > We still have a > lot of links which > do not have alternatives. In case no > alternatives, I think that > we prefer to deactivate the feature and let the > traffic thru the > link by "best effort" until we upgrade the link > or prepare > alternatives. But the same happens in BGP. Even if there is only one route to a destination and if it flaps then the whole of network cannot reach that particular destination. Flap Damping is regardless of whether we have substitute backup routes or not. OR you can also do another thing. Damp the routes/links if you know that you have some other routes to reach those destinations. > - about "bad news earlier": > > The "bad news earlier" logic is from that EGP is > more severe than > IGP about inactive route. If an AS advertise > unavailable route I thought it applied to the general routing as a whole. > then the AS doing illegal by consuming other > AS's network, by > calling meaningless traffic in. It is entire > Internet's implied > policy. In intra-AS/IGP, (I think) there's no > such consideration > for others exists: just fast convergence. I mean > I have a little > bit different feeling in your words "The same > should hold true for > OSPF". > > - about "havoc case": > > Do we advertise BGP route directly created by an > OSPF route in > general ? Oh yes we can certainly advertise some redistributed routes from OSPF directly to BGP after applying some suitable filters. > Should we advertise some aggregated > route ? Even in the > case directly advertised, BGP flap dampening > will do something ... NOt many BGP speakers run route flap damping and even if they do then it is only for its EBGP peers and not IBGP. > But I'm not confident I'm a little short in > operations ... :p) > > swatirstogi> implementation. > > I read on the Internet that we have failed at > changing OSPF cost > dynamically because it will not be stable due to > traffic shift over > some paths. Can you give me a link to any such document. It will be nice and instructive reading for me. > So your approach can not be applied by > dynamic way. > I am just trying to save the duration between errors > and human repairs > which is some pathological. what has been vexing me since i started pondering over this issue is the apparent difference between BGP and OSPF .. wherin this scheme works fine in BGP but will fail for OSPF :-( Any Clues anyone? > > regards. > yasu > __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com ----Next_Part(Wed_Jul__3_18:26:29_2002_263)---- From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jul 3 06:28: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 GAA03344 for ; Wed, 3 Jul 2002 06:28:09 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0067C50A@cherry.ease.lsoft.com>; Wed, 3 Jul 2002 6:28:56 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 42647 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 3 Jul 2002 06:28:56 -0400 Received: from 66.218.78.82 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 3 Jul 2002 06:28:55 -0400 Received: from [203.200.20.226] by web40303.mail.yahoo.com via HTTP; Wed, 03 Jul 2002 03:28:55 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20020703102855.20457.qmail@web40303.mail.yahoo.com> Date: Wed, 3 Jul 2002 03:28:55 -0700 Reply-To: Mailing List Sender: Mailing List From: Amit Srivastava Subject: Cisco Implementation?? To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20020703.182629.129013597.yasu@sfc.wide.ad.jp> Precedence: list Hi All, I have a simple doubt:- Suppose i have two n/w's one router is common on both the n/w let us call it as R0.Now R0 is in full state with both R1 and R2 routers on differnet n/w's Now suppose that R1 crashes suddenly so the LSA's of this router would remain in the R0 and R2.Now after router dead interval the R0 can flush the LSA's of R1 by originating new LSA with cost as infinitly.Now zebra is now doing like this. Does any one know how the CISCO is doing is CISCO performing the above approach or not. Regards Amit __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jul 3 06:40: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 GAA04490 for ; Wed, 3 Jul 2002 06:40:10 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0067C6B5@cherry.ease.lsoft.com>; Wed, 3 Jul 2002 6:40:57 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 42681 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 3 Jul 2002 06:40:57 -0400 Received: from 131.228.20.26 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 3 Jul 2002 06:30:57 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g63AWoW28230 for ; Wed, 3 Jul 2002 13:32:50 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 3 Jul 2002 13:30:55 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 3 Jul 2002 13:30:55 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: Link Flap Damping Thread-Index: AcIiZFJ0ZHttdoMWQNGQBIPkLsEtqgAEa1Ng X-OriginalArrivalTime: 03 Jul 2002 10:30:55.0599 (UTC) FILETIME=[B6AEBFF0:01C2227C] Message-ID: Date: Wed, 3 Jul 2002 13:30:54 +0300 Reply-To: Mailing List Sender: Mailing List From: Andreas Heiner Subject: Re: Link Flap Damping To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA04490 Hi comments in-line > Subject: Re: Link Flap Damping > > > swatirstogi> You are reducing LSA changes at the cost of providing > swatirstogi> sub-optimal (and in the worst case incorrect and > swatirstogi> false) routing. You still claim reachability to a > swatirstogi> router which you are no longer are connected to > swatirstogi> (during the period when the link is down) > [ side issue I'm not quite sure what you mean with "optimal routing". Intuitively optimality in this context is "getting as much traffic through as fast as possible", but with dynamic traffic demands optimality is not well defined. Moreover, the cost assignment is relatively arbitrary (one administrator may say hops, others reliability etc.), so in my opinion "optimal routing" is rather arbitrary. I prefer to use "as good as possible", or even better, "good enough" routing. Gives you way more flexibility. In the end, the only thing users are interested in is good (enough) service, not optimal service (the STAR protocol by Garcia-Luna-Aceves (http://www.soe.ucsc.edu/people/faculty/jj.html) also uses this principle) ] > swatirstogi> > swatirstogi> The downstream peers will falsely assume that u still > swatirstogi> have reachability to some networks and they will in > swatirstogi> turn advertise this to their peers. This will create > swatirstogi> havoc if one of the OSPF routers is redistributing > swatirstogi> routes into BGP > swatirstogi> > swatirstogi> One of the most fundamental rules of routing which i > swatirstogi> learnt long back was that we must advertise the bad > swatirstogi> news at the earliest. The same happens in BGP. Certain > swatirstogi> implementations maintain a MinAdvertismentInterval > swatirstogi> timer which when triggers causes a BGP speaker to > swatirstogi> advertise all its UPDATE messages to its peers. This > swatirstogi> timer is not honoured in case of sending UPDATE > swatirstogi> messages containing withdrawn/non feasible routes. > swatirstogi> > swatirstogi> The same should hold true for OSPF. Why should one > swatirstogi> router keep the link description up when it knows that > swatirstogi> it is down? > swatirstogi> > swatirstogi> Your comments please. > > I believe IGP has different logic from EGP's. > > - about "providing sub-optimal" and "why link description up": > > I'm thinking about link flapping caused by congestion. > If a link flaps, your feature will not allow OSPF to route any > traffics to the link entirely. We still have a lot of links which > do not have alternatives. In case no alternatives, I think that > we prefer to deactivate the feature and let the traffic thru the > link by "best effort" until we upgrade the link or prepare > alternatives. > > [a little bit off topic: > I once thought that "we should not worry about congestions, > because we have Diffserv technology and link monitor packet (such > as Hello in OSPF) should go beyond the others priority". > But now I wonder if this is true: in Diffserv world, some class's > packet go through normally and the other class's packet may not. > What is that the hello monitors ? Do we really want to keep the > reachability in that case ? Hello should monitor each class's link > path separately ... > ] > ...deleted... In my opinion the only service OSPF (or any other IGP) provides/should provide is connectivity, i.e. it tells you if a link exists and if it can carry traffic, not how much traffic there is. Route recalculation based on traffic information (congestion gives new cost values) should not be done as it will introduce route flaps. This also holds for a DiffServ world. In a DiffServ world packets are preferentially forwarded, but always such that no single class is starved. Even if some class gets so little BW that de-facto the link is down for that class, one should not declare the link down for that class, as it is equivalent with assigning a high cost for that link. Hence link monitor packets per class make no sense. (Besides, in long simulations with strict priority queueing we never had class starvation) As for Hello in the highest DiffServ class: we tested this idea in simulations for all OSPF packets, and results were excellent, i.e. route table convergence in the order of the half the minimum round trip time (excl. route table recalculations). This idea was also proposed in 'draft-ietf-ospf-scalability-01.txt'. regards, Andrepeter > regards. > yasu > From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jul 3 08:06: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 IAA08220 for ; Wed, 3 Jul 2002 08: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 <22.0067C922@cherry.ease.lsoft.com>; Wed, 3 Jul 2002 8:07:06 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 42959 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 3 Jul 2002 08:07:05 -0400 Received: from 144.254.15.118 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 3 Jul 2002 08:07:05 -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 g63C74h12211 for ; Wed, 3 Jul 2002 14:07:04 +0200 (CEST) References: <20020703102855.20457.qmail@web40303.mail.yahoo.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: <02f101c2228a$4edc0af0$ab09fe90@cisco.com> Date: Wed, 3 Jul 2002 14:08:13 +0200 Reply-To: Mailing List Sender: Mailing List From: Anton Smirnov Organization: Cisco Systems, Inc. Subject: Re: Cisco Implementation?? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Amit, R0 must not flush R1's LSA only on the ground that they lost direct neighborship. This LSA (s) should reside in LSDB until they are MAXAGEd. R0 and/or R2 may only update their own LSA(s) to reflect change in set of neighbors. That is what standard requires to do and what - I hope - both Cisco and Zebra do. There are nuances, though, for DC connections. But I think you are talking about usual broadcast networks. Anton ----- Original Message ----- From: "Amit Srivastava" To: Sent: Wednesday, July 03, 2002 12:28 Subject: [OSPF] Cisco Implementation?? > Hi All, > I have a simple doubt:- > > Suppose i have two n/w's one router is common on both > the n/w let us call it as R0.Now R0 is in full state > with both R1 and R2 routers on differnet n/w's > Now suppose that R1 crashes suddenly so the > LSA's of this router would remain in the R0 and R2.Now > after router dead interval the R0 can flush the LSA's > of R1 by originating new LSA with cost as > infinitly.Now zebra is now doing like this. > Does any one know how the CISCO is doing is > CISCO performing the above approach or not. > Regards > Amit > > > > > > > __________________________________________________ > Do You Yahoo!? > Sign up for SBC Yahoo! Dial - First Month Free > http://sbc.yahoo.com > From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jul 3 14:15: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 OAA25496 for ; Wed, 3 Jul 2002 14:15:51 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.0067CE9B@cherry.ease.lsoft.com>; Wed, 3 Jul 2002 11:08:54 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 43434 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 3 Jul 2002 11:08:54 -0400 Received: from 131.114.33.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 3 Jul 2002 10:58:53 -0400 Received: from there (pipc51.meta.cpr.it [131.114.33.217]) by atr42.meta.cpr.it (8.11.1/8.11.1) with SMTP id g63Ewlv15542 for ; Wed, 3 Jul 2002 16:58:47 +0200 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: KMail [version 1.3.1] References: <20020703102855.20457.qmail@web40303.mail.yahoo.com> <02f101c2228a$4edc0af0$ab09fe90@cisco.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: <200207031458.g63Ewlv15542@atr42.meta.cpr.it> Date: Wed, 3 Jul 2002 16:59:00 +0200 Reply-To: Mailing List Sender: Mailing List From: Enrico Dutti Subject: Looking for an old ospf draft To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <02f101c2228a$4edc0af0$ab09fe90@cisco.com> Precedence: list Content-Transfer-Encoding: 8bit Hi, I'm looking for the document: draft-ietf-ospf-extattr-00.txt but I'm not able to find it... Can anyone help? If it's not possible it would be enough to know the scope of type 8 LSAs... Thank you very much Enrico Dutti From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jul 3 15:19: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 PAA01078 for ; Wed, 3 Jul 2002 15:19:19 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0067D45E@cherry.ease.lsoft.com>; Wed, 3 Jul 2002 15:20:08 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 44407 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 3 Jul 2002 15:20:07 -0400 Received: from 192.128.134.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 3 Jul 2002 15:20:07 -0400 Received: from attrh1i.attrh.att.com ([135.71.62.10]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id g63IwZvC019782 for ; Wed, 3 Jul 2002 14:20:05 -0500 (CDT) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh1i.attrh.att.com (5.5.029) id 3CBB4973003C414E; Wed, 3 Jul 2002 15:19:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: IETF Draft for Comment -- "Proposed Mechanisms for Congestion Con trol/Failure Recovery in OSPF & ISIS Networks" Thread-Index: AcEDx4Vpozilqm+4EdWKNwCQJ7Zb0j6FUg4QA+tUwfA= Message-ID: <28F05913385EAC43AF019413F674A01701B653B2@OCCLUST04EVS1.ugd.att.com> Date: Wed, 3 Jul 2002 15:19:58 -0400 Reply-To: Mailing List Sender: Mailing List From: "Ash, Gerald R (Jerry), ALASO" Subject: Re: Congestion Avoidance & Control for OSPF Networks Comments: To: "Moy, John" Comments: cc: "Manral, Vishwas" , Alex Zinin , Bill Fenner To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA01078 Hello John, All: Hopefully by now you've had chance to review our latest draft on OSPF congestion control http://search.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control-00.txt. As requested (by John), we've narrowed the scope of the work to propose specific congestion control mechanisms not already addressed by other documents in the OSPF WG. These mechanisms will prevent control overloads from bringing down a network, as they have in the past (I give a brief background below). We request your comments on our I-D. We also request your suggestions for advancing the work in the working group. Thanks, Jerry Ash Brief background: AT&T has suffered a few massive failures of operational networks due to control overloads of link-state (LS) protocols ('OSPF', 'PNNI', etc.). These outages are documented and referenced in http://search.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control-00.txt and in http://search.ietf.org/internet-drafts/draft-ash-ospf-isis-congestion-control-02.txt. In the instances cited, the LS protocol overwhelmed the network with a control load 'storm' ('LSA overload'), which brought the network down, and then prevented its recovery. Fortunately such failures are very rare; however, 'rare' for such events is unacceptable, 'never' is the goal. Other service providers have experienced similar outages caused by similar problems. Such failures are not the fault of the service provider operation or the vendor/equipment implementation. They are due to shortcomings in the link-state protocols themselves -- thus the need for the enhancements proposed in the draft. The proposals in the draft will prevent such events from being triggered, and/or provide recovery mechanisms in case such events occur. The problem of control overload is becoming even more acute as LS protocols are enhanced to support new capabilities, such as: MPLS traffic engineering http://search.ietf.org/internet-drafts/draft-katz-yeung-ospf-traffic-06.txt, GMPLS http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-07.txt, multi-area TE http://www.ietf.org/internet-drafts/draft-cheng-ccamp-ospf-multiarea-te-extensions-00.txt, MPLS/DiffServ TE http://search.ietf.org/internet-drafts/draft-ietf-tewg-diff-te-reqts-05.txt, etc. With this ever advancing complexity, the need keeps increasing to address the stated problem, soon. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jul 3 18:11: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 SAA09362 for ; Wed, 3 Jul 2002 18:11:17 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0067D93F@cherry.ease.lsoft.com>; Wed, 3 Jul 2002 18:12:04 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 45126 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 3 Jul 2002 18:12:04 -0400 Received: from 207.217.120.50 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 3 Jul 2002 18:12:04 -0400 Received: from user-2ivflbi.dialup.mindspring.com ([165.247.213.114] helo=earthlink.net) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17PsLu-0005yo-00 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 03 Jul 2002 18:11:58 -0400 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: <20020702105633.35553.qmail@web20205.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3D23791C.78D604EF@earthlink.net> Date: Wed, 3 Jul 2002 15:22:20 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Link Flap Damping To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Swati, My two cents.. I guess you could think that route flapping is implicitly partially supported by a number of features in OSPF. 1) The requirement to first set up a 2-way connection between link partners. 2) The requirement to wait a certain amount of time before elections are done. 3) That database description synchronization is a multiple step process. Before routes are exchanged. 4) We will re-xmit until we get an ack or until dead-router-interval. 5) Etc... And that in a multi-access topology for OSPF only adjs will be established between a subset of the routers. Where BGP just about requires a mesh topology (yes, exceptions are route reflectors, etc). Thus, the dependence is on the interval of the flap. If the time while down is so short, it may be acting somewhat in a "demand-circuit" like mode. Why would we want to penalize the router when it meets the dead router interval requirement? If the time while up is so short, it hopefully cannot form an adjcency.. yes, worse case if it was elected the DR and could not form adjs because it was flapping.. So, what would you be protecting and hopefully not force longer convergence or flooding intervals. Mitchell Erblich --------------------- Swati Rastogi wrote: > > Hi, > We have this concept of route flap damping in BGP > while no such equivalent exists in OSPF. If we have a > neighbor which is constantly flapping then we must > give preference to another router if it is more > stable. We must tolerate flapping for some time but if > the figure of merit (it is increased by a fixed value > each time router flaps) goes beyond some pre defined > threshold then all the LSAs originated by the > offending router should be suppressed. > > What do others think on this? Why isnt a feature > similiar to this supported by OSPF? > > Is it because we want faster convergence in IGPs? > > Regards, > Swati > > __________________________________________________ > Do You Yahoo!? > Sign up for SBC Yahoo! Dial - First Month Free > http://sbc.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Thu Jul 4 07:01: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 HAA14049 for ; Thu, 4 Jul 2002 07:01:18 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0067E770@cherry.ease.lsoft.com>; Thu, 4 Jul 2002 7:02:05 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48677 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 4 Jul 2002 07:02:05 -0400 Received: from 133.145.224.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 4 Jul 2002 07:02:04 -0400 Received: from navsg3.hitachi.co.jp by hitpro.hitachi.co.jp (8.9.3/3.7W-hitpro) id UAA13775; Thu, 4 Jul 2002 20:02:03 +0900 (JST) Received: from navsg3.hitachi.co.jp by navsg3.hitachi.co.jp (8.9.3/3.7W-navsg3) id UAA23071; Thu, 4 Jul 2002 20:02:02 +0900 (JST) Received: from newton.ebina.hitachi.co.jp ([158.214.184.5]) by navsg3.hitachi.co.jp (NAVGW 2.5.1.16) with SMTP id M2002070420020225535 for ; Thu, 04 Jul 2002 20:02:02 +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 UAA24891 for ; Thu, 4 Jul 2002 20:02:02 +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 UAA01810 for ; Thu, 4 Jul 2002 20:02:01 +0900 (JST) Message-ID: <200207041102.UAA01810@one3463.ebina.hitachi.co.jp> Date: Thu, 4 Jul 2002 20:02:00 +0900 Reply-To: Mailing List Sender: Mailing List From: Yamate Keiichirou Subject: Re: Link Flap Damping To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Your message of "Wed, 03 Jul 2002 16:28:59 JST." <20020703.162859.03882168.yasu@sfc.wide.ad.jp> Precedence: list Hello, Yasu. I think that newly implimentation of "Link Flap Dampimg" rises 4 issues. First issue is RouterDeadInterval. In OSPF, it is dampened that Hellos dropped by collision or any reasons by RouterDeadInterval timer. Thus when OSPF operators want to dampen link states to Down, it should be accomplished simply by large RouterDeadInterval, rather than implimentation any unusual logics. Second issue is about IGPs' primary responsibility. I think that IGPs have two primary responsibilities of 1) notice new reachabilities rapidly and 2) notice new UNreachability rapidly. Thus, when implimentations want to dampen that Hellos not received recently from particular router, it should be ensured that the neighboring router is yet alive against of no Hellos received. Third issue is LSDB synchronization. When it is occured that the router has received no Hellos from particular router, if both router are continuously operating, it is likely that Link State Databases are not synchronized between two routers. Thus the link between these routers should be considered to be Down because LSDB unsynchronization means two unrelyability of that LSDB in at least one of routers is unreliable and that routing entries in one of routers is unreliable, and at result it means that the router should be omitted from routing domain. It is accomplished to omit unreliable router from routing domain by link to such router Down. Fourth issue is routing traffic preference. Where routing domain has only one data traffic class (i.e. routing domain has no QoS), OSPF Hello reachability implies phisical, logical, and traffic reachability of the only one class. But where routing domain has multiple traffic classes (i.e. routing domain has some QoS), OSPF Hello indeed implies reachability of none of these classes. On the other hand, routing traffic should be prefered to any other data traffics because routing traffic supports all of data traffics with reachability notation. Thus, where routing domain has any QoS, routing traffic should be in the first class of QoS and it will be ensured that none of routing traffics would be dropped by collision with any other traffics. --- yamate. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Jul 4 08:03: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 IAA15622 for ; Thu, 4 Jul 2002 08:03:01 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.0067E9FB@cherry.ease.lsoft.com>; Thu, 4 Jul 2002 8:03:49 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48847 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 4 Jul 2002 08:03:49 -0400 Received: from 203.254.224.24 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 4 Jul 2002 08:03:48 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) id <0GYQ0060148KTH@mailout1.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Thu, 04 Jul 2002 21:05:08 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GYQ0069A48JD1@mailout1.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Thu, 04 Jul 2002 21:05:08 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0GYQ00C6348LA4@mmp2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Thu, 04 Jul 2002 21:05:11 +0900 (KST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <200207041102.UAA01810@one3463.ebina.hitachi.co.jp> Message-ID: <137b01c22352$584ee0d0$b4036c6b@sisodomain.com> Date: Thu, 4 Jul 2002 17:30:07 +0530 Reply-To: Mailing List Sender: Mailing List From: Manav Bhatia Subject: Re: Link Flap Damping Comments: To: yamate@EBINA.HITACHI.CO.JP To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7BIT Hello Yamate, | | First issue is RouterDeadInterval. In OSPF, it is dampened that | Hellos dropped by collision or any reasons by RouterDeadInterval | timer. Thus when OSPF operators want to dampen link states to Down, | it should be accomplished simply by large RouterDeadInterval, rather | than implimentation any unusual logics. AFAIK the intention is to damp the flapping link which cannot be done by simply increasing the RouterDeadInterval. If its value is increased then we suffer from low convergence wherein a router takes larger time in recognizing that a peer ospf router has gone down. This is definitely not desired. What can perhaps be done is - each time a link flaps a figure of merit should be increased. This value should be decayed with time so that if the link remains stable for a long time (configurable) we can delete whatever past history we were maintaining for that link. If the link again flaps - increase the penalty. This goes on till the penalty reaches some upper threshold upon which it is deemed to be unstable. Now the router implementing flap damping should not include this router in its router LSA (because we know from the past that it is very unstable and there is a high probability that it will go down again). This router waits for some time. If it finds that the router/link is now stable (its not flapping anymore) it should originate a new router LSA wherein it mentions this link/router. This will only affect the normal working if the link/router is flapping very frequently (subjective). | | Second issue is about IGPs' primary responsibility. I think that IGPs | have two primary responsibilities of 1) notice new reachabilities | rapidly and 2) notice new UNreachability rapidly. I guess that is what the routing protocols were designed for. | Thus, when | implimentations want to dampen that Hellos not received recently from | particular router, it should be ensured that the neighboring router is | yet alive against of no Hellos received. This point was not very clear to me. Can you please expound on this? | | Third issue is LSDB synchronization. When it is occured that the | router has received no Hellos from particular router, if both router did not received HELLOs since how long? If it is the RouterDeadInterval then the remote ospf speaking router will be assumed to be dead (or state down). Regards, Manav From owner-ospf@DISCUSS.MICROSOFT.COM Thu Jul 4 08:40: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 IAA16270 for ; Thu, 4 Jul 2002 08:40:02 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0067E97E@cherry.ease.lsoft.com>; Thu, 4 Jul 2002 8:40:51 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48944 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 4 Jul 2002 08:40:51 -0400 Received: from 216.136.226.58 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 4 Jul 2002 08:40:51 -0400 Received: from [203.200.20.226] by web20203.mail.yahoo.com via HTTP; Thu, 04 Jul 2002 05:40:50 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20020704124050.51946.qmail@web20203.mail.yahoo.com> Date: Thu, 4 Jul 2002 05:40:50 -0700 Reply-To: Mailing List Sender: Mailing List From: Swati Rastogi Subject: Re: Link Flap Damping Comments: cc: erblichs@EARTHLINK.NET To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Mitchell, Consider the following scenario .. ------------------- | network cloud x | ------------------- | | -------------- | router ABC |----------- -------------- | | | |2 |3 --------------- -------------- | router abc | | router abc'| --------------- -------------- | | |------------------ | --------------------- | network cloud y | --------------------- Now the link between router abc and ABC is constantly flapping after some time period. Say initially the link is up. Since the cost between ABC-abc is less than ABC-abc' the path ABC-abc will be chosen. Now the link goes down. Traffic will be blackholed till RouterDeadInterval after which the new path ABC-abc' will be taken. Now suppose the link comes up again after some time. Again the adjacency will form between abc-ABC and SPF will be run. ABC-abc will be selected over BC-abc' since the cost is less. All the data traffic will be re-routed thru ABC-abc. Now again if it goes down then we wait for RouterDeadInterval before we identify that the router is down. SPF is again triggered and ABC0-abc' is selected and traffic is re-routed. This can go on for a long time thereby severly damaging our throughput. We need a mechanism by which ABC recognizes that abc is unstable and that when it comes up again after flapping for many times .. its presence should be ignored. It should be ignored till the time ABC takes to be confident that the offending router/link will now not crash again! In most of the implementations the lower layers will inform ospf of a link going down and it will actually never have to wait for RouterDeadInterval before knowing that the remote speaker is down. But there can be cases (however very rare) when we dont receive the HELLOs. Traffic congestion in the network, system crashes, etc. IMHO we must have a mechanism to damp such flapping links/routers. What do others say? Regards, Swati ----- Original Message ----- From: "Erblichs" To: Sent: Thursday, July 04, 2002 3:52 AM Subject: Re: Link Flap Damping | Swati, | | My two cents.. | | I guess you could think that route flapping | is implicitly partially supported by a | number of features in OSPF. | | 1) The requirement to first set up a 2-way | connection between link partners. | | 2) The requirement to wait a certain amount | of time before elections are done. | | 3) That database description synchronization | is a multiple step process. Before routes are | exchanged. | | 4) We will re-xmit until we get an ack or | until dead-router-interval. | | 5) Etc... | | And that in a multi-access topology for OSPF | only adjs will be established between a subset of | the routers. Where BGP just about requires a mesh | topology (yes, exceptions are route reflectors, etc). | | Thus, the dependence is on the interval of the | flap. If the time while down is so short, it may | be acting somewhat in a "demand-circuit" like mode. | Why would we want to penalize the router when it | meets the dead router interval requirement? | | If the time while up is so short, it hopefully | cannot form an adjcency.. yes __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Thu Jul 4 10:20: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 KAA17894 for ; Thu, 4 Jul 2002 10:20:45 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0067EA1F@cherry.ease.lsoft.com>; Thu, 4 Jul 2002 10:21:34 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49161 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 4 Jul 2002 10:21:34 -0400 Received: from 203.178.142.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 4 Jul 2002 10:21:34 -0400 Received: from localhost (page.sfc.wide.ad.jp [203.178.143.89]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 777425D016 for ; Thu, 4 Jul 2002 23:21:32 +0900 (JST) References: <200207041102.UAA01810@one3463.ebina.hitachi.co.jp> <137b01c22352$584ee0d0$b4036c6b@sisodomain.com> 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: <20020704.231417.32240273.yasu@sfc.wide.ad.jp> Date: Thu, 4 Jul 2002 23:14:17 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: Link Flap Damping To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <137b01c22352$584ee0d0$b4036c6b@sisodomain.com> <3D23791C.78D604EF@earthlink.net> Precedence: list Content-Transfer-Encoding: 7bit Erblichs: erblichs> Thus, the dependence is on the interval of the erblichs> flap. If the time while down is so short, it may erblichs> be acting somewhat in a "demand-circuit" like mode. erblichs> Why would we want to penalize the router when it erblichs> meets the dead router interval requirement? I guess it's not true in real world: some vendor's OSPF is triggered by link's electrical up/down. Then it will be down regardless of router dead interval. Note: I think that link's electrical up/down trigger is not bad; it's needed for faster convergence. erblichs> If the time while up is so short, it hopefully erblichs> cannot form an adjcency.. yes, worse case if it was erblichs> elected the DR and could not form adjs because it was erblichs> flapping.. That's also not true, because adjacency can be outcome as the end result of transaction which consists of (as you said) retransmissions. yamate, manav: manav> | First issue is RouterDeadInterval. In OSPF, it is dampened that manav> | Hellos dropped by collision or any reasons by RouterDeadInterval manav> | timer. Thus when OSPF operators want to dampen link states to Down, manav> | it should be accomplished simply by large RouterDeadInterval, rather manav> | than implimentation any unusual logics. manav> manav> AFAIK the intention is to damp the flapping link which cannot be done by manav> simply increasing the RouterDeadInterval. If its value is increased then we manav> suffer from low convergence wherein a router takes larger time in manav> recognizing that a peer ospf router has gone down. This is definitely not manav> desired. What can perhaps be done is - each time a link flaps a figure of manav> merit should be increased. This value should be decayed with time so that manav> if the link remains stable for a long time (configurable) we can delete manav> whatever past history we were maintaining for that link. If the link again manav> flaps - increase the penalty. This goes on till the penalty reaches some manav> upper threshold upon which it is deemed to be unstable. Now the router manav> implementing flap damping should not include this router in its router LSA manav> (because we know from the past that it is very unstable and there is a high manav> probability that it will go down again). This router waits for some time. manav> If it finds that the router/link is now stable (its not flapping anymore) manav> it should originate a new router LSA wherein it mentions this link/router. manav> manav> This will only affect the normal working if the link/router is flapping manav> very frequently (subjective). I agree with manav. There must be more information from history of the link, but today we use only snapshot information of the link. manav> | Second issue is about IGPs' primary responsibility. I think that IGPs manav> | have two primary responsibilities of 1) notice new reachabilities manav> | rapidly and 2) notice new UNreachability rapidly. manav> manav> I guess that is what the routing protocols were designed for. manav> manav> | Thus, when manav> | implimentations want to dampen that Hellos not received recently from manav> | particular router, it should be ensured that the neighboring router is manav> | yet alive against of no Hellos received. manav> manav> This point was not very clear to me. Can you please expound on this? manav> manav> | manav> | Third issue is LSDB synchronization. When it is occured that the manav> | router has received no Hellos from particular router, if both router manav> manav> did not received HELLOs since how long? If it is the RouterDeadInterval manav> then the remote ospf speaking router will be assumed to be dead (or state manav> down). The adjacency breaks and the failure of LSDB synchronization is absolutely different things. If we have alternative paths, LSDB stays synchronized. And again, retransmission/acknowledgement will do something even on the flapping link about the LSDB synchronization (this will make us calm about using LSAs from the other side of flapping link.) Of course as manav saying, if router dead interval have past those LSAs will be implicitly out of SPF calculation. regards. yasu From owner-ospf@DISCUSS.MICROSOFT.COM Fri Jul 5 02:25: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 CAA12863 for ; Fri, 5 Jul 2002 02:25:11 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0067FC2A@cherry.ease.lsoft.com>; Fri, 5 Jul 2002 2:25:59 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 51296 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 5 Jul 2002 02:25:59 -0400 Received: from 133.145.224.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 5 Jul 2002 02:25:58 -0400 Received: from navsg1.hitachi.co.jp by hitpro.hitachi.co.jp (8.9.3/3.7W-hitpro) id PAA29726; Fri, 5 Jul 2002 15:25:57 +0900 (JST) Received: from navsg1.hitachi.co.jp by navsg1.hitachi.co.jp (8.9.3/3.7W-navsg1) id PAA14229; Fri, 5 Jul 2002 15:25:56 +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 M2002070515255523396 for ; Fri, 05 Jul 2002 15:25:56 +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 PAA21333 for ; Fri, 5 Jul 2002 15:25:56 +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 PAA01294 for ; Fri, 5 Jul 2002 15:25:54 +0900 (JST) Message-ID: <200207050625.PAA01294@one3463.ebina.hitachi.co.jp> Date: Fri, 5 Jul 2002 15:25:54 +0900 Reply-To: Mailing List Sender: Mailing List From: Yamate Keiichirou Subject: Re: Link Flap Damping To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Your message of "Thu, 04 Jul 2002 17:30:07 +0530." <137b01c22352$584ee0d0$b4036c6b@sisodomain.com> Precedence: list Manav writes: (snip) > flaps - increase the penalty. This goes on till the penalty reaches some > upper threshold upon which it is deemed to be unstable. Now the router > implementing flap damping should not include this router in its router LSA > (because we know from the past that it is very unstable and there is a high > probability that it will go down again). This router waits for some time. > If it finds that the router/link is now stable (its not flapping anymore) > it should originate a new router LSA wherein it mentions this link/router. I agree that there is some cases that it is useful to consider flapping link Down by dampening Link Up. I'd been misunderstanding about flapping link to be considered either Up or Down. > | Thus, when > | implimentations want to dampen that Hellos not received recently from > | particular router, it should be ensured that the neighboring router is > | yet alive against of no Hellos received. > This point was not very clear to me. Can you please expound on this? This means, when an router receive no Hellos, it can't be distinguished why it occurs, either neighboring router down, link down, or collision. But where flapping link to be considered Down, there is no need to distinguish it because any either reasons should cause the link to Down. So I agree it is likely no probrem in above. yasu wrote: > The adjacency breaks and the failure of LSDB synchronization is > absolutely different things. If we have alternative paths, LSDB stays > synchronized. And again, retransmission/acknowledgement will do > something even on the flapping link about the LSDB synchronization > (this will make us calm about using LSAs from the other side of > flapping link.) It is noted that topology/LSDB/SPF are reliable on assumption that any adjacencies ensure particular responsibilities, includeing LSDB synchronization. In other words, topology's reliability is constructed with responsibility on each adjacencies in the routing domain, and any adjacency SHOULD NOT depend on topology reliability. When some adjacencies rely on topology and topology relies on the adjacencies, then undesirable reliability (or unreliability) loop might be occured. Thus, such adjacencies should be omited from Router-LSA to advertise their dis-functionality wherever it is also reachable with any other adjacencies. ---- yamate@ebina.hitachi.co.jp. From owner-ospf@DISCUSS.MICROSOFT.COM Fri Jul 5 19:53: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 TAA25235 for ; Fri, 5 Jul 2002 19:53:46 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00680DD7@cherry.ease.lsoft.com>; Fri, 5 Jul 2002 19:54:34 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 54895 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 5 Jul 2002 19:54:33 -0400 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 5 Jul 2002 19:44:33 -0400 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00680D7D@cherry.ease.lsoft.com>; Fri, 5 Jul 2002 19:44:33 -0400 Message-ID: Date: Fri, 5 Jul 2002 19:44:33 -0400 Reply-To: Mailing List Sender: Mailing List From: Amit Sinha Subject: Question on "OSPF Protocol Analysis" (RFC1245) To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list All, I have a question regarding the OSPF protocol analysis (RFC1245). I want to know if the information in there is still valid, because it was done in 1991 with ospf traffic data collected on 3 different networks. Are those information still valid in the present context. Can I still use those information (like the number of LSAs per packet, SPF calculation frequency etc.) for my work? If not, where can I find similar information which is more current. Thanks and regards, Amit From owner-ospf*ospf-archive**LISTS*-IETF*-ORG@DISCUSS.MICROSOFT.COM Mon Jul 8 14:08: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 OAA28595 for ; Mon, 8 Jul 2002 14:08:57 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.0068523D@cherry.ease.lsoft.com>; Mon, 8 Jul 2002 14:09:42 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 64814 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 8 Jul 2002 14:09:41 -0400 Received: from 216.15.8.227 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 8 Jul 2002 14:09:41 -0400 Received: from jupiter.polarisnetworks.com ([192.168.0.19]) by mercury.polarisnetworks.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Mon, 8 Jul 2002 11:05:05 -0700 Received: by JUPITER with Internet Mail Service (5.5.2650.21) id <32SQFK28>; Mon, 8 Jul 2002 11:07:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Mon, 8 Jul 2002 11:07:57 -0700 Reply-To: Mailing List Sender: Mailing List From: "Cheng, Dean" Subject: Re: Congestion Avoidance & Control for OSPF Networks Comments: To: "Ash, Gerald R (Jerry), ALASO" To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Jerry et. al, Just have a general comment on your I-D. For congestion and overload problems that may occur in the networks where LS protocols used, there are quite a few possibilities that may have nothing to do with the LS protocols themselves, such as: 1) Implementation faults. 2) Configuration problems. This includes the wrong setting of protocols' parameters such as timer values. 3) Network design/planning problems. This includes, for example, too many nodes in a single area/peer-group, etc. It would be better in your I-D to list all the non-protocol related problems along with suggestions (I believe that would resolve most of the problems as seen), before looking at the protocols themselves. Enhancements to existing protocols, if any, may not be able to resolve networking problems that are caused by anyone of the above. Also, the routing protocol used in the Frame Relay network where a failure occurred (the example given in the Section 2) is actually not a link-state protocol at all. Regards, Dean > -----Original Message----- > From: Ash, Gerald R (Jerry), ALASO [mailto:gash@ATT.COM] > Sent: Wednesday, July 03, 2002 12:20 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: Congestion Avoidance & Control for OSPF Networks > > > > Hello John, All: > > Hopefully by now you've had chance to review our latest draft > on OSPF congestion control > http://search.ietf.org/internet-drafts/draft-ash-manral-ospf-c > ongestion-control-00.txt. > > As requested (by John), we've narrowed the scope of the work > to propose specific congestion control mechanisms not already > addressed by other documents in the OSPF WG. > > These mechanisms will prevent control overloads from bringing > down a network, as they have in the past (I give a brief > background below). > > We request your comments on our I-D. We also request your > suggestions for advancing the work in the working group. > > Thanks, > Jerry Ash > > Brief background: > > AT&T has suffered a few massive failures of operational > networks due to control overloads of link-state (LS) > protocols ('OSPF', 'PNNI', etc.). These outages are > documented and referenced in > http://search.ietf.org/internet-drafts/draft-ash-manral-ospf-c ongestion-control-00.txt and in http://search.ietf.org/internet-drafts/draft-ash-ospf-isis-congestion-contro l-02.txt. In the instances cited, the LS protocol overwhelmed the network with a control load 'storm' ('LSA overload'), which brought the network down, and then prevented its recovery. Fortunately such failures are very rare; however, 'rare' for such events is unacceptable, 'never' is the goal. Other service providers have experienced similar outages caused by similar problems. Such failures are not the fault of the service provider operation or the vendor/equipment implementation. They are due to shortcomings in the link-state protocols themselves -- thus the need for the enhancements proposed in the draft. The proposals in the draft will prevent such events from being triggered, and/or provide recovery mechanisms in case such events occur. The problem of control overload is becoming even more acute as LS protocols are enhanced to support new capabilities, such as: MPLS traffic engineering http://search.ietf.org/internet-drafts/draft-katz-yeung-ospf-traffic-06.txt, GMPLS http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-0 7.txt, multi-area TE http://www.ietf.org/internet-drafts/draft-cheng-ccamp-ospf-multiarea-te-exte nsions-00.txt, MPLS/DiffServ TE http://search.ietf.org/internet-drafts/draft-ietf-tewg-diff-te-reqts-05.txt, etc. With this ever advancing complexity, the need keeps increasing to address the stated problem, soon. From owner-ospf@DISCUSS.MICROSOFT.COM Mon Jul 8 21: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 VAA22451 for ; Mon, 8 Jul 2002 21:19:48 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00685F01@cherry.ease.lsoft.com>; Mon, 8 Jul 2002 21:20:38 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 66532 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 8 Jul 2002 21:20:38 -0400 Received: from 192.128.134.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 8 Jul 2002 21:20:38 -0400 Received: from attrh3i.attrh.att.com ([135.71.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id g690wow4004877 for ; Mon, 8 Jul 2002 20:20:37 -0500 (CDT) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh3i.attrh.att.com (6.5.019) id 3CE519BE01931427 for ospf@discuss.microsoft.com; Mon, 8 Jul 2002 21:20:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: Congestion Avoidance & Control for OSPF Networks Thread-Index: AcImqqQa5zOCv6KuT0W5xd7JxfiTmwAOfnQw Message-ID: <28F05913385EAC43AF019413F674A0170167B0ED@OCCLUST04EVS1.ugd.att.com> Date: Mon, 8 Jul 2002 21:20:37 -0400 Reply-To: Mailing List Sender: Mailing List From: "Ash, Gerald R (Jerry), ALASO" Subject: Re: Congestion Avoidance & Control for OSPF Networks To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA22451 Dean, > For congestion and overload problems that may occur > in the networks where LS protocols used, there are > quite a few possibilities that may have nothing > to do with the LS protocols themselves, such as: > > 1) Implementation faults. > > 2) Configuration problems. > This includes the wrong setting of protocols' > parameters such as timer values. > > 3) Network design/planning problems. > This includes, for example, too many nodes in > a single area/peer-group, etc. > > It would be better in your I-D to list all the > non-protocol related problems along with suggestions > (I believe that would resolve most of the problems > as seen), before looking at the protocols themselves. While all of the above, of course, can lead to network problems, none of what you list explains the protocol issues raised in the I-D. Detailed route cause analysis was performed for the failures experienced (as summarized in the I-D). The conclusions reached are consistent with the proposed protocol extensions. > Enhancements to existing protocols, if any, > may not be able to resolve networking problems > that are caused by anyone of the above. Simulations have shown us that the enhancements would resolve the problems identified. These are summarized in the I-D and further references are given for more details. > Also, the routing protocol used in the Frame Relay > network where a failure occurred (the example > given in the Section 2) is actually not a link-state > protocol at all. Indeed it was a link-state protocol. I'll contact you privately if you'd like more information. Regards, Jerry Ash From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jul 9 11:39: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 LAA29573 for ; Tue, 9 Jul 2002 11:39:38 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.006875DD@cherry.ease.lsoft.com>; Tue, 9 Jul 2002 11:40:30 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 69603 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 9 Jul 2002 11:40:30 -0400 Received: from 216.32.181.78 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 9 Jul 2002 11:30:30 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 9 Jul 2002 08:30:29 -0700 Received: from 193.116.20.220 by lw2fd.hotmail.msn.com with HTTP; Tue, 09 Jul 2002 15:30:29 GMT X-Originating-IP: [193.116.20.220] Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 09 Jul 2002 15:30:29.0362 (UTC) FILETIME=[8E5BD520:01C2275D] Message-ID: Date: Tue, 9 Jul 2002 16:30:29 +0100 Reply-To: Mailing List Sender: Mailing List From: gab jones Subject: line protocol for serial connection To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi guys, We have a ospf private network running frame relay and voip. we have have two connections from the core area 0 connecting two remote sites in two different areas. connection 1(area 1) has encapsulation type ppp and the other connection 2(area 2) has encapsulation frame relay. The connection 1(area 1) has a clockrate configured on the serial interface to enable clocking due to the network being a private network. The 2nd connection has encapsulation frame relay and the serial interface has the lmi type configured has dce to enable the line protocol up. But the 2nd connection running frame relay with lmi type configured has dce on the serial interface the router keeps putting a clock rate statement even when i issue a no clockrate command It just comes up again by default. Because i have enabled the serial interface to be dce there shouldnt be a clock rate set up. I have noticed that without a clock rate configured on the interface of connection 2 the link is very slow and the remote site is unable to send a ping request to the the hub site area 0. The router putting the default clockrate is the backbone router is a 7513 with ios version 11.1 regards, gab _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jul 10 20:11: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 UAA24157 for ; Wed, 10 Jul 2002 20:11:45 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0068AC10@cherry.ease.lsoft.com>; Wed, 10 Jul 2002 20:12:29 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 76880 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 10 Jul 2002 20:12:29 -0400 Received: from 206.54.51.125 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 10 Jul 2002 20:12:29 -0400 Received: from EXCH-CLUSTER.force10networks.com ([10.11.0.31]) by EXCH-SJC-IMS2.force10networks.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 10 Jul 2002 17:12:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2286F.A3F85285" Thread-Topic: Database synchronization during hitless restart Thread-Index: AcIob6PwetbHGPwJTRi1qkGQLAywFg== X-OriginalArrivalTime: 11 Jul 2002 00:12:28.0242 (UTC) FILETIME=[A4476B20:01C2286F] Message-ID: Date: Wed, 10 Jul 2002 17:12:27 -0700 Reply-To: Mailing List Sender: Mailing List From: Jason Chen Subject: Database synchronization during hitless restart To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This is a multi-part message in MIME format. ------_=_NextPart_001_01C2286F.A3F85285 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi,=20 As I understand from the John's hitless-restart draft, the helper side = always maintains a FULL state for the restarted neighbor. Once the = restarted router resume operation, it will operate the same as any other = OSPF router. It will perform the database exchange procedure.=20 My question is that how a restarted router to request database from his = helper since the neighbor state is FULL from the helper point of view. = Is there a conflict to RFC2328 ?=20 Thanks for the help, Jason=20 ------_=_NextPart_001_01C2286F.A3F85285 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Database synchronization during hitless restart

Hi,
As I understand from the John's = hitless-restart draft, the helper side always maintains a FULL state for = the restarted neighbor. Once the restarted router resume operation, it = will operate the same as any other OSPF router. It will perform the = database exchange procedure.

My question is that how a restarted = router to request database from his helper since the neighbor state is = FULL from the helper point of view. Is there a conflict to RFC2328 ? =

Thanks for the help,
Jason

------_=_NextPart_001_01C2286F.A3F85285-- From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jul 10 23:20: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 XAA28979 for ; Wed, 10 Jul 2002 23:20:45 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.0068B34E@cherry.ease.lsoft.com>; Wed, 10 Jul 2002 23:21:37 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 78172 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 10 Jul 2002 23:21:36 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 10 Jul 2002 23:21:35 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id CC5FC26281F for ; Wed, 10 Jul 2002 20: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: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D2CF9C2.2070300@redback.com> Date: Wed, 10 Jul 2002 23:21:38 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Database synchronization during hitless restart To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Jason wrote: > Hi, > As I understand from the John's hitless-restart draft, the helper side > always maintains a FULL state for the restarted neighbor. Jason, The helper router does not maintain FULL state - it continues originating router and network LSAs as if the restarting neighbor were in FULL state. > Once the > restarted router resume operation, it will operate the same as any other > OSPF router. It will perform the database exchange procedure. > > My question is that how a restarted router to request database from his > helper since the neighbor state is FULL from the helper point of view. > Is there a conflict to RFC2328 ? > > Thanks for the help, > Jason > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Jul 11 00:14:02 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 AAA29756 for ; Thu, 11 Jul 2002 00:14:02 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0068B3BC@cherry.ease.lsoft.com>; Thu, 11 Jul 2002 0:13:58 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 78371 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 11 Jul 2002 00:13:57 -0400 Received: from 203.190.133.225 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 11 Jul 2002 00:03:55 -0400 Received: from cyborg (IDENT:root@localhost [127.0.0.1]) by dharti.aplion.stpn.soft.net (8.11.2/8.11.2) with SMTP id g6B463J11669 for ; Thu, 11 Jul 2002 09:36:03 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Message-ID: <013001c22890$6ec7e170$feca64c0@cyborg> Date: Thu, 11 Jul 2002 09:37:10 +0530 Reply-To: Mailing List Sender: Mailing List From: Mayank Kumar Subject: ospf TE extensions latest drafts To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit hi does any body know of the latest draft relating to Traffic Engineering Extensions to OSPF (draft-katz-yeung-ospf-traffic-06.txt). This shows a expiry date of april 2002. So its already 3 months old. Has a revision to this draft been posted and if yes then where is it ???Becoz i cannot find a later version then this on the ietf working group. If any major modifications to this draft have proposed then somebody please tell me what are they ??? thanks and regds Mayank From owner-ospf@DISCUSS.MICROSOFT.COM Thu Jul 11 02:32: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 CAA10739 for ; Thu, 11 Jul 2002 02:32:52 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0068B685@cherry.ease.lsoft.com>; Thu, 11 Jul 2002 2:33:43 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 78756 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 11 Jul 2002 02:33:43 -0400 Received: from 135.207.30.103 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 11 Jul 2002 02:33:43 -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 A2F471E10F; Thu, 11 Jul 2002 02:33:42 -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 CAA07232; Thu, 11 Jul 2002 02:33:41 -0400 (EDT) Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id XAA09875; Wed, 10 Jul 2002 23:33:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Versions: dmail (solaris) 2.4c/makemail 2.9d Message-ID: <200207110633.XAA09875@windsor.research.att.com> Date: Wed, 10 Jul 2002 23:33:40 -0700 Reply-To: Mailing List Sender: Mailing List From: Bill Fenner Subject: OSPF WG Agenda for Yokohama Comments: To: agenda@ietf.org To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Dear all, Apologies for the late agenda, and double apologies if I've missed someone's request for meeting time - that's what agenda bashing is for. Open Shortest Path First IGP (ospf) WEDNESDAY, July 17 at 1530-1730 =============================== Meeting Facilitator: Bill Fenner AGENDA: Administriva 5m Scribe? Blue Sheets Agenda Bashing Document status update Bill 15m Goals & Milestones review Bill 10m draft-ietf-ospf-scalability-01.txt Gagan 15m draft-raggarwa-igp-cap-00.txt Rahul 15m draft-gupta-ospf-ospfv3-auth-00.txt Mukesh 15m From owner-ospf@DISCUSS.MICROSOFT.COM Thu Jul 11 13:00: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 NAA25637 for ; Thu, 11 Jul 2002 13:00:46 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0068C4B5@cherry.ease.lsoft.com>; Thu, 11 Jul 2002 13:00:51 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 81883 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 11 Jul 2002 13:00:51 -0400 Received: from 206.54.51.125 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 11 Jul 2002 13:00:51 -0400 Received: from EXCH-CLUSTER.force10networks.com ([10.11.0.32]) by EXCH-SJC-IMS2.force10networks.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 11 Jul 2002 10:00:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C228FC.82777DE9" Thread-Topic: draft-kompella-te-pathcomp-00.txt Thread-Index: AcIo/IIVvkIXbHaQRzul+htQ8Da2zA== X-OriginalArrivalTime: 11 Jul 2002 17:00:51.0238 (UTC) FILETIME=[82DFF460:01C228FC] Message-ID: Date: Thu, 11 Jul 2002 10:00:50 -0700 Reply-To: Mailing List Sender: Mailing List From: Jason Chen Subject: draft-kompella-te-pathcomp-00.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This is a multi-part message in MIME format. ------_=_NextPart_001_01C228FC.82777DE9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, If you have newer version of the above draft, would you send me a copy = ? Thanks, Jason ------_=_NextPart_001_01C228FC.82777DE9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-kompella-te-pathcomp-00.txt

Hi,

If you have  newer version of the = above draft, would you send me a copy ?

Thanks,
Jason

------_=_NextPart_001_01C228FC.82777DE9-- From owner-ospf@DISCUSS.MICROSOFT.COM Fri Jul 12 05:38: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 FAA13723 for ; Fri, 12 Jul 2002 05:38:17 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0068DEC5@cherry.ease.lsoft.com>; Fri, 12 Jul 2002 5:38:51 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 85269 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 12 Jul 2002 05:38:51 -0400 Received: from 212.113.174.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 12 Jul 2002 05:28:51 -0400 Received: from oemcomputer ([213.22.242.75]) by smtp.netcabo.pt with Microsoft SMTPSVC(5.0.2195.4905); Fri, 12 Jul 2002 10:27:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 12 Jul 2002 09:27:24.0009 (UTC) FILETIME=[54840590:01C22986] Message-ID: Date: Fri, 12 Jul 2002 10:18:48 +0100 Reply-To: Mailing List Sender: Mailing List From: "Patricia macedo (NC)" Subject: OSPF and gated To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <013001c22890$6ec7e170$feca64c0@cyborg> Precedence: list Content-Transfer-Encoding: 8bit Hi does any body know where can I find specif documentation about implementation of OSPF in gateD ? I'm trying to make some changes to gateD source code to implement some changes on OSPF protocol, but it´s quite hard without any documentation about the structure of the programa . thanks and regards Patrícia Macedo From owner-ospf@DISCUSS.MICROSOFT.COM Fri Jul 12 07:16: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 HAA17105 for ; Fri, 12 Jul 2002 07:16:26 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0068DE5F@cherry.ease.lsoft.com>; Fri, 12 Jul 2002 7:17:17 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 85889 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 12 Jul 2002 07:17:17 -0400 Received: from 192.51.44.37 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 12 Jul 2002 07:07:16 -0400 Received: from m4.gw.fujitsu.co.jp by fgwmail7.fujitsu.co.jp (8.9.3/3.7W-MX0205-Fujitsu Gateway) id UAA03515 for ; Fri, 12 Jul 2002 20:07:14 +0900 (JST) (envelope-from sasaki@soft.net.fujitsu.co.jp) Received: from mailhost.soft.net.fujitsu.co.jp by m4.gw.fujitsu.co.jp (8.9.3/3.7W-0207-Fujitsu Domain Master) id UAA01654 for ; Fri, 12 Jul 2002 20:07:14 +0900 (JST) (envelope-from sasaki@soft.net.fujitsu.co.jp) Received: from [10.22.158.220] (dhcp158220.nd.net.fujitsu.co.jp [10.22.158.220]) by mailhost.soft.net.fujitsu.co.jp (8.11.6/8.11.6) with ESMTP id g6CB7Dh07281 for ; Fri, 12 Jul 2002 20:07:14 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.01 Message-ID: <20020712200239.5975.SASAKI@soft.net.fujitsu.co.jp> Date: Fri, 12 Jul 2002 20:07:13 +0900 Reply-To: Mailing List Sender: Mailing List From: Taisuke Sasaki Subject: OSPFv3 route calculation To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I have a question about the OSPFv3 route calculation. Suppose the network and condition below: 1) R1: interface cost to the Network N1 is 10. 2) R2: interface cost to the Network N1 is 1. 3) Network N1: R1 is DR and R2 is BDR. 4) prefix C is assigned in R1, but not in R2. 5) all interfaces belong to the OSPFv3 backbone area. ----+---------------+----- Network N1 prefix A | |prefix A prefix C | | +-+-+ +-+-+ |R1 | |R2 | +-+-+ +-+-+ | | ----+------+--------+----- Network N2 | +-+-+ |R3 | +---+ R1 originates a Network-LSA and an Intra-Area-Prefix-LSA like this: Network-LSA has 2 active neighbors(R1 and R2). Intra-Area-Prefix-LSA has 2 prefixes(prefix A and prefix C). When R3 calculates the nexthop to the prefix C, R3 selects the R2 because R2's interface cost is smaller than R1's. However, R2 doesn't know the nexthop to the prefix C. I think it is necessary for R2 to calculate the nexthop to the prefix C from its R1's Link-LSA, but I cannot find the corresponding statement in rfc2740. --- Taisuke Sasaki From owner-ospf@DISCUSS.MICROSOFT.COM Fri Jul 12 09:00: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 JAA20605 for ; Fri, 12 Jul 2002 09:00:39 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.0068E060@cherry.ease.lsoft.com>; Fri, 12 Jul 2002 9:01:31 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 86524 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 12 Jul 2002 09:01:31 -0400 Received: from 203.178.142.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 12 Jul 2002 09:01:30 -0400 Received: from localhost (page.sfc.wide.ad.jp [203.178.143.89]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 410665D03A; Fri, 12 Jul 2002 22:01:29 +0900 (JST) References: <20020712200239.5975.SASAKI@soft.net.fujitsu.co.jp> 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: <20020712.215400.82051721.yasu@sfc.wide.ad.jp> Date: Fri, 12 Jul 2002 21:54:00 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: OSPFv3 route calculation Comments: To: sasaki@SOFT.NET.FUJITSU.CO.JP To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20020712200239.5975.SASAKI@soft.net.fujitsu.co.jp> Precedence: list Content-Transfer-Encoding: 7bit sasaki> I have a question about the OSPFv3 route calculation. sasaki> Suppose the network and condition below: sasaki> sasaki> 1) R1: interface cost to the Network N1 is 10. sasaki> 2) R2: interface cost to the Network N1 is 1. sasaki> 3) Network N1: R1 is DR and R2 is BDR. sasaki> 4) prefix C is assigned in R1, but not in R2. sasaki> 5) all interfaces belong to the OSPFv3 backbone area. sasaki> sasaki> ----+---------------+----- Network N1 sasaki> prefix A | |prefix A sasaki> prefix C | | sasaki> +-+-+ +-+-+ sasaki> |R1 | |R2 | sasaki> +-+-+ +-+-+ sasaki> | | sasaki> ----+------+--------+----- Network N2 sasaki> | sasaki> +-+-+ sasaki> |R3 | sasaki> +---+ sasaki> sasaki> R1 originates a Network-LSA and an Intra-Area-Prefix-LSA like this: sasaki> Network-LSA has 2 active neighbors(R1 and R2). sasaki> Intra-Area-Prefix-LSA has 2 prefixes(prefix A and prefix C). sasaki> sasaki> When R3 calculates the nexthop to the prefix C, sasaki> R3 selects the R2 because R2's interface cost is smaller than R1's. sasaki> However, R2 doesn't know the nexthop to the prefix C. sasaki> sasaki> I think it is necessary for R2 to calculate the nexthop to the sasaki> prefix C from its R1's Link-LSA, but I cannot find the corresponding sasaki> statement in rfc2740. Hi. I think there's no detailed statement in RFC. I thought R2 should use NDP to resolve the actual nexthop on N1 in this case (since it's attached network), and am doing do so in Zebra. regards. yasu From owner-ospf@DISCUSS.MICROSOFT.COM Fri Jul 12 15:45: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 PAA11621 for ; Fri, 12 Jul 2002 15:45:46 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0068E83D@cherry.ease.lsoft.com>; Fri, 12 Jul 2002 15:46:38 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 88329 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 12 Jul 2002 15:46:37 -0400 Received: from 171.68.227.69 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 12 Jul 2002 15:46:37 -0400 Received: from cisco.com (dhcp-171-69-101-25.cisco.com [171.69.101.25]) by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id MAA13833 for ; Fri, 12 Jul 2002 12:46:37 -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: <20020712200239.5975.SASAKI@soft.net.fujitsu.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3D2F321C.1766A50D@cisco.com> Date: Fri, 12 Jul 2002 12:46:36 -0700 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: OSPFv3 route calculation To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Taisuke Taisuke Sasaki wrote: > I have a question about the OSPFv3 route calculation. > Suppose the network and condition below: > > 1) R1: interface cost to the Network N1 is 10. > 2) R2: interface cost to the Network N1 is 1. > 3) Network N1: R1 is DR and R2 is BDR. > 4) prefix C is assigned in R1, but not in R2. > 5) all interfaces belong to the OSPFv3 backbone area. > > ----+---------------+----- Network N1 > prefix A | |prefix A > prefix C | | > +-+-+ +-+-+ > |R1 | |R2 | > +-+-+ +-+-+ > | | > ----+------+--------+----- Network N2 > | > +-+-+ > |R3 | > +---+ > > R1 originates a Network-LSA and an Intra-Area-Prefix-LSA like this: > Network-LSA has 2 active neighbors(R1 and R2). > Intra-Area-Prefix-LSA has 2 prefixes(prefix A and prefix C). > > When R3 calculates the nexthop to the prefix C, > R3 selects the R2 because R2's interface cost is smaller than R1's. > However, R2 doesn't know the nexthop to the prefix C. > R2 does know R1's next hop through Link-LSA ( each router generate a link-LSA for each attached segment ) once R2 knows the next hop which is a link-local address, ND will take care of layer3- layer2 mapping to send the packet Sina > > I think it is necessary for R2 to calculate the nexthop to the > prefix C from its R1's Link-LSA, but I cannot find the corresponding > statement in rfc2740. > > --- > Taisuke Sasaki From owner-ospf@DISCUSS.MICROSOFT.COM Sun Jul 14 23:45: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 XAA28877 for ; Sun, 14 Jul 2002 23:45:37 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.006920ED@cherry.ease.lsoft.com>; 14 Jul 2002 23:46:13 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 95324 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 14 Jul 2002 23:46:13 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sun, 14 Jul 2002 23:46:13 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Sun, 14 Jul 2002 23:46:08 -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: Sun, 14 Jul 2002 23:48:43 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Congestion Avoidance & Control for OSPF Networks To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Dean, Thanks a lot for the comments and sorry for the extremely delayed response(I have been away from my mails for quite some time now). I will just add "my little bit" to what Jerry has already stated. > It would be better in your I-D to list all the > non-protocol related problems along with suggestions > (I believe that would resolve most of the problems > as seen), before looking at the protocols themselves. I agree it would be nice to detail a list of reasons that could cause similar problems. The problems that you have stated i.e. "implementation faults" can cause a problem as seen by AT&T. > Enhancements to existing protocols, if any, > may not be able to resolve networking problems > that are caused by anyone of the above. For "implementation faults"(or others as you stated) a protocol solution isn't the best way however the solutions provided in the draft do minimize the effect of such a problem by adding minimal functionality to the protocol. Besides a lot of suggestions provided in the draft do not require changes to the protocol but suggest basic functionality required in an implementation to alleviate such problems. Thanks, Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jul 17 07:59: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 HAA13744 for ; Wed, 17 Jul 2002 07:59:15 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00696851@cherry.ease.lsoft.com>; Wed, 17 Jul 2002 8:00:08 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 105197 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 17 Jul 2002 08:00:08 -0400 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 17 Jul 2002 08:00:08 -0400 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00696834@cherry.ease.lsoft.com>; Wed, 17 Jul 2002 8:00:08 -0400 Message-ID: Date: Wed, 17 Jul 2002 08:00:08 -0400 Reply-To: Mailing List Sender: Mailing List From: Murali Krishna Subject: Questions on Interfaces To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list I have some very basic questions. 1. What exactly are interfaces on routers? In section 2.1 in RFC2328, for p-to-p networks, the link-state-database graph has an edge between a. two routers and b. between a router and the interface on the other router. --What does this mean? --What is the difference between an edge from RT1 to RT2 and one from RT1 to Ib? --If no IP address is assigned to the p-to-p interfaces on the two routers, will there be no entry in the link-state-database graph for these interfaces? --If no IP address is assigned to the interfaces, what sort of communication takes place between the two routers? (diagram pasted below) **FROM** * |RT1|RT2| +---+Ia +---+ * ------------ |RT1|------|RT2| T RT1| | X | +---+ Ib+---+ O RT2| X | | * Ia| | X | * Ib| X | | Physical point-to-point networks In case of pt-to-multipoint networks, each router has a stub connection to its own IP interface address. --Why is this so? (if this is because the interface address cannot be broadcase since p-to-mp is a non broadcase network, how is the establishment of such a stub connection achieved?) 2. Page 20. Figure 3. Why does the directed graph for the autonomous system (Fig 2 page 19) not have entries for the two interfaces Ia and Ib on RT6 and RT 10, but are accounted for in the SPF Tree for RT 6 in page 22 Figure 5.? 3. Why do arcs from Networks to Routers have cost 0? If there are other RFCs that i need to go thru before referring to the OSPF RFC, which may answer these basic questions please mention them. Thanks Murali. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jul 17 18:08: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 SAA01077 for ; Wed, 17 Jul 2002 18:08:30 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00697A1C@cherry.ease.lsoft.com>; Wed, 17 Jul 2002 18:09:26 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 106862 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 17 Jul 2002 18:09:26 -0400 Received: from 216.136.174.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 17 Jul 2002 17:59:25 -0400 Received: from [12.36.127.194] by web12905.mail.yahoo.com via HTTP; Wed, 17 Jul 2002 14:59:25 PDT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-198891840-1026943165=:2917" Message-ID: <20020717215925.3232.qmail@web12905.mail.yahoo.com> Date: Wed, 17 Jul 2002 14:59:25 -0700 Reply-To: Mailing List Sender: Mailing List From: Vinay Ravuri Subject: OSPF Test Tool ? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --0-198891840-1026943165=:2917 Content-Type: text/plain; charset=us-ascii I am looking to do conformance and stress test against a OSPFv2 stack/router. I was wondering if anyone is aware of a free ospf tool (preferably with source code) that can do this? Any help is grealy appreciated. Cheers, Vinay vinay_usenet@yahoo.com --------------------------------- Do You Yahoo!? Yahoo! Autos - Get free new car price quotes --0-198891840-1026943165=:2917 Content-Type: text/html; charset=us-ascii I am looking to do conformance and stress test against a
OSPFv2 stack/router.  I was wondering if anyone
is aware of a free ospf tool (preferably with source
code) that can do this?

Any help is grealy appreciated.

Cheers,
Vinay
vinay_usenet@yahoo.com


Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes --0-198891840-1026943165=:2917-- From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jul 17 18:29: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 SAA01390 for ; Wed, 17 Jul 2002 18:29:56 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00697AB6@cherry.ease.lsoft.com>; Wed, 17 Jul 2002 18:30:50 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 106954 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 17 Jul 2002 18:30:49 -0400 Received: from 129.192.64.128 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 17 Jul 2002 18:20:49 -0400 Received: from pralay (devdhcp63138.dev.acc.am.ericsson.se [129.192.63.138]) by mailsrv.acc.com (8.12.3/8.12.3) with SMTP id g6HMKiBI023962 for ; Wed, 17 Jul 2002 15:20:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0105_01C22DA4.D0A70B50" 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 X-Scanned-By: MIMEDefang 2.8 Message-ID: Date: Wed, 17 Jul 2002 15:15:41 -0700 Reply-To: Mailing List Sender: Mailing List From: Kameswara Rao Avasarala Subject: Re: OSPF Test Tool ? To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20020717215925.3232.qmail@web12905.mail.yahoo.com> Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0105_01C22DA4.D0A70B50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Vinay, You can try the OSPFD at http://ospf.org/ospfd2_0/index.html . Hope this helps, Kamesh. Kameswara Rao Avasarala Software Engineer Ericsson Inc Telephone: Work:805-562-6212 Resi: 805-562-8841 -----Original Message----- From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Vinay Ravuri Sent: Wednesday, July 17, 2002 2:59 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: OSPF Test Tool ? I am looking to do conformance and stress test against a OSPFv2 stack/router. I was wondering if anyone is aware of a free ospf tool (preferably with source code) that can do this? Any help is grealy appreciated. Cheers, Vinay vinay_usenet@yahoo.com ---------------------------------------------------------------------------- -- Do You Yahoo!? Yahoo! Autos - Get free new car price quotes ------=_NextPart_000_0105_01C22DA4.D0A70B50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Vinay,
          &nbs= p; You=20 can try the OSPFD at http://ospf.org/ospfd2_0/ind= ex.html .
Hope this=20 helps,
Kamesh.
 
Kameswara Rao = Avasarala
Software = Engineer
Ericsson = Inc
Telephone:
Work:805-562-6212
Resi:=20 805-562-8841
 
 
-----Original Message-----
From: Mailing List=20 [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Vinay=20 Ravuri
Sent: Wednesday, July 17, 2002 2:59 PM
To:=20 OSPF@DISCUSS.MICROSOFT.COM
Subject: OSPF Test Tool=20 ?

I am looking to do conformance and stress test = against=20 a
OSPFv2 stack/router.  I was wondering if anyone
is = aware of=20 a free ospf tool (preferably with source
code) that can do = this?

Any=20 help is grealy appreciated.

Cheers,
Vinay
vinay_usenet@yahoo.com


Do You Yahoo!?
Yahoo! = Autos -=20 Get free new car price quotes
------=_NextPart_000_0105_01C22DA4.D0A70B50-- From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jul 17 18:35: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 SAA01488 for ; Wed, 17 Jul 2002 18:35:32 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.006979E6@cherry.ease.lsoft.com>; Wed, 17 Jul 2002 18:36:29 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 106957 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 17 Jul 2002 18:36:29 -0400 Received: from 65.223.109.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 17 Jul 2002 18:26:28 -0400 Received: from ipinfusion.com (vividh.ipinfusion.com [10.10.0.80] (may be forged)) by gateway.ipinfusion.com (8.11.0/8.11.0) with ESMTP id g6HMO0H31020 for ; Wed, 17 Jul 2002 15:24:00 -0700 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 References: <20020717215925.3232.qmail@web12905.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D35EE72.4030205@ipinfusion.com> Date: Wed, 17 Jul 2002 15:23:46 -0700 Reply-To: Mailing List Sender: Mailing List From: Vividh Siddha Subject: Re: OSPF Test Tool ? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Try www.zebra.org. Its not a test tool but a full OSPF implementation against which you can test. Vinay Ravuri wrote: > I am looking to do conformance and stress test against a > OSPFv2 stack/router. I was wondering if anyone > is aware of a free ospf tool (preferably with source > code) that can do this? > > Any help is grealy appreciated. > > Cheers, > Vinay > vinay_usenet@yahoo.com > > > > ------------------------------------------------------------------------ > Do You Yahoo!? > Yahoo! Autos - Get free new car price quotes From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jul 17 18:35: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 SAA01503 for ; Wed, 17 Jul 2002 18:35:39 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00697A42@cherry.ease.lsoft.com>; Wed, 17 Jul 2002 18:36:35 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 107094 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 17 Jul 2002 18:36:35 -0400 Received: from 216.136.174.69 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 17 Jul 2002 18:36:34 -0400 Received: from [12.36.127.194] by web12902.mail.yahoo.com via HTTP; Wed, 17 Jul 2002 15:36:34 PDT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-64928751-1026945394=:49322" Message-ID: <20020717223634.51715.qmail@web12902.mail.yahoo.com> Date: Wed, 17 Jul 2002 15:36:34 -0700 Reply-To: Mailing List Sender: Mailing List From: Vinay Ravuri Subject: Re: OSPF Test Tool ? To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list --0-64928751-1026945394=:49322 Content-Type: text/plain; charset=us-ascii Hi Kamesh, Thanks for the info. I am aware of moy's ospfd and zebra implementations, but they are not test tools they just act as another router. I wanted to simulate multiple interfaces, routers, area's etc from one node and do some conformance stuff to reproduce some problems I am having with my stack. If I can't find anything I will probably end up using ospfd or zebra as you suggested. -Vinay Kameswara Rao Avasarala wrote: Hi Vinay, You can try the OSPFD at http://ospf.org/ospfd2_0/index.html .Hope this helps,Kamesh. Kameswara Rao AvasaralaSoftware EngineerEricsson IncTelephone:Work:805-562-6212Resi: 805-562-8841 -----Original Message----- From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Vinay Ravuri Sent: Wednesday, July 17, 2002 2:59 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: OSPF Test Tool ? I am looking to do conformance and stress test against a OSPFv2 stack/router. I was wondering if anyone is aware of a free ospf tool (preferably with source code) that can do this? Any help is grealy appreciated. Cheers, Vinay vinay_usenet@yahoo.com --------------------------------- Do You Yahoo!? Yahoo! Autos - Get free new car price quotes --------------------------------- Do You Yahoo!? Yahoo! Autos - Get free new car price quotes --0-64928751-1026945394=:49322 Content-Type: text/html; charset=us-ascii

Hi Kamesh,

    Thanks for the info.  I am aware of moy's ospfd and zebra implementations, but they are not test tools they just act as another router.  I wanted to simulate multiple interfaces, routers, area's etc from one node and do some conformance stuff to reproduce some problems I am having with my stack.

   If I can't find anything I will probably end up using ospfd or zebra as you suggested.

-Vinay

  Kameswara Rao Avasarala <kameswara.rao@ERICSSON.COM> wrote:

Hi Vinay,
            You can try the OSPFD at http://ospf.org/ospfd2_0/index.html .
Hope this helps,
Kamesh.
 
Kameswara Rao Avasarala
Software Engineer
Ericsson Inc
Telephone:
Work:805-562-6212
Resi: 805-562-8841
 
 
-----Original Message-----
From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Vinay Ravuri
Sent: Wednesday, July 17, 2002 2:59 PM
To: OSPF@DISCUSS.MICROSOFT.COM
Subject: OSPF Test Tool ?

I am looking to do conformance and stress test against a
OSPFv2 stack/router.  I was wondering if anyone
is aware of a free ospf tool (preferably with source
code) that can do this?

Any help is grealy appreciated.

Cheers,
Vinay
vinay_usenet@yahoo.com


Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes


Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes --0-64928751-1026945394=:49322-- From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jul 17 18:42: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 SAA01596 for ; Wed, 17 Jul 2002 18:42:29 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00697A96@cherry.ease.lsoft.com>; Wed, 17 Jul 2002 18:43:26 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 107070 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 17 Jul 2002 18:43:26 -0400 Received: from 141.156.71.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 17 Jul 2002 18:33:26 -0400 Received: from WTN10069.opnet.com (unverified) by smtp1.opnet.com (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Wed, 17 Jul 2002 18:32:41 -0400 X-Sender: svenkatachalam@mail.opnet.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_773499984==_.ALT" Message-ID: <5.1.0.14.2.20020717183219.00a7c270@mail.opnet.com> Date: Wed, 17 Jul 2002 18:33:19 -0400 Reply-To: Mailing List Sender: Mailing List From: "Senthil K. Venkatachalam" Subject: Re: OSPF Test Tool ? To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20020717215925.3232.qmail@web12905.mail.yahoo.com> Precedence: list --=====================_773499984==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Try RPS (Routing Protocol Simulator), available with the GateD code. Regards, Senthil. At 02:59 PM 7/17/2002 -0700, you wrote: >I am looking to do conformance and stress test against a >OSPFv2 stack/router. I was wondering if anyone >is aware of a free ospf tool (preferably with source >code) that can do this? > >Any help is grealy appreciated. > >Cheers, >Vinay >vinay_usenet@yahoo.com > > > >Do You Yahoo!? >Yahoo! Autos - Get free new car price quotes --=====================_773499984==_.ALT Content-Type: text/html; charset="us-ascii" Try RPS (Routing Protocol Simulator), available with the GateD code.

Regards,
Senthil.

At 02:59 PM 7/17/2002 -0700, you wrote:
I am looking to do conformance and stress test against a
OSPFv2 stack/router.  I was wondering if anyone
is aware of a free ospf tool (preferably with source
code) that can do this?

Any help is grealy appreciated.

Cheers,
Vinay
vinay_usenet@yahoo.com



Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
--=====================_773499984==_.ALT-- From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jul 17 19:32: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 TAA02401 for ; Wed, 17 Jul 2002 19:32:58 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00697B98@cherry.ease.lsoft.com>; Wed, 17 Jul 2002 19:33:54 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 107284 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 17 Jul 2002 19:33:53 -0400 Received: from 131.241.15.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 17 Jul 2002 19:33:53 -0400 Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com [131.241.31.2]) by mail4.nec.com (/) with ESMTP id g6HNXoe03656 for ; Wed, 17 Jul 2002 16:33:50 -0700 (PDT) Received: from necsun.tdd.sj.nec.com (localhost [127.0.0.1]) by netkeeper.sj.nec.com (8.9.1a/8.9.1) with ESMTP id QAA10272 for ; Wed, 17 Jul 2002 16:33:44 -0700 (PDT) Received: from bunny.tdd.sj.nec.com by necsun.tdd.sj.nec.com with ESMTP id g6HNR994001791 for ; Wed, 17 Jul 2002 16:27:09 -0700 (PDT) Received: from ems12 (ems12 [131.241.5.17]) by bunny.tdd.sj.nec.com with SMTP id g6HNR7Jv001032 for ; Wed, 17 Jul 2002 16:27:07 -0700 (PDT) References: <20020717215925.3232.qmail@web12905.mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008F_01C22DAF.F4935C20" 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: <009201c22dea$a1248ec0$1105f183@b90.tdd.sj.nec.com> Date: Wed, 17 Jul 2002 16:35:26 -0700 Reply-To: Mailing List Sender: Mailing List From: kamatchi soundaram Subject: Re: OSPF Test Tool ? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_008F_01C22DAF.F4935C20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I don't think any free tool is available for OSPF conformance testing = as u r expecting to simulate a large network and test. But if u really looking for a good tool, and doesn't bother about the = cost, then there is a tool u can go for it.. =20 It's "ANVL" OSPF conformance tool. I think it's a product of Midnight = networks. regards, GKS. ----- Original Message -----=20 From: Vinay Ravuri=20 To: OSPF@discuss.microsoft.com=20 Sent: Wednesday, July 17, 2002 2:59 PM Subject: OSPF Test Tool ? I am looking to do conformance and stress test against a OSPFv2 stack/router. I was wondering if anyone is aware of a free ospf tool (preferably with source code) that can do this? Any help is grealy appreciated. Cheers, Vinay vinay_usenet@yahoo.com -------------------------------------------------------------------------= ----- Do You Yahoo!? Yahoo! Autos - Get free new car price quotes ------=_NextPart_000_008F_01C22DAF.F4935C20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
 I don't think any free tool is = available for=20 OSPF conformance testing as u r expecting to simulate a large network = and=20 test.
 
 But if u really looking for a = good tool, and=20 doesn't bother about the cost, then there is a tool u can go for=20 it..
 
 It's "ANVL" OSPF conformance = tool. I=20 think it's a product of  Midnight networks.
 
regards,
GKS.
 
----- Original Message -----
From:=20 Vinay=20 Ravuri
Sent: Wednesday, July 17, 2002 = 2:59=20 PM
Subject: OSPF Test Tool ?

I am looking to do conformance and stress test against=20 a
OSPFv2 stack/router.  I was wondering if anyone
is = aware of=20 a free ospf tool (preferably with source
code) that can do = this?

Any=20 help is grealy appreciated.

Cheers,
Vinay
vinay_usenet@yahoo.com


Do You Yahoo!?
Yahoo! = Autos -=20 Get free new car price quotes ------=_NextPart_000_008F_01C22DAF.F4935C20-- From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jul 17 22:34: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 WAA08072 for ; Wed, 17 Jul 2002 22:34:41 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00697F40@cherry.ease.lsoft.com>; Wed, 17 Jul 2002 22:35:33 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 107644 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 17 Jul 2002 22:35:32 -0400 Received: from 155.226.10.207 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 17 Jul 2002 22:35:32 -0400 Received: from smtp.adc.com (localhost [127.0.0.1]) by smtp.adc.com (8.11.1/8.11.1) with ESMTP id g6I2ZVw02709 for ; Wed, 17 Jul 2002 21:35:31 -0500 (CDT) Received: from rtegrp1 (bas-195-227.basystems.com [146.71.195.227]) by smtp.adc.com (8.11.1/8.11.1) with SMTP id g6I2ZTM02693 for ; Wed, 17 Jul 2002 21:35:30 -0500 (CDT) References: <20020717215925.3232.qmail@web12905.mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C5_01C22E4F.3FBFBE60" 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: <00ca01c22e03$d1625fe0$e3c34792@basystems.com> Date: Thu, 18 Jul 2002 11:35:42 +0900 Reply-To: Mailing List Sender: Mailing List From: Igor Lasic Subject: Re: OSPF Test Tool ? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_00C5_01C22E4F.3FBFBE60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable How about Zebra ? zebra.org ----- Original Message -----=20 From: Vinay Ravuri=20 To: OSPF@DISCUSS.MICROSOFT.COM=20 Sent: Thursday, July 18, 2002 6:59 AM Subject: OSPF Test Tool ? I am looking to do conformance and stress test against a OSPFv2 stack/router. I was wondering if anyone is aware of a free ospf tool (preferably with source code) that can do this? Any help is grealy appreciated. Cheers, Vinay vinay_usenet@yahoo.com -------------------------------------------------------------------------= ----- Do You Yahoo!? Yahoo! Autos - Get free new car price quotes ------=_NextPart_000_00C5_01C22E4F.3FBFBE60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
How about Zebra ?
zebra.org
 
----- Original Message -----
From:=20 Vinay=20 Ravuri
Sent: Thursday, July 18, 2002 = 6:59=20 AM
Subject: OSPF Test Tool ?

I am looking to do conformance and stress test against=20 a
OSPFv2 stack/router.  I was wondering if anyone
is = aware of=20 a free ospf tool (preferably with source
code) that can do = this?

Any=20 help is grealy appreciated.

Cheers,
Vinay
vinay_usenet@yahoo.com


Do You Yahoo!?
Yahoo! = Autos -=20 Get free new car price quotes ------=_NextPart_000_00C5_01C22E4F.3FBFBE60-- From owner-ospf@DISCUSS.MICROSOFT.COM Thu Jul 18 04:38: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 EAA26127 for ; Thu, 18 Jul 2002 04:38:23 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00698BDD@cherry.ease.lsoft.com>; Thu, 18 Jul 2002 4:39:19 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 108491 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 18 Jul 2002 04:39:19 -0400 Received: from 192.67.198.65 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 18 Jul 2002 04:29:19 -0400 Received: from giga-stream.de (maxtnt-013.telip.uni-sb.de [134.96.70.140]) by post.webmailer.de (8.9.3/8.8.7) with SMTP id KAA20157 for ; Thu, 18 Jul 2002 10:29:17 +0200 (MET DST) X-Mailer: Dirk Jacob's registered AK-Mail 3.11 [ger] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200207180829.KAA20157@post.webmailer.de> Date: Thu, 18 Jul 2002 10:28:46 +0200 Reply-To: Mailing List Sender: Mailing List From: Dirk Jacob Subject: Re: OSPF Test Tool ? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi. Have you looked at www.iol.unh.edu? They provide test suites for some routing protocols, including OSPF. There is not a test tool, but they provide a comprehensive set of test scenarios, which you can use for testing. Hope that helps. Dirk From owner-ospf@DISCUSS.MICROSOFT.COM Thu Jul 18 09:57: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 JAA02729 for ; Thu, 18 Jul 2002 09:57:39 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.0069921F@cherry.ease.lsoft.com>; Thu, 18 Jul 2002 9:58:33 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 109373 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 18 Jul 2002 09:58:33 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 18 Jul 2002 09:58:33 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Jul 2002 09:58:26 -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, 18 Jul 2002 10:00:59 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Questions on Interfaces To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Murali, I will try to answer your queries. Replies inline prefixed by a VM>. Thanks, Vishwas -----Original Message----- From: Murali Krishna [mailto:muralikrishna@SOFTHOME.NET] Sent: Wednesday, July 17, 2002 5:30 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Questions on Interfaces I have some very basic questions. 1. What exactly are interfaces on routers? VM> Interfaces are the points of connection on the router to the network. In section 2.1 in RFC2328, for p-to-p networks, the link-state-database graph has an edge between a. two routers and b. between a router and the interface on the other router. --What does this mean? VM> a. means you can reach from router 1 to router 2. b. means you can reach the address Ib. The idea of a. is that we can reach other networks from RT1 thru RT2. b. however only means that you can reach the address Ib. --What is the difference between an edge from RT1 to RT2 and one from RT1 to Ib? VM> Explained above. Also see section 12.4.1 in the RFC. It will clarify a lot of things. --If no IP address is assigned to the p-to-p interfaces on the two routers, will there be no entry in the link-state-database graph for these interfaces? VM> Yes there will be no stub entries in case of unnumbered links. Section 12.4.1.1. --If no IP address is assigned to the interfaces, what sort of communication takes place between the two routers? VM> We still send Hellos to ALLOSPFRouters multicast address. Is this what you are looking for? (diagram pasted below) **FROM** * |RT1|RT2| +---+Ia +---+ * ------------ |RT1|------|RT2| T RT1| | X | +---+ Ib+---+ O RT2| X | | * Ia| | X | * Ib| X | | Physical point-to-point networks In case of pt-to-multipoint networks, each router has a stub connection to its own IP interface address. --Why is this so? (if this is because the interface address cannot be broadcase since p-to-mp is a non broadcase network, how is the establishment of such a stub connection achieved?) 2. Page 20. Figure 3. Why does the directed graph for the autonomous system (Fig 2 page 19) not have entries for the two interfaces Ia and Ib on RT6 and RT 10, but are accounted for in the SPF Tree for RT 6 in page 22 Figure 5.? 3. Why do arcs from Networks to Routers have cost 0? VM> The cost between of a network is to be accounted for only once. So from going from a router to a router the cost is accounted when going from router to network and the network to router cost is set to 0. If there are other RFCs that i need to go thru before referring to the OSPF RFC, which may answer these basic questions please mention them. VM> You can look at the archives at http://discuss.microsoft.com/archives/ospf.html a lot of topics have been discussed before and that will help you. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Jul 18 19:35: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 TAA15554 for ; Thu, 18 Jul 2002 19:35:23 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0069A080@cherry.ease.lsoft.com>; Thu, 18 Jul 2002 19:36:18 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 111335 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 18 Jul 2002 19:36:18 -0400 Received: from 64.246.203.216 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 18 Jul 2002 19:36:18 -0400 Received: from [192.168.254.10] by mainserver (ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.1.1)); Thu, 18 Jul 2002 19:32:26 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C22E92.442C92F0" 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: Thu, 18 Jul 2002 19:35:26 -0400 Reply-To: Mailing List Sender: Mailing List From: Tom Thomas Subject: Re: OSPF Test Tool ? To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20020717215925.3232.qmail@web12905.mail.yahoo.com> Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C22E92.442C92F0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Vinay, if you want to test your implementation you are going to have to be flexible in tools out there, one possible solution I would recommend is: http://advanced.comms.agilent.com/RouterTester/ -----Original Message----- From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Vinay Ravuri Sent: Wednesday, July 17, 2002 5:59 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: OSPF Test Tool ? I am looking to do conformance and stress test against a OSPFv2 stack/router. I was wondering if anyone is aware of a free ospf tool (preferably with source code) that can do this? Any help is grealy appreciated. Cheers, Vinay vinay_usenet@yahoo.com ---------------------------------------------------------------------------- -- Do You Yahoo!? Yahoo! Autos - Get free new car price quotes ------=_NextPart_000_0002_01C22E92.442C92F0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Vinay,=20 if you want to test your implementation you are going to have to be = flexible in=20 tools out there, one possible solution I would recommend = is:
 
http://advanced.= comms.agilent.com/RouterTester/
-----Original Message-----
From: Mailing List=20 [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of Vinay=20 Ravuri
Sent: Wednesday, July 17, 2002 5:59 PM
To:=20 OSPF@DISCUSS.MICROSOFT.COM
Subject: OSPF Test Tool=20 ?

I am looking to do conformance and stress test = against=20 a
OSPFv2 stack/router.  I was wondering if anyone
is = aware of=20 a free ospf tool (preferably with source
code) that can do = this?

Any=20 help is grealy appreciated.

Cheers,
Vinay
vinay_usenet@yahoo.com


Do You Yahoo!?
Yahoo! = Autos -=20 Get free new car price quotes
------=_NextPart_000_0002_01C22E92.442C92F0-- From owner-ospf@DISCUSS.MICROSOFT.COM Thu Jul 18 19:47: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 TAA15894 for ; Thu, 18 Jul 2002 19:47:03 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0069A05A@cherry.ease.lsoft.com>; Thu, 18 Jul 2002 19:47:59 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 111372 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 18 Jul 2002 19:47:59 -0400 Received: from 63.236.75.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 18 Jul 2002 19:47:59 -0400 Received: by xmxpita.excite.com (Postfix, from userid 110) id A27A03DE6; Thu, 18 Jul 2002 19:47:55 -0400 (EDT) Received: from [66.245.52.179] by xprdmailfe9.nwk.excite.com via HTTP; Thu, 18 Jul 2002 19:47:55 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = ec82b6fdd46be93d41f8984a0e3ae1f8 MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20020718234755.A27A03DE6@xmxpita.excite.com> Date: Thu, 18 Jul 2002 19:47:55 -0400 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: OSPF Test Tool ? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Vinay, GKS is right. There are no free tools available (and I've been testing OSPF for almost 10 years). ANVL was the first commericial tool available. Others have tried and mostly failed, although Spirent (Netcom/Adtech) and Ixia have added OSPF conformance tests recently. In fact, just a few months ago, Ixia bought the ANVL software. -don --- On Wed 07/17, kamatchi soundaram wrote: From: kamatchi soundaram [mailto: kamatchi@TDD.SJ.NEC.COM] To: OSPF@DISCUSS.MICROSOFT.COM Date: Wed, 17 Jul 2002 16:35:26 -0700 Subject: Re: OSPF Test Tool ? > > > > > > > > Hi, > > I don't think any free tool is > available for > OSPF conformance testing as u r expecting to simulate a large network and > > test. > > But if u really looking for a good > tool, and > doesn't bother about the cost, then there is a tool u can go for > it.. > > It's "ANVL" OSPF conformance > tool. I > think it's a product of Midnight networks. > > regards, > GKS. > > > ----- Original Message ----- > From: > Vinay > Ravuri > To: OSPF@discuss.microsoft.com > > Sent: Wednesday, July 17, 2002 2:59 > > PM > Subject: OSPF Test Tool ? > I am looking to do conformance and stress test against > aOSPFv2 stack/router. I was wondering if anyoneis > aware of > a free ospf tool (preferably with sourcecode) that can do > this?Any > help is grealy appreciated.Cheers,Vinayvinay_usenet@yahoo.com > > > Do You Yahoo!?Yahoo! > Autos - > Get free new car price quotes > ------------------------------------------------ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ospf@DISCUSS.MICROSOFT.COM Fri Jul 19 14:17: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 OAA15155 for ; Fri, 19 Jul 2002 14:17:45 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.0069BDDB@cherry.ease.lsoft.com>; Fri, 19 Jul 2002 14:18:35 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 114724 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 19 Jul 2002 14:18:35 -0400 Received: from 216.136.173.239 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 19 Jul 2002 14:18:34 -0400 Received: from [192.25.240.26] by web12702.mail.yahoo.com via HTTP; Fri, 19 Jul 2002 11:18:34 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20020719181834.42442.qmail@web12702.mail.yahoo.com> Date: Fri, 19 Jul 2002 11:18:34 -0700 Reply-To: Mailing List Sender: Mailing List From: Suvani Kaura Subject: RFCs 2328, 2740 & SeqNumber Mismatch Error To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Hi All, I have a question pertaining to section 10.6 of RFC 2328, with regards to generating SequenceNumberMismatch error, specifically the following portion: When the router accepts a received Database Description Packet as the next in sequence the packet contents are processed as follows. For each LSA listed, the LSA's LS type is checked for validity. If the LS type is unknown (e.g., not one of the LS types 1-5 defined by this specification), or if this is an AS- external-LSA (LS type = 5) and the neighbor is associated with a stub area, generate the neighbor event SeqNumberMismatch and stop processing the packet. At other places in the document, it is also stated that type-5 LSAs should not be flooded (or summarized in DD packets) over virtual links. Shouldn't reception of a type-5 LSA header over a virtual link during DD exchange also cause the generation of SeqNumberMismatch event? Additionally, am I correct in interpreting the above taken along with RFC2740, to mean that for OPSFv3 unknown LSAs are permitted for non-stub areas (irrespective of U-bit)? Only for Stub areas unknown LSAs with U-bit == 1 should not be advertised in Updates & DDs, and seq. num mismatch event be generated upon their receipt in DDs. The rule about AS-wide LSAs still applies to both stub areas & virtual links. Right? Thanks for your input, Suvani __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Fri Jul 19 15:42: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 PAA16474 for ; Fri, 19 Jul 2002 15:42:11 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.0069BFBD@cherry.ease.lsoft.com>; Fri, 19 Jul 2002 15:43:09 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 114893 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 19 Jul 2002 15:43:09 -0400 Received: from 131.241.15.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 19 Jul 2002 15:43:06 -0400 Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com [131.241.31.2]) by mail4.nec.com (/) with ESMTP id g6JJfGe13171 for ; Fri, 19 Jul 2002 12:41:16 -0700 (PDT) Received: from necsun.tdd.sj.nec.com (localhost [127.0.0.1]) by netkeeper.sj.nec.com (8.9.1a/8.9.1) with ESMTP id MAA28873 for ; Fri, 19 Jul 2002 12:41:11 -0700 (PDT) Received: from bunny.tdd.sj.nec.com by necsun.tdd.sj.nec.com with ESMTP id g6JJYY94017657 for ; Fri, 19 Jul 2002 12:34:34 -0700 (PDT) Received: from ems12 (ems12 [131.241.5.17]) by bunny.tdd.sj.nec.com with SMTP id g6JJYWZ0002924 for ; Fri, 19 Jul 2002 12:34:33 -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: <006901c22f5c$81a5f930$1105f183@b90.tdd.sj.nec.com> Date: Fri, 19 Jul 2002 12:43:07 -0700 Reply-To: Mailing List Sender: Mailing List From: kamatchi soundaram Subject: Any standard for MAC address for OSPF mutilcast address . To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi, I need the following two clarifications. It would be highly appreciable, if i get some input. 1) Whenever OSPF comes up, i will register for IP multicast address. Similarly, do i need to register with the Mac (ethernet device) with any? MAC multicast address. 2) If so, what is the standard Multicast MAC address for OSPF? thanks, GKS. From owner-ospf@DISCUSS.MICROSOFT.COM Fri Jul 19 16:01: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 QAA16668 for ; Fri, 19 Jul 2002 16:01:27 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.0069C101@cherry.ease.lsoft.com>; Fri, 19 Jul 2002 16:02:24 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 114947 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 19 Jul 2002 16:02:24 -0400 Received: from 63.113.114.132 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 19 Jul 2002 15:52:23 -0400 Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Jul 2002 15:46:52 -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, 19 Jul 2002 15:46:51 -0400 Reply-To: Mailing List Sender: Mailing List From: Eldose Paul Subject: Re: Any standard for MAC address for OSPF mutilcast address . To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list The Multicast MAC address is derived from the IP address itself. Refer to the TCP/IP Book by Stevens Vol 2 Page 341, it explains how the MAC address is derived from the IP address. Eldose -----Original Message----- From: kamatchi soundaram [mailto:kamatchi@TDD.SJ.NEC.COM] Sent: Friday, July 19, 2002 3:43 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Any standard for MAC address for OSPF mutilcast address . Hi, I need the following two clarifications. It would be highly appreciable, if i get some input. 1) Whenever OSPF comes up, i will register for IP multicast address. Similarly, do i need to register with the Mac (ethernet device) with any? MAC multicast address. 2) If so, what is the standard Multicast MAC address for OSPF? thanks, GKS. From owner-ospf@DISCUSS.MICROSOFT.COM Fri Jul 19 18:19: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 SAA18273 for ; Fri, 19 Jul 2002 18:19: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.0069C458@cherry.ease.lsoft.com>; Fri, 19 Jul 2002 18:20:53 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 115342 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 19 Jul 2002 18:20:53 -0400 Received: from 131.241.15.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 19 Jul 2002 18:20:53 -0400 Received: from netkeeper.sj.nec.com (netkeeper.sj.nec.com [131.241.31.2]) by mail4.nec.com (/) with ESMTP id g6JMJVe22859 for ; Fri, 19 Jul 2002 15:19:31 -0700 (PDT) Received: from necsun.tdd.sj.nec.com (localhost [127.0.0.1]) by netkeeper.sj.nec.com (8.9.1a/8.9.1) with ESMTP id PAA02499 for ; Fri, 19 Jul 2002 15:19:25 -0700 (PDT) Received: from bunny.tdd.sj.nec.com by necsun.tdd.sj.nec.com with ESMTP id g6JMCl94018733 for ; Fri, 19 Jul 2002 15:12:48 -0700 (PDT) Received: from ems12 (ems12 [131.241.5.17]) by bunny.tdd.sj.nec.com with SMTP id g6JMCkZ0027129 for ; Fri, 19 Jul 2002 15:12:46 -0700 (PDT) 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 Content-Transfer-Encoding: 7bit Message-ID: <000c01c22f72$9c4fd510$1105f183@b90.tdd.sj.nec.com> Date: Fri, 19 Jul 2002 15:21:21 -0700 Reply-To: Mailing List Sender: Mailing List From: kamatchi soundaram Subject: Re: Any standard for MAC address for OSPF mutilcast address . To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Thank u very much. GKS. ----- Original Message ----- From: "Eldose Paul" To: Sent: Friday, July 19, 2002 12:46 PM Subject: Re: Any standard for MAC address for OSPF mutilcast address . > The Multicast MAC address is derived from the IP address itself. Refer to > the TCP/IP Book by Stevens Vol 2 Page 341, it explains how the MAC address > is derived from the IP address. > > Eldose > > -----Original Message----- > From: kamatchi soundaram [mailto:kamatchi@TDD.SJ.NEC.COM] > Sent: Friday, July 19, 2002 3:43 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Any standard for MAC address for OSPF mutilcast address . > > > Hi, > > I need the following two clarifications. It would be highly appreciable, > if i get some input. > > 1) Whenever OSPF comes up, i will register for IP multicast address. > Similarly, do i need to register with the Mac (ethernet device) with any? > MAC multicast address. > > 2) If so, what is the standard Multicast MAC address for OSPF? > > thanks, > GKS. > From owner-ospf@DISCUSS.MICROSOFT.COM Mon Jul 22 03:30: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 DAA27597 for ; Mon, 22 Jul 2002 03:30:24 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.0069FDA4@cherry.ease.lsoft.com>; Mon, 22 Jul 2002 3:31:16 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 120726 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 22 Jul 2002 03:31:16 -0400 Received: from 131.228.20.21 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 22 Jul 2002 03:31:16 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g6M7TYd24937 for ; Mon, 22 Jul 2002 10:29:34 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 22 Jul 2002 10:31:11 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 22 Jul 2002 10:31:11 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Topic: Link Flap Damping Thread-Index: AcIiZFJ0ZHttdoMWQNGQBIPkLsEtqgAEa1NgA7bvmEA= X-OriginalArrivalTime: 22 Jul 2002 07:31:11.0267 (UTC) FILETIME=[C0918730:01C23151] Message-ID: Date: Mon, 22 Jul 2002 10:31:10 +0300 Reply-To: Mailing List Sender: Mailing List From: Andreas Heiner Subject: Re: Link Flap Damping To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA27597 > -----Original Message----- > From: ext Andreas Heiner [mailto:andreas.heiner@NOKIA.COM] > Sent: 03 July, 2002 13:31 > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: Link Flap Damping > > > Hi > > comments in-line > > > Subject: Re: Link Flap Damping > > > > > > swatirstogi> You are reducing LSA changes at the cost of providing > > swatirstogi> sub-optimal (and in the worst case incorrect and > > swatirstogi> false) routing. You still claim reachability to a > > swatirstogi> router which you are no longer are connected to > > swatirstogi> (during the period when the link is down) > > > [ side issue > I'm not quite sure what you mean with "optimal routing". > Intuitively optimality in this context is "getting as much > traffic through as fast as possible", but with dynamic > traffic demands optimality is not well defined. Moreover, the > cost assignment is relatively arbitrary (one administrator > may say hops, others reliability etc.), so in my opinion > "optimal routing" is rather arbitrary. I prefer to use "as > good as possible", or even better, "good enough" routing. > Gives you way more flexibility. In the end, the only thing > users are interested in is good (enough) service, not optimal service > (the STAR protocol by Garcia-Luna-Aceves > (http://www.soe.ucsc.edu/people/faculty/jj.html) also uses > this principle) > ] > > > swatirstogi> > > swatirstogi> The downstream peers will falsely assume that u still > > swatirstogi> have reachability to some networks and they will in > > swatirstogi> turn advertise this to their peers. This will create > > swatirstogi> havoc if one of the OSPF routers is redistributing > > swatirstogi> routes into BGP > > swatirstogi> > > swatirstogi> One of the most fundamental rules of routing which i > > swatirstogi> learnt long back was that we must advertise the bad > > swatirstogi> news at the earliest. The same happens in BGP. Certain > > swatirstogi> implementations maintain a MinAdvertismentInterval > > swatirstogi> timer which when triggers causes a BGP speaker to > > swatirstogi> advertise all its UPDATE messages to its peers. This > > swatirstogi> timer is not honoured in case of sending UPDATE > > swatirstogi> messages containing withdrawn/non feasible routes. > > swatirstogi> > > swatirstogi> The same should hold true for OSPF. Why should one > > swatirstogi> router keep the link description up when it knows that > > swatirstogi> it is down? > > swatirstogi> > > swatirstogi> Your comments please. > > > > I believe IGP has different logic from EGP's. > > > > - about "providing sub-optimal" and "why link description up": > > > > I'm thinking about link flapping caused by congestion. > > If a link flaps, your feature will not allow OSPF to route any > > traffics to the link entirely. We still have a lot of > links which > > do not have alternatives. In case no alternatives, I think that > > we prefer to deactivate the feature and let the traffic thru the > > link by "best effort" until we upgrade the link or prepare > > alternatives. > > > > [a little bit off topic: > > I once thought that "we should not worry about congestions, > > because we have Diffserv technology and link monitor > packet (such > > as Hello in OSPF) should go beyond the others priority". > > But now I wonder if this is true: in Diffserv world, > some class's > > packet go through normally and the other class's packet may not. > > What is that the hello monitors ? Do we really want to keep the > > reachability in that case ? Hello should monitor each > class's link > > path separately ... > > ] > > > ...deleted... > In my opinion the only service OSPF (or any other IGP) > provides/should provide is connectivity, i.e. it tells you if > a link exists and if it can carry traffic, not how much > traffic there is. Route recalculation based on traffic > information (congestion gives new cost values) should not be > done as it will introduce route flaps. > This also holds for a DiffServ world. In a DiffServ world > packets are preferentially forwarded, but always such that no > single class is starved. Even if some class gets so little BW > that de-facto the link is down for that class, one should not > declare the link down for that class, as it is equivalent > with assigning a high cost for that link. Hence link monitor > packets per class make no sense. (Besides, in long > simulations with strict priority queueing we never had class > starvation) > As for Hello in the highest DiffServ class: we tested this > idea in simulations for all OSPF packets, and results were > excellent, i.e. route table convergence in the order of the > half the minimum round trip time (excl. route table > recalculations). This idea was also proposed in > 'draft-ietf-ospf-scalability-01.txt'. > > regards, > > Andrepeter > > > regards. > > yasu > > > From owner-ospf@DISCUSS.MICROSOFT.COM Mon Jul 22 23:12: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 XAA10436 for ; Mon, 22 Jul 2002 23:12: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.006A1D03@cherry.ease.lsoft.com>; Mon, 22 Jul 2002 23:13:46 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 124353 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 22 Jul 2002 23:13:46 -0400 Received: from 203.254.224.24 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 22 Jul 2002 23:13:45 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) id <0GZO00601MEJUY@mailout1.samsung.com> for ospf@diSCUSS.MICROSOFT.COM; Tue, 23 Jul 2002 12:15:55 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GZO0061HMEIS7@mailout1.samsung.com> for ospf@diSCUSS.MICROSOFT.COM; Tue, 23 Jul 2002 12:15:55 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0GZO0003TMEPCF@mmp2.samsung.com> for ospf@diSCUSS.MICROSOFT.COM; Tue, 23 Jul 2002 12:16:02 +0900 (KST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Message-ID: <009701c231f6$5b8d54e0$b4036c6b@sisodomain.com> Date: Tue, 23 Jul 2002 08:39:27 +0530 Reply-To: Mailing List Sender: Mailing List From: Manav Bhatia Subject: 54 IETF minutes To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7BIT Hi, Can somebody please post the minutes of the OSPF WG for the 54th IETF meeting on the list? Regards, Manav ---- "When you are courting a nice girl an hour seems like a second. When you sit on a red-hot cinder a second seems like an hour. That's relativity." -Albert Einstein, on relativity From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jul 23 00:41: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 AAA17425 for ; Tue, 23 Jul 2002 00:41:31 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.006A1F75@cherry.ease.lsoft.com>; Tue, 23 Jul 2002 0:42:30 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 124666 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 23 Jul 2002 00:42:30 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 23 Jul 2002 00:42:30 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Jul 2002 00:42:22 -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, 23 Jul 2002 00:44:45 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Link Flap Damping To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Andrepeter, I haven't really been following the thread but now that you mentioned the draft http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-01.txt I would like to add that there are some things that we have mentioned in section 4 of the draft that could help in case of "link flaps". The main point being to give more priority to "link down" than to "link up". This could mean that in case of flaps we could signal "link down" immediately however damp the "link up" event. Cengiz and Steve Casner reached a similar conclusion with respect to ISIS protocol, they even presented something related at NANOG. Thanks, Vishwas > ...deleted... > In my opinion the only service OSPF (or any other IGP) > provides/should provide is connectivity, i.e. it tells you if > a link exists and if it can carry traffic, not how much > traffic there is. Route recalculation based on traffic > information (congestion gives new cost values) should not be > done as it will introduce route flaps. > This also holds for a DiffServ world. In a DiffServ world > packets are preferentially forwarded, but always such that no > single class is starved. Even if some class gets so little BW > that de-facto the link is down for that class, one should not > declare the link down for that class, as it is equivalent > with assigning a high cost for that link. Hence link monitor > packets per class make no sense. (Besides, in long > simulations with strict priority queueing we never had class > starvation) > As for Hello in the highest DiffServ class: we tested this > idea in simulations for all OSPF packets, and results were > excellent, i.e. route table convergence in the order of the > half the minimum round trip time (excl. route table > recalculations). This idea was also proposed in > 'draft-ietf-ospf-scalability-01.txt'. > > regards, > > Andrepeter From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jul 23 04:00: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 EAA02851 for ; Tue, 23 Jul 2002 04:00:50 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.006A2232@cherry.ease.lsoft.com>; Tue, 23 Jul 2002 4:01:48 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 125248 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 23 Jul 2002 04:01:48 -0400 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 23 Jul 2002 04:01:48 -0400 Received: from localhost ([127.0.0.1] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17Wuc4-000LTl-00; Tue, 23 Jul 2002 01:01:44 -0700 X-Mailer: The Bat! (v1.51) Personal X-Priority: 3 (Normal) References: <009701c231f6$5b8d54e0$b4036c6b@sisodomain.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <1548775445.20020723010024@psg.com> Date: Tue, 23 Jul 2002 01:00:24 -0700 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: Re: 54 IETF minutes Comments: To: Manav Bhatia To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <009701c231f6$5b8d54e0$b4036c6b@sisodomain.com> Precedence: list Content-Transfer-Encoding: 7bit Manav, I was the minute taker for this meeting. I'll be sending them to the list for a review within a couple of days. Thanks. -- Alex Monday, July 22, 2002, 8:09:27 PM, Manav Bhatia wrote: > Hi, > Can somebody please post the minutes of the OSPF WG for the 54th IETF > meeting on the list? > Regards, > Manav > ---- > "When you are courting a nice girl an hour seems like a second. When you > sit on a red-hot cinder a second seems like an hour. That's relativity." > -Albert Einstein, on relativity From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jul 23 10:14: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 KAA13007 for ; Tue, 23 Jul 2002 10:14:48 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.006A2CE5@cherry.ease.lsoft.com>; Tue, 23 Jul 2002 10:15:47 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 126534 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 23 Jul 2002 10:15:47 -0400 Received: from 205.158.62.80 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 23 Jul 2002 10:15:46 -0400 Received: (qmail 97558 invoked by uid 1001); 23 Jul 2002 14:14:41 -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.254.12] by ws1-11.us4.outblaze.com with http for beatriz_hargrave@mail.com; Tue, 23 Jul 2002 09:14:41 -0500 X-Originating-Ip: 129.187.254.12 X-Originating-Server: ws1-11.us4.outblaze.com Message-ID: <20020723141441.97557.qmail@mail.com> Date: Tue, 23 Jul 2002 09:14:41 -0500 Reply-To: Mailing List Sender: Mailing List From: Beatriz Silva Subject: what cause the generation of LSAs, and which LSAs To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hello everybody, Does anybody know (or know where I could find something about it) which kind of changes in the topology lead to generation of which kind of LSAs and by whom (router or network LSAs, or both together - I am talking about one area only)? 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 Tue Jul 23 12:11: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 MAA20792 for ; Tue, 23 Jul 2002 12:11:11 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.006A31A2@cherry.ease.lsoft.com>; Tue, 23 Jul 2002 12:12:11 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 127081 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 23 Jul 2002 12:12:11 -0400 Received: from 207.217.120.120 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 23 Jul 2002 12:12:11 -0400 Received: from user-2ivfjgf.dialup.mindspring.com ([165.247.206.15] helo=earthlink.net) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 17X2Gf-0004ud-00 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 23 Jul 2002 09:12:09 -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: <3D3D82F0.5DE5166@earthlink.net> Date: Tue, 23 Jul 2002 09:23:12 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Link Flap Damping To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, I totally agree with Vishwas. However, I think if you keep knowledge of objects beyond the "link down" event instead of just deleting them. This knowledge would allow you to properly characterize the "link up" as being a NEW event and the amount of damping. Thus in my opinion a first "link up" event or a "link up" after a configurable considerable amount of time, needs minimal or no damping. Mitchell Erblich ====================== "Manral, Vishwas" wrote: > > Hi Andrepeter, > > I haven't really been following the thread but now that you mentioned the > draft > http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-01.txt > > I would like to add that there are some things that we have mentioned in > section 4 of the draft that could help in case of "link flaps". > > The main point being to give more priority to "link down" than to "link up". > This could mean that in case of flaps we could signal "link down" > immediately however damp the "link up" event. Cengiz and Steve Casner > reached a similar conclusion with respect to ISIS protocol, they even > presented something related at NANOG. > > Thanks, > Vishwas > > > ...deleted... > > In my opinion the only service OSPF (or any other IGP) > > provides/should provide is connectivity, i.e. it tells you if > > a link exists and if it can carry traffic, not how much > > traffic there is. Route recalculation based on traffic > > information (congestion gives new cost values) should not be > > done as it will introduce route flaps. > > This also holds for a DiffServ world. In a DiffServ world > > packets are preferentially forwarded, but always such that no > > single class is starved. Even if some class gets so little BW > > that de-facto the link is down for that class, one should not > > declare the link down for that class, as it is equivalent > > with assigning a high cost for that link. Hence link monitor > > packets per class make no sense. (Besides, in long > > simulations with strict priority queueing we never had class > > starvation) > > As for Hello in the highest DiffServ class: we tested this > > idea in simulations for all OSPF packets, and results were > > excellent, i.e. route table convergence in the order of the > > half the minimum round trip time (excl. route table > > recalculations). This idea was also proposed in > > 'draft-ietf-ospf-scalability-01.txt'. > > > > regards, > > > > Andrepeter From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jul 23 13:04: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 NAA23863 for ; Tue, 23 Jul 2002 13:04:31 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.006A32F9@cherry.ease.lsoft.com>; Tue, 23 Jul 2002 13:05:32 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 127225 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 23 Jul 2002 13:05:32 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 23 Jul 2002 13:05:32 -0400 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id 26AD94483FA for ; Tue, 23 Jul 2002 10:05:30 -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: <20020723141441.97557.qmail@mail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D3D8CE5.3000308@redback.com> Date: Tue, 23 Jul 2002 13:05:41 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: what cause the generation of LSAs, and which LSAs To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Beatriz Silva wrote: > Hello everybody, > > Does anybody know (or know where I could find something about it) which kind of changes in the topology lead to generation of which kind of LSAs and by whom (router or network LSAs, or both together - I am talking about one area only)? > Take a look at section 12.4 in RFC 2328. > 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 > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jul 23 22:45: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 WAA12109 for ; Tue, 23 Jul 2002 22:45:43 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.006A3EE3@cherry.ease.lsoft.com>; Tue, 23 Jul 2002 22:46:43 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 128461 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 23 Jul 2002 22:46:42 -0400 Received: from 147.28.0.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 23 Jul 2002 22:46:42 -0400 Received: from localhost ([127.0.0.1] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17XCAi-000OEA-00 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 23 Jul 2002 19:46:41 -0700 X-Mailer: The Bat! (v1.51) Personal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <60116269626.20020723194518@psg.com> Date: Tue, 23 Jul 2002 19:45:18 -0700 Reply-To: Mailing List Sender: Mailing List From: Alex Zinin Subject: IETF-54/OSPF WG minutes To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Folks, Below is what I took at the meeting. Thanks to Eric Gray for his help and sorry if I missed anything. Those who were there, pls review and provide corrections if you find a mistake. -- Alex Bill Fenner chaired the meeting, since John was on vacation. 1. Administrivia from Bill The ADs are looking for a co-chair. If you would like to be considered or suggest someone, please talk to Bill and Alex. Agenda bashing Status update: MIBs: MIB doctor review Pending for new version after AD comments: alt-abr padma's flooding reduction katz-yeung NSSA: almost out Active WG documents: Multi-area links HItless restart Hello priority 5-to-7 trans Bunch of ospf ids not mapping to the charter (Bill showed the list of all drafts with ospf in them) Goals & Milestones: Bill: The dc-neighbor: status? Alex: expired, but should be ready for the LC Bill: should probably do the LC then Bill: refresh guidelines? Alex: need to solve the problem with publishing the model and increase the refresh jitter per comments from the WG, should be ready for the LC then. MOSPF update? no work MOSPF prunning? no work Flooding reduction item? maps to padma's doc Bill: what do people think about the goals and milestones? Dimitry: LLS in charter? Bill: no Dimitry: any interest in the WG? Bill: need interest and the IESG approval of the milestone Dimitry: isn't it a WG item as I see in the list? Bill: the chairs allowed the documents to be WG docs without the charter update. We're trying to make sure all work items are in the charter. Rahul: GMPLS ext: part of the CCAMP WG, should we revisit this issue and bring them here? Kireeti: I had a discussion with John, he was happy to put it in CCAMP. Bill: does CCAMP want to do it? K: it is probably easier, it's GMPLS details, an opaque LSA. ISIS took a different approach: it's an extension to the base proto, so we don't want to be out of the WG Need to rediscuss with Tonys. B: CCAMP could create a document for the pieces of info and have a protocol-specific details in protocol WGs K: we have it. the ownership of ISIS is in ISIS WG. In isis we have to be careful too. There are reasons. We need to revisit with the ISIS chairs. Maybe also OSPF Dave Ward: On behalf on the Tonys, they want to control the changes to the protocol, but are happy with GMPLS going back to CCAMP K: As virtual John: do you have a preference? :) B: makes sense for the protocol pieces to be in the protocol-specific WG to make sure proto-specific issues are dealt with. A: this is the default K: ccamp does work on the protocols A: I meant to say if we're using an existing protoc K: not necessarily the case, examples: CR-LDP, RSVP-TE. A: should probably discuss this more Mina: we should look where the expertise is and the workload of the WG is 2. Rahul presented ospf optional router capabilities. current use is for troubleshooting and management, maybe used for protocol extension in future: [draft-raggarwa-igp-cap-00.txt] Abhay: have you looked at the LLS? R: no A: it solves most of what you're talking about R: haven't looked at the draft, but the intention is to provide a mechanism for ann. of capabilities. we're trying to consolidate capabilities announcement for IGPs, A: LLS will allow you to have options in Hello packets, useful if you want to do negotiation before the adj comes up while the opaque lsa maybe too late: R: will look A: why do you need bits for restart? R: for management. one of the operators said there's a way in other protocols (bgp) to announce capability... right now, no help for the protocol, info, Naming: coming from the anchor of the hitless restart, some vendors support either one of them or both of them Amir: not to comment on any related necessity, specific: it might be better to exclude the actual bit listing from the specified draft, so you don't have to update the doc everytime a new capability is introduced. you mention it is optional, you should take in account that if this goes through, it will have to be implemented, people will use it. R: 1st point those are existing capabilities, let's identify them 2nd: optional mechanism, TE is optional, implement or not--different issue. A: we either don't need it or the graceful restart will use it N: 1st point: took the approach from ISIS, list the current standard drafts published that so far have been using the code point, it does not prevent.... if in future any draft wants to announce a capability, we'll have another draft 2. ?????? K: you should have a bit that says: I'm capable of doing capabilities :) K: does this belong here or in MIB? R: MIB does not solve what we're trying to solve K: why not use the MIB, since it is informational Bill: I had the same concern, so why do we need it in the IGP R: some operators asked us to introduce this info, but point is well-taken. Alex: Sounds like we should either have a useful application for this mechanism or have the operators speak up on the list explaining why this is a do-or-die for them. Otherwise, we're just increasing the entropy. R: yep, makes sense. Jeff: easy to foresee events under which some peer would take action, if you do envision that, you need to specify those actions also, how many bits you have: R: extensible J: good, bgp takes approach of list of values Andrew L: peer? J: adjacencies, the neighbor could use it to take different actions Andrew: you could manually configure Naming: on Kireeti's: MIB is for the NMS, needs explicit request. if you're troubleshooting the hitless restart, ours helps to see who supports hitless restart. SNMP support is behind feature-wise if the protocol wants to use for internal use, it's not the MIB issue Kireeti: if purely informational: MIB, no protocol Dimitry: do you debug the capability or the fact that it is announced? R: didn't understand K: you have to bits support restart and restart enabled R: the draft does not specify... if you haven't received any LSA identifying a capability you don't know what happens, if you HAVE but the bit is off, it gives the clue that it doesn't support Bill: we need more discussion on the list R: we'll take it to the list, will ask the SPs to speak up 3. Mukesh presented his draft on ospfv3 and ipsec, discussing how ipsec should be used to secure ospv3 communication. [draft-gupta-ospf-ospfv3-auth-00.txt] Bill: the document says AH or ESP, we get inconsistent advise, just use one--AH/ESP. I'm told that there are existing implementations with AH only, switching to ESP only would mean interoperability problems. M: I have options AH or ESP B: if we implement different, we won't interoperate there are places: getting interoperability: what algos are necessary: hash, cyphers, the doc doesn't pick a cipher, we could have interop problems M: should I add algos? B: yeah, if you implement one and I implement another, we wont work together M: I implemented, have options for both B: say i have a router that has no ipsec implement, i want to implemenyt ipsec sec, what the min to implement to be compat with others. have to have common min M: ok Alex: to give a bit of perspective--I encouraged Mukesh to look at the problem after the discussion on the list went in a wrong direction, this is the first shot, expecting constructive comments from the WG. Yasu: did you look at both unicast & multicast packets? M: covered both unicast and multiast Y: another question: do you think OSPF can prevent the reply attacks? if there's a replay packet, it will break the adjacencies Alex: We use ipsec for ospfv3. ike is p2p only, hence we need to use static shared keys, which means no sequence number, and effectively no replay protection. ospfv2 solves this by using its own crypto sequence numbers, but not completely, isis went a different direction--no sequence numbers there. M: we also have a problem with maintaining the seq nums in SAs when operating in a multicast group. ????: could we use sequence numbers in ospf packets? Alex: we don't really have them in packets. LSAs do have seq nums, but the problem is when an LSA is gone, the seq num is gone and you can replay. No seq num in ospf packets, ospfv2 has its own crypto ones, the problem with them is when a nbr is gone, its seq num is gone and you can replay again. Bill: there's some work on mcast key exchange protocol, when they mature, it might be useful for it. M: it is all happening at the IPSec, if IPsec has a problem, we have it in OSPF B: got some comment from Ran Atkinson, will work with you. 4. JP presented the draft on PCSD-discovery draft [draft-vasseur-mpls-ospf-pcsd-discovery-00.txt] Bill: needs reviews like other uses of OSPF opaque LSAs. Kireeti: issues need to be broken down into what they affect. One consideration in deciding where to do the work is how many times are you going to have to see the draft presented. Kireeti also talked about breaking the task into functional and protocol specifications. This makes it easier to decide where to do the work. Francois: talked about precedents that had followed a similar model. Bill: the idea is that the WG needs to review the work at some point. Alex: please provide comments on the OSPFv3 FA issue, getting feedback that the discussion was not sufficient to resolve it. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jul 24 01:00: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 BAA15182 for ; Wed, 24 Jul 2002 01:00:57 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.006A4662@cherry.ease.lsoft.com>; Wed, 24 Jul 2002 1:01:57 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 128910 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 24 Jul 2002 01:01:57 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 24 Jul 2002 01:01:57 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Jul 2002 01:01:49 -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, 24 Jul 2002 01:04:25 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: what cause the generation of LSAs, and which LSAs To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Beatriz, Though Acee has pointed you to the section where you can get related information, a simple rule you can apply is, whenever you feel that the information carried by a previous version of the LSA has changed, (for whatever reason e.g a new neighbor to full state), you need to originate an LSA. Besides that a new instance of the same LSA are sent out on refresh, however these are periodic and not caused by any change in topology. Thanks, Vishwas -----Original Message----- From: Beatriz Silva [mailto:beatriz_hargrave@MAIL.COM] Sent: Tuesday, July 23, 2002 7:45 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: what cause the generation of LSAs, and which LSAs Hello everybody, Does anybody know (or know where I could find something about it) which kind of changes in the topology lead to generation of which kind of LSAs and by whom (router or network LSAs, or both together - I am talking about one area only)? Thanks, Beatriz. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jul 24 01:18: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 BAA15544 for ; Wed, 24 Jul 2002 01:18:23 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.006A4620@cherry.ease.lsoft.com>; Wed, 24 Jul 2002 1:19:24 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 128947 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 24 Jul 2002 01:19:24 -0400 Received: from 64.4.15.133 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 24 Jul 2002 01:09:23 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 23 Jul 2002 22:09:23 -0700 Received: from 203.196.146.243 by lw10fd.law10.hotmail.msn.com with HTTP; Wed, 24 Jul 2002 05:09:22 GMT X-Originating-IP: [203.196.146.243] Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 24 Jul 2002 05:09:23.0257 (UTC) FILETIME=[4639BA90:01C232D0] Message-ID: Date: Wed, 24 Jul 2002 05:09:22 +0000 Reply-To: Mailing List Sender: Mailing List From: praveendas e Subject: Link state data base example To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hai all i am new to this group ,hope somebody will clear my doubt My question is In RFC 2328 ,section 2.1.2 An Example link-state database ,figure 2 The router R6 had an interface to Ia ,it is a stub network, when the router RT6 calculate the routing table it is used RT10 as the next hope to the stub network Ia having a cost of 12( i.e in section 2.2 The shortest -path tree) eventhough the router RT6 is directly connected to Ia with cost 7 ... 1.why it is using RT10 as next hope to Ia (the stub network)? 2.Why RT6 is adverising its direct interface,with other router as next hop? Thanks in Advance Regards Praveendas _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jul 24 10:13: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 KAA18168 for ; Wed, 24 Jul 2002 10:13:20 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.006A50F8@cherry.ease.lsoft.com>; Wed, 24 Jul 2002 10:14:22 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 130518 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 24 Jul 2002 10:14:22 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 24 Jul 2002 10:14:22 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 6E8B9262813 for ; Wed, 24 Jul 2002 07:14:20 -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: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D3EB63C.4060905@redback.com> Date: Wed, 24 Jul 2002 10:14:20 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Link state data base example To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Praveendas, This is in fact the route table that will result using Option 1 for describing point-to-point numbered interfaces (section 12.4.1.1). This is because RT10 is the only router advertising a /32 prefix to Ia (RT6's local address). If Option 2 is used, the OSPF computed route will be the same as the direct (i.e., connected) route. Good Luck, Acee praveendas e wrote: > Hai all > i am new to this group ,hope somebody will clear my doubt > > My question is > In RFC 2328 ,section 2.1.2 An Example link-state database ,figure 2 > The router R6 had an interface to Ia ,it is a stub network, > when the router RT6 calculate the routing table it is used RT10 as the > next hope to the stub network Ia having a cost of 12( i.e in section 2.2 > The > shortest -path tree) > eventhough the router RT6 is directly connected to Ia with cost 7 ... > > 1.why it is using RT10 as next hope to Ia (the stub network)? > 2.Why RT6 is adverising its direct interface,with other router as next hop? > > Thanks in Advance > Regards > Praveendas > > > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jul 24 10:36: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 KAA19361 for ; Wed, 24 Jul 2002 10:36:00 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.006A5499@cherry.ease.lsoft.com>; Wed, 24 Jul 2002 10:37:03 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 130807 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 24 Jul 2002 10:37:03 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 24 Jul 2002 10:37:02 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id F158C262813 for ; Wed, 24 Jul 2002 07:36:59 -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: <20020719181834.42442.qmail@web12702.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D3EBB8B.20406@redback.com> Date: Wed, 24 Jul 2002 10:36:59 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: RFCs 2328, 2740 & SeqNumber Mismatch Error To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Suvani Kaura wrote: > Hi All, > > I have a question pertaining to section 10.6 of RFC 2328, with > regards to generating SequenceNumberMismatch error, specifically the > following portion: > > When the router accepts a received Database Description Packet > as the next in sequence the packet contents are processed as > follows. For each LSA listed, the LSA's LS type is checked for > validity. If the LS type is unknown (e.g., not one of the LS > types 1-5 defined by this specification), or if this is an AS- > external-LSA (LS type = 5) and the neighbor is associated with a > stub area, generate the neighbor event SeqNumberMismatch and > stop processing the packet. > > At other places in the document, it is also stated that type-5 LSAs > should not be flooded (or summarized in DD packets) over virtual > links. Shouldn't reception of a type-5 LSA header over a virtual > link during DD exchange also cause the generation of > SeqNumberMismatch event? Suvani, This would seem to logical. However, since it wasn't in the original specification I would allow it in the spirit of being "liberal in what you accept". > > Additionally, am I correct in interpreting the above taken along with > RFC2740, to mean that for OPSFv3 unknown LSAs are permitted for > non-stub areas (irrespective of U-bit)? Only for Stub areas unknown > LSAs with U-bit == 1 should not be advertised in Updates & DDs, and > seq. num mismatch event be generated upon their receipt in DDs. The > rule about AS-wide LSAs still applies to both stub areas & virtual > links. Right? Haven't read this RFC 2740 in a while. > > Thanks for your input, > Suvani > > __________________________________________________ > Do You Yahoo!? > Yahoo! Autos - Get free new car price quotes > http://autos.yahoo.com > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jul 24 11:27:04 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 LAA21313 for ; Wed, 24 Jul 2002 11:27:03 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.006A588E@cherry.ease.lsoft.com>; Wed, 24 Jul 2002 11:28:05 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 131122 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 24 Jul 2002 11:28:05 -0400 Received: from 171.68.227.75 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 24 Jul 2002 11:28:04 -0400 Received: from cisco.com (dhcp-171-69-100-248.cisco.com [171.69.100.248]) by fire.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id g6OFS3329993 for ; Wed, 24 Jul 2002 08:28:03 -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: <20020719181834.42442.qmail@web12702.mail.yahoo.com> <3D3EBB8B.20406@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3D3EC783.8A96B68F@cisco.com> Date: Wed, 24 Jul 2002 08:28:03 -0700 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: RFCs 2328, 2740 & SeqNumber Mismatch Error To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Suvani > > > > > > Additionally, am I correct in interpreting the above taken along with > > RFC2740, to mean that for OPSFv3 unknown LSAs are permitted for > > non-stub areas (irrespective of U-bit)? right depending on the U bit the flooding scope will change from the actual flooding coded in the packet > Only for Stub areas unknown > > LSAs with U-bit == 1 should not be advertised in Updates & DDs, and > > seq. num mismatch event be generated upon their receipt in DDs. the LSA should have U bit set to 0 and link-local or area wide flooding scope in order to be flooded into Stub area although it is not mentioned explicitly but if the above condition is not satisfied SeqNumberMismatch should be generated > The > > rule about AS-wide LSAs still applies to both stub areas & virtual > > links. Right? for Stub yes for VL as Acee said it is not explicitly mentioned in the RFC 2328 further type 5 flooding are not flooded over VL in order to avoid duplicating of effort ( they are already flooded though the Transit area ) and Not because it is not allowed to be flooded as in case of Stub area Sina > > > > > > Thanks for your input, > > Suvani > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Autos - Get free new car price quotes > > http://autos.yahoo.com > > > > > > -- > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jul 24 14:44: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 OAA27267 for ; Wed, 24 Jul 2002 14:44: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.006A5E02@cherry.ease.lsoft.com>; Wed, 24 Jul 2002 14:45:17 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 131918 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 24 Jul 2002 14:45:16 -0400 Received: from 216.136.173.245 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 24 Jul 2002 14:45:16 -0400 Received: from [192.25.240.23] by web12708.mail.yahoo.com via HTTP; Wed, 24 Jul 2002 11:45:16 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20020724184516.77697.qmail@web12708.mail.yahoo.com> Date: Wed, 24 Jul 2002 11:45:16 -0700 Reply-To: Mailing List Sender: Mailing List From: Suvani Kaura Subject: Re: RFCs 2328, 2740 & SeqNumber Mismatch Error To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3D3EC783.8A96B68F@cisco.com> Precedence: list Thanks Sina & Acee. --- Sina Mirtorabi wrote: > > Only for Stub areas unknown LSAs with U-bit == 1 > > should not be advertised in Updates & DDs, and seq. > > num mismatch event be generated upon their receipt in DDs. > > the LSA should have U bit set to 0 and link-local or area wide > flooding scope in order to be flooded into Stub area > although it is not mentioned explicitly but if the above condition > is not satisfied SeqNumberMismatch should be generated > > > The rule about AS-wide LSAs still applies to both stub areas & > > virtual links. Right? > > for Stub yes for VL as Acee said it is not explicitly mentioned in > the RFC 2328 further type 5 flooding are not flooded over VL in > order to avoid duplicating of effort ( they are already flooded > though the Transit area ) and Not because it is not allowed to be > flooded as in case of Stub area > > Sina __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Thu Jul 25 14:38:04 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 OAA16473 for ; Thu, 25 Jul 2002 14:38:04 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.006A83CC@cherry.ease.lsoft.com>; Thu, 25 Jul 2002 14:39:05 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 135216 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 25 Jul 2002 14:39:04 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Thu, 25 Jul 2002 14:39:02 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 7D8A04F41B7 for ; Thu, 25 Jul 2002 11:39:01 -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: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D4045B5.1070209@redback.com> Date: Thu, 25 Jul 2002 14:38:45 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Link Flap Damping To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I really don't think adding this feature to OSPF is necessary for the following reasons: 1. Dampening the delivery/processing of "link up" events is a very good idea. However, I believe that this should be done locally at layer 2 rather than in OSPF. 2. The OSPF specified MinLSInterval is 5 seconds (RFC 2328, appendix B). This is already quite a long time and I don't think further dampening is required. 3. OSPF is an IGP and, as such, an OSPF instance should span a single routing domain under a single administrative authority. Hence, it should be possible to address and remedy link flapping issues. 4. I haven't heard a requirement for such a feature from a network operator (public or enterprise). Has anyone? It may make sense to dampen/control route redistribution (aka route import/export). RFC 1765 is an example. Another example from our implementation is the ability to configure the maximum number of redistributed routes and the rate at which external route changes are introduced into a routing domain. Thanks, Acee Manral, Vishwas wrote: > Hi Andrepeter, > > I haven't really been following the thread but now that you mentioned the > draft > http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-01.txt > > I would like to add that there are some things that we have mentioned in > section 4 of the draft that could help in case of "link flaps". > > The main point being to give more priority to "link down" than to "link up". > This could mean that in case of flaps we could signal "link down" > immediately however damp the "link up" event. Cengiz and Steve Casner > reached a similar conclusion with respect to ISIS protocol, they even > presented something related at NANOG. > > Thanks, > Vishwas > > >>...deleted... >>In my opinion the only service OSPF (or any other IGP) >>provides/should provide is connectivity, i.e. it tells you if >>a link exists and if it can carry traffic, not how much >>traffic there is. Route recalculation based on traffic >>information (congestion gives new cost values) should not be >>done as it will introduce route flaps. >>This also holds for a DiffServ world. In a DiffServ world >>packets are preferentially forwarded, but always such that no >>single class is starved. Even if some class gets so little BW >>that de-facto the link is down for that class, one should not >>declare the link down for that class, as it is equivalent >>with assigning a high cost for that link. Hence link monitor >>packets per class make no sense. (Besides, in long >>simulations with strict priority queueing we never had class >>starvation) >>As for Hello in the highest DiffServ class: we tested this >>idea in simulations for all OSPF packets, and results were >>excellent, i.e. route table convergence in the order of the >>half the minimum round trip time (excl. route table >>recalculations). This idea was also proposed in >>'draft-ietf-ospf-scalability-01.txt'. >> >>regards, >> >>Andrepeter >> > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Jul 26 01: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 BAA29908 for ; Fri, 26 Jul 2002 01: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 <19.006A927E@cherry.ease.lsoft.com>; Fri, 26 Jul 2002 1:16:02 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 136451 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 26 Jul 2002 01:16:02 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 26 Jul 2002 01:16:01 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Jul 2002 01:15:54 -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, 26 Jul 2002 01:18:17 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Link Flap Damping To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Acee, > 1. Dampening the delivery/processing of "link up" events is a very good idea. > However, I believe that this should be done locally at layer 2 rather > than in OSPF. I agree here. Infact check the mail I sent to the list some time back. http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0108&L=OSPF&P=R7962&I= -3 where I agree to what you have said, link flap is best dealt with the lower layer, the closer to hardware the better. > 2. The OSPF specified MinLSInterval is 5 seconds (RFC 2328, appendix B). This > is already quite a long time and I don't think further dampening is required. There is a difference here. MinLSInterval does prevent the same LSA from being originated too soon. However this does not prevent the entire adjacencies to have to be reformed/broken. Damping the flap can prevent us from doing this(in case the thing is not done at a lower layer). > 3. OSPF is an IGP and, as such, an OSPF instance should span a single routing > domain under a single administrative authority. Hence, it should be possible > to address and remedy link flapping issues. Agreed !!! > 4. I haven't heard a requirement for such a feature from a network operator > (public or enterprise). Has anyone? Not exactly, but I guess the study by Cengiz and Steve on faster convergence does talk about advantages of asymmetricaly damping Up/Down events, where and how it is done I guess is left to the implementor. This was presented at one of the recent NANOG meetings. The study was done on the Qwest backbone. In our draft(with the AT&T folks) we did find this feature useful in case of congestion/scalability conditions too. Infact I guess Nokia also did a study on this and came with similar results. Thanks, Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Fri Jul 26 02:15: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 CAA09613 for ; Fri, 26 Jul 2002 02:15:20 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.006A9566@cherry.ease.lsoft.com>; Fri, 26 Jul 2002 2:16:23 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 136693 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 26 Jul 2002 02:16:23 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 26 Jul 2002 02:16:22 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id D785C18D3E8 for ; Thu, 25 Jul 2002 23:16:20 -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: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D40E91E.8060304@redback.com> Date: Fri, 26 Jul 2002 02:15:58 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Link Flap Damping To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Manral, Vishwas wrote: > Hi Acee, Hi Vishwas, > > >> 1. Dampening the delivery/processing of "link up" events is a very good >> > idea. > >> However, I believe that this should be done locally at layer 2 >> > rather > >> than in OSPF. >> > I agree here. Infact check the mail I sent to the list some time back. > http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0108&L=OSPF&P=R7962&I= > -3 where I agree to what you have said, link flap is best dealt with the > lower layer, the closer to hardware the better. > > >> 2. The OSPF specified MinLSInterval is 5 seconds (RFC 2328, appendix B). >> > This > >> is already quite a long time and I don't think further dampening is >> > required. > There is a difference here. MinLSInterval does prevent the same LSA from > being originated too soon. However this does not prevent the entire > adjacencies to have to be reformed/broken. Damping the flap can prevent us > from doing this(in case the thing is not done at a lower layer). You're right. After I sent the E-mail I thought of at least two scenarios where MinLSInterval doesn't prevent multiple originations and flushes in the same 5 second interval. There are probably more. 1. You have a broadcast network with two routers. The non-DR is flapping. The DR will originate and purge his network LSA at the rate it takes to for the two routers to establish an adjacency (the DR's router LSA will be origination rate limited by MinLSInterval) . This could easily be handled - does anyone keep a timestamp in the OSPF interface data structure to prevent this? 2. An ABR's intra-area routes are flapping faster than MinLSInterval. This could happen if multiple routers are advertising the same unstable network but are not in sync as far as originating LSAs. Each of the intra-area routers will be limited by MinLSInterval but the ABR could be purging and originating the corresponding summary LSAs at a faster rate. > > >> 3. OSPF is an IGP and, as such, an OSPF instance should span a single >> > routing > >> domain under a single administrative authority. Hence, it should be >> > possible > >> to address and remedy link flapping issues. >> > Agreed !!! > > >> 4. I haven't heard a requirement for such a feature from a network >> > operator > >>(public or enterprise). Has anyone? >> > Not exactly, but I guess the study by Cengiz and Steve on faster convergence > does talk about advantages of asymmetricaly damping Up/Down events, where > and how it is done I guess is left to the implementor. This was presented at > one of the recent NANOG meetings. The study was done on the Qwest backbone. > > In our draft(with the AT&T folks) we did find this feature useful in case of > congestion/scalability conditions too. Infact I guess Nokia also did a study > on this and came with similar results. I'll take a look at the draft again. > > Thanks, > Vishwas > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Jul 26 02:45: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 CAA10184 for ; Fri, 26 Jul 2002 02:45:18 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.006A949B@cherry.ease.lsoft.com>; Fri, 26 Jul 2002 2:46:22 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 136817 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 26 Jul 2002 02:46:22 -0400 Received: from 203.254.224.24 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 26 Jul 2002 02:46:22 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) id <0GZU00501G93ZV@mailout1.samsung.com> for ospf@diSCUSS.MICROSOFT.COM; Fri, 26 Jul 2002 15:48:39 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GZU0059HG93N2@mailout1.samsung.com> for ospf@diSCUSS.MICROSOFT.COM; Fri, 26 Jul 2002 15:48:39 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0GZU003FNG993M@mmp2.samsung.com> for ospf@diSCUSS.MICROSOFT.COM; Fri, 26 Jul 2002 15:48:47 +0900 (KST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Message-ID: <003e01c2346f$8a62f330$b4036c6b@sisodomain.com> Date: Fri, 26 Jul 2002 12:11:57 +0530 Reply-To: Mailing List Sender: Mailing List From: Manav Bhatia Subject: Re: Link Flap Damping Comments: To: vishwasM@netplane.com To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7BIT Hi Vishwas, Are you aware of any vendor implementing link flap damping in the hardware? If there are such implementations out there and it is not a standard then cant it create problems out there in the wild when you can snoop HELLOs coming from the other end but find them not being delivered to your OSPF instance because of which the adjacency never comes up? Infact understanding the fact that those HELLOs are not being delivered to your local OSPF daemon will itself take up some time !!! Regards, Manav ----- Original Message ----- From: "Manral, Vishwas" To: Sent: Friday, July 26, 2002 10:48 AM Subject: Re: Link Flap Damping || > than in OSPF. | I agree here. Infact check the mail I sent to the list some time back. | http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0108&L=OSPF&P=R7962&I = | -3 where I agree to what you have said, link flap is best dealt with the | lower layer, the closer to hardware the better. | | > 2. The OSPF specified MinLSInterval is 5 seconds (RFC 2328, appendix B). | This | > is already quite a long time and I don't think further dampening is | required. | There is a difference here. MinLSInterval does prevent the same LSA from | being originated too soon. However this does not prevent the entire | adjacencies to have to be reformed/broken. Damping the flap can prevent us | from doing this(in case the thing is not done at a lower layer). | | > 3. OSPF is an IGP and, as such, an OSPF instance should span a single | routing | > domain under a single administrative authority. Hence, it should be | possible | > to address and remedy link flapping issues. | Agreed !!! | | > 4. I haven't heard a requirement for such a feature from a network | operator | > (public or enterprise). Has anyone? | Not exactly, but I guess the study by Cengiz and Steve on faster convergence | does talk about advantages of asymmetricaly damping Up/Down events, where | and how it is done I guess is left to the implementor. This was presented at | one of the recent NANOG meetings. The study was done on the Qwest backbone. | | In our draft(with the AT&T folks) we did find this feature useful in case of | congestion/scalability conditions too. Infact I guess Nokia also did a study | on this and came with similar results. | | Thanks, | Vishwas ---- "When you are courting a nice girl an hour seems like a second. When you sit on a red-hot cinder a second seems like an hour. That's relativity." -Albert Einstein, on relativity From owner-ospf@DISCUSS.MICROSOFT.COM Fri Jul 26 03:01: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 DAA10582 for ; Fri, 26 Jul 2002 03:01:39 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.006A94D1@cherry.ease.lsoft.com>; Fri, 26 Jul 2002 3:02:42 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 136893 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 26 Jul 2002 03:02:42 -0400 Received: from 64.4.14.182 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 26 Jul 2002 03:02:42 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 26 Jul 2002 00:02:41 -0700 Received: from 203.196.146.243 by lw10fd.law10.hotmail.msn.com with HTTP; Fri, 26 Jul 2002 07:02:41 GMT X-Originating-IP: [203.196.146.243] Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 26 Jul 2002 07:02:41.0668 (UTC) FILETIME=[6F386C40:01C23472] Message-ID: Date: Fri, 26 Jul 2002 07:02:41 +0000 Reply-To: Mailing List Sender: Mailing List From: praveendas e Subject: Re: Link state data base example To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hai Acee Can you specify the reason for using option 1 instead of using option 2 for describing point-to-point numbered interfaces. Regards Praveendas >From: Acee Lindem >Reply-To: Mailing List >To: OSPF@DISCUSS.MICROSOFT.COM >Subject: Re: Link state data base example >Date: Wed, 24 Jul 2002 10:14:20 -0400 > > Praveendas, > >This is in fact the route table that will result using Option 1 >for describing point-to-point numbered interfaces (section >12.4.1.1). This is because RT10 is the only router advertising >a /32 prefix to Ia (RT6's local address). If Option 2 is used, > the OSPF computed route will be the same as the direct (i.e., >connected) route. > >Good Luck, >Acee > > > >praveendas e wrote: > >>Hai all >> i am new to this group ,hope somebody will clear my doubt >> >>My question is >>In RFC 2328 ,section 2.1.2 An Example link-state database ,figure 2 >>The router R6 had an interface to Ia ,it is a stub network, >>when the router RT6 calculate the routing table it is used RT10 as the >>next hope to the stub network Ia having a cost of 12( i.e in section 2.2 >>The >>shortest -path tree) >>eventhough the router RT6 is directly connected to Ia with cost 7 ... >> >>1.why it is using RT10 as next hope to Ia (the stub network)? >>2.Why RT6 is adverising its direct interface,with other router as next >>hop? >> >>Thanks in Advance >>Regards >>Praveendas >> >> >> >> >>_________________________________________________________________ >>Join the world's largest e-mail service with MSN Hotmail. >>http://www.hotmail.com >> > > >-- >Acee _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com From owner-ospf@DISCUSS.MICROSOFT.COM Fri Jul 26 10:18: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 KAA21225 for ; Fri, 26 Jul 2002 10:18:15 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.006A9A20@cherry.ease.lsoft.com>; Fri, 26 Jul 2002 10:19:13 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 138198 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 26 Jul 2002 10:19:13 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 26 Jul 2002 10:19:13 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 98BEDCAB68 for ; Fri, 26 Jul 2002 07:19:11 -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: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D415A44.5030101@redback.com> Date: Fri, 26 Jul 2002 10:18:44 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Link state data base example To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit praveendas e wrote: > Hai Acee > Can you specify the reason for using option 1 instead of using option 2 > for describing point-to-point numbered interfaces. > Regards > Praveendas Hello Praveendas, Option 1 preceded option 2. BSD based systems have always treated a point-to-point link as a way of getting to single IP destination as opposed to a subnet. This could be considered more topologically correct since a P2P link only leads to a single destination. However, I think it is much simpler to treat all the numbered interfaces as subnets and special case the unnumbered case. In fact, the implementation I'm working on now does not provide a configuration knob to use option 1. So, in response to your original question, the only reason I can think of to use option 1 is to be compatible with an OSPF implementation that only supports option 1. > > >> From: Acee Lindem >> Reply-To: Mailing List >> To: OSPF@DISCUSS.MICROSOFT.COM >> Subject: Re: Link state data base example >> Date: Wed, 24 Jul 2002 10:14:20 -0400 >> >> Praveendas, >> >> This is in fact the route table that will result using Option 1 >> for describing point-to-point numbered interfaces (section >> 12.4.1.1). This is because RT10 is the only router advertising >> a /32 prefix to Ia (RT6's local address). If Option 2 is used, >> the OSPF computed route will be the same as the direct (i.e., >> connected) route. >> >> Good Luck, >> Acee >> >> >> >> praveendas e wrote: >> >>> Hai all >>> i am new to this group ,hope somebody will clear my doubt >>> >>> My question is >>> In RFC 2328 ,section 2.1.2 An Example link-state database ,figure 2 >>> The router R6 had an interface to Ia ,it is a stub network, >>> when the router RT6 calculate the routing table it is used RT10 as the >>> next hope to the stub network Ia having a cost of 12( i.e in section 2.2 >>> The >>> shortest -path tree) >>> eventhough the router RT6 is directly connected to Ia with cost 7 ... >>> >>> 1.why it is using RT10 as next hope to Ia (the stub network)? >>> 2.Why RT6 is adverising its direct interface,with other router as next >>> hop? >>> >>> Thanks in Advance >>> Regards >>> Praveendas >>> >>> >>> >>> >>> _________________________________________________________________ >>> Join the world's largest e-mail service with MSN Hotmail. >>> http://www.hotmail.com >>> >> >> >> -- >> Acee > > > > > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Jul 26 12:44: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 MAA29318 for ; Fri, 26 Jul 2002 12:44:51 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.006A9E5B@cherry.ease.lsoft.com>; Fri, 26 Jul 2002 12:45:55 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 138578 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 26 Jul 2002 12:45:55 -0400 Received: from 205.226.5.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 26 Jul 2002 12:45:54 -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 JAA00507; Fri, 26 Jul 2002 09:45:52 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g6QGjpb12161; Fri, 26 Jul 2002 09:45:51 -0700 X-mProtect: <200207261645> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.19.66.85, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd5u2BIa; Fri, 26 Jul 2002 09:45:49 PDT X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3D417CBB.2AB20AD8@iprg.nokia.com> Date: Fri, 26 Jul 2002 09:45:47 -0700 Reply-To: Mailing List Sender: Mailing List From: Mukesh Gupta Organization: Nokia Subject: Draft on providing Authentication/Confidentiality to OSPFv3 Comments: To: ipsec@lists.tislabs.com Comments: cc: nmelam@iprg.nokia.com To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi All, We have submitted the following internet draft on providing Authentication/Confidentiality to OSPFv3 using IPsec. Version 01 of the draft is available at http://www.ietf.org/internet-drafts/draft-gupta-ospf-ospfv3-auth-01.txt We would highly appreciate comments/suggestions from everyone. Thanks. Mukesh & Suresh From owner-ospf@DISCUSS.MICROSOFT.COM Fri Jul 26 12:49:02 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 MAA29602 for ; Fri, 26 Jul 2002 12:49:02 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.006A9FD2@cherry.ease.lsoft.com>; Fri, 26 Jul 2002 12:50:06 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 138609 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 26 Jul 2002 12:50:06 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Fri, 26 Jul 2002 12:50:06 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 20AC9FC05E for ; Fri, 26 Jul 2002 09:50:05 -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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D417DA0.5050404@redback.com> Date: Fri, 26 Jul 2002 12:49:36 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Comments on OSPF PC/CE Drafts To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I posted this on the PPVPN list. I'm posting here as well since some of you may not be aware of these drafts.... Here are my comments on draft-rosen-vpns-ospf-bgp-mpls-04.txt and draft-rosen-ppvpn-ospf2547-area0-00.txt: General: - It would seem that these two drafts could be combined since draft-rosen-ppvpn-ospf2547-area0-00.txt only contains a couple paragraphs of unique information. This would also avoid all references in draft-rosen-vpns-ospf-bgp-mpls-04.txt - The PE router doesn't really have to be an ABR. It is already "faking" that VPN redistributed routes are inter-area routes. It can also set its router LSA B bit accordingly. Oh well, maybe this could be considered an implementation detail. draft-rosen-vpns-ospf-bgp-mpls-04.txt: - Page 4, second list item. Since the VPN routes are advertised as type 3 LSAs, I believe you should say "inter-area routes" rather than "intra-network routes". - Page 6, Again - A PE router doesn't necessarily have to be an area 0 router. It just has to present itself as a border router advertise type 3 LSAs. - Page 11 - This states that the sham link endpoint "must be advertised as VPN-IPv4 address and it may be distributed by OSPF". The extant implementation does not advertise the sham endpoint as an OSPF VPN route (one must redistribute the connected route corresponding to the loopback address of the sham link endpoint). Advertising the sham link endpoint as an OSPF route is only needed for auto-configuration (unless I'm missing something). - Page 11 - Why is auto-configuration a "MUST"? It seems to me that the use of sham-links will be limited and the use of a full mesh of sham links will be even rarer. - Page 12 - State the default hello and dead time for the sham link. Experience has shown that the existing implementation uses 10 and 40 but this is non-obvious due to the fact that an OSPF virtual link defaults to 40 and 120. - Page 12, last paragraph - Don't you mean that the PE should not install the route into the VRF routing table (since there should already be a BGP route). This will insure it doesn't replace the route and that it is not redistributed. - Page 13 - I believe the bulleted conditions could be greatly simplified. - the VRF has a non-zero OSPF Domain Identifier, but the route does not have a non-zero OSPF Domain Identifier Extended Communities attribute, or ((VRF-Domain-ID != 0) && !(Route-Domain-ID != 0)) || - the route has an OSPF Domain Identifier Extended Communities attribute whose value is not the same as the OSPF Domain Identifier associated with the VRF (Route-Domain-ID != VRF-Domain-ID) Isn't the first condition unnecessary since it is a subset of the second? draft-rosen-ppvpn-ospf2547-area0-00.txt No additional comments. That's all for now... Thanks, --- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Sat Jul 27 06:11: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 GAA29658 for ; Sat, 27 Jul 2002 06:11:12 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.006AB33B@cherry.ease.lsoft.com>; Sat, 27 Jul 2002 6:12:15 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 140520 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 27 Jul 2002 06:12:15 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sat, 27 Jul 2002 06:12:15 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Sat, 27 Jul 2002 06:12: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: Sat, 27 Jul 2002 06:14:43 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Link Flap Damping To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Manav, Though I do not remember the details(and things have changed a lot there), in RPR(802.17) there is something called a "Wait To Restore"(WTR) timer. A failed link is required to show no failure for the given period of time before being declared working. Thanks, Vishwas -----Original Message----- From: Manav Bhatia [mailto:manav@SAMSUNG.COM] Sent: Friday, July 26, 2002 12:12 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Link Flap Damping Hi Vishwas, Are you aware of any vendor implementing link flap damping in the hardware? If there are such implementations out there and it is not a standard then cant it create problems out there in the wild when you can snoop HELLOs coming from the other end but find them not being delivered to your OSPF instance because of which the adjacency never comes up? Infact understanding the fact that those HELLOs are not being delivered to your local OSPF daemon will itself take up some time !!! Regards, Manav ----- Original Message ----- From: "Manral, Vishwas" To: Sent: Friday, July 26, 2002 10:48 AM Subject: Re: Link Flap Damping || > than in OSPF. | I agree here. Infact check the mail I sent to the list some time back. | http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0108&L=OSPF&P=R7962&I = | -3 where I agree to what you have said, link flap is best dealt with the | lower layer, the closer to hardware the better. | | > 2. The OSPF specified MinLSInterval is 5 seconds (RFC 2328, appendix B). | This | > is already quite a long time and I don't think further dampening is | required. | There is a difference here. MinLSInterval does prevent the same LSA from | being originated too soon. However this does not prevent the entire | adjacencies to have to be reformed/broken. Damping the flap can prevent us | from doing this(in case the thing is not done at a lower layer). | | > 3. OSPF is an IGP and, as such, an OSPF instance should span a single | routing | > domain under a single administrative authority. Hence, it should be | possible | > to address and remedy link flapping issues. | Agreed !!! | | > 4. I haven't heard a requirement for such a feature from a network | operator | > (public or enterprise). Has anyone? | Not exactly, but I guess the study by Cengiz and Steve on faster convergence | does talk about advantages of asymmetricaly damping Up/Down events, where | and how it is done I guess is left to the implementor. This was presented at | one of the recent NANOG meetings. The study was done on the Qwest backbone. | | In our draft(with the AT&T folks) we did find this feature useful in case of | congestion/scalability conditions too. Infact I guess Nokia also did a study | on this and came with similar results. | | Thanks, | Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Sat Jul 27 08:10: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 IAA00847 for ; Sat, 27 Jul 2002 08:10:50 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.006AB42F@cherry.ease.lsoft.com>; Sat, 27 Jul 2002 8:11:54 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 140702 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 27 Jul 2002 08:11:54 -0400 Received: from 203.178.142.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sat, 27 Jul 2002 08:11:53 -0400 Received: from localhost (page.sfc.wide.ad.jp [203.178.143.89]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 27A985D01A; Sat, 27 Jul 2002 21:11:52 +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: <20020727.210403.21240676.yasu@sfc.wide.ad.jp> Date: Sat, 27 Jul 2002 21:04:03 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: Link Flap Damping Comments: To: VishwasM@NETPLANE.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit All, The L2's link flap dampen feature is not enough, since L3 (i.e. OSPF) uses its own method to detect link flap. Even if the L2 do not trigger up/down events to OSPF process, there will still be a case where a OSPF process detects link flaps by Hello. If one want to say "L2 flap dampening feature is enough to prevent OSPF to flap", we have to remove Hello. This is obviously not what we want. regards. yasu VishwasM> Hi Manav, VishwasM> VishwasM> Though I do not remember the details(and things have changed a lot there), VishwasM> in RPR(802.17) there is something called a "Wait To Restore"(WTR) timer. A VishwasM> failed link is required to show no failure for the given period of time VishwasM> before being declared working. VishwasM> VishwasM> Thanks, VishwasM> Vishwas VishwasM> VishwasM> -----Original Message----- VishwasM> From: Manav Bhatia [mailto:manav@SAMSUNG.COM] VishwasM> Sent: Friday, July 26, 2002 12:12 PM VishwasM> To: OSPF@DISCUSS.MICROSOFT.COM VishwasM> Subject: Re: Link Flap Damping VishwasM> VishwasM> VishwasM> Hi Vishwas, VishwasM> Are you aware of any vendor implementing link flap damping in the hardware? VishwasM> VishwasM> If there are such implementations out there and it is not a standard then VishwasM> cant it create problems out there in the wild when you can snoop HELLOs VishwasM> coming from the other end but find them not being delivered to your OSPF VishwasM> instance because of which the adjacency never comes up? VishwasM> VishwasM> Infact understanding the fact that those HELLOs are not being delivered to VishwasM> your local OSPF daemon will itself take up some time !!! VishwasM> VishwasM> Regards, VishwasM> Manav VishwasM> ----- Original Message ----- VishwasM> From: "Manral, Vishwas" VishwasM> To: VishwasM> Sent: Friday, July 26, 2002 10:48 AM VishwasM> Subject: Re: Link Flap Damping VishwasM> VishwasM> VishwasM> || > than in OSPF. VishwasM> | I agree here. Infact check the mail I sent to the list some time back. VishwasM> | VishwasM> http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0108&L=OSPF&P=R7962&I VishwasM> = VishwasM> | -3 where I agree to what you have said, link flap is best dealt with the VishwasM> | lower layer, the closer to hardware the better. VishwasM> | VishwasM> | > 2. The OSPF specified MinLSInterval is 5 seconds (RFC 2328, appendix VishwasM> B). VishwasM> | This VishwasM> | > is already quite a long time and I don't think further dampening VishwasM> is VishwasM> | required. VishwasM> | There is a difference here. MinLSInterval does prevent the same LSA from VishwasM> | being originated too soon. However this does not prevent the entire VishwasM> | adjacencies to have to be reformed/broken. Damping the flap can prevent VishwasM> us VishwasM> | from doing this(in case the thing is not done at a lower layer). VishwasM> | VishwasM> | > 3. OSPF is an IGP and, as such, an OSPF instance should span a single VishwasM> | routing VishwasM> | > domain under a single administrative authority. Hence, it should VishwasM> be VishwasM> | possible VishwasM> | > to address and remedy link flapping issues. VishwasM> | Agreed !!! VishwasM> | VishwasM> | > 4. I haven't heard a requirement for such a feature from a network VishwasM> | operator VishwasM> | > (public or enterprise). Has anyone? VishwasM> | Not exactly, but I guess the study by Cengiz and Steve on faster VishwasM> convergence VishwasM> | does talk about advantages of asymmetricaly damping Up/Down events, where VishwasM> | and how it is done I guess is left to the implementor. This was presented VishwasM> at VishwasM> | one of the recent NANOG meetings. The study was done on the Qwest VishwasM> backbone. VishwasM> | VishwasM> | In our draft(with the AT&T folks) we did find this feature useful in case VishwasM> of VishwasM> | congestion/scalability conditions too. Infact I guess Nokia also did a VishwasM> study VishwasM> | on this and came with similar results. VishwasM> | VishwasM> | Thanks, VishwasM> | Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Sat Jul 27 09:31: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 JAA01777 for ; Sat, 27 Jul 2002 09:31: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.006AB612@cherry.ease.lsoft.com>; Sat, 27 Jul 2002 9:31:26 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 140818 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 27 Jul 2002 09:31:26 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sat, 27 Jul 2002 09:31:25 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Sat, 27 Jul 2002 09:31:17 -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, 27 Jul 2002 09:33:29 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Link Flap Damping To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Yasu, If both ends of a link do have a link damping feature what problem would it still not solve. The hellos would not be causing any flap if the lower layer itself has taken care that the flap, because it would not convey a link up event till the link showed no failure for some time(as in RPR example below). Yes, for congestion case something may be required. We have put that down in our draft congestion-control draft. Thanks, Vishwas -----Original Message----- From: Yasuhiro Ohara [mailto:yasu@SFC.WIDE.AD.JP] Sent: Saturday, July 27, 2002 5:34 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Link Flap Damping All, The L2's link flap dampen feature is not enough, since L3 (i.e. OSPF) uses its own method to detect link flap. Even if the L2 do not trigger up/down events to OSPF process, there will still be a case where a OSPF process detects link flaps by Hello. If one want to say "L2 flap dampening feature is enough to prevent OSPF to flap", we have to remove Hello. This is obviously not what we want. regards. yasu VishwasM> Hi Manav, VishwasM> VishwasM> Though I do not remember the details(and things have changed a lot there), VishwasM> in RPR(802.17) there is something called a "Wait To Restore"(WTR) timer. A VishwasM> failed link is required to show no failure for the given period of time VishwasM> before being declared working. VishwasM> VishwasM> Thanks, VishwasM> Vishwas VishwasM> VishwasM> -----Original Message----- VishwasM> From: Manav Bhatia [mailto:manav@SAMSUNG.COM] VishwasM> Sent: Friday, July 26, 2002 12:12 PM VishwasM> To: OSPF@DISCUSS.MICROSOFT.COM VishwasM> Subject: Re: Link Flap Damping VishwasM> VishwasM> VishwasM> Hi Vishwas, VishwasM> Are you aware of any vendor implementing link flap damping in the hardware? VishwasM> VishwasM> If there are such implementations out there and it is not a standard then VishwasM> cant it create problems out there in the wild when you can snoop HELLOs VishwasM> coming from the other end but find them not being delivered to your OSPF VishwasM> instance because of which the adjacency never comes up? VishwasM> VishwasM> Infact understanding the fact that those HELLOs are not being delivered to VishwasM> your local OSPF daemon will itself take up some time !!! VishwasM> VishwasM> Regards, VishwasM> Manav VishwasM> ----- Original Message ----- VishwasM> From: "Manral, Vishwas" VishwasM> To: VishwasM> Sent: Friday, July 26, 2002 10:48 AM VishwasM> Subject: Re: Link Flap Damping VishwasM> VishwasM> VishwasM> || > than in OSPF. VishwasM> | I agree here. Infact check the mail I sent to the list some time back. VishwasM> | VishwasM> http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0108&L=OSPF&P=R7962&I VishwasM> = VishwasM> | -3 where I agree to what you have said, link flap is best dealt with the VishwasM> | lower layer, the closer to hardware the better. VishwasM> | VishwasM> | > 2. The OSPF specified MinLSInterval is 5 seconds (RFC 2328, appendix VishwasM> B). VishwasM> | This VishwasM> | > is already quite a long time and I don't think further dampening VishwasM> is VishwasM> | required. VishwasM> | There is a difference here. MinLSInterval does prevent the same LSA from VishwasM> | being originated too soon. However this does not prevent the entire VishwasM> | adjacencies to have to be reformed/broken. Damping the flap can prevent VishwasM> us VishwasM> | from doing this(in case the thing is not done at a lower layer). VishwasM> | VishwasM> | > 3. OSPF is an IGP and, as such, an OSPF instance should span a single VishwasM> | routing VishwasM> | > domain under a single administrative authority. Hence, it should VishwasM> be VishwasM> | possible VishwasM> | > to address and remedy link flapping issues. VishwasM> | Agreed !!! VishwasM> | VishwasM> | > 4. I haven't heard a requirement for such a feature from a network VishwasM> | operator VishwasM> | > (public or enterprise). Has anyone? VishwasM> | Not exactly, but I guess the study by Cengiz and Steve on faster VishwasM> convergence VishwasM> | does talk about advantages of asymmetricaly damping Up/Down events, where VishwasM> | and how it is done I guess is left to the implementor. This was presented VishwasM> at VishwasM> | one of the recent NANOG meetings. The study was done on the Qwest VishwasM> backbone. VishwasM> | VishwasM> | In our draft(with the AT&T folks) we did find this feature useful in case VishwasM> of VishwasM> | congestion/scalability conditions too. Infact I guess Nokia also did a VishwasM> study VishwasM> | on this and came with similar results. VishwasM> | VishwasM> | Thanks, VishwasM> | Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Sat Jul 27 13:33: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 NAA05103 for ; Sat, 27 Jul 2002 13:33:23 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.006AB98F@cherry.ease.lsoft.com>; Sat, 27 Jul 2002 13:34:26 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 141251 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 27 Jul 2002 13:34:26 -0400 Received: from 207.217.120.123 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sat, 27 Jul 2002 13:34:26 -0400 Received: from user-2ivfmpj.dialup.mindspring.com ([165.247.219.51] helo=earthlink.net) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17YVSS-0004nD-00 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 27 Jul 2002 10:34:24 -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: <3D42DC40.ED8D4D88@earthlink.net> Date: Sat, 27 Jul 2002 10:45:36 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Link Flap Damping To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Ummm, I wasn't sure whether I wanted to get involved in this great discussion... Has anyone seen or invisioned an interaction with "link flap dampening" and Moy's OSPF implimentation where he attempts to accelerate bi-directional status? Chapt 1, p.2 1.1.1 Optimizations Basicly, can a damped link on one side prevent this acceleration to occur? And should this accelerated method bunch the load on a router and thus counter-intuitive to congestion control? Especially with a set of routers all coming up at the same time and then the bunching of adjacency formations. Mitchell Erblich ================== "Manral, Vishwas" wrote: > > Hi Yasu, > > If both ends of a link do have a link damping feature what problem would it > still not solve. The hellos would not be causing any flap if the lower layer > itself has taken care that the flap, because it would not convey a link up > event till the link showed no failure for some time(as in RPR example > below). > > Yes, for congestion case something may be required. We have put that down in > our draft congestion-control draft. > > Thanks, > Vishwas > > -----Original Message----- > From: Yasuhiro Ohara [mailto:yasu@SFC.WIDE.AD.JP] > Sent: Saturday, July 27, 2002 5:34 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: Link Flap Damping > > All, > > The L2's link flap dampen feature is not enough, since L3 (i.e. OSPF) > uses its own method to detect link flap. Even if the L2 do not trigger > up/down events to OSPF process, there will still be a case where a > OSPF process detects link flaps by Hello. > > If one want to say "L2 flap dampening feature is enough to prevent > OSPF to flap", we have to remove Hello. This is obviously not what we > want. > > regards. > yasu > > VishwasM> Hi Manav, > VishwasM> > VishwasM> Though I do not remember the details(and things have changed a lot > there), > VishwasM> in RPR(802.17) there is something called a "Wait To Restore"(WTR) > timer. A > VishwasM> failed link is required to show no failure for the given period of > time > VishwasM> before being declared working. > VishwasM> > VishwasM> Thanks, > VishwasM> Vishwas > VishwasM> > VishwasM> -----Original Message----- > VishwasM> From: Manav Bhatia [mailto:manav@SAMSUNG.COM] > VishwasM> Sent: Friday, July 26, 2002 12:12 PM > VishwasM> To: OSPF@DISCUSS.MICROSOFT.COM > VishwasM> Subject: Re: Link Flap Damping > VishwasM> > VishwasM> > VishwasM> Hi Vishwas, > VishwasM> Are you aware of any vendor implementing link flap damping in the > hardware? > VishwasM> > VishwasM> If there are such implementations out there and it is not a > standard then > VishwasM> cant it create problems out there in the wild when you can snoop > HELLOs > VishwasM> coming from the other end but find them not being delivered to > your OSPF > VishwasM> instance because of which the adjacency never comes up? > VishwasM> > VishwasM> Infact understanding the fact that those HELLOs are not being > delivered to > VishwasM> your local OSPF daemon will itself take up some time !!! > VishwasM> > VishwasM> Regards, > VishwasM> Manav > VishwasM> ----- Original Message ----- > VishwasM> From: "Manral, Vishwas" > VishwasM> To: > VishwasM> Sent: Friday, July 26, 2002 10:48 AM > VishwasM> Subject: Re: Link Flap Damping > VishwasM> > VishwasM> > VishwasM> || > than in OSPF. > VishwasM> | I agree here. Infact check the mail I sent to the list some time > back. > VishwasM> | > VishwasM> > http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0108&L=OSPF&P=R7962&I > VishwasM> = > VishwasM> | -3 where I agree to what you have said, link flap is best dealt > with the > VishwasM> | lower layer, the closer to hardware the better. > VishwasM> | > VishwasM> | > 2. The OSPF specified MinLSInterval is 5 seconds (RFC 2328, > appendix > VishwasM> B). > VishwasM> | This > VishwasM> | > is already quite a long time and I don't think further > dampening > VishwasM> is > VishwasM> | required. > VishwasM> | There is a difference here. MinLSInterval does prevent the same > LSA from > VishwasM> | being originated too soon. However this does not prevent the > entire > VishwasM> | adjacencies to have to be reformed/broken. Damping the flap can > prevent > VishwasM> us > VishwasM> | from doing this(in case the thing is not done at a lower layer). > VishwasM> | > VishwasM> | > 3. OSPF is an IGP and, as such, an OSPF instance should span > a single > VishwasM> | routing > VishwasM> | > domain under a single administrative authority. Hence, > it should > VishwasM> be > VishwasM> | possible > VishwasM> | > to address and remedy link flapping issues. > VishwasM> | Agreed !!! > VishwasM> | > VishwasM> | > 4. I haven't heard a requirement for such a feature from a > network > VishwasM> | operator > VishwasM> | > (public or enterprise). Has anyone? > VishwasM> | Not exactly, but I guess the study by Cengiz and Steve on faster > VishwasM> convergence > VishwasM> | does talk about advantages of asymmetricaly damping Up/Down > events, where > VishwasM> | and how it is done I guess is left to the implementor. This was > presented > VishwasM> at > VishwasM> | one of the recent NANOG meetings. The study was done on the > Qwest > VishwasM> backbone. > VishwasM> | > VishwasM> | In our draft(with the AT&T folks) we did find this feature > useful in case > VishwasM> of > VishwasM> | congestion/scalability conditions too. Infact I guess Nokia also > did a > VishwasM> study > VishwasM> | on this and came with similar results. > VishwasM> | > VishwasM> | Thanks, > VishwasM> | Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Sat Jul 27 17:21: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 RAA07664 for ; Sat, 27 Jul 2002 17:21:15 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.006ABECA@cherry.ease.lsoft.com>; Sat, 27 Jul 2002 17:22:19 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 141703 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 27 Jul 2002 17:22:19 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Sat, 27 Jul 2002 17:22:19 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 189C8CAB6E for ; Sat, 27 Jul 2002 14:22:17 -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: <20020727.210403.21240676.yasu@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D430EDD.2000302@redback.com> Date: Sat, 27 Jul 2002 17:21:33 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Link Flap Damping To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Yasuhiro Ohara wrote: > All, > > The L2's link flap dampen feature is not enough, since L3 (i.e. OSPF) > uses its own method to detect link flap. Even if the L2 do not trigger > up/down events to OSPF process, there will still be a case where a > OSPF process detects link flaps by Hello. > > If one want to say "L2 flap dampening feature is enough to prevent > OSPF to flap", we have to remove Hello. This is obviously not what we > want. Yasu, Normally, it is the link up event that is dampened at layer 2 and it is normally done in a such a way that the OSPF hello packets will not be received or will be dropped at a low level. Thanks, Acee > > regards. > yasu > > VishwasM> Hi Manav, > VishwasM> > VishwasM> Though I do not remember the details(and things have changed a lot there), > VishwasM> in RPR(802.17) there is something called a "Wait To Restore"(WTR) timer. A > VishwasM> failed link is required to show no failure for the given period of time > VishwasM> before being declared working. > VishwasM> > VishwasM> Thanks, > VishwasM> Vishwas > VishwasM> > VishwasM> -----Original Message----- > VishwasM> From: Manav Bhatia [mailto:manav@SAMSUNG.COM] > VishwasM> Sent: Friday, July 26, 2002 12:12 PM > VishwasM> To: OSPF@DISCUSS.MICROSOFT.COM > VishwasM> Subject: Re: Link Flap Damping > VishwasM> > VishwasM> > VishwasM> Hi Vishwas, > VishwasM> Are you aware of any vendor implementing link flap damping in the hardware? > VishwasM> > VishwasM> If there are such implementations out there and it is not a standard then > VishwasM> cant it create problems out there in the wild when you can snoop HELLOs > VishwasM> coming from the other end but find them not being delivered to your OSPF > VishwasM> instance because of which the adjacency never comes up? > VishwasM> > VishwasM> Infact understanding the fact that those HELLOs are not being delivered to > VishwasM> your local OSPF daemon will itself take up some time !!! > VishwasM> > VishwasM> Regards, > VishwasM> Manav > VishwasM> ----- Original Message ----- > VishwasM> From: "Manral, Vishwas" > VishwasM> To: > VishwasM> Sent: Friday, July 26, 2002 10:48 AM > VishwasM> Subject: Re: Link Flap Damping > VishwasM> > VishwasM> > VishwasM> || > than in OSPF. > VishwasM> | I agree here. Infact check the mail I sent to the list some time back. > VishwasM> | > VishwasM> http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0108&L=OSPF&P=R7962&I > VishwasM> = > VishwasM> | -3 where I agree to what you have said, link flap is best dealt with the > VishwasM> | lower layer, the closer to hardware the better. > VishwasM> | > VishwasM> | > 2. The OSPF specified MinLSInterval is 5 seconds (RFC 2328, appendix > VishwasM> B). > VishwasM> | This > VishwasM> | > is already quite a long time and I don't think further dampening > VishwasM> is > VishwasM> | required. > VishwasM> | There is a difference here. MinLSInterval does prevent the same LSA from > VishwasM> | being originated too soon. However this does not prevent the entire > VishwasM> | adjacencies to have to be reformed/broken. Damping the flap can prevent > VishwasM> us > VishwasM> | from doing this(in case the thing is not done at a lower layer). > VishwasM> | > VishwasM> | > 3. OSPF is an IGP and, as such, an OSPF instance should span a single > VishwasM> | routing > VishwasM> | > domain under a single administrative authority. Hence, it should > VishwasM> be > VishwasM> | possible > VishwasM> | > to address and remedy link flapping issues. > VishwasM> | Agreed !!! > VishwasM> | > VishwasM> | > 4. I haven't heard a requirement for such a feature from a network > VishwasM> | operator > VishwasM> | > (public or enterprise). Has anyone? > VishwasM> | Not exactly, but I guess the study by Cengiz and Steve on faster > VishwasM> convergence > VishwasM> | does talk about advantages of asymmetricaly damping Up/Down events, where > VishwasM> | and how it is done I guess is left to the implementor. This was presented > VishwasM> at > VishwasM> | one of the recent NANOG meetings. The study was done on the Qwest > VishwasM> backbone. > VishwasM> | > VishwasM> | In our draft(with the AT&T folks) we did find this feature useful in case > VishwasM> of > VishwasM> | congestion/scalability conditions too. Infact I guess Nokia also did a > VishwasM> study > VishwasM> | on this and came with similar results. > VishwasM> | > VishwasM> | Thanks, > VishwasM> | Vishwas > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon Jul 29 00:36: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 AAA08769 for ; Mon, 29 Jul 2002 00:36:54 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.006AE5DC@cherry.ease.lsoft.com>; Mon, 29 Jul 2002 0:37:58 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 144737 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 29 Jul 2002 00:37:58 -0400 Received: from 203.254.224.24 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 29 Jul 2002 00:37:58 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) id <0GZZ00B01UBBZY@mailout1.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Mon, 29 Jul 2002 13:40:23 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GZZ00B8LUBAKG@mailout1.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Mon, 29 Jul 2002 13:40:23 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0GZZ00IDRUBIBF@mmp2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Mon, 29 Jul 2002 13:40:33 +0900 (KST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Message-ID: <00bc01c236b9$16279e20$b4036c6b@sisodomain.com> Date: Mon, 29 Jul 2002 10:03:26 +0530 Reply-To: Mailing List Sender: Mailing List From: Manav Bhatia Subject: Re: Link Flap Damping Comments: To: vishwasM@netplane.com To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7BIT Hi Vishwas, Implementing link damping feature at L2 will work only if both the ends of the link do that. I explained a problem with only one end doing that in one of my previous mails on the list. There is no backward compatibility and all the routers would have to be upgraded simultaneously to let peace reign inside your routing domain. This can be avoided if link flap damping is correctly and smartly implemented in L3 wherein it can be negotiated while exchanging the HELLOs with the adjacent router. Even if both ends don't do that, the side implementing flap damping can atleast inform the sys admin as to why the adjacency is not coming up with the router at the other end and the additional time it will take for the adjacency to come provided the link remains sane till then. Secondly, in my opinion we must penalize a link more if it flaps severely or more often than a link which flaps lesser number of times and less vigorously. Using the WTR we don't differentiate between the two cases since both of them are advertised if they remain stable for some time period which is specified in the WTR. And there seems to be no way of doing that since there is no concept of history being maintained with the individual links. Also if L2 flap damping is good enough then why at all do we need to do that in BGP? We must understand that informing BGP of the correct next hop (usually redistributed from the IGPs) is very essential and of utmost importance as a single change in the IGP next hop can cause a next hop change in many thousands of BGP routes resulting in massive flaps causing penalties in forms of money to the provider, besides bringing a lot of instability to the network. Moreover it can be put as a generic feature which can work well for both links flapping and routes redistributed from outside OSPF domain flapping. I strongly believe that such a feature is best suited at L3! Regards, Manav ----- Original Message ----- From: "Manral, Vishwas" To: Sent: Saturday, July 27, 2002 7:03 PM Subject: Re: Link Flap Damping | Hi Yasu, | | If both ends of a link do have a link damping feature what problem would it | still not solve. The hellos would not be causing any flap if the lower layer | itself has taken care that the flap, because it would not convey a link up | event till the link showed no failure for some time(as in RPR example | below). | | Yes, for congestion case something may be required. We have put that down in | our draft congestion-control draft. | | Thanks, | Vishwas | | -----Original Message----- | From: Yasuhiro Ohara [mailto:yasu@SFC.WIDE.AD.JP] | Sent: Saturday, July 27, 2002 5:34 PM | To: OSPF@DISCUSS.MICROSOFT.COM | Subject: Re: Link Flap Damping | | | All, | | The L2's link flap dampen feature is not enough, since L3 (i.e. OSPF) | uses its own method to detect link flap. Even if the L2 do not trigger | up/down events to OSPF process, there will still be a case where a | OSPF process detects link flaps by Hello. | | If one want to say "L2 flap dampening feature is enough to prevent | OSPF to flap", we have to remove Hello. This is obviously not what we | want. | | regards. | yasu | | VishwasM> Hi Manav, | VishwasM> | VishwasM> Though I do not remember the details(and things have changed a lot | there), | VishwasM> in RPR(802.17) there is something called a "Wait To Restore"(WTR) | timer. A | VishwasM> failed link is required to show no failure for the given period of | time | VishwasM> before being declared working. | VishwasM> | VishwasM> Thanks, | VishwasM> Vishwas | VishwasM> | VishwasM> -----Original Message----- | VishwasM> From: Manav Bhatia [mailto:manav@SAMSUNG.COM] | VishwasM> Sent: Friday, July 26, 2002 12:12 PM | VishwasM> To: OSPF@DISCUSS.MICROSOFT.COM | VishwasM> Subject: Re: Link Flap Damping | VishwasM> | VishwasM> | VishwasM> Hi Vishwas, | VishwasM> Are you aware of any vendor implementing link flap damping in the | hardware? | VishwasM> | VishwasM> If there are such implementations out there and it is not a | standard then | VishwasM> cant it create problems out there in the wild when you can snoop | HELLOs | VishwasM> coming from the other end but find them not being delivered to | your OSPF | VishwasM> instance because of which the adjacency never comes up? | VishwasM> | VishwasM> Infact understanding the fact that those HELLOs are not being | delivered to | VishwasM> your local OSPF daemon will itself take up some time !!! | VishwasM> | VishwasM> Regards, | VishwasM> Manav | VishwasM> ----- Original Message ----- | VishwasM> From: "Manral, Vishwas" | VishwasM> To: | VishwasM> Sent: Friday, July 26, 2002 10:48 AM | VishwasM> Subject: Re: Link Flap Damping | VishwasM> | VishwasM> | VishwasM> || > than in OSPF. | VishwasM> | I agree here. Infact check the mail I sent to the list some time | back. | VishwasM> | | VishwasM> | http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0108&L=OSPF&P=R7962&I | VishwasM> = | VishwasM> | -3 where I agree to what you have said, link flap is best dealt | with the | VishwasM> | lower layer, the closer to hardware the better. | VishwasM> | | VishwasM> | > 2. The OSPF specified MinLSInterval is 5 seconds (RFC 2328, | appendix | VishwasM> B). | VishwasM> | This | VishwasM> | > is already quite a long time and I don't think further | dampening | VishwasM> is | VishwasM> | required. | VishwasM> | There is a difference here. MinLSInterval does prevent the same | LSA from | VishwasM> | being originated too soon. However this does not prevent the | entire | VishwasM> | adjacencies to have to be reformed/broken. Damping the flap can | prevent | VishwasM> us | VishwasM> | from doing this(in case the thing is not done at a lower layer). | VishwasM> | | VishwasM> | > 3. OSPF is an IGP and, as such, an OSPF instance should span | a single | VishwasM> | routing | VishwasM> | > domain under a single administrative authority. Hence, | it should | VishwasM> be | VishwasM> | possible | VishwasM> | > to address and remedy link flapping issues. | VishwasM> | Agreed !!! | VishwasM> | | VishwasM> | > 4. I haven't heard a requirement for such a feature from a | network | VishwasM> | operator | VishwasM> | > (public or enterprise). Has anyone? | VishwasM> | Not exactly, but I guess the study by Cengiz and Steve on faster | VishwasM> convergence | VishwasM> | does talk about advantages of asymmetricaly damping Up/Down | events, where | VishwasM> | and how it is done I guess is left to the implementor. This was | presented | VishwasM> at | VishwasM> | one of the recent NANOG meetings. The study was done on the | Qwest | VishwasM> backbone. | VishwasM> | | VishwasM> | In our draft(with the AT&T folks) we did find this feature | useful in case | VishwasM> of | VishwasM> | congestion/scalability conditions too. Infact I guess Nokia also | did a | VishwasM> study | VishwasM> | on this and came with similar results. | VishwasM> | | VishwasM> | Thanks, | VishwasM> | Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Mon Jul 29 01:13: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 BAA09178 for ; Mon, 29 Jul 2002 01:13:28 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.006AE4E2@cherry.ease.lsoft.com>; Mon, 29 Jul 2002 1:14:34 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 144854 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 29 Jul 2002 01:14:34 -0400 Received: from 203.254.224.24 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 29 Jul 2002 01:14:33 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) id <0GZZ00D01W0BDX@mailout1.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Mon, 29 Jul 2002 14:16:59 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GZZ00D2BW0AAL@mailout1.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Mon, 29 Jul 2002 14:16:59 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0GZZ00JATW0JC8@mmp2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Mon, 29 Jul 2002 14:17:09 +0900 (KST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Message-ID: <013601c236be$3324a180$b4036c6b@sisodomain.com> Date: Mon, 29 Jul 2002 10:40:02 +0530 Reply-To: Mailing List Sender: Mailing List From: Manav Bhatia Subject: Re: Link Flap Damping Comments: To: vishwasM@netplane.com To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7BIT Hi Vishwas, When the light goes out on the SONET link then it can be easily detected by the hardware and we can thus comfortably debounce/hold down this event in or close to the hardware to reduce churn in the upper layers. The problem comes with the Ethernet technologies deployed so vastly in the POPs where the above is somewhat difficult since as of now there are no data link layer signaling protocols (none that i am aware of !) which can inform us cleanly that we cant talk to our other neighbor. If a wire falls out of my router then we can come to know of it immediately but if it happens to fall out of the other end's router then there is no way that i can come to know of it. Eventually the software detection (aka HELLOs) has to be used. There is no way that this can be obviated given the ubiquitous presence of Ethernets all around us. We thus ultimately need some sort of flap damping mechanism at the software layer aka L3. Regards, Manav ----- Original Message ----- From: "Manral, Vishwas" To: Sent: Saturday, July 27, 2002 3:44 PM Subject: Re: Link Flap Damping | Hi Manav, | | Though I do not remember the details(and things have changed a lot there), | in RPR(802.17) there is something called a "Wait To Restore"(WTR) timer. A | failed link is required to show no failure for the given period of time | before being declared working. | | Thanks, | Vishwas | | -----Original Message----- | From: Manav Bhatia [mailto:manav@SAMSUNG.COM] | Sent: Friday, July 26, 2002 12:12 PM | To: OSPF@DISCUSS.MICROSOFT.COM | Subject: Re: Link Flap Damping | | | Hi Vishwas, | Are you aware of any vendor implementing link flap damping in the hardware? | | If there are such implementations out there and it is not a standard then | cant it create problems out there in the wild when you can snoop HELLOs | coming from the other end but find them not being delivered to your OSPF | instance because of which the adjacency never comes up? | | Infact understanding the fact that those HELLOs are not being delivered to | your local OSPF daemon will itself take up some time !!! | | Regards, | Manav | ----- Original Message ----- | From: "Manral, Vishwas" | To: | Sent: Friday, July 26, 2002 10:48 AM | Subject: Re: Link Flap Damping | | | || > than in OSPF. | | I agree here. Infact check the mail I sent to the list some time back. | | | http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0108&L=OSPF&P=R7962&I | = | | -3 where I agree to what you have said, link flap is best dealt with the | | lower layer, the closer to hardware the better. | | | | > 2. The OSPF specified MinLSInterval is 5 seconds (RFC 2328, appendix | B). | | This | | > is already quite a long time and I don't think further dampening | is | | required. | | There is a difference here. MinLSInterval does prevent the same LSA from | | being originated too soon. However this does not prevent the entire | | adjacencies to have to be reformed/broken. Damping the flap can prevent | us | | from doing this(in case the thing is not done at a lower layer). | | | | > 3. OSPF is an IGP and, as such, an OSPF instance should span a single | | routing | | > domain under a single administrative authority. Hence, it should | be | | possible | | > to address and remedy link flapping issues. | | Agreed !!! | | | | > 4. I haven't heard a requirement for such a feature from a network | | operator | | > (public or enterprise). Has anyone? | | Not exactly, but I guess the study by Cengiz and Steve on faster | convergence | | does talk about advantages of asymmetricaly damping Up/Down events, where | | and how it is done I guess is left to the implementor. This was presented | at | | one of the recent NANOG meetings. The study was done on the Qwest | backbone. | | | | In our draft(with the AT&T folks) we did find this feature useful in case | of | | congestion/scalability conditions too. Infact I guess Nokia also did a | study | | on this and came with similar results. | | | | Thanks, | | Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Mon Jul 29 05:09:50 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 FAA21505 for ; Mon, 29 Jul 2002 05:09:49 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.006AE712@cherry.ease.lsoft.com>; Mon, 29 Jul 2002 5:10:52 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 145309 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 29 Jul 2002 05:10:52 -0400 Received: from 66.218.78.85 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 29 Jul 2002 05:10:52 -0400 Received: from [203.200.20.226] by web40306.mail.yahoo.com via HTTP; Mon, 29 Jul 2002 02:10:51 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20020729091051.51847.qmail@web40306.mail.yahoo.com> Date: Mon, 29 Jul 2002 02:10:51 -0700 Reply-To: Mailing List Sender: Mailing List From: Amit Srivastava Subject: Virtual Link To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Hi All, We know that vitual link are basically for the back bone connectivety. Now consider a scenirie where we have R1 connected to area 1 , area 2 ,area 3 and R2 connected to area 2 and area 4 now if i want to configure a virtual link between R1 and R2 what should be the LSAs flowing over the virtual link.(As there in no back bone connectivety) Regards Amit __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Mon Jul 29 05:36: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 FAA21812 for ; Mon, 29 Jul 2002 05:36:25 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.006AE7E2@cherry.ease.lsoft.com>; Mon, 29 Jul 2002 5:37:30 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 145366 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 29 Jul 2002 05:37:30 -0400 Received: from 144.254.15.119 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 29 Jul 2002 05:37:30 -0400 Received: from cisco.com (dhcp-bru-peg1-vl18-144-254-2-59.cisco.com [144.254.2.59]) by strange-brew.cisco.com (8.11.6+Sun/8.8.8) with ESMTP id g6T9bT716633; Mon, 29 Jul 2002 11:37:29 +0200 (CEST) X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <3D417DA0.5050404@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3D450CD8.C6D86FA@cisco.com> Date: Mon, 29 Jul 2002 11:37:28 +0200 Reply-To: Mailing List Sender: Mailing List From: Peter Psenak Subject: Re: Comments on OSPF PC/CE Drafts Comments: cc: erosen@cisco.com To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Acee, please see inline: Acee Lindem wrote: > > I posted this on the PPVPN list. I'm posting here as well since some > of you may not be aware of these drafts.... > > Here are my comments on draft-rosen-vpns-ospf-bgp-mpls-04.txt and > draft-rosen-ppvpn-ospf2547-area0-00.txt: > > General: > > - It would seem that these two drafts could be combined since > draft-rosen-ppvpn-ospf2547-area0-00.txt only contains a couple > paragraphs of unique information. This would also avoid all > references in draft-rosen-vpns-ospf-bgp-mpls-04.txt > > - The PE router doesn't really have to be an ABR. It is already "faking" > that VPN redistributed routes are inter-area routes. It can also > set its router LSA B bit accordingly. Oh well, maybe this could be > considered an implementation detail. right, it does not need to be an ABR (being attached to multiple areas) it should present itself as an ABR, so it can generate Type-3 LSAs. > > draft-rosen-vpns-ospf-bgp-mpls-04.txt: > > - Page 4, second list item. Since the VPN routes are advertised as type > 3 LSAs, I believe you should say "inter-area routes" rather than > "intra-network routes". agree, will be changed. > > - Page 6, Again - A PE router doesn't necessarily have to be an area 0 > router. It just has to present itself as a border router advertise type 3 > LSAs. agree, will be changed. > > - Page 11 - This states that the sham link endpoint "must be advertised > as VPN-IPv4 address and it may be distributed by OSPF". The extant > implementation does not advertise the sham endpoint as an OSPF VPN > route (one must redistribute the connected route corresponding > to the loopback address of the sham link endpoint). Advertising > the sham link endpoint as an OSPF route is only needed for > auto-configuration (unless I'm missing something). I guess the original idea was that the sham-link control traffic can be routed over the OSPF 'backdoor' area instead of the VPN backbone if there is a reason to do it that way. Usually the sham-link control traffic is routed over the VPN backbone. > > - Page 11 - Why is auto-configuration a "MUST"? It seems to me that the use > of sham-links will be limited and the use of a full mesh of sham links will > be even rarer. agree, autoconfiguration should be optional. > > - Page 12 - State the default hello and dead time for the sham link. Experience > has shown that the existing implementation uses 10 and 40 but this is non-obvious > due to the fact that an OSPF virtual link defaults to 40 and 120. we will add that. We chose the same defaults as used for any p2p link. Sham-link should be operating as a DC, so no Hellos should be sent after the adjacency is formed. > > - Page 12, last paragraph - Don't you mean that the PE should not install the route > into the VRF routing table (since there should already be a BGP route). This will > insure it doesn't replace the route and that it is not redistributed. PE will install the OSPF route over the sham-link. It will show in the RT as an OSPF route. As this route came from the remote PE and an equivalent route was advertised as an BGP prefix on the remote PE, receiving PE should not redistribute the route back to BGP. > > - Page 13 - I believe the bulleted conditions could be greatly simplified. > > - the VRF has a non-zero OSPF Domain Identifier, but the route does > not have a non-zero OSPF Domain Identifier Extended Communities > attribute, or > > ((VRF-Domain-ID != 0) && !(Route-Domain-ID != 0)) || > > - the route has an OSPF Domain Identifier Extended Communities > attribute whose value is not the same as the OSPF Domain > Identifier associated with the VRF > > (Route-Domain-ID != VRF-Domain-ID) > > Isn't the first condition unnecessary since it is a subset of the second? right, I guess this was added for clarity. There has been some changes in the Domain-ID part recently and this will be reflected in the next version of the draft. thanks, Peter > > draft-rosen-ppvpn-ospf2547-area0-00.txt > > No additional comments. > > That's all for now... > > Thanks, > --- > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon Jul 29 06:54: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 GAA23469 for ; Mon, 29 Jul 2002 06:54:39 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.006AEA3F@cherry.ease.lsoft.com>; Mon, 29 Jul 2002 6:55:44 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 145805 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 29 Jul 2002 06:55:44 -0400 Received: from 64.4.14.175 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 29 Jul 2002 06:55:44 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 29 Jul 2002 03:55:43 -0700 Received: from 203.196.146.243 by lw10fd.law10.hotmail.msn.com with HTTP; Mon, 29 Jul 2002 10:55:43 GMT X-Originating-IP: [203.196.146.243] Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 29 Jul 2002 10:55:43.0738 (UTC) FILETIME=[7C6C3DA0:01C236EE] Message-ID: Date: Mon, 29 Jul 2002 10:55:43 +0000 Reply-To: Mailing List Sender: Mailing List From: praveendas e Subject: Re: Virtual Link To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hai Amit We know that vitual link are basically for the back bone connectivety. Now consider a scenirie where we have R1 connected to area 1 , area 2 ,area 3 and R2 connected to area 2 and area 4 now if i want to configure a virtual link between R1 and R2 what should be the LSAs flowing over the virtual link.(As there in no back bone connectivety) Regards Amit Your Scenario is looking like both routers are in disconnected area.If the routers are residing in non backbone area it is impossible to have a virtual link other than chainning of virtual link.For that you have to create a virtual link b/w R1 or R2 to the router in the backbone. About the LSA's passing through this link is ,it will send all LSA's other than External LSA's passing through the backbone. Hope this help you .... Rgds Praveendas >From: Amit Srivastava >Reply-To: Mailing List >To: OSPF@DISCUSS.MICROSOFT.COM >Subject: Virtual Link >Date: Mon, 29 Jul 2002 02:10:51 -0700 > >Hi All, > We know that vitual link are basically for the >back bone connectivety. Now consider a scenirie where >we have R1 connected to area 1 , area 2 ,area 3 and R2 >connected to area 2 and area 4 now if i want to >configure a virtual link between R1 and R2 what should >be the LSAs flowing over the virtual link.(As there in >no back bone connectivety) >Regards >Amit > >__________________________________________________ >Do You Yahoo!? >Yahoo! Health - Feel better, live better >http://health.yahoo.com _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From owner-ospf@DISCUSS.MICROSOFT.COM Mon Jul 29 07:03: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 HAA23674 for ; Mon, 29 Jul 2002 07:03:13 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.006AEA86@cherry.ease.lsoft.com>; Mon, 29 Jul 2002 7:04:16 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 145849 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 29 Jul 2002 07:04:16 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 29 Jul 2002 07:04:16 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Mon, 29 Jul 2002 07:04:08 -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, 29 Jul 2002 07:06:44 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Link Flap Damping To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Manav, First, some good news. ;-) I hear IEEE is working on failure notification for Ethernet. As I see link flap damping, it has nothing to do with the other end but our own interface. So when we know that we are consistently flapping, we can have some way to prevent it. I guess all that you say, does not come into the picture at all in that case. In OSPF because we have a 3-way handshake hello mechanism, the link would not come up, and be used for routing table calculation, if either end damped it. We can, for precaution sake do flap damping at OSPF layer. Ways to do it could be: - http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0108&L=OSPF&P=R7962&I= -3 and we could actually advertize the link metric with value 0xffff for such links. So in case there is no other path to a destination the link can still be used. We could probably have more opinions on this. Alex/John ?? Thanks, Vishwas -----Original Message----- From: Manav Bhatia [mailto:manav@SAMSUNG.COM] Sent: Monday, July 29, 2002 10:40 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Link Flap Damping Hi Vishwas, When the light goes out on the SONET link then it can be easily detected by the hardware and we can thus comfortably debounce/hold down this event in or close to the hardware to reduce churn in the upper layers. The problem comes with the Ethernet technologies deployed so vastly in the POPs where the above is somewhat difficult since as of now there are no data link layer signaling protocols (none that i am aware of !) which can inform us cleanly that we cant talk to our other neighbor. If a wire falls out of my router then we can come to know of it immediately but if it happens to fall out of the other end's router then there is no way that i can come to know of it. Eventually the software detection (aka HELLOs) has to be used. There is no way that this can be obviated given the ubiquitous presence of Ethernets all around us. We thus ultimately need some sort of flap damping mechanism at the software layer aka L3. Regards, Manav ----- Original Message ----- From: "Manral, Vishwas" To: Sent: Saturday, July 27, 2002 3:44 PM Subject: Re: Link Flap Damping | Hi Manav, | | Though I do not remember the details(and things have changed a lot there), | in RPR(802.17) there is something called a "Wait To Restore"(WTR) timer. A | failed link is required to show no failure for the given period of time | before being declared working. | | Thanks, | Vishwas | | -----Original Message----- | From: Manav Bhatia [mailto:manav@SAMSUNG.COM] | Sent: Friday, July 26, 2002 12:12 PM | To: OSPF@DISCUSS.MICROSOFT.COM | Subject: Re: Link Flap Damping | | | Hi Vishwas, | Are you aware of any vendor implementing link flap damping in the hardware? | | If there are such implementations out there and it is not a standard then | cant it create problems out there in the wild when you can snoop HELLOs | coming from the other end but find them not being delivered to your OSPF | instance because of which the adjacency never comes up? | | Infact understanding the fact that those HELLOs are not being delivered to | your local OSPF daemon will itself take up some time !!! | | Regards, | Manav | ----- Original Message ----- | From: "Manral, Vishwas" | To: | Sent: Friday, July 26, 2002 10:48 AM | Subject: Re: Link Flap Damping | | | || > than in OSPF. | | I agree here. Infact check the mail I sent to the list some time back. | | | http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0108&L=OSPF&P=R7962&I | = | | -3 where I agree to what you have said, link flap is best dealt with the | | lower layer, the closer to hardware the better. | | | | > 2. The OSPF specified MinLSInterval is 5 seconds (RFC 2328, appendix | B). | | This | | > is already quite a long time and I don't think further dampening | is | | required. | | There is a difference here. MinLSInterval does prevent the same LSA from | | being originated too soon. However this does not prevent the entire | | adjacencies to have to be reformed/broken. Damping the flap can prevent | us | | from doing this(in case the thing is not done at a lower layer). | | | | > 3. OSPF is an IGP and, as such, an OSPF instance should span a single | | routing | | > domain under a single administrative authority. Hence, it should | be | | possible | | > to address and remedy link flapping issues. | | Agreed !!! | | | | > 4. I haven't heard a requirement for such a feature from a network | | operator | | > (public or enterprise). Has anyone? | | Not exactly, but I guess the study by Cengiz and Steve on faster | convergence | | does talk about advantages of asymmetricaly damping Up/Down events, where | | and how it is done I guess is left to the implementor. This was presented | at | | one of the recent NANOG meetings. The study was done on the Qwest | backbone. | | | | In our draft(with the AT&T folks) we did find this feature useful in case | of | | congestion/scalability conditions too. Infact I guess Nokia also did a | study | | on this and came with similar results. | | | | Thanks, | | Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Mon Jul 29 08:50: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 IAA27461 for ; Mon, 29 Jul 2002 08:50:51 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.006AEBE5@cherry.ease.lsoft.com>; Mon, 29 Jul 2002 8:51:56 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 146105 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 29 Jul 2002 08:51:55 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 29 Jul 2002 08:51:55 -0400 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 2D07E4483FE for ; Mon, 29 Jul 2002 05:51:53 -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: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D453A27.9070001@redback.com> Date: Mon, 29 Jul 2002 08:50:47 -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 Amit, Praveendas is right. You'd need to configure a backbone area on R1 and R2 with a virtual link using area 2 (the common area) as a transit area. Thanks, Acee praveendas e wrote: > Hai Amit > > We know that vitual link are basically for the > back bone connectivety. Now consider a scenirie where > we have R1 connected to area 1 , area 2 ,area 3 and R2 > connected to area 2 and area 4 now if i want to > configure a virtual link between R1 and R2 what should > be the LSAs flowing over the virtual link.(As there in > no back bone connectivety) > Regards > Amit > > Your Scenario is looking like both routers are in disconnected area.If the > routers are residing in non backbone area it is impossible to have a > virtual > link other than chainning of virtual link.For that you have to create a > virtual link b/w R1 or R2 to the router in the backbone. > > About the LSA's passing through this link is ,it will send all LSA's > other than External LSA's passing through the backbone. > Hope this help you .... > Rgds > Praveendas > >> From: Amit Srivastava >> Reply-To: Mailing List >> To: OSPF@DISCUSS.MICROSOFT.COM >> Subject: Virtual Link >> Date: Mon, 29 Jul 2002 02:10:51 -0700 >> >> Hi All, >> We know that vitual link are basically for the >> back bone connectivety. Now consider a scenirie where >> we have R1 connected to area 1 , area 2 ,area 3 and R2 >> connected to area 2 and area 4 now if i want to >> configure a virtual link between R1 and R2 what should >> be the LSAs flowing over the virtual link.(As there in >> no back bone connectivety) >> Regards >> Amit >> >> __________________________________________________ >> Do You Yahoo!? >> Yahoo! Health - Feel better, live better >> http://health.yahoo.com > > > > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon Jul 29 09:18: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 JAA28444 for ; Mon, 29 Jul 2002 09:18:29 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.006AEB7F@cherry.ease.lsoft.com>; Mon, 29 Jul 2002 9:19:35 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 146173 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 29 Jul 2002 09:19:35 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 29 Jul 2002 09:19:35 -0400 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 1CD4C4483FD for ; Mon, 29 Jul 2002 06:19:34 -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: <3D417DA0.5050404@redback.com> <3D450CD8.C6D86FA@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D4540A3.8090009@redback.com> Date: Mon, 29 Jul 2002 09:18:27 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Comments on OSPF PC/CE Drafts To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Peter, I'm happy. Thanks much, Acee Peter Psenak wrote: > Acee, > > please see inline: > > Acee Lindem wrote: > >>I posted this on the PPVPN list. I'm posting here as well since some >>of you may not be aware of these drafts.... >> >>Here are my comments on draft-rosen-vpns-ospf-bgp-mpls-04.txt and >>draft-rosen-ppvpn-ospf2547-area0-00.txt: >> >>General: >> >> - It would seem that these two drafts could be combined since >> draft-rosen-ppvpn-ospf2547-area0-00.txt only contains a couple >> paragraphs of unique information. This would also avoid all >> references in draft-rosen-vpns-ospf-bgp-mpls-04.txt >> >> - The PE router doesn't really have to be an ABR. It is already "faking" >> that VPN redistributed routes are inter-area routes. It can also >> set its router LSA B bit accordingly. Oh well, maybe this could be >> considered an implementation detail. >> > > right, it does not need to be an ABR (being attached to multiple areas) > it should present itself as an ABR, so it can generate Type-3 LSAs. > > >>draft-rosen-vpns-ospf-bgp-mpls-04.txt: >> >> - Page 4, second list item. Since the VPN routes are advertised as type >> 3 LSAs, I believe you should say "inter-area routes" rather than >> "intra-network routes". >> > > agree, will be changed. > > >> - Page 6, Again - A PE router doesn't necessarily have to be an area 0 >> router. It just has to present itself as a border router advertise type 3 >> LSAs. >> > > agree, will be changed. > > >> - Page 11 - This states that the sham link endpoint "must be advertised >> as VPN-IPv4 address and it may be distributed by OSPF". The extant >> implementation does not advertise the sham endpoint as an OSPF VPN >> route (one must redistribute the connected route corresponding >> to the loopback address of the sham link endpoint). Advertising >> the sham link endpoint as an OSPF route is only needed for >> auto-configuration (unless I'm missing something). >> > > I guess the original idea was that the sham-link control traffic can be > routed over the OSPF 'backdoor' area instead of the VPN backbone if > there is a reason to do it that way. Usually the sham-link control > traffic is routed over the VPN backbone. > > >> - Page 11 - Why is auto-configuration a "MUST"? It seems to me that the use >> of sham-links will be limited and the use of a full mesh of sham links will >> be even rarer. >> > > agree, autoconfiguration should be optional. > > >> - Page 12 - State the default hello and dead time for the sham link. Experience >> has shown that the existing implementation uses 10 and 40 but this is non-obvious >> due to the fact that an OSPF virtual link defaults to 40 and 120. >> > > we will add that. We chose the same defaults as used for any p2p link. > Sham-link should be operating as a DC, so no Hellos should be sent after > the adjacency is formed. > > >> - Page 12, last paragraph - Don't you mean that the PE should not install the route >> into the VRF routing table (since there should already be a BGP route). This will >> insure it doesn't replace the route and that it is not redistributed. >> > > PE will install the OSPF route over the sham-link. It will show in the > RT as an OSPF route. As this route came from the remote PE and an > equivalent route was advertised as an BGP prefix on the remote PE, > receiving PE should not redistribute the route back to BGP. > > >> - Page 13 - I believe the bulleted conditions could be greatly simplified. >> >> - the VRF has a non-zero OSPF Domain Identifier, but the route does >> not have a non-zero OSPF Domain Identifier Extended Communities >> attribute, or >> >> ((VRF-Domain-ID != 0) && !(Route-Domain-ID != 0)) || >> >> - the route has an OSPF Domain Identifier Extended Communities >> attribute whose value is not the same as the OSPF Domain >> Identifier associated with the VRF >> >> (Route-Domain-ID != VRF-Domain-ID) >> >> Isn't the first condition unnecessary since it is a subset of the second? >> > > right, I guess this was added for clarity. There has been some changes > in the Domain-ID part recently and this will be reflected in the next > version of the draft. > > thanks, > Peter > > >>draft-rosen-ppvpn-ospf2547-area0-00.txt >> >> No additional comments. >> >>That's all for now... >> >>Thanks, >>--- >>Acee >> > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon Jul 29 09:57: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 JAA00213 for ; Mon, 29 Jul 2002 09:57:45 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.006AEBF3@cherry.ease.lsoft.com>; Mon, 29 Jul 2002 9:58:51 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 146273 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 29 Jul 2002 09:58:50 -0400 Received: from 66.218.78.82 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 29 Jul 2002 09:58:50 -0400 Received: from [203.200.20.226] by web40303.mail.yahoo.com via HTTP; Mon, 29 Jul 2002 06:58:49 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20020729135849.78314.qmail@web40303.mail.yahoo.com> Date: Mon, 29 Jul 2002 06:58:49 -0700 Reply-To: Mailing List Sender: Mailing List From: Amit Srivastava Subject: Re: Virtual Link To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Hi Praveendas, I think only the backbone traffice can flow over the virtual link.I just wanted to simulate the sinario where my router R1 is configured to backbone after the virtual link is configured between R1 and R2. Regards Amit --- praveendas e wrote: > Hai Amit > > We know that vitual link are basically for the > back bone connectivety. Now consider a scenirie > where > we have R1 connected to area 1 , area 2 ,area 3 and > R2 > connected to area 2 and area 4 now if i want to > configure a virtual link between R1 and R2 what > should > be the LSAs flowing over the virtual link.(As there > in > no back bone connectivety) > Regards > Amit > > Your Scenario is looking like both routers are in > disconnected area.If the > routers are residing in non backbone area it is > impossible to have a virtual > link other than chainning of virtual link.For that > you have to create a > virtual link b/w R1 or R2 to the router in the > backbone. > > About the LSA's passing through this link is ,it > will send all LSA's > other than External LSA's passing through the > backbone. > Hope this help you .... > Rgds > Praveendas > > >From: Amit Srivastava > >Reply-To: Mailing List > >To: OSPF@DISCUSS.MICROSOFT.COM > >Subject: Virtual Link > >Date: Mon, 29 Jul 2002 02:10:51 -0700 > > > >Hi All, > > We know that vitual link are basically for the > >back bone connectivety. Now consider a scenirie > where > >we have R1 connected to area 1 , area 2 ,area 3 and > R2 > >connected to area 2 and area 4 now if i want to > >configure a virtual link between R1 and R2 what > should > >be the LSAs flowing over the virtual link.(As there > in > >no back bone connectivety) > >Regards > >Amit > > > >__________________________________________________ > >Do You Yahoo!? > >Yahoo! Health - Feel better, live better > >http://health.yahoo.com > > > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Mon Jul 29 14:56: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 OAA10986 for ; Mon, 29 Jul 2002 14:56:44 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.006AF641@cherry.ease.lsoft.com>; Mon, 29 Jul 2002 14:57:50 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 147409 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 29 Jul 2002 14:57:49 -0400 Received: from 63.236.75.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 29 Jul 2002 14:57:49 -0400 Received: by xmxpita.excite.com (Postfix, from userid 110) id E2AF7B6E6; Mon, 29 Jul 2002 14:57:45 -0400 (EDT) Received: from [63.104.212.252] by xprdmailfe15.nwk.excite.com via HTTP; Mon, 29 Jul 2002 14:57:45 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = b4f718530cf8af0dd8df25e0425ffee0 MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20020729185745.E2AF7B6E6@xmxpita.excite.com> Date: Mon, 29 Jul 2002 14:57:45 -0400 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: Virtual Link To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit My 2 cents... Nowhere is section 15 of RFC2328 does it state that either endpoint of the virtual link MUST be connected to the backbone area. Further, it does state that the purpose of a virtual-link is to establish/maintain backbone connectivity. In my mind, so long as each end-point is an ABR, the virtual-link should be brought up, and associated with area 0.0.0.0. In the case below, area 2 would then be used as the transit-area. Of course, depending on the OSPF implementation, the router may or may not become an ABR without area 0 being configured on at least one interface (usually a loopback). In this case, it's merely a matter of setting up the virtual-adjacency when the ABR bit toggle on and tearing it down when the bit is cleared (on either end). Have fun, Don --- On Mon 07/29, praveendas e wrote: From: praveendas e [mailto: e_praveendas@HOTMAIL.COM] To: OSPF@DISCUSS.MICROSOFT.COM Date: Mon, 29 Jul 2002 10:55:43 +0000 Subject: Re: Virtual Link > Hai Amit > > We know that vitual link are basically for the > back bone connectivety. Now consider a scenirie where > we have R1 connected to area 1 , area 2 ,area 3 and R2 > connected to area 2 and area 4 now if i want to > configure a virtual link between R1 and R2 what should > be the LSAs flowing over the virtual link.(As there in > no back bone connectivety) > Regards > Amit > > Your Scenario is looking like both routers are in disconnected area.If > the > routers are residing in non backbone area it is impossible to have a > virtual > link other than chainning of virtual link.For that you have to create a > virtual link b/w R1 or R2 to the router in the backbone. > > About the LSA's passing through this link is ,it will send all LSA's > other than External LSA's passing through the backbone. > Hope this help you .... > Rgds > Praveendas > > >From: Amit Srivastava > >Reply-To: Mailing List > >To: OSPF@DISCUSS.MICROSOFT.COM > >Subject: Virtual Link > >Date: Mon, 29 Jul 2002 02:10:51 -0700 > > > >Hi All, > > We know that vitual link are basically for the > >back bone connectivety. Now consider a scenirie where > >we have R1 connected to area 1 , area 2 ,area 3 and R2 > >connected to area 2 and area 4 now if i want to > >configure a virtual link between R1 and R2 what should > >be the LSAs flowing over the virtual link.(As there in > >no back bone connectivety) > >Regards > >Amit > > > >__________________________________________________ > >Do You Yahoo!? > >Yahoo! Health - Feel better, live better > >http://health.yahoo.com > > > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com > ------------------------------------------------ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ospf@DISCUSS.MICROSOFT.COM Mon Jul 29 15:56: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 PAA13012 for ; Mon, 29 Jul 2002 15:56:51 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.006AFA21@cherry.ease.lsoft.com>; Mon, 29 Jul 2002 15:57:58 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 147756 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 29 Jul 2002 15:57:58 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Mon, 29 Jul 2002 15:57:58 -0400 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id B5313F2C46 for ; Mon, 29 Jul 2002 12:57:56 -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: <20020729185745.E2AF7B6E6@xmxpita.excite.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D459DFF.2030005@redback.com> Date: Mon, 29 Jul 2002 15:56:47 -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 Don Goodspeed wrote: > My 2 cents... > > Nowhere is section 15 of RFC2328 does it state that either endpoint > of the virtual link MUST be connected to the backbone area. Further, > it does state that the purpose of a virtual-link is to establish/maintain > backbone connectivity. In my mind, so long as each end-point is an ABR, > the virtual-link should be brought up, and associated with area 0.0.0.0. > > In the case below, area 2 would then be used as the transit-area. > > Of course, depending on the OSPF implementation, the router may > or may not become an ABR without area 0 being configured on > at least one interface (usually a loopback). Don, The virtual link itself "counts" as an OSPF interface so any router with an active virtualy link is, by definition, connected to the backbone. Thanks, Acee > In this case, it's > merely a matter of setting up the virtual-adjacency when the > ABR bit toggle on and tearing it down when the bit is cleared > (on either end). > > Have fun, > Don > > --- On Mon 07/29, praveendas e wrote: > From: praveendas e [mailto: e_praveendas@HOTMAIL.COM] > To: OSPF@DISCUSS.MICROSOFT.COM > Date: Mon, 29 Jul 2002 10:55:43 +0000 > Subject: Re: Virtual Link > > >>Hai Amit >> >> We know that vitual link are basically for the >>back bone connectivety. Now consider a scenirie where >>we have R1 connected to area 1 , area 2 ,area 3 and R2 >>connected to area 2 and area 4 now if i want to >>configure a virtual link between R1 and R2 what should >>be the LSAs flowing over the virtual link.(As there in >>no back bone connectivety) >>Regards >>Amit >> >> Your Scenario is looking like both routers are in disconnected area.If >>the >>routers are residing in non backbone area it is impossible to have a >>virtual >>link other than chainning of virtual link.For that you have to create a >>virtual link b/w R1 or R2 to the router in the backbone. >> >> About the LSA's passing through this link is ,it will send all LSA's >>other than External LSA's passing through the backbone. >>Hope this help you .... >>Rgds >>Praveendas >> >> >>>From: Amit Srivastava >>>Reply-To: Mailing List >>>To: OSPF@DISCUSS.MICROSOFT.COM >>>Subject: Virtual Link >>>Date: Mon, 29 Jul 2002 02:10:51 -0700 >>> >>>Hi All, >>> We know that vitual link are basically for the >>>back bone connectivety. Now consider a scenirie where >>>we have R1 connected to area 1 , area 2 ,area 3 and R2 >>>connected to area 2 and area 4 now if i want to >>>configure a virtual link between R1 and R2 what should >>>be the LSAs flowing over the virtual link.(As there in >>>no back bone connectivety) >>>Regards >>>Amit >>> >>>__________________________________________________ >>>Do You Yahoo!? >>>Yahoo! Health - Feel better, live better >>>http://health.yahoo.com >>> >> >> >> >>_________________________________________________________________ >>Chat with friends online, try MSN Messenger: http://messenger.msn.com >> >> > > ------------------------------------------------ > Join Excite! - http://www.excite.com > The most personalized portal on the Web! > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jul 30 00:01: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 AAA24873 for ; Tue, 30 Jul 2002 00:01:07 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.006B0A46@cherry.ease.lsoft.com>; Tue, 30 Jul 2002 0:02:08 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 149102 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 30 Jul 2002 00:02:07 -0400 Received: from 203.178.142.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 30 Jul 2002 00:01:12 -0400 Received: from localhost (page.sfc.wide.ad.jp [203.178.143.89]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id E65995D01E; Tue, 30 Jul 2002 13:01:10 +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: <20020730.125317.27309274.yasu@sfc.wide.ad.jp> Date: Tue, 30 Jul 2002 12:53:17 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: Link Flap Damping Comments: To: VishwasM@NETPLANE.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3D42DC40.ED8D4D88@earthlink.net> <3D430EDD.2000302@redback.com> <00bc01c236b9$16279e20$b4036c6b@sisodomain.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Manral, Erblichs, Acee: Forgive me to reply by this all-in-one message for some of previous e-mails. First, I have some prerequisions about this discussion. I guess we all want to decrease Hello-Interval and Dead-Interval to make convergence more faster, is this right ? I don't think Hello-Interval should be 10 seconds because that's too long. And I am so impatient that I cannot wait for 40 seconds for my communication being revived each time the network topology changes. If we keep this in mind things may be changed bellow. VishwasM> Hi Yasu, VishwasM> VishwasM> If both ends of a link do have a link damping feature what VishwasM> problem would it still not solve. The hellos would not be VishwasM> causing any flap if the lower layer itself has taken care VishwasM> that the flap, because it would not convey a link up event VishwasM> till the link showed no failure for some time(as in RPR VishwasM> example below). What would it be done with the Hellos going through the link which is down but kept from notifying the upper layer ? It is obviously not good for L2 switches to keep this traffic in its own buffer and re-send it. (I believe all of the L2 flap dampening technology won't do this.) So, hellos may be dropped anyway whether L2 dampening feature is on or not (off). VishwasM> Yes, for congestion case something may be required. We have VishwasM> put that down in our draft congestion-control draft. Yes, I've read the draft and it'll be very effective where hello/dead are 10/40s (or similar). But none of this will solve the problem essentially. - Throttle setup of adjacency I guess prioritizing the adjacencies is the most bothering thing for network operators. The future world enforcing this to be involved is not attractive ... - DSCP marking of hello/ack This is for congestion and can do nothing with link down. - Use other control packets than hello as detect link live-ness This is also mainly for congestion I guess. Frequency of other control packets than hello is another critical issue for OSPF scalability and should be decreased. But in the other hand (ideally) the dead interval may not be so long to wait these kind of "OSPF update" to occur. Hence we should think we can use only the hellos to detect link flaps. # By the way, though the draft inform me a lot of valuable things, # I could not understand one part of it. 4.1.2's end paragraph says: # "Maintaining sequence number counters for different packet types # may solve this issue" but what is the sequence number and how a # implementation take care the packet reordering ? erblichs> Has anyone seen or invisioned an interaction with "link flap erblichs> dampening" and Moy's OSPF implimentation where he attempts erblichs> to accelerate bi-directional status? Chapt 1, p.2 1.1.1 erblichs> Optimizations erblichs> erblichs> Basicly, can a damped link on one side prevent this erblichs> acceleration to occur? erblichs> erblichs> And should this accelerated method bunch the load on a erblichs> router and thus counter-intuitive to congestion control? erblichs> Especially with a set of routers all coming up at the same erblichs> time and then the bunching of adjacency formations. Could you explain more detail about this ? I understood this as a feature to simply make the adjacency to come up faster, and nothing has to do with the flap dampening. acee> Normally, it is the link up event that is dampened at layer 2 acee> and it is normally done in a such a way that the OSPF hello acee> packets will not be received or will be dropped at a low level. OK, so I feel I can't admit L2's link flap dampening more and more. If the link up event is dropped and does not come up during the link physically flaps until someone take care of the link's problem, and if the link is the only one to reach a place (this is usual case), the place will be unreach very long time. I guess it's not acceptable. Today we implicitly dampen the flaps by keeping the hello/dead interval long (like 10/40s). The result of this dampened link while flaps is *UP*, realizing "Best effort" Internet policy because some packet may reach still through the flapping link. Are we really change this thing ? Can someone easily drop being unaware of how important the link's live-ness is, even partially ? VishwasM> Hi Manav, VishwasM> VishwasM> First, some good news. ;-) I hear IEEE is working on failure VishwasM> notification for Ethernet. VishwasM> VishwasM> As I see link flap damping, it has nothing to do with the VishwasM> other end but our own interface. So when we know that we are VishwasM> consistently flapping, we can have some way to prevent it. I VishwasM> guess all that you say, does not come into the picture at VishwasM> all in that case. VishwasM> VishwasM> In OSPF because we have a 3-way handshake hello mechanism, VishwasM> the link would not come up, and be used for routing table VishwasM> calculation, if either end damped it. No, I don't think so. In usual case below: [sw1]-[sw2]-[sw3] | | R1 R2 If L2 switch [sw2] or the link connected to it flaps, R1 and R2 would not be able to recognize the flaps even if there's some conversation about the link's (L2) information above [sw1], [sw2] and [sw3]. There are still possibilities of dropping Hellos. If the hello/dead intervals are so short, the frequency of OSPF calculation will be MinLSInterval (5sec). The network where the route changes each 5 secs are not acceptable. Yes, we have one major conflict in OSPF routing: "Converge fast but don't let a link flap". VishwasM> We can, for precaution sake do flap damping at OSPF VishwasM> layer. Ways to do it could be: - VishwasM> VishwasM> http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0108&L=OSPF&P=R7962&I=-3 VishwasM> VishwasM> and VishwasM> VishwasM> we could actually advertize the link metric with value VishwasM> 0xffff for such links. So in case there is no other path to VishwasM> a destination the link can still be used. That's very similar to what I am looking for ;p) But how did you recognize the flap ? All I want to know is this. How did you distinct the flap from the link completely down, when dead-interval have elapsed without receiving Hello ? How immediately could you recover the link's availability when the link's flaps vanished ? It is worth writing I-D for experimental/informational use, even though I admit it's an implementation issue. VishwasM> We could probably have more opinions on this. Alex/John ?? Really waiting for your reply. regards ! yasu From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jul 30 01:41: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 BAA26550 for ; Tue, 30 Jul 2002 01:41:00 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.006B0C4B@cherry.ease.lsoft.com>; Tue, 30 Jul 2002 1:42:05 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 149421 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 30 Jul 2002 01:42:05 -0400 Received: from 66.218.78.89 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 30 Jul 2002 01:42:05 -0400 Received: from [203.200.20.226] by web40310.mail.yahoo.com via HTTP; Mon, 29 Jul 2002 22:42:04 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20020730054204.7025.qmail@web40310.mail.yahoo.com> Date: Mon, 29 Jul 2002 22:42:04 -0700 Reply-To: Mailing List Sender: Mailing List From: Amit Srivastava Subject: Re: Virtual Link To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3D459DFF.2030005@redback.com> Precedence: list Hi All, I agree wih Don as we can have the virtual Link configured between two ABRs even though they are not connected to the backbone. It is also documented in the Alternative ABR implementation document by ietf. My doubt is that in this case the virtual Link will come up but will there be any traffic flowing over the virtual Link as i think only backbone traffice flows over the virtual Link. What do you Say Don and Acee Regards Amit --- Acee Lindem wrote: > Don Goodspeed wrote: > > > My 2 cents... > > > > Nowhere is section 15 of RFC2328 does it state > that either endpoint > > of the virtual link MUST be connected to the > backbone area. Further, > > it does state that the purpose of a virtual-link > is to establish/maintain > > backbone connectivity. In my mind, so long as > each end-point is an ABR, > > the virtual-link should be brought up, and > associated with area 0.0.0.0. > > > > In the case below, area 2 would then be used as > the transit-area. > > > > Of course, depending on the OSPF implementation, > the router may > > or may not become an ABR without area 0 being > configured on > > at least one interface (usually a loopback). > > > Don, > > The virtual link itself "counts" as an OSPF > interface so any router with > an active virtualy link is, by definition, connected > to the backbone. > > Thanks, > Acee > > > In this case, it's > > merely a matter of setting up the > virtual-adjacency when the > > ABR bit toggle on and tearing it down when the bit > is cleared > > (on either end). > > > > Have fun, > > Don > > > > --- On Mon 07/29, praveendas e wrote: > > From: praveendas e [mailto: > e_praveendas@HOTMAIL.COM] > > To: OSPF@DISCUSS.MICROSOFT.COM > > Date: Mon, 29 Jul 2002 10:55:43 +0000 > > Subject: Re: Virtual Link > > > > > >>Hai Amit > >> > >> We know that vitual link are basically for > the > >>back bone connectivety. Now consider a scenirie > where > >>we have R1 connected to area 1 , area 2 ,area 3 > and R2 > >>connected to area 2 and area 4 now if i want to > >>configure a virtual link between R1 and R2 what > should > >>be the LSAs flowing over the virtual link.(As > there in > >>no back bone connectivety) > >>Regards > >>Amit > >> > >> Your Scenario is looking like both routers are > in disconnected area.If > >>the > >>routers are residing in non backbone area it is > impossible to have a > >>virtual > >>link other than chainning of virtual link.For that > you have to create a > >>virtual link b/w R1 or R2 to the router in the > backbone. > >> > >> About the LSA's passing through this link is > ,it will send all LSA's > >>other than External LSA's passing through the > backbone. > >>Hope this help you .... > >>Rgds > >>Praveendas > >> > >> > >>>From: Amit Srivastava > >>>Reply-To: Mailing List > >>>To: OSPF@DISCUSS.MICROSOFT.COM > >>>Subject: Virtual Link > >>>Date: Mon, 29 Jul 2002 02:10:51 -0700 > >>> > >>>Hi All, > >>> We know that vitual link are basically for > the > >>>back bone connectivety. Now consider a scenirie > where > >>>we have R1 connected to area 1 , area 2 ,area 3 > and R2 > >>>connected to area 2 and area 4 now if i want to > >>>configure a virtual link between R1 and R2 what > should > >>>be the LSAs flowing over the virtual link.(As > there in > >>>no back bone connectivety) > >>>Regards > >>>Amit > >>> > >>>__________________________________________________ > >>>Do You Yahoo!? > >>>Yahoo! Health - Feel better, live better > >>>http://health.yahoo.com > >>> > >> > >> > >> > >>_________________________________________________________________ > >>Chat with friends online, try MSN Messenger: > http://messenger.msn.com > >> > >> > > > > ------------------------------------------------ > > Join Excite! - http://www.excite.com > > The most personalized portal on the Web! > > > > > > > -- > Acee __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jul 30 02:15: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 CAA06141 for ; Tue, 30 Jul 2002 02:15:17 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.006B0D3B@cherry.ease.lsoft.com>; Tue, 30 Jul 2002 2:16:23 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 149528 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 30 Jul 2002 02:16:23 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 30 Jul 2002 02:16:21 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id CB261F2C4E for ; Mon, 29 Jul 2002 23:16:19 -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: <20020730054204.7025.qmail@web40310.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D462EE8.804@redback.com> Date: Tue, 30 Jul 2002 02:15:04 -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 Amit Srivastava wrote: > Hi All, > I agree wih Don as we can have the virtual Link > configured between two ABRs even though they are not > connected to the backbone. Hello Amit, I agree that a virtual link can be "configured" without a backbone connection. However, the virtual link is a backbone interface and once it is "active" both ABRs will be connected to the backbone. > It is also documented in > the Alternative ABR implementation document by ietf. This is an informational draft. > My doubt is that in this case the virtual Link will > come up but will there be any traffic flowing over the > virtual Link as i think only backbone traffice flows > over the virtual Link. Actually, this is inaccurate. Backbone traffic may flow over the transit area corresponding to the virtual link (refer to section 16.3 in RFC 2328) - not necessarily the virtual link itself. However, you are correct that the virtual link will only be a factor in the route calculation for backbone traffic. > What do you Say Don and Acee > Regards > Amit > > --- Acee Lindem wrote: > >>Don Goodspeed wrote: >> >> >>>My 2 cents... >>> >>>Nowhere is section 15 of RFC2328 does it state >>> >>that either endpoint >> >>>of the virtual link MUST be connected to the >>> >>backbone area. Further, >> >>>it does state that the purpose of a virtual-link >>> >>is to establish/maintain >> >>>backbone connectivity. In my mind, so long as >>> >>each end-point is an ABR, >> >>>the virtual-link should be brought up, and >>> >>associated with area 0.0.0.0. >> >>>In the case below, area 2 would then be used as >>> >>the transit-area. >> >>>Of course, depending on the OSPF implementation, >>> >>the router may >> >>>or may not become an ABR without area 0 being >>> >>configured on >> >>>at least one interface (usually a loopback). >>> >> >>Don, >> >>The virtual link itself "counts" as an OSPF >>interface so any router with >>an active virtualy link is, by definition, connected >>to the backbone. >> >>Thanks, >>Acee >> >> >>>In this case, it's >>>merely a matter of setting up the >>> >>virtual-adjacency when the >> >>>ABR bit toggle on and tearing it down when the bit >>> >>is cleared >> >>>(on either end). >>> >>>Have fun, >>>Don >>> >>> --- On Mon 07/29, praveendas e wrote: >>>From: praveendas e [mailto: >>> >>e_praveendas@HOTMAIL.COM] >> >>>To: OSPF@DISCUSS.MICROSOFT.COM >>>Date: Mon, 29 Jul 2002 10:55:43 +0000 >>>Subject: Re: Virtual Link >>> >>> >>> >>>>Hai Amit >>>> >>>> We know that vitual link are basically for >>>> >>the >> >>>>back bone connectivety. Now consider a scenirie >>>> >>where >> >>>>we have R1 connected to area 1 , area 2 ,area 3 >>>> >>and R2 >> >>>>connected to area 2 and area 4 now if i want to >>>>configure a virtual link between R1 and R2 what >>>> >>should >> >>>>be the LSAs flowing over the virtual link.(As >>>> >>there in >> >>>>no back bone connectivety) >>>>Regards >>>>Amit >>>> >>>> Your Scenario is looking like both routers are >>>> >>in disconnected area.If >> >>>>the >>>>routers are residing in non backbone area it is >>>> >>impossible to have a >> >>>>virtual >>>>link other than chainning of virtual link.For that >>>> >>you have to create a >> >>>>virtual link b/w R1 or R2 to the router in the >>>> >>backbone. >> >>>> About the LSA's passing through this link is >>>> >>,it will send all LSA's >> >>>>other than External LSA's passing through the >>>> >>backbone. >> >>>>Hope this help you .... >>>>Rgds >>>>Praveendas >>>> >>>> >>>> >>>>>From: Amit Srivastava >>>>>Reply-To: Mailing List >>>>>To: OSPF@DISCUSS.MICROSOFT.COM >>>>>Subject: Virtual Link >>>>>Date: Mon, 29 Jul 2002 02:10:51 -0700 >>>>> >>>>>Hi All, >>>>> We know that vitual link are basically for >>>>> >>the >> >>>>>back bone connectivety. Now consider a scenirie >>>>> >>where >> >>>>>we have R1 connected to area 1 , area 2 ,area 3 >>>>> >>and R2 >> >>>>>connected to area 2 and area 4 now if i want to >>>>>configure a virtual link between R1 and R2 what >>>>> >>should >> >>>>>be the LSAs flowing over the virtual link.(As >>>>> >>there in >> >>>>>no back bone connectivety) >>>>>Regards >>>>>Amit >>>>> >>>>> >>>>__________________________________________________ >>>> >>>>>Do You Yahoo!? >>>>>Yahoo! Health - Feel better, live better >>>>>http://health.yahoo.com >>>>> >>>>> >>>> >>>> >>>_________________________________________________________________ >>> >>>>Chat with friends online, try MSN Messenger: >>>> >>http://messenger.msn.com >> >>>> >>>------------------------------------------------ >>>Join Excite! - http://www.excite.com >>>The most personalized portal on the Web! >>> >>> >>> >> >>-- >>Acee >> > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Health - Feel better, live better > http://health.yahoo.com > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jul 30 02:33: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 CAA06341 for ; Tue, 30 Jul 2002 02:33:07 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.006B0D89@cherry.ease.lsoft.com>; Tue, 30 Jul 2002 2:34:12 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 149615 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 30 Jul 2002 02:34:11 -0400 Received: from 192.25.46.26 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 30 Jul 2002 02:34:10 -0400 Received: from msgrel1.sgp.agilent.com (msgrel1.sgp.agilent.com [141.183.101.233]) by msgbas2.sgp.agilent.com (Postfix) with ESMTP id D111A1D9 for ; Tue, 30 Jul 2002 14:35:01 +0800 (SGP) Received: from apbrg1.sgp.agilent.com (apbrg1.sgp.agilent.com [141.183.6.40]) by msgrel1.sgp.agilent.com (Postfix) with SMTP id 0B4875EF for ; Tue, 30 Jul 2002 14:33:33 +0800 (SGP) Received: from 141.183.6.40 by apbrg1.sgp.agilent.com (InterScan E-Mail VirusWall NT); Tue, 30 Jul 2002 14:34:06 +0800 Received: by apbrg1.sgp.agilent.com with Internet Mail Service (5.5.2653.19) id <3QZB8YNA>; Tue, 30 Jul 2002 14:34:06 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <89D04169635E024E8FD2174A852D788B890C86@apmail16.ind.agilent.com> Date: Tue, 30 Jul 2002 14:34:22 +0800 Reply-To: Mailing List Sender: Mailing List From: Joseph Placid Subject: Re: Virtual Link To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Acee, You wrote - " virtual link can be configured without a backbone connection". From what I understand, Virtual links are used for 1) Maintaining a Hub-and-Spoke topology between Backbone area and the Non-Backbone areas. 2) Connecting physically seperate components of the backbone. 3) Providing redundant paths for connectivity between Backbone and Non-Backbone areas. Since all of the above conditions involve at least one Backbone Router, how can the virtual link be configured without a backbone connection? Or does a virtual link have uses other than the ones mentioned above? Joseph -----Original Message----- From: Acee Lindem [mailto:acee@REDBACK.COM] Sent: Tuesday, July 30, 2002 11:45 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Virtual Link Amit Srivastava wrote: > Hi All, > I agree wih Don as we can have the virtual Link > configured between two ABRs even though they are not > connected to the backbone. Hello Amit, I agree that a virtual link can be "configured" without a backbone connection. However, the virtual link is a backbone interface and once it is "active" both ABRs will be connected to the backbone. > It is also documented in > the Alternative ABR implementation document by ietf. This is an informational draft. > My doubt is that in this case the virtual Link will > come up but will there be any traffic flowing over the > virtual Link as i think only backbone traffice flows > over the virtual Link. Actually, this is inaccurate. Backbone traffic may flow over the transit area corresponding to the virtual link (refer to section 16.3 in RFC 2328) - not necessarily the virtual link itself. However, you are correct that the virtual link will only be a factor in the route calculation for backbone traffic. > What do you Say Don and Acee > Regards > Amit > > --- Acee Lindem wrote: > >>Don Goodspeed wrote: >> >> >>>My 2 cents... >>> >>>Nowhere is section 15 of RFC2328 does it state >>> >>that either endpoint >> >>>of the virtual link MUST be connected to the >>> >>backbone area. Further, >> >>>it does state that the purpose of a virtual-link >>> >>is to establish/maintain >> >>>backbone connectivity. In my mind, so long as >>> >>each end-point is an ABR, >> >>>the virtual-link should be brought up, and >>> >>associated with area 0.0.0.0. >> >>>In the case below, area 2 would then be used as >>> >>the transit-area. >> >>>Of course, depending on the OSPF implementation, >>> >>the router may >> >>>or may not become an ABR without area 0 being >>> >>configured on >> >>>at least one interface (usually a loopback). >>> >> >>Don, >> >>The virtual link itself "counts" as an OSPF >>interface so any router with >>an active virtualy link is, by definition, connected >>to the backbone. >> >>Thanks, >>Acee >> >> >>>In this case, it's >>>merely a matter of setting up the >>> >>virtual-adjacency when the >> >>>ABR bit toggle on and tearing it down when the bit >>> >>is cleared >> >>>(on either end). >>> >>>Have fun, >>>Don >>> >>> --- On Mon 07/29, praveendas e wrote: >>>From: praveendas e [mailto: >>> >>e_praveendas@HOTMAIL.COM] >> >>>To: OSPF@DISCUSS.MICROSOFT.COM >>>Date: Mon, 29 Jul 2002 10:55:43 +0000 >>>Subject: Re: Virtual Link >>> >>> >>> >>>>Hai Amit >>>> >>>> We know that vitual link are basically for >>>> >>the >> >>>>back bone connectivety. Now consider a scenirie >>>> >>where >> >>>>we have R1 connected to area 1 , area 2 ,area 3 >>>> >>and R2 >> >>>>connected to area 2 and area 4 now if i want to >>>>configure a virtual link between R1 and R2 what >>>> >>should >> >>>>be the LSAs flowing over the virtual link.(As >>>> >>there in >> >>>>no back bone connectivety) >>>>Regards >>>>Amit >>>> >>>> Your Scenario is looking like both routers are >>>> >>in disconnected area.If >> >>>>the >>>>routers are residing in non backbone area it is >>>> >>impossible to have a >> >>>>virtual >>>>link other than chainning of virtual link.For that >>>> >>you have to create a >> >>>>virtual link b/w R1 or R2 to the router in the >>>> >>backbone. >> >>>> About the LSA's passing through this link is >>>> >>,it will send all LSA's >> >>>>other than External LSA's passing through the >>>> >>backbone. >> >>>>Hope this help you .... >>>>Rgds >>>>Praveendas >>>> >>>> >>>> >>>>>From: Amit Srivastava >>>>>Reply-To: Mailing List >>>>>To: OSPF@DISCUSS.MICROSOFT.COM >>>>>Subject: Virtual Link >>>>>Date: Mon, 29 Jul 2002 02:10:51 -0700 >>>>> >>>>>Hi All, >>>>> We know that vitual link are basically for >>>>> >>the >> >>>>>back bone connectivety. Now consider a scenirie >>>>> >>where >> >>>>>we have R1 connected to area 1 , area 2 ,area 3 >>>>> >>and R2 >> >>>>>connected to area 2 and area 4 now if i want to >>>>>configure a virtual link between R1 and R2 what >>>>> >>should >> >>>>>be the LSAs flowing over the virtual link.(As >>>>> >>there in >> >>>>>no back bone connectivety) >>>>>Regards >>>>>Amit >>>>> >>>>> >>>>__________________________________________________ >>>> >>>>>Do You Yahoo!? >>>>>Yahoo! Health - Feel better, live better >>>>>http://health.yahoo.com >>>>> >>>>> >>>> >>>> >>>_________________________________________________________________ >>> >>>>Chat with friends online, try MSN Messenger: >>>> >>http://messenger.msn.com >> >>>> >>>------------------------------------------------ >>>Join Excite! - http://www.excite.com >>>The most personalized portal on the Web! >>> >>> >>> >> >>-- >>Acee >> > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Health - Feel better, live better > http://health.yahoo.com > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jul 30 04:19: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 EAA08202 for ; Tue, 30 Jul 2002 04:19:35 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.006B1AB6@cherry.ease.lsoft.com>; Tue, 30 Jul 2002 4:20:39 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 150755 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 30 Jul 2002 04:20:39 -0400 Received: from 66.218.78.85 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 30 Jul 2002 04:20:39 -0400 Received: from [203.200.20.226] by web40306.mail.yahoo.com via HTTP; Tue, 30 Jul 2002 01:20:39 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20020730082039.80494.qmail@web40306.mail.yahoo.com> Date: Tue, 30 Jul 2002 01:20:39 -0700 Reply-To: Mailing List Sender: Mailing List From: Amit Srivastava Subject: Re: Virtual Link To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <89D04169635E024E8FD2174A852D788B890C86@apmail16.ind.agilent.com> Precedence: list Hi Acee, I think the transit area will contain only the summary LSAs(of both backbone and non-backbone areas) and no router or network LSA of backbone will be given to the transit network.Nor the router LSA and network LSA of the non-backbone area be given to the transit Area. So in my case i think even though the virtual Link will be declared up there will be no backbone traffic for the virtual Link. RFC 2328 Section 16.3 also states that the transit area's summary LSA is examined. What do you say Acee?? Regards Amit --- Joseph Placid wrote: > Hi Acee, > You wrote - " virtual link can be configured > without a backbone connection". From what I > understand, Virtual links are used for > 1) Maintaining a Hub-and-Spoke topology > between Backbone area and the Non-Backbone areas. > 2) Connecting physically seperate components > of the backbone. > 3) Providing redundant paths for > connectivity between Backbone and Non-Backbone > areas. > Since all of the above conditions involve at least > one Backbone Router, how can the virtual link be > configured without a backbone connection? Or does a > virtual link have uses other than the ones mentioned > above? > > Joseph > > > > > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Tuesday, July 30, 2002 11:45 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: Virtual Link > > > Amit Srivastava wrote: > > > Hi All, > > I agree wih Don as we can have the virtual > Link > > configured between two ABRs even though they are > not > > connected to the backbone. > > > Hello Amit, > > I agree that a virtual link can be "configured" > without > a backbone connection. However, the virtual link is > a > backbone interface and once it is "active" both ABRs > will be connected to the backbone. > > > It is also documented in > > the Alternative ABR implementation document by > ietf. > > > This is an informational draft. > > > > My doubt is that in this case the virtual Link > will > > come up but will there be any traffic flowing over > the > > virtual Link as i think only backbone traffice > flows > > over the virtual Link. > > > Actually, this is inaccurate. Backbone traffic may > flow > over the transit area corresponding to the virtual > link (refer > to section 16.3 in RFC 2328) - not necessarily the > virtual link > itself. However, you are correct that the virtual > link will only > be a factor in the route calculation for backbone > traffic. > > > > What do you Say Don and Acee > > Regards > > Amit > > > > --- Acee Lindem wrote: > > > >>Don Goodspeed wrote: > >> > >> > >>>My 2 cents... > >>> > >>>Nowhere is section 15 of RFC2328 does it state > >>> > >>that either endpoint > >> > >>>of the virtual link MUST be connected to the > >>> > >>backbone area. Further, > >> > >>>it does state that the purpose of a virtual-link > >>> > >>is to establish/maintain > >> > >>>backbone connectivity. In my mind, so long as > >>> > >>each end-point is an ABR, > >> > >>>the virtual-link should be brought up, and > >>> > >>associated with area 0.0.0.0. > >> > >>>In the case below, area 2 would then be used as > >>> > >>the transit-area. > >> > >>>Of course, depending on the OSPF implementation, > >>> > >>the router may > >> > >>>or may not become an ABR without area 0 being > >>> > >>configured on > >> > >>>at least one interface (usually a loopback). > >>> > >> > >>Don, > >> > >>The virtual link itself "counts" as an OSPF > >>interface so any router with > >>an active virtualy link is, by definition, > connected > >>to the backbone. > >> > >>Thanks, > >>Acee > >> > >> > >>>In this case, it's > >>>merely a matter of setting up the > >>> > >>virtual-adjacency when the > >> > >>>ABR bit toggle on and tearing it down when the > bit > >>> > >>is cleared > >> > >>>(on either end). > >>> > >>>Have fun, > >>>Don > >>> > >>> --- On Mon 07/29, praveendas e wrote: > >>>From: praveendas e [mailto: > >>> > >>e_praveendas@HOTMAIL.COM] > >> > >>>To: OSPF@DISCUSS.MICROSOFT.COM > >>>Date: Mon, 29 Jul 2002 10:55:43 +0000 > >>>Subject: Re: Virtual Link > >>> > >>> > >>> > >>>>Hai Amit > >>>> > >>>> We know that vitual link are basically for > >>>> > >>the > >> > >>>>back bone connectivety. Now consider a scenirie > >>>> > >>where > >> > >>>>we have R1 connected to area 1 , area 2 ,area 3 > >>>> > >>and R2 > >> > >>>>connected to area 2 and area 4 now if i want to > >>>>configure a virtual link between R1 and R2 what > >>>> > >>should > >> > >>>>be the LSAs flowing over the virtual link.(As > >>>> > >>there in > >> > >>>>no back bone connectivety) > >>>>Regards > >>>>Amit > >>>> > >>>> Your Scenario is looking like both routers are > >>>> > >>in disconnected area.If > >> > >>>>the > >>>>routers are residing in non backbone area it is > >>>> > >>impossible to have a > >> > >>>>virtual > >>>>link other than chainning of virtual link.For > that > >>>> > === message truncated === __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jul 30 04: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 EAA08266 for ; Tue, 30 Jul 2002 04: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 <4.006B1BD6@cherry.ease.lsoft.com>; Tue, 30 Jul 2002 4:24:47 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 150806 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 30 Jul 2002 04:24:47 -0400 Received: from 66.218.78.80 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 30 Jul 2002 04:24:47 -0400 Received: from [203.200.20.226] by web40301.mail.yahoo.com via HTTP; Tue, 30 Jul 2002 01:24:46 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20020730082446.49361.qmail@web40301.mail.yahoo.com> Date: Tue, 30 Jul 2002 01:24:46 -0700 Reply-To: Mailing List Sender: Mailing List From: Amit Srivastava Subject: Re: Virtual Link To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <89D04169635E024E8FD2174A852D788B890C86@apmail16.ind.agilent.com> Precedence: list Hi Acee, My doubt is in my case as there is no backbone connectivity so no backbone traffic will be send over the virtual Link.But only the summary LSAs of the nonbackbone area will be send over the virtual Link Am I right?? Regards Amit --- Joseph Placid wrote: > Hi Acee, > You wrote - " virtual link can be configured > without a backbone connection". From what I > understand, Virtual links are used for > 1) Maintaining a Hub-and-Spoke topology > between Backbone area and the Non-Backbone areas. > 2) Connecting physically seperate components > of the backbone. > 3) Providing redundant paths for > connectivity between Backbone and Non-Backbone > areas. > Since all of the above conditions involve at least > one Backbone Router, how can the virtual link be > configured without a backbone connection? Or does a > virtual link have uses other than the ones mentioned > above? > > Joseph > > > > > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Tuesday, July 30, 2002 11:45 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: Virtual Link > > > Amit Srivastava wrote: > > > Hi All, > > I agree wih Don as we can have the virtual > Link > > configured between two ABRs even though they are > not > > connected to the backbone. > > > Hello Amit, > > I agree that a virtual link can be "configured" > without > a backbone connection. However, the virtual link is > a > backbone interface and once it is "active" both ABRs > will be connected to the backbone. > > > It is also documented in > > the Alternative ABR implementation document by > ietf. > > > This is an informational draft. > > > > My doubt is that in this case the virtual Link > will > > come up but will there be any traffic flowing over > the > > virtual Link as i think only backbone traffice > flows > > over the virtual Link. > > > Actually, this is inaccurate. Backbone traffic may > flow > over the transit area corresponding to the virtual > link (refer > to section 16.3 in RFC 2328) - not necessarily the > virtual link > itself. However, you are correct that the virtual > link will only > be a factor in the route calculation for backbone > traffic. > > > > What do you Say Don and Acee > > Regards > > Amit > > > > --- Acee Lindem wrote: > > > >>Don Goodspeed wrote: > >> > >> > >>>My 2 cents... > >>> > >>>Nowhere is section 15 of RFC2328 does it state > >>> > >>that either endpoint > >> > >>>of the virtual link MUST be connected to the > >>> > >>backbone area. Further, > >> > >>>it does state that the purpose of a virtual-link > >>> > >>is to establish/maintain > >> > >>>backbone connectivity. In my mind, so long as > >>> > >>each end-point is an ABR, > >> > >>>the virtual-link should be brought up, and > >>> > >>associated with area 0.0.0.0. > >> > >>>In the case below, area 2 would then be used as > >>> > >>the transit-area. > >> > >>>Of course, depending on the OSPF implementation, > >>> > >>the router may > >> > >>>or may not become an ABR without area 0 being > >>> > >>configured on > >> > >>>at least one interface (usually a loopback). > >>> > >> > >>Don, > >> > >>The virtual link itself "counts" as an OSPF > >>interface so any router with > >>an active virtualy link is, by definition, > connected > >>to the backbone. > >> > >>Thanks, > >>Acee > >> > >> > >>>In this case, it's > >>>merely a matter of setting up the > >>> > >>virtual-adjacency when the > >> > >>>ABR bit toggle on and tearing it down when the > bit > >>> > >>is cleared > >> > >>>(on either end). > >>> > >>>Have fun, > >>>Don > >>> > >>> --- On Mon 07/29, praveendas e wrote: > >>>From: praveendas e [mailto: > >>> > >>e_praveendas@HOTMAIL.COM] > >> > >>>To: OSPF@DISCUSS.MICROSOFT.COM > >>>Date: Mon, 29 Jul 2002 10:55:43 +0000 > >>>Subject: Re: Virtual Link > >>> > >>> > >>> > >>>>Hai Amit > >>>> > >>>> We know that vitual link are basically for > >>>> > >>the > >> > >>>>back bone connectivety. Now consider a scenirie > >>>> > >>where > >> > >>>>we have R1 connected to area 1 , area 2 ,area 3 > >>>> > >>and R2 > >> > >>>>connected to area 2 and area 4 now if i want to > >>>>configure a virtual link between R1 and R2 what > >>>> > >>should > >> > >>>>be the LSAs flowing over the virtual link.(As > >>>> > >>there in > >> > >>>>no back bone connectivety) > >>>>Regards > >>>>Amit > >>>> > >>>> Your Scenario is looking like both routers are > >>>> > >>in disconnected area.If > >> > >>>>the > >>>>routers are residing in non backbone area it is > >>>> > >>impossible to have a > >> > >>>>virtual > >>>>link other than chainning of virtual link.For > that > >>>> > === message truncated === __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jul 30 08:51: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 IAA15781 for ; Tue, 30 Jul 2002 08:51:16 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.006B2BF5@cherry.ease.lsoft.com>; Tue, 30 Jul 2002 8:52:20 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 152476 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 30 Jul 2002 08:52:20 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 30 Jul 2002 08:52:20 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 43D931DCC60 for ; Tue, 30 Jul 2002 05:52:17 -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: <89D04169635E024E8FD2174A852D788B890C86@apmail16.ind.agilent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D468BB2.9000002@redback.com> Date: Tue, 30 Jul 2002 08:50:58 -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 Joseph Placid wrote: > Hi Acee, > You wrote - " virtual link can be configured without a backbone connection". From what I understand, Virtual links are used for > 1) Maintaining a Hub-and-Spoke topology between Backbone area and the Non-Backbone areas. > 2) Connecting physically seperate components of the backbone. > 3) Providing redundant paths for connectivity between Backbone and Non-Backbone areas. > Since all of the above conditions involve at least one Backbone Router, how can the virtual link be configured without a backbone connection? > Or does a virtual link have uses other than the ones mentioned above? Joseph, Although it wouldn't be a common topology, the backbone could be completely virtual. In other words, only virtual links connect ABRs though common transit area(s). Perhaps, the ambiguity of "connected" in Amit's initial query caused the confusion. What I trying to articulate in the response below is that the virtual link is a backbone interface and once it is active (i.e., there is a route to it through the transit area), the ABR is attached to the backbone. Thanks, Acee >>Hi All, >> I agree wih Don as we can have the virtual Link >>configured between two ABRs even though they are not >>connected to the backbone. >> > > > Hello Amit, > > I agree that a virtual link can be "configured" without > a backbone connection. However, the virtual link is a > backbone interface and once it is "active" both ABRs > will be connected to the backbone. > > >>It is also documented in >>the Alternative ABR implementation document by ietf. >> > > > This is an informational draft. > > > >>My doubt is that in this case the virtual Link will >>come up but will there be any traffic flowing over the >>virtual Link as i think only backbone traffice flows >>over the virtual Link. >> > > > Actually, this is inaccurate. Backbone traffic may flow > over the transit area corresponding to the virtual link (refer > to section 16.3 in RFC 2328) - not necessarily the virtual link > itself. However, you are correct that the virtual link will only > be a factor in the route calculation for backbone traffic. > > > >>What do you Say Don and Acee >>Regards >>Amit >> >>--- Acee Lindem wrote: >> >> >>>Don Goodspeed wrote: >>> >>> >>> >>>>My 2 cents... >>>> >>>>Nowhere is section 15 of RFC2328 does it state >>>> >>>> >>>that either endpoint >>> >>> >>>>of the virtual link MUST be connected to the >>>> >>>> >>>backbone area. Further, >>> >>> >>>>it does state that the purpose of a virtual-link >>>> >>>> >>>is to establish/maintain >>> >>> >>>>backbone connectivity. In my mind, so long as >>>> >>>> >>>each end-point is an ABR, >>> >>> >>>>the virtual-link should be brought up, and >>>> >>>> >>>associated with area 0.0.0.0. >>> >>> >>>>In the case below, area 2 would then be used as >>>> >>>> >>>the transit-area. >>> >>> >>>>Of course, depending on the OSPF implementation, >>>> >>>> >>>the router may >>> >>> >>>>or may not become an ABR without area 0 being >>>> >>>> >>>configured on >>> >>> >>>>at least one interface (usually a loopback). >>>> >>>> >>>Don, >>> >>>The virtual link itself "counts" as an OSPF >>>interface so any router with >>>an active virtualy link is, by definition, connected >>>to the backbone. >>> >>>Thanks, >>>Acee >>> >>> >>> >>>>In this case, it's >>>>merely a matter of setting up the >>>> >>>> >>>virtual-adjacency when the >>> >>> >>>>ABR bit toggle on and tearing it down when the bit >>>> >>>> >>>is cleared >>> >>> >>>>(on either end). >>>> >>>>Have fun, >>>>Don >>>> >>>>--- On Mon 07/29, praveendas e wrote: >>>>From: praveendas e [mailto: >>>> >>>> >>>e_praveendas@HOTMAIL.COM] >>> >>> >>>>To: OSPF@DISCUSS.MICROSOFT.COM >>>>Date: Mon, 29 Jul 2002 10:55:43 +0000 >>>>Subject: Re: Virtual Link >>>> >>>> >>>> >>>> >>>>>Hai Amit >>>>> >>>>> We know that vitual link are basically for >>>>> >>>>> >>>the >>> >>> >>>>>back bone connectivety. Now consider a scenirie >>>>> >>>>> >>>where >>> >>> >>>>>we have R1 connected to area 1 , area 2 ,area 3 >>>>> >>>>> >>>and R2 >>> >>> >>>>>connected to area 2 and area 4 now if i want to >>>>>configure a virtual link between R1 and R2 what >>>>> >>>>> >>>should >>> >>> >>>>>be the LSAs flowing over the virtual link.(As >>>>> >>>>> >>>there in >>> >>> >>>>>no back bone connectivety) >>>>>Regards >>>>>Amit >>>>> >>>>>Your Scenario is looking like both routers are >>>>> >>>>> >>>in disconnected area.If >>> >>> >>>>>the >>>>>routers are residing in non backbone area it is >>>>> >>>>> >>>impossible to have a >>> >>> >>>>>virtual >>>>>link other than chainning of virtual link.For that >>>>> >>>>> >>>you have to create a >>> >>> >>>>>virtual link b/w R1 or R2 to the router in the >>>>> >>>>> >>>backbone. >>> >>> >>>>> About the LSA's passing through this link is >>>>> >>>>> >>>,it will send all LSA's >>> >>> >>>>>other than External LSA's passing through the >>>>> >>>>> >>>backbone. >>> >>> >>>>>Hope this help you .... >>>>>Rgds >>>>>Praveendas >>>>> >>>>> >>>>> >>>>> >>>>>>From: Amit Srivastava >>>>>>Reply-To: Mailing List >>>>>>To: OSPF@DISCUSS.MICROSOFT.COM >>>>>>Subject: Virtual Link >>>>>>Date: Mon, 29 Jul 2002 02:10:51 -0700 >>>>>> >>>>>>Hi All, >>>>>> We know that vitual link are basically for >>>>>> >>>>>> >>>the >>> >>> >>>>>>back bone connectivety. Now consider a scenirie >>>>>> >>>>>> >>>where >>> >>> >>>>>>we have R1 connected to area 1 , area 2 ,area 3 >>>>>> >>>>>> >>>and R2 >>> >>> >>>>>>connected to area 2 and area 4 now if i want to >>>>>>configure a virtual link between R1 and R2 what >>>>>> >>>>>> >>>should >>> >>> >>>>>>be the LSAs flowing over the virtual link.(As >>>>>> >>>>>> >>>there in >>> >>> >>>>>>no back bone connectivety) >>>>>>Regards >>>>>>Amit >>>>>> >>>>>> >>>>>> >>>>>__________________________________________________ >>>>> >>>>> >>>>>>Do You Yahoo!? >>>>>>Yahoo! Health - Feel better, live better >>>>>>http://health.yahoo.com >>>>>> >>>>>> >>>>>> >>>>> >>>>_________________________________________________________________ >>>> >>>> >>>>>Chat with friends online, try MSN Messenger: >>>>> >>>>> >>>http://messenger.msn.com >>> >>> >>>>------------------------------------------------ >>>>Join Excite! - http://www.excite.com >>>>The most personalized portal on the Web! >>>> >>>> >>>> >>>> >>>-- >>>Acee >>> >>> >> >>__________________________________________________ >>Do You Yahoo!? >>Yahoo! Health - Feel better, live better >>http://health.yahoo.com >> >> >> > > > -- > Acee > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jul 30 09:02: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 JAA16290 for ; Tue, 30 Jul 2002 09:02:49 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.006B2CD9@cherry.ease.lsoft.com>; Tue, 30 Jul 2002 9:03:56 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 152541 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 30 Jul 2002 09:03:56 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 30 Jul 2002 09:03:56 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 58F5D1DCC60 for ; Tue, 30 Jul 2002 06:03:54 -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: <20020730082446.49361.qmail@web40301.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D468E6B.60505@redback.com> Date: Tue, 30 Jul 2002 09:02:35 -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 Amit Srivastava wrote: > Hi Acee, > My doubt is in my case as there is no backbone > connectivity so no backbone traffic will be send over > the virtual Link.But only the summary LSAs of the > nonbackbone area will be send over the virtual Link > Am I right?? Amit, I think we're having a failure to communicate - if you have a virtual link you have backbone connectivity. Area 0 Virtual Link O - - - - - - - - - O +------+ +--------+ | R1 |--------------| R2 | +-----+ Area 1 +---------+ | | Area 2 Area 3 In the picture above all traffic between area 2 and area 3 will be via the area 1 (the virtual link's transit area). Thanks, Acee > Regards > Amit > --- Joseph Placid > wrote: > >>Hi Acee, >> You wrote - " virtual link can be configured >>without a backbone connection". From what I >>understand, Virtual links are used for >> 1) Maintaining a Hub-and-Spoke topology >>between Backbone area and the Non-Backbone areas. >> 2) Connecting physically seperate components >>of the backbone. >> 3) Providing redundant paths for >>connectivity between Backbone and Non-Backbone >>areas. >>Since all of the above conditions involve at least >>one Backbone Router, how can the virtual link be >>configured without a backbone connection? Or does a >>virtual link have uses other than the ones mentioned >>above? >> >>Joseph >> >> >> >> >>-----Original Message----- >>From: Acee Lindem [mailto:acee@REDBACK.COM] >>Sent: Tuesday, July 30, 2002 11:45 AM >>To: OSPF@DISCUSS.MICROSOFT.COM >>Subject: Re: Virtual Link >> >> >>Amit Srivastava wrote: >> >> >>>Hi All, >>> I agree wih Don as we can have the virtual >>> >>Link >> >>>configured between two ABRs even though they are >>> >>not >> >>>connected to the backbone. >>> >> >>Hello Amit, >> >>I agree that a virtual link can be "configured" >>without >>a backbone connection. However, the virtual link is >>a >>backbone interface and once it is "active" both ABRs >>will be connected to the backbone. >> >> >>>It is also documented in >>>the Alternative ABR implementation document by >>> >>ietf. >> >> >>This is an informational draft. >> >> >> >>>My doubt is that in this case the virtual Link >>> >>will >> >>>come up but will there be any traffic flowing over >>> >>the >> >>>virtual Link as i think only backbone traffice >>> >>flows >> >>>over the virtual Link. >>> >> >>Actually, this is inaccurate. Backbone traffic may >>flow >>over the transit area corresponding to the virtual >>link (refer >>to section 16.3 in RFC 2328) - not necessarily the >>virtual link >>itself. However, you are correct that the virtual >>link will only >>be a factor in the route calculation for backbone >>traffic. >> >> >> >>>What do you Say Don and Acee >>>Regards >>>Amit >>> >>>--- Acee Lindem wrote: >>> >>> >>>>Don Goodspeed wrote: >>>> >>>> >>>> >>>>>My 2 cents... >>>>> >>>>>Nowhere is section 15 of RFC2328 does it state >>>>> >>>>> >>>>that either endpoint >>>> >>>> >>>>>of the virtual link MUST be connected to the >>>>> >>>>> >>>>backbone area. Further, >>>> >>>> >>>>>it does state that the purpose of a virtual-link >>>>> >>>>> >>>>is to establish/maintain >>>> >>>> >>>>>backbone connectivity. In my mind, so long as >>>>> >>>>> >>>>each end-point is an ABR, >>>> >>>> >>>>>the virtual-link should be brought up, and >>>>> >>>>> >>>>associated with area 0.0.0.0. >>>> >>>> >>>>>In the case below, area 2 would then be used as >>>>> >>>>> >>>>the transit-area. >>>> >>>> >>>>>Of course, depending on the OSPF implementation, >>>>> >>>>> >>>>the router may >>>> >>>> >>>>>or may not become an ABR without area 0 being >>>>> >>>>> >>>>configured on >>>> >>>> >>>>>at least one interface (usually a loopback). >>>>> >>>>> >>>>Don, >>>> >>>>The virtual link itself "counts" as an OSPF >>>>interface so any router with >>>>an active virtualy link is, by definition, >>>> >>connected >> >>>>to the backbone. >>>> >>>>Thanks, >>>>Acee >>>> >>>> >>>> >>>>>In this case, it's >>>>>merely a matter of setting up the >>>>> >>>>> >>>>virtual-adjacency when the >>>> >>>> >>>>>ABR bit toggle on and tearing it down when the >>>>> >>bit >> >>>>is cleared >>>> >>>> >>>>>(on either end). >>>>> >>>>>Have fun, >>>>>Don >>>>> >>>>>--- On Mon 07/29, praveendas e wrote: >>>>>From: praveendas e [mailto: >>>>> >>>>> >>>>e_praveendas@HOTMAIL.COM] >>>> >>>> >>>>>To: OSPF@DISCUSS.MICROSOFT.COM >>>>>Date: Mon, 29 Jul 2002 10:55:43 +0000 >>>>>Subject: Re: Virtual Link >>>>> >>>>> >>>>> >>>>> >>>>>>Hai Amit >>>>>> >>>>>> We know that vitual link are basically for >>>>>> >>>>>> >>>>the >>>> >>>> >>>>>>back bone connectivety. Now consider a scenirie >>>>>> >>>>>> >>>>where >>>> >>>> >>>>>>we have R1 connected to area 1 , area 2 ,area 3 >>>>>> >>>>>> >>>>and R2 >>>> >>>> >>>>>>connected to area 2 and area 4 now if i want to >>>>>>configure a virtual link between R1 and R2 what >>>>>> >>>>>> >>>>should >>>> >>>> >>>>>>be the LSAs flowing over the virtual link.(As >>>>>> >>>>>> >>>>there in >>>> >>>> >>>>>>no back bone connectivety) >>>>>>Regards >>>>>>Amit >>>>>> >>>>>>Your Scenario is looking like both routers are >>>>>> >>>>>> >>>>in disconnected area.If >>>> >>>> >>>>>>the >>>>>>routers are residing in non backbone area it is >>>>>> >>>>>> >>>>impossible to have a >>>> >>>> >>>>>>virtual >>>>>>link other than chainning of virtual link.For >>>>>> >>that >> > === message truncated === > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Health - Feel better, live better > http://health.yahoo.com > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jul 30 10:02: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 KAA18759 for ; Tue, 30 Jul 2002 10:02:38 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.006B2D9B@cherry.ease.lsoft.com>; Tue, 30 Jul 2002 10:03:45 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 152716 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 30 Jul 2002 10:03:45 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 30 Jul 2002 10:03:45 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Jul 2002 10:03:43 -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, 30 Jul 2002 10:06:05 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Link Flap Damping Comments: To: Yasuhiro Ohara To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Yasu, I will try reply in brief. > So, hellos may be dropped anyway whether L2 dampening feature is on or > not (off). Exactly. The packets would be dropped if the Lower-Layer is down. By damping, we are keeping it down even when it isn't really, so that we do not have persistent cycles of up/down. I think we have some slight confusion here, regarding what you are thinking and what I am. >Yes, I've read the draft and it'll be very effective where hello/dead >are 10/40s (or similar). But none of this will solve the problem >essentially. I was talking about doing something like section 4.2.2.3. What I meant was imagine a case where we get a flap from the lower-layer to OSPF, a Down and then an UP. What we could do in such a case would be as soon as we get the down event, we do advertize the link as down, however we do not actually bring the adjacency down for some short period of time. So incase the link comes up immediately we do not have to reform adjacency all over again. If the other end however breaks the adjacency we anyway form adjacency from the beginning again. >No, I don't think so. > >In usual case below: > > [sw1]-[sw2]-[sw3] > | | > R1 R2 > > If L2 switch [sw2] or the link connected to it flaps, R1 and R2 would > not be able to recognize the flaps even if there's some conversation > about the link's (L2) information above [sw1], [sw2] and [sw3]. If the link is flapping on sw2, sw2 would damp it wouldn't it. If we did have flap dampening at layer 2. then the two ends R1 and R2, would not form an adjacency. By the way L2 damping would help not only OSPF but all other protocols above L2. > That's very similar to what I am looking for ;p) > > But how did you recognize the flap ? All I want to know is this. > How did you distinct the flap from the link completely down, when > dead-interval have elapsed without receiving Hello ? How immediately > could you recover the link's availability when the link's flaps > vanished ? To recognize a link flap the flap history of the link will have to be stored. If the link went up/down x times in time t, we could damp it. We could have a link damped for at most a time Tand so on. Methods are left to the implementor, as well as the value of x ,T and t. We could however do things, as I pointed out earlier. >Really waiting for your reply. Guess the wait is finally over now(though it did take considerable time). ;-) Thanks, Vishwas From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jul 30 10:06: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 KAA18957 for ; Tue, 30 Jul 2002 10:05:59 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.006B2E0D@cherry.ease.lsoft.com>; Tue, 30 Jul 2002 10:07:06 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 152759 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 30 Jul 2002 10:07:06 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 30 Jul 2002 10:07:06 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 8349C1DCC60 for ; Tue, 30 Jul 2002 07:07:04 -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: <20020730.125317.27309274.yasu@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3D469D38.7020002@redback.com> Date: Tue, 30 Jul 2002 10:05:44 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Link Flap Damping To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Yasuhiro Ohara wrote: > Hi Manral, Erblichs, Acee: > > Forgive me to reply by this all-in-one message for some of previous > e-mails. All, I think we're digesting too much on the issue of whether or not a given layer 2 technology can detect a link status change or loss of connectivity. For the sake of argument, let's say that there are cases where the layer 2 technology/implementation either doesn't support link flap dampening or can't reliably detect layer 3 connectivity loss/gain. Yasu, Manav, Irrespective of what is configured for the hello and router dead intervals, the current value of MinLSInterval is 5 seconds. Even if adjacent routers can lose and form an adjacency faster than the 5 second interval, they will not re-originate their router LSAs any faster and routes will not flap. Do you really feel there is a strong requirement for further dampening? If so, is this requirement from a network operator? It would seem the best tact would be to progressively delay link up event processing and/or neighbor adjacency formation (bad news should always be propagated quickly). Anyway, I'm not convinced it is necessary but that's not to say you shouldn't proceed. Thanks, Acee > > First, I have some prerequisions about this discussion. I guess we all > want to decrease Hello-Interval and Dead-Interval to make convergence > more faster, is this right ? I don't think Hello-Interval should be 10 > seconds because that's too long. And I am so impatient that I cannot > wait for 40 seconds for my communication being revived each time the > network topology changes. > > If we keep this in mind things may be changed bellow. > > VishwasM> Hi Yasu, > VishwasM> > VishwasM> If both ends of a link do have a link damping feature what > VishwasM> problem would it still not solve. The hellos would not be > VishwasM> causing any flap if the lower layer itself has taken care > VishwasM> that the flap, because it would not convey a link up event > VishwasM> till the link showed no failure for some time(as in RPR > VishwasM> example below). > > What would it be done with the Hellos going through the link which is > down but kept from notifying the upper layer ? It is obviously not > good for L2 switches to keep this traffic in its own buffer and > re-send it. (I believe all of the L2 flap dampening technology won't > do this.) > > So, hellos may be dropped anyway whether L2 dampening feature is on or > not (off). > > VishwasM> Yes, for congestion case something may be required. We have > VishwasM> put that down in our draft congestion-control draft. > > Yes, I've read the draft and it'll be very effective where hello/dead > are 10/40s (or similar). But none of this will solve the problem > essentially. > > - Throttle setup of adjacency > I guess prioritizing the adjacencies is the most bothering thing > for network operators. The future world enforcing this to be > involved is not attractive ... > - DSCP marking of hello/ack > This is for congestion and can do nothing with link down. > - Use other control packets than hello as detect link live-ness > This is also mainly for congestion I guess. > Frequency of other control packets than hello is another critical > issue for OSPF scalability and should be decreased. But in the > other hand (ideally) the dead interval may not be so long to > wait these kind of "OSPF update" to occur. Hence we should think > we can use only the hellos to detect link flaps. > > # By the way, though the draft inform me a lot of valuable things, > # I could not understand one part of it. 4.1.2's end paragraph says: > # "Maintaining sequence number counters for different packet types > # may solve this issue" but what is the sequence number and how a > # implementation take care the packet reordering ? > > erblichs> Has anyone seen or invisioned an interaction with "link flap > erblichs> dampening" and Moy's OSPF implimentation where he attempts > erblichs> to accelerate bi-directional status? Chapt 1, p.2 1.1.1 > erblichs> Optimizations > erblichs> > erblichs> Basicly, can a damped link on one side prevent this > erblichs> acceleration to occur? > erblichs> > erblichs> And should this accelerated method bunch the load on a > erblichs> router and thus counter-intuitive to congestion control? > erblichs> Especially with a set of routers all coming up at the same > erblichs> time and then the bunching of adjacency formations. > > Could you explain more detail about this ? I understood this as a > feature to simply make the adjacency to come up faster, and nothing > has to do with the flap dampening. > > acee> Normally, it is the link up event that is dampened at layer 2 > acee> and it is normally done in a such a way that the OSPF hello > acee> packets will not be received or will be dropped at a low level. > > OK, so I feel I can't admit L2's link flap dampening more and more. > > If the link up event is dropped and does not come up during the link > physically flaps until someone take care of the link's problem, and if > the link is the only one to reach a place (this is usual case), the > place will be unreach very long time. I guess it's not acceptable. > > Today we implicitly dampen the flaps by keeping the hello/dead > interval long (like 10/40s). The result of this dampened link while > flaps is *UP*, realizing "Best effort" Internet policy because some > packet may reach still through the flapping link. > > Are we really change this thing ? Can someone easily drop being > unaware of how important the link's live-ness is, even partially ? > > VishwasM> Hi Manav, > VishwasM> > VishwasM> First, some good news. ;-) I hear IEEE is working on failure > VishwasM> notification for Ethernet. > VishwasM> > VishwasM> As I see link flap damping, it has nothing to do with the > VishwasM> other end but our own interface. So when we know that we are > VishwasM> consistently flapping, we can have some way to prevent it. I > VishwasM> guess all that you say, does not come into the picture at > VishwasM> all in that case. > VishwasM> > VishwasM> In OSPF because we have a 3-way handshake hello mechanism, > VishwasM> the link would not come up, and be used for routing table > VishwasM> calculation, if either end damped it. > > No, I don't think so. > > In usual case below: > > [sw1]-[sw2]-[sw3] > | | > R1 R2 > > If L2 switch [sw2] or the link connected to it flaps, R1 and R2 would > not be able to recognize the flaps even if there's some conversation > about the link's (L2) information above [sw1], [sw2] and [sw3]. > There are still possibilities of dropping Hellos. If the hello/dead > intervals are so short, the frequency of OSPF calculation will be > MinLSInterval (5sec). The network where the route changes each 5 secs > are not acceptable. > > Yes, we have one major conflict in OSPF routing: > "Converge fast but don't let a link flap". > > VishwasM> We can, for precaution sake do flap damping at OSPF > VishwasM> layer. Ways to do it could be: - > VishwasM> > VishwasM> http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0108&L=OSPF&P=R7962&I=-3 > VishwasM> > VishwasM> and > VishwasM> > VishwasM> we could actually advertize the link metric with value > VishwasM> 0xffff for such links. So in case there is no other path to > VishwasM> a destination the link can still be used. > > That's very similar to what I am looking for ;p) > > But how did you recognize the flap ? All I want to know is this. > How did you distinct the flap from the link completely down, when > dead-interval have elapsed without receiving Hello ? How immediately > could you recover the link's availability when the link's flaps > vanished ? > > It is worth writing I-D for experimental/informational use, even > though I admit it's an implementation issue. > > VishwasM> We could probably have more opinions on this. Alex/John ?? > > Really waiting for your reply. > > regards ! > yasu > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jul 30 14:40: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 OAA03993 for ; Tue, 30 Jul 2002 14:40:18 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.006B33C9@cherry.ease.lsoft.com>; Tue, 30 Jul 2002 14:41:23 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 153851 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 30 Jul 2002 14:41:22 -0400 Received: from 63.236.75.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 30 Jul 2002 14:41:22 -0400 Received: by xmxpita.excite.com (Postfix, from userid 110) id A2F4629A56; Tue, 30 Jul 2002 14:41:19 -0400 (EDT) Received: from [63.104.212.252] by xprdmailfe21.nwk.excite.com via HTTP; Tue, 30 Jul 2002 14:41:19 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = b4f718530cf8af0dd8df25e0425ffee0 MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20020730184119.A2F4629A56@xmxpita.excite.com> Date: Tue, 30 Jul 2002 14:41:19 -0400 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: Virtual Link Comments: cc: acee@REDBACK.COM To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Acee, Could not have said it better myself. I always tell people "Remember, a virtual-link is like a physical point-to-point link strung directly between the two endpoint routers and it always belongs to area 0." The only caveat is that if there are multiple end-points, it will chose the path to the nearest end-point, not necessarily the endpoint with the virtual-link configured on it. -don --- On Tue 07/30, Acee Lindem wrote: From: Acee Lindem [mailto: acee@REDBACK.COM] To: OSPF@DISCUSS.MICROSOFT.COM Date: Tue, 30 Jul 2002 02:15:04 -0400 Subject: Re: Virtual Link > Amit Srivastava wrote: > > > Hi All, > > I agree wih Don as we can have the virtual Link > > configured between two ABRs even though they are not > > connected to the backbone. > > > Hello Amit, > > I agree that a virtual link can be "configured" without > a backbone connection. However, the virtual link is a > backbone interface and once it is "active" both ABRs > will be connected to the backbone. > > > It is also documented in > > the Alternative ABR implementation document by ietf. > > > This is an informational draft. > > > > My doubt is that in this case the virtual Link will > > come up but will there be any traffic flowing over the > > virtual Link as i think only backbone traffice flows > > over the virtual Link. > > > Actually, this is inaccurate. Backbone traffic may flow > over the transit area corresponding to the virtual link (refer > to section 16.3 in RFC 2328) - not necessarily the virtual link > itself. However, you are correct that the virtual link will only > be a factor in the route calculation for backbone traffic. > > > > What do you Say Don and Acee > > Regards > > Amit > > ------------------------------------------------ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ospf@DISCUSS.MICROSOFT.COM Tue Jul 30 14:44: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 OAA04151 for ; Tue, 30 Jul 2002 14:44:19 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.006B3488@cherry.ease.lsoft.com>; Tue, 30 Jul 2002 14:45:26 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 153873 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 30 Jul 2002 14:45:26 -0400 Received: from 63.236.75.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Tue, 30 Jul 2002 14:45:25 -0400 Received: by xmxpita.excite.com (Postfix, from userid 110) id D694329A70; Tue, 30 Jul 2002 14:45:22 -0400 (EDT) Received: from [63.104.212.252] by xprdmailfe21.nwk.excite.com via HTTP; Tue, 30 Jul 2002 14:45:22 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = b4f718530cf8af0dd8df25e0425ffee0 MIME-Version: 1.0 X-Sender: dgoodspe@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-ID: <20020730184522.D694329A70@xmxpita.excite.com> Date: Tue, 30 Jul 2002 14:45:22 -0400 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: Virtual Link To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Joesph, Also remember that the RFC says the purpose of a virtual-link is to establish/maintain backbone connectivity. The point of this chain is that most people forget about the "establish" part of that statement when discussing virtual-links. So, yes, that would be a 4th purpose. Cheers, Don --- On Tue 07/30, Acee Lindem wrote: From: Acee Lindem [mailto: acee@REDBACK.COM] To: OSPF@DISCUSS.MICROSOFT.COM Date: Tue, 30 Jul 2002 08:50:58 -0400 Subject: Re: Virtual Link > Joseph Placid wrote: > > > Hi Acee, > > You wrote - " virtual link can be configured without a > backbone connection". From what I understand, Virtual links are used > for > > 1) Maintaining a Hub-and-Spoke topology between Backbone area > and the Non-Backbone areas. > > 2) Connecting physically seperate components of the > backbone. > > 3) Providing redundant paths for connectivity between > Backbone and Non-Backbone areas. > > Since all of the above conditions involve at least one Backbone > Router, how can the virtual link be configured without a backbone > connection? > > > Or does a virtual link have uses other than the ones mentioned > above? > > > Joseph, > > Although it wouldn't be a common topology, the backbone could be > completely > virtual. In other words, only virtual links connect ABRs though common > transit area(s). Perhaps, the ambiguity of "connected" in Amit's > initial > query caused the confusion. What I trying to articulate in the response > below is > that the virtual link is a backbone interface and once it is active (i.e., > there > is a route to it through the transit area), the ABR is attached to the > backbone. > > Thanks, > > Acee > ------------------------------------------------ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jul 31 00:56: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 AAA20792 for ; Wed, 31 Jul 2002 00:56:34 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.006B43E2@cherry.ease.lsoft.com>; Wed, 31 Jul 2002 0:57:39 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 155318 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 31 Jul 2002 00:57:39 -0400 Received: from 203.254.224.24 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 31 Jul 2002 00:57:39 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) id <0H0300401KKB5W@mailout1.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Wed, 31 Jul 2002 14:00:11 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0H030041TKKA0L@mailout1.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Wed, 31 Jul 2002 14:00:11 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0H0300FAWKKIW3@mmp2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Wed, 31 Jul 2002 14:00:20 +0900 (KST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20020730.125317.27309274.yasu@sfc.wide.ad.jp> <3D469D38.7020002@redback.com> Message-ID: <009701c2384e$29073d20$b4036c6b@sisodomain.com> Date: Wed, 31 Jul 2002 10:23:04 +0530 Reply-To: Mailing List Sender: Mailing List From: Manav Bhatia Subject: [Prob with L2] - Re: Link Flap Damping Comments: To: acee@REDBACK.COM, vishwasM@netplane.com To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7BIT Acee and Vishwas, | I think we're digesting too much on the issue of whether or not a | given layer 2 technology can detect a link status change or loss of | connectivity. For the sake of argument, let's say that there are cases | where the layer 2 technology/implementation either doesn't support | link flap dampening or can't reliably detect layer 3 connectivity | loss/gain. This is not the only issue. What i am looking for is a unified approach which can take care of both the flapping links/routers and flapping routes redistributed from outside OSPF domain. This is very important because each time a router recieves some LSAs it requires SPF computation which takes up some CPU resources. There is some time delay before it actually triggers the SPF computation and the time it recieves the LSAs. Now if the CPU is too busy performing SPF calculation then it may miss out sending HELLOs which may falsely bring down some adjacenices. In the worst case because of these new LSAs originated, more adjacencies may go down for the CPU is busy running the SPF. Even if we provide link flap damping at L2 there is no way that we can ever identify flapping routes redistributed from outside OSPF domain. And once again, if L2 flap damping is enough then why do we have the concept of route flap damping in BGP which we know is widely used and deployed. IGPs are crucial for the operation of BGP since it uses the information provided by the IGPs to calculate the nexthop to reach the exit router. IGP calculates the best next hop to reach the exit router and if IGP changes then we have to change the next hop in tens of thousands of BGP routes which are being advertised to the whole world. And there is no flap damping mechanism which exits in BGP which can detect changes in the next hop of BGP routes and somehow damp them or straighten them out. | | Irrespective of what is configured for the hello and router dead intervals, We dont care for these values in the current context. | the current value of MinLSInterval is 5 seconds. Even if adjacent routers | can lose and form an adjacency faster than the 5 second interval, they will | not re-originate their router LSAs any faster and routes will not flap. What if it happens every 7 secs. | Do you | really feel there is a strong requirement for further dampening? If so, is | this requirement from a network operator? | It would seem the best tact | would be to progressively delay link up event processing and/or neighbor | adjacency formation (bad news should always be propagated quickly). Anyway, | I'm not convinced it is necessary but that's not to say you shouldn't proceed. Another problem which exists with damping enabled at L2 is that the interface becomes unusable and the networks on the other side of this interface get isolated when we declare the link as down. It is not limited to only OSPF. Things will become clear with this diagram below. ---------------- | Internet cloud | ---------------- | ----------- | Rtr A | ----------- | link A ---------------- | local network | ---------------- If for e.g. link A is flapping for some reason or the router is crashing after some time period (30 secs ~ 30 mins) then if link flap damping is enabled at L2 then after some threshold is reached link A will be declared as down. It will continue to be declared down till some figure of merit falls below another threshold and we start using it again. During the period when this link is being damped the local network cannot reach the internet cloud and vica versa. This is not at all desirable. Our intention is to just let OSPF remain undisturbed with the continued perturbations we see on this link A. Implementing link flap damping at L3 will enable us to do just that. Second, link flap damping can be enabled at L2 only if the link flaps in milli secs or a time of some nearby order. What if it flaps every 30 mins. Is it then proper to declare the link as down? No .. but from the OSPF perspective if the nexthop is very vital and is being exported to BGP then the system administrator can set it so. It should be possible to configure flap damping to handle short term severe route flaps and chronic milder route flaps (a pattern of occasional drops over a long time period). The former would require a fast decay and low threshold (allowing a small number of consecutive flaps to cause a link/route to be suppressed, but allowing it to be reused after a relatively short period of stability). The latter would require a very slow decay and a higher threshold and might be appropriate for links/routes for which there was an alternate path of similar bandwidth. A less aggressive suppression can be applied to the case where no alternate path exists In the simplest case, a more aggressive suppression should be applied if any alternate route/path exists. It might also be desirable to configure a different set of thresholds for routes which rely on switched services and may disconnect at times to reduce connect charges. Such routes might be expected to change state somewhat more often, but should be suppressed if continuous state changes indicate instability. All of these arguments lead me to believe that the place best to damp any flaps is L3. Thanks and Regards, Manav From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jul 31 01:48: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 BAA21982 for ; Wed, 31 Jul 2002 01:47: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.006B4599@cherry.ease.lsoft.com>; Wed, 31 Jul 2002 1:49:05 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 155490 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 31 Jul 2002 01:49:05 -0400 Received: from 203.254.224.24 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 31 Jul 2002 01:49:04 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) id <0H0300501MY1WG@mailout1.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Wed, 31 Jul 2002 14:51:37 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0H030051RMY0S2@mailout1.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Wed, 31 Jul 2002 14:51:36 +0900 (KST) Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTPA id <0H0300I2FMY8HP@mmp2.samsung.com> for OSPF@DISCUSS.MICROSOFT.COM; Wed, 31 Jul 2002 14:51:46 +0900 (KST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Message-ID: <00fe01c23855$58154600$b4036c6b@sisodomain.com> Date: Wed, 31 Jul 2002 11:14:30 +0530 Reply-To: Mailing List Sender: Mailing List From: Manav Bhatia Subject: Re: Link Flap Damping Comments: To: vishwasM@netplane.com To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7BIT Hi Manral, | > | > [sw1]-[sw2]-[sw3] | > | | | > R1 R2 | > | > If L2 switch [sw2] or the link connected to it flaps, R1 and R2 would | > not be able to recognize the flaps even if there's some conversation | > about the link's (L2) information above [sw1], [sw2] and [sw3]. | If the link is flapping on sw2, sw2 would damp it wouldn't it. If we did | have flap dampening at layer 2. then the two ends R1 and R2, would not form | an adjacency. By the way L2 damping would help not only OSPF but all other | protocols above L2. not exactly. link flap damping implemented at L2 will only work if the time period of the flap is high and the duration is small. What can be done if an interface fails after every 10 mins and takes 20 seconds to come up. Will we flap the link at L2 after 30 mins (hypothetical figures) when its has flapped thrice for some 10 mins? We will thus be blocking all the traffic which might otherwise flow over this link. If we do it at the L3 then we can specify which all applications needs to do the damping and rest of the things work normally following the traditional best delivery model. I can cite cases when we may like to continue with a flapping link than having no link/communication channel at all. If you decided to let L2 take care of link flap damping then it can adversely affect BGP functioning under some circumstances. BGP may continue to use this link as the last resort claiming reachability to some destinations through it and assigning it a higher MED and announcing this to its external peers. The system administrator can then suitably set the route flapping parameters associated with that link and things will work out fine for him! Thanks and Regards, Manav From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jul 31 07:55: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 HAA22230 for ; Wed, 31 Jul 2002 07:55:42 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.006B4A10@cherry.ease.lsoft.com>; Wed, 31 Jul 2002 7:56:24 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 156814 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 31 Jul 2002 07:56:23 -0400 Received: from 198.62.10.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 31 Jul 2002 07:56:23 -0400 Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Wed, 31 Jul 2002 07:56:21 -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, 31 Jul 2002 07:58:51 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Link Flap Damping To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Manav, As Acee pointed out, if you still feel there is a desired requirement for further dampening and can compensate for the added complexity, go ahead and draft it. Thanks, Vishwas -----Original Message----- From: Manav Bhatia [mailto:manav@SAMSUNG.COM] Sent: Wednesday, July 31, 2002 11:15 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Link Flap Damping Hi Manral, | > | > [sw1]-[sw2]-[sw3] | > | | | > R1 R2 | > | > If L2 switch [sw2] or the link connected to it flaps, R1 and R2 would | > not be able to recognize the flaps even if there's some conversation | > about the link's (L2) information above [sw1], [sw2] and [sw3]. | If the link is flapping on sw2, sw2 would damp it wouldn't it. If we did | have flap dampening at layer 2. then the two ends R1 and R2, would not form | an adjacency. By the way L2 damping would help not only OSPF but all other | protocols above L2. not exactly. link flap damping implemented at L2 will only work if the time period of the flap is high and the duration is small. What can be done if an interface fails after every 10 mins and takes 20 seconds to come up. Will we flap the link at L2 after 30 mins (hypothetical figures) when its has flapped thrice for some 10 mins? We will thus be blocking all the traffic which might otherwise flow over this link. If we do it at the L3 then we can specify which all applications needs to do the damping and rest of the things work normally following the traditional best delivery model. I can cite cases when we may like to continue with a flapping link than having no link/communication channel at all. If you decided to let L2 take care of link flap damping then it can adversely affect BGP functioning under some circumstances. BGP may continue to use this link as the last resort claiming reachability to some destinations through it and assigning it a higher MED and announcing this to its external peers. The system administrator can then suitably set the route flapping parameters associated with that link and things will work out fine for him! Thanks and Regards, Manav From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jul 31 12:08: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 MAA04520 for ; Wed, 31 Jul 2002 12:08:25 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.006B5193@cherry.ease.lsoft.com>; Wed, 31 Jul 2002 12:08:56 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 157454 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 31 Jul 2002 12:08:55 -0400 Received: from 207.217.120.84 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 31 Jul 2002 12:08:55 -0400 Received: from user-2ivfi3p.dialup.mindspring.com ([165.247.200.121] helo=earthlink.net) by gull.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17Zw1s-00067P-00 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 31 Jul 2002 09:08:53 -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: <20020730.125317.27309274.yasu@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3D480E3C.CAB8929D@earthlink.net> Date: Wed, 31 Jul 2002 09:20:12 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Link Flap Damping To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, My questions are in two directions, dampening and congestion. Has anybody even read, looked, executed Moy's OSPF implimentation? Moy's optimatization applies to neighbor conversations. If you dampen a link coming up with a hello packet on that link, then it won't be seen depending on the amount of time the link is dampened. Thus, his optimation could be wasted in my opinion. But my 2nd thought has to due with congestion and that a percentage of these neighbor conversations becoming adjacencies. By speeding up to the 2-way state, if a number of hellos are recieved, then Moy's implimentation will send out immediate hellos. This may be okay for a couple of hellos recvd at once, but if the router becomes the DR or BDR, then a number of adjs will try to be formed and lead to the adj congestion limits. Mitchell Erblich =========================== Yasuhiro Ohara wrote: > > Hi Manral, Erblichs, Acee: > > Forgive me to reply by this all-in-one message for some of previous > e-mails. > > First, I have some prerequisions about this discussion. I guess we all > want to decrease Hello-Interval and Dead-Interval to make convergence > more faster, is this right ? I don't think Hello-Interval should be 10 > seconds because that's too long. And I am so impatient that I cannot > wait for 40 seconds for my communication being revived each time the > network topology changes. > > If we keep this in mind things may be changed bellow. > > VishwasM> Hi Yasu, > VishwasM> > VishwasM> If both ends of a link do have a link damping feature what > VishwasM> problem would it still not solve. The hellos would not be > VishwasM> causing any flap if the lower layer itself has taken care > VishwasM> that the flap, because it would not convey a link up event > VishwasM> till the link showed no failure for some time(as in RPR > VishwasM> example below). > > What would it be done with the Hellos going through the link which is > down but kept from notifying the upper layer ? It is obviously not > good for L2 switches to keep this traffic in its own buffer and > re-send it. (I believe all of the L2 flap dampening technology won't > do this.) > > So, hellos may be dropped anyway whether L2 dampening feature is on or > not (off). > > VishwasM> Yes, for congestion case something may be required. We have > VishwasM> put that down in our draft congestion-control draft. > > Yes, I've read the draft and it'll be very effective where hello/dead > are 10/40s (or similar). But none of this will solve the problem > essentially. > > - Throttle setup of adjacency > I guess prioritizing the adjacencies is the most bothering thing > for network operators. The future world enforcing this to be > involved is not attractive ... > - DSCP marking of hello/ack > This is for congestion and can do nothing with link down. > - Use other control packets than hello as detect link live-ness > This is also mainly for congestion I guess. > Frequency of other control packets than hello is another critical > issue for OSPF scalability and should be decreased. But in the > other hand (ideally) the dead interval may not be so long to > wait these kind of "OSPF update" to occur. Hence we should think > we can use only the hellos to detect link flaps. > > # By the way, though the draft inform me a lot of valuable things, > # I could not understand one part of it. 4.1.2's end paragraph says: > # "Maintaining sequence number counters for different packet types > # may solve this issue" but what is the sequence number and how a > # implementation take care the packet reordering ? > > erblichs> Has anyone seen or invisioned an interaction with "link flap > erblichs> dampening" and Moy's OSPF implimentation where he attempts > erblichs> to accelerate bi-directional status? Chapt 1, p.2 1.1.1 > erblichs> Optimizations > erblichs> > erblichs> Basicly, can a damped link on one side prevent this > erblichs> acceleration to occur? > erblichs> > erblichs> And should this accelerated method bunch the load on a > erblichs> router and thus counter-intuitive to congestion control? > erblichs> Especially with a set of routers all coming up at the same > erblichs> time and then the bunching of adjacency formations. > > Could you explain more detail about this ? I understood this as a > feature to simply make the adjacency to come up faster, and nothing > has to do with the flap dampening. > > acee> Normally, it is the link up event that is dampened at layer 2 > acee> and it is normally done in a such a way that the OSPF hello > acee> packets will not be received or will be dropped at a low level. > > OK, so I feel I can't admit L2's link flap dampening more and more. > > If the link up event is dropped and does not come up during the link > physically flaps until someone take care of the link's problem, and if > the link is the only one to reach a place (this is usual case), the > place will be unreach very long time. I guess it's not acceptable. > > Today we implicitly dampen the flaps by keeping the hello/dead > interval long (like 10/40s). The result of this dampened link while > flaps is *UP*, realizing "Best effort" Internet policy because some > packet may reach still through the flapping link. > > Are we really change this thing ? Can someone easily drop being > unaware of how important the link's live-ness is, even partially ? > > VishwasM> Hi Manav, > VishwasM> > VishwasM> First, some good news. ;-) I hear IEEE is working on failure > VishwasM> notification for Ethernet. > VishwasM> > VishwasM> As I see link flap damping, it has nothing to do with the > VishwasM> other end but our own interface. So when we know that we are > VishwasM> consistently flapping, we can have some way to prevent it. I > VishwasM> guess all that you say, does not come into the picture at > VishwasM> all in that case. > VishwasM> > VishwasM> In OSPF because we have a 3-way handshake hello mechanism, > VishwasM> the link would not come up, and be used for routing table > VishwasM> calculation, if either end damped it. > > No, I don't think so. > > In usual case below: > > [sw1]-[sw2]-[sw3] > | | > R1 R2 > > If L2 switch [sw2] or the link connected to it flaps, R1 and R2 would > not be able to recognize the flaps even if there's some conversation > about the link's (L2) information above [sw1], [sw2] and [sw3]. > There are still possibilities of dropping Hellos. If the hello/dead > intervals are so short, the frequency of OSPF calculation will be > MinLSInterval (5sec). The network where the route changes each 5 secs > are not acceptable. > > Yes, we have one major conflict in OSPF routing: > "Converge fast but don't let a link flap". > > VishwasM> We can, for precaution sake do flap damping at OSPF > VishwasM> layer. Ways to do it could be: - > VishwasM> > VishwasM> http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0108&L=OSPF&P=R7962&I=-3 > VishwasM> > VishwasM> and > VishwasM> > VishwasM> we could actually advertize the link metric with value > VishwasM> 0xffff for such links. So in case there is no other path to > VishwasM> a destination the link can still be used. > > That's very similar to what I am looking for ;p) > > But how did you recognize the flap ? All I want to know is this. > How did you distinct the flap from the link completely down, when > dead-interval have elapsed without receiving Hello ? How immediately > could you recover the link's availability when the link's flaps > vanished ? > > It is worth writing I-D for experimental/informational use, even > though I admit it's an implementation issue. > > VishwasM> We could probably have more opinions on this. Alex/John ?? > > Really waiting for your reply. > > regards ! > yasu From owner-ospf@DISCUSS.MICROSOFT.COM Wed Jul 31 13:22: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 NAA08579 for ; Wed, 31 Jul 2002 13:22:33 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.006B51EA@cherry.ease.lsoft.com>; Wed, 31 Jul 2002 13:23:39 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 157833 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 31 Jul 2002 13:23:39 -0400 Received: from 203.178.142.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 31 Jul 2002 13:23:39 -0400 Received: from localhost (page.sfc.wide.ad.jp [203.178.143.89]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id F31855D11A; Thu, 1 Aug 2002 02:23:37 +0900 (JST) References: <20020730.125317.27309274.yasu@sfc.wide.ad.jp> <3D480E3C.CAB8929D@earthlink.net> 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: <20020801.021542.96167823.yasu@sfc.wide.ad.jp> Date: Thu, 1 Aug 2002 02:15:42 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: Link Flap Damping Comments: To: erblichs@EARTHLINK.NET To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3D480E3C.CAB8929D@earthlink.net> Precedence: list Content-Transfer-Encoding: 7bit Hi erblichs, None of us are trying to dampen Hello packets itself. So the dampening feature will be nothing to do with the Moy's optimization. About the congestion from simultaneous adjacencies bringing up, I guess and hope dampening feature touches nothing (it does neither solve the problem nor aggravate the problem). The techniques described in congestion-control draft will be used for it. regards, yasu erblichs> Group, erblichs> erblichs> My questions are in two directions, dampening erblichs> and congestion. erblichs> erblichs> erblichs> Has anybody even read, looked, executed Moy's OSPF erblichs> implimentation? erblichs> Moy's optimatization applies to neighbor conversations. erblichs> erblichs> If you dampen a link coming up with a hello packet erblichs> on that link, then it won't be seen depending on the erblichs> amount of time the link is dampened. Thus, his optimation erblichs> could be wasted in my opinion. erblichs> erblichs> But my 2nd thought has to due with congestion and that erblichs> a percentage of these neighbor conversations becoming erblichs> adjacencies. erblichs> erblichs> By speeding up to the 2-way state, if a number of hellos erblichs> are recieved, then Moy's implimentation will send out erblichs> immediate hellos. erblichs> erblichs> This may be okay for a couple of hellos erblichs> recvd at once, but if the router becomes the DR or BDR, erblichs> then a number of adjs will try to be formed and lead erblichs> to the adj congestion limits. erblichs> erblichs> Mitchell Erblich erblichs> ===========================