From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 1 12:50:25 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03613 for ; Tue, 1 Apr 2003 12:50:25 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.0095B407@cherry.ease.lsoft.com>; Tue, 1 Apr 2003 12:52:32 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 707738 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 1 Apr 2003 12:52:31 -0500 Received: from 64.60.75.69 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 1 Apr 2003 12:52:31 -0500 Received: by racerx.ixiacom.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Apr 2003 09:52:30 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <15FDCE057B48784C80836803AE3598D5292F22@racerx.ixiacom.com> Date: Tue, 1 Apr 2003 09:52:28 -0800 Reply-To: Mailing List Sender: Mailing List From: Ankur Sheth Subject: OSPFv3 : Referenced LS Type for Intra-Area-Prefix LSA To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Section 3.4.3.7 of RFC 2740 (Page 32-35) states that the value to be used for Referenced LS Type is 0x2001 when it is a Router LSA reference and 0x2002 when it is a Network LSA reference. However Section A.4.9 of the same RFC (Page 71-73) states "...If Referenced LS type is 1, the prefixes are associated with a router-LSA, ..... If Referenced LS type is 2, the prefixes are associated with a network-LSA....". My question is which is the correct one? I know of atleast 2 vendors who use 0x2001 and 0x2002. thanks, Ankur From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 1 13:11:14 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05596 for ; Tue, 1 Apr 2003 13:11:13 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0095B4AE@cherry.ease.lsoft.com>; Tue, 1 Apr 2003 13:13:39 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 707793 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 1 Apr 2003 13:13:39 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 1 Apr 2003 13:13:39 -0500 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id E729D456D4A for ; Tue, 1 Apr 2003 10:13:37 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <15FDCE057B48784C80836803AE3598D5292F22@racerx.ixiacom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E89D6F9.50406@redback.com> Date: Tue, 1 Apr 2003 13:14:17 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv3 : Referenced LS Type for Intra-Area-Prefix LSA To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Ankur Sheth wrote: > Section 3.4.3.7 of RFC 2740 (Page 32-35) states that the value to be used > for Referenced LS Type is 0x2001 when it is a Router LSA reference and > 0x2002 when it is a Network LSA reference. However Section A.4.9 of the > same RFC (Page 71-73) states "...If Referenced LS type is 1, the prefixes > are associated with a router-LSA, ..... If Referenced LS type is 2, the > prefixes are associated with a network-LSA....". > > My question is which is the correct one? I know of atleast 2 vendors who > use 0x2001 and 0x2002. Ankur, 0x2001 and 0x2002 are correct. Section A.4.9 has left out the flooding scope portion of the LSA type. I'm keeping track of these omissions (in case we ever re-issue RFC 2740 with update) and I will update the errata page with the RFC editor. > > thanks, > Ankur > Thanks, -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 2 03:17:30 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00367 for ; Wed, 2 Apr 2003 03:17:30 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.0095D209@cherry.ease.lsoft.com>; Wed, 2 Apr 2003 3:19:57 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 709494 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 2 Apr 2003 03:19:57 -0500 Received: from 207.217.120.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 2 Apr 2003 03:19:57 -0500 Received: from user-2ivfi7s.dialup.mindspring.com ([165.247.200.252] helo=earthlink.net) by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 190dTP-0007Zz-00 for ospf@discuss.microsoft.com; Wed, 02 Apr 2003 00:19:55 -0800 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: <3E8A9CE0.9F92015E@earthlink.net> Date: Wed, 2 Apr 2003 00:18:40 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: rfc1765 experimental : leaving overflowstate To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, I have a requirement to recover from the overlowstate condition. Excuse this question on the interpretation of "leaving overflowstate". In section 2.4 it states "when this timer fires, the router leaves OverlowState". This statement presumes that the ospfExitoverflowInterval is large enough as to allow updates to occur or for us to age LSAs out of our database that reduces our AS-externel-LSAs below ospfExtLsdbLimit. What happens if we still are over this limit when the timer fires? Shouldn't we reset the timer and not exit the state? Why wasn't this condition mentioned OR am I going blind OR what am I missing that gurantees that we must be under this Limit value after the timer fires? Secondly, if we can execute the timer multiple times before we are below the limit, it would make sense at least to me that the Intervals set at each router should not be multiples of each other. By setting the values to at least double-digit prime numbers should remove the requirement of intervals expiring simultaneously and thus the jitter requirement shouldn't be necessary. Mitchell Erblich Sr. Software Engineer From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 2 04:28:05 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01656 for ; Wed, 2 Apr 2003 04:28:05 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0095D118@cherry.ease.lsoft.com>; Wed, 2 Apr 2003 4:30:29 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 709621 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 2 Apr 2003 04:30:29 -0500 Received: from 129.188.136.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 2 Apr 2003 04:30:29 -0500 Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h329UT15017718 for ; Wed, 2 Apr 2003 02:30:29 -0700 (MST) Received: [from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id CAA14667 for ; Wed, 2 Apr 2003 02:30:00 -0700 (MST)] Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id <2D45B803>; Wed, 2 Apr 2003 04:30:23 -0500 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, 2 Apr 2003 04:32:03 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: rfc1765 experimental : leaving overflowstate To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Mitchell, Yes, if you are still in overloaded state after the timer expires, you should restart the timer and stay in the state. I think implied in the RFC, not sure if it is explictly stated. I guess every time jittering the timer value before restart helps, though any other methods like configuring different values would for sure help too. Thanks, Vishwas -----Original Message----- From: Erblichs [mailto:erblichs@EARTHLINK.NET] Sent: Wednesday, April 02, 2003 1:49 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: rfc1765 experimental : leaving overflowstate Group, I have a requirement to recover from the overlowstate condition. Excuse this question on the interpretation of "leaving overflowstate". In section 2.4 it states "when this timer fires, the router leaves OverlowState". This statement presumes that the ospfExitoverflowInterval is large enough as to allow updates to occur or for us to age LSAs out of our database that reduces our AS-externel-LSAs below ospfExtLsdbLimit. What happens if we still are over this limit when the timer fires? Shouldn't we reset the timer and not exit the state? Why wasn't this condition mentioned OR am I going blind OR what am I missing that gurantees that we must be under this Limit value after the timer fires? Secondly, if we can execute the timer multiple times before we are below the limit, it would make sense at least to me that the Intervals set at each router should not be multiples of each other. By setting the values to at least double-digit prime numbers should remove the requirement of intervals expiring simultaneously and thus the jitter requirement shouldn't be necessary. Mitchell Erblich Sr. Software Engineer From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 2 04:34:11 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAB01777 for ; Wed, 2 Apr 2003 04:34:11 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.0095D1FA@cherry.ease.lsoft.com>; Wed, 2 Apr 2003 4:36:37 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 709645 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 2 Apr 2003 04:36:37 -0500 Received: from 203.199.83.248 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 2 Apr 2003 04:36:36 -0500 Received: (qmail 5842 invoked by uid 510); 2 Apr 2003 09:35:13 -0000 Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 02 apr 2003 09:35:13 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20030402093513.5841.qmail@webmail36.rediffmail.com> Date: Wed, 2 Apr 2003 09:35:13 -0000 Reply-To: Mailing List Sender: Mailing List From: arunsy Subject: Premature Ageing To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, I'm facing problem in LSA Premature Aging. Here's is description of the problem. I've two Routers R1 and R2 connected by a broadcast Link. R2 has few more neighbors connected through other interfaces. I configured an external Route in R1. Hence R1 is originating new External LSA (with initial sequence Number)and afterwards as I delete the external route, it's flushing the same by means of premature ageing. R2 sends LSA Ack back to R1. So R1 is deleting the LSA from LSDB. R2 inturn flushes the LSA by flooding out on other interfaces. Now if the External route is activated again, R1 generates a new LSA with initial seqence Number. But by the timer R2 receives the new LSA, it still has the Max Age LSA since it didn't receive Ack from the Neighbors. So R2 is discarding the new LSA as the Max Age LSA is regarded as the recent LSA (Since Sequence Numbers are same (Initial Sequence Number), Checksum is Same and the Old LSA is a MAX Age LSA). Logically to say new LSA should be recent. But as the Sequence Numbers being same, the Router with Max Age is regarded as the most recent. Can any body have other thoughts in resolving this? With Regards, ARunSY. _______________________________________________________________________ Odomos - the only mosquito protection outside 4 walls - Click here to know more! http://r.rediff.com/r?http://clients.rediff.com/odomos/Odomos.htm&&odomos&&wn From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 2 04:41:16 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01872 for ; Wed, 2 Apr 2003 04:41:15 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.0095D1AD@cherry.ease.lsoft.com>; Wed, 2 Apr 2003 4:43:41 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 709675 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 2 Apr 2003 04:43:42 -0500 Received: from 144.189.100.105 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 2 Apr 2003 04:43:41 -0500 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h329hBrg017346 for ; Wed, 2 Apr 2003 02:43:11 -0700 (MST) Received: [from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id CAA29893 for ; Wed, 2 Apr 2003 02:41:09 -0700 (MST)] Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id <2D45B9AH>; Wed, 2 Apr 2003 04:43:34 -0500 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, 2 Apr 2003 04:45:29 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Premature Ageing To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Arunsy, This conditon can very well occur and RFC2328 Section 13.4 has provision to deal with the issue. In this case when the originating router finds that the sefl-originated LSA received is more recent than the LSA it originated, it will increment the sequence number of its LSA, past the received LSA's sequence number. This way the new LSA is flooded in the domain. Thanks, Vishwas -----Original Message----- From: arunsy [mailto:arunsarat@REDIFFMAIL.COM] Sent: Wednesday, April 02, 2003 3:05 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Premature Ageing Hi, I'm facing problem in LSA Premature Aging. Here's is description of the problem. I've two Routers R1 and R2 connected by a broadcast Link. R2 has few more neighbors connected through other interfaces. I configured an external Route in R1. Hence R1 is originating new External LSA (with initial sequence Number)and afterwards as I delete the external route, it's flushing the same by means of premature ageing. R2 sends LSA Ack back to R1. So R1 is deleting the LSA from LSDB. R2 inturn flushes the LSA by flooding out on other interfaces. Now if the External route is activated again, R1 generates a new LSA with initial seqence Number. But by the timer R2 receives the new LSA, it still has the Max Age LSA since it didn't receive Ack from the Neighbors. So R2 is discarding the new LSA as the Max Age LSA is regarded as the recent LSA (Since Sequence Numbers are same (Initial Sequence Number), Checksum is Same and the Old LSA is a MAX Age LSA). Logically to say new LSA should be recent. But as the Sequence Numbers being same, the Router with Max Age is regarded as the most recent. Can any body have other thoughts in resolving this? With Regards, ARunSY. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 2 06:38:32 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04463 for ; Wed, 2 Apr 2003 06:38:32 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.0095D375@cherry.ease.lsoft.com>; Wed, 2 Apr 2003 6:40:58 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 710109 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 2 Apr 2003 06:40:58 -0500 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 2 Apr 2003 06:30:58 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04200; Wed, 2 Apr 2003 06:28:30 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200304021128.GAA04200@ietf.org> Date: Wed, 2 Apr 2003 06:28:29 -0500 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-scalability-03.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Prioritized Treatment of Specific OSPF Packets and Congestion Avoidance Author(s) : G. Choudhury et al. Filename : draft-ietf-ospf-scalability-03.txt Pages : 16 Date : 2003-4-1 This document proposes methods that are intended to improve the scalability and stability of large networks using OSPF protocol. The methods include processing OSPF Hellos and LSA Acknowledgements at a higher priority compared to other OSPF packets, and other congestion avoidance procedures. Simulation results in support of some of the proposals are given in the appendix sections. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-scalability-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-scalability-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-1154544.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-scalability-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-scalability-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-1154544.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 2 07:36:37 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07090 for ; Wed, 2 Apr 2003 07:36:36 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0095D3CB@cherry.ease.lsoft.com>; Wed, 2 Apr 2003 7:39:03 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 710262 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 2 Apr 2003 07:39:03 -0500 Received: from 203.199.83.246 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 2 Apr 2003 07:39:02 -0500 Received: (qmail 30530 invoked by uid 510); 2 Apr 2003 12:37:39 -0000 Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 02 apr 2003 12:37:39 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20030402123739.30529.qmail@webmail35.rediffmail.com> Date: Wed, 2 Apr 2003 12:37:39 -0000 Reply-To: Mailing List Sender: Mailing List From: arunsy Subject: Re: Premature Ageing To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Vishwas, Thanks for your reply. But in the scenario I described, there is no way that R1 could get the self originated LSA by floodig as R1 is DR for that Network. As per RFC 2328 13.3.(4) which says if the LSA is received from the DR, then there's no need to flood back on the received interface. I think then, sequence number can not be updated. Can this be possible? Thanks and Regards, ARunSY. On Wed, 02 Apr 2003 Manral, Vishwas wrote : >Hi Arunsy, > >This conditon can very well occur and RFC2328 Section 13.4 has >provision to >deal with the issue. > >In this case when the originating router finds that the >sefl-originated LSA >received is more recent than the LSA it originated, it will >increment the >sequence number of its LSA, past the received LSA's sequence >number. This >way the new LSA is flooded in the domain. > >Thanks, >Vishwas > >-----Original Message----- > From: arunsy [mailto:arunsarat@REDIFFMAIL.COM] >Sent: Wednesday, April 02, 2003 3:05 PM >To: OSPF@DISCUSS.MICROSOFT.COM >Subject: Premature Ageing > > >Hi, >I'm facing problem in LSA Premature Aging. Here's is >description >of the problem. > >I've two Routers R1 and R2 connected by a broadcast Link. R2 >has >few more neighbors connected through other interfaces. I >configured an external Route in R1. Hence R1 is originating new >External LSA (with initial sequence Number)and afterwards as I >delete the external route, it's flushing the same by means of >premature ageing. R2 sends LSA Ack back to R1. So R1 is >deleting >the LSA from LSDB. R2 inturn flushes the LSA by flooding out on >other interfaces. >Now if the External route is activated again, R1 generates a >new >LSA with initial seqence Number. But by the timer R2 receives >the >new LSA, it still has the Max Age LSA since it didn't receive >Ack > from the Neighbors. So R2 is discarding the new LSA as the >Max >Age LSA is regarded as the recent LSA (Since Sequence Numbers >are >same (Initial Sequence Number), Checksum is Same and the Old >LSA >is a MAX Age LSA). > >Logically to say new LSA should be recent. But as the Sequence >Numbers being same, the Router with Max Age is regarded as the >most recent. Can any body have other thoughts in resolving >this? > >With Regards, >ARunSY. _______________________________________________________________________ Odomos - the only mosquito protection outside 4 walls - Click here to know more! http://r.rediff.com/r?http://clients.rediff.com/odomos/Odomos.htm&&odomos&&wn From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 2 07:48:04 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07302 for ; Wed, 2 Apr 2003 07:48:04 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.0095D548@cherry.ease.lsoft.com>; Wed, 2 Apr 2003 7:50:31 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 710291 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 2 Apr 2003 07:50:31 -0500 Received: from 144.189.100.103 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 2 Apr 2003 07:50:30 -0500 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h32CnZmr029370 for ; Wed, 2 Apr 2003 05:49:36 -0700 (MST) Received: [from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id FAA18356 for ; Wed, 2 Apr 2003 05:50:29 -0700 (MST)] Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id <2D45B9GH>; Wed, 2 Apr 2003 07:50:23 -0500 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, 2 Apr 2003 07:52:19 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Premature Ageing To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Arunsy, I am not sure what you mean. But if R1 originates an LSA, but R2 has the same LSA but a newer version with it, it will flood the LSA on that adjacency. Mind you once the LSA is in the database you do not keep track of where you got the LSA from, so if from that very interface you get an older LSA later you send the LSa in ur database to it. Hope this helps out. Thanks, Vishwas -----Original Message----- From: arunsy [mailto:arunsarat@REDIFFMAIL.COM] Sent: Wednesday, April 02, 2003 6:08 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Premature Ageing Hi Vishwas, Thanks for your reply. But in the scenario I described, there is no way that R1 could get the self originated LSA by floodig as R1 is DR for that Network. As per RFC 2328 13.3.(4) which says if the LSA is received from the DR, then there's no need to flood back on the received interface. I think then, sequence number can not be updated. Can this be possible? Thanks and Regards, ARunSY. On Wed, 02 Apr 2003 Manral, Vishwas wrote : >Hi Arunsy, > >This conditon can very well occur and RFC2328 Section 13.4 has >provision to >deal with the issue. > >In this case when the originating router finds that the >sefl-originated LSA >received is more recent than the LSA it originated, it will >increment the >sequence number of its LSA, past the received LSA's sequence >number. This >way the new LSA is flooded in the domain. > >Thanks, >Vishwas > >-----Original Message----- > From: arunsy [mailto:arunsarat@REDIFFMAIL.COM] >Sent: Wednesday, April 02, 2003 3:05 PM >To: OSPF@DISCUSS.MICROSOFT.COM >Subject: Premature Ageing > > >Hi, >I'm facing problem in LSA Premature Aging. Here's is >description >of the problem. > >I've two Routers R1 and R2 connected by a broadcast Link. R2 >has >few more neighbors connected through other interfaces. I >configured an external Route in R1. Hence R1 is originating new >External LSA (with initial sequence Number)and afterwards as I >delete the external route, it's flushing the same by means of >premature ageing. R2 sends LSA Ack back to R1. So R1 is >deleting >the LSA from LSDB. R2 inturn flushes the LSA by flooding out on >other interfaces. >Now if the External route is activated again, R1 generates a >new >LSA with initial seqence Number. But by the timer R2 receives >the >new LSA, it still has the Max Age LSA since it didn't receive >Ack > from the Neighbors. So R2 is discarding the new LSA as the >Max >Age LSA is regarded as the recent LSA (Since Sequence Numbers >are >same (Initial Sequence Number), Checksum is Same and the Old >LSA >is a MAX Age LSA). > >Logically to say new LSA should be recent. But as the Sequence >Numbers being same, the Router with Max Age is regarded as the >most recent. Can any body have other thoughts in resolving >this? > >With Regards, >ARunSY. _______________________________________________________________________ Odomos - the only mosquito protection outside 4 walls - Click here to know more! http://r.rediff.com/r?http://clients.rediff.com/odomos/Odomos.htm&&odomos&&w n From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 2 08:44:36 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09132 for ; Wed, 2 Apr 2003 08:44:36 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.0095D61A@cherry.ease.lsoft.com>; Wed, 2 Apr 2003 8:47:03 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 710434 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 2 Apr 2003 08:47:03 -0500 Received: from 192.128.166.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 2 Apr 2003 08:47:02 -0500 Received: from attrh3i.attrh.att.com ([135.71.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h32DkUil018622 for ; Wed, 2 Apr 2003 08:47:01 -0500 (EST) Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (6.5.032) id 3E85156000017317 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 2 Apr 2003 08:47:00 -0500 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: I-D ACTION:draft-ietf-ospf-scalability-03.txt Thread-Index: AcL5DMEmG+SeOnXiQ4qs4U/l7A2IGwAEGnqw Message-ID: <73656AE8EE4C9C4D9FFF9DBFEAE9A00F223BE8@KCCLUST06EVS1.ugd.att.com> Date: Wed, 2 Apr 2003 07:47:01 -0600 Reply-To: Mailing List Sender: Mailing List From: "Choudhury, Gagan L, ALABS" Subject: Re: I-D ACTION:draft-ietf-ospf-scalability-03.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA09132 Hi All, Here is a highlight of changes on the attached draft: 1. The draft is in the BCP track. 2. The length of the title is significantly reduced. 3. "Explicit Marking" of OSPF packets is not advocated in the main body of the draft. A short discussion on that is included in Appendix C. The title is also changed to reflect that fact. 4. Discussions on the simulation study and detailed discussion on the causes for generation of LSA storm and its impact are moved to the appendix. 5. Now the main body of the draft is short and mainly concentrates on implementation. Also, all proposals are made fairly explicit. Whenever a parameter is involved in a proposal, an example value is also given. 6. Two proposals are included based on "implicit congestion detection", i.e., without requiring any changes in protocol bits on the wire. The first one is an exponential backoff of the LSA retransmission interval based on the number of times a particular LSA has to be retransmitted. The second one is throttling the rate of sending LSAs towards a node if the number of unacknowledged LSAs from that node exceeds a threshold. Another proposal is also included on limiting the maximum number of adjacencies to be brought up simultaneously. Gagan Choudhury -----Original Message----- From: Internet-Drafts@IETF.ORG [mailto:Internet-Drafts@IETF.ORG] Sent: Wednesday, April 02, 2003 6:28 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: I-D ACTION:draft-ietf-ospf-scalability-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Prioritized Treatment of Specific OSPF Packets and Congestion Avoidance Author(s) : G. Choudhury et al. Filename : draft-ietf-ospf-scalability-03.txt Pages : 16 Date : 2003-4-1 This document proposes methods that are intended to improve the scalability and stability of large networks using OSPF protocol. The methods include processing OSPF Hellos and LSA Acknowledgements at a higher priority compared to other OSPF packets, and other congestion avoidance procedures. Simulation results in support of some of the proposals are given in the appendix sections. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-scalability-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-scalability-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 2 11:27:39 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16094 for ; Wed, 2 Apr 2003 11:27:39 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0095DB56@cherry.ease.lsoft.com>; Wed, 2 Apr 2003 11:30:04 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 711037 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 2 Apr 2003 11:30:04 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 2 Apr 2003 11:30:04 -0500 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 1289DA46AA for ; Wed, 2 Apr 2003 08:30:03 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E8B1026.50404@redback.com> Date: Wed, 2 Apr 2003 11:30:30 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Microsoft Mailing List Contact To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Does anyone subscribed to this list work for Microsoft? I have been unable to reach a contact for administration of the list via ospf-request@microsoft.com or through the Web interface. Please contact me offline if you can provide a contact or have any suggestions. Dave Whipple set the list up originally but apparently he is no longer working for MS. Thanks, -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 2 15:30:35 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07937 for ; Wed, 2 Apr 2003 15:30:35 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0095E0DB@cherry.ease.lsoft.com>; Wed, 2 Apr 2003 15:31:31 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 712196 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 2 Apr 2003 15:31:30 -0500 Received: from 207.217.120.22 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 2 Apr 2003 15:31:30 -0500 Received: from user-38lc0l9.dialup.mindspring.com ([209.86.2.169] helo=earthlink.net) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 190otN-0004a4-00 for ospf@discuss.microsoft.com; Wed, 02 Apr 2003 12:31:29 -0800 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: <3E8B4877.EEA45457@earthlink.net> Date: Wed, 2 Apr 2003 12:30:47 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Internet Draft : OSPF Refresh and Flooding in Stable Topologies To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, Sorry, just a few items to ponder :) This document does not discuss the implications of a LSA being corrupted (LSA checksum failed) and then being discarded. Should we not do checksums on DNA LSAs? Can the router that is removing the failed checksum LSA flood a earlier instance of the LSA? This hoping that the LSA will be reflooded by the originator? Should it be stated here? Should it be stated that this knob is per interface? Should it be stated what happens if the knob is first to have normal flooding, then reduced flooding or vice versa, OR more simply stated the requirement to reflush the LSA that are having their DNA bit changed? What is the implication of changing the knob twice within the standard 5 secs of re-originating the same LSA? Should a DNA LSA be removed upon loss of an adj due to the dead router interval expiring? **What is the implication that during the initial flooding of the DNA LSA, that a temporary routing loop or a black hole existed? This could even be due to mis-router configuration? Now, after this temporary condition has cleared will some routers never get the LSA? In the past we could be assured that we would eventually see the LSA.... And lastly, should this document identify the procedure for removing its originated LSA before a orderly shutdown? Mitchell Erblich Sr Software Engineer ----------------------------------- From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 2 16:11:23 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09432 for ; Wed, 2 Apr 2003 16:11:22 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0095E395@cherry.ease.lsoft.com>; Wed, 2 Apr 2003 16:13:50 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 712276 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 2 Apr 2003 16:13:51 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 2 Apr 2003 16:13:50 -0500 Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h32LDnS73992; Wed, 2 Apr 2003 13:13:49 -0800 (PST) (envelope-from padma@juniper.net) Received: (from padma@localhost) by garnet.juniper.net (8.11.5/8.11.3) id h32LDnr81349; Wed, 2 Apr 2003 13:13:49 -0800 (PST) (envelope-from padma) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200304022113.h32LDnr81349@garnet.juniper.net> Date: Wed, 2 Apr 2003 13:13:49 -0800 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: Internet Draft : OSPF Refresh and Flooding in Stable Topologies To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E8B4877.EEA45457@earthlink.net> from "Erblichs" at Apr 02, 2003 12:30:47 PM Precedence: list Content-Transfer-Encoding: 7bit Mitchell, First let me state that this feature can only operate if all the routers have an understanding on how to handle DNA LSA per rfc 1793. > > Group, > > Sorry, just a few items to ponder :) > > This document does not discuss the implications of a LSA > being corrupted (LSA checksum failed) and then being > discarded. > > Should we not do checksums on DNA LSAs? > > Can the router that is removing the failed checksum LSA > flood a earlier instance of the LSA? This hoping that the > LSA will be reflooded by the originator? Should it be > stated here? I am not sure I understand your question. How does handling this case differ between a router implementing this draft and having a router implementing DC somewhere in your topology and emitting DNA LSAs? > > Should it be stated that this knob is per interface? This is stated in section 5. > > Should it be stated what happens if the knob is first to > have normal flooding, then reduced flooding or vice versa, > OR more simply stated the requirement to reflush the LSA > that are having their DNA bit changed? > Do you mean to state that turning off the feature should cause all the LSAs to be reflooded with the DNA bit clear ? This seemed obvious to me. But any ways, on the first refresh of the LSA on the originating router this will cause the LSA to be flooded with the new sequence number and DNA bit clear. > What is the implication of changing the knob twice within > the standard 5 secs of re-originating the same LSA? That would be implementation choice how to keep track of this. > > Should a DNA LSA be removed upon loss of an adj due to > the dead router interval expiring? This is part of rfc 1793 that when reachability to the router originating an LSA with DNA bit set is lost that LSA should be maxaged. > > **What is the implication that during the initial flooding of > the DNA LSA, that a temporary routing loop or a black hole > existed? This could even be due to mis-router configuration? > Now, after this temporary condition has cleared will some > routers never get the LSA? In the past we could be assured > that we would eventually see the LSA.... Any change in topology/configuration will result in LSA(s) being flooded so this will clear up. > > And lastly, should this document identify the procedure > for removing its originated LSA before a orderly shutdown? This is covered by the non-reachability rule. > > > Mitchell Erblich > Sr Software Engineer > ----------------------------------- > Padma From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 2 16:37:52 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10767 for ; Wed, 2 Apr 2003 16:37:52 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0095E3B5@cherry.ease.lsoft.com>; Wed, 2 Apr 2003 16:40:20 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 712332 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 2 Apr 2003 16:40:20 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 2 Apr 2003 16:40:20 -0500 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 0D65C62E102 for ; Wed, 2 Apr 2003 13:40:19 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <425CE0ADBE82F946AFBAE21AA54D4A8826FB8F@quark.jnpr.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E8B58DB.6070701@redback.com> Date: Wed, 2 Apr 2003 16:40:43 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: FW: Microsoft Mailing List Contact To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Some minor issues - will take it offline. David Whipple wrote: > Acee, > > That's correct, I do not work for MS any longer. Luckily, I am still a > subscriber...:-) > > I am currently in the process of moving the administration of the list > off MSFT paid for servers.. It's been a slow, painful process. Sorry > for any inconvenience... > > I honestly haven't been doing much admin wise, but what's up, is > something broken? > > Contact me directly or you can call me at 571-203-1833 also... > > Thanks. > David Whipple. > > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Wednesday, April 02, 2003 11:31 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Microsoft Mailing List Contact > > > Does anyone subscribed to this list work for Microsoft? I have > been unable to reach a contact for administration of the list > via ospf-request@microsoft.com or through the Web interface. Please > contact me offline if you can provide a contact or have any > suggestions. Dave Whipple set the list up originally but apparently > he is no longer working for MS. > > Thanks, > -- > Acee > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 2 16:39:28 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10868 for ; Wed, 2 Apr 2003 16:39:28 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.0095E5CD@cherry.ease.lsoft.com>; Wed, 2 Apr 2003 16:41:57 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 712320 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 2 Apr 2003 16:41:57 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 2 Apr 2003 16:31:57 -0500 Received: from quark.jnpr.net ([172.24.18.152]) by alpha.jnpr.net with Microsoft SMTPSVC(5.0.2195.5329); Wed, 2 Apr 2003 13:31:56 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Thread-Topic: Microsoft Mailing List Contact Thread-Index: AcL5NSBfu+2olE8kQJaJEYLyshQmZQAKXwVw X-OriginalArrivalTime: 02 Apr 2003 21:31:56.0388 (UTC) FILETIME=[4920A240:01C2F95F] Message-ID: <425CE0ADBE82F946AFBAE21AA54D4A8826FB8F@quark.jnpr.net> Date: Wed, 2 Apr 2003 13:31:56 -0800 Reply-To: Mailing List Sender: Mailing List From: David Whipple Subject: FW: Microsoft Mailing List Contact Comments: To: Acee Lindem To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA10868 Acee, That's correct, I do not work for MS any longer. Luckily, I am still a subscriber...:-) I am currently in the process of moving the administration of the list off MSFT paid for servers.. It's been a slow, painful process. Sorry for any inconvenience... I honestly haven't been doing much admin wise, but what's up, is something broken? Contact me directly or you can call me at 571-203-1833 also... Thanks. David Whipple. -----Original Message----- From: Acee Lindem [mailto:acee@REDBACK.COM] Sent: Wednesday, April 02, 2003 11:31 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Microsoft Mailing List Contact Does anyone subscribed to this list work for Microsoft? I have been unable to reach a contact for administration of the list via ospf-request@microsoft.com or through the Web interface. Please contact me offline if you can provide a contact or have any suggestions. Dave Whipple set the list up originally but apparently he is no longer working for MS. Thanks, -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 2 17:53:55 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13558 for ; Wed, 2 Apr 2003 17:53:55 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.0095E69C@cherry.ease.lsoft.com>; Wed, 2 Apr 2003 17:54:31 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 712586 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 2 Apr 2003 17:54:31 -0500 Received: from 207.217.120.50 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 2 Apr 2003 17:54:31 -0500 Received: from user-2ivfkbg.dialup.mindspring.com ([165.247.209.112] helo=earthlink.net) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 190r7l-0004j5-00 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 02 Apr 2003 14:54:29 -0800 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: <200304022113.h32LDnr81349@garnet.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E8B69F8.5D6DB9AD@earthlink.net> Date: Wed, 2 Apr 2003 14:53:44 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Internet Draft : OSPF Refresh and Flooding in Stable Topologies To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Padma Pillay-Esnault, Let me re-phrase the first question. 1) One of the most common methods that a stable OSPF router does is the periodic verification of the checksums of LSAs within its database. Upon checksum verifcation failure and removal, (router just removes the bad LSA and marks the memory location as suspect) then non-aynchronous flooding will not resubmit the removed LSA.... Note: With the draft that deals with the later re-Initial Database Synchronization work, we can get back the LSA if the adj hasn't also removed it. But not yet.. So, you then break the assumption that all routers within an area must have the same LSAs in their database????? You just forced us to take doown the interface if we have a DNA LSA on a non-DC configured interface and we fail a checksum? Right??? (Actually, identify the adj that submitted us the LSA, and remove him from the next hello, then...redo the Init DB Sync) *** Yes, This problem was not reported to me early on dealing with demand-circuits! I don't know why other people dont't see this. Maybe people have perfect memory or they just don't run the checksuming algorithm. The current solution is to restart the DC interface where the LSDB originated to restart the Initial Database Synchronization. Else, we wait for the asynchronous re-submit of the LSA. It depends on the time that we last saw the LSA instance. But now you are making it apply to all interfaces / adjs ... 2) Oops, section 5 does specify interfaces or globaly. 3) Let me state this one.. Reachability in the Demand Circuit is 1 hr, etc. Shouldn't your document state that reachability is based on Dead Router Interval? You reference a doc and take some things from it and leave this type of item "explicitly unstated". 4) Are you stating reflooding by the LSA orignator? What happens if the originator doesn't see the change? The orignator will not reflood the LSA... ` 5) The non-reachability rule for Demand-Circuit specifies 1 hr, but for normal routers specify dead-router interval? Which one should we follow? Shouldn't it explicitly be stated in the document? Remember, I stated an orderly shutdown. Why don't we reflood with MAX-AGE, to remove un-necessary LSAs? This is analgous to RIP's poisson reverse something... Mitchell Erblich Sr Software Engineer --------------------------- Padma Pillay-Esnault wrote: > > Mitchell, > > First let me state that this feature can only operate if > all the routers have an understanding on how to handle DNA > LSA per rfc 1793. > > > > > Group, > > > > Sorry, just a few items to ponder :) > > 1) > > This document does not discuss the implications of a LSA > > being corrupted (LSA checksum failed) and then being > > discarded. > > > > Should we not do checksums on DNA LSAs? > > > > Can the router that is removing the failed checksum LSA > > flood a earlier instance of the LSA? This hoping that the > > LSA will be reflooded by the originator? Should it be > > stated here? > > I am not sure I understand your question. > How does handling this case differ between a router implementing this > draft and having a router implementing DC somewhere in your topology > and emitting DNA LSAs? > 2) > > > > Should it be stated that this knob is per interface? > > This is stated in section 5. > > > > > Should it be stated what happens if the knob is first to > > have normal flooding, then reduced flooding or vice versa, > > OR more simply stated the requirement to reflush the LSA > > that are having their DNA bit changed? > > > Do you mean to state that turning off the feature should cause all > the LSAs to be reflooded with the DNA bit clear ? This seemed obvious > to me. But any ways, on the first refresh of the LSA on the originating > router this will cause the LSA to be flooded with the new sequence > number and DNA bit clear. > > > What is the implication of changing the knob twice within > > the standard 5 secs of re-originating the same LSA? > > That would be implementation choice how to keep track of this. > 3) > > > > Should a DNA LSA be removed upon loss of an adj due to > > the dead router interval expiring? > > This is part of rfc 1793 that when reachability to the router > originating an LSA with DNA bit set is lost that LSA should be maxaged. > 4) > > > > **What is the implication that during the initial flooding of > > the DNA LSA, that a temporary routing loop or a black hole > > existed? This could even be due to mis-router configuration? > > Now, after this temporary condition has cleared will some > > routers never get the LSA? In the past we could be assured > > that we would eventually see the LSA.... > > Any change in topology/configuration will result in LSA(s) being > flooded so this will clear up. > 5) > > > > And lastly, should this document identify the procedure > > for removing its originated LSA before a orderly shutdown? > > This is covered by the non-reachability rule. > > > > > > > Mitchell Erblich > > Sr Software Engineer > > ----------------------------------- > > > > Padma From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 2 18:26:30 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15494 for ; Wed, 2 Apr 2003 18:26:30 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.0095E792@cherry.ease.lsoft.com>; Wed, 2 Apr 2003 18:28:57 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 712663 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 2 Apr 2003 18:28:57 -0500 Received: from 207.217.120.74 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 2 Apr 2003 18:28:57 -0500 Received: from user-2ivfkbg.dialup.mindspring.com ([165.247.209.112] helo=earthlink.net) by falcon.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 190rf5-0002aE-00 for ospf@discuss.microsoft.com; Wed, 02 Apr 2003 15:28:55 -0800 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: <3E8B720A.3A980273@earthlink.net> Date: Wed, 2 Apr 2003 15:28:10 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Internet Draft : Prioritized Treatment of Specific OSPF Packets and Congestion Avoidance #1 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, Lets keep it simple.. A) 2) The Proposal (1b) Separate the hello packets into its own FIFO queue for later processing. Periodicly process hellos based on the hello interval and the number of nbrs on the interface. Upon recieving the event that informs that a adj may be down due to hellos, mark the number of hellos currently in the queue. Process all the hellos up to the mark and identify whether the event is cleared. If not, do normal processing that takes down the nbr, adj. This way hellos can be processed as "lower priority". (1c) Packet Pacing Due to the fact that packet congestion on a interface is based on packet spacing with interpacket gaps (ala Ethernet), dynamicly adjust the rate of outgoing packets based on multicast or unicast destination, the number of nbrs/adjs on the interface, and the bandwidth of the interface. The algorithm that determines spacing should have a defined rampup speed, and have a exponential slowdown if congestion is determined (tcp Van Jacobson's algorithm is a good start) (1c) Router capability and Congestion determination should be based on past round-trip times of known events with the nbr; ie, Initial Database Synchronization packets. These are just 3 of dozens of items that can be used to determine and adjust for increased load/scalability. Done.. :) Mitchell Erblich Sr Software Engineer From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 2 19:05:28 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18141 for ; Wed, 2 Apr 2003 19:05:28 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.0095E86D@cherry.ease.lsoft.com>; Wed, 2 Apr 2003 19:07:54 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 712780 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 2 Apr 2003 19:07:54 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 2 Apr 2003 19:07:54 -0500 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id D237656244A for ; Wed, 2 Apr 2003 16:07:40 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3E8B720A.3A980273@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E8B7B64.1030502@redback.com> Date: Wed, 2 Apr 2003 19:08:04 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Internet Draft : Prioritized Treatment of Specific OSPF Packets and Congestion Avoidance #1 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Mitchell, This draft has been in progress for some time. There is some concensus that many of the techniques are the right things to do to improve scalability (though possibly not all of them). Much of what you're proposing below is either new or dictates a specific implementation of the techniques in the draft. I don't think we want to add any of this to the BCP at this time. Thanks, Acee Erblichs wrote: > Group, > > Lets keep it simple.. > > A) 2) The Proposal > > (1b) Separate the hello packets into its own FIFO queue > for later processing. Periodicly process hellos > based on the hello interval and the number of > nbrs on the interface. > > Upon recieving the event that informs that a adj may > be down due to hellos, mark the number of hellos > currently in the queue. > > Process all the hellos up to the mark and identify > whether the event is cleared. If not, do normal > processing that takes down the nbr, adj. > > This way hellos can be processed as "lower priority". > > (1c) Packet Pacing > Due to the fact that packet congestion on a interface is > based on packet spacing with interpacket gaps (ala Ethernet), > dynamicly adjust the rate of outgoing packets based on > multicast or unicast destination, the number of nbrs/adjs > on the interface, and the bandwidth of the interface. > > The algorithm that determines spacing should have a defined > rampup speed, and have a exponential slowdown if congestion > is determined (tcp Van Jacobson's algorithm is a good start) > > (1c) Router capability and Congestion determination should > be based on past round-trip > times of known events with the nbr; ie, Initial Database > Synchronization packets. > > > These are just 3 of dozens of items that can be used to > determine and adjust for increased load/scalability. > > Done.. :) > > > Mitchell Erblich > Sr Software Engineer > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 2 19:30:44 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18800 for ; Wed, 2 Apr 2003 19:30:44 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0095EA74@cherry.ease.lsoft.com>; Wed, 2 Apr 2003 19:33:11 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 712828 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 2 Apr 2003 19:33:11 -0500 Received: from 207.217.120.232 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 2 Apr 2003 19:33:11 -0500 Received: from user-2ivfkbg.dialup.mindspring.com ([165.247.209.112] helo=earthlink.net) by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 190sfF-0005mL-00 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 02 Apr 2003 16:33:09 -0800 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: <3E8B720A.3A980273@earthlink.net> <3E8B7B64.1030502@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E8B8116.5321BB82@earthlink.net> Date: Wed, 2 Apr 2003 16:32:22 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Internet Draft : Prioritized Treatment of Specific OSPF Packetsand Congestion Avoidance #1 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Acee Lindem, That is interesting due to the fact that some of the items I am suggesting also have FCS related implimentations. Mitchell Erblich Sr Software Engineer ======================== Acee Lindem wrote: > > Mitchell, > > This draft has been in progress for some time. There is some > concensus that many of the techniques are the right things to > do to improve scalability (though possibly not all of them). > Much of what you're proposing below is either new or dictates > a specific implementation of the techniques in the draft. > I don't think we want to add any of this to the BCP at > this time. > > Thanks, > Acee > > Erblichs wrote: > > Group, > > > > Lets keep it simple.. > > > > A) 2) The Proposal > > > > (1b) Separate the hello packets into its own FIFO queue > > for later processing. Periodicly process hellos > > based on the hello interval and the number of > > nbrs on the interface. > > > > Upon recieving the event that informs that a adj may > > be down due to hellos, mark the number of hellos > > currently in the queue. > > > > Process all the hellos up to the mark and identify > > whether the event is cleared. If not, do normal > > processing that takes down the nbr, adj. > > > > This way hellos can be processed as "lower priority". > > > > (1c) Packet Pacing > > Due to the fact that packet congestion on a interface is > > based on packet spacing with interpacket gaps (ala Ethernet), > > dynamicly adjust the rate of outgoing packets based on > > multicast or unicast destination, the number of nbrs/adjs > > on the interface, and the bandwidth of the interface. > > > > The algorithm that determines spacing should have a defined > > rampup speed, and have a exponential slowdown if congestion > > is determined (tcp Van Jacobson's algorithm is a good start) > > > > (1c) Router capability and Congestion determination should > > be based on past round-trip > > times of known events with the nbr; ie, Initial Database > > Synchronization packets. > > > > > > These are just 3 of dozens of items that can be used to > > determine and adjust for increased load/scalability. > > > > Done.. :) > > > > > > Mitchell Erblich > > Sr Software Engineer > > > > -- > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 3 07:37:41 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17653 for ; Thu, 3 Apr 2003 07:37:40 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00960461@cherry.ease.lsoft.com>; Thu, 3 Apr 2003 7:40:07 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 714688 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Apr 2003 07:40:07 -0500 Received: from 203.199.83.32 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 3 Apr 2003 07:40:06 -0500 Received: (qmail 479 invoked by uid 510); 3 Apr 2003 12:39:12 -0000 Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 03 apr 2003 12:39:12 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20030403123912.478.qmail@webmail32.rediffmail.com> Date: Thu, 3 Apr 2003 12:39:12 -0000 Reply-To: Mailing List Sender: Mailing List From: Krishna Rao Subject: Re: I-D ACTION:draft-ietf-ospf-scalability-03.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, The proposal made to "throttle adjacencies" in the draft, won't affect convergence time ?? What's the criteria to decide which adjacency are to be formed and which ones to defer?? thanks, krishna On Wed, 02 Apr 2003 Choudhury, Gagan L, ALABS wrote : >Hi All, > Here is a highlight of changes on the attached draft: > >1. The draft is in the BCP track. > >2. The length of the title is significantly reduced. > >3. "Explicit Marking" of OSPF packets is not advocated in the >main body of > the draft. A short discussion on that is included in >Appendix C. The title is > also changed to reflect that fact. > >4. Discussions on the simulation study and detailed discussion on >the causes for > generation of LSA storm and its impact are moved to the >appendix. > >5. Now the main body of the draft is short and mainly >concentrates on implementation. > Also, all proposals are made fairly explicit. > Whenever a parameter is involved in a proposal, an example >value is also given. > >6. Two proposals are included based on "implicit congestion >detection", i.e., > without requiring any changes in protocol bits on the wire. >The first one is > an exponential backoff of the LSA retransmission interval >based > on the number of times a particular LSA has to be >retransmitted. The > second one is throttling the rate of sending LSAs towards a >node if the > number of unacknowledged LSAs from that node exceeds a >threshold. Another > proposal is also included on limiting the maximum number of >adjacencies > to be brought up simultaneously. > > Gagan Choudhury > >-----Original Message----- > From: Internet-Drafts@IETF.ORG >[mailto:Internet-Drafts@IETF.ORG] >Sent: Wednesday, April 02, 2003 6:28 AM >To: OSPF@DISCUSS.MICROSOFT.COM >Subject: I-D ACTION:draft-ietf-ospf-scalability-03.txt > > >A New Internet-Draft is available from the on-line >Internet-Drafts directories. >This draft is a work item of the Open Shortest Path First IGP >Working Group of the IETF. > > Title : Prioritized Treatment of Specific OSPF >Packets and > Congestion Avoidance > Author(s) : G. Choudhury et al. > Filename : draft-ietf-ospf-scalability-03.txt > Pages : 16 > Date : 2003-4-1 > >This document proposes methods that are intended to improve the >scalability and stability of large networks using OSPF >protocol. >The methods include processing OSPF Hellos and LSA >Acknowledgements >at a higher priority compared to other OSPF packets, and other >congestion avoidance procedures. Simulation results in support >of >some of the proposals are given in the appendix sections. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-03.txt > >To remove yourself from the IETF Announcement list, send a >message to >ietf-announce-request with the word unsubscribe in the body of >the message. > >Internet-Drafts are also available by anonymous FTP. Login with >the username >"anonymous" and a password of your e-mail address. After logging >in, >type "cd internet-drafts" and then > "get draft-ietf-ospf-scalability-03.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE >/internet-drafts/draft-ietf-ospf-scalability-03.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use >this > feature, insert the command "ENCODING mime" before the >"FILE" > command. To decode the response(s), you will need >"munpack" or > a MIME-compliant mail reader. Different MIME-compliant >mail readers > exhibit different behavior, especially when dealing >with > "multipart" MIME messages (i.e. documents which have >been split > up into multiple messages), so check your local >documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail >reader >implementation to automatically retrieve the ASCII version of >the >Internet-Draft. _______________________________________________________________________ Odomos - the only mosquito protection outside 4 walls - Click here to know more! http://r.rediff.com/r?http://clients.rediff.com/odomos/Odomos.htm&&odomos&&wn From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 3 09:29:53 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21101 for ; Thu, 3 Apr 2003 09:29:53 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.0096068F@cherry.ease.lsoft.com>; Thu, 3 Apr 2003 9:32:20 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 714893 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Apr 2003 09:32:20 -0500 Received: from 32.97.110.132 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 3 Apr 2003 09:32:20 -0500 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e34.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h33EWJA9040152 for ; Thu, 3 Apr 2003 09:32:19 -0500 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h33EWIZ9219914 for ; Thu, 3 Apr 2003 07:32:18 -0700 X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0 [IBM]|December 16, 2002) at 04/03/2003 07:32:18 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Message-ID: Date: Thu, 3 Apr 2003 09:32:16 -0500 Reply-To: Mailing List Sender: Mailing List From: Mike Fox Subject: Re: Internet Draft : Prioritized Treatment of Specific OSPF Packets and Congestion Avoidance #1 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list I know I am coming a little late to this conversation, having only recently joined the mailing list. But I did want to mention that we have had good success with increasing the priority of hello packets. I do think that two of the suggestions may be mutually exclusive: increasing priority of hello packets and resetting inactivity timer on any packet from a neighbor. If hello packets are higher priority and the neighbor actually did go down, do you really want to delay learning about the neighbor outage while you work through a backlog of lower-priority packets from that neighbor? Mike From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 3 09:41:15 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21534 for ; Thu, 3 Apr 2003 09:41:14 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00960736@cherry.ease.lsoft.com>; Thu, 3 Apr 2003 9:43:42 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 714935 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Apr 2003 09:43:43 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 3 Apr 2003 09:43:42 -0500 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 6262883D962 for ; Thu, 3 Apr 2003 06:43:41 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E8C48AC.6040708@redback.com> Date: Thu, 3 Apr 2003 09:43:56 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Internet Draft : Prioritized Treatment of Specific OSPF Packets and Congestion Avoidance #1 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Mike Fox wrote: > I know I am coming a little late to this conversation, having only recently > joined the mailing list. But I did want to mention that we have had good > success with increasing the priority of hello packets. > > I do think that two of the suggestions may be mutually exclusive: > increasing priority of hello packets and resetting inactivity timer on any > packet from a neighbor. If hello packets are higher priority and the > neighbor actually did go down, do you really want to delay learning about > the neighbor outage while you work through a backlog of lower-priority > packets from that neighbor? My feeling is that prioritization is a much more effective mechanism. On a broadcast networks you may receive packets sent to a multicast address and this is no indication of whether or not the sending OSPF router has maintained state with you. > > Mike > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 3 10:45:17 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25890 for ; Thu, 3 Apr 2003 10:45:16 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00960A7A@cherry.ease.lsoft.com>; Thu, 3 Apr 2003 10:47:33 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 715213 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Apr 2003 10:47:33 -0500 Received: from 32.97.110.133 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 3 Apr 2003 10:47:33 -0500 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e35.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h33FlVs5039452 for ; Thu, 3 Apr 2003 10:47:32 -0500 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h33FlUZ9023000 for ; Thu, 3 Apr 2003 08:47:31 -0700 X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0 [IBM]|December 16, 2002) at 04/03/2003 08:47:30 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Message-ID: Date: Thu, 3 Apr 2003 10:47:29 -0500 Reply-To: Mailing List Sender: Mailing List From: Mike Fox Subject: Interaction of ICMPv6 Router Advertisement and OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Just wanted to follow up on the thread I started earlier this week on how a hybrid host/router would treat Router Advertisement routes. I realize that my initial query was not completely clear and we may have some terminology and assumption mismatches, so here is the summary of the design that I have tenatively adopted based on mailing list discussions and discussions with some router people. One thing that I may not have made clear in the previous thread that I was only referring to the logic for an interface on which OSPFv3 is running. In this case, we have decided that all on-link prefixes for this interface will be considered OSPF internal, whether learned via ICMPv6 Router Advertisements or link-LSAs, or both. Rationale: for link-LSAs the rationale is obvious -- it's an OSPF internal advertisement after all. If OSPFv3 is running on a link, a link-LSA should be sent by a router for all on-link prefixes anyway, so the case in which an ICMPv6 Router Advertisement is received for an on-link prefix but not a link-LSA should be rare -- it should only happen when there is a router on the link which is not running OSPFv3. In that case, we decided that all prefixes that are on-link to an OSPF link should still be considered OSPF internal for a couple of reasons. First, that's how we do it in IPv4. I know it isn't exactly analogous, but the subnet of an IPv4 OSPF interface is considered internal to OSPF. Another reason is because a prefix learned via ICMPv6 Router Advertisement may be used for stateless autconfiguration, resulting in a home address for the interface. All home addresses on an OSPFv3 interface are internal to the OSPFv3 automous system. It didn't seem to make sense to have a host address that is internal to the autonomous system, but the prefix that it is part of is not. As an aside, for interfaces on which OSPFv3 is NOT running, all home addresses and on-link prefixes will be considered external to the OSPF autnomous system, regardless of how they are learned. Their importation will be controlled by the "import direct routes" knob. Mike From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 3 10:46:05 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25970 for ; Thu, 3 Apr 2003 10:46:05 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.0096098B@cherry.ease.lsoft.com>; Thu, 3 Apr 2003 10:48:34 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 715234 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Apr 2003 10:48:34 -0500 Received: from 129.188.136.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 3 Apr 2003 10:48:34 -0500 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h33FmXYE029717 for ; Thu, 3 Apr 2003 08:48:33 -0700 (MST) Received: [from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id IAA08590 for ; Thu, 3 Apr 2003 08:46:00 -0700 (MST)] Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id <2D45CBAG>; Thu, 3 Apr 2003 10:48:26 -0500 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, 3 Apr 2003 10:50:22 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Internet Draft : Prioritized Treatment of Specific OSPF Pack ets and Congestion Avoidance #1 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Mike, Let me try to answer your question. I do not think the two suggestions are exclusive. We give priority to hellos and yet we reset the inactivity timer whenever we get a packet from a neighbor including hellos(I dont know how they are mutually exclusive). We do not stop sending hellos if we have sent a packet in that hello interval already. The point is that hello not only conveys the neighbor reachabiltiy information but also fields like DR/BDR etc which can be of use(unlike in BGP keepalives I guess). Let me know if you agree? Thanks, Vishwas -----Original Message----- From: Mike Fox [mailto:mjfox@US.IBM.COM] Sent: Thursday, April 03, 2003 8:02 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Internet Draft : Prioritized Treatment of Specific OSPF Packets and Congestion Avoidance #1 I know I am coming a little late to this conversation, having only recently joined the mailing list. But I did want to mention that we have had good success with increasing the priority of hello packets. I do think that two of the suggestions may be mutually exclusive: increasing priority of hello packets and resetting inactivity timer on any packet from a neighbor. If hello packets are higher priority and the neighbor actually did go down, do you really want to delay learning about the neighbor outage while you work through a backlog of lower-priority packets from that neighbor? Mike From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 3 10:57:26 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26653 for ; Thu, 3 Apr 2003 10:57:26 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00960B08@cherry.ease.lsoft.com>; Thu, 3 Apr 2003 10:59:54 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 715265 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Apr 2003 10:59:54 -0500 Received: from 192.128.166.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 3 Apr 2003 10:59:54 -0500 Received: from attrh3i.attrh.att.com ([135.71.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h33FxZii008561 for ; Thu, 3 Apr 2003 10:59:35 -0500 (EST) Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (6.5.032) id 3E851560000213BF for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Apr 2003 10:59:34 -0500 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: I-D ACTION:draft-ietf-ospf-scalability-03.txt Thread-Index: AcL53ixNU8of7FcARGGoNWiDrTKvyQAGputA Message-ID: <73656AE8EE4C9C4D9FFF9DBFEAE9A00F09E89F@KCCLUST06EVS1.ugd.att.com> Date: Thu, 3 Apr 2003 09:59:04 -0600 Reply-To: Mailing List Sender: Mailing List From: "Choudhury, Gagan L, ALABS" Subject: Re: I-D ACTION:draft-ietf-ospf-scalability-03.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA26653 Krishna, Throttling adjacencies does reduce congestion but as you point out it may also increase convergence time. However, the number of adjacencies being brought up, "n" is an adjustable parameter. If it is felt that the routers are very fast and faster convergence is the main objective then "n" may be made large. On the other hand if the main objective is to reduce congestion during the simultaneous database synchronization process then a smaller value of "n" may be used. Regarding which adjacencies to bring up in which order, a priority list may be used. Gagan -----Original Message----- From: Krishna Rao [mailto:ospf_query@REDIFFMAIL.COM] Sent: Thursday, April 03, 2003 7:39 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: I-D ACTION:draft-ietf-ospf-scalability-03.txt Hi, The proposal made to "throttle adjacencies" in the draft, won't affect convergence time ?? What's the criteria to decide which adjacency are to be formed and which ones to defer?? thanks, krishna On Wed, 02 Apr 2003 Choudhury, Gagan L, ALABS wrote : >Hi All, > Here is a highlight of changes on the attached draft: > >1. The draft is in the BCP track. > >2. The length of the title is significantly reduced. > >3. "Explicit Marking" of OSPF packets is not advocated in the >main body of > the draft. A short discussion on that is included in >Appendix C. The title is > also changed to reflect that fact. > >4. Discussions on the simulation study and detailed discussion on >the causes for > generation of LSA storm and its impact are moved to the >appendix. > >5. Now the main body of the draft is short and mainly >concentrates on implementation. > Also, all proposals are made fairly explicit. > Whenever a parameter is involved in a proposal, an example >value is also given. > >6. Two proposals are included based on "implicit congestion >detection", i.e., > without requiring any changes in protocol bits on the wire. >The first one is > an exponential backoff of the LSA retransmission interval >based > on the number of times a particular LSA has to be >retransmitted. The > second one is throttling the rate of sending LSAs towards a >node if the > number of unacknowledged LSAs from that node exceeds a >threshold. Another > proposal is also included on limiting the maximum number of >adjacencies > to be brought up simultaneously. > > Gagan Choudhury > >-----Original Message----- > From: Internet-Drafts@IETF.ORG >[mailto:Internet-Drafts@IETF.ORG] >Sent: Wednesday, April 02, 2003 6:28 AM >To: OSPF@DISCUSS.MICROSOFT.COM >Subject: I-D ACTION:draft-ietf-ospf-scalability-03.txt > > >A New Internet-Draft is available from the on-line >Internet-Drafts directories. >This draft is a work item of the Open Shortest Path First IGP >Working Group of the IETF. > > Title : Prioritized Treatment of Specific OSPF >Packets and > Congestion Avoidance > Author(s) : G. Choudhury et al. > Filename : draft-ietf-ospf-scalability-03.txt > Pages : 16 > Date : 2003-4-1 > >This document proposes methods that are intended to improve the >scalability and stability of large networks using OSPF >protocol. >The methods include processing OSPF Hellos and LSA >Acknowledgements >at a higher priority compared to other OSPF packets, and other >congestion avoidance procedures. Simulation results in support >of >some of the proposals are given in the appendix sections. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-03.txt > >To remove yourself from the IETF Announcement list, send a >message to >ietf-announce-request with the word unsubscribe in the body of >the message. > >Internet-Drafts are also available by anonymous FTP. Login with >the username >"anonymous" and a password of your e-mail address. After logging >in, >type "cd internet-drafts" and then > "get draft-ietf-ospf-scalability-03.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE >/internet-drafts/draft-ietf-ospf-scalability-03.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use >this > feature, insert the command "ENCODING mime" before the >"FILE" > command. To decode the response(s), you will need >"munpack" or > a MIME-compliant mail reader. Different MIME-compliant >mail readers > exhibit different behavior, especially when dealing >with > "multipart" MIME messages (i.e. documents which have >been split > up into multiple messages), so check your local >documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail >reader >implementation to automatically retrieve the ASCII version of >the >Internet-Draft. _______________________________________________________________________ Odomos - the only mosquito protection outside 4 walls - Click here to know more! http://r.rediff.com/r?http://clients.rediff.com/odomos/Odomos.htm&&odomos&&wn From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 3 10:59:19 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26737 for ; Thu, 3 Apr 2003 10:59:19 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.009609D0@cherry.ease.lsoft.com>; Thu, 3 Apr 2003 11:01:37 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 715286 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Apr 2003 11:01:37 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 3 Apr 2003 11:01:37 -0500 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 41B57224183 for ; Thu, 3 Apr 2003 08:01:36 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E8C5AEE.5010302@redback.com> Date: Thu, 3 Apr 2003 11:01:50 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Interaction of ICMPv6 Router Advertisement and OSPFv3 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Mike, Sounds like a reasonable host implementation. Mike Fox wrote: > Just wanted to follow up on the thread I started earlier this week on how a > hybrid host/router would treat Router Advertisement routes. I realize that > my initial query was not completely clear and we may have some terminology > and assumption mismatches, so here is the summary of the design that I have > tenatively adopted based on mailing list discussions and discussions with > some router people. > > One thing that I may not have made clear in the previous thread that I was > only referring to the logic for an interface on which OSPFv3 is running. > In this case, we have decided that all on-link prefixes for this interface > will be considered OSPF internal, whether learned via ICMPv6 Router > Advertisements or link-LSAs, or both. > > Rationale: for link-LSAs the rationale is obvious -- it's an OSPF internal > advertisement after all. If OSPFv3 is running on a link, a link-LSA should > be sent by a router for all on-link prefixes anyway, so the case in which > an ICMPv6 Router Advertisement is received for an on-link prefix but not a > link-LSA should be rare -- it should only happen when there is a router on > the link which is not running OSPFv3. In that case, we decided that all > prefixes that are on-link to an OSPF link should still be considered OSPF > internal for a couple of reasons. First, that's how we do it in IPv4. I > know it isn't exactly analogous, but the subnet of an IPv4 OSPF interface > is considered internal to OSPF. Another reason is because a prefix learned > via ICMPv6 Router Advertisement may be used for stateless autconfiguration, > resulting in a home address for the interface. All home addresses on an > OSPFv3 interface are internal to the OSPFv3 automous system. It didn't > seem to make sense to have a host address that is internal to the > autonomous system, but the prefix that it is part of is not. > > As an aside, for interfaces on which OSPFv3 is NOT running, all home > addresses and on-link prefixes will be considered external to the OSPF > autnomous system, regardless of how they are learned. Their importation > will be controlled by the "import direct routes" knob. > > Mike > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 3 11:01:10 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26901 for ; Thu, 3 Apr 2003 11:01:10 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00960B28@cherry.ease.lsoft.com>; Thu, 3 Apr 2003 11:03:38 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 715319 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Apr 2003 11:03:38 -0500 Received: from 144.189.100.103 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 3 Apr 2003 11:03:38 -0500 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h33G2hRf025839 for ; Thu, 3 Apr 2003 09:02:44 -0700 (MST) Received: [from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id JAA16644 for ; Thu, 3 Apr 2003 09:03:36 -0700 (MST)] Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id <2D45CBC1>; Thu, 3 Apr 2003 11:03:30 -0500 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, 3 Apr 2003 11:05:25 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: I-D ACTION:draft-ietf-ospf-scalability-03.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Krishna, The draft aims at two things: - 1. Increase scalability 2. Prevent CPU overload The throttling adjacencies is done in case where the number of adjacencies comming up can actually cause a CPU overload. We have purposely left out the criteria(which could be implementaion specific), based on comments got on the list. You could check out the congestion-control draft we had out some time back, where(m not sure) we may have given some example criterias. Thanks, Vishwas -----Original Message----- From: Krishna Rao [mailto:ospf_query@REDIFFMAIL.COM] Sent: Thursday, April 03, 2003 6:09 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: I-D ACTION:draft-ietf-ospf-scalability-03.txt Hi, The proposal made to "throttle adjacencies" in the draft, won't affect convergence time ?? What's the criteria to decide which adjacency are to be formed and which ones to defer?? thanks, krishna On Wed, 02 Apr 2003 Choudhury, Gagan L, ALABS wrote : >Hi All, > Here is a highlight of changes on the attached draft: > >1. The draft is in the BCP track. > >2. The length of the title is significantly reduced. > >3. "Explicit Marking" of OSPF packets is not advocated in the >main body of > the draft. A short discussion on that is included in >Appendix C. The title is > also changed to reflect that fact. > >4. Discussions on the simulation study and detailed discussion on >the causes for > generation of LSA storm and its impact are moved to the >appendix. > >5. Now the main body of the draft is short and mainly >concentrates on implementation. > Also, all proposals are made fairly explicit. > Whenever a parameter is involved in a proposal, an example >value is also given. > >6. Two proposals are included based on "implicit congestion >detection", i.e., > without requiring any changes in protocol bits on the wire. >The first one is > an exponential backoff of the LSA retransmission interval >based > on the number of times a particular LSA has to be >retransmitted. The > second one is throttling the rate of sending LSAs towards a >node if the > number of unacknowledged LSAs from that node exceeds a >threshold. Another > proposal is also included on limiting the maximum number of >adjacencies > to be brought up simultaneously. > > Gagan Choudhury > >-----Original Message----- > From: Internet-Drafts@IETF.ORG >[mailto:Internet-Drafts@IETF.ORG] >Sent: Wednesday, April 02, 2003 6:28 AM >To: OSPF@DISCUSS.MICROSOFT.COM >Subject: I-D ACTION:draft-ietf-ospf-scalability-03.txt > > >A New Internet-Draft is available from the on-line >Internet-Drafts directories. >This draft is a work item of the Open Shortest Path First IGP >Working Group of the IETF. > > Title : Prioritized Treatment of Specific OSPF >Packets and > Congestion Avoidance > Author(s) : G. Choudhury et al. > Filename : draft-ietf-ospf-scalability-03.txt > Pages : 16 > Date : 2003-4-1 > >This document proposes methods that are intended to improve the >scalability and stability of large networks using OSPF >protocol. >The methods include processing OSPF Hellos and LSA >Acknowledgements >at a higher priority compared to other OSPF packets, and other >congestion avoidance procedures. Simulation results in support >of >some of the proposals are given in the appendix sections. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-03.txt > >To remove yourself from the IETF Announcement list, send a >message to >ietf-announce-request with the word unsubscribe in the body of >the message. > >Internet-Drafts are also available by anonymous FTP. Login with >the username >"anonymous" and a password of your e-mail address. After logging >in, >type "cd internet-drafts" and then > "get draft-ietf-ospf-scalability-03.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE >/internet-drafts/draft-ietf-ospf-scalability-03.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use >this > feature, insert the command "ENCODING mime" before the >"FILE" > command. To decode the response(s), you will need >"munpack" or > a MIME-compliant mail reader. Different MIME-compliant >mail readers > exhibit different behavior, especially when dealing >with > "multipart" MIME messages (i.e. documents which have >been split > up into multiple messages), so check your local >documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail >reader >implementation to automatically retrieve the ASCII version of >the >Internet-Draft. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 3 11:10:28 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27429 for ; Thu, 3 Apr 2003 11:10:28 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00960A99@cherry.ease.lsoft.com>; Thu, 3 Apr 2003 11:12:55 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 715348 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Apr 2003 11:12:55 -0500 Received: from 192.128.134.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 3 Apr 2003 11:12:55 -0500 Received: from attrh3i.attrh.att.com ([135.71.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h33GCiKN008942 for ; Thu, 3 Apr 2003 10:12:44 -0600 (CST) Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (6.5.032) id 3E8515600002168E for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Apr 2003 11:12:44 -0500 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: Internet Draft : Prioritized Treatment of Specific OSPF Pack ets and Congestion Avoidance #1 Thread-Index: AcL5+IE+70+t6qOwTUSLmMDopuqfVgAAU3HQ Message-ID: <73656AE8EE4C9C4D9FFF9DBFEAE9A00F223BED@KCCLUST06EVS1.ugd.att.com> Date: Thu, 3 Apr 2003 10:12:10 -0600 Reply-To: Mailing List Sender: Mailing List From: "Choudhury, Gagan L, ALABS" Subject: Re: Internet Draft : Prioritized Treatment of Specific OSPF Pack ets and Congestion Avoidance #1 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA27429 Hi Mike and Acee, Let me make one more point beyond what Vishwas said. Perhaps a point made by Mike and Acee is that prioritizing Hello is a good thing to do (ensures that an adjacency does not go down due to congestion) but if we already do it then why do we also need resetting inactivity timer on receiving any packet? Note that in Section 2 we say that "either all, or a subset of the proposals may be implemented by a router". So you do not have to reset inactivity timer on receiving any packet if you are already prioritizing Hello. Also, please keep in mind that there may be situations where specially identifying Hello and prioritizing it (at the receiver) may not be easy but it may be easier to reset inactivity timers on receiving any packet. Gagan -----Original Message----- From: Manral, Vishwas [mailto:VishwasM@NETPLANE.COM] Sent: Thursday, April 03, 2003 10:50 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Internet Draft : Prioritized Treatment of Specific OSPF Pack ets and Congestion Avoidance #1 Hi Mike, Let me try to answer your question. I do not think the two suggestions are exclusive. We give priority to hellos and yet we reset the inactivity timer whenever we get a packet from a neighbor including hellos(I dont know how they are mutually exclusive). We do not stop sending hellos if we have sent a packet in that hello interval already. The point is that hello not only conveys the neighbor reachabiltiy information but also fields like DR/BDR etc which can be of use(unlike in BGP keepalives I guess). Let me know if you agree? Thanks, Vishwas -----Original Message----- From: Mike Fox [mailto:mjfox@US.IBM.COM] Sent: Thursday, April 03, 2003 8:02 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Internet Draft : Prioritized Treatment of Specific OSPF Packets and Congestion Avoidance #1 I know I am coming a little late to this conversation, having only recently joined the mailing list. But I did want to mention that we have had good success with increasing the priority of hello packets. I do think that two of the suggestions may be mutually exclusive: increasing priority of hello packets and resetting inactivity timer on any packet from a neighbor. If hello packets are higher priority and the neighbor actually did go down, do you really want to delay learning about the neighbor outage while you work through a backlog of lower-priority packets from that neighbor? Mike From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 3 11:47:17 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29055 for ; Thu, 3 Apr 2003 11:47:16 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00960CE0@cherry.ease.lsoft.com>; Thu, 3 Apr 2003 11:49:44 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 715472 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Apr 2003 11:49:44 -0500 Received: from 129.188.136.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 3 Apr 2003 11:49:44 -0500 Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h33GnhYE021477 for ; Thu, 3 Apr 2003 09:49:43 -0700 (MST) Received: [from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id JAA12182 for ; Thu, 3 Apr 2003 09:49:11 -0700 (MST)] Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id <2D45CBG2>; Thu, 3 Apr 2003 11:49:37 -0500 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, 3 Apr 2003 11:51:15 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Internet Draft : OSPF Refresh and Flooding in Stable Topologi es To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Padma, Just a minor comment. It would be nice to put the configuration part in the appendix, as in other OSPF drafts. Besides putting the object names as well as default values if any, though I know it does look very obvious from the draft itself. Thanks, Vishwas -----Original Message----- From: Padma Pillay-Esnault [mailto:padma@JUNIPER.NET] Sent: Thursday, April 03, 2003 2:44 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Internet Draft : OSPF Refresh and Flooding in Stable Topologies Mitchell, First let me state that this feature can only operate if all the routers have an understanding on how to handle DNA LSA per rfc 1793. > > Group, > > Sorry, just a few items to ponder :) > > This document does not discuss the implications of a LSA > being corrupted (LSA checksum failed) and then being > discarded. > > Should we not do checksums on DNA LSAs? > > Can the router that is removing the failed checksum LSA > flood a earlier instance of the LSA? This hoping that the > LSA will be reflooded by the originator? Should it be > stated here? I am not sure I understand your question. How does handling this case differ between a router implementing this draft and having a router implementing DC somewhere in your topology and emitting DNA LSAs? > > Should it be stated that this knob is per interface? This is stated in section 5. > > Should it be stated what happens if the knob is first to > have normal flooding, then reduced flooding or vice versa, > OR more simply stated the requirement to reflush the LSA > that are having their DNA bit changed? > Do you mean to state that turning off the feature should cause all the LSAs to be reflooded with the DNA bit clear ? This seemed obvious to me. But any ways, on the first refresh of the LSA on the originating router this will cause the LSA to be flooded with the new sequence number and DNA bit clear. > What is the implication of changing the knob twice within > the standard 5 secs of re-originating the same LSA? That would be implementation choice how to keep track of this. > > Should a DNA LSA be removed upon loss of an adj due to > the dead router interval expiring? This is part of rfc 1793 that when reachability to the router originating an LSA with DNA bit set is lost that LSA should be maxaged. > > **What is the implication that during the initial flooding of > the DNA LSA, that a temporary routing loop or a black hole > existed? This could even be due to mis-router configuration? > Now, after this temporary condition has cleared will some > routers never get the LSA? In the past we could be assured > that we would eventually see the LSA.... Any change in topology/configuration will result in LSA(s) being flooded so this will clear up. > > And lastly, should this document identify the procedure > for removing its originated LSA before a orderly shutdown? This is covered by the non-reachability rule. > > > Mitchell Erblich > Sr Software Engineer > ----------------------------------- > Padma From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 3 12:02:29 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29801 for ; Thu, 3 Apr 2003 12:02:29 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00960D30@cherry.ease.lsoft.com>; Thu, 3 Apr 2003 12:04:56 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 715501 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Apr 2003 12:04:55 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 3 Apr 2003 12:04:54 -0500 Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h33H4rS44544; Thu, 3 Apr 2003 09:04:53 -0800 (PST) (envelope-from padma@juniper.net) Received: (from padma@localhost) by garnet.juniper.net (8.11.5/8.11.3) id h33H4rV84104; Thu, 3 Apr 2003 09:04:53 -0800 (PST) (envelope-from padma) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200304031704.h33H4rV84104@garnet.juniper.net> Date: Thu, 3 Apr 2003 09:04:53 -0800 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: Internet Draft : OSPF Refresh and Flooding in Stable Topologies To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E8B69F8.5D6DB9AD@earthlink.net> from "Erblichs" at Apr 02, 2003 02:53:44 PM Precedence: list Content-Transfer-Encoding: 7bit Mitchell Erblich, > > Padma Pillay-Esnault, > > Let me re-phrase the first question. > > 1) One of the most common methods that a > stable OSPF router does is the periodic > verification of the checksums of > LSAs within its database. > > Upon checksum verifcation failure and > removal, (router just removes the bad > LSA and marks the memory location as > suspect) then non-aynchronous flooding > will not resubmit the removed LSA.... > > Note: With the draft that deals with > the later re-Initial Database Synchronization > work, we can get back the LSA if the > adj hasn't also removed it. But not > yet.. What is this work ?? > > So, you then break the assumption that > all routers within an area must have the > same LSAs in their database????? No. The LSA contents are the same. > > You just forced us to > take doown the interface > if we have a DNA LSA on a non-DC configured > interface and we fail a checksum? Right??? > > (Actually, identify the adj that submitted > us the LSA, and remove him from the next > hello, then...redo the Init DB Sync) I usually don't force anyone ;-) ???- Are you referring to the work above ? > > > *** Yes, This problem was not reported to > me early on dealing with demand-circuits! > I don't know why other people dont't see > this. Maybe people have perfect memory or > they just don't run the checksuming algorithm. > The current solution is to restart the > DC interface where the LSDB originated to > restart the Initial Database Synchronization. > > Else, we wait for the asynchronous re-submit of > the LSA. It depends on the time that we last saw > the LSA instance. > > But now you are making it apply to all > interfaces / adjs ... > Let assume that what you say happens in a regular topology - an LSA gets corrupted and discarded then the SPF should run and this route and others including it in their SPF calculation should be discarded. Hence we will lose routes for at the maximum 30 minutes. I have not heard anyone complain about such a problem in normal. I believe that it is very rare if it indeeds happens. > > 2) Oops, section 5 does specify interfaces or > globaly. > > 3) Let me state this one.. Reachability in the > Demand Circuit is 1 hr, etc. Shouldn't your > document state that reachability is based > on Dead Router Interval? You reference a > doc and take some things from it and leave > this type of item "explicitly unstated". > Remember that this is *not* DC. We are not setting DC bit in the hellos or in the DBD packets. So it is Dead Interval. > 4) Are you stating reflooding by the LSA orignator? > What happens if the originator doesn't see > the change? The orignator will not reflood > the LSA... > If the originator doesn't see a change that should cause a change in contents in its LSA then there is a bug ;-) > > ` 5) The non-reachability rule for Demand-Circuit > specifies 1 hr, but for normal routers specify > dead-router interval? Which one should we > follow? Shouldn't it explicitly be stated in > the document? > See response 3. > Remember, I stated an orderly shutdown. Why > don't we reflood with MAX-AGE, to remove > un-necessary LSAs? This is analgous to RIP's > poisson reverse something... > This is an implementation decision. When you lose your adjacency, the LSA from the originating router will not be used in the spf anyway. Flooding MAXAGE LSA can be very expensive while the lingering LSAs will not be used in the SPF anyway. So, some believe it is useless. Padma > Mitchell Erblich > Sr Software Engineer > --------------------------- > > > Padma Pillay-Esnault wrote: > > > > Mitchell, > > > > First let me state that this feature can only operate if > > all the routers have an understanding on how to handle DNA > > LSA per rfc 1793. > > > > > > > > Group, > > > > > > Sorry, just a few items to ponder :) > > > > > 1) > > > This document does not discuss the implications of a LSA > > > being corrupted (LSA checksum failed) and then being > > > discarded. > > > > > > Should we not do checksums on DNA LSAs? > > > > > > Can the router that is removing the failed checksum LSA > > > flood a earlier instance of the LSA? This hoping that the > > > LSA will be reflooded by the originator? Should it be > > > stated here? > > > > I am not sure I understand your question. > > How does handling this case differ between a router implementing this > > draft and having a router implementing DC somewhere in your topology > > and emitting DNA LSAs? > > > 2) > > > > > > Should it be stated that this knob is per interface? > > > > This is stated in section 5. > > > > > > > > Should it be stated what happens if the knob is first to > > > have normal flooding, then reduced flooding or vice versa, > > > OR more simply stated the requirement to reflush the LSA > > > that are having their DNA bit changed? > > > > > Do you mean to state that turning off the feature should cause all > > the LSAs to be reflooded with the DNA bit clear ? This seemed obvious > > to me. But any ways, on the first refresh of the LSA on the originating > > router this will cause the LSA to be flooded with the new sequence > > number and DNA bit clear. > > > > > What is the implication of changing the knob twice within > > > the standard 5 secs of re-originating the same LSA? > > > > That would be implementation choice how to keep track of this. > > > 3) > > > > > > Should a DNA LSA be removed upon loss of an adj due to > > > the dead router interval expiring? > > > > This is part of rfc 1793 that when reachability to the router > > originating an LSA with DNA bit set is lost that LSA should be maxaged. > > > > 4) > > > > > > **What is the implication that during the initial flooding of > > > the DNA LSA, that a temporary routing loop or a black hole > > > existed? This could even be due to mis-router configuration? > > > Now, after this temporary condition has cleared will some > > > routers never get the LSA? In the past we could be assured > > > that we would eventually see the LSA.... > > > > Any change in topology/configuration will result in LSA(s) being > > flooded so this will clear up. > > > 5) > > > > > > And lastly, should this document identify the procedure > > > for removing its originated LSA before a orderly shutdown? > > > > This is covered by the non-reachability rule. > > > > > > > > > > > Mitchell Erblich > > > Sr Software Engineer > > > ----------------------------------- > > > > > > > Padma > From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 3 12:03:42 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29838 for ; Thu, 3 Apr 2003 12:03:42 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00960CD9@cherry.ease.lsoft.com>; Thu, 3 Apr 2003 12:06:11 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 715520 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Apr 2003 12:06:11 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 3 Apr 2003 12:06:11 -0500 Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h33H6AS44604; Thu, 3 Apr 2003 09:06:10 -0800 (PST) (envelope-from padma@juniper.net) Received: (from padma@localhost) by garnet.juniper.net (8.11.5/8.11.3) id h33H6AQ84428; Thu, 3 Apr 2003 09:06:10 -0800 (PST) (envelope-from padma) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200304031706.h33H6AQ84428@garnet.juniper.net> Date: Thu, 3 Apr 2003 09:06:10 -0800 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: Internet Draft : OSPF Refresh and Flooding in Stable Topologi es To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: from "Manral, Vishwas" at Apr 03, 2003 11:51:15 AM Precedence: list Content-Transfer-Encoding: 7bit Hi Vishwas > > Hi Padma, > > Just a minor comment. It would be nice to put the configuration part in the > appendix, as in other OSPF drafts. Besides putting the object names as well > as default values if any, though I know it does look very obvious from the > draft itself. I'll see to it. Thanks Padma > > Thanks, > Vishwas > > -----Original Message----- > From: Padma Pillay-Esnault [mailto:padma@JUNIPER.NET] > Sent: Thursday, April 03, 2003 2:44 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: Internet Draft : OSPF Refresh and Flooding in Stable > Topologies > > > Mitchell, > > First let me state that this feature can only operate if > all the routers have an understanding on how to handle DNA > LSA per rfc 1793. > > > > > Group, > > > > Sorry, just a few items to ponder :) > > > > This document does not discuss the implications of a LSA > > being corrupted (LSA checksum failed) and then being > > discarded. > > > > Should we not do checksums on DNA LSAs? > > > > Can the router that is removing the failed checksum LSA > > flood a earlier instance of the LSA? This hoping that the > > LSA will be reflooded by the originator? Should it be > > stated here? > > I am not sure I understand your question. > How does handling this case differ between a router implementing this > draft and having a router implementing DC somewhere in your topology > and emitting DNA LSAs? > > > > > Should it be stated that this knob is per interface? > > This is stated in section 5. > > > > > Should it be stated what happens if the knob is first to > > have normal flooding, then reduced flooding or vice versa, > > OR more simply stated the requirement to reflush the LSA > > that are having their DNA bit changed? > > > Do you mean to state that turning off the feature should cause all > the LSAs to be reflooded with the DNA bit clear ? This seemed obvious > to me. But any ways, on the first refresh of the LSA on the originating > router this will cause the LSA to be flooded with the new sequence > number and DNA bit clear. > > > What is the implication of changing the knob twice within > > the standard 5 secs of re-originating the same LSA? > > That would be implementation choice how to keep track of this. > > > > > Should a DNA LSA be removed upon loss of an adj due to > > the dead router interval expiring? > > This is part of rfc 1793 that when reachability to the router > originating an LSA with DNA bit set is lost that LSA should be maxaged. > > > > > **What is the implication that during the initial flooding of > > the DNA LSA, that a temporary routing loop or a black hole > > existed? This could even be due to mis-router configuration? > > Now, after this temporary condition has cleared will some > > routers never get the LSA? In the past we could be assured > > that we would eventually see the LSA.... > > Any change in topology/configuration will result in LSA(s) being > flooded so this will clear up. > > > > > And lastly, should this document identify the procedure > > for removing its originated LSA before a orderly shutdown? > > This is covered by the non-reachability rule. > > > > > > > Mitchell Erblich > > Sr Software Engineer > > ----------------------------------- > > > > Padma > From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 3 12:07:03 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00156 for ; Thu, 3 Apr 2003 12:07:03 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00960DC1@cherry.ease.lsoft.com>; Thu, 3 Apr 2003 12:09:32 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 715496 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Apr 2003 12:09:32 -0500 Received: from 63.94.127.69 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 3 Apr 2003 11:59:32 -0500 Received: from notepad.laurelnetworks.com (notepad.laurelnetworks.com [63.94.127.20]) by paperclip.laurelnetworks.com (Laurel/Laurel) with ESMTP id h33GxUt1004848 for ; Thu, 3 Apr 2003 11:59:30 -0500 Received: from laurelnetworks.com (goli-pc.dhcp.pit.laurelnetworks.com [10.0.17.215]) by notepad.laurelnetworks.com (Laurel/Laurel) with ESMTP id h33GxULU013320 for ; Thu, 3 Apr 2003 11:59:30 -0500 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E8C6872.1000900@laurelnetworks.com> Date: Thu, 3 Apr 2003 11:59:30 -0500 Reply-To: Mailing List Sender: Mailing List From: Srinivas Goli Subject: Re: I-D ACTION:draft-ietf-ospf-scalability-03.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Perhaps you should address the authentication related issues with prioritizing certain packets. For example if MD5 authentication is enabled the received packet's sequence numbers may be out of order. We should change this to expect different sequence numbers for high priority packets and low priority packets. Manral, Vishwas wrote: >Hi Krishna, > >The draft aims at two things: - > >1. Increase scalability >2. Prevent CPU overload > >The throttling adjacencies is done in case where the number of adjacencies >comming up can actually cause a CPU overload. We have purposely left out the >criteria(which could be implementaion specific), based on comments got on >the list. > >You could check out the congestion-control draft we had out some time back, >where(m not sure) we may have given some example criterias. > >Thanks, >Vishwas > >-----Original Message----- >From: Krishna Rao [mailto:ospf_query@REDIFFMAIL.COM] >Sent: Thursday, April 03, 2003 6:09 PM >To: OSPF@DISCUSS.MICROSOFT.COM >Subject: Re: I-D ACTION:draft-ietf-ospf-scalability-03.txt > > >Hi, >The proposal made to "throttle adjacencies" in the draft, >won't affect convergence time ?? >What's the criteria to decide which adjacency are >to be formed and which ones to defer?? > > >thanks, >krishna > > > >On Wed, 02 Apr 2003 Choudhury, Gagan L, ALABS wrote : > > >>Hi All, >> Here is a highlight of changes on the attached draft: >> >>1. The draft is in the BCP track. >> >>2. The length of the title is significantly reduced. >> >>3. "Explicit Marking" of OSPF packets is not advocated in the >>main body of >> the draft. A short discussion on that is included in >>Appendix C. The title is >> also changed to reflect that fact. >> >>4. Discussions on the simulation study and detailed discussion on >>the causes for >> generation of LSA storm and its impact are moved to the >>appendix. >> >>5. Now the main body of the draft is short and mainly >>concentrates on implementation. >> Also, all proposals are made fairly explicit. >> Whenever a parameter is involved in a proposal, an example >>value is also given. >> >>6. Two proposals are included based on "implicit congestion >>detection", i.e., >> without requiring any changes in protocol bits on the wire. >>The first one is >> an exponential backoff of the LSA retransmission interval >>based >> on the number of times a particular LSA has to be >>retransmitted. The >> second one is throttling the rate of sending LSAs towards a >>node if the >> number of unacknowledged LSAs from that node exceeds a >>threshold. Another >> proposal is also included on limiting the maximum number of >>adjacencies >> to be brought up simultaneously. >> >> Gagan Choudhury >> >>-----Original Message----- >>From: Internet-Drafts@IETF.ORG >>[mailto:Internet-Drafts@IETF.ORG] >>Sent: Wednesday, April 02, 2003 6:28 AM >>To: OSPF@DISCUSS.MICROSOFT.COM >>Subject: I-D ACTION:draft-ietf-ospf-scalability-03.txt >> >> >>A New Internet-Draft is available from the on-line >>Internet-Drafts directories. >>This draft is a work item of the Open Shortest Path First IGP >>Working Group of the IETF. >> >> Title : Prioritized Treatment of Specific OSPF >>Packets and >> Congestion Avoidance >> Author(s) : G. Choudhury et al. >> Filename : draft-ietf-ospf-scalability-03.txt >> Pages : 16 >> Date : 2003-4-1 >> >>This document proposes methods that are intended to improve the >>scalability and stability of large networks using OSPF >>protocol. >>The methods include processing OSPF Hellos and LSA >>Acknowledgements >>at a higher priority compared to other OSPF packets, and other >>congestion avoidance procedures. Simulation results in support >>of >>some of the proposals are given in the appendix sections. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-03.txt >> >>To remove yourself from the IETF Announcement list, send a >>message to >>ietf-announce-request with the word unsubscribe in the body of >>the message. >> >>Internet-Drafts are also available by anonymous FTP. Login with >>the username >>"anonymous" and a password of your e-mail address. After logging >>in, >>type "cd internet-drafts" and then >> "get draft-ietf-ospf-scalability-03.txt". >> >>A list of Internet-Drafts directories can be found in >>http://www.ietf.org/shadow.html >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >>Internet-Drafts can also be obtained by e-mail. >> >>Send a message to: >> mailserv@ietf.org. >>In the body type: >> "FILE >>/internet-drafts/draft-ietf-ospf-scalability-03.txt". >> >>NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use >>this >> feature, insert the command "ENCODING mime" before the >>"FILE" >> command. To decode the response(s), you will need >>"munpack" or >> a MIME-compliant mail reader. Different MIME-compliant >>mail readers >> exhibit different behavior, especially when dealing >>with >> "multipart" MIME messages (i.e. documents which have >>been split >> up into multiple messages), so check your local >>documentation on >> how to manipulate these messages. >> >> >>Below is the data which will enable a MIME compliant mail >>reader >>implementation to automatically retrieve the ASCII version of >>the >>Internet-Draft. >> >> -- -- Srinivas Laurel Networks Inc. sgoli@laurelnetworks.com (412)809-4268 From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 3 12:31:55 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02396 for ; Thu, 3 Apr 2003 12:31:55 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00960CF7@cherry.ease.lsoft.com>; Thu, 3 Apr 2003 12:34:22 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 715620 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Apr 2003 12:34:22 -0500 Received: from 129.188.136.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 3 Apr 2003 12:34:22 -0500 Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h33HYLYE007036 for ; Thu, 3 Apr 2003 10:34:22 -0700 (MST) Received: [from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id KAA06157 for ; Thu, 3 Apr 2003 10:33:49 -0700 (MST)] Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id <2D45CBKB>; Thu, 3 Apr 2003 12:34:14 -0500 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, 3 Apr 2003 12:36:07 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: I-D ACTION:draft-ietf-ospf-scalability-03.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Srinivas, We had added text in this regard in section 4.1.2. http://www.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control -00.txt If its agreed to by the working group, we can add similar text in the scalability draft. Thanks, Vishwas -----Original Message----- From: Srinivas Goli [mailto:goli@LAURELNETWORKS.COM] Sent: Thursday, April 03, 2003 10:30 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: I-D ACTION:draft-ietf-ospf-scalability-03.txt Perhaps you should address the authentication related issues with prioritizing certain packets. For example if MD5 authentication is enabled the received packet's sequence numbers may be out of order. We should change this to expect different sequence numbers for high priority packets and low priority packets. Manral, Vishwas wrote: >Hi Krishna, > >The draft aims at two things: - > >1. Increase scalability >2. Prevent CPU overload > >The throttling adjacencies is done in case where the number of adjacencies >comming up can actually cause a CPU overload. We have purposely left out the >criteria(which could be implementaion specific), based on comments got on >the list. > >You could check out the congestion-control draft we had out some time back, >where(m not sure) we may have given some example criterias. > >Thanks, >Vishwas > >-----Original Message----- >From: Krishna Rao [mailto:ospf_query@REDIFFMAIL.COM] >Sent: Thursday, April 03, 2003 6:09 PM >To: OSPF@DISCUSS.MICROSOFT.COM >Subject: Re: I-D ACTION:draft-ietf-ospf-scalability-03.txt > > >Hi, >The proposal made to "throttle adjacencies" in the draft, >won't affect convergence time ?? >What's the criteria to decide which adjacency are >to be formed and which ones to defer?? > > >thanks, >krishna > > > >On Wed, 02 Apr 2003 Choudhury, Gagan L, ALABS wrote : > > >>Hi All, >> Here is a highlight of changes on the attached draft: >> >>1. The draft is in the BCP track. >> >>2. The length of the title is significantly reduced. >> >>3. "Explicit Marking" of OSPF packets is not advocated in the >>main body of >> the draft. A short discussion on that is included in >>Appendix C. The title is >> also changed to reflect that fact. >> >>4. Discussions on the simulation study and detailed discussion on >>the causes for >> generation of LSA storm and its impact are moved to the >>appendix. >> >>5. Now the main body of the draft is short and mainly >>concentrates on implementation. >> Also, all proposals are made fairly explicit. >> Whenever a parameter is involved in a proposal, an example >>value is also given. >> >>6. Two proposals are included based on "implicit congestion >>detection", i.e., >> without requiring any changes in protocol bits on the wire. >>The first one is >> an exponential backoff of the LSA retransmission interval >>based >> on the number of times a particular LSA has to be >>retransmitted. The >> second one is throttling the rate of sending LSAs towards a >>node if the >> number of unacknowledged LSAs from that node exceeds a >>threshold. Another >> proposal is also included on limiting the maximum number of >>adjacencies >> to be brought up simultaneously. >> >> Gagan Choudhury >> >>-----Original Message----- >>From: Internet-Drafts@IETF.ORG >>[mailto:Internet-Drafts@IETF.ORG] >>Sent: Wednesday, April 02, 2003 6:28 AM >>To: OSPF@DISCUSS.MICROSOFT.COM >>Subject: I-D ACTION:draft-ietf-ospf-scalability-03.txt >> >> >>A New Internet-Draft is available from the on-line >>Internet-Drafts directories. >>This draft is a work item of the Open Shortest Path First IGP >>Working Group of the IETF. >> >> Title : Prioritized Treatment of Specific OSPF >>Packets and >> Congestion Avoidance >> Author(s) : G. Choudhury et al. >> Filename : draft-ietf-ospf-scalability-03.txt >> Pages : 16 >> Date : 2003-4-1 >> >>This document proposes methods that are intended to improve the >>scalability and stability of large networks using OSPF >>protocol. >>The methods include processing OSPF Hellos and LSA >>Acknowledgements >>at a higher priority compared to other OSPF packets, and other >>congestion avoidance procedures. Simulation results in support >>of >>some of the proposals are given in the appendix sections. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-03.txt >> >>To remove yourself from the IETF Announcement list, send a >>message to >>ietf-announce-request with the word unsubscribe in the body of >>the message. >> >>Internet-Drafts are also available by anonymous FTP. Login with >>the username >>"anonymous" and a password of your e-mail address. After logging >>in, >>type "cd internet-drafts" and then >> "get draft-ietf-ospf-scalability-03.txt". >> >>A list of Internet-Drafts directories can be found in >>http://www.ietf.org/shadow.html >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >>Internet-Drafts can also be obtained by e-mail. >> >>Send a message to: >> mailserv@ietf.org. >>In the body type: >> "FILE >>/internet-drafts/draft-ietf-ospf-scalability-03.txt". >> >>NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use >>this >> feature, insert the command "ENCODING mime" before the >>"FILE" >> command. To decode the response(s), you will need >>"munpack" or >> a MIME-compliant mail reader. Different MIME-compliant >>mail readers >> exhibit different behavior, especially when dealing >>with >> "multipart" MIME messages (i.e. documents which have >>been split >> up into multiple messages), so check your local >>documentation on >> how to manipulate these messages. >> >> >>Below is the data which will enable a MIME compliant mail >>reader >>implementation to automatically retrieve the ASCII version of >>the >>Internet-Draft. >> >> -- -- Srinivas Laurel Networks Inc. sgoli@laurelnetworks.com (412)809-4268 From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 3 12:37:29 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03154 for ; Thu, 3 Apr 2003 12:37:28 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00960E85@cherry.ease.lsoft.com>; Thu, 3 Apr 2003 12:39:54 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 715671 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Apr 2003 12:39:54 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 3 Apr 2003 12:39:54 -0500 Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h33HdrS47012 for ; Thu, 3 Apr 2003 09:39:53 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id h33Hdr926137; Thu, 3 Apr 2003 09:39:53 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) References: <73656AE8EE4C9C4D9FFF9DBFEAE9A00F223BED@KCCLUST06EVS1.ugd.att.com> Message-ID: <200304031739.h33Hdr926137@cirrus.juniper.net> Date: Thu, 3 Apr 2003 09:39:53 -0800 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: Internet Draft : Prioritized Treatment of Specific OSPF Pack ets and Congestion Avoidance #1 To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <73656AE8EE4C9C4D9FFF9DBFEAE9A00F223BED@KCCLUST06EVS1.ugd.att.com> (gchoudhury@ATT.COM) Precedence: list I think you're dancing around the bigger issue, which is that optimizations are highly dependent on the implementation in which they are applied (stop me if you've heard me rant on this before.) Some of the optimizations will be more helpful than others in some implementations. Trying to prioritize them or otherwise be too specific is akin to calculating angel density on pinheads. --Dave Hi Mike and Acee, Let me make one more point beyond what Vishwas said. Perhaps a point made by Mike and Acee is that prioritizing Hello is a good thing to do (ensures that an adjacency does not go down due to congestion) but if we already do it then why do we also need resetting inactivity timer on receiving any packet? Note that in Section 2 we say that "either all, or a subset of the proposals may be implemented by a router". So you do not have to reset inactivity timer on receiving any packet if you are already prioritizing Hello. Also, please keep in mind that there may be situations where specially identifying Hello and prioritizing it (at the receiver) may not be easy but it may be easier to reset inactivity timers on receiving any packet. Gagan From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 3 13:24:46 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05541 for ; Thu, 3 Apr 2003 13:24:46 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00961028@cherry.ease.lsoft.com>; Thu, 3 Apr 2003 13:27:13 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 715900 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Apr 2003 13:27:12 -0500 Received: from 207.217.120.50 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 3 Apr 2003 13:27:12 -0500 Received: from user-2ivfjqj.dialup.mindspring.com ([165.247.207.83] helo=earthlink.net) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1919Qc-0004SW-00 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 03 Apr 2003 10:27:10 -0800 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: <200304031704.h33H4rV84104@garnet.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E8C7CA8.BDCE3DC8@earthlink.net> Date: Thu, 3 Apr 2003 10:25:44 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Internet Draft : OSPF Refresh and Flooding in Stable Topologies To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Lets try inlining this time.. Mitchell Erblich Sr Software Engineer ---------- Padma Pillay-Esnault wrote: > > Mitchell Erblich, > > > > > Padma Pillay-Esnault, > > > > Let me re-phrase the first question. > > > > 1) One of the most common methods that a > > stable OSPF router does is the periodic > > verification of the checksums of > > LSAs within its database. > > > > Upon checksum verifcation failure and > > removal, (router just removes the bad > > LSA and marks the memory location as > > suspect) then non-aynchronous flooding > > will not resubmit the removed LSA.... > > > > Note: With the draft that deals with > > the later re-Initial Database Synchronization > > work, we can get back the LSA if the > > adj hasn't also removed it. But not > > yet.. > > What is this work ?? OSPF Out-of-band LSDB resynchronization by Alex Zinn and Abhay Roy Cisco, Feb 2001 And truly, I don't know what is happening with it??? > > > > > So, you then break the assumption that > > all routers within an area must have the > > same LSAs in their database????? > > No. The LSA contents are the same. > > > > > You just forced us to > > take doown the interface > > if we have a DNA LSA on a non-DC configured > > interface and we fail a checksum? Right??? > > > > (Actually, identify the adj that submitted > > us the LSA, and remove him from the next > > hello, then...redo the Init DB Sync) > > I usually don't force anyone ;-) > ???- Are you referring to the work above ? Yes... > > > > > > > *** Yes, This problem was not reported to > > me early on dealing with demand-circuits! > > I don't know why other people dont't see > > this. Maybe people have perfect memory or > > they just don't run the checksuming algorithm. > > The current solution is to restart the > > DC interface where the LSDB originated to > > restart the Initial Database Synchronization. > > > > Else, we wait for the asynchronous re-submit of > > the LSA. It depends on the time that we last saw > > the LSA instance. > > > > But now you are making it apply to all > > interfaces / adjs ... > > > Let assume that what you say happens in a regular topology - > an LSA gets corrupted and discarded then the SPF should run and > this route and others including it in their SPF calculation > should be discarded. Hence we will lose routes for at the maximum > 30 minutes. I have not heard anyone complain about such a problem > in normal. I believe that it is very rare if it indeeds happens. > Maybe implimentations are skipping the periodic checksum. The 30 minutes is assuming that asynchronous flooding will occur started at the originator. Your draft changes from 30 minutes to whenever the originator refloods the LSA if ever. So, a route can now be lost for an undeterminate amount of time, if you don't do anything. I don't think that is good. BTW, If our current dyanmic SPF wait interval (see Cisco's SPF Throttling Paper on their web site) which approximates this paper, (max of 600,000 ms) is less than the expected time of reflush of the removed LSA, we then wait for the reflood. > > > > 2) Oops, section 5 does specify interfaces or > > globaly. > > > > 3) Let me state this one.. Reachability in the > > Demand Circuit is 1 hr, etc. Shouldn't your > > document state that reachability is based > > on Dead Router Interval? You reference a > > doc and take some things from it and leave > > this type of item "explicitly unstated". > > > Remember that this is *not* DC. We are not setting DC bit > in the hellos or in the DBD packets. So it is Dead Interval. > Yes, but shouldn't you possibly want to state this in the RFC? > > 4) Are you stating reflooding by the LSA orignator? > > What happens if the originator doesn't see > > the change? The orignator will not reflood > > the LSA... > > > If the originator doesn't see a change that should cause a > change in contents in its LSA then there is a bug ;-) > > > > > ` 5) The non-reachability rule for Demand-Circuit > > specifies 1 hr, but for normal routers specify > > dead-router interval? Which one should we > > follow? Shouldn't it explicitly be stated in > > the document? > > > > See response 3. > > > Remember, I stated an orderly shutdown. Why > > don't we reflood with MAX-AGE, to remove > > un-necessary LSAs? This is analgous to RIP's > > poisson reverse something... > > > > This is an implementation decision. When you lose your adjacency, > the LSA from the originating router will not be used in the spf > anyway. Flooding MAXAGE LSA can be very expensive while the > lingering LSAs will not be used in the SPF anyway. So, some > believe it is useless. Well Moy does the former in his book and I agree with his decision. See the shutdown function. > > Padma > > > Mitchell Erblich > > Sr Software Engineer > > --------------------------- > > > > > > Padma Pillay-Esnault wrote: > > > > > > Mitchell, > > > > > > First let me state that this feature can only operate if > > > all the routers have an understanding on how to handle DNA > > > LSA per rfc 1793. > > > > > > > > > > > Group, > > > > > > > > Sorry, just a few items to ponder :) > > > > > > > > 1) > > > > This document does not discuss the implications of a LSA > > > > being corrupted (LSA checksum failed) and then being > > > > discarded. > > > > > > > > Should we not do checksums on DNA LSAs? > > > > > > > > Can the router that is removing the failed checksum LSA > > > > flood a earlier instance of the LSA? This hoping that the > > > > LSA will be reflooded by the originator? Should it be > > > > stated here? > > > > > > I am not sure I understand your question. > > > How does handling this case differ between a router implementing this > > > draft and having a router implementing DC somewhere in your topology > > > and emitting DNA LSAs? > > > > > 2) > > > > > > > > Should it be stated that this knob is per interface? > > > > > > This is stated in section 5. > > > > > > > > > > > Should it be stated what happens if the knob is first to > > > > have normal flooding, then reduced flooding or vice versa, > > > > OR more simply stated the requirement to reflush the LSA > > > > that are having their DNA bit changed? > > > > > > > Do you mean to state that turning off the feature should cause all > > > the LSAs to be reflooded with the DNA bit clear ? This seemed obvious > > > to me. But any ways, on the first refresh of the LSA on the originating > > > router this will cause the LSA to be flooded with the new sequence > > > number and DNA bit clear. > > > > > > > What is the implication of changing the knob twice within > > > > the standard 5 secs of re-originating the same LSA? > > > > > > That would be implementation choice how to keep track of this. > > > > > 3) > > > > > > > > Should a DNA LSA be removed upon loss of an adj due to > > > > the dead router interval expiring? > > > > > > This is part of rfc 1793 that when reachability to the router > > > originating an LSA with DNA bit set is lost that LSA should be maxaged. > > > > > > > 4) > > > > > > > > **What is the implication that during the initial flooding of > > > > the DNA LSA, that a temporary routing loop or a black hole > > > > existed? This could even be due to mis-router configuration? > > > > Now, after this temporary condition has cleared will some > > > > routers never get the LSA? In the past we could be assured > > > > that we would eventually see the LSA.... > > > > > > Any change in topology/configuration will result in LSA(s) being > > > flooded so this will clear up. > > > > > 5) > > > > > > > > And lastly, should this document identify the procedure > > > > for removing its originated LSA before a orderly shutdown? > > > > > > This is covered by the non-reachability rule. > > > > > > > > > > > > > > > Mitchell Erblich > > > > Sr Software Engineer > > > > ----------------------------------- > > > > > > > > > > Padma > > From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 3 13:48:13 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06659 for ; Thu, 3 Apr 2003 13:48:12 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00961046@cherry.ease.lsoft.com>; Thu, 3 Apr 2003 13:50:39 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 716042 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Apr 2003 13:50:39 -0500 Received: from 207.217.120.123 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 3 Apr 2003 13:50:39 -0500 Received: from user-2ivfjqj.dialup.mindspring.com ([165.247.207.83] helo=earthlink.net) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1919nJ-00023y-00 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 03 Apr 2003 10:50:37 -0800 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: <73656AE8EE4C9C4D9FFF9DBFEAE9A00F09E89F@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E8C8226.2CD7E268@earthlink.net> Date: Thu, 3 Apr 2003 10:49:10 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: I-D ACTION:draft-ietf-ospf-scalability-03.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, I agree partly. But when you throttle adjs are you throttling update packets between the adjs? Isn't the synchronization time between routers also based on the bandwidth and delay characteristics of the link. A high delay delay link should allow more simultaneous adj formations. And shouldn't the priority list be a FIFO and ordered with respect to the order of DBD packets recieved with the I bit set? Mitchell Erblich Sr Software Engineer ---------------------- "Choudhury, Gagan L, ALABS" wrote: > > Krishna, > Throttling adjacencies does reduce congestion but as you point out > it may also increase convergence time. However, the number of adjacencies > being brought up, "n" is an adjustable parameter. If it is felt that the > routers are very fast and faster convergence is the main objective then > "n" may be made large. On the other hand if the main objective is > to reduce congestion during the simultaneous database synchronization > process then a smaller value of "n" may be used. Regarding which adjacencies > to bring up in which order, a priority list may be used. > > Gagan > > -----Original Message----- > From: Krishna Rao [mailto:ospf_query@REDIFFMAIL.COM] > Sent: Thursday, April 03, 2003 7:39 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: I-D ACTION:draft-ietf-ospf-scalability-03.txt > > Hi, > The proposal made to "throttle adjacencies" in the draft, > won't affect convergence time ?? > What's the criteria to decide which adjacency are > to be formed and which ones to defer?? > > thanks, > krishna > > On Wed, 02 Apr 2003 Choudhury, Gagan L, ALABS wrote : > >Hi All, > > Here is a highlight of changes on the attached draft: > > > >1. The draft is in the BCP track. > > > >2. The length of the title is significantly reduced. > > > >3. "Explicit Marking" of OSPF packets is not advocated in the > >main body of > > the draft. A short discussion on that is included in > >Appendix C. The title is > > also changed to reflect that fact. > > > >4. Discussions on the simulation study and detailed discussion on > >the causes for > > generation of LSA storm and its impact are moved to the > >appendix. > > > >5. Now the main body of the draft is short and mainly > >concentrates on implementation. > > Also, all proposals are made fairly explicit. > > Whenever a parameter is involved in a proposal, an example > >value is also given. > > > >6. Two proposals are included based on "implicit congestion > >detection", i.e., > > without requiring any changes in protocol bits on the wire. > >The first one is > > an exponential backoff of the LSA retransmission interval > >based > > on the number of times a particular LSA has to be > >retransmitted. The > > second one is throttling the rate of sending LSAs towards a > >node if the > > number of unacknowledged LSAs from that node exceeds a > >threshold. Another > > proposal is also included on limiting the maximum number of > >adjacencies > > to be brought up simultaneously. > > > > Gagan Choudhury > > > >-----Original Message----- > > From: Internet-Drafts@IETF.ORG > >[mailto:Internet-Drafts@IETF.ORG] > >Sent: Wednesday, April 02, 2003 6:28 AM > >To: OSPF@DISCUSS.MICROSOFT.COM > >Subject: I-D ACTION:draft-ietf-ospf-scalability-03.txt > > > > > >A New Internet-Draft is available from the on-line > >Internet-Drafts directories. > >This draft is a work item of the Open Shortest Path First IGP > >Working Group of the IETF. > > > > Title : Prioritized Treatment of Specific OSPF > >Packets and > > Congestion Avoidance > > Author(s) : G. Choudhury et al. > > Filename : draft-ietf-ospf-scalability-03.txt > > Pages : 16 > > Date : 2003-4-1 > > > >This document proposes methods that are intended to improve the > >scalability and stability of large networks using OSPF > >protocol. > >The methods include processing OSPF Hellos and LSA > >Acknowledgements > >at a higher priority compared to other OSPF packets, and other > >congestion avoidance procedures. Simulation results in support > >of > >some of the proposals are given in the appendix sections. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-03.txt > > > >To remove yourself from the IETF Announcement list, send a > >message to > >ietf-announce-request with the word unsubscribe in the body of > >the message. > > > >Internet-Drafts are also available by anonymous FTP. Login with > >the username > >"anonymous" and a password of your e-mail address. After logging > >in, > >type "cd internet-drafts" and then > > "get draft-ietf-ospf-scalability-03.txt". > > > >A list of Internet-Drafts directories can be found in > >http://www.ietf.org/shadow.html > >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > >Internet-Drafts can also be obtained by e-mail. > > > >Send a message to: > > mailserv@ietf.org. > >In the body type: > > "FILE > >/internet-drafts/draft-ietf-ospf-scalability-03.txt". > > > >NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use > >this > > feature, insert the command "ENCODING mime" before the > >"FILE" > > command. To decode the response(s), you will need > >"munpack" or > > a MIME-compliant mail reader. Different MIME-compliant > >mail readers > > exhibit different behavior, especially when dealing > >with > > "multipart" MIME messages (i.e. documents which have > >been split > > up into multiple messages), so check your local > >documentation on > > how to manipulate these messages. > > > > > >Below is the data which will enable a MIME compliant mail > >reader > >implementation to automatically retrieve the ASCII version of > >the > >Internet-Draft. > > _______________________________________________________________________ > Odomos - the only mosquito protection outside 4 walls - > Click here to know more! > http://r.rediff.com/r?http://clients.rediff.com/odomos/Odomos.htm&&odomos&&wn From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 3 13:51:15 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06806 for ; Thu, 3 Apr 2003 13:51:14 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.009610F0@cherry.ease.lsoft.com>; Thu, 3 Apr 2003 13:53:42 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 716064 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Apr 2003 13:53:42 -0500 Received: from 207.217.120.123 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 3 Apr 2003 13:53:42 -0500 Received: from user-2ivfjqj.dialup.mindspring.com ([165.247.207.83] helo=earthlink.net) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1919qF-0007Dz-00 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 03 Apr 2003 10:53:40 -0800 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: <20030403123912.478.qmail@webmail32.rediffmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E8C82DD.D0A09AC2@earthlink.net> Date: Thu, 3 Apr 2003 10:52:13 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: I-D ACTION:draft-ietf-ospf-scalability-03.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Inline, Mitchell Erblich Sr Software Engineer ------------------------ Krishna Rao wrote: > > Hi, > The proposal made to "throttle adjacencies" in the draft, > won't affect convergence time ?? > What's the criteria to decide which adjacency are > to be formed and which ones to defer?? The order of rec'vd DBD packets with the I bit set. In my opinion. Mitchell Erblich Sr Software Engineer ---------------------- > > thanks, > krishna > > On Wed, 02 Apr 2003 Choudhury, Gagan L, ALABS wrote : > >Hi All, > > Here is a highlight of changes on the attached draft: > > > >1. The draft is in the BCP track. > > > >2. The length of the title is significantly reduced. > > > >3. "Explicit Marking" of OSPF packets is not advocated in the > >main body of > > the draft. A short discussion on that is included in > >Appendix C. The title is > > also changed to reflect that fact. > > > >4. Discussions on the simulation study and detailed discussion on > >the causes for > > generation of LSA storm and its impact are moved to the > >appendix. > > > >5. Now the main body of the draft is short and mainly > >concentrates on implementation. > > Also, all proposals are made fairly explicit. > > Whenever a parameter is involved in a proposal, an example > >value is also given. > > > >6. Two proposals are included based on "implicit congestion > >detection", i.e., > > without requiring any changes in protocol bits on the wire. > >The first one is > > an exponential backoff of the LSA retransmission interval > >based > > on the number of times a particular LSA has to be > >retransmitted. The > > second one is throttling the rate of sending LSAs towards a > >node if the > > number of unacknowledged LSAs from that node exceeds a > >threshold. Another > > proposal is also included on limiting the maximum number of > >adjacencies > > to be brought up simultaneously. > > > > Gagan Choudhury > > > >-----Original Message----- > > From: Internet-Drafts@IETF.ORG > >[mailto:Internet-Drafts@IETF.ORG] > >Sent: Wednesday, April 02, 2003 6:28 AM > >To: OSPF@DISCUSS.MICROSOFT.COM > >Subject: I-D ACTION:draft-ietf-ospf-scalability-03.txt > > > > > >A New Internet-Draft is available from the on-line > >Internet-Drafts directories. > >This draft is a work item of the Open Shortest Path First IGP > >Working Group of the IETF. > > > > Title : Prioritized Treatment of Specific OSPF > >Packets and > > Congestion Avoidance > > Author(s) : G. Choudhury et al. > > Filename : draft-ietf-ospf-scalability-03.txt > > Pages : 16 > > Date : 2003-4-1 > > > >This document proposes methods that are intended to improve the > >scalability and stability of large networks using OSPF > >protocol. > >The methods include processing OSPF Hellos and LSA > >Acknowledgements > >at a higher priority compared to other OSPF packets, and other > >congestion avoidance procedures. Simulation results in support > >of > >some of the proposals are given in the appendix sections. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-03.txt > > > >To remove yourself from the IETF Announcement list, send a > >message to > >ietf-announce-request with the word unsubscribe in the body of > >the message. > > > >Internet-Drafts are also available by anonymous FTP. Login with > >the username > >"anonymous" and a password of your e-mail address. After logging > >in, > >type "cd internet-drafts" and then > > "get draft-ietf-ospf-scalability-03.txt". > > > >A list of Internet-Drafts directories can be found in > >http://www.ietf.org/shadow.html > >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > >Internet-Drafts can also be obtained by e-mail. > > > >Send a message to: > > mailserv@ietf.org. > >In the body type: > > "FILE > >/internet-drafts/draft-ietf-ospf-scalability-03.txt". > > > >NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use > >this > > feature, insert the command "ENCODING mime" before the > >"FILE" > > command. To decode the response(s), you will need > >"munpack" or > > a MIME-compliant mail reader. Different MIME-compliant > >mail readers > > exhibit different behavior, especially when dealing > >with > > "multipart" MIME messages (i.e. documents which have > >been split > > up into multiple messages), so check your local > >documentation on > > how to manipulate these messages. > > > > > >Below is the data which will enable a MIME compliant mail > >reader > >implementation to automatically retrieve the ASCII version of > >the > >Internet-Draft. > > _______________________________________________________________________ > Odomos - the only mosquito protection outside 4 walls - > Click here to know more! > http://r.rediff.com/r?http://clients.rediff.com/odomos/Odomos.htm&&odomos&&wn From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 3 14:27:27 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08119 for ; Thu, 3 Apr 2003 14:27:27 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.009611A5@cherry.ease.lsoft.com>; Thu, 3 Apr 2003 14:27:45 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 716134 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Apr 2003 14:27:45 -0500 Received: from 207.217.120.49 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 3 Apr 2003 14:27:45 -0500 Received: from user-2ivfjqj.dialup.mindspring.com ([165.247.207.83] helo=earthlink.net) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 191AND-0004lQ-00 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 03 Apr 2003 11:27:44 -0800 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: <3E8B720A.3A980273@earthlink.net> <3E8B7B64.1030502@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E8C8ACB.EB56A65E@earthlink.net> Date: Thu, 3 Apr 2003 11:26:03 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Internet Draft : Prioritized Treatment of Specific OSPF Packetsand Congestion Avoidance #1 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Acee, What I am proposing is not really new... Some large companies even document what they do with OSPF outside of the RFC process. Second, if it has been in progress over so much time, why doesn't the group just make it a RFC and eliminate it as a draft! I will just re-cover (1a). I will assume that over 99.99% of the time, whatever people do is acceptable with handing the hello packets. Tbe draft specifies high priority hello packets and to do that already requires a separate queue for the hello packets. My exception basely generates a priority boost for the hellos and process them! I suggest routers to process these two queues in a weighted round-robin fashion based on my earlier criteria without prioritization. Mitchell Erblich Sr. Software Engineers ------------------ Acee Lindem wrote: > > Mitchell, > > This draft has been in progress for some time. There is some > concensus that many of the techniques are the right things to > do to improve scalability (though possibly not all of them). > Much of what you're proposing below is either new or dictates > a specific implementation of the techniques in the draft. > I don't think we want to add any of this to the BCP at > this time. > > Thanks, > Acee > > Erblichs wrote: > > Group, > > > > Lets keep it simple.. > > > > A) 2) The Proposal > > > > (1b) Separate the hello packets into its own FIFO queue > > for later processing. Periodicly process hellos > > based on the hello interval and the number of > > nbrs on the interface. > > > > Upon recieving the event that informs that a adj may > > be down due to hellos, mark the number of hellos > > currently in the queue. > > > > Process all the hellos up to the mark and identify > > whether the event is cleared. If not, do normal > > processing that takes down the nbr, adj. > > > > This way hellos can be processed as "lower priority". > > > > (1c) Packet Pacing > > Due to the fact that packet congestion on a interface is > > based on packet spacing with interpacket gaps (ala Ethernet), > > dynamicly adjust the rate of outgoing packets based on > > multicast or unicast destination, the number of nbrs/adjs > > on the interface, and the bandwidth of the interface. > > > > The algorithm that determines spacing should have a defined > > rampup speed, and have a exponential slowdown if congestion > > is determined (tcp Van Jacobson's algorithm is a good start) > > > > (1c) Router capability and Congestion determination should > > be based on past round-trip > > times of known events with the nbr; ie, Initial Database > > Synchronization packets. > > > > > > These are just 3 of dozens of items that can be used to > > determine and adjust for increased load/scalability. > > > > Done.. :) > > > > > > Mitchell Erblich > > Sr Software Engineer > > > > -- > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 3 14:34:28 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08511 for ; Thu, 3 Apr 2003 14:34:28 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.0096125D@cherry.ease.lsoft.com>; Thu, 3 Apr 2003 14:36:56 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 716158 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Apr 2003 14:36:56 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 3 Apr 2003 14:36:55 -0500 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 5D4604542CA for ; Thu, 3 Apr 2003 11:36:54 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3E8B720A.3A980273@earthlink.net> <3E8B7B64.1030502@redback.com> <3E8C8ACB.EB56A65E@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E8C8D63.2070003@redback.com> Date: Thu, 3 Apr 2003 14:37:07 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Internet Draft : Prioritized Treatment of Specific OSPF Packetsand Congestion Avoidance #1 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Mitchell, In your original E-mail, I took more of an issue with your 1c) comments. I don't believe using TCP like congestion and backoff mechanisms to adjust OSPF flooding and retransmissions rates is the right thing to do. IMHO, it makes no sense to measure rtt over a single link. As for your packets queuing comments 1b), I don't believe that the specific queuing implementation should be specified. Thanks, Acee P.S. How do your comments 1b) and 1c) map to the proposals in section 2 of the draft? In the future can you use the same numbering as the draft you are commenting on? Erblichs wrote: > Acee, > > What I am proposing is not really new... > Some large companies even document what > they do with OSPF outside of the RFC process. > > Second, if it has been in progress over > so much time, why doesn't the group just > make it a RFC and eliminate it as a draft! > > I will just re-cover (1a). I will assume that > over 99.99% of the time, whatever people do is > acceptable with handing the hello packets. > > Tbe draft specifies high priority hello packets > and to do that already requires a separate queue > for the hello packets. My exception basely > generates a priority boost for the hellos and > process them! > > I suggest routers to process these two queues > in a weighted round-robin fashion based on > my earlier criteria without prioritization. > > Mitchell Erblich > Sr. Software Engineers > ------------------ > > Acee Lindem wrote: > >>Mitchell, >> >>This draft has been in progress for some time. There is some >>concensus that many of the techniques are the right things to >>do to improve scalability (though possibly not all of them). >>Much of what you're proposing below is either new or dictates >>a specific implementation of the techniques in the draft. >>I don't think we want to add any of this to the BCP at >>this time. >> >>Thanks, >>Acee >> >>Erblichs wrote: >> >>>Group, >>> >>> Lets keep it simple.. >>> >>> A) 2) The Proposal >>> >>> (1b) Separate the hello packets into its own FIFO queue >>> for later processing. Periodicly process hellos >>> based on the hello interval and the number of >>> nbrs on the interface. >>> >>> Upon recieving the event that informs that a adj may >>> be down due to hellos, mark the number of hellos >>> currently in the queue. >>> >>> Process all the hellos up to the mark and identify >>> whether the event is cleared. If not, do normal >>> processing that takes down the nbr, adj. >>> >>> This way hellos can be processed as "lower priority". >>> >>> (1c) Packet Pacing >>> Due to the fact that packet congestion on a interface is >>> based on packet spacing with interpacket gaps (ala Ethernet), >>> dynamicly adjust the rate of outgoing packets based on >>> multicast or unicast destination, the number of nbrs/adjs >>> on the interface, and the bandwidth of the interface. >>> >>> The algorithm that determines spacing should have a defined >>> rampup speed, and have a exponential slowdown if congestion >>> is determined (tcp Van Jacobson's algorithm is a good start) >>> >>> (1c) Router capability and Congestion determination should >>> be based on past round-trip >>> times of known events with the nbr; ie, Initial Database >>> Synchronization packets. >>> >>> >>> These are just 3 of dozens of items that can be used to >>> determine and adjust for increased load/scalability. >>> >>> Done.. :) >>> >>> >>> Mitchell Erblich >>> Sr Software Engineer >>> >> >>-- >>Acee > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 3 14:40:26 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08666 for ; Thu, 3 Apr 2003 14:40:25 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00961135@cherry.ease.lsoft.com>; Thu, 3 Apr 2003 14:42:53 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 716188 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Apr 2003 14:42:53 -0500 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 3 Apr 2003 14:42:53 -0500 Received: (qmail 613 invoked from network); 3 Apr 2003 19:42:53 -0000 Received: from unknown (HELO xebeo.com) (192.168.2.180) by lxmail.xebeo.com with SMTP; 3 Apr 2003 19:42:53 -0000 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <73656AE8EE4C9C4D9FFF9DBFEAE9A00F223BED@KCCLUST06EVS1.ugd.att.com> <200304031739.h33Hdr926137@cirrus.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E8C8EBA.50509@xebeo.com> Date: Thu, 3 Apr 2003 21:42:50 +0200 Reply-To: Mailing List Sender: Mailing List From: Tony Przygienda Subject: Re: Internet Draft : Prioritized Treatment of Specific OSPF Pack ets and Congestion Avoidance #1 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Dave Katz wrote: >I think you're dancing around the bigger issue, which is that >optimizations are highly dependent on the implementation in which they >are applied (stop me if you've heard me rant on this before.) > >Some of the optimizations will be more helpful than others in some >implementations. Trying to prioritize them or otherwise be too >specific is akin to calculating angel density on pinheads. > the issue was as far I remember Thomas of Acquine, the _number_ of angels on a pinhead which is a far more practical problem. > Also, please keep > in mind that there may be > situations where specially identifying Hello and prioritizing it > (at the receiver) may not > be easy but it may be easier to reset inactivity timers on receiving > any packet. > doing that (resetting timer on every packet instead of what the spec says) may lead to very subtle interoperability problems (and had in the past, a.k.a routers 'forgetting' to send hellos for one or another reason) and you may want to point that out. I don't disagree though that it's a good thing. --- tony From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 3 14:44:25 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08804 for ; Thu, 3 Apr 2003 14:44:25 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00961211@cherry.ease.lsoft.com>; Thu, 3 Apr 2003 14:46:53 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 716213 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Apr 2003 14:46:53 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 3 Apr 2003 14:46:53 -0500 Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h33JkqS59074 for ; Thu, 3 Apr 2003 11:46:52 -0800 (PST) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id h33JkqZ26616; Thu, 3 Apr 2003 11:46:52 -0800 (PST) (envelope-from dkatz@cirrus.juniper.net) References: <73656AE8EE4C9C4D9FFF9DBFEAE9A00F223BED@KCCLUST06EVS1.ugd.att.com> <200304031739.h33Hdr926137@cirrus.juniper.net> <3E8C8EBA.50509@xebeo.com> Message-ID: <200304031946.h33JkqZ26616@cirrus.juniper.net> Date: Thu, 3 Apr 2003 11:46:52 -0800 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: Internet Draft : Prioritized Treatment of Specific OSPF Pack ets and Congestion Avoidance #1 To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E8C8EBA.50509@xebeo.com> (message from Tony Przygienda on Thu, 3 Apr 2003 21:42:50 +0200) Precedence: list the issue was as far I remember Thomas of Acquine, the _number_ of angels on a pinhead which is a far more practical problem. Perhaps, but the density is really the architectural constant, given varying sizes of pinheads. (Insert tasteless microcephalic joke here.) From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 3 14:53:04 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09051 for ; Thu, 3 Apr 2003 14:53:04 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.009612E0@cherry.ease.lsoft.com>; Thu, 3 Apr 2003 14:55:32 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 716366 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Apr 2003 14:55:32 -0500 Received: from 192.128.134.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 3 Apr 2003 14:55:32 -0500 Received: from attrh3i.attrh.att.com ([135.71.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h33JtQKN013300 for ; Thu, 3 Apr 2003 13:55:27 -0600 (CST) Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (6.5.032) id 3E85156000023FE3 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Apr 2003 14:55:25 -0500 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: Internet Draft : Prioritized Treatment of Specific OSPF Pack ets and Congestion Avoidance #1 Thread-Index: AcL6GVa4NINGtlHCTeGakqsAtbqVzwAADz/Q Message-ID: <73656AE8EE4C9C4D9FFF9DBFEAE9A00F09E8A4@KCCLUST06EVS1.ugd.att.com> Date: Thu, 3 Apr 2003 13:55:19 -0600 Reply-To: Mailing List Sender: Mailing List From: "Choudhury, Gagan L, ALABS" Subject: Re: Internet Draft : Prioritized Treatment of Specific OSPF Pack ets and Congestion Avoidance #1 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA09051 Based on the various comments so far perhaps we can point out explicitly that if Hello packets are already being prioritized then it may not be necessary to reset the activity timer based on receiving any packet over the inteface since there may be other issues associated with that. Does it address most comments? Gagan -----Original Message----- From: Tony Przygienda [mailto:prz@XEBEO.COM] Sent: Thursday, April 03, 2003 2:43 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Internet Draft : Prioritized Treatment of Specific OSPF Pack ets and Congestion Avoidance #1 > Also, please keep > in mind that there may be > situations where specially identifying Hello and prioritizing it > (at the receiver) may not > be easy but it may be easier to reset inactivity timers on receiving > any packet. > doing that (resetting timer on every packet instead of what the spec says) may lead to very subtle interoperability problems (and had in the past, a.k.a routers 'forgetting' to send hellos for one or another reason) and you may want to point that out. I don't disagree though that it's a good thing. --- tony From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 3 14:57:55 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09212 for ; Thu, 3 Apr 2003 14:57:55 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00961141@cherry.ease.lsoft.com>; Thu, 3 Apr 2003 15:00:16 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 716463 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Apr 2003 15:00:16 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 3 Apr 2003 15:00:16 -0500 Received: from juniper.net (localhost [127.0.0.1]) by padma-bsd.juniper.net (8.12.6/8.12.3) with ESMTP id h33K0F0R022561; Thu, 3 Apr 2003 12:00:15 -0800 (PST) (envelope-from padma@juniper.net) User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 References: <200304031704.h33H4rV84104@garnet.juniper.net> <3E8C7CA8.BDCE3DC8@earthlink.net> Content-Type: multipart/alternative; boundary="------------090200000002060901090407" Message-ID: <3E8C92CF.1060008@juniper.net> Date: Thu, 3 Apr 2003 12:00:15 -0800 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Organization: Juniper Networks Subject: Re: Internet Draft : OSPF Refresh and Flooding in Stable Topologies To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --------------090200000002060901090407 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit See below Erblichs wrote: >Lets try inlining this time.. > >Mitchell Erblich >Sr Software Engineer >---------- > >Padma Pillay-Esnault wrote: > >>Mitchell Erblich, >> >>>Padma Pillay-Esnault, >>> >>> Let me re-phrase the first question. >>> >>> 1) One of the most common methods that a >>> stable OSPF router does is the periodic >>> verification of the checksums of >>> LSAs within its database. >>> >>> Upon checksum verifcation failure and >>> removal, (router just removes the bad >>> LSA and marks the memory location as >>> suspect) then non-aynchronous flooding >>> will not resubmit the removed LSA.... >>> >>> Note: With the draft that deals with >>> the later re-Initial Database Synchronization >>> work, we can get back the LSA if the >>> adj hasn't also removed it. But not >>> yet.. >>> >>What is this work ?? >> > > OSPF Out-of-band LSDB resynchronization > by Alex Zinn and Abhay Roy > Cisco, Feb 2001 > > And truly, I don't know what is happening with it??? > >>> So, you then break the assumption that >>> all routers within an area must have the >>> same LSAs in their database????? >>> >>No. The LSA contents are the same. >> >>> You just forced us to >>> take doown the interface >>> if we have a DNA LSA on a non-DC configured >>> interface and we fail a checksum? Right??? >>> >>> (Actually, identify the adj that submitted >>> us the LSA, and remove him from the next >>> hello, then...redo the Init DB Sync) >>> >>I usually don't force anyone ;-) >>???- Are you referring to the work above ? >> > > Yes... > I think this draft is for a issue orthogonal to mine and let's not mix them. > >>> >>> *** Yes, This problem was not reported to >>> me early on dealing with demand-circuits! >>> I don't know why other people dont't see >>> this. Maybe people have perfect memory or >>> they just don't run the checksuming algorithm. >>> The current solution is to restart the >>> DC interface where the LSDB originated to >>> restart the Initial Database Synchronization. >>> >>> Else, we wait for the asynchronous re-submit of >>> the LSA. It depends on the time that we last saw >>> the LSA instance. >>> >>> But now you are making it apply to all >>> interfaces / adjs ... >>> >>Let assume that what you say happens in a regular topology - >>an LSA gets corrupted and discarded then the SPF should run and >>this route and others including it in their SPF calculation >>should be discarded. Hence we will lose routes for at the maximum >>30 minutes. I have not heard anyone complain about such a problem >>in normal. I believe that it is very rare if it indeeds happens. >> > > Maybe implimentations are skipping the periodic checksum. > > The 30 minutes is assuming that asynchronous flooding will > occur started at the originator. Your draft changes from > 30 minutes to whenever the originator refloods the LSA if > ever. So, a route can now be lost for an undeterminate > amount of time, if you don't do anything. I don't think that > is good. > > BTW, If our current dyanmic SPF wait interval (see Cisco's > SPF Throttling Paper on their web site) which approximates > this paper, (max of 600,000 ms) is less than the expected > time of reflush of the removed LSA, we then wait for the > reflood. > This draft does not introduce any new issue from the rfc 1793. More over, Section 5 mentions the forced periodic forced flooding. The parameter to be configured to whatever they want and hence still have a flooding of LSAs. > >>> 2) Oops, section 5 does specify interfaces or >>> globaly. >>> >>> 3) Let me state this one.. Reachability in the >>> Demand Circuit is 1 hr, etc. Shouldn't your >>> document state that reachability is based >>> on Dead Router Interval? You reference a >>> doc and take some things from it and leave >>> this type of item "explicitly unstated". >>> >>Remember that this is *not* DC. We are not setting DC bit >>in the hellos or in the DBD packets. So it is Dead Interval. >> > Yes, but shouldn't you possibly want to state > this in the RFC? > It can be stated. > >>> 4) Are you stating reflooding by the LSA orignator? >>> What happens if the originator doesn't see >>> the change? The orignator will not reflood >>> the LSA... >>> >>If the originator doesn't see a change that should cause a >>change in contents in its LSA then there is a bug ;-) >> >>>` 5) The non-reachability rule for Demand-Circuit >>> specifies 1 hr, but for normal routers specify >>> dead-router interval? Which one should we >>> follow? Shouldn't it explicitly be stated in >>> the document? >>> >>See response 3. >> >>> Remember, I stated an orderly shutdown. Why >>> don't we reflood with MAX-AGE, to remove >>> un-necessary LSAs? This is analgous to RIP's >>> poisson reverse something... >>> >>This is an implementation decision. When you lose your adjacency, >>the LSA from the originating router will not be used in the spf >>anyway. Flooding MAXAGE LSA can be very expensive while the >>lingering LSAs will not be used in the SPF anyway. So, some >>believe it is useless. >> > > Well Moy does the former in his book and I agree with > his decision. See the shutdown function. > Let me put it like this .. my draft is about eliminating unneccessary protocol traffic .. and the maxaging on going out is unnecessary traffic. Padma > >>Padma >> >>> Mitchell Erblich >>> Sr Software Engineer >>> --------------------------- >>> >>> >>>Padma Pillay-Esnault wrote: >>> >>>>Mitchell, >>>> >>>>First let me state that this feature can only operate if >>>>all the routers have an understanding on how to handle DNA >>>>LSA per rfc 1793. >>>> >>>>>Group, >>>>> >>>>> Sorry, just a few items to ponder :) >>>>> >>> 1) >>> >>>>> This document does not discuss the implications of a LSA >>>>> being corrupted (LSA checksum failed) and then being >>>>> discarded. >>>>> >>>>> Should we not do checksums on DNA LSAs? >>>>> >>>>> Can the router that is removing the failed checksum LSA >>>>> flood a earlier instance of the LSA? This hoping that the >>>>> LSA will be reflooded by the originator? Should it be >>>>> stated here? >>>>> >>>>I am not sure I understand your question. >>>>How does handling this case differ between a router implementing this >>>>draft and having a router implementing DC somewhere in your topology >>>>and emitting DNA LSAs? >>>> >>> 2) >>> >>>>> Should it be stated that this knob is per interface? >>>>> >>>>This is stated in section 5. >>>> >>>>> Should it be stated what happens if the knob is first to >>>>> have normal flooding, then reduced flooding or vice versa, >>>>> OR more simply stated the requirement to reflush the LSA >>>>> that are having their DNA bit changed? >>>>> >>>>Do you mean to state that turning off the feature should cause all >>>>the LSAs to be reflooded with the DNA bit clear ? This seemed obvious >>>>to me. But any ways, on the first refresh of the LSA on the originating >>>>router this will cause the LSA to be flooded with the new sequence >>>>number and DNA bit clear. >>>> >>>>> What is the implication of changing the knob twice within >>>>> the standard 5 secs of re-originating the same LSA? >>>>> >>>>That would be implementation choice how to keep track of this. >>>> >>> 3) >>> >>>>> Should a DNA LSA be removed upon loss of an adj due to >>>>> the dead router interval expiring? >>>>> >>>>This is part of rfc 1793 that when reachability to the router >>>>originating an LSA with DNA bit set is lost that LSA should be maxaged. >>>> >>> 4) >>> >>>>> **What is the implication that during the initial flooding of >>>>> the DNA LSA, that a temporary routing loop or a black hole >>>>> existed? This could even be due to mis-router configuration? >>>>> Now, after this temporary condition has cleared will some >>>>> routers never get the LSA? In the past we could be assured >>>>> that we would eventually see the LSA.... >>>>> >>>>Any change in topology/configuration will result in LSA(s) being >>>>flooded so this will clear up. >>>> >>> 5) >>> >>>>> And lastly, should this document identify the procedure >>>>> for removing its originated LSA before a orderly shutdown? >>>>> >>>>This is covered by the non-reachability rule. >>>> >>>>> >>>>> Mitchell Erblich >>>>> Sr Software Engineer >>>>> ----------------------------------- >>>>> >>>>Padma >>>> > > --------------090200000002060901090407 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit See below


Erblichs wrote:
Lets try  inlining this time..

Mitchell Erblich
Sr Software Engineer
----------

Padma Pillay-Esnault wrote:
Mitchell Erblich,

Padma Pillay-Esnault,

        Let me re-phrase the first question.

        1) One of the most common methods that a
        stable OSPF router does is the periodic
        verification of the checksums of
        LSAs within its database.

        Upon checksum verifcation failure and
        removal, (router just removes the bad
        LSA and marks the memory location as
        suspect) then non-aynchronous flooding
        will not resubmit the removed LSA....

        Note: With the draft that deals with
        the later re-Initial Database Synchronization
        work, we can get back the LSA if the
        adj hasn't also removed it. But not
        yet..
What is this work ??

        OSPF Out-of-band LSDB resynchronization
        by Alex Zinn and Abhay Roy
        Cisco, Feb 2001

        And truly, I don't know what is happening with it???
        So, you then break the assumption that
        all routers within an area must have the
        same LSAs in their database?????
No. The LSA contents are the same.

        You just forced us to
        take doown the interface
        if we have a DNA LSA on a non-DC configured
        interface and we fail a checksum? Right???

        (Actually, identify the adj that submitted
         us the LSA, and remove him from the next
         hello, then...redo the Init DB Sync)
I usually don't force anyone ;-)
???- Are you referring to the work above ?

        Yes...

I think this draft is for a issue orthogonal to mine and let's not mix them.



        *** Yes, This problem was not reported to
        me early on dealing with demand-circuits!
        I don't know why other people dont't see
        this. Maybe people have perfect memory or
        they just don't run the checksuming algorithm.
        The current solution is to restart the
        DC interface where the LSDB originated to
        restart the Initial Database Synchronization.

        Else, we wait for the asynchronous re-submit of
        the LSA. It depends on the time that we last saw
        the LSA instance.

        But now you are making it apply to all
        interfaces / adjs ...

Let assume that what you say happens in a regular topology -
an LSA gets corrupted and discarded then the SPF should run and
this route and others including it in their SPF calculation
should be discarded. Hence we will lose routes for at the maximum
30 minutes. I have not heard anyone complain about such a problem
in normal. I believe that it is very rare if it indeeds happens.


        Maybe implimentations are skipping the periodic checksum.

        The 30 minutes is assuming that asynchronous flooding will
        occur started at the originator. Your draft changes from
        30 minutes to whenever the originator refloods the LSA if
        ever. So, a route can now be lost for an undeterminate
        amount of time, if you don't do anything. I don't think that
        is good.

        BTW, If our current dyanmic SPF wait interval (see Cisco's
        SPF Throttling Paper on their web site) which approximates
        this paper, (max of 600,000 ms) is less than the expected
        time of reflush of the removed LSA, we then wait for the
        reflood.

This draft does not introduce any new issue from the rfc 1793. More over, Section 5
mentions the forced periodic forced flooding. The parameter to be configured to
whatever they want and hence still have a flooding of LSAs.

        2) Oops, section 5 does specify interfaces or
           globaly.

        3) Let me state this one.. Reachability in the
           Demand Circuit is 1 hr, etc. Shouldn't your
           document state that reachability is based
           on Dead Router Interval? You reference a
           doc and take some things from it and leave
           this type of item "explicitly unstated".

Remember that this is *not* DC. We are not setting DC bit
in the hellos or in the DBD packets. So it is Dead Interval.

                Yes, but shouldn't you possibly want to state
                this in the RFC?
It can be stated.

        4) Are you stating reflooding by the LSA orignator?
           What happens if the originator doesn't see
           the change? The orignator will not reflood
           the LSA...

If the originator doesn't see a change that should cause a
change in contents in its LSA then there is a bug ;-)

`       5) The non-reachability rule for Demand-Circuit
           specifies 1 hr, but for normal routers specify
           dead-router interval? Which one should we
           follow? Shouldn't it explicitly be stated in
           the document?

See response 3.

           Remember, I stated an orderly shutdown. Why
           don't we reflood with MAX-AGE, to remove
           un-necessary LSAs? This is analgous to RIP's
           poisson reverse something...

This is an implementation decision. When you lose your adjacency,
the LSA from the originating router will not be used in the spf
anyway. Flooding MAXAGE LSA can be very expensive while the
lingering LSAs will not be used in the SPF anyway. So, some
believe it is useless.

        Well Moy does the former in his book and I agree with
        his decision. See the shutdown function.


Let me put it like this .. my draft is about eliminating unneccessary protocol
traffic .. and the maxaging on going out is unnecessary traffic.

Padma

Padma

        Mitchell Erblich
        Sr Software Engineer
        ---------------------------


Padma Pillay-Esnault wrote:
Mitchell,

First let me state that this feature can only operate if
all the routers have an understanding on how to handle DNA
LSA per rfc 1793.

Group,

        Sorry, just a few items to ponder :)

        1)
        This document does not discuss the implications of a LSA
        being corrupted (LSA checksum failed) and then being
        discarded.

        Should we not do checksums on DNA LSAs?

        Can the router that is removing the failed checksum LSA
        flood a earlier instance of the LSA? This hoping that the
        LSA will be reflooded by the originator? Should it be
        stated here?
I am not sure I understand your question.
How does handling this case differ between a router implementing this
draft and having a router implementing DC somewhere in your topology
and emitting DNA LSAs?

        2)
        Should it be stated that this knob is per interface?
This is stated in section 5.

        Should it be stated what happens if the knob is first to
        have normal flooding, then reduced flooding or vice versa,
        OR more simply stated the requirement to reflush the LSA
        that are having their DNA bit changed?

Do you mean to state that turning off the feature should cause all
the LSAs to be reflooded with the DNA bit clear ? This seemed obvious
to me. But any ways, on the first refresh of the LSA on the originating
router this will cause the LSA to be flooded with the new sequence
number and DNA bit clear.

        What is the implication of changing the knob twice within
        the standard 5 secs of re-originating the same LSA?
That would be implementation choice how to keep track of this.

        3)
        Should a DNA LSA be removed upon loss of an adj due to
        the dead router interval expiring?
This is part of rfc 1793 that when reachability to the router
originating an LSA with DNA bit set is lost that LSA should be maxaged.

        4)
        **What is the implication that during the initial flooding of
        the DNA LSA, that a temporary routing loop or a black hole
        existed? This could even be due to mis-router configuration?
        Now, after this temporary condition has cleared will some
        routers never get the LSA?  In the past we could be assured
        that we would eventually see the LSA....
Any change in topology/configuration will result in LSA(s) being
flooded so this will clear up.

        5)
        And lastly, should this document identify the procedure
        for removing its originated LSA before a orderly shutdown?
This is covered by the non-reachability rule.


        Mitchell Erblich
        Sr Software Engineer
        -----------------------------------

Padma



--------------090200000002060901090407-- From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 3 15:12:08 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10716 for ; Thu, 3 Apr 2003 15:12:08 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.009612FA@cherry.ease.lsoft.com>; Thu, 3 Apr 2003 15:14:36 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 716572 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Apr 2003 15:14:36 -0500 Received: from 32.97.110.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 3 Apr 2003 15:14:36 -0500 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h33KDCi2112644 for ; Thu, 3 Apr 2003 15:13:12 -0500 Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h33KEYAU119144 for ; Thu, 3 Apr 2003 13:14:34 -0700 X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0 [IBM]|December 16, 2002) at 04/03/2003 13:14:34 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Message-ID: Date: Thu, 3 Apr 2003 15:14:32 -0500 Reply-To: Mailing List Sender: Mailing List From: Mike Fox Subject: Re: Internet Draft : Prioritized Treatment of Specific OSPF Pack ets and Congestion Avoidance #1 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Gagan wrote: > Based on the various comments so far perhaps we can point out explicitly > that if Hello packets are already being prioritized then it may not > be necessary to reset the activity timer based on receiving any packet > over the inteface since there may be other issues associated with that. > Does it address most comments? That works for me, though I would just expand it a teeny bit to mention that one of the "other issues" is decreased convergence time because doing both may cause it to take significantly longer than the dead router interval to discover that a neighbor has died because of the inactivity timer being reset as stale packets in the lower priority queue are being processed. Mike From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 3 15:19:30 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11553 for ; Thu, 3 Apr 2003 15:19:30 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.009612C4@cherry.ease.lsoft.com>; Thu, 3 Apr 2003 15:21:58 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 716611 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Apr 2003 15:21:58 -0500 Received: from 192.128.134.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 3 Apr 2003 15:21:58 -0500 Received: from attrh3i.attrh.att.com ([135.71.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h33KLtKN028422 for ; Thu, 3 Apr 2003 14:21:55 -0600 (CST) Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (6.5.032) id 3E851560000244DD for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Apr 2003 15:21:55 -0500 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: Internet Draft : Prioritized Treatment of Specific OSPF Pack ets and Congestion Avoidance #1 Thread-Index: AcL6Hatr1MPgQJtlQ9ecPNvXSbyMCwAAGu0w Message-ID: <73656AE8EE4C9C4D9FFF9DBFEAE9A00F09E8A5@KCCLUST06EVS1.ugd.att.com> Date: Thu, 3 Apr 2003 14:21:23 -0600 Reply-To: Mailing List Sender: Mailing List From: "Choudhury, Gagan L, ALABS" Subject: Re: Internet Draft : Prioritized Treatment of Specific OSPF Pack ets and Congestion Avoidance #1 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA11553 Mike, Thanks. We will address your point. Gagan -----Original Message----- From: Mike Fox [mailto:mjfox@US.IBM.COM] Sent: Thursday, April 03, 2003 3:15 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Internet Draft : Prioritized Treatment of Specific OSPF Pack ets and Congestion Avoidance #1 Gagan wrote: > Based on the various comments so far perhaps we can point out explicitly > that if Hello packets are already being prioritized then it may not > be necessary to reset the activity timer based on receiving any packet > over the inteface since there may be other issues associated with that. > Does it address most comments? That works for me, though I would just expand it a teeny bit to mention that one of the "other issues" is decreased convergence time because doing both may cause it to take significantly longer than the dead router interval to discover that a neighbor has died because of the inactivity timer being reset as stale packets in the lower priority queue are being processed. Mike From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 3 16:31:13 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15042 for ; Thu, 3 Apr 2003 16:31:13 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.009614AB@cherry.ease.lsoft.com>; Thu, 3 Apr 2003 16:33:41 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 716811 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Apr 2003 16:33:40 -0500 Received: from 207.217.120.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 3 Apr 2003 16:33:40 -0500 Received: from user-2ivfjqj.dialup.mindspring.com ([165.247.207.83] helo=earthlink.net) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 191CL3-0006kd-00 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 03 Apr 2003 13:33:38 -0800 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: <200304031704.h33H4rV84104@garnet.juniper.net> <3E8C7CA8.BDCE3DC8@earthlink.net> <3E8C92CF.1060008@juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E8CA857.618BFB54@earthlink.net> Date: Thu, 3 Apr 2003 13:32:07 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Internet Draft : OSPF Refresh and Flooding in Stable Topologies To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Padma Pillay_Esnault, I agree with your intention! However, in MY OPINION. 1) Decrease the flooding interval to maybe 50 minutes for LSAs without the DNA being set. Thus request that this archectural constant become a configurable parameter. 2) Create a new capability that allows a minimal OOB request/ack for a single LSA over an adj with awareness of the LSA instance. - This would take care of a loss of synchronization due to checksum removal or some other loss. - Be able to have the request directed to the LSA originator when the below #3 header is identified. 3) Suggest a new flooding low-overhead flood capability using LSA headers (ala IS-IS) that is defaulted to re-xmit every 30 minutes but can be set higher. 4) Define a method for backward compatibility. Mitchell Erblich Sr Software Engineer ======================== Padma Pillay-Esnault wrote: > > See below > > Erblichs wrote: > > > Lets try inlining this time.. > > Mitchell Erblich > > Sr Software Engineer > > ---------- > > Padma Pillay-Esnault wrote: > > > >> Mitchell Erblich, > >> > >> > Padma Pillay-Esnault, > >> > Let me re-phrase the first question. > >> > 1) One of the most common methods that a > >> > stable OSPF router does is the periodic > >> > verification of the checksums of > >> > LSAs within its database. > >> > Upon checksum verifcation failure and > >> > removal, (router just removes the bad > >> > LSA and marks the memory location as > >> > suspect) then non-aynchronous flooding > >> > will not resubmit the removed LSA.... > >> > Note: With the draft that deals with > >> > the later re-Initial Database Synchronization > >> > work, we can get back the LSA if the > >> > adj hasn't also removed it. But not > >> > yet.. > >> > > >> What is this work ?? > >> > > OSPF Out-of-band LSDB resynchronization > > by Alex Zinn and Abhay Roy > > Cisco, Feb 2001 > > And truly, I don't know what is happening with it??? > > > >> > So, you then break the assumption that > >> > all routers within an area must have the > >> > same LSAs in their database????? > >> > > >> No. The LSA contents are the same. > >> > >> > You just forced us to > >> > take doown the interface > >> > if we have a DNA LSA on a non-DC configured > >> > interface and we fail a checksum? Right??? > >> > (Actually, identify the adj that submitted > >> > us the LSA, and remove him from the next > >> > hello, then...redo the Init DB Sync) > >> > > >> I usually don't force anyone ;-) > >> ???- Are you referring to the work above ? > >> > > Yes... > > > > I think this draft is for a issue orthogonal to mine and let's not mix > them. > > >> > *** Yes, This problem was not reported to > >> > me early on dealing with demand-circuits! > >> > I don't know why other people dont't see > >> > this. Maybe people have perfect memory or > >> > they just don't run the checksuming algorithm. > >> > The current solution is to restart the > >> > DC interface where the LSDB originated to > >> > restart the Initial Database Synchronization. > >> > Else, we wait for the asynchronous re-submit of > >> > the LSA. It depends on the time that we last saw > >> > the LSA instance. > >> > But now you are making it apply to all > >> > interfaces / adjs ... > >> > > >> Let assume that what you say happens in a regular topology - > >> an LSA gets corrupted and discarded then the SPF should run and > >> this route and others including it in their SPF calculation > >> should be discarded. Hence we will lose routes for at the maximum > >> 30 minutes. I have not heard anyone complain about such a problem > >> in normal. I believe that it is very rare if it indeeds happens. > >> > > Maybe implimentations are skipping the periodic checksum. > > The 30 minutes is assuming that asynchronous flooding will > > occur started at the originator. Your draft changes from > > 30 minutes to whenever the originator refloods the LSA if > > ever. So, a route can now be lost for an undeterminate > > amount of time, if you don't do anything. I don't think that > > is good. > > BTW, If our current dyanmic SPF wait interval (see Cisco's > > SPF Throttling Paper on their web site) which approximates > > this paper, (max of 600,000 ms) is less than the expected > > time of reflush of the removed LSA, we then wait for the > > reflood. > > > This draft does not introduce any new issue from the rfc 1793. More > over, Section 5 > mentions the forced periodic forced flooding. The parameter to be > configured to > whatever they want and hence still have a flooding of LSAs. > > >> > 2) Oops, section 5 does specify interfaces or > >> > globaly. > >> > 3) Let me state this one.. Reachability in the > >> > Demand Circuit is 1 hr, etc. Shouldn't your > >> > document state that reachability is based > >> > on Dead Router Interval? You reference a > >> > doc and take some things from it and leave > >> > this type of item "explicitly unstated". > >> > > >> Remember that this is *not* DC. We are not setting DC bit > >> in the hellos or in the DBD packets. So it is Dead Interval. > >> > > Yes, but shouldn't you possibly want to state > > this in the RFC? > > > It can be stated. > > >> > 4) Are you stating reflooding by the LSA orignator? > >> > What happens if the originator doesn't see > >> > the change? The orignator will not reflood > >> > the LSA... > >> > > >> If the originator doesn't see a change that should cause a > >> change in contents in its LSA then there is a bug ;-) > >> > >> > ` 5) The non-reachability rule for Demand-Circuit > >> > specifies 1 hr, but for normal routers specify > >> > dead-router interval? Which one should we > >> > follow? Shouldn't it explicitly be stated in > >> > the document? > >> > > >> See response 3. > >> > >> > Remember, I stated an orderly shutdown. Why > >> > don't we reflood with MAX-AGE, to remove > >> > un-necessary LSAs? This is analgous to RIP's > >> > poisson reverse something... > >> > > >> This is an implementation decision. When you lose your adjacency, > >> the LSA from the originating router will not be used in the spf > >> anyway. Flooding MAXAGE LSA can be very expensive while the > >> lingering LSAs will not be used in the SPF anyway. So, some > >> believe it is useless. > >> > > Well Moy does the former in his book and I agree with > > his decision. See the shutdown function. > > > > Let me put it like this .. my draft is about eliminating unneccessary > protocol > traffic .. and the maxaging on going out is unnecessary traffic. > > Padma > > >> Padma > >> > >> > Mitchell Erblich > >> > Sr Software Engineer > >> > --------------------------- > >> > Padma Pillay-Esnault wrote: > >> > > >> >> Mitchell, > >> >> First let me state that this feature can only operate if > >> >> all the routers have an understanding on how to handle DNA > >> >> LSA per rfc 1793. > >> >> > >> >> > Group, > >> >> > Sorry, just a few items to ponder :) > >> >> > > >> > 1) > >> > > >> >> > This document does not discuss the implications of a > >> >> > LSA > >> >> > being corrupted (LSA checksum failed) and then being > >> >> > discarded. > >> >> > Should we not do checksums on DNA LSAs? > >> >> > Can the router that is removing the failed checksum > >> >> > LSA > >> >> > flood a earlier instance of the LSA? This hoping that > >> >> > the > >> >> > LSA will be reflooded by the originator? Should it be > >> >> > stated here? > >> >> > > >> >> I am not sure I understand your question. > >> >> How does handling this case differ between a router > >> >> implementing this > >> >> draft and having a router implementing DC somewhere in your > >> >> topology > >> >> and emitting DNA LSAs? > >> >> > >> > 2) > >> > > >> >> > Should it be stated that this knob is per interface? > >> >> > > >> >> This is stated in section 5. > >> >> > >> >> > Should it be stated what happens if the knob is first > >> >> > to > >> >> > have normal flooding, then reduced flooding or vice > >> >> > versa, > >> >> > OR more simply stated the requirement to reflush the > >> >> > LSA > >> >> > that are having their DNA bit changed? > >> >> > > >> >> Do you mean to state that turning off the feature should cause > >> >> all > >> >> the LSAs to be reflooded with the DNA bit clear ? This seemed > >> >> obvious > >> >> to me. But any ways, on the first refresh of the LSA on the > >> >> originating > >> >> router this will cause the LSA to be flooded with the new > >> >> sequence > >> >> number and DNA bit clear. > >> >> > >> >> > What is the implication of changing the knob twice > >> >> > within > >> >> > the standard 5 secs of re-originating the same LSA? > >> >> > > >> >> That would be implementation choice how to keep track of this. > >> >> > >> > 3) > >> > > >> >> > Should a DNA LSA be removed upon loss of an adj due > >> >> > to > >> >> > the dead router interval expiring? > >> >> > > >> >> This is part of rfc 1793 that when reachability to the router > >> >> originating an LSA with DNA bit set is lost that LSA should be > >> >> maxaged. > >> >> > >> > 4) > >> > > >> >> > **What is the implication that during the initial > >> >> > flooding of > >> >> > the DNA LSA, that a temporary routing loop or a black > >> >> > hole > >> >> > existed? This could even be due to mis-router > >> >> > configuration? > >> >> > Now, after this temporary condition has cleared will > >> >> > some > >> >> > routers never get the LSA? In the past we could be > >> >> > assured > >> >> > that we would eventually see the LSA.... > >> >> > > >> >> Any change in topology/configuration will result in LSA(s) > >> >> being > >> >> flooded so this will clear up. > >> >> > >> > 5) > >> > > >> >> > And lastly, should this document identify the > >> >> > procedure > >> >> > for removing its originated LSA before a orderly > >> >> > shutdown? > >> >> > > >> >> This is covered by the non-reachability rule. > >> >> > >> >> > Mitchell Erblich > >> >> > Sr Software Engineer > >> >> > ----------------------------------- > >> >> > > >> >> Padma > >> >> From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 3 17:22:23 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17244 for ; Thu, 3 Apr 2003 17:22:20 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.009617EB@cherry.ease.lsoft.com>; Thu, 3 Apr 2003 17:24:48 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 716942 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Apr 2003 17:24:48 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 3 Apr 2003 17:24:47 -0500 Received: from juniper.net (localhost [127.0.0.1]) by padma-bsd.juniper.net (8.12.6/8.12.3) with ESMTP id h33MOl0R022741; Thu, 3 Apr 2003 14:24:47 -0800 (PST) (envelope-from padma@juniper.net) User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 References: <200304031704.h33H4rV84104@garnet.juniper.net> <3E8C7CA8.BDCE3DC8@earthlink.net> <3E8C92CF.1060008@juniper.net> <3E8CA857.618BFB54@earthlink.net> Content-Type: multipart/alternative; boundary="------------040006020004040206060206" Message-ID: <3E8CB4AF.50907@juniper.net> Date: Thu, 3 Apr 2003 14:24:47 -0800 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Organization: Juniper Networks Subject: Re: Internet Draft : OSPF Refresh and Flooding in Stable Topologies To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --------------040006020004040206060206 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Erblichs wrote: >Padma Pillay_Esnault, > > I agree with your intention! > > However, in MY OPINION. > > 1) Decrease the flooding interval to maybe > 50 minutes for LSAs without the DNA being > set. Thus request that this archectural > constant become a configurable parameter. > There was a passage in the draft that mentionned this explicitly as well as its limitations. Our Chair asked me to remove it. You can bring it up to Acee. ;-) > > 2) Create a new capability that allows a minimal > OOB request/ack for a single LSA over an adj > with awareness of the LSA instance. > > - This would take care of a loss of synchronization > due to checksum removal or some other loss. > > - Be able to have the request directed to the LSA > originator when the below #3 header is identified. > Not scalable in my opinion for a problem which is too rare and autosolved by a periodic force refresh. > > 3) Suggest a new flooding low-overhead flood capability > using LSA headers (ala IS-IS) that is defaulted to > re-xmit every 30 minutes but can be set higher. > Problem that the LSAs will still die within 1hr. This draft gets more flexibility. > > 4) Define a method for backward compatibility. > How is this draft not backward compatible ? > > Mitchell Erblich > Sr Software Engineer > ======================== > > >Padma Pillay-Esnault wrote: > >>See below >> >>Erblichs wrote: >> >>>Lets try inlining this time.. >>>Mitchell Erblich >>>Sr Software Engineer >>>---------- >>>Padma Pillay-Esnault wrote: >>> >>>>Mitchell Erblich, >>>> >>>>>Padma Pillay-Esnault, >>>>> Let me re-phrase the first question. >>>>> 1) One of the most common methods that a >>>>> stable OSPF router does is the periodic >>>>> verification of the checksums of >>>>> LSAs within its database. >>>>> Upon checksum verifcation failure and >>>>> removal, (router just removes the bad >>>>> LSA and marks the memory location as >>>>> suspect) then non-aynchronous flooding >>>>> will not resubmit the removed LSA.... >>>>> Note: With the draft that deals with >>>>> the later re-Initial Database Synchronization >>>>> work, we can get back the LSA if the >>>>> adj hasn't also removed it. But not >>>>> yet.. >>>>> >>>>What is this work ?? >>>> >>> OSPF Out-of-band LSDB resynchronization >>> by Alex Zinn and Abhay Roy >>> Cisco, Feb 2001 >>> And truly, I don't know what is happening with it??? >>> >>>>> So, you then break the assumption that >>>>> all routers within an area must have the >>>>> same LSAs in their database????? >>>>> >>>>No. The LSA contents are the same. >>>> >>>>> You just forced us to >>>>> take doown the interface >>>>> if we have a DNA LSA on a non-DC configured >>>>> interface and we fail a checksum? Right??? >>>>> (Actually, identify the adj that submitted >>>>> us the LSA, and remove him from the next >>>>> hello, then...redo the Init DB Sync) >>>>> >>>>I usually don't force anyone ;-) >>>>???- Are you referring to the work above ? >>>> >>> Yes... >>> >>I think this draft is for a issue orthogonal to mine and let's not mix >>them. >> >>>>> *** Yes, This problem was not reported to >>>>> me early on dealing with demand-circuits! >>>>> I don't know why other people dont't see >>>>> this. Maybe people have perfect memory or >>>>> they just don't run the checksuming algorithm. >>>>> The current solution is to restart the >>>>> DC interface where the LSDB originated to >>>>> restart the Initial Database Synchronization. >>>>> Else, we wait for the asynchronous re-submit of >>>>> the LSA. It depends on the time that we last saw >>>>> the LSA instance. >>>>> But now you are making it apply to all >>>>> interfaces / adjs ... >>>>> >>>>Let assume that what you say happens in a regular topology - >>>>an LSA gets corrupted and discarded then the SPF should run and >>>>this route and others including it in their SPF calculation >>>>should be discarded. Hence we will lose routes for at the maximum >>>>30 minutes. I have not heard anyone complain about such a problem >>>>in normal. I believe that it is very rare if it indeeds happens. >>>> >>> Maybe implimentations are skipping the periodic checksum. >>> The 30 minutes is assuming that asynchronous flooding will >>> occur started at the originator. Your draft changes from >>> 30 minutes to whenever the originator refloods the LSA if >>> ever. So, a route can now be lost for an undeterminate >>> amount of time, if you don't do anything. I don't think that >>> is good. >>> BTW, If our current dyanmic SPF wait interval (see Cisco's >>> SPF Throttling Paper on their web site) which approximates >>> this paper, (max of 600,000 ms) is less than the expected >>> time of reflush of the removed LSA, we then wait for the >>> reflood. >>> >>This draft does not introduce any new issue from the rfc 1793. More >>over, Section 5 >>mentions the forced periodic forced flooding. The parameter to be >>configured to >>whatever they want and hence still have a flooding of LSAs. >> >>>>> 2) Oops, section 5 does specify interfaces or >>>>> globaly. >>>>> 3) Let me state this one.. Reachability in the >>>>> Demand Circuit is 1 hr, etc. Shouldn't your >>>>> document state that reachability is based >>>>> on Dead Router Interval? You reference a >>>>> doc and take some things from it and leave >>>>> this type of item "explicitly unstated". >>>>> >>>>Remember that this is *not* DC. We are not setting DC bit >>>>in the hellos or in the DBD packets. So it is Dead Interval. >>>> >>> Yes, but shouldn't you possibly want to state >>> this in the RFC? >>> >>It can be stated. >> >>>>> 4) Are you stating reflooding by the LSA orignator? >>>>> What happens if the originator doesn't see >>>>> the change? The orignator will not reflood >>>>> the LSA... >>>>> >>>>If the originator doesn't see a change that should cause a >>>>change in contents in its LSA then there is a bug ;-) >>>> >>>>>` 5) The non-reachability rule for Demand-Circuit >>>>> specifies 1 hr, but for normal routers specify >>>>> dead-router interval? Which one should we >>>>> follow? Shouldn't it explicitly be stated in >>>>> the document? >>>>> >>>>See response 3. >>>> >>>>> Remember, I stated an orderly shutdown. Why >>>>> don't we reflood with MAX-AGE, to remove >>>>> un-necessary LSAs? This is analgous to RIP's >>>>> poisson reverse something... >>>>> >>>>This is an implementation decision. When you lose your adjacency, >>>>the LSA from the originating router will not be used in the spf >>>>anyway. Flooding MAXAGE LSA can be very expensive while the >>>>lingering LSAs will not be used in the SPF anyway. So, some >>>>believe it is useless. >>>> >>> Well Moy does the former in his book and I agree with >>> his decision. See the shutdown function. >>> >>Let me put it like this .. my draft is about eliminating unneccessary >>protocol >>traffic .. and the maxaging on going out is unnecessary traffic. >> >>Padma >> >>>>Padma >>>> >>>>> Mitchell Erblich >>>>> Sr Software Engineer >>>>> --------------------------- >>>>>Padma Pillay-Esnault wrote: >>>>> >>>>>> Mitchell, >>>>>> First let me state that this feature can only operate if >>>>>> all the routers have an understanding on how to handle DNA >>>>>> LSA per rfc 1793. >>>>>> >>>>>>>Group, >>>>>>> Sorry, just a few items to ponder :) >>>>>>> >>>>> 1) >>>>> >>>>>>> This document does not discuss the implications of a >>>>>>>LSA >>>>>>> being corrupted (LSA checksum failed) and then being >>>>>>> discarded. >>>>>>> Should we not do checksums on DNA LSAs? >>>>>>> Can the router that is removing the failed checksum >>>>>>>LSA >>>>>>> flood a earlier instance of the LSA? This hoping that >>>>>>>the >>>>>>> LSA will be reflooded by the originator? Should it be >>>>>>> stated here? >>>>>>> >>>>>> I am not sure I understand your question. >>>>>> How does handling this case differ between a router >>>>>> implementing this >>>>>> draft and having a router implementing DC somewhere in your >>>>>> topology >>>>>> and emitting DNA LSAs? >>>>>> >>>>> 2) >>>>> >>>>>>> Should it be stated that this knob is per interface? >>>>>>> >>>>>> This is stated in section 5. >>>>>> >>>>>>> Should it be stated what happens if the knob is first >>>>>>>to >>>>>>> have normal flooding, then reduced flooding or vice >>>>>>>versa, >>>>>>> OR more simply stated the requirement to reflush the >>>>>>>LSA >>>>>>> that are having their DNA bit changed? >>>>>>> >>>>>> Do you mean to state that turning off the feature should cause >>>>>> all >>>>>> the LSAs to be reflooded with the DNA bit clear ? This seemed >>>>>> obvious >>>>>> to me. But any ways, on the first refresh of the LSA on the >>>>>> originating >>>>>> router this will cause the LSA to be flooded with the new >>>>>> sequence >>>>>> number and DNA bit clear. >>>>>> >>>>>>> What is the implication of changing the knob twice >>>>>>>within >>>>>>> the standard 5 secs of re-originating the same LSA? >>>>>>> >>>>>> That would be implementation choice how to keep track of this. >>>>>> >>>>> 3) >>>>> >>>>>>> Should a DNA LSA be removed upon loss of an adj due >>>>>>>to >>>>>>> the dead router interval expiring? >>>>>>> >>>>>> This is part of rfc 1793 that when reachability to the router >>>>>> originating an LSA with DNA bit set is lost that LSA should be >>>>>> maxaged. >>>>>> >>>>> 4) >>>>> >>>>>>> **What is the implication that during the initial >>>>>>>flooding of >>>>>>> the DNA LSA, that a temporary routing loop or a black >>>>>>>hole >>>>>>> existed? This could even be due to mis-router >>>>>>>configuration? >>>>>>> Now, after this temporary condition has cleared will >>>>>>>some >>>>>>> routers never get the LSA? In the past we could be >>>>>>>assured >>>>>>> that we would eventually see the LSA.... >>>>>>> >>>>>> Any change in topology/configuration will result in LSA(s) >>>>>> being >>>>>> flooded so this will clear up. >>>>>> >>>>> 5) >>>>> >>>>>>> And lastly, should this document identify the >>>>>>>procedure >>>>>>> for removing its originated LSA before a orderly >>>>>>>shutdown? >>>>>>> >>>>>> This is covered by the non-reachability rule. >>>>>> >>>>>>> Mitchell Erblich >>>>>>> Sr Software Engineer >>>>>>> ----------------------------------- >>>>>>> >>>>>> Padma >>>>>> > > --------------040006020004040206060206 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Erblichs wrote:
Padma Pillay_Esnault,

        I agree with your intention!

        However, in MY OPINION.

        1) Decrease the flooding interval to maybe
           50 minutes for LSAs without the DNA being
           set. Thus request that this archectural
           constant become a configurable parameter.

There was a passage in the draft that mentionned this explicitly as well as
its limitations. Our Chair asked me to remove it. You can bring it up to
Acee. ;-)

        2) Create a new capability that allows a minimal
           OOB request/ack for a single LSA over an adj
           with awareness of the LSA instance.

           - This would take care of a loss of synchronization
             due to checksum removal or some other loss.

           - Be able to have the request directed to the LSA
             originator when the below #3 header is identified.

Not scalable in my opinion for a problem which is too rare and autosolved
by a periodic force refresh.


        3) Suggest a new flooding low-overhead flood capability
           using LSA headers (ala IS-IS) that is defaulted to
           re-xmit every 30 minutes but can be set higher.

Problem that the LSAs will still die within 1hr. This draft gets more
flexibility.

        4) Define a method for backward compatibility.

How is this draft not backward compatible ?

        Mitchell Erblich
        Sr Software Engineer
        ========================


Padma Pillay-Esnault wrote:
See below

Erblichs wrote:

Lets try  inlining this time..
Mitchell Erblich
Sr Software Engineer
----------
Padma Pillay-Esnault wrote:

Mitchell Erblich,

Padma Pillay-Esnault,
        Let me re-phrase the first question.
        1) One of the most common methods that a
        stable OSPF router does is the periodic
        verification of the checksums of
        LSAs within its database.
        Upon checksum verifcation failure and
        removal, (router just removes the bad
        LSA and marks the memory location as
        suspect) then non-aynchronous flooding
        will not resubmit the removed LSA....
        Note: With the draft that deals with
        the later re-Initial Database Synchronization
        work, we can get back the LSA if the
        adj hasn't also removed it. But not
        yet..

What is this work ??

        OSPF Out-of-band LSDB resynchronization
        by Alex Zinn and Abhay Roy
        Cisco, Feb 2001
        And truly, I don't know what is happening with it???

        So, you then break the assumption that
        all routers within an area must have the
        same LSAs in their database?????

No. The LSA contents are the same.

        You just forced us to
        take doown the interface
        if we have a DNA LSA on a non-DC configured
        interface and we fail a checksum? Right???
        (Actually, identify the adj that submitted
         us the LSA, and remove him from the next
         hello, then...redo the Init DB Sync)

I usually don't force anyone ;-)
???- Are you referring to the work above ?

        Yes...

I think this draft is for a issue orthogonal to mine and let's not mix
them.

        *** Yes, This problem was not reported to
        me early on dealing with demand-circuits!
        I don't know why other people dont't see
        this. Maybe people have perfect memory or
        they just don't run the checksuming algorithm.
        The current solution is to restart the
        DC interface where the LSDB originated to
        restart the Initial Database Synchronization.
        Else, we wait for the asynchronous re-submit of
        the LSA. It depends on the time that we last saw
        the LSA instance.
        But now you are making it apply to all
        interfaces / adjs ...

Let assume that what you say happens in a regular topology -
an LSA gets corrupted and discarded then the SPF should run and
this route and others including it in their SPF calculation
should be discarded. Hence we will lose routes for at the maximum
30 minutes. I have not heard anyone complain about such a problem
in normal. I believe that it is very rare if it indeeds happens.

        Maybe implimentations are skipping the periodic checksum.
        The 30 minutes is assuming that asynchronous flooding will
        occur started at the originator. Your draft changes from
        30 minutes to whenever the originator refloods the LSA if
        ever. So, a route can now be lost for an undeterminate
        amount of time, if you don't do anything. I don't think that
        is good.
        BTW, If our current dyanmic SPF wait interval (see Cisco's
        SPF Throttling Paper on their web site) which approximates
        this paper, (max of 600,000 ms) is less than the expected
        time of reflush of the removed LSA, we then wait for the
        reflood.

This draft does not introduce any new issue from the rfc 1793. More
over, Section 5
mentions the forced periodic forced flooding. The parameter to be
configured to
whatever they want and hence still have a flooding of LSAs.

        2) Oops, section 5 does specify interfaces or
           globaly.
        3) Let me state this one.. Reachability in the
           Demand Circuit is 1 hr, etc. Shouldn't your
           document state that reachability is based
           on Dead Router Interval? You reference a
           doc and take some things from it and leave
           this type of item "explicitly unstated".

Remember that this is *not* DC. We are not setting DC bit
in the hellos or in the DBD packets. So it is Dead Interval.

                Yes, but shouldn't you possibly want to state
                this in the RFC?

It can be stated.

        4) Are you stating reflooding by the LSA orignator?
           What happens if the originator doesn't see
           the change? The orignator will not reflood
           the LSA...

If the originator doesn't see a change that should cause a
change in contents in its LSA then there is a bug ;-)

`       5) The non-reachability rule for Demand-Circuit
           specifies 1 hr, but for normal routers specify
           dead-router interval? Which one should we
           follow? Shouldn't it explicitly be stated in
           the document?

See response 3.

           Remember, I stated an orderly shutdown. Why
           don't we reflood with MAX-AGE, to remove
           un-necessary LSAs? This is analgous to RIP's
           poisson reverse something...

This is an implementation decision. When you lose your adjacency,
the LSA from the originating router will not be used in the spf
anyway. Flooding MAXAGE LSA can be very expensive while the
lingering LSAs will not be used in the SPF anyway. So, some
believe it is useless.

        Well Moy does the former in his book and I agree with
        his decision. See the shutdown function.

Let me put it like this .. my draft is about eliminating unneccessary
protocol
traffic .. and the maxaging on going out is unnecessary traffic.

Padma

Padma

        Mitchell Erblich
        Sr Software Engineer
        ---------------------------
Padma Pillay-Esnault wrote:

 Mitchell,
 First let me state that this feature can only operate if
 all the routers have an understanding on how to handle DNA
 LSA per rfc 1793.

Group,
        Sorry, just a few items to ponder :)

        1)

        This document does not discuss the implications of a
LSA
        being corrupted (LSA checksum failed) and then being
        discarded.
        Should we not do checksums on DNA LSAs?
        Can the router that is removing the failed checksum
LSA
        flood a earlier instance of the LSA? This hoping that
the
        LSA will be reflooded by the originator? Should it be
        stated here?

 I am not sure I understand your question.
 How does handling this case differ between a router
 implementing this
 draft and having a router implementing DC somewhere in your
 topology
 and emitting DNA LSAs?

        2)

        Should it be stated that this knob is per interface?

 This is stated in section 5.

        Should it be stated what happens if the knob is first
to
        have normal flooding, then reduced flooding or vice
versa,
        OR more simply stated the requirement to reflush the
LSA
        that are having their DNA bit changed?

 Do you mean to state that turning off the feature should cause
 all
 the LSAs to be reflooded with the DNA bit clear ? This seemed
 obvious
 to me. But any ways, on the first refresh of the LSA on the
 originating
 router this will cause the LSA to be flooded with the new
 sequence
 number and DNA bit clear.

        What is the implication of changing the knob twice
within
        the standard 5 secs of re-originating the same LSA?

 That would be implementation choice how to keep track of this.

        3)

        Should a DNA LSA be removed upon loss of an adj due
to
        the dead router interval expiring?

 This is part of rfc 1793 that when reachability to the router
 originating an LSA with DNA bit set is lost that LSA should be
 maxaged.

        4)

        **What is the implication that during the initial
flooding of
        the DNA LSA, that a temporary routing loop or a black
hole
        existed? This could even be due to mis-router
configuration?
        Now, after this temporary condition has cleared will
some
        routers never get the LSA?  In the past we could be
assured
        that we would eventually see the LSA....

 Any change in topology/configuration will result in LSA(s)
 being
 flooded so this will clear up.

        5)

        And lastly, should this document identify the
procedure
        for removing its originated LSA before a orderly
shutdown?

 This is covered by the non-reachability rule.

        Mitchell Erblich
        Sr Software Engineer
        -----------------------------------

 Padma




--------------040006020004040206060206-- From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 3 18:42:28 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20355 for ; Thu, 3 Apr 2003 18:42:28 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.009619D0@cherry.ease.lsoft.com>; Thu, 3 Apr 2003 18:44:17 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 717033 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 3 Apr 2003 18:44:16 -0500 Received: from 207.217.120.232 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 3 Apr 2003 18:44:16 -0500 Received: from user-2ivfjfm.dialup.mindspring.com ([165.247.205.246] helo=earthlink.net) by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 191ENR-0007G5-00 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 03 Apr 2003 15:44:13 -0800 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: <200304031704.h33H4rV84104@garnet.juniper.net> <3E8C7CA8.BDCE3DC8@earthlink.net> <3E8C92CF.1060008@juniper.net> <3E8CA857.618BFB54@earthlink.net> <3E8CB4AF.50907@juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E8CC6E9.485FF63C@earthlink.net> Date: Thu, 3 Apr 2003 15:42:33 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Internet Draft : OSPF Refresh and Flooding in Stable Topologies To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Padma, :) Comments inline.. Mitchell Erblich ------------- Padma Pillay-Esnault wrote: > > Erblichs wrote: > > > Padma Pillay_Esnault, > > I agree with your intention! > > However, in MY OPINION. > > 1) Decrease the flooding interval to maybe > > 50 minutes for LSAs without the DNA being > > set. Thus request that this archectural > > constant become a configurable parameter. > > > > There was a passage in the draft that mentionned this explicitly as > well as > its limitations. Our Chair asked me to remove it. You can bring it up > to > Acee. ;-) I could guess what his issue was. That is another proposal to decreasing refresh and flooding and felt that the scope of your document didn't need to specify every possible way to decrease.. > > > 2) Create a new capability that allows a minimal > > OOB request/ack for a single LSA over an adj > > with awareness of the LSA instance. > > - This would take care of a loss of synchronization > > due to checksum removal or some other loss. > > - Be able to have the request directed to the LSA > > originator when the below #3 header is identified. > > > > Not scalable in my opinion for a problem which is too rare and > autosolved > by a periodic force refresh. I agree that a periodic forced refresh is simpler, but using updates pkts is a very high overhead method. The main problem is with periodic refresh without a request mechanism is that on avg you have to wait 1/2 of the refresh interval. This "periodic force refresh" could be set to days, weeks, months, years" and that would effectively remove asynchronous flooding requirement from OSPF!!!!! If you have a request mechanism, that avg wait time is decreased to 2x delay of the link plus time to process the request. LSA headers for flooding is really lightweight vs update pkts with a miminally changing or Stable environment. However, if the environment changes, a rush of LSA reqs could significantly increase the amount of traffic. Yes, I thought about this... But I was working with a Stable env assumption. My #2 and #3 compliment each other. The #2 can get instance information supplied by #3. Implimenting #2 without #3 or #3 without #2 wouldn't make sense. > > > 3) Suggest a new flooding low-overhead flood capability > > using LSA headers (ala IS-IS) that is defaulted to > > re-xmit every 30 minutes but can be set higher. > > > > Problem that the LSAs will still die within 1hr. This draft gets more > flexibility. > Yes, I am not removing the 1 hour timeframe. However, this SUGGESTION should significantly decrease the number of bytes be flooded, which significantly decreases the amount of overhead in the flooding process for a STABLE TOPOLOGY. Yes, my suggestion still would require each router to process the header packets and make LSA comparisons. With the new header information, my #2 suggestion would then be able to take the instance and do a "Initial DBD Synchronization" like comparison for a single LSA and follow up with a req / ack communication. > > 4) Define a method for backward compatibility. > > > > How is this draft not backward compatible ? Noooo, yours draft is okay wrt this item.. What I was suggesting would need a section for backward compatiblity. > > > Mitchell Erblich > > Sr Software Engineer > > ======================== > > Padma Pillay-Esnault wrote: > > > >> See below > >> Erblichs wrote: > >> > >> > Lets try inlining this time.. > >> > Mitchell Erblich > >> > Sr Software Engineer > >> > ---------- > >> > Padma Pillay-Esnault wrote: > >> > > >> >> Mitchell Erblich, > >> >> > >> >> > Padma Pillay-Esnault, > >> >> > Let me re-phrase the first question. > >> >> > 1) One of the most common methods that a > >> >> > stable OSPF router does is the periodic > >> >> > verification of the checksums of > >> >> > LSAs within its database. > >> >> > Upon checksum verifcation failure and > >> >> > removal, (router just removes the bad > >> >> > LSA and marks the memory location as > >> >> > suspect) then non-aynchronous flooding > >> >> > will not resubmit the removed LSA.... > >> >> > Note: With the draft that deals with > >> >> > the later re-Initial Database Synchronization > >> >> > work, we can get back the LSA if the > >> >> > adj hasn't also removed it. But not > >> >> > yet.. > >> >> > > >> >> What is this work ?? > >> >> > >> > OSPF Out-of-band LSDB resynchronization > >> > by Alex Zinn and Abhay Roy > >> > Cisco, Feb 2001 > >> > And truly, I don't know what is happening with it??? > >> > > >> >> > So, you then break the assumption that > >> >> > all routers within an area must have the > >> >> > same LSAs in their database????? > >> >> > > >> >> No. The LSA contents are the same. > >> >> > >> >> > You just forced us to > >> >> > take doown the interface > >> >> > if we have a DNA LSA on a non-DC configured > >> >> > interface and we fail a checksum? Right??? > >> >> > (Actually, identify the adj that submitted > >> >> > us the LSA, and remove him from the next > >> >> > hello, then...redo the Init DB Sync) > >> >> > > >> >> I usually don't force anyone ;-) > >> >> ???- Are you referring to the work above ? > >> >> > >> > Yes... > >> > > >> I think this draft is for a issue orthogonal to mine and let's not > >> mix > >> them. > >> > >> >> > *** Yes, This problem was not reported to > >> >> > me early on dealing with demand-circuits! > >> >> > I don't know why other people dont't see > >> >> > this. Maybe people have perfect memory or > >> >> > they just don't run the checksuming algorithm. > >> >> > The current solution is to restart the > >> >> > DC interface where the LSDB originated to > >> >> > restart the Initial Database Synchronization. > >> >> > Else, we wait for the asynchronous re-submit of > >> >> > the LSA. It depends on the time that we last saw > >> >> > the LSA instance. > >> >> > But now you are making it apply to all > >> >> > interfaces / adjs ... > >> >> > > >> >> Let assume that what you say happens in a regular topology - > >> >> an LSA gets corrupted and discarded then the SPF should run and > >> >> this route and others including it in their SPF calculation > >> >> should be discarded. Hence we will lose routes for at the > >> >> maximum > >> >> 30 minutes. I have not heard anyone complain about such a > >> >> problem > >> >> in normal. I believe that it is very rare if it indeeds > >> >> happens. > >> >> > >> > Maybe implimentations are skipping the periodic checksum. > >> > The 30 minutes is assuming that asynchronous flooding > >> > will > >> > occur started at the originator. Your draft changes from > >> > 30 minutes to whenever the originator refloods the LSA if > >> > ever. So, a route can now be lost for an undeterminate > >> > amount of time, if you don't do anything. I don't think > >> > that > >> > is good. > >> > BTW, If our current dyanmic SPF wait interval (see > >> > Cisco's > >> > SPF Throttling Paper on their web site) which > >> > approximates > >> > this paper, (max of 600,000 ms) is less than the expected > >> > time of reflush of the removed LSA, we then wait for the > >> > reflood. > >> > > >> This draft does not introduce any new issue from the rfc 1793. > >> More > >> over, Section 5 > >> mentions the forced periodic forced flooding. The parameter to be > >> configured to > >> whatever they want and hence still have a flooding of LSAs. > >> > >> >> > 2) Oops, section 5 does specify interfaces or > >> >> > globaly. > >> >> > 3) Let me state this one.. Reachability in the > >> >> > Demand Circuit is 1 hr, etc. Shouldn't your > >> >> > document state that reachability is based > >> >> > on Dead Router Interval? You reference a > >> >> > doc and take some things from it and leave > >> >> > this type of item "explicitly unstated". > >> >> > > >> >> Remember that this is *not* DC. We are not setting DC bit > >> >> in the hellos or in the DBD packets. So it is Dead Interval. > >> >> > >> > Yes, but shouldn't you possibly want to state > >> > this in the RFC? > >> > > >> It can be stated. > >> > >> >> > 4) Are you stating reflooding by the LSA orignator? > >> >> > What happens if the originator doesn't see > >> >> > the change? The orignator will not reflood > >> >> > the LSA... > >> >> > > >> >> If the originator doesn't see a change that should cause a > >> >> change in contents in its LSA then there is a bug ;-) > >> >> > >> >> > ` 5) The non-reachability rule for Demand-Circuit > >> >> > specifies 1 hr, but for normal routers specify > >> >> > dead-router interval? Which one should we > >> >> > follow? Shouldn't it explicitly be stated in > >> >> > the document? > >> >> > > >> >> See response 3. > >> >> > >> >> > Remember, I stated an orderly shutdown. Why > >> >> > don't we reflood with MAX-AGE, to remove > >> >> > un-necessary LSAs? This is analgous to RIP's > >> >> > poisson reverse something... > >> >> > > >> >> This is an implementation decision. When you lose your > >> >> adjacency, > >> >> the LSA from the originating router will not be used in the spf > >> >> anyway. Flooding MAXAGE LSA can be very expensive while the > >> >> lingering LSAs will not be used in the SPF anyway. So, some > >> >> believe it is useless. > >> >> > >> > Well Moy does the former in his book and I agree with > >> > his decision. See the shutdown function. > >> > > >> Let me put it like this .. my draft is about eliminating > >> unneccessary > >> protocol > >> traffic .. and the maxaging on going out is unnecessary traffic. > >> Padma > >> > >> >> Padma > >> >> > >> >> > Mitchell Erblich > >> >> > Sr Software Engineer > >> >> > --------------------------- > >> >> > Padma Pillay-Esnault wrote: > >> >> > > >> >> >> Mitchell, > >> >> >> First let me state that this feature can only operate if > >> >> >> all the routers have an understanding on how to handle DNA > >> >> >> LSA per rfc 1793. > >> >> >> > >> >> >> > Group, > >> >> >> > Sorry, just a few items to ponder :) > >> >> >> > > >> >> > 1) > >> >> > > >> >> >> > This document does not discuss the implications of > >> >> >> > a > >> >> >> > LSA > >> >> >> > being corrupted (LSA checksum failed) and then > >> >> >> > being > >> >> >> > discarded. > >> >> >> > Should we not do checksums on DNA LSAs? > >> >> >> > Can the router that is removing the failed > >> >> >> > checksum > >> >> >> > LSA > >> >> >> > flood a earlier instance of the LSA? This hoping > >> >> >> > that > >> >> >> > the > >> >> >> > LSA will be reflooded by the originator? Should it > >> >> >> > be > >> >> >> > stated here? > >> >> >> > > >> >> >> I am not sure I understand your question. > >> >> >> How does handling this case differ between a router > >> >> >> implementing this > >> >> >> draft and having a router implementing DC somewhere in your > >> >> >> topology > >> >> >> and emitting DNA LSAs? > >> >> >> > >> >> > 2) > >> >> > > >> >> >> > Should it be stated that this knob is per > >> >> >> > interface? > >> >> >> > > >> >> >> This is stated in section 5. > >> >> >> > >> >> >> > Should it be stated what happens if the knob is > >> >> >> > first > >> >> >> > to > >> >> >> > have normal flooding, then reduced flooding or > >> >> >> > vice > >> >> >> > versa, > >> >> >> > OR more simply stated the requirement to reflush > >> >> >> > the > >> >> >> > LSA > >> >> >> > that are having their DNA bit changed? > >> >> >> > > >> >> >> Do you mean to state that turning off the feature should > >> >> >> cause > >> >> >> all > >> >> >> the LSAs to be reflooded with the DNA bit clear ? This > >> >> >> seemed > >> >> >> obvious > >> >> >> to me. But any ways, on the first refresh of the LSA on the > >> >> >> originating > >> >> >> router this will cause the LSA to be flooded with the new > >> >> >> sequence > >> >> >> number and DNA bit clear. > >> >> >> > >> >> >> > What is the implication of changing the knob twice > >> >> >> > within > >> >> >> > the standard 5 secs of re-originating the same > >> >> >> > LSA? > >> >> >> > > >> >> >> That would be implementation choice how to keep track of > >> >> >> this. > >> >> >> > >> >> > 3) > >> >> > > >> >> >> > Should a DNA LSA be removed upon loss of an adj > >> >> >> > due > >> >> >> > to > >> >> >> > the dead router interval expiring? > >> >> >> > > >> >> >> This is part of rfc 1793 that when reachability to the > >> >> >> router > >> >> >> originating an LSA with DNA bit set is lost that LSA should > >> >> >> be > >> >> >> maxaged. > >> >> >> > >> >> > 4) > >> >> > > >> >> >> > **What is the implication that during the initial > >> >> >> > flooding of > >> >> >> > the DNA LSA, that a temporary routing loop or a > >> >> >> > black > >> >> >> > hole > >> >> >> > existed? This could even be due to mis-router > >> >> >> > configuration? > >> >> >> > Now, after this temporary condition has cleared > >> >> >> > will > >> >> >> > some > >> >> >> > routers never get the LSA? In the past we could > >> >> >> > be > >> >> >> > assured > >> >> >> > that we would eventually see the LSA.... > >> >> >> > > >> >> >> Any change in topology/configuration will result in LSA(s) > >> >> >> being > >> >> >> flooded so this will clear up. > >> >> >> > >> >> > 5) > >> >> > > >> >> >> > And lastly, should this document identify the > >> >> >> > procedure > >> >> >> > for removing its originated LSA before a orderly > >> >> >> > shutdown? > >> >> >> > > >> >> >> This is covered by the non-reachability rule. > >> >> >> > >> >> >> > Mitchell Erblich > >> >> >> > Sr Software Engineer > >> >> >> > ----------------------------------- > >> >> >> > > >> >> >> Padma > >> >> >> From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 4 04:22:32 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11915 for ; Fri, 4 Apr 2003 04:22:31 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00962710@cherry.ease.lsoft.com>; Fri, 4 Apr 2003 4:23:58 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 717853 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 4 Apr 2003 04:23:58 -0500 Received: from 203.199.83.39 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 4 Apr 2003 04:23:56 -0500 Received: (qmail 6001 invoked by uid 510); 4 Apr 2003 09:22:16 -0000 Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 04 apr 2003 09:22:16 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20030404092216.6000.qmail@webmail29.rediffmail.com> Date: Fri, 4 Apr 2003 09:22:16 -0000 Reply-To: Mailing List Sender: Mailing List From: Krishna Rao Subject: Graceful Restart To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, draft-ietf-ospf-hitless-restart-07.txt: 2. Operation of restarting router: Point 2) If the restarting router determines that it was Designated Router on a given segment immediately prior to the restart, it elects itself as Designated Router again Q1)Why does this need to be done while restarting? AND How does it help ?? Q2)What if normal DR/BDR election takes place "on exiting graceful restart" thanks, krishna On Fri, 04 Apr 2003 Erblichs wrote : >Padma, :) > > Comments inline.. > > Mitchell Erblich > ------------- > >Padma Pillay-Esnault wrote: > > > > Erblichs wrote: > > > > > Padma Pillay_Esnault, > > > I agree with your intention! > > > However, in MY OPINION. > > > 1) Decrease the flooding interval to maybe > > > 50 minutes for LSAs without the DNA being > > > set. Thus request that this archectural > > > constant become a configurable parameter. > > > > > > > There was a passage in the draft that mentionned this >explicitly as > > well as > > its limitations. Our Chair asked me to remove it. You can >bring it up > > to > > Acee. ;-) > > I could guess what his issue was. That is >another > proposal to decreasing refresh and flooding >and > felt that the scope of your document didn't >need > to specify every possible way to decrease.. > > > > > > 2) Create a new capability that allows a minimal > > > OOB request/ack for a single LSA over an adj > > > with awareness of the LSA instance. > > > - This would take care of a loss of >synchronization > > > due to checksum removal or some other loss. > > > - Be able to have the request directed to the >LSA > > > originator when the below #3 header is >identified. > > > > > > > Not scalable in my opinion for a problem which is too rare >and > > autosolved > > by a periodic force refresh. > > I agree that a periodic forced refresh is >simpler, but > using updates pkts is a very high overhead >method. The main > problem is with periodic refresh without a >request mechanism > is that on avg you have to wait 1/2 of the >refresh interval. > This "periodic force refresh" could be set to >days, weeks, > months, years" and that would effectively remove >asynchronous > flooding requirement from OSPF!!!!! > > If you have a request mechanism, that avg wait >time is > decreased to 2x delay of the link plus time to >process the > request. LSA headers for flooding is really >lightweight vs > update pkts with a miminally changing or Stable >environment. > However, if the environment changes, a rush of >LSA reqs > could significantly increase the amount of >traffic. Yes, > I thought about this... But I was working with a >Stable env > assumption. > > My #2 and #3 compliment each other. The #2 can >get instance > information supplied by #3. Implimenting #2 >without #3 or > #3 without #2 wouldn't make sense. > > > > > 3) Suggest a new flooding low-overhead flood >capability > > > using LSA headers (ala IS-IS) that is defaulted >to > > > re-xmit every 30 minutes but can be set higher. > > > > > > > Problem that the LSAs will still die within 1hr. This draft >gets more > > flexibility. > > > > Yes, I am not removing the 1 hour timeframe. >However, this SUGGESTION > should significantly decrease the number of >bytes be flooded, >which > significantly decreases the amount of overhead >in the flooding process > for a STABLE TOPOLOGY. Yes, my suggestion still >would require each >router > to process the header packets and make LSA >comparisons. > > With the new header information, my #2 >suggestion would then be able >to > take the instance and do a "Initial DBD >Synchronization" like >comparison > for a single LSA and follow up with a req / ack >communication. > > > > > > > 4) Define a method for backward compatibility. > > > > > > > How is this draft not backward compatible ? > > Noooo, yours draft is okay wrt this item.. What >I was suggesting would > need a section for backward compatiblity. > > > > > > Mitchell Erblich > > > Sr Software Engineer > > > ======================== > > > Padma Pillay-Esnault wrote: > > > > > >> See below > > >> Erblichs wrote: > > >> > > >> > Lets try inlining this time.. > > >> > Mitchell Erblich > > >> > Sr Software Engineer > > >> > ---------- > > >> > Padma Pillay-Esnault wrote: > > >> > > > >> >> Mitchell Erblich, > > >> >> > > >> >> > Padma Pillay-Esnault, > > >> >> > Let me re-phrase the first question. > > >> >> > 1) One of the most common methods that a > > >> >> > stable OSPF router does is the periodic > > >> >> > verification of the checksums of > > >> >> > LSAs within its database. > > >> >> > Upon checksum verifcation failure and > > >> >> > removal, (router just removes the bad > > >> >> > LSA and marks the memory location as > > >> >> > suspect) then non-aynchronous flooding > > >> >> > will not resubmit the removed LSA.... > > >> >> > Note: With the draft that deals with > > >> >> > the later re-Initial Database >Synchronization > > >> >> > work, we can get back the LSA if the > > >> >> > adj hasn't also removed it. But not > > >> >> > yet.. > > >> >> > > > >> >> What is this work ?? > > >> >> > > >> > OSPF Out-of-band LSDB resynchronization > > >> > by Alex Zinn and Abhay Roy > > >> > Cisco, Feb 2001 > > >> > And truly, I don't know what is happening with >it??? > > >> > > > >> >> > So, you then break the assumption that > > >> >> > all routers within an area must have the > > >> >> > same LSAs in their database????? > > >> >> > > > >> >> No. The LSA contents are the same. > > >> >> > > >> >> > You just forced us to > > >> >> > take doown the interface > > >> >> > if we have a DNA LSA on a non-DC configured > > >> >> > interface and we fail a checksum? Right??? > > >> >> > (Actually, identify the adj that submitted > > >> >> > us the LSA, and remove him from the next > > >> >> > hello, then...redo the Init DB Sync) > > >> >> > > > >> >> I usually don't force anyone ;-) > > >> >> ???- Are you referring to the work above ? > > >> >> > > >> > Yes... > > >> > > > >> I think this draft is for a issue orthogonal to mine and >let's not > > >> mix > > >> them. > > >> > > >> >> > *** Yes, This problem was not reported to > > >> >> > me early on dealing with demand-circuits! > > >> >> > I don't know why other people dont't see > > >> >> > this. Maybe people have perfect memory or > > >> >> > they just don't run the checksuming >algorithm. > > >> >> > The current solution is to restart the > > >> >> > DC interface where the LSDB originated to > > >> >> > restart the Initial Database >Synchronization. > > >> >> > Else, we wait for the asynchronous re-submit >of > > >> >> > the LSA. It depends on the time that we last >saw > > >> >> > the LSA instance. > > >> >> > But now you are making it apply to all > > >> >> > interfaces / adjs ... > > >> >> > > > >> >> Let assume that what you say happens in a regular >topology - > > >> >> an LSA gets corrupted and discarded then the SPF should >run and > > >> >> this route and others including it in their SPF >calculation > > >> >> should be discarded. Hence we will lose routes for at >the > > >> >> maximum > > >> >> 30 minutes. I have not heard anyone complain about such >a > > >> >> problem > > >> >> in normal. I believe that it is very rare if it >indeeds > > >> >> happens. > > >> >> > > >> > Maybe implimentations are skipping the periodic >checksum. > > >> > The 30 minutes is assuming that asynchronous >flooding > > >> > will > > >> > occur started at the originator. Your draft >changes from > > >> > 30 minutes to whenever the originator refloods >the LSA if > > >> > ever. So, a route can now be lost for an >undeterminate > > >> > amount of time, if you don't do anything. I don't >think > > >> > that > > >> > is good. > > >> > BTW, If our current dyanmic SPF wait interval >(see > > >> > Cisco's > > >> > SPF Throttling Paper on their web site) which > > >> > approximates > > >> > this paper, (max of 600,000 ms) is less than the >expected > > >> > time of reflush of the removed LSA, we then wait >for the > > >> > reflood. > > >> > > > >> This draft does not introduce any new issue from the rfc >1793. > > >> More > > >> over, Section 5 > > >> mentions the forced periodic forced flooding. The parameter >to be > > >> configured to > > >> whatever they want and hence still have a flooding of >LSAs. > > >> > > >> >> > 2) Oops, section 5 does specify interfaces >or > > >> >> > globaly. > > >> >> > 3) Let me state this one.. Reachability in >the > > >> >> > Demand Circuit is 1 hr, etc. Shouldn't >your > > >> >> > document state that reachability is based > > >> >> > on Dead Router Interval? You reference a > > >> >> > doc and take some things from it and >leave > > >> >> > this type of item "explicitly unstated". > > >> >> > > > >> >> Remember that this is *not* DC. We are not setting DC >bit > > >> >> in the hellos or in the DBD packets. So it is Dead >Interval. > > >> >> > > >> > Yes, but shouldn't you possibly want to >state > > >> > this in the RFC? > > >> > > > >> It can be stated. > > >> > > >> >> > 4) Are you stating reflooding by the LSA >orignator? > > >> >> > What happens if the originator doesn't >see > > >> >> > the change? The orignator will not >reflood > > >> >> > the LSA... > > >> >> > > > >> >> If the originator doesn't see a change that should >cause a > > >> >> change in contents in its LSA then there is a bug ;-) > > >> >> > > >> >> > ` 5) The non-reachability rule for >Demand-Circuit > > >> >> > specifies 1 hr, but for normal routers >specify > > >> >> > dead-router interval? Which one should we > > >> >> > follow? Shouldn't it explicitly be stated >in > > >> >> > the document? > > >> >> > > > >> >> See response 3. > > >> >> > > >> >> > Remember, I stated an orderly shutdown. >Why > > >> >> > don't we reflood with MAX-AGE, to remove > > >> >> > un-necessary LSAs? This is analgous to >RIP's > > >> >> > poisson reverse something... > > >> >> > > > >> >> This is an implementation decision. When you lose >your > > >> >> adjacency, > > >> >> the LSA from the originating router will not be used in >the spf > > >> >> anyway. Flooding MAXAGE LSA can be very expensive while >the > > >> >> lingering LSAs will not be used in the SPF anyway. So, >some > > >> >> believe it is useless. > > >> >> > > >> > Well Moy does the former in his book and I agree >with > > >> > his decision. See the shutdown function. > > >> > > > >> Let me put it like this .. my draft is about eliminating > > >> unneccessary > > >> protocol > > >> traffic .. and the maxaging on going out is unnecessary >traffic. > > >> Padma > > >> > > >> >> Padma > > >> >> > > >> >> > Mitchell Erblich > > >> >> > Sr Software Engineer > > >> >> > --------------------------- > > >> >> > Padma Pillay-Esnault wrote: > > >> >> > > > >> >> >> Mitchell, > > >> >> >> First let me state that this feature can only >operate if > > >> >> >> all the routers have an understanding on how to >handle DNA > > >> >> >> LSA per rfc 1793. > > >> >> >> > > >> >> >> > Group, > > >> >> >> > Sorry, just a few items to ponder :) > > >> >> >> > > > >> >> > 1) > > >> >> > > > >> >> >> > This document does not discuss the >implications of > > >> >> >> > a > > >> >> >> > LSA > > >> >> >> > being corrupted (LSA checksum failed) and >then > > >> >> >> > being > > >> >> >> > discarded. > > >> >> >> > Should we not do checksums on DNA LSAs? > > >> >> >> > Can the router that is removing the >failed > > >> >> >> > checksum > > >> >> >> > LSA > > >> >> >> > flood a earlier instance of the LSA? This >hoping > > >> >> >> > that > > >> >> >> > the > > >> >> >> > LSA will be reflooded by the originator? >Should it > > >> >> >> > be > > >> >> >> > stated here? > > >> >> >> > > > >> >> >> I am not sure I understand your question. > > >> >> >> How does handling this case differ between a >router > > >> >> >> implementing this > > >> >> >> draft and having a router implementing DC somewhere >in your > > >> >> >> topology > > >> >> >> and emitting DNA LSAs? > > >> >> >> > > >> >> > 2) > > >> >> > > > >> >> >> > Should it be stated that this knob is per > > >> >> >> > interface? > > >> >> >> > > > >> >> >> This is stated in section 5. > > >> >> >> > > >> >> >> > Should it be stated what happens if the >knob is > > >> >> >> > first > > >> >> >> > to > > >> >> >> > have normal flooding, then reduced flooding >or > > >> >> >> > vice > > >> >> >> > versa, > > >> >> >> > OR more simply stated the requirement to >reflush > > >> >> >> > the > > >> >> >> > LSA > > >> >> >> > that are having their DNA bit changed? > > >> >> >> > > > >> >> >> Do you mean to state that turning off the feature >should > > >> >> >> cause > > >> >> >> all > > >> >> >> the LSAs to be reflooded with the DNA bit clear ? >This > > >> >> >> seemed > > >> >> >> obvious > > >> >> >> to me. But any ways, on the first refresh of the >LSA on the > > >> >> >> originating > > >> >> >> router this will cause the LSA to be flooded with >the new > > >> >> >> sequence > > >> >> >> number and DNA bit clear. > > >> >> >> > > >> >> >> > What is the implication of changing the >knob twice > > >> >> >> > within > > >> >> >> > the standard 5 secs of re-originating the >same > > >> >> >> > LSA? > > >> >> >> > > > >> >> >> That would be implementation choice how to keep >track of > > >> >> >> this. > > >> >> >> > > >> >> > 3) > > >> >> > > > >> >> >> > Should a DNA LSA be removed upon loss of an >adj > > >> >> >> > due > > >> >> >> > to > > >> >> >> > the dead router interval expiring? > > >> >> >> > > > >> >> >> This is part of rfc 1793 that when reachability to >the > > >> >> >> router > > >> >> >> originating an LSA with DNA bit set is lost that >LSA should > > >> >> >> be > > >> >> >> maxaged. > > >> >> >> > > >> >> > 4) > > >> >> > > > >> >> >> > **What is the implication that during the >initial > > >> >> >> > flooding of > > >> >> >> > the DNA LSA, that a temporary routing loop >or a > > >> >> >> > black > > >> >> >> > hole > > >> >> >> > existed? This could even be due to >mis-router > > >> >> >> > configuration? > > >> >> >> > Now, after this temporary condition has >cleared > > >> >> >> > will > > >> >> >> > some > > >> >> >> > routers never get the LSA? In the past we >could > > >> >> >> > be > > >> >> >> > assured > > >> >> >> > that we would eventually see the LSA.... > > >> >> >> > > > >> >> >> Any change in topology/configuration will result in >LSA(s) > > >> >> >> being > > >> >> >> flooded so this will clear up. > > >> >> >> > > >> >> > 5) > > >> >> > > > >> >> >> > And lastly, should this document identify >the > > >> >> >> > procedure > > >> >> >> > for removing its originated LSA before a >orderly > > >> >> >> > shutdown? > > >> >> >> > > > >> >> >> This is covered by the non-reachability rule. > > >> >> >> > > >> >> >> > Mitchell Erblich > > >> >> >> > Sr Software Engineer > > >> >> >> > ----------------------------------- > > >> >> >> > > > >> >> >> Padma > > >> >> >> _______________________________________________________________________ Odomos - the only mosquito protection outside 4 walls - Click here to know more! http://r.rediff.com/r?http://clients.rediff.com/odomos/Odomos.htm&&odomos&&wn From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 4 04:42:39 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12506 for ; Fri, 4 Apr 2003 04:42:39 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.0096287A@cherry.ease.lsoft.com>; Fri, 4 Apr 2003 4:45:07 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 717894 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 4 Apr 2003 04:45:07 -0500 Received: from 203.199.83.24 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 4 Apr 2003 04:45:07 -0500 Received: (qmail 14907 invoked by uid 510); 4 Apr 2003 09:43:34 -0000 Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 04 apr 2003 09:43:34 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20030404094334.14906.qmail@webmail14.rediffmail.com> Date: Fri, 4 Apr 2003 09:43:34 -0000 Reply-To: Mailing List Sender: Mailing List From: Krishna Rao Subject: Re: NSSA ABR To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Vishwas, Then why not prevent such a router from going through NSSA Translator election at all. Any NSSA ABR having no Normal Ospf area, should not go for Translator election ? Does it make sense and worth the effort? Or such scenarios occur rarely ?? krishna On Wed, 26 Mar 2003 Manral, Vishwas wrote : >Hi Krishna, > >Interesting question !!!! > >It will not qualify for the translator election on other routers >as E-bit >cannot be set on an ABR, with an NSSA and a stub area into the >stub area. > >The following statements are relevent: - >" All NSSA border routers must set the E-bit in the Type-1 >router-LSAs > of their directly attached non-stub areas, even when they are >not > translating. This allows other NSSA border routers to see >their ASBR > status across the AS's transit topology. Failure to do so >may cause > the election algorithm to elect unnecessary translators. >" >besides >" An NSSA border router whose NSSA's NSSATranslatorRole is set >to > Candidate must maintain a list of the NSSA's border routers >that are > reachable both over the NSSA and as ASBRs over the AS's >transit > topology. >" > >So although the router becomes the translator(win the translator >election on >itself alone), it will not translate because it is attached to >stub. Besides >it will allow other ABR's to become translator as it will not >qualify for >their translator election. > >Thanks, >Vishwas > > > >-----Original Message----- > From: Krishna Rao [mailto:ospf_query@REDIFFMAIL.COM] >Sent: Wednesday, March 26, 2003 6:00 PM >To: OSPF@DISCUSS.MICROSOFT.COM >Subject: NSSA ABR > > >Hi, >Suppose a router has two areas of which >one is NSSA and the other is stub area. >Does it qualify to be NSSA ABR and take >part in NSSA Translator election ?? > >thanks, >krishna > > > > > > > > >On Mon, 24 Feb 2003 Krishna Rao wrote : > >Hi, > >Is there any difference between NSSA draft 11 and NSSA RFC >3101 > >as per protocol functionality? > >Or NSSA draft 11 is made into standard RFC 3101?? > > > >thanks, > >krishna > > > > > > > >On Mon, 24 Feb 2003 Rohit Gupta wrote : > >>Acee, > >> > > >> > Externally, origination should appear as the latter. > >> > However, keep in mind that the only time flooding > >> > can be suppressed is if an LSA is MaxAged while > >> > waiting MinLSInterval to expire AND the sequence > >> > number is the initial sequence number (0x80000001). > >> > >>And what if its not ISN. In my particular case it wont > >>be! > >> > >>Theoretically i understand that the latter is the > >>desired behaviour but do implementations actually do > >>that when sending a MaxAge LSA (scan thru the Rxmt > >>lists, etc and block the origination!) > >> > >> > > >> > > > >> > > Given the granularity of this timer (and maybe > >> > some > >> > > others too!) isnt it a little difficult to achieve > >> > > sub-second convergence? > >> > > >> > This OSPF constant can delay convergence but it > >> > is more a factor with router LSAs. For external > >> > LSAs, > >> > I think you want some holddown between originations > >> > and I don't think 5 seconds is unreasonable. > >> > >>But this timer is applied for all the LSAs .. > >>including the Router LSA. AS-External-LSA was just an > >>example which i was taking .. > >> > >>Has anyone thought on these lines or is there some > >>work which has been done over this. > >> > >>I for one would certainly be interested in knowing > >>more about it. > >> > >>Regards, > >>Rohit > >> > >> > >> > >> > >> > >>__________________________________________________ > >>Do you Yahoo!? > >>Yahoo! Tax Center - forms, calculators, tips, more > >>http://taxes.yahoo.com/ > >_______________________________________________________________________ >Odomos - the only mosquito protection outside 4 walls - >Click here to know more! >http://r.rediff.com/r?http://clients.rediff.com/odomos/Odomos.htm&&odomos&&w >n _______________________________________________________________________ Odomos - the only mosquito protection outside 4 walls - Click here to know more! http://r.rediff.com/r?http://clients.rediff.com/odomos/Odomos.htm&&odomos&&wn From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 4 06:52:32 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16945 for ; Fri, 4 Apr 2003 06:52:32 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00962AB9@cherry.ease.lsoft.com>; Fri, 4 Apr 2003 6:54:14 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 718308 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 4 Apr 2003 06:54:14 -0500 Received: from 216.136.226.140 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 4 Apr 2003 06:54:14 -0500 Received: from [203.200.20.226] by web20505.mail.yahoo.com via HTTP; Fri, 04 Apr 2003 12:54:13 BST MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <20030404115413.36400.qmail@web20505.mail.yahoo.com> Date: Fri, 4 Apr 2003 12:54:13 +0100 Reply-To: Mailing List Sender: Mailing List From: =?iso-8859-1?q?John=20Smith?= Subject: Re: Graceful Restart To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit Krishna, my 2 euros (dollars are out !!!) > > draft-ietf-ospf-hitless-restart-07.txt: > 2. Operation of restarting router: > > Point 2) If the restarting router determines that it was > Designated > Router on a given segment immediately prior to the > restart, > it elects itself as Designated Router again > > Q1)Why does this need to be done while restarting? > AND > How does it help ?? Its helps in maintaining sanity in the network. Others think that this router is still up and continue trusting him as DR. When he comes up he should not break this trust and should ideally start operating as a DR. The basic concept is that if he resigns from DRship then the BDR will take over and they will need to again re-elect the BDR .. which is a messy affair. The whole point of graceful restart is to avoid such events !! > > Q2)What if normal DR/BDR election takes place "on exiting > graceful restart" Why do you want to land in this mess? You will again need to re-issue your LSAs, etc. Everybody will have to re-synch .. and the whole purpose of graceful restart will be defeated. Others more informed about this protocol can correct me whatever i missed out! JS __________________________________________________ Yahoo! Plus For a better Internet experience http://www.yahoo.co.uk/btoffer From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 4 06:56:47 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17401 for ; Fri, 4 Apr 2003 06:56:47 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00962C02@cherry.ease.lsoft.com>; Fri, 4 Apr 2003 6:59:16 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 718338 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 4 Apr 2003 06:59:16 -0500 Received: from 136.182.1.10 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 4 Apr 2003 06:59:16 -0500 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h34BxO91006041 for ; Fri, 4 Apr 2003 04:59:24 -0700 (MST) Received: [from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id EAA29902 for ; Fri, 4 Apr 2003 04:59:15 -0700 (MST)] Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id <2D45CDFY>; Fri, 4 Apr 2003 06:59:09 -0500 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, 4 Apr 2003 07:00:59 -0500 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: NSSA ABR To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Krishna, It works fine even in the special case you mentioned. I guess we could always add a statement about this special scenario, but as the RFC treats the case corrrectly we could do without it. Thanks, Vishwas -----Original Message----- From: Krishna Rao [mailto:ospf_query@REDIFFMAIL.COM] Sent: Friday, April 04, 2003 3:14 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: NSSA ABR Hi Vishwas, Then why not prevent such a router from going through NSSA Translator election at all. Any NSSA ABR having no Normal Ospf area, should not go for Translator election ? Does it make sense and worth the effort? Or such scenarios occur rarely ?? krishna On Wed, 26 Mar 2003 Manral, Vishwas wrote : >Hi Krishna, > >Interesting question !!!! > >It will not qualify for the translator election on other routers >as E-bit >cannot be set on an ABR, with an NSSA and a stub area into the >stub area. > >The following statements are relevent: - >" All NSSA border routers must set the E-bit in the Type-1 >router-LSAs > of their directly attached non-stub areas, even when they are >not > translating. This allows other NSSA border routers to see >their ASBR > status across the AS's transit topology. Failure to do so >may cause > the election algorithm to elect unnecessary translators. >" >besides >" An NSSA border router whose NSSA's NSSATranslatorRole is set >to > Candidate must maintain a list of the NSSA's border routers >that are > reachable both over the NSSA and as ASBRs over the AS's >transit > topology. >" > >So although the router becomes the translator(win the translator >election on >itself alone), it will not translate because it is attached to >stub. Besides >it will allow other ABR's to become translator as it will not >qualify for >their translator election. > >Thanks, >Vishwas > > > >-----Original Message----- > From: Krishna Rao [mailto:ospf_query@REDIFFMAIL.COM] >Sent: Wednesday, March 26, 2003 6:00 PM >To: OSPF@DISCUSS.MICROSOFT.COM >Subject: NSSA ABR > > >Hi, >Suppose a router has two areas of which >one is NSSA and the other is stub area. >Does it qualify to be NSSA ABR and take >part in NSSA Translator election ?? > >thanks, >krishna > > > > > > > > >On Mon, 24 Feb 2003 Krishna Rao wrote : > >Hi, > >Is there any difference between NSSA draft 11 and NSSA RFC >3101 > >as per protocol functionality? > >Or NSSA draft 11 is made into standard RFC 3101?? > > > >thanks, > >krishna > > > > > > > >On Mon, 24 Feb 2003 Rohit Gupta wrote : > >>Acee, > >> > > >> > Externally, origination should appear as the latter. > >> > However, keep in mind that the only time flooding > >> > can be suppressed is if an LSA is MaxAged while > >> > waiting MinLSInterval to expire AND the sequence > >> > number is the initial sequence number (0x80000001). > >> > >>And what if its not ISN. In my particular case it wont > >>be! > >> > >>Theoretically i understand that the latter is the > >>desired behaviour but do implementations actually do > >>that when sending a MaxAge LSA (scan thru the Rxmt > >>lists, etc and block the origination!) > >> > >> > > >> > > > >> > > Given the granularity of this timer (and maybe > >> > some > >> > > others too!) isnt it a little difficult to achieve > >> > > sub-second convergence? > >> > > >> > This OSPF constant can delay convergence but it > >> > is more a factor with router LSAs. For external > >> > LSAs, > >> > I think you want some holddown between originations > >> > and I don't think 5 seconds is unreasonable. > >> > >>But this timer is applied for all the LSAs .. > >>including the Router LSA. AS-External-LSA was just an > >>example which i was taking .. > >> > >>Has anyone thought on these lines or is there some > >>work which has been done over this. > >> > >>I for one would certainly be interested in knowing > >>more about it. > >> > >>Regards, > >>Rohit > >> > >> > >> > >> > >> > >>__________________________________________________ > >>Do you Yahoo!? > >>Yahoo! Tax Center - forms, calculators, tips, more > >>http://taxes.yahoo.com/ > >_______________________________________________________________________ >Odomos - the only mosquito protection outside 4 walls - >Click here to know more! >http://r.rediff.com/r?http://clients.rediff.com/odomos/Odomos.htm&&odomos&& w >n _______________________________________________________________________ Odomos - the only mosquito protection outside 4 walls - Click here to know more! http://r.rediff.com/r?http://clients.rediff.com/odomos/Odomos.htm&&odomos&&w n From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 4 06:58:24 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17442 for ; Fri, 4 Apr 2003 06:58:24 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00962BD4@cherry.ease.lsoft.com>; Fri, 4 Apr 2003 7:00:54 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 718368 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 4 Apr 2003 07:00:54 -0500 Received: from 216.136.226.143 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 4 Apr 2003 07:00:54 -0500 Received: from [203.200.20.226] by web20508.mail.yahoo.com via HTTP; Fri, 04 Apr 2003 13:00:53 BST MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <20030404120053.54360.qmail@web20508.mail.yahoo.com> Date: Fri, 4 Apr 2003 13:00:53 +0100 Reply-To: Mailing List Sender: Mailing List From: =?iso-8859-1?q?John=20Smith?= Subject: Normal to STUB/NSSSA To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit Hello, What must a router do when its configured inside a normal area and then re-configured to be a part of the stub network OR NSSA network. Should it flush all the AS-External-LSAs it has in its database .. What exactly will happen? Thanks in advance, JS __________________________________________________ Yahoo! Plus For a better Internet experience http://www.yahoo.co.uk/btoffer From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 4 07:26:15 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19360 for ; Fri, 4 Apr 2003 07:26:15 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00962B26@cherry.ease.lsoft.com>; Fri, 4 Apr 2003 7:28:44 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 718414 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 4 Apr 2003 07:28:44 -0500 Received: from 203.197.140.35 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 4 Apr 2003 07:28:43 -0500 Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 04 Apr 2003 18:04:23 +0530 Received: from vivekd (vivekd.future.futsoft.com [10.20.6.77]) by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id h34CMmIM024941 for ; Fri, 4 Apr 2003 17:52:48 +0530 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-ID: <001101c2faa5$bd7e15e0$4d06140a@future.futsoft.com> Date: Fri, 4 Apr 2003 17:58:46 +0530 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: Re: Normal to STUB/NSSSA To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20030404120053.54360.qmail@web20508.mail.yahoo.com> Precedence: list Content-Transfer-Encoding: 7bit Hi, When a router moves from being part of normal ospf area to internal NSSA/STUB router: 1) Type 5 LSAs should be deleted/flushed. 2) Type 3 can be kept/removed based on whether import of Type 3 is allowed. Cleaner way would be to re-initialize the area itself and start afresh. This should take care of most things..... vivek -----Original Message----- From: Mailing List [mailto:OSPF@discuss.microsoft.com]On Behalf Of John Smith Sent: Friday, 4 April 2003 5:31 PM To: OSPF@discuss.microsoft.com Subject: Normal to STUB/NSSSA Hello, What must a router do when its configured inside a normal area and then re-configured to be a part of the stub network OR NSSA network. Should it flush all the AS-External-LSAs it has in its database .. What exactly will happen? Thanks in advance, JS __________________________________________________ Yahoo! Plus For a better Internet experience http://www.yahoo.co.uk/btoffer *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 4 07:52:29 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20313 for ; Fri, 4 Apr 2003 07:52:29 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00962B65@cherry.ease.lsoft.com>; Fri, 4 Apr 2003 7:54:56 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 718452 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 4 Apr 2003 07:54:56 -0500 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 4 Apr 2003 07:54:56 -0500 Received: from mail.apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h34DR3L12874 for ; Fri, 4 Apr 2003 18:57:03 +0530 Received: from alok ([203.124.140.97]) (authenticated) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h34DR0X12868 for ; Fri, 4 Apr 2003 18:57:01 +0530 References: <001101c2faa5$bd7e15e0$4d06140a@future.futsoft.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <021d01c2faa9$bea69380$81c802c0@alok> Date: Fri, 4 Apr 2003 18:27:10 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: Re: Normal to STUB/NSSSA To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list hi, > Hi, > When a router moves from being part > of normal ospf area to internal NSSA/STUB router: > 1) Type 5 LSAs should be deleted/flushed. > > 2) Type 3 can be kept/removed based on > whether import of Type 3 is allowed. i know there is a difference between what some people call "stub" versus totally "stub" ....but is this a standard/draft.....? i mean this makes sense if one puts BGP etc into IGP but do people do that anywhere............? -thanks and rgds Alok From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 4 08:22:08 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21177 for ; Fri, 4 Apr 2003 08:22:07 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00962BD8@cherry.ease.lsoft.com>; Fri, 4 Apr 2003 8:24:35 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 718524 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 4 Apr 2003 08:24:36 -0500 Received: from 156.147.1.151 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 4 Apr 2003 08:14:36 -0500 Received: from [150.150.40.133] (yjim@lge.com) by mail1.lge.co.kr (Terrace Internet Messaging Server) with ESMTP id 2003040422:08:43:224399.17971.1044 for ; Fri, 04 Apr 2003 22:08:43 +0900 (KST) MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: <000901c2faac$2ac2e5d0$85289696@yongjuni> Date: Fri, 4 Apr 2003 22:14:47 +0900 Reply-To: Mailing List Sender: Mailing List From: Yongjun Im Subject: Regarding keeping multiple routes with unequal costs to ABR/ASBR To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id IAA21177 Hello, I would like to ask if the OSPF behaviour described below complies with RFC 2328. As a matter of fact, I believe it doesn't work appropriately even if it complies with the standard. The problem was found in the following network topology in which we wanted to test primiary/secondary routes using different OSPF metrics (the Link1 and Link2 are set to 10 and 1, respectively). OSPF <--Link1(10) --> OSPF LER_A LSR <--------> LER_B <--Link2(1)---> (ABR) OSPF <------ Area 0 ---------> <----- Area 100 -----> In the picture above, we added OSPF route entries using Adtech analyzer which acted as a ABR/ASBR. What the OSPF routing table in LER_A contained, after all routes propagation through OSPF routing domain, was somewhat unexpected for us, because it kept all of the routes, including the route to LSR, injected from Analyzer as equal-cost multi-path through both Link1 and Link2, not only through Link2 with lower cost. Regardless of whether a destination is ABR or ASBR, I believe the best route (with the least cost) to that router, should be kept. Therefore, in the topology above I think that LER_A has to keep only the route over Link2, with the smaller metric, to LSR(ABR). Any help in this regard will be greatly appreciated. Regards, Yongjun. From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 4 09:34:13 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23219 for ; Fri, 4 Apr 2003 09:34:12 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00962EB8@cherry.ease.lsoft.com>; Fri, 4 Apr 2003 9:36:40 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 718762 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 4 Apr 2003 09:36:40 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 4 Apr 2003 09:36:38 -0500 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 1A7CD7A65A0 for ; Fri, 4 Apr 2003 06:36:37 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030404115413.36400.qmail@web20505.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E8D9877.9030009@redback.com> Date: Fri, 4 Apr 2003 09:36:39 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Graceful Restart To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit John, Krishna, John has it pretty much right but there is one additional key point. If the restarting router doesn't succeed its role as DR on interfaces where it was previously DR the specification is broken. The restarting router uses his own pre-restart router and network LSAs to determine when graceful restart has converged. A DR election would change the topology and the restarting router would detect an LSA inconsistency and exit graceful restart prematurely. Thanks, Acee John Smith wrote: > Krishna, > my 2 euros (dollars are out !!!) > > >>draft-ietf-ospf-hitless-restart-07.txt: >>2. Operation of restarting router: >> >>Point 2) If the restarting router determines that it was >>Designated >> Router on a given segment immediately prior to the >>restart, >> it elects itself as Designated Router again >> >>Q1)Why does this need to be done while restarting? >> AND >> How does it help ?? > > > Its helps in maintaining sanity in the network. Others think that this router is still up > and continue trusting him as DR. When he comes up he should not break this trust and > should ideally start operating as a DR. > > The basic concept is that if he resigns from DRship then the BDR will take over and they > will need to again re-elect the BDR .. which is a messy affair. The whole point of > graceful restart is to avoid such events !! > > >>Q2)What if normal DR/BDR election takes place "on exiting >> graceful restart" > > > Why do you want to land in this mess? You will again need to re-issue your LSAs, etc. > Everybody will have to re-synch .. and the whole purpose of graceful restart will be > defeated. > > Others more informed about this protocol can correct me whatever i missed out! > > JS > > > > __________________________________________________ > Yahoo! Plus > For a better Internet experience > http://www.yahoo.co.uk/btoffer > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 4 09:47:30 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23738 for ; Fri, 4 Apr 2003 09:47:30 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00962EF3@cherry.ease.lsoft.com>; Fri, 4 Apr 2003 9:49:58 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 718803 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 4 Apr 2003 09:49:58 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 4 Apr 2003 09:49:58 -0500 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 9D2FF65774E for ; Fri, 4 Apr 2003 06:49:42 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <000901c2faac$2ac2e5d0$85289696@yongjuni> Content-Type: text/plain; charset=x-windows-949 Content-Transfer-Encoding: 7bit Message-ID: <3E8D9B88.6040706@redback.com> Date: Fri, 4 Apr 2003 09:49:44 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Regarding keeping multiple routes with unequal costs to ABR/ASBR To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Yongjun, If I understand your topology you are correct. LER_A should only install the lower cost routes over Link2. Thanks, Acee Yongjun Im wrote: > Hello, > > I would like to ask if the OSPF behaviour described below complies with RFC 2328. > As a matter of fact, I believe it doesn't work appropriately even if it complies with the standard. > > The problem was found in the following network topology in which we wanted to > test primiary/secondary routes using different OSPF metrics > (the Link1 and Link2 are set to 10 and 1, respectively). > > OSPF > <--Link1(10) --> OSPF > LER_A LSR <--------> LER_B > <--Link2(1)---> (ABR) > OSPF > > <------ Area 0 ---------> <----- Area 100 -----> > > In the picture above, we added OSPF route entries using Adtech analyzer which > acted as a ABR/ASBR. What the OSPF routing table in LER_A contained, > after all routes propagation through OSPF routing domain, was somewhat unexpected for us, > because it kept all of the routes, including the route to LSR, injected from Analyzer > as equal-cost multi-path through both Link1 and Link2, not only through Link2 with lower cost. > > Regardless of whether a destination is ABR or ASBR, I believe the best route > (with the least cost) to that router, should be kept. Therefore, in the topology above > I think that LER_A has to keep only the route over Link2, with the smaller metric, to LSR(ABR). > > Any help in this regard will be greatly appreciated. > > Regards, > > Yongjun. -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 4 09:51:45 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23871 for ; Fri, 4 Apr 2003 09:51:45 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00962F4A@cherry.ease.lsoft.com>; Fri, 4 Apr 2003 9:54:13 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 718830 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 4 Apr 2003 09:54:13 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 4 Apr 2003 09:54:13 -0500 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 2F7D365774A for ; Fri, 4 Apr 2003 06:54:12 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030404120053.54360.qmail@web20508.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E8D9C96.6070504@redback.com> Date: Fri, 4 Apr 2003 09:54:14 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Normal to STUB/NSSSA To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi John, John Smith wrote: > Hello, > What must a router do when its configured inside a normal area and then re-configured to > be a part of the stub network OR NSSA network. > > Should it flush all the AS-External-LSAs it has in its database .. What exactly will > happen? To make things simple, let's consider this router to be internal to the area (not an ABR). The router should flush its self-originated AS external LSAs and discard all its AS external LSA. If it is an NSSA, it should (dependent on policy), reoriginate its redistributed routes as NSSA type 7 LSAs. If may or may not have reoriginate its router LSA dependent on changes to the router bits. The ABR case is much more complicated. > > Thanks in advance, > JS > > __________________________________________________ > Yahoo! Plus > For a better Internet experience > http://www.yahoo.co.uk/btoffer > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 4 11:08:42 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27825 for ; Fri, 4 Apr 2003 11:08:42 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.009637BC@cherry.ease.lsoft.com>; Fri, 4 Apr 2003 11:11:10 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 719089 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 4 Apr 2003 11:11:10 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 4 Apr 2003 11:11:10 -0500 Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h34GB9S38333; Fri, 4 Apr 2003 08:11:09 -0800 (PST) (envelope-from padma@juniper.net) Received: (from padma@localhost) by garnet.juniper.net (8.11.5/8.11.3) id h34GB9v71888; Fri, 4 Apr 2003 08:11:09 -0800 (PST) (envelope-from padma) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200304041611.h34GB9v71888@garnet.juniper.net> Date: Fri, 4 Apr 2003 08:11:09 -0800 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: Graceful Restart To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20030404115413.36400.qmail@web20505.mail.yahoo.com> from "=?iso-8859-1?q?John=20Smith?=" at Apr 04, 2003 12:54:13 PM Precedence: list Content-Transfer-Encoding: 7bit One important point is that the DR is the one who issues the network LSA and have adjacency with. If you change the DR then this would imply that - All the routers will have to tear down their previous adj to the restarting router and build a new one to the DR. Flooding patterns will change which is not desirable. - the new DR will build the new network LSA for the network and this will cause the restart to abort on change in topology. Padma > > Krishna, > my 2 euros (dollars are out !!!) > > > > > draft-ietf-ospf-hitless-restart-07.txt: > > 2. Operation of restarting router: > > > > Point 2) If the restarting router determines that it was > > Designated > > Router on a given segment immediately prior to the > > restart, > > it elects itself as Designated Router again > > > > Q1)Why does this need to be done while restarting? > > AND > > How does it help ?? > > Its helps in maintaining sanity in the network. Others think that this router is still up > and continue trusting him as DR. When he comes up he should not break this trust and > should ideally start operating as a DR. > > The basic concept is that if he resigns from DRship then the BDR will take over and they > will need to again re-elect the BDR .. which is a messy affair. The whole point of > graceful restart is to avoid such events !! > > > > > Q2)What if normal DR/BDR election takes place "on exiting > > graceful restart" > > Why do you want to land in this mess? You will again need to re-issue your LSAs, etc. > Everybody will have to re-synch .. and the whole purpose of graceful restart will be > defeated. > > Others more informed about this protocol can correct me whatever i missed out! > > JS > > > > __________________________________________________ > Yahoo! Plus > For a better Internet experience > http://www.yahoo.co.uk/btoffer > From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 4 11:32:30 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28450 for ; Fri, 4 Apr 2003 11:32:30 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00963757@cherry.ease.lsoft.com>; Fri, 4 Apr 2003 11:34:59 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 719147 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 4 Apr 2003 11:34:59 -0500 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 4 Apr 2003 11:34:58 -0500 Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h34GYwS39598; Fri, 4 Apr 2003 08:34:58 -0800 (PST) (envelope-from padma@juniper.net) Received: (from padma@localhost) by garnet.juniper.net (8.11.5/8.11.3) id h34GYwg78441; Fri, 4 Apr 2003 08:34:58 -0800 (PST) (envelope-from padma) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200304041634.h34GYwg78441@garnet.juniper.net> Date: Fri, 4 Apr 2003 08:34:58 -0800 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: Normal to STUB/NSSSA To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <001101c2faa5$bd7e15e0$4d06140a@future.futsoft.com> from "Vivek Dubey" at Apr 04, 2003 05:58:46 PM Precedence: list Content-Transfer-Encoding: 7bit Hi I do not agree with the fact that it should necessarily flush its external LSA. Moving to a stub ~~~~~~~~~~~~~~~~ Whether or not it flushes the LSA doesn't matter as those LSAs will not be taken into account by anyone as the Advertising router router-lsa has the E-bit clear. This will in turn flush the type-4 LSAs (rfc2328 pg 136). The router will not be part of the router routing table as an ASBR. Hence none of the external LSAs originated by that router will be considered for SPF calculation. So it is an implementation decision to do so. I think it is more scalable not to do so .. it reduces traffic. Moving into a NSSA ~~~~~~~~~~~~~~~~~~ You need to flush your type 5 and generated type 7 instead. Type 3 kept/flushed - depends on config Padma > > Hi, > When a router moves from being part > of normal ospf area to internal NSSA/STUB router: > 1) Type 5 LSAs should be deleted/flushed. > > 2) Type 3 can be kept/removed based on > whether import of Type 3 is allowed. > > Cleaner way would be to re-initialize the > area itself and start afresh. This should take > care of most things..... > > vivek > > > > -----Original Message----- > From: Mailing List [mailto:OSPF@discuss.microsoft.com]On Behalf Of John > Smith > Sent: Friday, 4 April 2003 5:31 PM > To: OSPF@discuss.microsoft.com > Subject: Normal to STUB/NSSSA > > > Hello, > What must a router do when its configured inside a normal area and then > re-configured to > be a part of the stub network OR NSSA network. > > Should it flush all the AS-External-LSAs it has in its database .. What > exactly will > happen? > > Thanks in advance, > JS > > __________________________________________________ > Yahoo! Plus > For a better Internet experience > http://www.yahoo.co.uk/btoffer > > *************************************************************************** > This message is proprietary to Future Software Limited (FSL) > and is intended solely for the use of the individual to whom it > is addressed. It may contain privileged or confidential information > and should not be circulated or used for any purpose other than for > what it is intended. > > If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, > you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. > FSL accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including > damage from virus. > *************************************************************************** > From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 4 12:13:38 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29670 for ; Fri, 4 Apr 2003 12:13:38 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00963947@cherry.ease.lsoft.com>; Fri, 4 Apr 2003 12:16:07 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 719260 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 4 Apr 2003 12:16:07 -0500 Received: from 156.147.1.151 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 4 Apr 2003 12:16:06 -0500 Received: from [156.147.51.110] (yjim@lge.com) by mail1.lge.co.kr (Terrace Internet Messaging Server) with ESMTP id 2003040502:10:11:756336.17971.1087 for ; Sat, 05 Apr 2003 02:10:11 +0900 (KST) References: <000901c2faac$2ac2e5d0$85289696@yongjuni> X-MIMETrack: Serialize by Router on LGEKRHQMS26/LGE/LG Group(Release 5.0.9a |January 7, 2002) at 2003/04/05 02:17:50 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Message-ID: Date: Sat, 5 Apr 2003 02:17:48 +0900 Reply-To: Mailing List Sender: Mailing List From: =?euc-kr?B?wNO/68HY?= Subject: Re : Re: Regarding keeping multiple routes with unequal costs to ABR/ASBR Comments: To: Acee Lindem To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list If LER_B is an ASBR, should LER_A install only the lower cost route (over Link2) to ASBR(LER_B) ? ------------- Yongjun, If I understand your topology you are correct. LER_A should only install the lower cost routes over Link2. Thanks, Acee Yongjun Im wrote: > Hello, > > I would like to ask if the OSPF behaviour described below complies with RFC 2328. > As a matter of fact, I believe it doesn't work appropriately even if it complies with the standard. > > The problem was found in the following network topology in which we wanted to > test primiary/secondary routes using different OSPF metrics > (the Link1 and Link2 are set to 10 and 1, respectively). > > OSPF > <--Link1(10) --> OSPF > LER_A LSR <--------> LER_B > <--Link2(1)---> (ABR) > OSPF > > <------ Area 0 ---------> <----- Area 100 -----> > > In the picture above, we added OSPF route entries using Adtech analyzer which > acted as a ABR/ASBR. What the OSPF routing table in LER_A contained, > after all routes propagation through OSPF routing domain, was somewhat unexpected for us, > because it kept all of the routes, including the route to LSR, injected from Analyzer > as equal-cost multi-path through both Link1 and Link2, not only through Link2 with lower cost. > > Regardless of whether a destination is ABR or ASBR, I believe the best route > (with the least cost) to that router, should be kept. Therefore, in the topology above > I think that LER_A has to keep only the route over Link2, with the smaller metric, to LSR(ABR). > > Any help in this regard will be greatly appreciated. > > Regards, > > Yongjun. -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 4 12:26:03 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00058 for ; Fri, 4 Apr 2003 12:26:03 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00963B11@cherry.ease.lsoft.com>; Fri, 4 Apr 2003 12:28:31 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 719306 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 4 Apr 2003 12:28:31 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 4 Apr 2003 12:28:30 -0500 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id AB206252F4C; Fri, 4 Apr 2003 09:28:28 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <000901c2faac$2ac2e5d0$85289696@yongjuni> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E8DC0BD.4000000@redback.com> Date: Fri, 4 Apr 2003 12:28:29 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Re : Re: Regarding keeping multiple routes with unequal costs to ABR/ASBR Comments: To: =?windows-1252?Q?=3F=3F=3F?= To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit ??? wrote: > If LER_B is an ASBR, should LER_A install only the lower cost route > (over Link2) to ASBR(LER_B) ? Yes. What would lead you to think otherwise? > > ------------- > Yongjun, > > If I understand your topology you are correct. LER_A should > only install the lower cost routes over Link2. > > Thanks, > Acee > > Yongjun Im wrote: > >>Hello, >> >>I would like to ask if the OSPF behaviour described below complies with > > RFC 2328. > >>As a matter of fact, I believe it doesn't work appropriately even if it > > complies > with the standard. > >>The problem was found in the following network topology in which we > > wanted to > >>test primiary/secondary routes using different OSPF metrics >>(the Link1 and Link2 are set to 10 and 1, respectively). >> >> OSPF >> <--Link1(10) --> OSPF >>LER_A LSR <--------> LER_B >> <--Link2(1)---> (ABR) >> OSPF >> >><------ Area 0 ---------> <----- Area 100 -----> >> >>In the picture above, we added OSPF route entries using Adtech analyzer > > which > >>acted as a ABR/ASBR. What the OSPF routing table in LER_A contained, >>after all routes propagation through OSPF routing domain, was somewhat > > unexpected for us, > >>because it kept all of the routes, including the route to LSR, injected > > from > Analyzer > >>as equal-cost multi-path through both Link1 and Link2, not only through > > Link2 > with lower cost. > >>Regardless of whether a destination is ABR or ASBR, I believe the best > > route > >>(with the least cost) to that router, should be kept. Therefore, in the > > topology > above > >>I think that LER_A has to keep only the route over Link2, with the > > smaller > metric, to LSR(ABR). > >>Any help in this regard will be greatly appreciated. >> >>Regards, >> >>Yongjun. > > > > -- > Acee > > > > > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 4 14:57:39 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04866 for ; Fri, 4 Apr 2003 14:57:39 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00964004@cherry.ease.lsoft.com>; Fri, 4 Apr 2003 14:57:39 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 719736 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 4 Apr 2003 14:57:39 -0500 Received: from 207.217.120.48 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 4 Apr 2003 14:57:39 -0500 Received: from user-2ivfk2p.dialup.mindspring.com ([165.247.208.89] helo=earthlink.net) by mallard.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 191XJi-00038A-00 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 04 Apr 2003 11:57:38 -0800 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: <20030404115413.36400.qmail@web20505.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E8DE1DA.19CFFC70@earthlink.net> Date: Fri, 4 Apr 2003 11:49:46 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Graceful Restart To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Krishna and group, Under the assumption that "network topology remains static" (1. Overview, 4th paragraph), then election of a DR / BDR really only requires the exchange of DBD packets. This is pretty lightweight in my opinion. On the assumption, that a more capable system had booted-up after the wait time, it actually, might make sense for the DR or the BDR to resign his position upon exiting graceful restart. Mitchell Erblich --------------------- John Smith wrote: > > Krishna, > my 2 euros (dollars are out !!!) > > > > > draft-ietf-ospf-hitless-restart-07.txt: > > 2. Operation of restarting router: > > > > Point 2) If the restarting router determines that it was > > Designated > > Router on a given segment immediately prior to the > > restart, > > it elects itself as Designated Router again > > > > Q1)Why does this need to be done while restarting? > > AND > > How does it help ?? > > Its helps in maintaining sanity in the network. Others think that this router is still up > and continue trusting him as DR. When he comes up he should not break this trust and > should ideally start operating as a DR. > > The basic concept is that if he resigns from DRship then the BDR will take over and they > will need to again re-elect the BDR .. which is a messy affair. The whole point of > graceful restart is to avoid such events !! > > > > > Q2)What if normal DR/BDR election takes place "on exiting > > graceful restart" > > Why do you want to land in this mess? You will again need to re-issue your LSAs, etc. > Everybody will have to re-synch .. and the whole purpose of graceful restart will be > defeated. > > Others more informed about this protocol can correct me whatever i missed out! > > JS > > __________________________________________________ > Yahoo! Plus > For a better Internet experience > http://www.yahoo.co.uk/btoffer From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 4 15:59:55 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07986 for ; Fri, 4 Apr 2003 15:59:55 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.009644AE@cherry.ease.lsoft.com>; Fri, 4 Apr 2003 16:02:06 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 719980 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 4 Apr 2003 16:02:06 -0500 Received: from 207.217.120.120 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 4 Apr 2003 16:02:06 -0500 Received: from user-2ivfk2p.dialup.mindspring.com ([165.247.208.89] helo=earthlink.net) by albatross.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 191YK4-0003WV-00 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 04 Apr 2003 13:02:05 -0800 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: <20030404115413.36400.qmail@web20505.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E8DF0E5.1A097E29@earthlink.net> Date: Fri, 4 Apr 2003 12:53:57 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Draft : Graceful Restart : : grace period, etc To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, 1) Within 2.1 "Entering graceful restart", iff all the LSAs were from DC specified NBRs with DNA LSAs should the LS RefreshTime still be followed? 2) Within 2.2 "When to exit graceful restart", number (3) "The grace period expires". What happens if we follow #3 and your #1 "reestablished all its adjacencies" criteria is not met? Or are you stating that the specified "grace period" was to short to perform what was required? 3) Within 2.2. Would seeing a hello without the graceful restarting router id", force it to exit? 4) Within 2.2. Would seeing a hello without the graceful restarting router id as the earlier DR or BDR, cause it to exit, if it was a DR / BDR? 5) Within 2.2. Is it implimentation dependent on how we determine our existing nbrs and place their router ids in a hello? 6) Within 2.2 (1), isn't adj establishment partly the recieving of hellos, with your own router-id? Shouldn't that inform others that we are back and to cancel their helper graceful nbr timer? 7 & 8) Within 2.3 "Actions on exiting graceful restart". 7) Shouldn't the sending hellos be performed that identify full adj be a criteria here? 8) I am unsure whether you are specifying the storage of part of restarting router's LSDB into non-volatile memory. If so, then upon retrieval, shouldn't some elements of the LSDB be aged by the amount that the actual amount of time the LSAs were in NV memory? Mitchell Erblich ================================== From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 4 17:42:40 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10904 for ; Fri, 4 Apr 2003 17:42:39 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.009648BD@cherry.ease.lsoft.com>; Fri, 4 Apr 2003 17:45:08 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 720128 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 4 Apr 2003 17:45:08 -0500 Received: from 207.217.120.123 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 4 Apr 2003 17:45:08 -0500 Received: from user-38lc0dq.dialup.mindspring.com ([209.86.1.186] helo=earthlink.net) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 191Zvm-0005II-00 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 04 Apr 2003 14:45:06 -0800 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: <20030404115413.36400.qmail@web20505.mail.yahoo.com> <3E8DF0E5.1A097E29@earthlink.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E8E0AD1.929B4823@earthlink.net> Date: Fri, 4 Apr 2003 14:44:33 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Draft : Graceful Restart : Very short grace period To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, I had one more item for this draft. If the grace period could be kept within the router dead interval, our entire state stored in NVRAM for later retrieval would their even be a need to attempt to require helper routers? Mitchell Erblich ------------------------- Erblichs wrote: > > Group, > > 1) Within 2.1 "Entering graceful restart", iff all > the LSAs were from DC specified NBRs with DNA > LSAs should the LS RefreshTime still be followed? > > 2) Within 2.2 "When to exit graceful restart", number > (3) "The grace period expires". > > What happens if we follow #3 and your #1 "reestablished > all its adjacencies" criteria is not met? > > Or are you stating that the specified "grace period" was > to short to perform what was required? > > 3) Within 2.2. Would seeing a hello without the graceful > restarting router id", force it to exit? > > 4) Within 2.2. Would seeing a hello without the graceful > restarting router id as the earlier DR or BDR, cause > it to exit, if it was a DR / BDR? > > 5) Within 2.2. Is it implimentation dependent on how we > determine our existing nbrs and place their router ids > in a hello? > > 6) Within 2.2 (1), isn't adj establishment partly the > recieving of hellos, with your own router-id? Shouldn't > that inform others that we are back and to cancel > their helper graceful nbr timer? > > 7 & 8) Within 2.3 "Actions on exiting graceful restart". > > 7) Shouldn't the sending hellos be performed that > identify full adj be a criteria here? > > 8) I am unsure whether you are specifying the > storage of part of restarting router's LSDB into > non-volatile memory. If so, then upon retrieval, > shouldn't some elements of the LSDB be aged > by the amount that the actual amount of time > the LSAs were in NV memory? > > Mitchell Erblich > ================================== From owner-ospf@DISCUSS.MICROSOFT.COM Sat Apr 5 02:36:14 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02286 for ; Sat, 5 Apr 2003 02:36:13 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.009654DA@cherry.ease.lsoft.com>; Sat, 5 Apr 2003 2:38:41 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 720745 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 5 Apr 2003 02:38:41 -0500 Received: from 142.55.5.42 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 5 Apr 2003 02:28:41 -0500 Received: from atlas.sheridanc.on.ca (atlas.sheridanc.on.ca [142.55.114.50]) by magellan.sheridanc.on.ca (8.12.9/8.12.9) with ESMTP id h357SeF4009442 for ; Sat, 5 Apr 2003 02:28:40 -0500 Received: from lemondav (helo=localhost) by atlas.sheridanc.on.ca with local-esmtp (Exim 3.35 #1 (Debian)) id 191i6S-0006Qg-00 for ; Sat, 05 Apr 2003 02:28:40 -0500 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Sat, 5 Apr 2003 02:28:40 -0500 Reply-To: Mailing List Sender: Mailing List From: David Lemon Subject: Re: Normal to STUB/NSSSA To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <000d01c2fb5d$22648ae0$0a45000a@djcitron> Precedence: list A 'simple' stub essentially allows type 1,2 and 3 LSA's into the area. A 'fully' stub'd area will remove type 3, 4 and 5 from the lsa databases of the routers within the area. The only lsa within the area's databases that doesn't describe the topology is the default route that the abr's inject into the area. On Sat, 5 Apr 2003, David Lemon wrote: > > OSPF@DISCUSS.MICROSOFT.COM > -----Original Message----- > From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM] On Behalf Of > Padma Pillay-Esnault > Sent: Friday, April 04, 2003 8:35 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: Normal to STUB/NSSSA > > Hi > > I do not agree with the fact that it should necessarily > flush its external LSA. > > Moving to a stub > ~~~~~~~~~~~~~~~~ > Whether or not it flushes the LSA doesn't matter as those > LSAs will not be taken into account by anyone as the > Advertising router router-lsa has the E-bit clear. > This will in turn flush the type-4 LSAs (rfc2328 pg 136). > The router will not be part of the router routing table > as an ASBR. Hence none of the external LSAs originated by > that router will be considered for SPF calculation. > > So it is an implementation decision to do so. I think it > is more scalable not to do so .. it reduces traffic. > > > Moving into a NSSA > ~~~~~~~~~~~~~~~~~~ > You need to flush your type 5 and generated type 7 instead. > Type 3 kept/flushed - depends on config > > > Padma > > > > > Hi, > > When a router moves from being part > > of normal ospf area to internal NSSA/STUB router: > > 1) Type 5 LSAs should be deleted/flushed. > > > > 2) Type 3 can be kept/removed based on > > whether import of Type 3 is allowed. > > > > Cleaner way would be to re-initialize the > > area itself and start afresh. This should take > > care of most things..... > > > > vivek > > > > > > > > -----Original Message----- > > From: Mailing List [mailto:OSPF@discuss.microsoft.com]On Behalf Of > John > > Smith > > Sent: Friday, 4 April 2003 5:31 PM > > To: OSPF@discuss.microsoft.com > > Subject: Normal to STUB/NSSSA > > > > > > Hello, > > What must a router do when its configured inside a normal area and > then > > re-configured to > > be a part of the stub network OR NSSA network. > > > > Should it flush all the AS-External-LSAs it has in its database .. > What > > exactly will > > happen? > > > > Thanks in advance, > > JS > > > > __________________________________________________ > > Yahoo! Plus > > For a better Internet experience > > http://www.yahoo.co.uk/btoffer > > > > > ************************************************************************ > *** > > This message is proprietary to Future Software Limited (FSL) > > and is intended solely for the use of the individual to whom it > > is addressed. It may contain privileged or confidential information > > and should not be circulated or used for any purpose other than for > > what it is intended. > > > > If you have received this message in error, please notify the > > originator immediately. If you are not the intended recipient, > > you are notified that you are strictly prohibited from using, > > copying, altering, or disclosing the contents of this message. > > FSL accepts no responsibility for loss or damage arising from > > the use of the information transmitted by this email including > > damage from virus. > > > ************************************************************************ > *** > > > > From owner-ospf@DISCUSS.MICROSOFT.COM Sat Apr 5 21:32:59 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20248 for ; Sat, 5 Apr 2003 21:32:59 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.0096632E@cherry.ease.lsoft.com>; Sat, 5 Apr 2003 21:35:27 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 722366 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 5 Apr 2003 21:35:26 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 5 Apr 2003 21:35:26 -0500 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id E7A74123EF8 for ; Sat, 5 Apr 2003 18:35:24 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030404115413.36400.qmail@web20505.mail.yahoo.com> <3E8DF0E5.1A097E29@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E8F925B.3000308@redback.com> Date: Sat, 5 Apr 2003 21:35:07 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Draft : Graceful Restart : : grace period, etc To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Mitchell, See answers below. Erblichs wrote: > Group, > > 1) Within 2.1 "Entering graceful restart", iff all > the LSAs were from DC specified NBRs with DNA > LSAs should the LS RefreshTime still be followed? LSA Refresh isn't relevant since the restarting router will reestablish adjacencies. > > 2) Within 2.2 "When to exit graceful restart", number > (3) "The grace period expires". > > What happens if we follow #3 and your #1 "reestablished > all its adjacencies" criteria is not met? The restarting router will exit graceful restart anyway. > > Or are you stating that the specified "grace period" was > to short to perform what was required? Not necessarily - perhaps the topology has changed and graceful restart cannot be completed successfully. > > 3) Within 2.2. Would seeing a hello without the graceful > restarting router id", force it to exit? No. The adjacency can go all the way down on the helper router. The hello shouldn't be used as a criteria for exiting helper mode. Do not confuse this with other graceful restart proposals. > > 4) Within 2.2. Would seeing a hello without the graceful > restarting router id as the earlier DR or BDR, cause > it to exit, if it was a DR / BDR? Not directly, but an inconsistency with the pre-restart LSA will cause the restarting router to exist graceful restart prematurely. > > 5) Within 2.2. Is it implimentation dependent on how we > determine our existing nbrs and place their router ids > in a hello? This isn't changed for graceful restart. > > 6) Within 2.2 (1), isn't adj establishment partly the > recieving of hellos, with your own router-id? Shouldn't > that inform others that we are back and to cancel > their helper graceful nbr timer? > > 7 & 8) Within 2.3 "Actions on exiting graceful restart". > > 7) Shouldn't the sending hellos be performed that > identify full adj be a criteria here? No. LSA convergence with the pre-restart LSAs is a much surer mechanism for determining the graceful restart can be exited. > > > 8) I am unsure whether you are specifying the > storage of part of restarting router's LSDB into > non-volatile memory. If so, then upon retrieval, > shouldn't some elements of the LSDB be aged > by the amount that the actual amount of time > the LSAs were in NV memory? There is no mention of storing LSAs in non-volatile storage. > > > > Mitchell Erblich > ================================== > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Sat Apr 5 21:35:15 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20322 for ; Sat, 5 Apr 2003 21:35:15 -0500 (EST) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.009663AF@cherry.ease.lsoft.com>; Sat, 5 Apr 2003 21:37:44 -0500 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 722391 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 5 Apr 2003 21:37:44 -0500 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 5 Apr 2003 21:37:44 -0500 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id D1350123EF5 for ; Sat, 5 Apr 2003 18:37:42 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030404115413.36400.qmail@web20505.mail.yahoo.com> <3E8DF0E5.1A097E29@earthlink.net> <3E8E0AD1.929B4823@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E8F92E5.80202@redback.com> Date: Sat, 5 Apr 2003 21:37:25 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Draft : Graceful Restart : Very short grace period To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Erblichs wrote: > Group, > > I had one more item for this draft. > > If the grace period could be kept within > the router dead interval, our entire > state stored in NVRAM for later retrieval > would their even be a need to attempt > to require helper routers? No - if you store your entire state you don't need any protocol interaction to recover. In fact, there are implementations that sync their state between redundant route processors. Please note that the Link State Database alone doesn't constitute full state ;^) > > Mitchell Erblich > ------------------------- > > Erblichs wrote: > >>Group, >> >> 1) Within 2.1 "Entering graceful restart", iff all >> the LSAs were from DC specified NBRs with DNA >> LSAs should the LS RefreshTime still be followed? >> >> 2) Within 2.2 "When to exit graceful restart", number >> (3) "The grace period expires". >> >> What happens if we follow #3 and your #1 "reestablished >> all its adjacencies" criteria is not met? >> >> Or are you stating that the specified "grace period" was >> to short to perform what was required? >> >> 3) Within 2.2. Would seeing a hello without the graceful >> restarting router id", force it to exit? >> >> 4) Within 2.2. Would seeing a hello without the graceful >> restarting router id as the earlier DR or BDR, cause >> it to exit, if it was a DR / BDR? >> >> 5) Within 2.2. Is it implimentation dependent on how we >> determine our existing nbrs and place their router ids >> in a hello? >> >> 6) Within 2.2 (1), isn't adj establishment partly the >> recieving of hellos, with your own router-id? Shouldn't >> that inform others that we are back and to cancel >> their helper graceful nbr timer? >> >> 7 & 8) Within 2.3 "Actions on exiting graceful restart". >> >> 7) Shouldn't the sending hellos be performed that >> identify full adj be a criteria here? >> >> 8) I am unsure whether you are specifying the >> storage of part of restarting router's LSDB into >> non-volatile memory. If so, then upon retrieval, >> shouldn't some elements of the LSDB be aged >> by the amount that the actual amount of time >> the LSAs were in NV memory? >> >> Mitchell Erblich >> ================================== > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Sun Apr 6 13:52:56 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01703 for ; Sun, 6 Apr 2003 13:52:56 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.009670FA@cherry.ease.lsoft.com>; 6 Apr 2003 13:55:25 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 723423 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 6 Apr 2003 13:55:25 -0400 Received: from 216.136.226.84 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 6 Apr 2003 13:45:25 -0500 Received: from [68.160.177.125] by web20303.mail.yahoo.com via HTTP; Sun, 06 Apr 2003 10:45:25 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20030406174525.71607.qmail@web20303.mail.yahoo.com> Date: Sun, 6 Apr 2003 10:45:25 -0700 Reply-To: Mailing List Sender: Mailing List From: Shanthi Karthik Subject: Learning OSPF To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hello: I am sorry if this is a beginner's question. But is there any way in OSPF to establish an adjacency to a router, but to receieve no data traffic from [or send data to] that router under any circumstances ? I realize you can set the cost to your links very high, but that is only a discouragement, as far as I can tell. Illusrtation: R1 <---- link1 ----- > R2 R1 wants to establish adjacency to R2, but wants to receive [and send] no data traffic from R2. I understand R 1 and R2 will have to exchange routing traffic. Thanks for your patience and answers. -Shalini __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Sun Apr 6 14:31:27 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02453 for ; Sun, 6 Apr 2003 14:31:27 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00966F32@cherry.ease.lsoft.com>; 6 Apr 2003 14:33:57 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 723573 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 6 Apr 2003 14:33:58 -0400 Received: from 142.55.5.43 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 6 Apr 2003 14:33:57 -0500 Received: from atlas.sheridanc.on.ca (atlas.sheridanc.on.ca [142.55.114.50]) by mariner.sheridanc.on.ca (8.12.9/8.12.9) with ESMTP id h36IXulF005528 for ; Sun, 6 Apr 2003 14:33:57 -0400 Received: from lemondav (helo=localhost) by atlas.sheridanc.on.ca with local-esmtp (Exim 3.35 #1 (Debian)) id 192Exo-0001wd-00 for ; Sun, 06 Apr 2003 14:33:56 -0400 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Sun, 6 Apr 2003 14:33:56 -0400 Reply-To: Mailing List Sender: Mailing List From: David Lemon Subject: Re: Learning OSPF To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20030406174525.71607.qmail@web20303.mail.yahoo.com> Precedence: list If I understand your question correctly; you can set the interface to be passive. So R1 will TX ospf data, but not RX any ospf data from R2. It pretty much disregards ospf data coming from R2. On Sun, 6 Apr 2003, Shanthi Karthik wrote: > Hello: > > I am sorry if this is a beginner's question. But is > there any way in OSPF to establish an adjacency to a > router, but to receieve no data traffic from [or send > data to] that router under any circumstances ? I > realize you can set the cost to your links very high, > but that is only a discouragement, as far as I can > tell. > > Illusrtation: R1 <---- link1 ----- > R2 > > R1 wants to establish adjacency to R2, but wants to > receive [and send] no data traffic from R2. I > understand R 1 and R2 will have to exchange routing > traffic. > > Thanks for your patience and answers. > > -Shalini > > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - File online, calculators, forms, and more > http://tax.yahoo.com > From owner-ospf@DISCUSS.MICROSOFT.COM Sun Apr 6 15:26:44 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04551 for ; Sun, 6 Apr 2003 15:26:44 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00967145@cherry.ease.lsoft.com>; 6 Apr 2003 15:29:15 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 723630 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 6 Apr 2003 15:29:15 -0400 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 6 Apr 2003 15:29:15 -0500 Received: from mail.apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h36K2BL12538 for ; Mon, 7 Apr 2003 01:32:11 +0530 Received: from apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with SMTP id h36K2BX12532; Mon, 7 Apr 2003 01:32:11 +0530 Received: from 219.65.135.5 (SquirrelMail authenticated user alok.dube) by mail.apara.com with HTTP; Mon, 7 Apr 2003 01:32:11 +0530 (IST) References: <20030406174525.71607.qmail@web20303.mail.yahoo.com> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <1154.219.65.135.5.1049659331.squirrel@mail.apara.com> Date: Mon, 7 Apr 2003 01:32:11 +0530 Reply-To: Mailing List Sender: Mailing List From: Alok Dube Subject: Re: Learning OSPF Comments: cc: sk_1990@YAHOO.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20030406174525.71607.qmail@web20303.mail.yahoo.com> Precedence: list Content-Transfer-Encoding: 8bit > Hello: > > I am sorry if this is a beginner's question. But is > there any way in OSPF to establish an adjacency to a > router, but to receieve no data traffic from [or send > data to] that router under any circumstances ? passive would send data, but not establish adjacency....... i guess u want to establish adjacency but not send "data"...correct? > From owner-ospf@DISCUSS.MICROSOFT.COM Sun Apr 6 16:31:39 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05554 for ; Sun, 6 Apr 2003 16:31:39 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.0096711D@cherry.ease.lsoft.com>; 6 Apr 2003 16:34:09 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 723773 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 6 Apr 2003 16:34:09 -0400 Received: from 203.178.143.91 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 6 Apr 2003 16:34:09 -0500 Received: from localhost (localhost [127.0.0.1]) by plant.sfc.wide.ad.jp (Postfix) with ESMTP id 493EE252E3; Mon, 7 Apr 2003 05:34:07 +0900 (JST) References: <20030406174525.71607.qmail@web20303.mail.yahoo.com> X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20030407.053405.32296467.yasu@sfc.wide.ad.jp> Date: Mon, 7 Apr 2003 05:34:05 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: Learning OSPF Comments: To: sk_1990@YAHOO.COM To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20030406174525.71607.qmail@web20303.mail.yahoo.com> Precedence: list Content-Transfer-Encoding: 7bit Hi, What you want to get is the natural behavior of OSPF if R1 have only one OSPF-enabled interface. Let me change slightly your illustration: | R1 R2 | | --+---+---+-- | R3 | In above, the data traffic will go through from lower of R3 to upper of R2 and vice versa, even if adjacencies (OSPF protocol exchange channel) had been formed between all the 3 routers. The data traffic won't be lead to R1 except the data bound to R1 itself. OSPF knows that the R1 will be a dead-end, wrong direction for other traffics than to R1 itself, and so don't route them to R1. Am I missing your point ? regards, yasu From: Shanthi Karthik Subject: Learning OSPF Date: Sun, 6 Apr 2003 10:45:25 -0700 > Hello: > > I am sorry if this is a beginner's question. But is > there any way in OSPF to establish an adjacency to a > router, but to receieve no data traffic from [or send > data to] that router under any circumstances ? I > realize you can set the cost to your links very high, > but that is only a discouragement, as far as I can > tell. > > Illusrtation: R1 <---- link1 ----- > R2 > > R1 wants to establish adjacency to R2, but wants to > receive [and send] no data traffic from R2. I > understand R 1 and R2 will have to exchange routing > traffic. > > Thanks for your patience and answers. > > -Shalini > > > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - File online, calculators, forms, and more > http://tax.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Mon Apr 7 02:06:47 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26412 for ; Mon, 7 Apr 2003 02:06:47 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.0096816E@cherry.ease.lsoft.com>; Mon, 7 Apr 2003 2:09:17 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 724441 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 7 Apr 2003 02:09:17 -0400 Received: from 171.71.177.237 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 7 Apr 2003 01:59:17 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h375xEmr016654 for ; Sun, 6 Apr 2003 22:59:15 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-253-236.cisco.com [10.32.253.236]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id AFU63309; Sun, 6 Apr 2003 22:57:29 -0700 (PDT) X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <5.2.0.9.2.20030406225836.0532fde0@mira-sjc5-b.cisco.com> Date: Sun, 6 Apr 2003 22:59:10 -0700 Reply-To: Mailing List Sender: Mailing List From: Fred Baker Subject: test To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20030406174525.71607.qmail@web20303.mail.yahoo.com> Precedence: list This is a test. From owner-ospf@DISCUSS.MICROSOFT.COM Mon Apr 7 07:26:45 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15614 for ; Mon, 7 Apr 2003 07:26: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.00968559@cherry.ease.lsoft.com>; Mon, 7 Apr 2003 7:29:14 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 725212 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 7 Apr 2003 07:29:14 -0400 Received: from 203.199.83.26 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 7 Apr 2003 07:29:13 -0500 Received: (qmail 20699 invoked by uid 510); 7 Apr 2003 11:32:22 -0000 Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 07 apr 2003 11:32:22 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20030407113222.20698.qmail@webmail16.rediffmail.com> Date: Mon, 7 Apr 2003 11:32:22 -0000 Reply-To: Mailing List Sender: Mailing List From: Krishna Rao Subject: Re: Graceful Restart To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, 1) Since the aim is to keep the restarting router in the network, so during graceful restart: If router analyses its own router/network lsa (if it was DR) and does necessary operation, that should be enough. Why to again elect itself as DR ? 2) So suppose, if it doesn't elect itself as DR and new DR(some other router) is elected. But if network topology hasn't changed, only change might be in terms of new DR/BDR and new adjacencies with those DR/BDR. But that does not in anyway change network topology in terms of reachability of routes. So graceful restart should not be aborted !!!! Though Network Lsa will change. But how does it makes "Router LSA" of restarting router inconsistent, in terms of reachability of "helpers", to restarting router??? 3)Finally when it exits the graceful restart: It originates router Lsas, calculates SPF etc. Or i am missing some point ??? krishna On Fri, 04 Apr 2003 Acee Lindem wrote : >John, Krishna, > >John has it pretty much right but there is one additional key >point. If the restarting router doesn't succeed its role as >DR on interfaces where it was previously DR the specification >is broken. The restarting router uses his own pre-restart >router and network LSAs to determine when graceful restart >has converged. A DR election would change the topology and >the restarting router would detect an LSA inconsistency and >exit graceful restart prematurely. > >Thanks, >Acee > >John Smith wrote: >>Krishna, >>my 2 euros (dollars are out !!!) >> >> >>>draft-ietf-ospf-hitless-restart-07.txt: >>>2. Operation of restarting router: >>> >>>Point 2) If the restarting router determines that it was >>>Designated >>> Router on a given segment immediately prior to the >>>restart, >>> it elects itself as Designated Router again >>> >>>Q1)Why does this need to be done while restarting? >>> AND >>> How does it help ?? >> >> >>Its helps in maintaining sanity in the network. Others think >>that this router is still up >>and continue trusting him as DR. When he comes up he should not >>break this trust and >>should ideally start operating as a DR. >> >>The basic concept is that if he resigns from DRship then the BDR >>will take over and they >>will need to again re-elect the BDR .. which is a messy affair. >>The whole point of >>graceful restart is to avoid such events !! >> >> >>>Q2)What if normal DR/BDR election takes place "on exiting >>> graceful restart" >> >> >>Why do you want to land in this mess? You will again need to >>re-issue your LSAs, etc. >>Everybody will have to re-synch .. and the whole purpose of >>graceful restart will be >>defeated. >> >>Others more informed about this protocol can correct me whatever >>i missed out! >> >>JS >> >> >> >>__________________________________________________ >>Yahoo! Plus >>For a better Internet experience >>http://www.yahoo.co.uk/btoffer >> > > >-- >Acee _______________________________________________________________________ Odomos - the only mosquito protection outside 4 walls - Click here to know more! http://r.rediff.com/r?http://clients.rediff.com/odomos/Odomos.htm&&odomos&&wn From owner-ospf@DISCUSS.MICROSOFT.COM Mon Apr 7 09:45:01 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19567 for ; Mon, 7 Apr 2003 09:45:01 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.009688C8@cherry.ease.lsoft.com>; Mon, 7 Apr 2003 9:47:31 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 725505 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 7 Apr 2003 09:47:31 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 7 Apr 2003 09:47:31 -0500 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id EF32628823 for ; Mon, 7 Apr 2003 06:47:29 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030407113222.20698.qmail@webmail16.rediffmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E91814C.9000300@redback.com> Date: Mon, 7 Apr 2003 09:46:52 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Graceful Restart To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Krishna, Krishna Rao wrote: > Hi, > 1) Since the aim is to keep the restarting router > in the network, so during graceful restart: > > If router analyses its own router/network lsa (if > it was DR) and does necessary operation, that should > be enough. > Why to again elect itself as DR ? > > 2) So suppose, if it doesn't elect itself as DR and > new DR(some other router) is elected. > But if network topology hasn't changed, only change > might be in terms of new DR/BDR and new adjacencies > with those DR/BDR. > But that does not in anyway change network topology in > terms of reachability of routes. > So graceful restart should not be aborted !!!! > > Though Network Lsa will change. > But how does it makes "Router LSA" of restarting > router inconsistent, in terms of reachability > of "helpers", to restarting router??? > > 3)Finally when it exits the graceful restart: > It originates router Lsas, calculates SPF etc. > > Or i am missing some point ??? With the current approach, the restarting router doesn't re-originate any LSAs until it exits graceful restart. Rather, the pre-restart LSAs are used. Hence, a change in DR will result in a topology and an inconsistency with the pre-restart LSA. Thanks, Acee > > krishna > > > > On Fri, 04 Apr 2003 Acee Lindem wrote : > >> John, Krishna, >> >> John has it pretty much right but there is one additional key >> point. If the restarting router doesn't succeed its role as >> DR on interfaces where it was previously DR the specification >> is broken. The restarting router uses his own pre-restart >> router and network LSAs to determine when graceful restart >> has converged. A DR election would change the topology and >> the restarting router would detect an LSA inconsistency and >> exit graceful restart prematurely. >> >> Thanks, >> Acee >> >> John Smith wrote: >> >>> Krishna, >>> my 2 euros (dollars are out !!!) >>> >>> >>>> draft-ietf-ospf-hitless-restart-07.txt: >>>> 2. Operation of restarting router: >>>> >>>> Point 2) If the restarting router determines that it was >>>> Designated >>>> Router on a given segment immediately prior to the >>>> restart, >>>> it elects itself as Designated Router again >>>> >>>> Q1)Why does this need to be done while restarting? >>>> AND >>>> How does it help ?? >>> >>> >>> >>> Its helps in maintaining sanity in the network. Others think >>> that this router is still up >>> and continue trusting him as DR. When he comes up he should not >>> break this trust and >>> should ideally start operating as a DR. >>> >>> The basic concept is that if he resigns from DRship then the BDR >>> will take over and they >>> will need to again re-elect the BDR .. which is a messy affair. >>> The whole point of >>> graceful restart is to avoid such events !! >>> >>> >>>> Q2)What if normal DR/BDR election takes place "on exiting >>>> graceful restart" >>> >>> >>> >>> Why do you want to land in this mess? You will again need to >>> re-issue your LSAs, etc. >>> Everybody will have to re-synch .. and the whole purpose of >>> graceful restart will be >>> defeated. >>> >>> Others more informed about this protocol can correct me whatever >>> i missed out! >>> >>> JS >>> >>> >>> >>> __________________________________________________ >>> Yahoo! Plus >>> For a better Internet experience >>> http://www.yahoo.co.uk/btoffer >>> >> >> >> -- >> Acee > > > _______________________________________________________________________ > Odomos - the only mosquito protection outside 4 walls - > Click here to know more! > http://r.rediff.com/r?http://clients.rediff.com/odomos/Odomos.htm&&odomos&&wn > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon Apr 7 16:27:22 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05014 for ; Mon, 7 Apr 2003 16:27:21 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.009692C0@cherry.ease.lsoft.com>; Mon, 7 Apr 2003 16:29:13 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 726447 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 7 Apr 2003 16:29:13 -0400 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 7 Apr 2003 16:29:13 -0500 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.009692C9@cherry.ease.lsoft.com>; Mon, 7 Apr 2003 16:29:13 -0400 Message-ID: Date: Mon, 7 Apr 2003 16:29:13 -0400 Reply-To: Mailing List Sender: Mailing List From: Mike Fox Subject: OSPFv3 Router Priority To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list For OSPFv3, why is the router priority specified on the link-LSA in addition to the hello packets? From owner-ospf@DISCUSS.MICROSOFT.COM Mon Apr 7 20:28:23 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11861 for ; Mon, 7 Apr 2003 20:28:23 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00969C4F@cherry.ease.lsoft.com>; Mon, 7 Apr 2003 20:30:53 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 726969 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 7 Apr 2003 20:30:53 -0400 Received: from 207.217.120.84 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 7 Apr 2003 20:30:53 -0500 Received: from user-2ivfjdu.dialup.mindspring.com ([165.247.205.190] helo=earthlink.net) by gull.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 192h0i-0000lK-00 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 07 Apr 2003 17:30:51 -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: <20030404115413.36400.qmail@web20505.mail.yahoo.com> <3E8DF0E5.1A097E29@earthlink.net> <3E8F925B.3000308@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E9217FA.4291CF24@earthlink.net> Date: Mon, 7 Apr 2003 17:29:46 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Draft : Graceful Restart : : grace period, etc To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Acee Lindem, Sometimes my logic is a little obtuse.. Most of it is inline... I will first throw two new questions to you!!!! 1) Why don't you send out the Grace LSA at full adj timeframe. It would take effect after RouterDeadinterval has expired? This would also take care of unscheduled restarts and allow you to do an unscheduled graceful restart!!!! You could also send them as DNA LSAs.. See inline. The only new twist is that if you then schedule a restart, you may want to be able to cancel your previous request or update the LSAs over time. But if you conisder a stable topology, then why NOT?? 2) A) 2.1 3rd, paragraph.. "Their age field set to 0," Why can't you send DNA grace-LSAs???? B) 2.1, 4th paragraph. "it should retransmit... until they are acknowledged". If you can't retransmit the same LSA until 5 secs have passed, if a router was congested, you may want to resubmit the grace-LSA with a longer length timeframe to your helpers. I am assuming just bump your instance. Correct? Mitchell ================ Acee Lindem wrote: > > Mitchell, > > See answers below. > > Erblichs wrote: > > Group, > > > > 1) Within 2.1 "Entering graceful restart", iff all > > the LSAs were from DC specified NBRs with DNA > > LSAs should the LS RefreshTime still be followed? > > LSA Refresh isn't relevant since the restarting router will > reestablish adjacencies. Then why have a suggestion of 1800 secs for LSReshTime in your draft at the end of the 1st paragraph in section 2.1? In my scenario, there would be no reason not to let the value approach or exceed 3600 secs (1 hr). variation on a theme? Why not let the max value of your grace-LSA length field allow the helper determine what is the max that he will support? -- what happens if you specify a value that is greater than what the helper supports? Ans A: The helper sees it as an invalid request and throws away the whole request, OR Ans B: The helper determines what the length he will support? If it is B, then why have the length field. Just let the helper decide how long to support the request? > > > > > 2) Within 2.2 "When to exit graceful restart", number > > (3) "The grace period expires". > > > > What happens if we follow #3 and your #1 "reestablished > > all its adjacencies" criteria is not met? > > The restarting router will exit graceful restart anyway. Why? If you still have a non-changing topology, why limit the value to what you had said to the helpers? So, what if you asked for x time and it took you x + y time? > > > > > Or are you stating that the specified "grace period" was > > to short to perform what was required? > > Not necessarily - perhaps the topology has changed and graceful restart > cannot be completed successfully. > > > > > 3) Within 2.2. Would seeing a hello without the graceful > > restarting router id", force it to exit? > > No. The adjacency can go all the way down on the helper router. The hello > shouldn't be used as a criteria for exiting helper mode. Do not confuse > this with other graceful restart proposals. > I see that my question with the hello was answered in the 2. (3) "an hello packet is received".. I am confused. One router may list you as the DR and another may not? If one is a helper, then why would it take the adj down if all the crieria were met? I thought that helpers MUST send hellos as if you (graceful restarting router) were still there!! "an Hello packet is received from a neighbor listing the router as the Designated Router". If it did keep anouncing you in the hellos (you weren't the DR) and lets say that the DR went down. Could you then be elected as the DR while you were still rebooting? > > > > 4) Within 2.2. Would seeing a hello without the graceful > > restarting router id as the earlier DR or BDR, cause > > it to exit, if it was a DR / BDR? > > Not directly, but an inconsistency with the pre-restart LSA will cause > the restarting router to exist graceful restart prematurely. > > > > > 5) Within 2.2. Is it implimentation dependent on how we > > determine our existing nbrs and place their router ids > > in a hello? > > This isn't changed for graceful restart. I thought that you could save past nbr-ids in NVRAM and then compare to existing hellos... > > > > > 6) Within 2.2 (1), isn't adj establishment partly the > > recieving of hellos, with your own router-id? Shouldn't > > that inform others that we are back and to cancel > > their helper graceful nbr timer? > > > > 7 & 8) Within 2.3 "Actions on exiting graceful restart". > > > > 7) Shouldn't the sending hellos be performed that > > identify full adj be a criteria here? > > No. LSA convergence with the pre-restart LSAs is a much surer > mechanism for determining the graceful restart can be exited. > > > > > > > 8) I am unsure whether you are specifying the > > storage of part of restarting router's LSDB into > > non-volatile memory. If so, then upon retrieval, > > shouldn't some elements of the LSDB be aged > > by the amount that the actual amount of time > > the LSAs were in NV memory? > > There is no mention of storing LSAs in non-volatile storage. > Ok, you aren't suggesting saving the LSDB in NVRAM or some other type of storage media.. > > > > > > > > Mitchell Erblich > > ================================== > > > > -- > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon Apr 7 21:16:52 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13090 for ; Mon, 7 Apr 2003 21:16:52 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00969D5F@cherry.ease.lsoft.com>; Mon, 7 Apr 2003 21:19:23 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 727049 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 7 Apr 2003 21:19:23 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 7 Apr 2003 21:19:23 -0500 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 83A611E56A3 for ; Mon, 7 Apr 2003 18:19:21 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030404115413.36400.qmail@web20505.mail.yahoo.com> <3E8DF0E5.1A097E29@earthlink.net> <3E8F925B.3000308@redback.com> <3E9217FA.4291CF24@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E92236E.5040908@redback.com> Date: Mon, 7 Apr 2003 21:18:38 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Draft : Graceful Restart : : grace period, etc To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Erblichs wrote: > Acee Lindem, > > Sometimes my logic is a little obtuse.. > > Most of it is inline... > > I will first throw two new questions to you!!!! > > 1) Why don't you send out the Grace LSA at full > adj timeframe. It would take effect after > RouterDeadinterval has expired? How do you know, apriori, that the OSPF instance is restarting and not completely dead? > > This would also take care of unscheduled restarts > and allow you to do an unscheduled graceful > restart!!!! > > You could also send them as DNA LSAs.. See inline. > > The only new twist is that if you then schedule > a restart, you may want to be able to cancel your > previous request or update the LSAs over time. > But if you conisder a stable topology, then why > NOT?? > > > 2) A) 2.1 3rd, paragraph.. > "Their age field set to 0," > Why can't you send DNA grace-LSAs???? You wouldn't gain anything since the grace interval cannot exceed the LSA refresh time. > > B) 2.1, 4th paragraph. > > "it should retransmit... until > they are acknowledged". If you can't retransmit the > same LSA until 5 secs have passed, if a router > was congested, you may want to resubmit the grace-LSA > with a longer length timeframe to your helpers. I am > assuming just bump your instance. Correct? There are implementations that back off LSA retransmissions and the "Prioritized Treatment of Specific OSPF Packets and Congestion Avoidance" draft recommends this. However, this is not standard OSPF flooding as described in RFC2328 and it is an independent issue. > > > > Mitchell > ================ > Acee Lindem wrote: > >>Mitchell, >> >>See answers below. >> >>Erblichs wrote: >> >>>Group, >>> >>> 1) Within 2.1 "Entering graceful restart", iff all >>> the LSAs were from DC specified NBRs with DNA >>> LSAs should the LS RefreshTime still be followed? >> >>LSA Refresh isn't relevant since the restarting router will >>reestablish adjacencies. > > > Then why have a suggestion of 1800 secs for LSReshTime > in your draft at the end of the 1st paragraph in section > 2.1? > > In my scenario, there would be no reason not to let the > value approach or exceed 3600 secs (1 hr). > > variation on a theme? Why not let the max value of your > grace-LSA length field allow the helper determine what > is the max that he will support? > -- what happens if you specify a value that is > greater than what the helper supports? > Ans A: The helper sees it as an invalid request > and throws away the whole request, > > OR > Ans B: The helper determines what the length he > will support? > > If it is B, then why have the length field. Just let > the helper decide how long to support the request? > > >>> 2) Within 2.2 "When to exit graceful restart", number >>> (3) "The grace period expires". >>> >>> What happens if we follow #3 and your #1 "reestablished >>> all its adjacencies" criteria is not met? >> >>The restarting router will exit graceful restart anyway. > > > Why? If you still have a non-changing topology, why > limit the value to what you had said to the helpers? > > So, what if you asked for x time and it took you > x + y time? > > >>> Or are you stating that the specified "grace period" was >>> to short to perform what was required? >> >>Not necessarily - perhaps the topology has changed and graceful restart >>cannot be completed successfully. >> >> >>> 3) Within 2.2. Would seeing a hello without the graceful >>> restarting router id", force it to exit? >> >>No. The adjacency can go all the way down on the helper router. The hello >>shouldn't be used as a criteria for exiting helper mode. Do not confuse >>this with other graceful restart proposals. >> > > > I see that my question with the hello was answered in the > 2. (3) "an hello packet is received".. > > I am confused. One router may list you as the DR and another > may not? If one is a helper, then why would it take the adj > down if all the crieria were met? > > I thought that helpers > MUST send hellos as if you (graceful restarting router) were > still there!! > "an Hello packet is received from a neighbor listing the > router as the Designated Router". > > If it did keep anouncing you in the hellos (you weren't > the DR) and lets say that the DR went down. Could you > then be elected as the DR while you were still rebooting? > > >>> 4) Within 2.2. Would seeing a hello without the graceful >>> restarting router id as the earlier DR or BDR, cause >>> it to exit, if it was a DR / BDR? >> >>Not directly, but an inconsistency with the pre-restart LSA will cause >>the restarting router to exist graceful restart prematurely. >> >> >>> 5) Within 2.2. Is it implimentation dependent on how we >>> determine our existing nbrs and place their router ids >>> in a hello? >> >>This isn't changed for graceful restart. > > > I thought that you could save past nbr-ids in NVRAM > and then compare to existing hellos... > >>> 6) Within 2.2 (1), isn't adj establishment partly the >>> recieving of hellos, with your own router-id? Shouldn't >>> that inform others that we are back and to cancel >>> their helper graceful nbr timer? >>> >>> 7 & 8) Within 2.3 "Actions on exiting graceful restart". >>> >>> 7) Shouldn't the sending hellos be performed that >>> identify full adj be a criteria here? >> >>No. LSA convergence with the pre-restart LSAs is a much surer >>mechanism for determining the graceful restart can be exited. >> >> >>> >>> 8) I am unsure whether you are specifying the >>> storage of part of restarting router's LSDB into >>> non-volatile memory. If so, then upon retrieval, >>> shouldn't some elements of the LSDB be aged >>> by the amount that the actual amount of time >>> the LSAs were in NV memory? >> >>There is no mention of storing LSAs in non-volatile storage. >> > > > Ok, you aren't suggesting saving the LSDB in NVRAM > or some other type of storage media.. > >>> >>> >>> Mitchell Erblich >>> ================================== >>> >> >>-- >>Acee > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 8 05:44:21 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03566 for ; Tue, 8 Apr 2003 05:44: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.0096AE1B@cherry.ease.lsoft.com>; Tue, 8 Apr 2003 5:46:53 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 728047 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Apr 2003 05:46:53 -0400 Received: from 216.136.226.88 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 8 Apr 2003 05:46:53 -0500 Received: from [151.203.111.23] by web20307.mail.yahoo.com via HTTP; Tue, 08 Apr 2003 02:46:52 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20030408094652.6314.qmail@web20307.mail.yahoo.com> Date: Tue, 8 Apr 2003 02:46:52 -0700 Reply-To: Mailing List Sender: Mailing List From: Shanthi Karthik Subject: Re: Learning OSPF Comments: To: Yasuhiro Ohara To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20030407.053405.32296467.yasu@sfc.wide.ad.jp> Precedence: list Hello Yasu: Thanks to you and all others for your answers. Yes, you are pretty close to answering my question. Also your illustration is a much better one. If you could just extend your picture to R1, R2, and R3 being fully meshed [triangle], R1 wants to establish adjacencies with R2 and R3. However if the link between R2 and R3 fails, R1 DOES not want data traffic from R2 to R3 to pass thorough R1. Will setting the link cost to 0xffff prevent data traffic to be routed through R1 ? Thanks ! -Shalini --- Yasuhiro Ohara wrote: > > Hi, > > What you want to get is the natural behavior of OSPF > if R1 have > only one OSPF-enabled interface. > > Let me change slightly your illustration: > > | > R1 R2 > | | > --+---+---+-- > | > R3 > | > > In above, the data traffic will go through from > lower of R3 to > upper of R2 and vice versa, even if adjacencies > (OSPF protocol exchange > channel) had been formed between all the 3 routers. > > The data traffic won't be lead to R1 except the data > bound to R1 itself. > OSPF knows that the R1 will be a dead-end, wrong > direction for other > traffics than to R1 itself, and so don't route them > to R1. > > Am I missing your point ? > > regards, > yasu > > From: Shanthi Karthik > Subject: Learning OSPF > Date: Sun, 6 Apr 2003 10:45:25 -0700 > > > Hello: > > > > I am sorry if this is a beginner's question. But > is > > there any way in OSPF to establish an adjacency to > a > > router, but to receieve no data traffic from [or > send > > data to] that router under any circumstances ? I > > realize you can set the cost to your links very > high, > > but that is only a discouragement, as far as I can > > tell. > > > > Illusrtation: R1 <---- link1 ----- > R2 > > > > R1 wants to establish adjacency to R2, but wants > to > > receive [and send] no data traffic from R2. I > > understand R 1 and R2 will have to exchange > routing > > traffic. > > > > Thanks for your patience and answers. > > > > -Shalini > > > > > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Tax Center - File online, calculators, > forms, and more > > http://tax.yahoo.com __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 8 10:15:50 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12392 for ; Tue, 8 Apr 2003 10:15:50 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0096B190@cherry.ease.lsoft.com>; Tue, 8 Apr 2003 10:18:21 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 728561 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Apr 2003 10:18:21 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 8 Apr 2003 10:08:21 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11091; Tue, 8 Apr 2003 10:05:47 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200304081405.KAA11091@ietf.org> Date: Tue, 8 Apr 2003 10:05:46 -0400 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-ospfv3-mib-06.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Management Information Base for OSPFv3 Author(s) : D. Joyal, V. Manral, S. Zwolinski, J. Kwiatkowski Filename : draft-ietf-ospf-ospfv3-mib-06.txt Pages : 64 Date : 2003-4-7 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in IPv6-based internets. In particular, it defines objects for managing the Open Shortest Path First Routing Protocol for IPv6. Please send comments to ospf@discuss.microsoft.com. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-mib-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-ospfv3-mib-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-ospfv3-mib-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-7134036.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-ospfv3-mib-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-ospfv3-mib-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-7134036.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 8 14:18:00 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24721 for ; Tue, 8 Apr 2003 14:18: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.0096BAD1@cherry.ease.lsoft.com>; Tue, 8 Apr 2003 14:20:16 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 729445 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Apr 2003 14:20:16 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 8 Apr 2003 14:20:16 -0500 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id A8B63A04CA0 for ; Tue, 8 Apr 2003 11:20:11 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E9312A7.1000906@redback.com> Date: Tue, 8 Apr 2003 14:19:19 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: OSPF Charter Addition of draft-rosen-ospf-2547bis-dn-00.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit [Speaking as WG Co-chair] This draft proposes a mechanism for preventing leaking VPN routes from a CE site connected to multiple PEs. It makes use of an LSA option bit and is a generalization of a mechanism for area 0 VPN connection proposed in a previous PPVPN WG draft (draft-rosen-vpns-ospf-bgp-mpls-04.txt). At the last WG meeting, we discussed adding this work to the OSPF WG charter. There was mild support and no opposition. [Speaking as WG member] I propose we add this to the OSPF WG charter for the following reasons: 1. The use of the LSA option bit has been already been implemented by at least two vendors (and probably others). We need to standardize the usage of this LSA bit since it is becoming a de facto standard. 2. There was no opposition and mild support at the SF IETF meeting. 3. The generalization of the LSA bit was specifically requested by OSPF WG (actually myself) when the previous draft was reviewed. [Speaking as WG Co-Chair] Does anyone feel that this work should not be added to the OSPF WG charter? Are there any questions that need to be answered? Thanks, -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 8 14:48:44 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26073 for ; Tue, 8 Apr 2003 14:48:44 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.0096BDF1@cherry.ease.lsoft.com>; Tue, 8 Apr 2003 14:51:13 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 729564 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Apr 2003 14:51:12 -0400 Received: from 203.178.143.91 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 8 Apr 2003 14:51:12 -0500 Received: from localhost (localhost [127.0.0.1]) by plant.sfc.wide.ad.jp (Postfix) with ESMTP id 1E48A2CCCF; Wed, 9 Apr 2003 03:51:10 +0900 (JST) References: <20030407.053405.32296467.yasu@sfc.wide.ad.jp> <20030408094652.6314.qmail@web20307.mail.yahoo.com> X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20030409.035108.20118054.yasu@sfc.wide.ad.jp> Date: Wed, 9 Apr 2003 03:51:08 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: Learning OSPF Comments: To: sk_1990@yahoo.com To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20030408094652.6314.qmail@web20307.mail.yahoo.com> Precedence: list Content-Transfer-Encoding: 7bit Hi Shanthi, > If you could just extend your picture to R1, R2, and > R3 being fully meshed [triangle], R1 wants to > establish adjacencies with R2 and R3. However if the > link between R2 and R3 fails, R1 DOES not want data > traffic from R2 to R3 to pass thorough R1. Now I understand. You're correct, If the configuration is triangle and if R2-R3 link become down, R1 will actually get the data traffic to pass through. > Will setting the link cost to 0xffff prevent data traffic > to be routed through R1 ? Should be, but it may be somewhat implementation dependent I guess, because all the specification mentions explicitly regarding to LSInfinity is about the handling of the Summary/AS-External LSAs. I think it's pretty possible and it's reasonable that an implementation treat an intra-area route having cost LSInfinity as unreachable. Needs someone's follow ... ;p) # Shanthi, LSInfinity is 0xffffff, not 0xffff, you know. regards, yasu From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 8 15:24:22 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28817 for ; Tue, 8 Apr 2003 15:24:22 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.0096BE34@cherry.ease.lsoft.com>; Tue, 8 Apr 2003 15:26:53 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 729734 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Apr 2003 15:26:53 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 8 Apr 2003 15:26:53 -0500 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 9433E91BAF2 for ; Tue, 8 Apr 2003 12:26:51 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030407.053405.32296467.yasu@sfc.wide.ad.jp> <20030408094652.6314.qmail@web20307.mail.yahoo.com> <20030409.035108.20118054.yasu@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E932246.3020105@redback.com> Date: Tue, 8 Apr 2003 15:25:58 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Learning OSPF To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Yasuhiro Ohara wrote: > Hi Shanthi, > > >>If you could just extend your picture to R1, R2, and >>R3 being fully meshed [triangle], R1 wants to >>establish adjacencies with R2 and R3. However if the >>link between R2 and R3 fails, R1 DOES not want data >>traffic from R2 to R3 to pass thorough R1. > > > Now I understand. You're correct, If the configuration is > triangle and if R2-R3 link become down, R1 will actually > get the data traffic to pass through. > > >>Will setting the link cost to 0xffff prevent data traffic >>to be routed through R1 ? > > > Should be, but it may be somewhat implementation dependent I guess, > because all the specification mentions explicitly regarding to LSInfinity > is about the handling of the Summary/AS-External LSAs. > > I think it's pretty possible and it's reasonable that an implementation > treat an intra-area route having cost LSInfinity as unreachable. > > Needs someone's follow ... ;p) Yasu, I guess section 16.1 of RFC 2328 doesn't explicitly state that LSInfinity constitutes unreachability. However, I also think it is reasonable (and probable) that an implementation treats it as such. As for Shanthi's original question, there is no way to guarentee that a router with more than one active OSPF interface is not used for transit traffic. OSPFv3 has this capability. If your implementation supports multiple instances, you could configure each interface in a separate instance. Thanks, Acee > > # Shanthi, LSInfinity is 0xffffff, not 0xffff, you know. > > regards, > yasu > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 8 17:29:35 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03085 for ; Tue, 8 Apr 2003 17:29:34 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0096C23A@cherry.ease.lsoft.com>; Tue, 8 Apr 2003 17:32:04 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 729990 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Apr 2003 17:32:04 -0400 Received: from 209.119.0.100 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 8 Apr 2003 17:32:04 -0500 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0096C211@cherry.ease.lsoft.com>; Tue, 8 Apr 2003 17:32:03 -0400 Message-ID: Date: Tue, 8 Apr 2003 17:32:03 -0400 Reply-To: Mailing List Sender: Mailing List From: Mike Fox Subject: OSPFv3: Multiple Router-LSA (and intra-area-prefix LSA) questions To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list I've skimmed the archives all the way back and I don't think I've seen this addressed, but other implementations must have answered this question for themselves. What is the definitive way to remove a link from a Router LSA? This could be necessary because either the link has been deleted from the router, or the link no longer meets the requirement for being included in the router LSA (for example, the router lost all its adjacencies over the link). In OSPFv2, it's done by sending a new router advertisement without the link. Now with multiple router advertisements, it can get tricky. That observation drives the following question: Are link memberships in router LSAs "sticky"? It seems to me that this is almost necessary to have decent convergence on removed links. For example, assume RT1 originates three router LSA's into an area, as follows: Link state id: 1 Advertising Router: RT1 links: link1, link2 Link state id: 2 Advertising Router: RT1 links: link3, link4 Link state id: 3 Advertising router: RT1 links: link5 Now if, RT1 later sends the following Router LSA: Link State id: 2 Advertising Router: RT1 links: link4 Is this enough to cause other routers to realize that link3 has been removed from router1? Or is it necessary for them to verify that link3 has not moved to the router LSA with link state id 1 or 3, or even a new one with link state id 4? If links are not "sticky", then how long should a receiving router wait to make sure it doesn't receive new copies of another LSA containing that link before it can decide that link is deleted from RT1? Also, if links are not "sticky", consider the original case above but now link5 has been deleted. How can RT1 communicate that fact? If links are sticky he can just flush the router LSA with link state id 3. If they aren't, that would not be sufficient because other routers would have to verify that link5 hasn't moved to another link state id, meaning waiting an interval to make sure a new router LSA with link5 in it does not arrive from RT1. In either case, if the links are not sticky to their specific router LSA instances, what's necessary starts to look suspiciously like recreating TCP's fragmentation/reassembly logic in the routing process. Btw, the same question can be asked about intra-area-prefix LSAs. Are prefixes sticky to particular intra-area-prefix LSA instances (link state IDs)? Virtually the same problems and questions arise about them. Mike From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 8 19:18:02 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07916 for ; Tue, 8 Apr 2003 19:18:01 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0096C3D2@cherry.ease.lsoft.com>; Tue, 8 Apr 2003 19:20:34 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 730336 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Apr 2003 19:20:34 -0400 Received: from 207.217.120.12 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 8 Apr 2003 19:20:34 -0500 Received: from user-2ivfk1k.dialup.mindspring.com ([165.247.208.52] helo=earthlink.net) by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1932OF-000459-00 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 08 Apr 2003 16:20:31 -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: <20030404115413.36400.qmail@web20505.mail.yahoo.com> <3E8DF0E5.1A097E29@earthlink.net> <3E8F925B.3000308@redback.com> <3E9217FA.4291CF24@earthlink.net> <3E92236E.5040908@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E935828.A40A4210@earthlink.net> Date: Tue, 8 Apr 2003 16:15:52 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Draft : Graceful Restart : : grace period, etc To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Acee Lindem, Since,, you skipped the inline re-comments, I will assume that at least you read them.. :) I think I have expressed as best as I could (I am not a tech writer) how I feel that this draft should evolve. So in summary... ` 0) Remove the length (seconds) field from the grace-LSA. 1) Transmit DNA grace-LSAs at adj creation time. 2) Let the helpers determine amount of time that they will function as a helper. Suggest a minimum of 1 hr time. 3) Reflood the DNA grace-LSAs anytime the contents have changed. 4) If the restart router expects to be down for a period longer than X, then retransmit the Grace-LSAs as MAXage LSAs. This would minimize bandwidth requirements and allow a restarting router to have either scheduled or unscheduled restarts. I don't know what else to add, except if you adopt one or more of these suggestions, then please add my name to your comment list. :) Mitchell Erblich Sr Software Engineer ============================ Acee Lindem wrote: > > Erblichs wrote: > > Acee Lindem, > > > > Sometimes my logic is a little obtuse.. > > > > Most of it is inline... > > > > I will first throw two new questions to you!!!! > > > > 1) Why don't you send out the Grace LSA at full > > adj timeframe. It would take effect after > > RouterDeadinterval has expired? > > How do you know, apriori, that the OSPF instance is > restarting and not completely dead? Why do you care? As long as the topology isn't changing then everything is ok. Wwhy not minimize the effects of unnecessary SPF computations? > > > > > This would also take care of unscheduled restarts > > and allow you to do an unscheduled graceful > > restart!!!! > > > > You could also send them as DNA LSAs.. See inline. > > > > The only new twist is that if you then schedule > > a restart, you may want to be able to cancel your > > previous request or update the LSAs over time. > > But if you conisder a stable topology, then why > > NOT?? > > > > > > 2) A) 2.1 3rd, paragraph.. > > "Their age field set to 0," > > Why can't you send DNA grace-LSAs???? > > You wouldn't gain anything since the grace interval cannot > exceed the LSA refresh time. > So, first why do you need to specify the grace-LSA timeframe. Let it be implicitly known to be 1 hr! With DNA grace-LSAs, we don't need to reflood them. If I sent them out at adj creation time and the topology isn't changing, then I don't need to consume resources and keep on re-flooding them.. Thus, they can last multiple hours or longer.. > > > > B) 2.1, 4th paragraph. > > > > "it should retransmit... until > > they are acknowledged". If you can't retransmit the > > same LSA until 5 secs have passed, if a router > > was congested, you may want to resubmit the grace-LSA > > with a longer length timeframe to your helpers. I am > > assuming just bump your instance. Correct? > > There are implementations that back off LSA retransmissions and the > "Prioritized Treatment of Specific OSPF Packets and Congestion > Avoidance" draft recommends this. However, this is not standard > OSPF flooding as described in RFC2328 and it is an independent > issue. > No, no, you are missing my point. Until all of your grace-LSAs are ack'ed, you can't continue successfully with a graceful-restart. This delay consumes time that you specified in your grace-LSA. Yea, again, I don't know why you need to specify the amount of time!! The timeframe that the helpers will help you can be set independently and your spec doesn't allow them to communicate the amount of time that they will keeep around a grace-LSA. Sorry, minor sidetrack. So, the time consumed to get the ack, actually reduces the amount of time before the grace-LSA expires. > > > > > > > > Mitchell > > ================ > > Acee Lindem wrote: > > > >>Mitchell, > >> > >>See answers below. > >> > >>Erblichs wrote: > >> > >>>Group, > >>> > >>> 1) Within 2.1 "Entering graceful restart", iff all > >>> the LSAs were from DC specified NBRs with DNA > >>> LSAs should the LS RefreshTime still be followed? > >> > >>LSA Refresh isn't relevant since the restarting router will > >>reestablish adjacencies. > > > > > > Then why have a suggestion of 1800 secs for LSReshTime > > in your draft at the end of the 1st paragraph in section > > 2.1? > > > > In my scenario, there would be no reason not to let the > > value approach or exceed 3600 secs (1 hr). > > > > variation on a theme? Why not let the max value of your > > grace-LSA length field allow the helper determine what > > is the max that he will support? > > -- what happens if you specify a value that is > > greater than what the helper supports? > > Ans A: The helper sees it as an invalid request > > and throws away the whole request, > > > > OR > > Ans B: The helper determines what the length he > > will support? > > > > If it is B, then why have the length field. Just let > > the helper decide how long to support the request? > > > > > >>> 2) Within 2.2 "When to exit graceful restart", number > >>> (3) "The grace period expires". > >>> > >>> What happens if we follow #3 and your #1 "reestablished > >>> all its adjacencies" criteria is not met? > >> > >>The restarting router will exit graceful restart anyway. > > > > > > Why? If you still have a non-changing topology, why > > limit the value to what you had said to the helpers? > > > > So, what if you asked for x time and it took you > > x + y time? > > > > > >>> Or are you stating that the specified "grace period" was > >>> to short to perform what was required? > >> > >>Not necessarily - perhaps the topology has changed and graceful restart > >>cannot be completed successfully. > >> > >> > >>> 3) Within 2.2. Would seeing a hello without the graceful > >>> restarting router id", force it to exit? > >> > >>No. The adjacency can go all the way down on the helper router. The hello > >>shouldn't be used as a criteria for exiting helper mode. Do not confuse > >>this with other graceful restart proposals. > >> > > > > > > I see that my question with the hello was answered in the > > 2. (3) "an hello packet is received".. > > > > I am confused. One router may list you as the DR and another > > may not? If one is a helper, then why would it take the adj > > down if all the crieria were met? > > > > I thought that helpers > > MUST send hellos as if you (graceful restarting router) were > > still there!! > > "an Hello packet is received from a neighbor listing the > > router as the Designated Router". > > > > If it did keep anouncing you in the hellos (you weren't > > the DR) and lets say that the DR went down. Could you > > then be elected as the DR while you were still rebooting? > > > > > >>> 4) Within 2.2. Would seeing a hello without the graceful > >>> restarting router id as the earlier DR or BDR, cause > >>> it to exit, if it was a DR / BDR? > >> > >>Not directly, but an inconsistency with the pre-restart LSA will cause > >>the restarting router to exist graceful restart prematurely. > >> > >> > >>> 5) Within 2.2. Is it implimentation dependent on how we > >>> determine our existing nbrs and place their router ids > >>> in a hello? > >> > >>This isn't changed for graceful restart. > > > > > > I thought that you could save past nbr-ids in NVRAM > > and then compare to existing hellos... > > > >>> 6) Within 2.2 (1), isn't adj establishment partly the > >>> recieving of hellos, with your own router-id? Shouldn't > >>> that inform others that we are back and to cancel > >>> their helper graceful nbr timer? > >>> > >>> 7 & 8) Within 2.3 "Actions on exiting graceful restart". > >>> > >>> 7) Shouldn't the sending hellos be performed that > >>> identify full adj be a criteria here? > >> > >>No. LSA convergence with the pre-restart LSAs is a much surer > >>mechanism for determining the graceful restart can be exited. > >> > >> > >>> > >>> 8) I am unsure whether you are specifying the > >>> storage of part of restarting router's LSDB into > >>> non-volatile memory. If so, then upon retrieval, > >>> shouldn't some elements of the LSDB be aged > >>> by the amount that the actual amount of time > >>> the LSAs were in NV memory? > >> > >>There is no mention of storing LSAs in non-volatile storage. > >> > > > > > > Ok, you aren't suggesting saving the LSDB in NVRAM > > or some other type of storage media.. > > > >>> > >>> > >>> Mitchell Erblich > >>> ================================== > >>> > >> > >>-- > >>Acee > > > > > > -- > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 8 19:54:19 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08607 for ; Tue, 8 Apr 2003 19:54:19 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0096C5BD@cherry.ease.lsoft.com>; Tue, 8 Apr 2003 19:56:50 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 730429 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Apr 2003 19:56:50 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 8 Apr 2003 19:56:50 -0500 Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h38Nunu99821 for ; Tue, 8 Apr 2003 16:56:49 -0700 (PDT) (envelope-from padma@juniper.net) Received: (from padma@localhost) by garnet.juniper.net (8.11.5/8.11.3) id h38NunH88489 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Apr 2003 16:56:49 -0700 (PDT) (envelope-from padma) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200304082356.h38NunH88489@garnet.juniper.net> Date: Tue, 8 Apr 2003 16:56:49 -0700 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: Draft : Graceful Restart : : grace period, etc To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E935828.A40A4210@earthlink.net> from "Erblichs" at Apr 08, 2003 04:15:52 PM Precedence: list Content-Transfer-Encoding: 7bit Mitchell, I'll try to address your comments > > Acee Lindem, > > Since,, you skipped the inline re-comments, I will assume > that at least you read them.. :) > > I think I have expressed as best as I could (I am not > a tech writer) how I feel that this draft should evolve. > > So in summary... > > ` 0) Remove the length (seconds) field from the grace-LSA. > This is using the TLV format .. so you want to keep the length > 1) Transmit DNA grace-LSAs at adj creation time. > This is not very useful. Today unless you have DNA lsa you cannot expect to be requesting a grace period of over one hour -- as all the LSA in the other routers database will expire at the most in 1hr. So if you decide to send a grace LSA it would be the most recent one that you built and hence if it has time to expire then the previous would already be gone. > 2) Let the helpers determine amount of time that > they will function as a helper. Suggest a minimum > of 1 hr time. > This is a matter of policy .. even if the helper decides that he is not going to help for the whole period .. as he is not going to signal it to the restarting router .. I do not see the use of doing so. > 3) Reflood the DNA grace-LSAs anytime the contents > have changed. > See my response in 1. > 4) If the restart router expects to be down for a period > longer than X, then retransmit the Grace-LSAs as > MAXage LSAs. > I do not see the benefit or I am missing your point Padma > This would minimize bandwidth requirements and allow a > restarting router to have either scheduled or unscheduled > restarts. > > I don't know what else to add, except if you adopt one or > more of these suggestions, then please add my name to your > comment list. :) > > Mitchell Erblich > Sr Software Engineer > ============================ > > > Acee Lindem wrote: > > > > Erblichs wrote: > > > Acee Lindem, > > > > > > Sometimes my logic is a little obtuse.. > > > > > > Most of it is inline... > > > > > > I will first throw two new questions to you!!!! > > > > > > 1) Why don't you send out the Grace LSA at full > > > adj timeframe. It would take effect after > > > RouterDeadinterval has expired? > > > > How do you know, apriori, that the OSPF instance is > > restarting and not completely dead? > > Why do you care? As long as the topology isn't changing > then everything is ok. > > Wwhy not minimize the effects of unnecessary SPF computations? > > > > > > > > > This would also take care of unscheduled restarts > > > and allow you to do an unscheduled graceful > > > restart!!!! > > > > > > You could also send them as DNA LSAs.. See inline. > > > > > > The only new twist is that if you then schedule > > > a restart, you may want to be able to cancel your > > > previous request or update the LSAs over time. > > > But if you conisder a stable topology, then why > > > NOT?? > > > > > > > > > 2) A) 2.1 3rd, paragraph.. > > > "Their age field set to 0," > > > Why can't you send DNA grace-LSAs???? > > > > You wouldn't gain anything since the grace interval cannot > > exceed the LSA refresh time. > > > > So, first why do you need to specify the grace-LSA > timeframe. Let it be implicitly known to be 1 hr! > > With DNA grace-LSAs, we > don't need to reflood them. If I sent them out > at adj creation time and the topology isn't > changing, then I don't need to consume > resources and keep on re-flooding them.. > > Thus, they can last multiple hours or longer.. > > > > > > > B) 2.1, 4th paragraph. > > > > > > "it should retransmit... until > > > they are acknowledged". If you can't retransmit the > > > same LSA until 5 secs have passed, if a router > > > was congested, you may want to resubmit the grace-LSA > > > with a longer length timeframe to your helpers. I am > > > assuming just bump your instance. Correct? > > > > There are implementations that back off LSA retransmissions and the > > "Prioritized Treatment of Specific OSPF Packets and Congestion > > Avoidance" draft recommends this. However, this is not standard > > OSPF flooding as described in RFC2328 and it is an independent > > issue. > > > > No, no, you are missing my point. Until all of your grace-LSAs are > ack'ed, you can't continue successfully with a graceful-restart. > > This delay consumes time that you specified in your grace-LSA. Yea, > again, I don't know why you need to specify the amount of time!! > The timeframe that the helpers will help you can be set independently > and your spec doesn't allow them to communicate the amount of time > that they will keeep around a grace-LSA. > > Sorry, minor sidetrack. So, the time consumed to get the ack, actually > reduces the amount of time before the grace-LSA expires. > > > > > > > > > > > > Mitchell > > > ================ > > > Acee Lindem wrote: > > > > > >>Mitchell, > > >> > > >>See answers below. > > >> > > >>Erblichs wrote: > > >> > > >>>Group, > > >>> > > >>> 1) Within 2.1 "Entering graceful restart", iff all > > >>> the LSAs were from DC specified NBRs with DNA > > >>> LSAs should the LS RefreshTime still be followed? > > >> > > >>LSA Refresh isn't relevant since the restarting router will > > >>reestablish adjacencies. > > > > > > > > > Then why have a suggestion of 1800 secs for LSReshTime > > > in your draft at the end of the 1st paragraph in section > > > 2.1? > > > > > > In my scenario, there would be no reason not to let the > > > value approach or exceed 3600 secs (1 hr). > > > > > > variation on a theme? Why not let the max value of your > > > grace-LSA length field allow the helper determine what > > > is the max that he will support? > > > -- what happens if you specify a value that is > > > greater than what the helper supports? > > > Ans A: The helper sees it as an invalid request > > > and throws away the whole request, > > > > > > OR > > > Ans B: The helper determines what the length he > > > will support? > > > > > > If it is B, then why have the length field. Just let > > > the helper decide how long to support the request? > > > > > > > > >>> 2) Within 2.2 "When to exit graceful restart", number > > >>> (3) "The grace period expires". > > >>> > > >>> What happens if we follow #3 and your #1 "reestablished > > >>> all its adjacencies" criteria is not met? > > >> > > >>The restarting router will exit graceful restart anyway. > > > > > > > > > Why? If you still have a non-changing topology, why > > > limit the value to what you had said to the helpers? > > > > > > So, what if you asked for x time and it took you > > > x + y time? > > > > > > > > >>> Or are you stating that the specified "grace period" was > > >>> to short to perform what was required? > > >> > > >>Not necessarily - perhaps the topology has changed and graceful restart > > >>cannot be completed successfully. > > >> > > >> > > >>> 3) Within 2.2. Would seeing a hello without the graceful > > >>> restarting router id", force it to exit? > > >> > > >>No. The adjacency can go all the way down on the helper router. The hello > > >>shouldn't be used as a criteria for exiting helper mode. Do not confuse > > >>this with other graceful restart proposals. > > >> > > > > > > > > > I see that my question with the hello was answered in the > > > 2. (3) "an hello packet is received".. > > > > > > I am confused. One router may list you as the DR and another > > > may not? If one is a helper, then why would it take the adj > > > down if all the crieria were met? > > > > > > I thought that helpers > > > MUST send hellos as if you (graceful restarting router) were > > > still there!! > > > "an Hello packet is received from a neighbor listing the > > > router as the Designated Router". > > > > > > If it did keep anouncing you in the hellos (you weren't > > > the DR) and lets say that the DR went down. Could you > > > then be elected as the DR while you were still rebooting? > > > > > > > > >>> 4) Within 2.2. Would seeing a hello without the graceful > > >>> restarting router id as the earlier DR or BDR, cause > > >>> it to exit, if it was a DR / BDR? > > >> > > >>Not directly, but an inconsistency with the pre-restart LSA will cause > > >>the restarting router to exist graceful restart prematurely. > > >> > > >> > > >>> 5) Within 2.2. Is it implimentation dependent on how we > > >>> determine our existing nbrs and place their router ids > > >>> in a hello? > > >> > > >>This isn't changed for graceful restart. > > > > > > > > > I thought that you could save past nbr-ids in NVRAM > > > and then compare to existing hellos... > > > > > >>> 6) Within 2.2 (1), isn't adj establishment partly the > > >>> recieving of hellos, with your own router-id? Shouldn't > > >>> that inform others that we are back and to cancel > > >>> their helper graceful nbr timer? > > >>> > > >>> 7 & 8) Within 2.3 "Actions on exiting graceful restart". > > >>> > > >>> 7) Shouldn't the sending hellos be performed that > > >>> identify full adj be a criteria here? > > >> > > >>No. LSA convergence with the pre-restart LSAs is a much surer > > >>mechanism for determining the graceful restart can be exited. > > >> > > >> > > >>> > > >>> 8) I am unsure whether you are specifying the > > >>> storage of part of restarting router's LSDB into > > >>> non-volatile memory. If so, then upon retrieval, > > >>> shouldn't some elements of the LSDB be aged > > >>> by the amount that the actual amount of time > > >>> the LSAs were in NV memory? > > >> > > >>There is no mention of storing LSAs in non-volatile storage. > > >> > > > > > > > > > Ok, you aren't suggesting saving the LSDB in NVRAM > > > or some other type of storage media.. > > > > > >>> > > >>> > > >>> Mitchell Erblich > > >>> ================================== > > >>> > > >> > > >>-- > > >>Acee > > > > > > > > > > -- > > Acee > From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 8 21:23:03 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11026 for ; Tue, 8 Apr 2003 21:23:02 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0096C837@cherry.ease.lsoft.com>; Tue, 8 Apr 2003 21:25:33 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 730621 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Apr 2003 21:25:33 -0400 Received: from 207.217.120.22 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 8 Apr 2003 21:25:33 -0500 Received: from user-2ivfk1k.dialup.mindspring.com ([165.247.208.52] helo=earthlink.net) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1934LB-000412-00 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 08 Apr 2003 18:25:30 -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: <200304082356.h38NunH88489@garnet.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E93755E.1937BC89@earthlink.net> Date: Tue, 8 Apr 2003 18:20:30 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Draft : Graceful Restart : : grace period, etc To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Padma, These are my last comments!! Also inline... Why doesn't the draft RFC authors want to allow non-scheduled restarts in this draft? Is there something wrong with the idea of un-scheduled restarts? Why restrict it to only scheduled restarts??? Why require the grace-LSAs to be reflooded every 30 minutes to 1 hr??? Why not send the grace-LSAs without the Type=1, Length=4 grace period field?? It will be determined by the helpers anyway. The sentance is. "The number of seconds that the router's neighbors should continue to advertise the router as fully adjacent".... Thus, without the word "MUST", implimentations will probably follow their own rules. Thus, the grace period field really isn't needed and just consumes bandwidth!!! Mitchell Erblich =================== Padma Pillay-Esnault wrote: > > Mitchell, > > I'll try to address your comments > > > > > Acee Lindem, > > > > Since,, you skipped the inline re-comments, I will assume > > that at least you read them.. :) > > > > I think I have expressed as best as I could (I am not > > a tech writer) how I feel that this draft should evolve. > > > > So in summary... > > > > ` 0) Remove the length (seconds) field from the grace-LSA. > > > This is using the TLV format .. so you want to keep the length Of course, Type, Length, Value... Fine. Reword.. Remove the Grace-Period field of (Type =1, Length = 4). Why transmit the field value????? > > > 1) Transmit DNA grace-LSAs at adj creation time. > > > This is not very useful. Today unless you have DNA lsa you cannot > expect to be requesting a grace period of over one hour -- as > all the LSA in the other routers database will expire at the > most in 1hr. > So if you decide to send a grace LSA it would be the most recent one > that you built and hence if it has time to expire then the previous > would already be gone. Think ahead of tomarrow, not today... How should this work in the utopian word? If the graceful restart is a good idea, then it NOT should be used for ALL possible restarts?? Why not restrict the amount of flooding with THESE types of LSAs if this draft becomes a standard RFC?? What happens if I send the grace-LSAs at adj formation time and then reflood them every 55 minutes?? This removes the lightweight mechanism of the draft, but still gets me unscheduled restart functionality? Maybe i will just do that.. BTW, and also do unscheduled restarts with my BGP protocol once it becomes a standard. Thus, a restriction of 1 hr isn't sensible. Else, even if I follow your logic, then why do I ask for 1 hr? Should my implimentation in the helper not ack the grace-LSA if the specified grace-period is over 1 hr from the restarting router? This is unspecified behavior!!! > > > 2) Let the helpers determine amount of time that > > they will function as a helper. Suggest a minimum > > of 1 hr time. > > > > This is a matter of policy .. even if the helper decides that > he is not going to help for the whole period .. as he is not > going to signal it to the restarting router .. I do not see > the use of doing so. > > > 3) Reflood the DNA grace-LSAs anytime the contents > > have changed. > > > See my response in 1. > > > 4) If the restart router expects to be down for a period > > longer than X, then retransmit the Grace-LSAs as > > MAXage LSAs. > > > I do not see the benefit or I am missing your point > > Padma > > > This would minimize bandwidth requirements and allow a > > restarting router to have either scheduled or unscheduled > > restarts. > > > > I don't know what else to add, except if you adopt one or > > more of these suggestions, then please add my name to your > > comment list. :) > > > > Mitchell Erblich > > Sr Software Engineer > > ============================ > > > > > > Acee Lindem wrote: > > > > > > Erblichs wrote: > > > > Acee Lindem, > > > > > > > > Sometimes my logic is a little obtuse.. > > > > > > > > Most of it is inline... > > > > > > > > I will first throw two new questions to you!!!! > > > > > > > > 1) Why don't you send out the Grace LSA at full > > > > adj timeframe. It would take effect after > > > > RouterDeadinterval has expired? > > > > > > How do you know, apriori, that the OSPF instance is > > > restarting and not completely dead? > > > > Why do you care? As long as the topology isn't changing > > then everything is ok. > > > > Wwhy not minimize the effects of unnecessary SPF computations? > > > > > > > > > > > > > This would also take care of unscheduled restarts > > > > and allow you to do an unscheduled graceful > > > > restart!!!! > > > > > > > > You could also send them as DNA LSAs.. See inline. > > > > > > > > The only new twist is that if you then schedule > > > > a restart, you may want to be able to cancel your > > > > previous request or update the LSAs over time. > > > > But if you conisder a stable topology, then why > > > > NOT?? > > > > > > > > > > > > 2) A) 2.1 3rd, paragraph.. > > > > "Their age field set to 0," > > > > Why can't you send DNA grace-LSAs???? > > > > > > You wouldn't gain anything since the grace interval cannot > > > exceed the LSA refresh time. > > > > > > > So, first why do you need to specify the grace-LSA > > timeframe. Let it be implicitly known to be 1 hr! > > > > With DNA grace-LSAs, we > > don't need to reflood them. If I sent them out > > at adj creation time and the topology isn't > > changing, then I don't need to consume > > resources and keep on re-flooding them.. > > > > Thus, they can last multiple hours or longer.. > > > > > > > > > > B) 2.1, 4th paragraph. > > > > > > > > "it should retransmit... until > > > > they are acknowledged". If you can't retransmit the > > > > same LSA until 5 secs have passed, if a router > > > > was congested, you may want to resubmit the grace-LSA > > > > with a longer length timeframe to your helpers. I am > > > > assuming just bump your instance. Correct? > > > > > > There are implementations that back off LSA retransmissions and the > > > "Prioritized Treatment of Specific OSPF Packets and Congestion > > > Avoidance" draft recommends this. However, this is not standard > > > OSPF flooding as described in RFC2328 and it is an independent > > > issue. > > > > > > > No, no, you are missing my point. Until all of your grace-LSAs are > > ack'ed, you can't continue successfully with a graceful-restart. > > > > This delay consumes time that you specified in your grace-LSA. Yea, > > again, I don't know why you need to specify the amount of time!! > > The timeframe that the helpers will help you can be set independently > > and your spec doesn't allow them to communicate the amount of time > > that they will keeep around a grace-LSA. > > > > Sorry, minor sidetrack. So, the time consumed to get the ack, actually > > reduces the amount of time before the grace-LSA expires. > > > > > > > > > > > > > > > > Mitchell > > > > ================ > > > > Acee Lindem wrote: > > > > > > > >>Mitchell, > > > >> > > > >>See answers below. > > > >> > > > >>Erblichs wrote: > > > >> > > > >>>Group, > > > >>> > > > >>> 1) Within 2.1 "Entering graceful restart", iff all > > > >>> the LSAs were from DC specified NBRs with DNA > > > >>> LSAs should the LS RefreshTime still be followed? > > > >> > > > >>LSA Refresh isn't relevant since the restarting router will > > > >>reestablish adjacencies. > > > > > > > > > > > > Then why have a suggestion of 1800 secs for LSReshTime > > > > in your draft at the end of the 1st paragraph in section > > > > 2.1? > > > > > > > > In my scenario, there would be no reason not to let the > > > > value approach or exceed 3600 secs (1 hr). > > > > > > > > variation on a theme? Why not let the max value of your > > > > grace-LSA length field allow the helper determine what > > > > is the max that he will support? > > > > -- what happens if you specify a value that is > > > > greater than what the helper supports? > > > > Ans A: The helper sees it as an invalid request > > > > and throws away the whole request, > > > > > > > > OR > > > > Ans B: The helper determines what the length he > > > > will support? > > > > > > > > If it is B, then why have the length field. Just let > > > > the helper decide how long to support the request? > > > > > > > > > > > >>> 2) Within 2.2 "When to exit graceful restart", number > > > >>> (3) "The grace period expires". > > > >>> > > > >>> What happens if we follow #3 and your #1 "reestablished > > > >>> all its adjacencies" criteria is not met? > > > >> > > > >>The restarting router will exit graceful restart anyway. > > > > > > > > > > > > Why? If you still have a non-changing topology, why > > > > limit the value to what you had said to the helpers? > > > > > > > > So, what if you asked for x time and it took you > > > > x + y time? > > > > > > > > > > > >>> Or are you stating that the specified "grace period" was > > > >>> to short to perform what was required? > > > >> > > > >>Not necessarily - perhaps the topology has changed and graceful restart > > > >>cannot be completed successfully. > > > >> > > > >> > > > >>> 3) Within 2.2. Would seeing a hello without the graceful > > > >>> restarting router id", force it to exit? > > > >> > > > >>No. The adjacency can go all the way down on the helper router. The hello > > > >>shouldn't be used as a criteria for exiting helper mode. Do not confuse > > > >>this with other graceful restart proposals. > > > >> > > > > > > > > > > > > I see that my question with the hello was answered in the > > > > 2. (3) "an hello packet is received".. > > > > > > > > I am confused. One router may list you as the DR and another > > > > may not? If one is a helper, then why would it take the adj > > > > down if all the crieria were met? > > > > > > > > I thought that helpers > > > > MUST send hellos as if you (graceful restarting router) were > > > > still there!! > > > > "an Hello packet is received from a neighbor listing the > > > > router as the Designated Router". > > > > > > > > If it did keep anouncing you in the hellos (you weren't > > > > the DR) and lets say that the DR went down. Could you > > > > then be elected as the DR while you were still rebooting? > > > > > > > > > > > >>> 4) Within 2.2. Would seeing a hello without the graceful > > > >>> restarting router id as the earlier DR or BDR, cause > > > >>> it to exit, if it was a DR / BDR? > > > >> > > > >>Not directly, but an inconsistency with the pre-restart LSA will cause > > > >>the restarting router to exist graceful restart prematurely. > > > >> > > > >> > > > >>> 5) Within 2.2. Is it implimentation dependent on how we > > > >>> determine our existing nbrs and place their router ids > > > >>> in a hello? > > > >> > > > >>This isn't changed for graceful restart. > > > > > > > > > > > > I thought that you could save past nbr-ids in NVRAM > > > > and then compare to existing hellos... > > > > > > > >>> 6) Within 2.2 (1), isn't adj establishment partly the > > > >>> recieving of hellos, with your own router-id? Shouldn't > > > >>> that inform others that we are back and to cancel > > > >>> their helper graceful nbr timer? > > > >>> > > > >>> 7 & 8) Within 2.3 "Actions on exiting graceful restart". > > > >>> > > > >>> 7) Shouldn't the sending hellos be performed that > > > >>> identify full adj be a criteria here? > > > >> > > > >>No. LSA convergence with the pre-restart LSAs is a much surer > > > >>mechanism for determining the graceful restart can be exited. > > > >> > > > >> > > > >>> > > > >>> 8) I am unsure whether you are specifying the > > > >>> storage of part of restarting router's LSDB into > > > >>> non-volatile memory. If so, then upon retrieval, > > > >>> shouldn't some elements of the LSDB be aged > > > >>> by the amount that the actual amount of time > > > >>> the LSAs were in NV memory? > > > >> > > > >>There is no mention of storing LSAs in non-volatile storage. > > > >> > > > > > > > > > > > > Ok, you aren't suggesting saving the LSDB in NVRAM > > > > or some other type of storage media.. > > > > > > > >>> > > > >>> > > > >>> Mitchell Erblich > > > >>> ================================== > > > >>> > > > >> > > > >>-- > > > >>Acee > > > > > > > > > > > > > > -- > > > Acee > > From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 8 21:59:29 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11809 for ; Tue, 8 Apr 2003 21:59:28 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0096C8BD@cherry.ease.lsoft.com>; Tue, 8 Apr 2003 22:01:45 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 730713 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Apr 2003 22:01:45 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 8 Apr 2003 22:01:44 -0500 Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h3921iu08646 for ; Tue, 8 Apr 2003 19:01:44 -0700 (PDT) (envelope-from padma@juniper.net) Received: (from padma@localhost) by garnet.juniper.net (8.11.5/8.11.3) id h3921iK25130 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 8 Apr 2003 19:01:44 -0700 (PDT) (envelope-from padma) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200304090201.h3921iK25130@garnet.juniper.net> Date: Tue, 8 Apr 2003 19:01:44 -0700 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: Draft : Graceful Restart : : grace period, etc To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E93755E.1937BC89@earthlink.net> from "Erblichs" at Apr 08, 2003 06:20:30 PM Precedence: list Content-Transfer-Encoding: 7bit > > Padma, > > > These are my last comments!! > > Also inline... > > Why doesn't the draft RFC authors want to > allow non-scheduled restarts in this > draft? > But it does - I actually contributed a lot to that ;-) > Is there something wrong with the idea > of un-scheduled restarts? No - Absolutely > > Why restrict it to only scheduled > restarts??? > see above > Why require > the grace-LSAs to be reflooded every > 30 minutes to 1 hr??? It doesn't need to - nor require but the general mechanism od refresh is the same for all LSA and grace happens to be one of them. > > Why not send the grace-LSAs without > the Type=1, Length=4 grace period field?? > It will be determined by the helpers > anyway. This is a "accepted norm" TLV ... What is the advantage ? let say in the future you want to send more infos there .. by using TLV you know where an info starts and finishes. Unknown TLV should be just ignored by implementations. Here you have a very easy way to extend without breaking older implementation. > > The sentance is. > > "The number of seconds that the router's > neighbors should continue to advertise the > router as fully adjacent".... > > Thus, without the word "MUST", implimentations > will probably follow their own rules. Thus, the > grace period field really isn't needed and just > consumes bandwidth!!! > > Now I like the way the sentence is written ;-) because - An implementation can keep the state shown as FULL for the restarting neighbor but keep track of the real state for grace-period or just blocks rebuilding LSAs to reflect the real state for that time. the "should" enables us to do whatever is implementation architecture is simplest. The grace period is important for the helpers to know when they will eventually tear down the adjacency/rebuild lsa to reflect the real state . If the grace period did not exist then the restarting router would have to be in FULL state within the Dead Router Interval .. which is configurable and can be very short for a big DBD exchange. Padma > > Mitchell Erblich > =================== > > > > > > Padma Pillay-Esnault wrote: > > > > Mitchell, > > > > I'll try to address your comments > > > > > > > > Acee Lindem, > > > > > > Since,, you skipped the inline re-comments, I will assume > > > that at least you read them.. :) > > > > > > I think I have expressed as best as I could (I am not > > > a tech writer) how I feel that this draft should evolve. > > > > > > So in summary... > > > > > > ` 0) Remove the length (seconds) field from the grace-LSA. > > > > > This is using the TLV format .. so you want to keep the length > > Of course, Type, Length, Value... Fine. Reword.. > Remove > the Grace-Period field of (Type =1, Length = 4). > Why transmit the field value????? > > > > > 1) Transmit DNA grace-LSAs at adj creation time. > > > > > This is not very useful. Today unless you have DNA lsa you cannot > > expect to be requesting a grace period of over one hour -- as > > all the LSA in the other routers database will expire at the > > most in 1hr. > > So if you decide to send a grace LSA it would be the most recent one > > that you built and hence if it has time to expire then the previous > > would already be gone. > > Think ahead of tomarrow, not today... > How should this work in the utopian word? If the graceful > restart is a good idea, then it NOT should be used for ALL > possible restarts?? > > Why not restrict the amount of flooding with THESE types > of LSAs if this draft becomes a standard RFC?? > > What happens if I send the grace-LSAs at adj formation > time and then reflood them every 55 minutes?? This > removes the lightweight mechanism of the draft, but > still gets me unscheduled restart functionality? Maybe > i will just do that.. BTW, and also do unscheduled > restarts with my BGP protocol once it becomes a > standard. > > Thus, a restriction of 1 hr isn't sensible. Else, even if > I follow your logic, then why do I ask for 1 hr? Should > my implimentation in the helper not ack the grace-LSA if > the specified grace-period is over 1 hr from the restarting > router? This is unspecified behavior!!! > > > > > > > 2) Let the helpers determine amount of time that > > > they will function as a helper. Suggest a minimum > > > of 1 hr time. > > > > > > > This is a matter of policy .. even if the helper decides that > > he is not going to help for the whole period .. as he is not > > going to signal it to the restarting router .. I do not see > > the use of doing so. > > > > > 3) Reflood the DNA grace-LSAs anytime the contents > > > have changed. > > > > > See my response in 1. > > > > > 4) If the restart router expects to be down for a period > > > longer than X, then retransmit the Grace-LSAs as > > > MAXage LSAs. > > > > > I do not see the benefit or I am missing your point > > > > Padma > > > > > This would minimize bandwidth requirements and allow a > > > restarting router to have either scheduled or unscheduled > > > restarts. > > > > > > I don't know what else to add, except if you adopt one or > > > more of these suggestions, then please add my name to your > > > comment list. :) > > > > > > Mitchell Erblich > > > Sr Software Engineer > > > ============================ > > > > > > > > > Acee Lindem wrote: > > > > > > > > Erblichs wrote: > > > > > Acee Lindem, > > > > > > > > > > Sometimes my logic is a little obtuse.. > > > > > > > > > > Most of it is inline... > > > > > > > > > > I will first throw two new questions to you!!!! > > > > > > > > > > 1) Why don't you send out the Grace LSA at full > > > > > adj timeframe. It would take effect after > > > > > RouterDeadinterval has expired? > > > > > > > > How do you know, apriori, that the OSPF instance is > > > > restarting and not completely dead? > > > > > > Why do you care? As long as the topology isn't changing > > > then everything is ok. > > > > > > Wwhy not minimize the effects of unnecessary SPF computations? > > > > > > > > > > > > > > > > > This would also take care of unscheduled restarts > > > > > and allow you to do an unscheduled graceful > > > > > restart!!!! > > > > > > > > > > You could also send them as DNA LSAs.. See inline. > > > > > > > > > > The only new twist is that if you then schedule > > > > > a restart, you may want to be able to cancel your > > > > > previous request or update the LSAs over time. > > > > > But if you conisder a stable topology, then why > > > > > NOT?? > > > > > > > > > > > > > > > 2) A) 2.1 3rd, paragraph.. > > > > > "Their age field set to 0," > > > > > Why can't you send DNA grace-LSAs???? > > > > > > > > You wouldn't gain anything since the grace interval cannot > > > > exceed the LSA refresh time. > > > > > > > > > > So, first why do you need to specify the grace-LSA > > > timeframe. Let it be implicitly known to be 1 hr! > > > > > > With DNA grace-LSAs, we > > > don't need to reflood them. If I sent them out > > > at adj creation time and the topology isn't > > > changing, then I don't need to consume > > > resources and keep on re-flooding them.. > > > > > > Thus, they can last multiple hours or longer.. > > > > > > > > > > > > > B) 2.1, 4th paragraph. > > > > > > > > > > "it should retransmit... until > > > > > they are acknowledged". If you can't retransmit the > > > > > same LSA until 5 secs have passed, if a router > > > > > was congested, you may want to resubmit the grace-LSA > > > > > with a longer length timeframe to your helpers. I am > > > > > assuming just bump your instance. Correct? > > > > > > > > There are implementations that back off LSA retransmissions and the > > > > "Prioritized Treatment of Specific OSPF Packets and Congestion > > > > Avoidance" draft recommends this. However, this is not standard > > > > OSPF flooding as described in RFC2328 and it is an independent > > > > issue. > > > > > > > > > > No, no, you are missing my point. Until all of your grace-LSAs are > > > ack'ed, you can't continue successfully with a graceful-restart. > > > > > > This delay consumes time that you specified in your grace-LSA. Yea, > > > again, I don't know why you need to specify the amount of time!! > > > The timeframe that the helpers will help you can be set independently > > > and your spec doesn't allow them to communicate the amount of time > > > that they will keeep around a grace-LSA. > > > > > > Sorry, minor sidetrack. So, the time consumed to get the ack, actually > > > reduces the amount of time before the grace-LSA expires. > > > > > > > > > > > > > > > > > > > > Mitchell > > > > > ================ > > > > > Acee Lindem wrote: > > > > > > > > > >>Mitchell, > > > > >> > > > > >>See answers below. > > > > >> > > > > >>Erblichs wrote: > > > > >> > > > > >>>Group, > > > > >>> > > > > >>> 1) Within 2.1 "Entering graceful restart", iff all > > > > >>> the LSAs were from DC specified NBRs with DNA > > > > >>> LSAs should the LS RefreshTime still be followed? > > > > >> > > > > >>LSA Refresh isn't relevant since the restarting router will > > > > >>reestablish adjacencies. > > > > > > > > > > > > > > > Then why have a suggestion of 1800 secs for LSReshTime > > > > > in your draft at the end of the 1st paragraph in section > > > > > 2.1? > > > > > > > > > > In my scenario, there would be no reason not to let the > > > > > value approach or exceed 3600 secs (1 hr). > > > > > > > > > > variation on a theme? Why not let the max value of your > > > > > grace-LSA length field allow the helper determine what > > > > > is the max that he will support? > > > > > -- what happens if you specify a value that is > > > > > greater than what the helper supports? > > > > > Ans A: The helper sees it as an invalid request > > > > > and throws away the whole request, > > > > > > > > > > OR > > > > > Ans B: The helper determines what the length he > > > > > will support? > > > > > > > > > > If it is B, then why have the length field. Just let > > > > > the helper decide how long to support the request? > > > > > > > > > > > > > > >>> 2) Within 2.2 "When to exit graceful restart", number > > > > >>> (3) "The grace period expires". > > > > >>> > > > > >>> What happens if we follow #3 and your #1 "reestablished > > > > >>> all its adjacencies" criteria is not met? > > > > >> > > > > >>The restarting router will exit graceful restart anyway. > > > > > > > > > > > > > > > Why? If you still have a non-changing topology, why > > > > > limit the value to what you had said to the helpers? > > > > > > > > > > So, what if you asked for x time and it took you > > > > > x + y time? > > > > > > > > > > > > > > >>> Or are you stating that the specified "grace period" was > > > > >>> to short to perform what was required? > > > > >> > > > > >>Not necessarily - perhaps the topology has changed and graceful restart > > > > >>cannot be completed successfully. > > > > >> > > > > >> > > > > >>> 3) Within 2.2. Would seeing a hello without the graceful > > > > >>> restarting router id", force it to exit? > > > > >> > > > > >>No. The adjacency can go all the way down on the helper router. The hello > > > > >>shouldn't be used as a criteria for exiting helper mode. Do not confuse > > > > >>this with other graceful restart proposals. > > > > >> > > > > > > > > > > > > > > > I see that my question with the hello was answered in the > > > > > 2. (3) "an hello packet is received".. > > > > > > > > > > I am confused. One router may list you as the DR and another > > > > > may not? If one is a helper, then why would it take the adj > > > > > down if all the crieria were met? > > > > > > > > > > I thought that helpers > > > > > MUST send hellos as if you (graceful restarting router) were > > > > > still there!! > > > > > "an Hello packet is received from a neighbor listing the > > > > > router as the Designated Router". > > > > > > > > > > If it did keep anouncing you in the hellos (you weren't > > > > > the DR) and lets say that the DR went down. Could you > > > > > then be elected as the DR while you were still rebooting? > > > > > > > > > > > > > > >>> 4) Within 2.2. Would seeing a hello without the graceful > > > > >>> restarting router id as the earlier DR or BDR, cause > > > > >>> it to exit, if it was a DR / BDR? > > > > >> > > > > >>Not directly, but an inconsistency with the pre-restart LSA will cause > > > > >>the restarting router to exist graceful restart prematurely. > > > > >> > > > > >> > > > > >>> 5) Within 2.2. Is it implimentation dependent on how we > > > > >>> determine our existing nbrs and place their router ids > > > > >>> in a hello? > > > > >> > > > > >>This isn't changed for graceful restart. > > > > > > > > > > > > > > > I thought that you could save past nbr-ids in NVRAM > > > > > and then compare to existing hellos... > > > > > > > > > >>> 6) Within 2.2 (1), isn't adj establishment partly the > > > > >>> recieving of hellos, with your own router-id? Shouldn't > > > > >>> that inform others that we are back and to cancel > > > > >>> their helper graceful nbr timer? > > > > >>> > > > > >>> 7 & 8) Within 2.3 "Actions on exiting graceful restart". > > > > >>> > > > > >>> 7) Shouldn't the sending hellos be performed that > > > > >>> identify full adj be a criteria here? > > > > >> > > > > >>No. LSA convergence with the pre-restart LSAs is a much surer > > > > >>mechanism for determining the graceful restart can be exited. > > > > >> > > > > >> > > > > >>> > > > > >>> 8) I am unsure whether you are specifying the > > > > >>> storage of part of restarting router's LSDB into > > > > >>> non-volatile memory. If so, then upon retrieval, > > > > >>> shouldn't some elements of the LSDB be aged > > > > >>> by the amount that the actual amount of time > > > > >>> the LSAs were in NV memory? > > > > >> > > > > >>There is no mention of storing LSAs in non-volatile storage. > > > > >> > > > > > > > > > > > > > > > Ok, you aren't suggesting saving the LSDB in NVRAM > > > > > or some other type of storage media.. > > > > > > > > > >>> > > > > >>> > > > > >>> Mitchell Erblich > > > > >>> ================================== > > > > >>> > > > > >> > > > > >>-- > > > > >>Acee > > > > > > > > > > > > > > > > > > -- > > > > Acee > > > > From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 9 02:06:52 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26673 for ; Wed, 9 Apr 2003 02:06:52 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.0096CFC7@cherry.ease.lsoft.com>; Wed, 9 Apr 2003 2:09:23 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 731122 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 9 Apr 2003 02:09:22 -0400 Received: from 203.199.83.25 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 9 Apr 2003 02:09:22 -0500 Received: (qmail 29938 invoked by uid 510); 9 Apr 2003 06:07:25 -0000 Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 09 apr 2003 06:07:25 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20030409060725.29937.qmail@webmail15.rediffmail.com> Date: Wed, 9 Apr 2003 06:07:25 -0000 Reply-To: Mailing List Sender: Mailing List From: Krishna Rao Subject: RFC 1583 - TOS support To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, Suppose an LSA (for example AS Ext LSA) has TOS_0 metric advertised as LS_INFINITY while TOS_1 metric is valid( say 20). Should this LSA be considered for As Ext Route calculation ?? Probably not, since TOS_0 path is unreachable, does it make sense to calculates paths for other TOS's ??? thanks, Krishna _______________________________________________________________________ Odomos - the only mosquito protection outside 4 walls - Click here to know more! http://r.rediff.com/r?http://clients.rediff.com/odomos/Odomos.htm&&odomos&&wn From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 9 10:11:35 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29361 for ; Wed, 9 Apr 2003 10:11:35 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.0096DAC5@cherry.ease.lsoft.com>; Wed, 9 Apr 2003 10:14:07 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 732532 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 9 Apr 2003 10:14:07 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 9 Apr 2003 10:14:06 -0500 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 7256772AEC6 for ; Wed, 9 Apr 2003 07:13:51 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030409060725.29937.qmail@webmail15.rediffmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E942A60.4040804@redback.com> Date: Wed, 9 Apr 2003 10:12:48 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: RFC 1583 - TOS support To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Krisha, You should be looking at RFC 2328. TOS support has been deprecated. Krishna Rao wrote: > Hi, > Suppose an LSA (for example AS Ext LSA) has TOS_0 metric > advertised as LS_INFINITY while TOS_1 metric is valid( say 20). > > Should this LSA be considered for As Ext Route calculation ?? > > Probably not, since TOS_0 path is unreachable, does it > make sense to calculates paths for other TOS's ??? > > thanks, > Krishna > _______________________________________________________________________ > Odomos - the only mosquito protection outside 4 walls - > Click here to know more! > http://r.rediff.com/r?http://clients.rediff.com/odomos/Odomos.htm&&odomos&&wn > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 9 12:02:29 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04110 for ; Wed, 9 Apr 2003 12:02:28 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.0096DDD4@cherry.ease.lsoft.com>; Wed, 9 Apr 2003 12:05:00 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 732810 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 9 Apr 2003 12:05:00 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 9 Apr 2003 12:05:00 -0500 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 100AA3D8C0 for ; Wed, 9 Apr 2003 09:04:59 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E94446B.9080800@redback.com> Date: Wed, 9 Apr 2003 12:03:55 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPFv3: Multiple Router-LSA (and intra-area-prefix LSA) questions To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Mike, A few guidelines: 1. You only advertise a given link in a single router LSA. 2. If you want to withdraw or change the cost of that link, you should re-originate the LSA that contains it. If there are no more links in the LSA, you can purge it (of course, if you don't have any more links in the area it really doesn't matter anyway). 3. An implementation will probably treat the link as "sticky". However, there is no hard and fast rule. After a lot of changes, you could rebalance your links as long as you re-originate or purge all your changed router LSAs for the area. The same guidelines can be applied to prefixes in OSPFv3 LSAs that support multiples. Mike Fox wrote: > I've skimmed the archives all the way back and I don't think I've seen this > addressed, but other implementations must have answered this question for > themselves. > > What is the definitive way to remove a link from a Router LSA? This could be > necessary because either the link has been deleted from the router, or the > link no longer meets the requirement for being included in the router LSA > (for example, the router lost all its adjacencies over the link). In > OSPFv2, it's done by sending a new router advertisement without the link. > Now with multiple router advertisements, it can get tricky. That > observation drives the following question: > > Are link memberships in router LSAs "sticky"? It seems to me that this is > almost necessary to have decent convergence on removed links. > > For example, assume RT1 originates three router LSA's into an area, as follows: > > Link state id: 1 > Advertising Router: RT1 > links: link1, link2 > > Link state id: 2 > Advertising Router: RT1 > links: link3, link4 > > Link state id: 3 > Advertising router: RT1 > links: link5 > > Now if, RT1 later sends the following Router LSA: > > Link State id: 2 > Advertising Router: RT1 > links: link4 > > Is this enough to cause other routers to realize that link3 has been removed > from router1? Or is it necessary for them to verify that link3 has not > moved to the router LSA with link state id 1 or 3, or even a new one with > link state id 4? If links are not "sticky", then how long should a > receiving router wait to make sure it doesn't receive new copies of another > LSA containing that link before it can decide that link is deleted from RT1? > > Also, if links are not "sticky", consider the original case above but now > link5 has been deleted. How can RT1 communicate that fact? If links are > sticky he can just flush the router LSA with link state id 3. If they > aren't, that would not be sufficient because other routers would have to > verify that link5 hasn't moved to another link state id, meaning waiting an > interval to make sure a new router LSA with link5 in it does not arrive from > RT1. > > In either case, if the links are not sticky to their specific router LSA > instances, what's necessary starts to look suspiciously like recreating > TCP's fragmentation/reassembly logic in the routing process. > > Btw, the same question can be asked about intra-area-prefix LSAs. Are > prefixes sticky to particular intra-area-prefix LSA instances (link state > IDs)? Virtually the same problems and questions arise about them. > > Mike > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 9 12:42:12 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05581 for ; Wed, 9 Apr 2003 12: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 <6.0096DE34@cherry.ease.lsoft.com>; Wed, 9 Apr 2003 12:44:45 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 732925 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 9 Apr 2003 12:44:45 -0400 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 9 Apr 2003 12:44:45 -0500 Received: (qmail 14665 invoked from network); 9 Apr 2003 16:44:44 -0000 Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 9 Apr 2003 16:44:44 -0000 Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id MAA30679; Wed, 9 Apr 2003 12:44:43 -0400 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200304091644.MAA30679@bigbird.xebeo.com> Date: Wed, 9 Apr 2003 12:44:43 -0400 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Notice of WG last call on Diff Serv TE Protocol draft in TEWG (fwd) Comments: cc: jboyle@pdnets.com, zinin@psg.com, fenner@research.att.com To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Forwarding Jim's email since it didn't make it to the ospf list on its own. --rohit. ------- Forwarded Message Date: Mon, 7 Apr 2003 23:52:46 -0400 (EDT) From: Jim Boyle To: mpls@UU.NET, , , cc: te-wg@ops.ietf.org Subject: Notice of WG last call on Diff Serv TE Protocol draft in TEWG In May 2001 the TEWG adopted the development of the requirements and necessary protocol extensions for Diff-Serv TE. Upon completion, TEWG was to notify the various protocol WGs of the proposal to allow review of the proposed protocol changes (if any). This note serves that purpose. Please find the pointer for the protocol specification draft below and review the proposed changes required in the routing and signaling protocols. A WG last call on the protocol draft will start by separate email to the TEWG. Be sure to follow-up with any discussion to the te-wg list. http://www.ietf.org/internet-drafts/draft-ietf-tewg-diff-te-proto-03.txt It specifies extensions outlined as follows: - IGP Reuse of unreserved bandwidth sub-tlv to carry BW available per TE-Class - IGP Optional use bandwidth constraints sub-tlv - IGP Optional use local overbooking multiplier sub-tlv - RSVP Class Type Object for signaling class-types other than 0. - RSVP Diffserv TE error codes The protocol supports the use of a variety of different bandwidth constraint models. The following drafts are examples listed here for reference only. http://www.ietf.org/internet-drafts/draft-ietf-tewg-diff-te-russian-02.txt http://www.ietf.org/internet-drafts/draft-lefaucheur-diff-te-mam-00.txt http://www.ietf.org/internet-drafts/draft-ash-mpls-dste-bcmodel-max-alloc-resv- 01.txt Also for reference, the requirements are developed and with RFC-ED now. http://www.ietf.org/internet-drafts/draft-ietf-tewg-diff-te-reqts-07.txt ------- End of Forwarded Message From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 9 15:12:29 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10698 for ; Wed, 9 Apr 2003 15:12:28 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.0096E384@cherry.ease.lsoft.com>; Wed, 9 Apr 2003 15:14:58 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 733517 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 9 Apr 2003 15:14:58 -0400 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 9 Apr 2003 15:14:58 -0500 Received: (qmail 21490 invoked from network); 9 Apr 2003 19:14:58 -0000 Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 9 Apr 2003 19:14:58 -0000 Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id PAA31115 for ; Wed, 9 Apr 2003 15:14:57 -0400 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200304091914.PAA31115@bigbird.xebeo.com> Date: Wed, 9 Apr 2003 15:14:57 -0400 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Re: OSPF Charter Addition of draft-rosen-ospf-2547bis-dn-00.txt To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Message from Acee Lindem of "Tue, 08 Apr 2003 14:19:19 EDT." <3E9312A7.1000906@redback.com> Precedence: list [Speaking as WG member] I agree that we should go ahead with this as a charter item. --rohit. On Tue, 8 Apr 2003 14:19:19 -0400 Acee Lindem writes: =>[Speaking as WG Co-chair] => =>This draft proposes a mechanism for preventing leaking =>VPN routes from a CE site connected to multiple PEs. It makes =>use of an LSA option bit and is a generalization of a mechanism for =>area 0 VPN connection proposed in a previous PPVPN WG draft =>(draft-rosen-vpns-ospf-bgp-mpls-04.txt). => =>At the last WG meeting, we discussed adding this work to the OSPF WG =>charter. There was mild support and no opposition. => =>[Speaking as WG member] => =>I propose we add this to the OSPF WG charter for the following reasons: => => 1. The use of the LSA option bit has been already been implemented => by at least two vendors (and probably others). We need to standardize => the usage of this LSA bit since it is becoming a de facto standard. => => 2. There was no opposition and mild support at the SF IETF meeting. => => 3. The generalization of the LSA bit was specifically requested => by OSPF WG (actually myself) when the previous draft was reviewed. => =>[Speaking as WG Co-Chair] => =>Does anyone feel that this work should not be added to the =>OSPF WG charter? Are there any questions that need to be answered? => =>Thanks, =>-- =>Acee ___ From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 10 01:49:02 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27076 for ; Thu, 10 Apr 2003 01:49:01 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0096F638@cherry.ease.lsoft.com>; Thu, 10 Apr 2003 1:51:34 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 735085 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 10 Apr 2003 01:51:34 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 10 Apr 2003 01:51:33 -0500 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 36A22916019 for ; Wed, 9 Apr 2003 22:51:31 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <200304082356.h38NunH88489@garnet.juniper.net> <3E93755E.1937BC89@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E95061B.5060200@redback.com> Date: Thu, 10 Apr 2003 01:50:19 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Draft : Graceful Restart : : grace period, etc To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Erblichs wrote: > Padma, > > > These are my last comments!! > > Also inline... > > Why doesn't the draft RFC authors want to > allow non-scheduled restarts in this > draft? Michell, As Padma stated, the draft supports unscheduled restarts (there are multiple interoperable implementations). Your proposal to announce graceful restart in advance will unnecessarily delay the detection of a black hole if the restarting router is really dead or was abruptly decommissioned. The current draft doesn't suffer from this flaw. > > Is there something wrong with the idea > of un-scheduled restarts? > > Why restrict it to only scheduled > restarts??? > > Why require > the grace-LSAs to be reflooded every > 30 minutes to 1 hr??? > > Why not send the grace-LSAs without > the Type=1, Length=4 grace period field?? > It will be determined by the helpers > anyway. > > The sentance is. > > "The number of seconds that the router's > neighbors should continue to advertise the > router as fully adjacent".... > > Thus, without the word "MUST", implimentations > will probably follow their own rules. Thus, the > grace period field really isn't needed and just > consumes bandwidth!!! > > > > Mitchell Erblich > =================== > > > > > > Padma Pillay-Esnault wrote: > >>Mitchell, >> >>I'll try to address your comments >> >> >>>Acee Lindem, >>> >>> Since,, you skipped the inline re-comments, I will assume >>> that at least you read them.. :) >>> >>> I think I have expressed as best as I could (I am not >>> a tech writer) how I feel that this draft should evolve. >>> >>> So in summary... >>> >>>` 0) Remove the length (seconds) field from the grace-LSA. >>> >> >>This is using the TLV format .. so you want to keep the length > > > Of course, Type, Length, Value... Fine. Reword.. > Remove > the Grace-Period field of (Type =1, Length = 4). > Why transmit the field value????? > >>> 1) Transmit DNA grace-LSAs at adj creation time. >>> >> >>This is not very useful. Today unless you have DNA lsa you cannot >>expect to be requesting a grace period of over one hour -- as >>all the LSA in the other routers database will expire at the >>most in 1hr. >>So if you decide to send a grace LSA it would be the most recent one >>that you built and hence if it has time to expire then the previous >>would already be gone. > > > Think ahead of tomarrow, not today... > How should this work in the utopian word? If the graceful > restart is a good idea, then it NOT should be used for ALL > possible restarts?? > > Why not restrict the amount of flooding with THESE types > of LSAs if this draft becomes a standard RFC?? > > What happens if I send the grace-LSAs at adj formation > time and then reflood them every 55 minutes?? This > removes the lightweight mechanism of the draft, but > still gets me unscheduled restart functionality? Maybe > i will just do that.. BTW, and also do unscheduled > restarts with my BGP protocol once it becomes a > standard. > > Thus, a restriction of 1 hr isn't sensible. Else, even if > I follow your logic, then why do I ask for 1 hr? Should > my implimentation in the helper not ack the grace-LSA if > the specified grace-period is over 1 hr from the restarting > router? This is unspecified behavior!!! > > > >>> 2) Let the helpers determine amount of time that >>> they will function as a helper. Suggest a minimum >>> of 1 hr time. >>> >> >>This is a matter of policy .. even if the helper decides that >>he is not going to help for the whole period .. as he is not >>going to signal it to the restarting router .. I do not see >>the use of doing so. >> >> >>> 3) Reflood the DNA grace-LSAs anytime the contents >>> have changed. >>> >> >>See my response in 1. >> >> >>> 4) If the restart router expects to be down for a period >>> longer than X, then retransmit the Grace-LSAs as >>> MAXage LSAs. >>> >> >>I do not see the benefit or I am missing your point >> >>Padma >> >> >>> This would minimize bandwidth requirements and allow a >>> restarting router to have either scheduled or unscheduled >>> restarts. >>> >>> I don't know what else to add, except if you adopt one or >>> more of these suggestions, then please add my name to your >>> comment list. :) >>> >>> Mitchell Erblich >>> Sr Software Engineer >>> ============================ >>> >>> >>>Acee Lindem wrote: >>> >>>>Erblichs wrote: >>>> >>>>>Acee Lindem, >>>>> >>>>> Sometimes my logic is a little obtuse.. >>>>> >>>>> Most of it is inline... >>>>> >>>>> I will first throw two new questions to you!!!! >>>>> >>>>> 1) Why don't you send out the Grace LSA at full >>>>> adj timeframe. It would take effect after >>>>> RouterDeadinterval has expired? >>>> >>>>How do you know, apriori, that the OSPF instance is >>>>restarting and not completely dead? >>> >>> Why do you care? As long as the topology isn't changing >>> then everything is ok. >>> >>> Wwhy not minimize the effects of unnecessary SPF computations? >>> >>> >>>>> This would also take care of unscheduled restarts >>>>> and allow you to do an unscheduled graceful >>>>> restart!!!! >>>>> >>>>> You could also send them as DNA LSAs.. See inline. >>>>> >>>>> The only new twist is that if you then schedule >>>>> a restart, you may want to be able to cancel your >>>>> previous request or update the LSAs over time. >>>>> But if you conisder a stable topology, then why >>>>> NOT?? >>>>> >>>>> >>>>> 2) A) 2.1 3rd, paragraph.. >>>>> "Their age field set to 0," >>>>> Why can't you send DNA grace-LSAs???? >>>> >>>>You wouldn't gain anything since the grace interval cannot >>>>exceed the LSA refresh time. >>>> >>> >>> So, first why do you need to specify the grace-LSA >>> timeframe. Let it be implicitly known to be 1 hr! >>> >>> With DNA grace-LSAs, we >>> don't need to reflood them. If I sent them out >>> at adj creation time and the topology isn't >>> changing, then I don't need to consume >>> resources and keep on re-flooding them.. >>> >>> Thus, they can last multiple hours or longer.. >>> >>> >>>>> B) 2.1, 4th paragraph. >>>>> >>>>> "it should retransmit... until >>>>> they are acknowledged". If you can't retransmit the >>>>> same LSA until 5 secs have passed, if a router >>>>> was congested, you may want to resubmit the grace-LSA >>>>> with a longer length timeframe to your helpers. I am >>>>> assuming just bump your instance. Correct? >>>> >>>>There are implementations that back off LSA retransmissions and the >>>>"Prioritized Treatment of Specific OSPF Packets and Congestion >>>>Avoidance" draft recommends this. However, this is not standard >>>>OSPF flooding as described in RFC2328 and it is an independent >>>>issue. >>>> >>> >>> No, no, you are missing my point. Until all of your grace-LSAs are >>> ack'ed, you can't continue successfully with a graceful-restart. >>> >>> This delay consumes time that you specified in your grace-LSA. Yea, >>> again, I don't know why you need to specify the amount of time!! >>> The timeframe that the helpers will help you can be set independently >>> and your spec doesn't allow them to communicate the amount of time >>> that they will keeep around a grace-LSA. >>> >>> Sorry, minor sidetrack. So, the time consumed to get the ack, actually >>> reduces the amount of time before the grace-LSA expires. >>> >>>>> >>>>> >>>>> Mitchell >>>>> ================ >>>>>Acee Lindem wrote: >>>>> >>>>> >>>>>>Mitchell, >>>>>> >>>>>>See answers below. >>>>>> >>>>>>Erblichs wrote: >>>>>> >>>>>> >>>>>>>Group, >>>>>>> >>>>>>> 1) Within 2.1 "Entering graceful restart", iff all >>>>>>> the LSAs were from DC specified NBRs with DNA >>>>>>> LSAs should the LS RefreshTime still be followed? >>>>>> >>>>>>LSA Refresh isn't relevant since the restarting router will >>>>>>reestablish adjacencies. >>>>> >>>>> >>>>> Then why have a suggestion of 1800 secs for LSReshTime >>>>> in your draft at the end of the 1st paragraph in section >>>>> 2.1? >>>>> >>>>> In my scenario, there would be no reason not to let the >>>>> value approach or exceed 3600 secs (1 hr). >>>>> >>>>> variation on a theme? Why not let the max value of your >>>>> grace-LSA length field allow the helper determine what >>>>> is the max that he will support? >>>>> -- what happens if you specify a value that is >>>>> greater than what the helper supports? >>>>> Ans A: The helper sees it as an invalid request >>>>> and throws away the whole request, >>>>> >>>>> OR >>>>> Ans B: The helper determines what the length he >>>>> will support? >>>>> >>>>> If it is B, then why have the length field. Just let >>>>> the helper decide how long to support the request? >>>>> >>>>> >>>>> >>>>>>> 2) Within 2.2 "When to exit graceful restart", number >>>>>>> (3) "The grace period expires". >>>>>>> >>>>>>> What happens if we follow #3 and your #1 "reestablished >>>>>>> all its adjacencies" criteria is not met? >>>>>> >>>>>>The restarting router will exit graceful restart anyway. >>>>> >>>>> >>>>> Why? If you still have a non-changing topology, why >>>>> limit the value to what you had said to the helpers? >>>>> >>>>> So, what if you asked for x time and it took you >>>>> x + y time? >>>>> >>>>> >>>>> >>>>>>> Or are you stating that the specified "grace period" was >>>>>>> to short to perform what was required? >>>>>> >>>>>>Not necessarily - perhaps the topology has changed and graceful restart >>>>>>cannot be completed successfully. >>>>>> >>>>>> >>>>>> >>>>>>> 3) Within 2.2. Would seeing a hello without the graceful >>>>>>> restarting router id", force it to exit? >>>>>> >>>>>>No. The adjacency can go all the way down on the helper router. The hello >>>>>>shouldn't be used as a criteria for exiting helper mode. Do not confuse >>>>>>this with other graceful restart proposals. >>>>>> >>>>> >>>>> >>>>> I see that my question with the hello was answered in the >>>>> 2. (3) "an hello packet is received".. >>>>> >>>>> I am confused. One router may list you as the DR and another >>>>> may not? If one is a helper, then why would it take the adj >>>>> down if all the crieria were met? >>>>> >>>>> I thought that helpers >>>>> MUST send hellos as if you (graceful restarting router) were >>>>> still there!! >>>>> "an Hello packet is received from a neighbor listing the >>>>> router as the Designated Router". >>>>> >>>>> If it did keep anouncing you in the hellos (you weren't >>>>> the DR) and lets say that the DR went down. Could you >>>>> then be elected as the DR while you were still rebooting? >>>>> >>>>> >>>>> >>>>>>> 4) Within 2.2. Would seeing a hello without the graceful >>>>>>> restarting router id as the earlier DR or BDR, cause >>>>>>> it to exit, if it was a DR / BDR? >>>>>> >>>>>>Not directly, but an inconsistency with the pre-restart LSA will cause >>>>>>the restarting router to exist graceful restart prematurely. >>>>>> >>>>>> >>>>>> >>>>>>> 5) Within 2.2. Is it implimentation dependent on how we >>>>>>> determine our existing nbrs and place their router ids >>>>>>> in a hello? >>>>>> >>>>>>This isn't changed for graceful restart. >>>>> >>>>> >>>>> I thought that you could save past nbr-ids in NVRAM >>>>> and then compare to existing hellos... >>>>> >>>>> >>>>>>> 6) Within 2.2 (1), isn't adj establishment partly the >>>>>>> recieving of hellos, with your own router-id? Shouldn't >>>>>>> that inform others that we are back and to cancel >>>>>>> their helper graceful nbr timer? >>>>>>> >>>>>>> 7 & 8) Within 2.3 "Actions on exiting graceful restart". >>>>>>> >>>>>>> 7) Shouldn't the sending hellos be performed that >>>>>>> identify full adj be a criteria here? >>>>>> >>>>>>No. LSA convergence with the pre-restart LSAs is a much surer >>>>>>mechanism for determining the graceful restart can be exited. >>>>>> >>>>>> >>>>>> >>>>>>> 8) I am unsure whether you are specifying the >>>>>>> storage of part of restarting router's LSDB into >>>>>>> non-volatile memory. If so, then upon retrieval, >>>>>>> shouldn't some elements of the LSDB be aged >>>>>>> by the amount that the actual amount of time >>>>>>> the LSAs were in NV memory? >>>>>> >>>>>>There is no mention of storing LSAs in non-volatile storage. >>>>>> >>>>> >>>>> >>>>> Ok, you aren't suggesting saving the LSDB in NVRAM >>>>> or some other type of storage media.. >>>>> >>>>> >>>>>>> >>>>>>> Mitchell Erblich >>>>>>> ================================== >>>>>>> >>>>>> >>>>>>-- >>>>>>Acee >>>>> >>>>> >>>>-- >>>>Acee >>> > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 10 14:39:22 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00186 for ; Thu, 10 Apr 2003 14:39:22 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00970556@cherry.ease.lsoft.com>; Thu, 10 Apr 2003 14:41:55 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 737202 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 10 Apr 2003 14:41:55 -0400 Received: from 207.217.120.22 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 10 Apr 2003 14:41:55 -0500 Received: from user-v8ldv5t.dsl.mindspring.com ([209.86.252.189] helo=earthlink.net) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 193gze-0005qS-00 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 10 Apr 2003 11:41:51 -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: <200304082356.h38NunH88489@garnet.juniper.net> <3E93755E.1937BC89@earthlink.net> <3E95061B.5060200@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E95BACC.E53FDC89@earthlink.net> Date: Thu, 10 Apr 2003 11:41:16 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Draft : Graceful Restart : : grace period, etc To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Acee, et al, I didn't really want to continue this thread but I feel, I should restate some items here. :) > As Padma stated, the draft supports unscheduled restarts (there > are multiple interoperable implementations). Your proposal to > announce graceful restart in advance I don't see how one can send out grace-LSAs and possibly be able to retransmit a grace-LSA OTHER than in advance, AND still support unscheduled graceful restarts!!! You must do it in advance, else it is scheduled.. My definition of unscheduled is that some event occurs and the non-forwarding portion of the router is DOWN... No, time for an sys admin to do anything... The ONLY possible way is to have trap level code call the xmit grace-LSA code section. However, no time to see if acks have been rec'vd and no time for a 5 sec rexmit.... Ok, then WHAT is an UNSCHEDULED GRACEFUL RESTART in your guys opinion???? On the assumption that if the router fails and still abides by the condition that it is still forwarding as if it was still up.., then As long as there isn't any topologoy changes as stated within your document, that is one reason to allow for a graceful restart, I don't see the blackhole.. If the topology changes then it would invalidate my graceful restart, as it would also invalidate the graceful restart specified in the draft. The only deltas that I was asking for was: - the issue of sending out a minimal grace-LSA at adj timeframe, - being able to minimally update our grace-LSA as topology changes, - or we decide that we want to withdraw our grace-LSA via MAXAGE, As of this time, I have not read in your document, EXPLICITLY whether - you suggest to ONLY send out the grace-LSA when you have planned to do a restart (scheduled), - how to withdraw the grace-LSAs from accepted helpers when one proto-helper (to be helper), will not ack your LSA, - etc.. Mitchell Erblich Sr Software Engineer ============================ Acee Lindem wrote: > > Erblichs wrote: > > Padma, > > > > > > These are my last comments!! > > > > Also inline... > > > > Why doesn't the draft RFC authors want to > > allow non-scheduled restarts in this > > draft? > > Michell, > > As Padma stated, the draft supports unscheduled restarts (there > are multiple interoperable implementations). Your proposal to > announce graceful restart in advance will unnecessarily delay > the detection of a black hole if the restarting router is really dead > or was abruptly decommissioned. The current draft doesn't suffer > from this flaw. > > > > > Is there something wrong with the idea > > of un-scheduled restarts? > > > > Why restrict it to only scheduled > > restarts??? > > > > Why require > > the grace-LSAs to be reflooded every > > 30 minutes to 1 hr??? > > > > Why not send the grace-LSAs without > > the Type=1, Length=4 grace period field?? > > It will be determined by the helpers > > anyway. > > > > The sentance is. > > > > "The number of seconds that the router's > > neighbors should continue to advertise the > > router as fully adjacent".... > > > > Thus, without the word "MUST", implimentations > > will probably follow their own rules. Thus, the > > grace period field really isn't needed and just > > consumes bandwidth!!! > > > > > > > > Mitchell Erblich > > =================== > > > > > > > > > > > > Padma Pillay-Esnault wrote: > > > >>Mitchell, > >> > >>I'll try to address your comments > >> > >> > >>>Acee Lindem, > >>> > >>> Since,, you skipped the inline re-comments, I will assume > >>> that at least you read them.. :) > >>> > >>> I think I have expressed as best as I could (I am not > >>> a tech writer) how I feel that this draft should evolve. > >>> > >>> So in summary... > >>> > >>>` 0) Remove the length (seconds) field from the grace-LSA. > >>> > >> > >>This is using the TLV format .. so you want to keep the length > > > > > > Of course, Type, Length, Value... Fine. Reword.. > > Remove > > the Grace-Period field of (Type =1, Length = 4). > > Why transmit the field value????? > > > >>> 1) Transmit DNA grace-LSAs at adj creation time. > >>> > >> > >>This is not very useful. Today unless you have DNA lsa you cannot > >>expect to be requesting a grace period of over one hour -- as > >>all the LSA in the other routers database will expire at the > >>most in 1hr. > >>So if you decide to send a grace LSA it would be the most recent one > >>that you built and hence if it has time to expire then the previous > >>would already be gone. > > > > > > Think ahead of tomarrow, not today... > > How should this work in the utopian word? If the graceful > > restart is a good idea, then it NOT should be used for ALL > > possible restarts?? > > > > Why not restrict the amount of flooding with THESE types > > of LSAs if this draft becomes a standard RFC?? > > > > What happens if I send the grace-LSAs at adj formation > > time and then reflood them every 55 minutes?? This > > removes the lightweight mechanism of the draft, but > > still gets me unscheduled restart functionality? Maybe > > i will just do that.. BTW, and also do unscheduled > > restarts with my BGP protocol once it becomes a > > standard. > > > > Thus, a restriction of 1 hr isn't sensible. Else, even if > > I follow your logic, then why do I ask for 1 hr? Should > > my implimentation in the helper not ack the grace-LSA if > > the specified grace-period is over 1 hr from the restarting > > router? This is unspecified behavior!!! > > > > > > > >>> 2) Let the helpers determine amount of time that > >>> they will function as a helper. Suggest a minimum > >>> of 1 hr time. > >>> > >> > >>This is a matter of policy .. even if the helper decides that > >>he is not going to help for the whole period .. as he is not > >>going to signal it to the restarting router .. I do not see > >>the use of doing so. > >> > >> > >>> 3) Reflood the DNA grace-LSAs anytime the contents > >>> have changed. > >>> > >> > >>See my response in 1. > >> > >> > >>> 4) If the restart router expects to be down for a period > >>> longer than X, then retransmit the Grace-LSAs as > >>> MAXage LSAs. > >>> > >> > >>I do not see the benefit or I am missing your point > >> > >>Padma > >> > >> > >>> This would minimize bandwidth requirements and allow a > >>> restarting router to have either scheduled or unscheduled > >>> restarts. > >>> > >>> I don't know what else to add, except if you adopt one or > >>> more of these suggestions, then please add my name to your > >>> comment list. :) > >>> > >>> Mitchell Erblich > >>> Sr Software Engineer > >>> ============================ > >>> > >>> > >>>Acee Lindem wrote: > >>> > >>>>Erblichs wrote: > >>>> > >>>>>Acee Lindem, > >>>>> > >>>>> Sometimes my logic is a little obtuse.. > >>>>> > >>>>> Most of it is inline... > >>>>> > >>>>> I will first throw two new questions to you!!!! > >>>>> > >>>>> 1) Why don't you send out the Grace LSA at full > >>>>> adj timeframe. It would take effect after > >>>>> RouterDeadinterval has expired? > >>>> > >>>>How do you know, apriori, that the OSPF instance is > >>>>restarting and not completely dead? > >>> > >>> Why do you care? As long as the topology isn't changing > >>> then everything is ok. > >>> > >>> Wwhy not minimize the effects of unnecessary SPF computations? > >>> > >>> > >>>>> This would also take care of unscheduled restarts > >>>>> and allow you to do an unscheduled graceful > >>>>> restart!!!! > >>>>> > >>>>> You could also send them as DNA LSAs.. See inline. > >>>>> > >>>>> The only new twist is that if you then schedule > >>>>> a restart, you may want to be able to cancel your > >>>>> previous request or update the LSAs over time. > >>>>> But if you conisder a stable topology, then why > >>>>> NOT?? > >>>>> > >>>>> > >>>>> 2) A) 2.1 3rd, paragraph.. > >>>>> "Their age field set to 0," > >>>>> Why can't you send DNA grace-LSAs???? > >>>> > >>>>You wouldn't gain anything since the grace interval cannot > >>>>exceed the LSA refresh time. > >>>> > >>> > >>> So, first why do you need to specify the grace-LSA > >>> timeframe. Let it be implicitly known to be 1 hr! > >>> > >>> With DNA grace-LSAs, we > >>> don't need to reflood them. If I sent them out > >>> at adj creation time and the topology isn't > >>> changing, then I don't need to consume > >>> resources and keep on re-flooding them.. > >>> > >>> Thus, they can last multiple hours or longer.. > >>> > >>> > >>>>> B) 2.1, 4th paragraph. > >>>>> > >>>>> "it should retransmit... until > >>>>> they are acknowledged". If you can't retransmit the > >>>>> same LSA until 5 secs have passed, if a router > >>>>> was congested, you may want to resubmit the grace-LSA > >>>>> with a longer length timeframe to your helpers. I am > >>>>> assuming just bump your instance. Correct? > >>>> > >>>>There are implementations that back off LSA retransmissions and the > >>>>"Prioritized Treatment of Specific OSPF Packets and Congestion > >>>>Avoidance" draft recommends this. However, this is not standard > >>>>OSPF flooding as described in RFC2328 and it is an independent > >>>>issue. > >>>> > >>> > >>> No, no, you are missing my point. Until all of your grace-LSAs are > >>> ack'ed, you can't continue successfully with a graceful-restart. > >>> > >>> This delay consumes time that you specified in your grace-LSA. Yea, > >>> again, I don't know why you need to specify the amount of time!! > >>> The timeframe that the helpers will help you can be set independently > >>> and your spec doesn't allow them to communicate the amount of time > >>> that they will keeep around a grace-LSA. > >>> > >>> Sorry, minor sidetrack. So, the time consumed to get the ack, actually > >>> reduces the amount of time before the grace-LSA expires. > >>> > >>>>> > >>>>> > >>>>> Mitchell > >>>>> ================ > >>>>>Acee Lindem wrote: > >>>>> > >>>>> > >>>>>>Mitchell, > >>>>>> > >>>>>>See answers below. > >>>>>> > >>>>>>Erblichs wrote: > >>>>>> > >>>>>> > >>>>>>>Group, > >>>>>>> > >>>>>>> 1) Within 2.1 "Entering graceful restart", iff all > >>>>>>> the LSAs were from DC specified NBRs with DNA > >>>>>>> LSAs should the LS RefreshTime still be followed? > >>>>>> > >>>>>>LSA Refresh isn't relevant since the restarting router will > >>>>>>reestablish adjacencies. > >>>>> > >>>>> > >>>>> Then why have a suggestion of 1800 secs for LSReshTime > >>>>> in your draft at the end of the 1st paragraph in section > >>>>> 2.1? > >>>>> > >>>>> In my scenario, there would be no reason not to let the > >>>>> value approach or exceed 3600 secs (1 hr). > >>>>> > >>>>> variation on a theme? Why not let the max value of your > >>>>> grace-LSA length field allow the helper determine what > >>>>> is the max that he will support? > >>>>> -- what happens if you specify a value that is > >>>>> greater than what the helper supports? > >>>>> Ans A: The helper sees it as an invalid request > >>>>> and throws away the whole request, > >>>>> > >>>>> OR > >>>>> Ans B: The helper determines what the length he > >>>>> will support? > >>>>> > >>>>> If it is B, then why have the length field. Just let > >>>>> the helper decide how long to support the request? > >>>>> > >>>>> > >>>>> > >>>>>>> 2) Within 2.2 "When to exit graceful restart", number > >>>>>>> (3) "The grace period expires". > >>>>>>> > >>>>>>> What happens if we follow #3 and your #1 "reestablished > >>>>>>> all its adjacencies" criteria is not met? > >>>>>> > >>>>>>The restarting router will exit graceful restart anyway. > >>>>> > >>>>> > >>>>> Why? If you still have a non-changing topology, why > >>>>> limit the value to what you had said to the helpers? > >>>>> > >>>>> So, what if you asked for x time and it took you > >>>>> x + y time? > >>>>> > >>>>> > >>>>> > >>>>>>> Or are you stating that the specified "grace period" was > >>>>>>> to short to perform what was required? > >>>>>> > >>>>>>Not necessarily - perhaps the topology has changed and graceful restart > >>>>>>cannot be completed successfully. > >>>>>> > >>>>>> > >>>>>> > >>>>>>> 3) Within 2.2. Would seeing a hello without the graceful > >>>>>>> restarting router id", force it to exit? > >>>>>> > >>>>>>No. The adjacency can go all the way down on the helper router. The hello > >>>>>>shouldn't be used as a criteria for exiting helper mode. Do not confuse > >>>>>>this with other graceful restart proposals. > >>>>>> > >>>>> > >>>>> > >>>>> I see that my question with the hello was answered in the > >>>>> 2. (3) "an hello packet is received".. > >>>>> > >>>>> I am confused. One router may list you as the DR and another > >>>>> may not? If one is a helper, then why would it take the adj > >>>>> down if all the crieria were met? > >>>>> > >>>>> I thought that helpers > >>>>> MUST send hellos as if you (graceful restarting router) were > >>>>> still there!! > >>>>> "an Hello packet is received from a neighbor listing the > >>>>> router as the Designated Router". > >>>>> > >>>>> If it did keep anouncing you in the hellos (you weren't > >>>>> the DR) and lets say that the DR went down. Could you > >>>>> then be elected as the DR while you were still rebooting? > >>>>> > >>>>> > >>>>> > >>>>>>> 4) Within 2.2. Would seeing a hello without the graceful > >>>>>>> restarting router id as the earlier DR or BDR, cause > >>>>>>> it to exit, if it was a DR / BDR? > >>>>>> > >>>>>>Not directly, but an inconsistency with the pre-restart LSA will cause > >>>>>>the restarting router to exist graceful restart prematurely. > >>>>>> > >>>>>> > >>>>>> > >>>>>>> 5) Within 2.2. Is it implimentation dependent on how we > >>>>>>> determine our existing nbrs and place their router ids > >>>>>>> in a hello? > >>>>>> > >>>>>>This isn't changed for graceful restart. > >>>>> > >>>>> > >>>>> I thought that you could save past nbr-ids in NVRAM > >>>>> and then compare to existing hellos... > >>>>> > >>>>> > >>>>>>> 6) Within 2.2 (1), isn't adj establishment partly the > >>>>>>> recieving of hellos, with your own router-id? Shouldn't > >>>>>>> that inform others that we are back and to cancel > >>>>>>> their helper graceful nbr timer? > >>>>>>> > >>>>>>> 7 & 8) Within 2.3 "Actions on exiting graceful restart". > >>>>>>> > >>>>>>> 7) Shouldn't the sending hellos be performed that > >>>>>>> identify full adj be a criteria here? > >>>>>> > >>>>>>No. LSA convergence with the pre-restart LSAs is a much surer > >>>>>>mechanism for determining the graceful restart can be exited. > >>>>>> > >>>>>> > >>>>>> > >>>>>>> 8) I am unsure whether you are specifying the > >>>>>>> storage of part of restarting router's LSDB into > >>>>>>> non-volatile memory. If so, then upon retrieval, > >>>>>>> shouldn't some elements of the LSDB be aged > >>>>>>> by the amount that the actual amount of time > >>>>>>> the LSAs were in NV memory? > >>>>>> > >>>>>>There is no mention of storing LSAs in non-volatile storage. > >>>>>> > >>>>> > >>>>> > >>>>> Ok, you aren't suggesting saving the LSDB in NVRAM > >>>>> or some other type of storage media.. > >>>>> > >>>>> > >>>>>>> > >>>>>>> Mitchell Erblich > >>>>>>> ================================== > >>>>>>> > >>>>>> > >>>>>>-- > >>>>>>Acee > >>>>> > >>>>> > >>>>-- > >>>>Acee > >>> > > > > -- > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 10 14:58:10 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00933 for ; Thu, 10 Apr 2003 14:58:09 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0097063B@cherry.ease.lsoft.com>; Thu, 10 Apr 2003 15:00:44 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 737295 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 10 Apr 2003 15:00:44 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 10 Apr 2003 15:00:44 -0500 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 6BB567225AB for ; Thu, 10 Apr 2003 11:59:58 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <200304082356.h38NunH88489@garnet.juniper.net> <3E93755E.1937BC89@earthlink.net> <3E95061B.5060200@redback.com> <3E95BACC.E53FDC89@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E95BEDF.2010606@redback.com> Date: Thu, 10 Apr 2003 14:58:39 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Draft : Graceful Restart : : grace period, etc To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Erblichs wrote: > Acee, et al, > > I didn't really want to continue this thread > but I feel, I should restate some items here. :) > > >>As Padma stated, the draft supports unscheduled restarts (there >>are multiple interoperable implementations). Your proposal to >>announce graceful restart in advance > > > > I don't see how one can send out grace-LSAs and possibly be > able to retransmit a grace-LSA OTHER than in advance, > AND still support unscheduled graceful restarts!!! Mitchell, In the case of unscheduled restart you may send the grace LSA a couple times but you don't want for an acknowledge (you don't necessarily know your neighbors since you are learning the state from the networks). I suggest you read or review section 5 of the draft. It covers all of your concerns below. > > You must do it in advance, else it is scheduled.. > > My definition of unscheduled is that some event occurs and > the non-forwarding portion of the router is DOWN... No, > time for an sys admin to do anything... > > The ONLY possible way is to have trap level code call > the xmit grace-LSA code section. However, no time to > see if acks have been rec'vd and no time for a 5 sec > rexmit.... > > Ok, then WHAT is an UNSCHEDULED GRACEFUL RESTART in your > guys opinion???? > > On the assumption that if the router fails and > still abides by the condition that it is still > forwarding as if it was still up.., then > > As long as there isn't any topologoy changes > as stated within your document, that is one > reason to allow for a graceful restart, I don't > see the blackhole.. > > If the topology changes then it would invalidate > my graceful restart, as it would also invalidate > the graceful restart specified in the draft. > > The only deltas that I was asking for was: > - the issue of sending out a minimal grace-LSA at > adj timeframe, > - being able to minimally update our grace-LSA as > topology changes, > - or we decide that we want to withdraw our grace-LSA > via MAXAGE, > > As of this time, I have not read in your document, > EXPLICITLY whether > - you suggest to ONLY send out the grace-LSA when you > have planned to do a restart (scheduled), > - how to withdraw the grace-LSAs from accepted helpers > when one proto-helper (to be helper), will not ack > your LSA, > - etc.. > > > Mitchell Erblich > Sr Software Engineer > ============================ > > > > > Acee Lindem wrote: > >>Erblichs wrote: >> >>>Padma, >>> >>> >>> These are my last comments!! >>> >>> Also inline... >>> >>> Why doesn't the draft RFC authors want to >>> allow non-scheduled restarts in this >>> draft? >> >>Michell, >> >>As Padma stated, the draft supports unscheduled restarts (there >>are multiple interoperable implementations). Your proposal to >>announce graceful restart in advance will unnecessarily delay >>the detection of a black hole if the restarting router is really dead >>or was abruptly decommissioned. The current draft doesn't suffer >>from this flaw. >> >> >>> Is there something wrong with the idea >>> of un-scheduled restarts? >>> >>> Why restrict it to only scheduled >>> restarts??? >>> >>> Why require >>> the grace-LSAs to be reflooded every >>> 30 minutes to 1 hr??? >>> >>> Why not send the grace-LSAs without >>> the Type=1, Length=4 grace period field?? >>> It will be determined by the helpers >>> anyway. >>> >>> The sentance is. >>> >>> "The number of seconds that the router's >>> neighbors should continue to advertise the >>> router as fully adjacent".... >>> >>> Thus, without the word "MUST", implimentations >>> will probably follow their own rules. Thus, the >>> grace period field really isn't needed and just >>> consumes bandwidth!!! >>> >>> >>> >>> Mitchell Erblich >>> =================== >>> >>> >>> >>> >>> >>>Padma Pillay-Esnault wrote: >>> >>> >>>>Mitchell, >>>> >>>>I'll try to address your comments >>>> >>>> >>>> >>>>>Acee Lindem, >>>>> >>>>> Since,, you skipped the inline re-comments, I will assume >>>>> that at least you read them.. :) >>>>> >>>>> I think I have expressed as best as I could (I am not >>>>> a tech writer) how I feel that this draft should evolve. >>>>> >>>>> So in summary... >>>>> >>>>>` 0) Remove the length (seconds) field from the grace-LSA. >>>>> >>>> >>>>This is using the TLV format .. so you want to keep the length >>> >>> >>> Of course, Type, Length, Value... Fine. Reword.. >>> Remove >>> the Grace-Period field of (Type =1, Length = 4). >>> Why transmit the field value????? >>> >>> >>>>> 1) Transmit DNA grace-LSAs at adj creation time. >>>>> >>>> >>>>This is not very useful. Today unless you have DNA lsa you cannot >>>>expect to be requesting a grace period of over one hour -- as >>>>all the LSA in the other routers database will expire at the >>>>most in 1hr. >>>>So if you decide to send a grace LSA it would be the most recent one >>>>that you built and hence if it has time to expire then the previous >>>>would already be gone. >>> >>> >>> Think ahead of tomarrow, not today... >>> How should this work in the utopian word? If the graceful >>> restart is a good idea, then it NOT should be used for ALL >>> possible restarts?? >>> >>> Why not restrict the amount of flooding with THESE types >>> of LSAs if this draft becomes a standard RFC?? >>> >>> What happens if I send the grace-LSAs at adj formation >>> time and then reflood them every 55 minutes?? This >>> removes the lightweight mechanism of the draft, but >>> still gets me unscheduled restart functionality? Maybe >>> i will just do that.. BTW, and also do unscheduled >>> restarts with my BGP protocol once it becomes a >>> standard. >>> >>> Thus, a restriction of 1 hr isn't sensible. Else, even if >>> I follow your logic, then why do I ask for 1 hr? Should >>> my implimentation in the helper not ack the grace-LSA if >>> the specified grace-period is over 1 hr from the restarting >>> router? This is unspecified behavior!!! >>> >>> >>> >>> >>>>> 2) Let the helpers determine amount of time that >>>>> they will function as a helper. Suggest a minimum >>>>> of 1 hr time. >>>>> >>>> >>>>This is a matter of policy .. even if the helper decides that >>>>he is not going to help for the whole period .. as he is not >>>>going to signal it to the restarting router .. I do not see >>>>the use of doing so. >>>> >>>> >>>> >>>>> 3) Reflood the DNA grace-LSAs anytime the contents >>>>> have changed. >>>>> >>>> >>>>See my response in 1. >>>> >>>> >>>> >>>>> 4) If the restart router expects to be down for a period >>>>> longer than X, then retransmit the Grace-LSAs as >>>>> MAXage LSAs. >>>>> >>>> >>>>I do not see the benefit or I am missing your point >>>> >>>>Padma >>>> >>>> >>>> >>>>> This would minimize bandwidth requirements and allow a >>>>> restarting router to have either scheduled or unscheduled >>>>> restarts. >>>>> >>>>> I don't know what else to add, except if you adopt one or >>>>> more of these suggestions, then please add my name to your >>>>> comment list. :) >>>>> >>>>> Mitchell Erblich >>>>> Sr Software Engineer >>>>> ============================ >>>>> >>>>> >>>>>Acee Lindem wrote: >>>>> >>>>> >>>>>>Erblichs wrote: >>>>>> >>>>>> >>>>>>>Acee Lindem, >>>>>>> >>>>>>> Sometimes my logic is a little obtuse.. >>>>>>> >>>>>>> Most of it is inline... >>>>>>> >>>>>>> I will first throw two new questions to you!!!! >>>>>>> >>>>>>> 1) Why don't you send out the Grace LSA at full >>>>>>> adj timeframe. It would take effect after >>>>>>> RouterDeadinterval has expired? >>>>>> >>>>>>How do you know, apriori, that the OSPF instance is >>>>>>restarting and not completely dead? >>>>> >>>>> Why do you care? As long as the topology isn't changing >>>>> then everything is ok. >>>>> >>>>> Wwhy not minimize the effects of unnecessary SPF computations? >>>>> >>>>> >>>>> >>>>>>> This would also take care of unscheduled restarts >>>>>>> and allow you to do an unscheduled graceful >>>>>>> restart!!!! >>>>>>> >>>>>>> You could also send them as DNA LSAs.. See inline. >>>>>>> >>>>>>> The only new twist is that if you then schedule >>>>>>> a restart, you may want to be able to cancel your >>>>>>> previous request or update the LSAs over time. >>>>>>> But if you conisder a stable topology, then why >>>>>>> NOT?? >>>>>>> >>>>>>> >>>>>>> 2) A) 2.1 3rd, paragraph.. >>>>>>> "Their age field set to 0," >>>>>>> Why can't you send DNA grace-LSAs???? >>>>>> >>>>>>You wouldn't gain anything since the grace interval cannot >>>>>>exceed the LSA refresh time. >>>>>> >>>>> >>>>> So, first why do you need to specify the grace-LSA >>>>> timeframe. Let it be implicitly known to be 1 hr! >>>>> >>>>> With DNA grace-LSAs, we >>>>> don't need to reflood them. If I sent them out >>>>> at adj creation time and the topology isn't >>>>> changing, then I don't need to consume >>>>> resources and keep on re-flooding them.. >>>>> >>>>> Thus, they can last multiple hours or longer.. >>>>> >>>>> >>>>> >>>>>>> B) 2.1, 4th paragraph. >>>>>>> >>>>>>> "it should retransmit... until >>>>>>> they are acknowledged". If you can't retransmit the >>>>>>> same LSA until 5 secs have passed, if a router >>>>>>> was congested, you may want to resubmit the grace-LSA >>>>>>> with a longer length timeframe to your helpers. I am >>>>>>> assuming just bump your instance. Correct? >>>>>> >>>>>>There are implementations that back off LSA retransmissions and the >>>>>>"Prioritized Treatment of Specific OSPF Packets and Congestion >>>>>>Avoidance" draft recommends this. However, this is not standard >>>>>>OSPF flooding as described in RFC2328 and it is an independent >>>>>>issue. >>>>>> >>>>> >>>>> No, no, you are missing my point. Until all of your grace-LSAs are >>>>> ack'ed, you can't continue successfully with a graceful-restart. >>>>> >>>>> This delay consumes time that you specified in your grace-LSA. Yea, >>>>> again, I don't know why you need to specify the amount of time!! >>>>> The timeframe that the helpers will help you can be set independently >>>>> and your spec doesn't allow them to communicate the amount of time >>>>> that they will keeep around a grace-LSA. >>>>> >>>>> Sorry, minor sidetrack. So, the time consumed to get the ack, actually >>>>> reduces the amount of time before the grace-LSA expires. >>>>> >>>>> >>>>>>> >>>>>>> Mitchell >>>>>>> ================ >>>>>>>Acee Lindem wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Mitchell, >>>>>>>> >>>>>>>>See answers below. >>>>>>>> >>>>>>>>Erblichs wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>Group, >>>>>>>>> >>>>>>>>> 1) Within 2.1 "Entering graceful restart", iff all >>>>>>>>> the LSAs were from DC specified NBRs with DNA >>>>>>>>> LSAs should the LS RefreshTime still be followed? >>>>>>>> >>>>>>>>LSA Refresh isn't relevant since the restarting router will >>>>>>>>reestablish adjacencies. >>>>>>> >>>>>>> >>>>>>> Then why have a suggestion of 1800 secs for LSReshTime >>>>>>> in your draft at the end of the 1st paragraph in section >>>>>>> 2.1? >>>>>>> >>>>>>> In my scenario, there would be no reason not to let the >>>>>>> value approach or exceed 3600 secs (1 hr). >>>>>>> >>>>>>> variation on a theme? Why not let the max value of your >>>>>>> grace-LSA length field allow the helper determine what >>>>>>> is the max that he will support? >>>>>>> -- what happens if you specify a value that is >>>>>>> greater than what the helper supports? >>>>>>> Ans A: The helper sees it as an invalid request >>>>>>> and throws away the whole request, >>>>>>> >>>>>>> OR >>>>>>> Ans B: The helper determines what the length he >>>>>>> will support? >>>>>>> >>>>>>> If it is B, then why have the length field. Just let >>>>>>> the helper decide how long to support the request? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> 2) Within 2.2 "When to exit graceful restart", number >>>>>>>>> (3) "The grace period expires". >>>>>>>>> >>>>>>>>> What happens if we follow #3 and your #1 "reestablished >>>>>>>>> all its adjacencies" criteria is not met? >>>>>>>> >>>>>>>>The restarting router will exit graceful restart anyway. >>>>>>> >>>>>>> >>>>>>> Why? If you still have a non-changing topology, why >>>>>>> limit the value to what you had said to the helpers? >>>>>>> >>>>>>> So, what if you asked for x time and it took you >>>>>>> x + y time? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> Or are you stating that the specified "grace period" was >>>>>>>>> to short to perform what was required? >>>>>>>> >>>>>>>>Not necessarily - perhaps the topology has changed and graceful restart >>>>>>>>cannot be completed successfully. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> 3) Within 2.2. Would seeing a hello without the graceful >>>>>>>>> restarting router id", force it to exit? >>>>>>>> >>>>>>>>No. The adjacency can go all the way down on the helper router. The hello >>>>>>>>shouldn't be used as a criteria for exiting helper mode. Do not confuse >>>>>>>>this with other graceful restart proposals. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> I see that my question with the hello was answered in the >>>>>>> 2. (3) "an hello packet is received".. >>>>>>> >>>>>>> I am confused. One router may list you as the DR and another >>>>>>> may not? If one is a helper, then why would it take the adj >>>>>>> down if all the crieria were met? >>>>>>> >>>>>>> I thought that helpers >>>>>>> MUST send hellos as if you (graceful restarting router) were >>>>>>> still there!! >>>>>>> "an Hello packet is received from a neighbor listing the >>>>>>> router as the Designated Router". >>>>>>> >>>>>>> If it did keep anouncing you in the hellos (you weren't >>>>>>> the DR) and lets say that the DR went down. Could you >>>>>>> then be elected as the DR while you were still rebooting? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> 4) Within 2.2. Would seeing a hello without the graceful >>>>>>>>> restarting router id as the earlier DR or BDR, cause >>>>>>>>> it to exit, if it was a DR / BDR? >>>>>>>> >>>>>>>>Not directly, but an inconsistency with the pre-restart LSA will cause >>>>>>>>the restarting router to exist graceful restart prematurely. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> 5) Within 2.2. Is it implimentation dependent on how we >>>>>>>>> determine our existing nbrs and place their router ids >>>>>>>>> in a hello? >>>>>>>> >>>>>>>>This isn't changed for graceful restart. >>>>>>> >>>>>>> >>>>>>> I thought that you could save past nbr-ids in NVRAM >>>>>>> and then compare to existing hellos... >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> 6) Within 2.2 (1), isn't adj establishment partly the >>>>>>>>> recieving of hellos, with your own router-id? Shouldn't >>>>>>>>> that inform others that we are back and to cancel >>>>>>>>> their helper graceful nbr timer? >>>>>>>>> >>>>>>>>> 7 & 8) Within 2.3 "Actions on exiting graceful restart". >>>>>>>>> >>>>>>>>> 7) Shouldn't the sending hellos be performed that >>>>>>>>> identify full adj be a criteria here? >>>>>>>> >>>>>>>>No. LSA convergence with the pre-restart LSAs is a much surer >>>>>>>>mechanism for determining the graceful restart can be exited. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> 8) I am unsure whether you are specifying the >>>>>>>>> storage of part of restarting router's LSDB into >>>>>>>>> non-volatile memory. If so, then upon retrieval, >>>>>>>>> shouldn't some elements of the LSDB be aged >>>>>>>>> by the amount that the actual amount of time >>>>>>>>> the LSAs were in NV memory? >>>>>>>> >>>>>>>>There is no mention of storing LSAs in non-volatile storage. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> Ok, you aren't suggesting saving the LSDB in NVRAM >>>>>>> or some other type of storage media.. >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> Mitchell Erblich >>>>>>>>> ================================== >>>>>>>>> >>>>>>>> >>>>>>>>-- >>>>>>>>Acee >>>>>>> >>>>>>> >>>>>>-- >>>>>>Acee >>>>> >>-- >>Acee > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 11 03:26:43 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01974 for ; Fri, 11 Apr 2003 03:26:43 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.009719E9@cherry.ease.lsoft.com>; Fri, 11 Apr 2003 3:29:17 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 739082 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Apr 2003 03:29:17 -0400 Received: from 61.144.161.2 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 11 Apr 2003 03:19:16 -0500 Received: from CL30105030 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HD6009F3499TH@mta0.huawei.com> for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Apr 2003 15:17:36 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Mailer: Microsoft Outlook Express 5.50.4807.1700 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <200304091914.PAA31115@bigbird.xebeo.com> Message-ID: <006301c2fffb$5aaac390$ab04120a@in.huawei.com> Date: Fri, 11 Apr 2003 12:54:12 +0530 Reply-To: Mailing List Sender: Mailing List From: sujay Subject: OSPF test To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7BIT Hi List, I am a newbie. Are there any standard test cases available for conformance testing of OSPF, esp the TE support ? Looking forward to some guidance. Sujay From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 11 07:00:41 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06667 for ; Fri, 11 Apr 2003 07:00: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.00971B15@cherry.ease.lsoft.com>; Fri, 11 Apr 2003 7:03:15 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 739719 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Apr 2003 07:03:14 -0400 Received: from 216.136.131.39 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 11 Apr 2003 06:53:13 -0500 Received: from [192.100.124.218] by web10903.mail.yahoo.com via HTTP; Fri, 11 Apr 2003 11:53:13 BST MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <20030411105313.97404.qmail@web10903.mail.yahoo.com> Date: Fri, 11 Apr 2003 11:53:13 +0100 Reply-To: Mailing List Sender: Mailing List From: =?iso-8859-1?q?df=20klsd?= Subject: flooding LSA in RFC 2328 To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit I have a question on the flooding LSA in RFC 2328. Considering router-A sending LSA with MaxAge to router-B for flushing an instance x. However, the instance x of the LSA is not existing in the router B. What the router B will do? According to RFC 2328, §13, step (4): if "none of router's neighbors are in states Exchange or Loading, then take the following actions: a) Acknowledge the receipt of the LSA by sending a Link State Acknowledgment packet back to the sending neighbor (see Section 13.5), and b) Discard the LSA and examine the next LSA (if any) listed in the Link State Update packet." What about if "one of router's neighbors are in states Exchange or Loading"? Two possibility: (1) discard the LSA and no ACK (my initial understanding) However, it is not the case according to appendix G of RFC 2328 (2) Going to the step (5), if go to the step (5), let us have a look what will do: the substep (a)-(f) will and must be preformed: (a) not thing to be done (b) immediately flood the non-existing instance with MaxAge LSA out (c) not thing to be done (d) not thing to be done (e) no ACK is sent (router-B is in loading or exchange state) according to 13.5 of RFC 2328 (f) not thing to be done? The non-existing instance of the MaxAge LSA really creates problems to the adjacency routers by those substeps. 1. what is the point of flooding the non-existing instance with MaxAge? 2. the original sender router A will continually send the non-existing instance of the MaxAge LSA to router B until ACK is received. Then router finds it is the wrong copy and send the right copy. However, RFC 2178 will not have such a problem. Why RFC 2328 does such change? Is a bug in the RFC 2328? BR Shaoji __________________________________________________ Yahoo! Plus For a better Internet experience http://www.yahoo.co.uk/btoffer From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 11 08:53:08 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10788 for ; Fri, 11 Apr 2003 08:53:08 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00971C79@cherry.ease.lsoft.com>; Fri, 11 Apr 2003 8:55:42 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 739958 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Apr 2003 08:55:42 -0400 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 11 Apr 2003 08:55:42 -0500 Received: from mail.apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h3BDUOL20848 for ; Fri, 11 Apr 2003 19:00:24 +0530 Received: from alok ([203.124.140.101]) (authenticated) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h3BDUKX20842 for ; Fri, 11 Apr 2003 19:00:21 +0530 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <014001c3002a$10c24760$81c802c0@alok> Date: Fri, 11 Apr 2003 18:28:25 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: route insertion into Forwarding table.. To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Greetings, There is something which has been confusing me for quite a while now, If a router receives an update from a neighbour, informing it of some change in topology, or if one assumes that there is a "router coming up with some existing entries in the forwarding table", "when" is this new route put into the forwarding table? in other words, when is the new route treated as "valid"? Is it as soon as SPF calculations are done or is it after an LSack is sent? What is the exact sequence? update----SPF----ack---FT or update---SPF----FT---ack Thanking you for your help, Alok From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 11 10:03:09 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12721 for ; Fri, 11 Apr 2003 10:03:08 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00971D6B@cherry.ease.lsoft.com>; Fri, 11 Apr 2003 10:05:43 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 740115 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Apr 2003 10:05:42 -0400 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 11 Apr 2003 10:05:40 -0500 Received: from mail.apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h3BEeNL22046 for ; Fri, 11 Apr 2003 20:10:23 +0530 Received: from alok ([203.124.140.101]) (authenticated) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h3BEeLX22039 for ; Fri, 11 Apr 2003 20:10:21 +0530 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <029e01c30033$d765a200$81c802c0@alok> Date: Fri, 11 Apr 2003 19:38:24 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: Re: route insertion into Forwarding table.. To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list or is it update (update comes in)---ack----run SPF --- put into FT ? Could a router not go down after the ack ? but the neighbours would believe that the FT is accurate? -rgds Alok ----- Original Message ----- From: alok To: Sent: Friday, April 11, 2003 6:28 PM Subject: route insertion into Forwarding table.. > Greetings, > > There is something which has been confusing me for quite a while now, > > If a router receives an update from a neighbour, informing it of some change > in topology, > > or if one assumes that there is a "router coming up with some existing > entries in the forwarding table", > > "when" is this new route put into the forwarding table? > > in other words, when is the new route treated as "valid"? > > Is it as soon as SPF calculations are done or is it after an LSack is sent? > > What is the exact sequence? > > update----SPF----ack---FT > > or > > update---SPF----FT---ack > > > Thanking you for your help, > Alok > > > From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 11 10:33:51 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15605 for ; Fri, 11 Apr 2003 10:33:50 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00971E3B@cherry.ease.lsoft.com>; Fri, 11 Apr 2003 10:36:24 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 740198 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Apr 2003 10:36:23 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 11 Apr 2003 10:36:23 -0500 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 2E51C89C240 for ; Fri, 11 Apr 2003 07:36:22 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <029e01c30033$d765a200$81c802c0@alok> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E96D28C.5050401@redback.com> Date: Fri, 11 Apr 2003 10:34:52 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: route insertion into Forwarding table.. To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit alok wrote: > or is it > > update (update comes in)---ack----run SPF --- put into FT ? > > Could a router not go down after the ack ? > > but the neighbours would believe that the FT is accurate? Alok, The only thing the OSPF router should infer from the ack is that the LSA has been received by its neighbor and need not be retransmitted. The control plane and forwarding plane should converge in due time. Thanks, Acee > > -rgds > Alok > > > ----- Original Message ----- > From: alok > To: > Sent: Friday, April 11, 2003 6:28 PM > Subject: route insertion into Forwarding table.. > > > >>Greetings, >> >>There is something which has been confusing me for quite a while now, >> >>If a router receives an update from a neighbour, informing it of some > > change > >>in topology, >> >>or if one assumes that there is a "router coming up with some existing >>entries in the forwarding table", >> >>"when" is this new route put into the forwarding table? >> >>in other words, when is the new route treated as "valid"? >> >>Is it as soon as SPF calculations are done or is it after an LSack is > > sent? > >>What is the exact sequence? >> >>update----SPF----ack---FT >> >>or >> >>update---SPF----FT---ack >> >> >>Thanking you for your help, >>Alok >> >> >> > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 11 13:29:13 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22248 for ; Fri, 11 Apr 2003 13:29:13 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00972429@cherry.ease.lsoft.com>; Fri, 11 Apr 2003 13:31:36 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 740777 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Apr 2003 13:31:36 -0400 Received: from 131.241.15.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 11 Apr 2003 13:31:36 -0500 Received: from netkeeper2.sj.nec.com (netkeeper2.sj.nec.com [131.241.31.10]) by mail4.nec.com (/) with ESMTP id h3BHVYpG005594 for ; Fri, 11 Apr 2003 10:31:34 -0700 (PDT) Received: from necsun.tdd.sj.nec.com (localhost [127.0.0.1]) by netkeeper2.sj.nec.com (/) with ESMTP id h3BHVR98011788 for ; Fri, 11 Apr 2003 10:31:27 -0700 (PDT) Received: from bunny.tdd.sj.nec.com (bunny.tdd.sj.nec.com [131.241.9.33]) by necsun.tdd.sj.nec.com (8.12.8/8.12.8) with ESMTP id h3BHLJ3a024706 for ; Fri, 11 Apr 2003 10:21:19 -0700 (PDT) Received: from ems12 (ems12 [131.241.5.17]) by bunny.tdd.sj.nec.com with SMTP id h3BHLHYS000820 for ; Fri, 11 Apr 2003 10:21:17 -0700 (PDT) References: <200304091914.PAA31115@bigbird.xebeo.com> <006301c2fffb$5aaac390$ab04120a@in.huawei.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.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: <0fc301c30051$123a2fa0$1105f183@b90.tdd.sj.nec.com> Date: Fri, 11 Apr 2003 10:37:49 -0700 Reply-To: Mailing List Sender: Mailing List From: kamatchi soundaram Subject: Re: OSPF test To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Sujay!! The following link will take u to OSPF interoperability and other testing related test plans. But i am not sure, whether it covers OSPF-TE or not. http://www.iol.unh.edu/testsuites/index.html GKS. ----- Original Message ----- From: "sujay" To: Sent: Friday, April 11, 2003 12:24 AM Subject: OSPF test > Hi List, > I am a newbie. > Are there any standard test cases available for > conformance testing of OSPF, esp the TE support ? > Looking forward to some guidance. > Sujay > From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 11 15:14:24 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25953 for ; Fri, 11 Apr 2003 15:14:23 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.009725C6@cherry.ease.lsoft.com>; Fri, 11 Apr 2003 15:16:56 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 741150 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Apr 2003 15:16:56 -0400 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 11 Apr 2003 15:16:56 -0500 Received: from mail.apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h3BJphL24633 for ; Sat, 12 Apr 2003 01:21:43 +0530 Received: from apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with SMTP id h3BJphX24627 for ; Sat, 12 Apr 2003 01:21:43 +0530 Received: from 219.65.131.106 (SquirrelMail authenticated user alok.dube) by mail.apara.com with HTTP; Sat, 12 Apr 2003 01:21:43 +0530 (IST) References: <029e01c30033$d765a200$81c802c0@alok> <3E96D28C.5050401@redback.com> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <1160.219.65.131.106.1050090703.squirrel@mail.apara.com> Date: Sat, 12 Apr 2003 01:21:43 +0530 Reply-To: Mailing List Sender: Mailing List From: Alok Dube Subject: Re: route insertion into Forwarding table.. To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E96D28C.5050401@redback.com> Precedence: list Content-Transfer-Encoding: 8bit > alok wrote: >> or is it >> >> update (update comes in)---ack----run SPF --- put into FT ? >> >> Could a router not go down after the ack ? >> >> but the neighbours would believe that the FT is accurate? > > Alok, > > The only thing the OSPF router should infer from the ack is > that the LSA has been received by its neighbor and need not > be retransmitted. The control plane and forwarding plane > should converge in due time. > > Thanks, > Acee > Acee, 2 more queries.. pertaining to "graceful restart" 1. Incase a router "acks" this LSA and then enters a "graceful restart" without modifying the FT, what is the result? 2. If there is a way to "ensure this convergence" shouldnt this methodology be "documented" as a part of the draft?... or shouldnt it be mentioned that the "gracefully restarting router" should "ensure this convergence" before entring the "graceful restart"? -rgds Alok From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 11 20:31:55 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06474 for ; Fri, 11 Apr 2003 20:31:54 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00972E56@cherry.ease.lsoft.com>; Fri, 11 Apr 2003 20:34:28 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 741984 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Apr 2003 20:34:28 -0400 Received: from 207.217.120.116 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 11 Apr 2003 20:34:28 -0500 Received: from user-2ivfj22.dialup.mindspring.com ([165.247.204.66] helo=earthlink.net) by grouse.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1948yA-00031f-00 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Apr 2003 17:34:12 -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: <200304082356.h38NunH88489@garnet.juniper.net> <3E93755E.1937BC89@earthlink.net> <3E95061B.5060200@redback.com> <3E95BACC.E53FDC89@earthlink.net> <3E95BEDF.2010606@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E975E6E.73A22F08@earthlink.net> Date: Fri, 11 Apr 2003 17:31:42 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Draft : Graceful Restart : : grace period, etc To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, First of all I would want to apologize for continuing this discussion thread! I realize that some implimentions may exist based on this draft and what I am suggesting, may effect changes to them. In my past emails I have implicitly ignored the section 5 within this draft of "Unplanned outages". I will now explicitly state why I have ignored its suggested method. Why? * " must originate grace-LSAs *after* its control software resumes operation", we now lose our DR or BDR status, if it had existed. - This forces a SPF recomputation.. - This can forces many full adj reformations. - Removes the helper relationship with respect to the restarting router (monitoring, continues to (its) advertise its LSAs, etc) NIT: remove the first "its". - etc.. Thus this section invalidates many of the reasons for the draft's existance. * If the draft's unplanned outages did not have these negative effects and more, then anytime > 1 hr graceful restart is planned, then this would be a solid alternative. I just cannot see anyone forwarding any pkts accross a non-adj, so even if your forwarding table contents are sanitized, it will be ignored. So, from may past information dump, the only true side effect other than mentioned in the draft (clean flag for the forwarding table should remove the table sanity issue) are the issues of the reflooding bandwidth of early grace-LSAs, just in case the router has an unplanned restart. And the extra work that is placed on helper routers to "monitor" the network for topology changes, and its other assigned helper duties. Thus, I believe that I have more than sufficiently identified a graceful restart mechanism that removes the AFTER requirement and allows the planned graceful restart method to be used in a unplanned way. Plus, I agree that a knob/CLI command should be used to enable or disable this type of feature. Mitchell Erblich Sr Software Engineer ---------------------- Acee Lindem wrote: > > Erblichs wrote: > > Acee, et al, > > > > I didn't really want to continue this thread > > but I feel, I should restate some items here. :) > > > > > >>As Padma stated, the draft supports unscheduled restarts (there > >>are multiple interoperable implementations). Your proposal to > >>announce graceful restart in advance > > > > > > > > I don't see how one can send out grace-LSAs and possibly be > > able to retransmit a grace-LSA OTHER than in advance, > > AND still support unscheduled graceful restarts!!! > > Mitchell, > > In the case of unscheduled restart you may send the grace LSA a couple > times but you don't want for an acknowledge (you don't necessarily know your > neighbors since you are learning the state from the networks). > > I suggest you read or review section 5 of the draft. It covers all of your > concerns below. > > > > > You must do it in advance, else it is scheduled.. > > > > My definition of unscheduled is that some event occurs and > > the non-forwarding portion of the router is DOWN... No, > > time for an sys admin to do anything... > > > > The ONLY possible way is to have trap level code call > > the xmit grace-LSA code section. However, no time to > > see if acks have been rec'vd and no time for a 5 sec > > rexmit.... > > > > Ok, then WHAT is an UNSCHEDULED GRACEFUL RESTART in your > > guys opinion???? > > > > On the assumption that if the router fails and > > still abides by the condition that it is still > > forwarding as if it was still up.., then > > > > As long as there isn't any topologoy changes > > as stated within your document, that is one > > reason to allow for a graceful restart, I don't > > see the blackhole.. > > > > If the topology changes then it would invalidate > > my graceful restart, as it would also invalidate > > the graceful restart specified in the draft. > > > > The only deltas that I was asking for was: > > - the issue of sending out a minimal grace-LSA at > > adj timeframe, > > - being able to minimally update our grace-LSA as > > topology changes, > > - or we decide that we want to withdraw our grace-LSA > > via MAXAGE, > > > > As of this time, I have not read in your document, > > EXPLICITLY whether > > - you suggest to ONLY send out the grace-LSA when you > > have planned to do a restart (scheduled), > > - how to withdraw the grace-LSAs from accepted helpers > > when one proto-helper (to be helper), will not ack > > your LSA, > > - etc.. > > > > > > Mitchell Erblich > > Sr Software Engineer > > ============================ > > > > > > > > > > Acee Lindem wrote: > > > >>Erblichs wrote: > >> > >>>Padma, > >>> > >>> > >>> These are my last comments!! > >>> > >>> Also inline... > >>> > >>> Why doesn't the draft RFC authors want to > >>> allow non-scheduled restarts in this > >>> draft? > >> > >>Michell, > >> > >>As Padma stated, the draft supports unscheduled restarts (there > >>are multiple interoperable implementations). Your proposal to > >>announce graceful restart in advance will unnecessarily delay > >>the detection of a black hole if the restarting router is really dead > >>or was abruptly decommissioned. The current draft doesn't suffer > >>from this flaw. > >> > >> > >>> Is there something wrong with the idea > >>> of un-scheduled restarts? > >>> > >>> Why restrict it to only scheduled > >>> restarts??? > >>> > >>> Why require > >>> the grace-LSAs to be reflooded every > >>> 30 minutes to 1 hr??? > >>> > >>> Why not send the grace-LSAs without > >>> the Type=1, Length=4 grace period field?? > >>> It will be determined by the helpers > >>> anyway. > >>> > >>> The sentance is. > >>> > >>> "The number of seconds that the router's > >>> neighbors should continue to advertise the > >>> router as fully adjacent".... > >>> > >>> Thus, without the word "MUST", implimentations > >>> will probably follow their own rules. Thus, the > >>> grace period field really isn't needed and just > >>> consumes bandwidth!!! > >>> > >>> > >>> > >>> Mitchell Erblich > >>> =================== > >>> > >>> > >>> > >>> > >>> > >>>Padma Pillay-Esnault wrote: > >>> > >>> > >>>>Mitchell, > >>>> > >>>>I'll try to address your comments > >>>> > >>>> > >>>> > >>>>>Acee Lindem, > >>>>> > >>>>> Since,, you skipped the inline re-comments, I will assume > >>>>> that at least you read them.. :) > >>>>> > >>>>> I think I have expressed as best as I could (I am not > >>>>> a tech writer) how I feel that this draft should evolve. > >>>>> > >>>>> So in summary... > >>>>> > >>>>>` 0) Remove the length (seconds) field from the grace-LSA. > >>>>> > >>>> > >>>>This is using the TLV format .. so you want to keep the length > >>> > >>> > >>> Of course, Type, Length, Value... Fine. Reword.. > >>> Remove > >>> the Grace-Period field of (Type =1, Length = 4). > >>> Why transmit the field value????? > >>> > >>> > >>>>> 1) Transmit DNA grace-LSAs at adj creation time. > >>>>> > >>>> > >>>>This is not very useful. Today unless you have DNA lsa you cannot > >>>>expect to be requesting a grace period of over one hour -- as > >>>>all the LSA in the other routers database will expire at the > >>>>most in 1hr. > >>>>So if you decide to send a grace LSA it would be the most recent one > >>>>that you built and hence if it has time to expire then the previous > >>>>would already be gone. > >>> > >>> > >>> Think ahead of tomarrow, not today... > >>> How should this work in the utopian word? If the graceful > >>> restart is a good idea, then it NOT should be used for ALL > >>> possible restarts?? > >>> > >>> Why not restrict the amount of flooding with THESE types > >>> of LSAs if this draft becomes a standard RFC?? > >>> > >>> What happens if I send the grace-LSAs at adj formation > >>> time and then reflood them every 55 minutes?? This > >>> removes the lightweight mechanism of the draft, but > >>> still gets me unscheduled restart functionality? Maybe > >>> i will just do that.. BTW, and also do unscheduled > >>> restarts with my BGP protocol once it becomes a > >>> standard. > >>> > >>> Thus, a restriction of 1 hr isn't sensible. Else, even if > >>> I follow your logic, then why do I ask for 1 hr? Should > >>> my implimentation in the helper not ack the grace-LSA if > >>> the specified grace-period is over 1 hr from the restarting > >>> router? This is unspecified behavior!!! > >>> > >>> > >>> > >>> > >>>>> 2) Let the helpers determine amount of time that > >>>>> they will function as a helper. Suggest a minimum > >>>>> of 1 hr time. > >>>>> > >>>> > >>>>This is a matter of policy .. even if the helper decides that > >>>>he is not going to help for the whole period .. as he is not > >>>>going to signal it to the restarting router .. I do not see > >>>>the use of doing so. > >>>> > >>>> > >>>> > >>>>> 3) Reflood the DNA grace-LSAs anytime the contents > >>>>> have changed. > >>>>> > >>>> > >>>>See my response in 1. > >>>> > >>>> > >>>> > >>>>> 4) If the restart router expects to be down for a period > >>>>> longer than X, then retransmit the Grace-LSAs as > >>>>> MAXage LSAs. > >>>>> > >>>> > >>>>I do not see the benefit or I am missing your point > >>>> > >>>>Padma > >>>> > >>>> > >>>> > >>>>> This would minimize bandwidth requirements and allow a > >>>>> restarting router to have either scheduled or unscheduled > >>>>> restarts. > >>>>> > >>>>> I don't know what else to add, except if you adopt one or > >>>>> more of these suggestions, then please add my name to your > >>>>> comment list. :) > >>>>> > >>>>> Mitchell Erblich > >>>>> Sr Software Engineer > >>>>> ============================ > >>>>> > >>>>> > >>>>>Acee Lindem wrote: > >>>>> > >>>>> > >>>>>>Erblichs wrote: > >>>>>> > >>>>>> > >>>>>>>Acee Lindem, > >>>>>>> > >>>>>>> Sometimes my logic is a little obtuse.. > >>>>>>> > >>>>>>> Most of it is inline... > >>>>>>> > >>>>>>> I will first throw two new questions to you!!!! > >>>>>>> > >>>>>>> 1) Why don't you send out the Grace LSA at full > >>>>>>> adj timeframe. It would take effect after > >>>>>>> RouterDeadinterval has expired? > >>>>>> > >>>>>>How do you know, apriori, that the OSPF instance is > >>>>>>restarting and not completely dead? > >>>>> > >>>>> Why do you care? As long as the topology isn't changing > >>>>> then everything is ok. > >>>>> > >>>>> Wwhy not minimize the effects of unnecessary SPF computations? > >>>>> > >>>>> > >>>>> > >>>>>>> This would also take care of unscheduled restarts > >>>>>>> and allow you to do an unscheduled graceful > >>>>>>> restart!!!! > >>>>>>> > >>>>>>> You could also send them as DNA LSAs.. See inline. > >>>>>>> > >>>>>>> The only new twist is that if you then schedule > >>>>>>> a restart, you may want to be able to cancel your > >>>>>>> previous request or update the LSAs over time. > >>>>>>> But if you conisder a stable topology, then why > >>>>>>> NOT?? > >>>>>>> > >>>>>>> > >>>>>>> 2) A) 2.1 3rd, paragraph.. > >>>>>>> "Their age field set to 0," > >>>>>>> Why can't you send DNA grace-LSAs???? > >>>>>> > >>>>>>You wouldn't gain anything since the grace interval cannot > >>>>>>exceed the LSA refresh time. > >>>>>> > >>>>> > >>>>> So, first why do you need to specify the grace-LSA > >>>>> timeframe. Let it be implicitly known to be 1 hr! > >>>>> > >>>>> With DNA grace-LSAs, we > >>>>> don't need to reflood them. If I sent them out > >>>>> at adj creation time and the topology isn't > >>>>> changing, then I don't need to consume > >>>>> resources and keep on re-flooding them.. > >>>>> > >>>>> Thus, they can last multiple hours or longer.. > >>>>> > >>>>> > >>>>> > >>>>>>> B) 2.1, 4th paragraph. > >>>>>>> > >>>>>>> "it should retransmit... until > >>>>>>> they are acknowledged". If you can't retransmit the > >>>>>>> same LSA until 5 secs have passed, if a router > >>>>>>> was congested, you may want to resubmit the grace-LSA > >>>>>>> with a longer length timeframe to your helpers. I am > >>>>>>> assuming just bump your instance. Correct? > >>>>>> > >>>>>>There are implementations that back off LSA retransmissions and the > >>>>>>"Prioritized Treatment of Specific OSPF Packets and Congestion > >>>>>>Avoidance" draft recommends this. However, this is not standard > >>>>>>OSPF flooding as described in RFC2328 and it is an independent > >>>>>>issue. > >>>>>> > >>>>> > >>>>> No, no, you are missing my point. Until all of your grace-LSAs are > >>>>> ack'ed, you can't continue successfully with a graceful-restart. > >>>>> > >>>>> This delay consumes time that you specified in your grace-LSA. Yea, > >>>>> again, I don't know why you need to specify the amount of time!! > >>>>> The timeframe that the helpers will help you can be set independently > >>>>> and your spec doesn't allow them to communicate the amount of time > >>>>> that they will keeep around a grace-LSA. > >>>>> > >>>>> Sorry, minor sidetrack. So, the time consumed to get the ack, actually > >>>>> reduces the amount of time before the grace-LSA expires. > >>>>> > >>>>> > >>>>>>> > >>>>>>> Mitchell > >>>>>>> ================ > >>>>>>>Acee Lindem wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>Mitchell, > >>>>>>>> > >>>>>>>>See answers below. > >>>>>>>> > >>>>>>>>Erblichs wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>Group, > >>>>>>>>> > >>>>>>>>> 1) Within 2.1 "Entering graceful restart", iff all > >>>>>>>>> the LSAs were from DC specified NBRs with DNA > >>>>>>>>> LSAs should the LS RefreshTime still be followed? > >>>>>>>> > >>>>>>>>LSA Refresh isn't relevant since the restarting router will > >>>>>>>>reestablish adjacencies. > >>>>>>> > >>>>>>> > >>>>>>> Then why have a suggestion of 1800 secs for LSReshTime > >>>>>>> in your draft at the end of the 1st paragraph in section > >>>>>>> 2.1? > >>>>>>> > >>>>>>> In my scenario, there would be no reason not to let the > >>>>>>> value approach or exceed 3600 secs (1 hr). > >>>>>>> > >>>>>>> variation on a theme? Why not let the max value of your > >>>>>>> grace-LSA length field allow the helper determine what > >>>>>>> is the max that he will support? > >>>>>>> -- what happens if you specify a value that is > >>>>>>> greater than what the helper supports? > >>>>>>> Ans A: The helper sees it as an invalid request > >>>>>>> and throws away the whole request, > >>>>>>> > >>>>>>> OR > >>>>>>> Ans B: The helper determines what the length he > >>>>>>> will support? > >>>>>>> > >>>>>>> If it is B, then why have the length field. Just let > >>>>>>> the helper decide how long to support the request? > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>> 2) Within 2.2 "When to exit graceful restart", number > >>>>>>>>> (3) "The grace period expires". > >>>>>>>>> > >>>>>>>>> What happens if we follow #3 and your #1 "reestablished > >>>>>>>>> all its adjacencies" criteria is not met? > >>>>>>>> > >>>>>>>>The restarting router will exit graceful restart anyway. > >>>>>>> > >>>>>>> > >>>>>>> Why? If you still have a non-changing topology, why > >>>>>>> limit the value to what you had said to the helpers? > >>>>>>> > >>>>>>> So, what if you asked for x time and it took you > >>>>>>> x + y time? > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>> Or are you stating that the specified "grace period" was > >>>>>>>>> to short to perform what was required? > >>>>>>>> > >>>>>>>>Not necessarily - perhaps the topology has changed and graceful restart > >>>>>>>>cannot be completed successfully. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> 3) Within 2.2. Would seeing a hello without the graceful > >>>>>>>>> restarting router id", force it to exit? > >>>>>>>> > >>>>>>>>No. The adjacency can go all the way down on the helper router. The hello > >>>>>>>>shouldn't be used as a criteria for exiting helper mode. Do not confuse > >>>>>>>>this with other graceful restart proposals. > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> I see that my question with the hello was answered in the > >>>>>>> 2. (3) "an hello packet is received".. > >>>>>>> > >>>>>>> I am confused. One router may list you as the DR and another > >>>>>>> may not? If one is a helper, then why would it take the adj > >>>>>>> down if all the crieria were met? > >>>>>>> > >>>>>>> I thought that helpers > >>>>>>> MUST send hellos as if you (graceful restarting router) were > >>>>>>> still there!! > >>>>>>> "an Hello packet is received from a neighbor listing the > >>>>>>> router as the Designated Router". > >>>>>>> > >>>>>>> If it did keep anouncing you in the hellos (you weren't > >>>>>>> the DR) and lets say that the DR went down. Could you > >>>>>>> then be elected as the DR while you were still rebooting? > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>> 4) Within 2.2. Would seeing a hello without the graceful > >>>>>>>>> restarting router id as the earlier DR or BDR, cause > >>>>>>>>> it to exit, if it was a DR / BDR? > >>>>>>>> > >>>>>>>>Not directly, but an inconsistency with the pre-restart LSA will cause > >>>>>>>>the restarting router to exist graceful restart prematurely. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> 5) Within 2.2. Is it implimentation dependent on how we > >>>>>>>>> determine our existing nbrs and place their router ids > >>>>>>>>> in a hello? > >>>>>>>> > >>>>>>>>This isn't changed for graceful restart. > >>>>>>> > >>>>>>> > >>>>>>> I thought that you could save past nbr-ids in NVRAM > >>>>>>> and then compare to existing hellos... > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>> 6) Within 2.2 (1), isn't adj establishment partly the > >>>>>>>>> recieving of hellos, with your own router-id? Shouldn't > >>>>>>>>> that inform others that we are back and to cancel > >>>>>>>>> their helper graceful nbr timer? > >>>>>>>>> > >>>>>>>>> 7 & 8) Within 2.3 "Actions on exiting graceful restart". > >>>>>>>>> > >>>>>>>>> 7) Shouldn't the sending hellos be performed that > >>>>>>>>> identify full adj be a criteria here? > >>>>>>>> > >>>>>>>>No. LSA convergence with the pre-restart LSAs is a much surer > >>>>>>>>mechanism for determining the graceful restart can be exited. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> 8) I am unsure whether you are specifying the > >>>>>>>>> storage of part of restarting router's LSDB into > >>>>>>>>> non-volatile memory. If so, then upon retrieval, > >>>>>>>>> shouldn't some elements of the LSDB be aged > >>>>>>>>> by the amount that the actual amount of time > >>>>>>>>> the LSAs were in NV memory? > >>>>>>>> > >>>>>>>>There is no mention of storing LSAs in non-volatile storage. > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Ok, you aren't suggesting saving the LSDB in NVRAM > >>>>>>> or some other type of storage media.. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>> Mitchell Erblich > >>>>>>>>> ================================== > >>>>>>>>> > >>>>>>>> > >>>>>>>>-- > >>>>>>>>Acee > >>>>>>> > >>>>>>> > >>>>>>-- > >>>>>>Acee > >>>>> > >>-- > >>Acee > > > > > > -- > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Sat Apr 12 00:57:34 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10382 for ; Sat, 12 Apr 2003 00:57:33 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00973699@cherry.ease.lsoft.com>; Sat, 12 Apr 2003 1:00:06 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 742315 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 12 Apr 2003 01:00:06 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 12 Apr 2003 01:00:05 -0500 Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h3C505u22613 for ; Fri, 11 Apr 2003 22:00:05 -0700 (PDT) (envelope-from padma@juniper.net) Received: (from padma@localhost) by garnet.juniper.net (8.11.5/8.11.3) id h3C504u90560 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 11 Apr 2003 22:00:04 -0700 (PDT) (envelope-from padma) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200304120500.h3C504u90560@garnet.juniper.net> Date: Fri, 11 Apr 2003 22:00:04 -0700 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: Draft : Graceful Restart : : grace period, etc To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E975E6E.73A22F08@earthlink.net> from "Erblichs" at Apr 11, 2003 05:31:42 PM Precedence: list Content-Transfer-Encoding: 7bit > > Group, > > First of all I would want to apologize for continuing > this discussion thread! > > I realize that some implimentions may exist based on > this draft and what I am suggesting, may effect changes > to them. > > In my past emails I have implicitly ignored the section > 5 within this draft of "Unplanned outages". I will now > explicitly state why I have ignored its suggested method. > > Why? > * " must originate grace-LSAs *after* its control > software resumes operation", we now lose our DR or > BDR status, if it had existed. > > - This forces a SPF recomputation.. What makes you think that it forces a SPF computation ? Padma > - This can forces many full adj reformations. > - Removes the helper relationship with > respect to the restarting router > (monitoring, continues to (its) advertise its > LSAs, etc) NIT: remove the first "its". > - etc.. > > Thus this section invalidates many of the reasons > for the draft's existance. > > * If the draft's unplanned outages did not have these > negative effects and more, then anytime > 1 hr > graceful restart is planned, then this would be a > solid alternative. I just cannot see anyone > forwarding any pkts accross a non-adj, so even if > your forwarding table contents are sanitized, it > will be ignored. > > So, from may past information dump, the only true side effect > other than mentioned in the draft (clean flag for the forwarding > table should remove the table sanity issue) are the issues of the > reflooding bandwidth of early grace-LSAs, just in case the router > has an unplanned restart. And the extra work that is placed on > helper routers to "monitor" the network for topology changes, > and its other assigned helper duties. > > Thus, I believe that I have more than sufficiently identified > a graceful restart mechanism that removes the AFTER requirement > and allows the planned graceful restart method to be used in a > unplanned way. Plus, I agree that a knob/CLI command should be > used to enable or disable this type of feature. > > Mitchell Erblich > Sr Software Engineer > ---------------------- > > Acee Lindem wrote: > > > > Erblichs wrote: > > > Acee, et al, > > > > > > I didn't really want to continue this thread > > > but I feel, I should restate some items here. :) > > > > > > > > >>As Padma stated, the draft supports unscheduled restarts (there > > >>are multiple interoperable implementations). Your proposal to > > >>announce graceful restart in advance > > > > > > > > > > > > I don't see how one can send out grace-LSAs and possibly be > > > able to retransmit a grace-LSA OTHER than in advance, > > > AND still support unscheduled graceful restarts!!! > > > > Mitchell, > > > > In the case of unscheduled restart you may send the grace LSA a couple > > times but you don't want for an acknowledge (you don't necessarily know your > > neighbors since you are learning the state from the networks). > > > > I suggest you read or review section 5 of the draft. It covers all of your > > concerns below. > > > > > > > > You must do it in advance, else it is scheduled.. > > > > > > My definition of unscheduled is that some event occurs and > > > the non-forwarding portion of the router is DOWN... No, > > > time for an sys admin to do anything... > > > > > > The ONLY possible way is to have trap level code call > > > the xmit grace-LSA code section. However, no time to > > > see if acks have been rec'vd and no time for a 5 sec > > > rexmit.... > > > > > > Ok, then WHAT is an UNSCHEDULED GRACEFUL RESTART in your > > > guys opinion???? > > > > > > On the assumption that if the router fails and > > > still abides by the condition that it is still > > > forwarding as if it was still up.., then > > > > > > As long as there isn't any topologoy changes > > > as stated within your document, that is one > > > reason to allow for a graceful restart, I don't > > > see the blackhole.. > > > > > > If the topology changes then it would invalidate > > > my graceful restart, as it would also invalidate > > > the graceful restart specified in the draft. > > > > > > The only deltas that I was asking for was: > > > - the issue of sending out a minimal grace-LSA at > > > adj timeframe, > > > - being able to minimally update our grace-LSA as > > > topology changes, > > > - or we decide that we want to withdraw our grace-LSA > > > via MAXAGE, > > > > > > As of this time, I have not read in your document, > > > EXPLICITLY whether > > > - you suggest to ONLY send out the grace-LSA when you > > > have planned to do a restart (scheduled), > > > - how to withdraw the grace-LSAs from accepted helpers > > > when one proto-helper (to be helper), will not ack > > > your LSA, > > > - etc.. > > > > > > > > > Mitchell Erblich > > > Sr Software Engineer > > > ============================ > > > > > > > > > > > > > > > Acee Lindem wrote: > > > > > >>Erblichs wrote: > > >> > > >>>Padma, > > >>> > > >>> > > >>> These are my last comments!! > > >>> > > >>> Also inline... > > >>> > > >>> Why doesn't the draft RFC authors want to > > >>> allow non-scheduled restarts in this > > >>> draft? > > >> > > >>Michell, > > >> > > >>As Padma stated, the draft supports unscheduled restarts (there > > >>are multiple interoperable implementations). Your proposal to > > >>announce graceful restart in advance will unnecessarily delay > > >>the detection of a black hole if the restarting router is really dead > > >>or was abruptly decommissioned. The current draft doesn't suffer > > >>from this flaw. > > >> > > >> > > >>> Is there something wrong with the idea > > >>> of un-scheduled restarts? > > >>> > > >>> Why restrict it to only scheduled > > >>> restarts??? > > >>> > > >>> Why require > > >>> the grace-LSAs to be reflooded every > > >>> 30 minutes to 1 hr??? > > >>> > > >>> Why not send the grace-LSAs without > > >>> the Type=1, Length=4 grace period field?? > > >>> It will be determined by the helpers > > >>> anyway. > > >>> > > >>> The sentance is. > > >>> > > >>> "The number of seconds that the router's > > >>> neighbors should continue to advertise the > > >>> router as fully adjacent".... > > >>> > > >>> Thus, without the word "MUST", implimentations > > >>> will probably follow their own rules. Thus, the > > >>> grace period field really isn't needed and just > > >>> consumes bandwidth!!! > > >>> > > >>> > > >>> > > >>> Mitchell Erblich > > >>> =================== > > >>> > > >>> > > >>> > > >>> > > >>> > > >>>Padma Pillay-Esnault wrote: > > >>> > > >>> > > >>>>Mitchell, > > >>>> > > >>>>I'll try to address your comments > > >>>> > > >>>> > > >>>> > > >>>>>Acee Lindem, > > >>>>> > > >>>>> Since,, you skipped the inline re-comments, I will assume > > >>>>> that at least you read them.. :) > > >>>>> > > >>>>> I think I have expressed as best as I could (I am not > > >>>>> a tech writer) how I feel that this draft should evolve. > > >>>>> > > >>>>> So in summary... > > >>>>> > > >>>>>` 0) Remove the length (seconds) field from the grace-LSA. > > >>>>> > > >>>> > > >>>>This is using the TLV format .. so you want to keep the length > > >>> > > >>> > > >>> Of course, Type, Length, Value... Fine. Reword.. > > >>> Remove > > >>> the Grace-Period field of (Type =1, Length = 4). > > >>> Why transmit the field value????? > > >>> > > >>> > > >>>>> 1) Transmit DNA grace-LSAs at adj creation time. > > >>>>> > > >>>> > > >>>>This is not very useful. Today unless you have DNA lsa you cannot > > >>>>expect to be requesting a grace period of over one hour -- as > > >>>>all the LSA in the other routers database will expire at the > > >>>>most in 1hr. > > >>>>So if you decide to send a grace LSA it would be the most recent one > > >>>>that you built and hence if it has time to expire then the previous > > >>>>would already be gone. > > >>> > > >>> > > >>> Think ahead of tomarrow, not today... > > >>> How should this work in the utopian word? If the graceful > > >>> restart is a good idea, then it NOT should be used for ALL > > >>> possible restarts?? > > >>> > > >>> Why not restrict the amount of flooding with THESE types > > >>> of LSAs if this draft becomes a standard RFC?? > > >>> > > >>> What happens if I send the grace-LSAs at adj formation > > >>> time and then reflood them every 55 minutes?? This > > >>> removes the lightweight mechanism of the draft, but > > >>> still gets me unscheduled restart functionality? Maybe > > >>> i will just do that.. BTW, and also do unscheduled > > >>> restarts with my BGP protocol once it becomes a > > >>> standard. > > >>> > > >>> Thus, a restriction of 1 hr isn't sensible. Else, even if > > >>> I follow your logic, then why do I ask for 1 hr? Should > > >>> my implimentation in the helper not ack the grace-LSA if > > >>> the specified grace-period is over 1 hr from the restarting > > >>> router? This is unspecified behavior!!! > > >>> > > >>> > > >>> > > >>> > > >>>>> 2) Let the helpers determine amount of time that > > >>>>> they will function as a helper. Suggest a minimum > > >>>>> of 1 hr time. > > >>>>> > > >>>> > > >>>>This is a matter of policy .. even if the helper decides that > > >>>>he is not going to help for the whole period .. as he is not > > >>>>going to signal it to the restarting router .. I do not see > > >>>>the use of doing so. > > >>>> > > >>>> > > >>>> > > >>>>> 3) Reflood the DNA grace-LSAs anytime the contents > > >>>>> have changed. > > >>>>> > > >>>> > > >>>>See my response in 1. > > >>>> > > >>>> > > >>>> > > >>>>> 4) If the restart router expects to be down for a period > > >>>>> longer than X, then retransmit the Grace-LSAs as > > >>>>> MAXage LSAs. > > >>>>> > > >>>> > > >>>>I do not see the benefit or I am missing your point > > >>>> > > >>>>Padma > > >>>> > > >>>> > > >>>> > > >>>>> This would minimize bandwidth requirements and allow a > > >>>>> restarting router to have either scheduled or unscheduled > > >>>>> restarts. > > >>>>> > > >>>>> I don't know what else to add, except if you adopt one or > > >>>>> more of these suggestions, then please add my name to your > > >>>>> comment list. :) > > >>>>> > > >>>>> Mitchell Erblich > > >>>>> Sr Software Engineer > > >>>>> ============================ > > >>>>> > > >>>>> > > >>>>>Acee Lindem wrote: > > >>>>> > > >>>>> > > >>>>>>Erblichs wrote: > > >>>>>> > > >>>>>> > > >>>>>>>Acee Lindem, > > >>>>>>> > > >>>>>>> Sometimes my logic is a little obtuse.. > > >>>>>>> > > >>>>>>> Most of it is inline... > > >>>>>>> > > >>>>>>> I will first throw two new questions to you!!!! > > >>>>>>> > > >>>>>>> 1) Why don't you send out the Grace LSA at full > > >>>>>>> adj timeframe. It would take effect after > > >>>>>>> RouterDeadinterval has expired? > > >>>>>> > > >>>>>>How do you know, apriori, that the OSPF instance is > > >>>>>>restarting and not completely dead? > > >>>>> > > >>>>> Why do you care? As long as the topology isn't changing > > >>>>> then everything is ok. > > >>>>> > > >>>>> Wwhy not minimize the effects of unnecessary SPF computations? > > >>>>> > > >>>>> > > >>>>> > > >>>>>>> This would also take care of unscheduled restarts > > >>>>>>> and allow you to do an unscheduled graceful > > >>>>>>> restart!!!! > > >>>>>>> > > >>>>>>> You could also send them as DNA LSAs.. See inline. > > >>>>>>> > > >>>>>>> The only new twist is that if you then schedule > > >>>>>>> a restart, you may want to be able to cancel your > > >>>>>>> previous request or update the LSAs over time. > > >>>>>>> But if you conisder a stable topology, then why > > >>>>>>> NOT?? > > >>>>>>> > > >>>>>>> > > >>>>>>> 2) A) 2.1 3rd, paragraph.. > > >>>>>>> "Their age field set to 0," > > >>>>>>> Why can't you send DNA grace-LSAs???? > > >>>>>> > > >>>>>>You wouldn't gain anything since the grace interval cannot > > >>>>>>exceed the LSA refresh time. > > >>>>>> > > >>>>> > > >>>>> So, first why do you need to specify the grace-LSA > > >>>>> timeframe. Let it be implicitly known to be 1 hr! > > >>>>> > > >>>>> With DNA grace-LSAs, we > > >>>>> don't need to reflood them. If I sent them out > > >>>>> at adj creation time and the topology isn't > > >>>>> changing, then I don't need to consume > > >>>>> resources and keep on re-flooding them.. > > >>>>> > > >>>>> Thus, they can last multiple hours or longer.. > > >>>>> > > >>>>> > > >>>>> > > >>>>>>> B) 2.1, 4th paragraph. > > >>>>>>> > > >>>>>>> "it should retransmit... until > > >>>>>>> they are acknowledged". If you can't retransmit the > > >>>>>>> same LSA until 5 secs have passed, if a router > > >>>>>>> was congested, you may want to resubmit the grace-LSA > > >>>>>>> with a longer length timeframe to your helpers. I am > > >>>>>>> assuming just bump your instance. Correct? > > >>>>>> > > >>>>>>There are implementations that back off LSA retransmissions and the > > >>>>>>"Prioritized Treatment of Specific OSPF Packets and Congestion > > >>>>>>Avoidance" draft recommends this. However, this is not standard > > >>>>>>OSPF flooding as described in RFC2328 and it is an independent > > >>>>>>issue. > > >>>>>> > > >>>>> > > >>>>> No, no, you are missing my point. Until all of your grace-LSAs are > > >>>>> ack'ed, you can't continue successfully with a graceful-restart. > > >>>>> > > >>>>> This delay consumes time that you specified in your grace-LSA. Yea, > > >>>>> again, I don't know why you need to specify the amount of time!! > > >>>>> The timeframe that the helpers will help you can be set independently > > >>>>> and your spec doesn't allow them to communicate the amount of time > > >>>>> that they will keeep around a grace-LSA. > > >>>>> > > >>>>> Sorry, minor sidetrack. So, the time consumed to get the ack, actually > > >>>>> reduces the amount of time before the grace-LSA expires. > > >>>>> > > >>>>> > > >>>>>>> > > >>>>>>> Mitchell > > >>>>>>> ================ > > >>>>>>>Acee Lindem wrote: > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>>>Mitchell, > > >>>>>>>> > > >>>>>>>>See answers below. > > >>>>>>>> > > >>>>>>>>Erblichs wrote: > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>>Group, > > >>>>>>>>> > > >>>>>>>>> 1) Within 2.1 "Entering graceful restart", iff all > > >>>>>>>>> the LSAs were from DC specified NBRs with DNA > > >>>>>>>>> LSAs should the LS RefreshTime still be followed? > > >>>>>>>> > > >>>>>>>>LSA Refresh isn't relevant since the restarting router will > > >>>>>>>>reestablish adjacencies. > > >>>>>>> > > >>>>>>> > > >>>>>>> Then why have a suggestion of 1800 secs for LSReshTime > > >>>>>>> in your draft at the end of the 1st paragraph in section > > >>>>>>> 2.1? > > >>>>>>> > > >>>>>>> In my scenario, there would be no reason not to let the > > >>>>>>> value approach or exceed 3600 secs (1 hr). > > >>>>>>> > > >>>>>>> variation on a theme? Why not let the max value of your > > >>>>>>> grace-LSA length field allow the helper determine what > > >>>>>>> is the max that he will support? > > >>>>>>> -- what happens if you specify a value that is > > >>>>>>> greater than what the helper supports? > > >>>>>>> Ans A: The helper sees it as an invalid request > > >>>>>>> and throws away the whole request, > > >>>>>>> > > >>>>>>> OR > > >>>>>>> Ans B: The helper determines what the length he > > >>>>>>> will support? > > >>>>>>> > > >>>>>>> If it is B, then why have the length field. Just let > > >>>>>>> the helper decide how long to support the request? > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>>>> 2) Within 2.2 "When to exit graceful restart", number > > >>>>>>>>> (3) "The grace period expires". > > >>>>>>>>> > > >>>>>>>>> What happens if we follow #3 and your #1 "reestablished > > >>>>>>>>> all its adjacencies" criteria is not met? > > >>>>>>>> > > >>>>>>>>The restarting router will exit graceful restart anyway. > > >>>>>>> > > >>>>>>> > > >>>>>>> Why? If you still have a non-changing topology, why > > >>>>>>> limit the value to what you had said to the helpers? > > >>>>>>> > > >>>>>>> So, what if you asked for x time and it took you > > >>>>>>> x + y time? > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>>>> Or are you stating that the specified "grace period" was > > >>>>>>>>> to short to perform what was required? > > >>>>>>>> > > >>>>>>>>Not necessarily - perhaps the topology has changed and graceful restart > > >>>>>>>>cannot be completed successfully. > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>> 3) Within 2.2. Would seeing a hello without the graceful > > >>>>>>>>> restarting router id", force it to exit? > > >>>>>>>> > > >>>>>>>>No. The adjacency can go all the way down on the helper router. The hello > > >>>>>>>>shouldn't be used as a criteria for exiting helper mode. Do not confuse > > >>>>>>>>this with other graceful restart proposals. > > >>>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> I see that my question with the hello was answered in the > > >>>>>>> 2. (3) "an hello packet is received".. > > >>>>>>> > > >>>>>>> I am confused. One router may list you as the DR and another > > >>>>>>> may not? If one is a helper, then why would it take the adj > > >>>>>>> down if all the crieria were met? > > >>>>>>> > > >>>>>>> I thought that helpers > > >>>>>>> MUST send hellos as if you (graceful restarting router) were > > >>>>>>> still there!! > > >>>>>>> "an Hello packet is received from a neighbor listing the > > >>>>>>> router as the Designated Router". > > >>>>>>> > > >>>>>>> If it did keep anouncing you in the hellos (you weren't > > >>>>>>> the DR) and lets say that the DR went down. Could you > > >>>>>>> then be elected as the DR while you were still rebooting? > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>>>> 4) Within 2.2. Would seeing a hello without the graceful > > >>>>>>>>> restarting router id as the earlier DR or BDR, cause > > >>>>>>>>> it to exit, if it was a DR / BDR? > > >>>>>>>> > > >>>>>>>>Not directly, but an inconsistency with the pre-restart LSA will cause > > >>>>>>>>the restarting router to exist graceful restart prematurely. > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>> 5) Within 2.2. Is it implimentation dependent on how we > > >>>>>>>>> determine our existing nbrs and place their router ids > > >>>>>>>>> in a hello? > > >>>>>>>> > > >>>>>>>>This isn't changed for graceful restart. > > >>>>>>> > > >>>>>>> > > >>>>>>> I thought that you could save past nbr-ids in NVRAM > > >>>>>>> and then compare to existing hellos... > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>>>> 6) Within 2.2 (1), isn't adj establishment partly the > > >>>>>>>>> recieving of hellos, with your own router-id? Shouldn't > > >>>>>>>>> that inform others that we are back and to cancel > > >>>>>>>>> their helper graceful nbr timer? > > >>>>>>>>> > > >>>>>>>>> 7 & 8) Within 2.3 "Actions on exiting graceful restart". > > >>>>>>>>> > > >>>>>>>>> 7) Shouldn't the sending hellos be performed that > > >>>>>>>>> identify full adj be a criteria here? > > >>>>>>>> > > >>>>>>>>No. LSA convergence with the pre-restart LSAs is a much surer > > >>>>>>>>mechanism for determining the graceful restart can be exited. > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>> 8) I am unsure whether you are specifying the > > >>>>>>>>> storage of part of restarting router's LSDB into > > >>>>>>>>> non-volatile memory. If so, then upon retrieval, > > >>>>>>>>> shouldn't some elements of the LSDB be aged > > >>>>>>>>> by the amount that the actual amount of time > > >>>>>>>>> the LSAs were in NV memory? > > >>>>>>>> > > >>>>>>>>There is no mention of storing LSAs in non-volatile storage. > > >>>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> Ok, you aren't suggesting saving the LSDB in NVRAM > > >>>>>>> or some other type of storage media.. > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>>>> Mitchell Erblich > > >>>>>>>>> ================================== > > >>>>>>>>> > > >>>>>>>> > > >>>>>>>>-- > > >>>>>>>>Acee > > >>>>>>> > > >>>>>>> > > >>>>>>-- > > >>>>>>Acee > > >>>>> > > >>-- > > >>Acee > > > > > > > > > > -- > > Acee > From owner-ospf@DISCUSS.MICROSOFT.COM Sat Apr 12 06:43:44 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25248 for ; Sat, 12 Apr 2003 06:43:43 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00973845@cherry.ease.lsoft.com>; Sat, 12 Apr 2003 6:46:17 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 742828 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 12 Apr 2003 06:46:17 -0400 Received: from 61.135.128.152 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 12 Apr 2003 06:36:16 -0500 Received: from [218.0.199.169] by web15107.mail.bjs.yahoo.com via HTTP; Sat, 12 Apr 2003 18:36:11 CST MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1877808448-1050143771=:1149" Content-Transfer-Encoding: 8bit Message-ID: <20030412103611.1514.qmail@web15107.mail.bjs.yahoo.com> Date: Sat, 12 Apr 2003 18:36:11 +0800 Reply-To: Mailing List Sender: Mailing List From: =?gb2312?q?Jing=20Shen?= Subject: Re: route insertion into Forwarding table.. To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <1160.219.65.131.106.1050090703.squirrel@mail.apara.com> Precedence: list --0-1877808448-1050143771=:1149 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit >1. Incase a router "acks" this LSA and then enters a "graceful restart" without modifying the FT, what is the result? Maybe there will be transient loop during restart, but as routing daemon restarts routing table will be recomputed. >2. If there is a way to "ensure this convergence" shouldnt this >methodology be "documented" as a part of the draft?... or shouldnt it be >mentioned that the "gracefully restarting router" should "ensure this >convergence" before entring the "graceful restart"? But the problem is how could these LSAs be kept in a safe place? -rgds Alok Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, ZheJiang Province 310027 P.R.China --------------------------------- Do You Yahoo!? "ÑÅ»¢Í¨ÍøÂçKTV, ËæʱËæµØÃâ·Ñ¿¨À­OK~~" --0-1877808448-1050143771=:1149 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: 8bit


>1. Incase a router "acks" this LSA and then enters a "graceful restart"
without modifying the FT, what is the result?

Maybe there will be transient loop during restart, but as routing daemon restarts routing table will be recomputed.


>2. If there is a way to "ensure this convergence" shouldnt this
>methodology be "documented" as a part of the draft?... or shouldnt it be
>mentioned that the "gracefully restarting router" should "ensure this
>convergence" before entring the "graceful restart"?

But the problem is how could these LSAs be kept in a safe place?

-rgds
Alok



Jing Shen

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


Do You Yahoo!?
"ÑÅ»¢Í¨ÍøÂçKTV, ËæʱËæµØÃâ·Ñ¿¨À­OK~~" --0-1877808448-1050143771=:1149-- From owner-ospf@DISCUSS.MICROSOFT.COM Sat Apr 12 10:26:48 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28847 for ; Sat, 12 Apr 2003 10:26:47 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00973B57@cherry.ease.lsoft.com>; Sat, 12 Apr 2003 10:29:22 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 743029 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 12 Apr 2003 10:29:21 -0400 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 12 Apr 2003 10:29:21 -0500 Received: from mail.apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h3CF4QL32365 for ; Sat, 12 Apr 2003 20:34:26 +0530 Received: from apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with SMTP id h3CF4QX32359 for ; Sat, 12 Apr 2003 20:34:26 +0530 Received: from 219.65.149.158 (SquirrelMail authenticated user alok.dube) by mail.apara.com with HTTP; Sat, 12 Apr 2003 20:34:26 +0530 (IST) References: <1160.219.65.131.106.1050090703.squirrel@mail.apara.com> <20030412103611.1514.qmail@web15107.mail.bjs.yahoo.com> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by mail.apara.com id h3CF4QL32365 Message-ID: <1097.219.65.149.158.1050159866.squirrel@mail.apara.com> Date: Sat, 12 Apr 2003 20:34:26 +0530 Reply-To: Mailing List Sender: Mailing List From: Alok Dube Subject: Re: route insertion into Forwarding table.. To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20030412103611.1514.qmail@web15107.mail.bjs.yahoo.com> Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA28847 > > >>1. Incase a router "acks" this LSA and then enters a "graceful restart" > without modifying the FT, what is the result? > > Maybe there will be transient loop during restart, but as routing > daemon restarts routing table will be recomputed. but i could still enter a graceful restart or not? the draft says something in point 1 in 2.1 but I wasnt sure if this is what it meant...which is why the question. > > >>2. If there is a way to "ensure this convergence" shouldnt this >>methodology be "documented" as a part of the draft?... or shouldnt it >>be mentioned that the "gracefully restarting router" should "ensure >>this convergence" before entring the "graceful restart"? > > But the problem is how could these LSAs be kept in a safe place? There are LSAs which: 1. have been acked so the adjacent routers think everything is fine 2. have not been used to modify the FT (if required) or in other words, no SPF computation has been run on them.3. at this point a router enters a graceful restart. > > -rgds > Alok > > > Jing Shen > > State Key Lab of CAD&CG > ZheJiang University(YuQuan) > HangZhou, ZheJiang Province 310027 > P.R.China > > > --------------------------------- > Do You Yahoo!? > "ÑÅ»¢Í¨ÍøÂçKTV, ËæʱËæµØÃâ·Ñ¿¨À­OK~~" From owner-ospf@DISCUSS.MICROSOFT.COM Sun Apr 13 12:12:37 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01858 for ; Sun, 13 Apr 2003 12:12:37 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00975656@cherry.ease.lsoft.com>; 13 Apr 2003 12:15:13 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 745036 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 13 Apr 2003 12:15:13 -0400 Received: from 216.136.131.44 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 13 Apr 2003 12:15:12 -0500 Received: from [209.179.217.29] by web10908.mail.yahoo.com via HTTP; Sun, 13 Apr 2003 09:15:12 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20030413161512.92837.qmail@web10908.mail.yahoo.com> Date: Sun, 13 Apr 2003 09:15:12 -0700 Reply-To: Mailing List Sender: Mailing List From: j j Subject: Multiple un-numbered serial links between two routers To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Can OSPF support this? Seems like there isn't enough information in Router LSA to distinctly identify the interfaces for nexthop information. Or is this an invalid configuration on a router? thanks __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Sun Apr 13 17:46:27 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06236 for ; Sun, 13 Apr 2003 17:46: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.00975977@cherry.ease.lsoft.com>; 13 Apr 2003 17:49:01 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 745425 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 13 Apr 2003 17:48:59 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 13 Apr 2003 17:48:59 -0500 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 72F31231D0F for ; Sun, 13 Apr 2003 14:48:58 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <200304082356.h38NunH88489@garnet.juniper.net> <3E93755E.1937BC89@earthlink.net> <3E95061B.5060200@redback.com> <3E95BACC.E53FDC89@earthlink.net> <3E95BEDF.2010606@redback.com> <3E975E6E.73A22F08@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E99DAD2.9080507@redback.com> Date: Sun, 13 Apr 2003 17:46:58 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Draft : Graceful Restart : : grace period, etc To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Erblichs wrote: > Group, > > First of all I would want to apologize for continuing > this discussion thread! > > I realize that some implimentions may exist based on > this draft and what I am suggesting, may effect changes > to them. Mitchell, No apologies necessary for discussion of the draft. However, please make every attempt to read and understand it before suggesting substantive changes. > > In my past emails I have implicitly ignored the section > 5 within this draft of "Unplanned outages". I will now > explicitly state why I have ignored its suggested method. > > Why? > * " must originate grace-LSAs *after* its control > software resumes operation", we now lose our DR or > BDR status, if it had existed. The restarting router will succeed DR status if it was previously DR. See section 2 number 3. Also note section 5 for applicablility to unplanned restarts. Changes in BDR should have no effect on adjacencies or LSA contents. > > - This forces a SPF recomputation.. > - This can forces many full adj reformations. > - Removes the helper relationship with > respect to the restarting router > (monitoring, continues to (its) advertise its > LSAs, etc) NIT: remove the first "its". > - etc.. > > Thus this section invalidates many of the reasons > for the draft's existance. > > * If the draft's unplanned outages did not have these > negative effects and more, then anytime > 1 hr > graceful restart is planned, then this would be a > solid alternative. I just cannot see anyone > forwarding any pkts accross a non-adj, so even if > your forwarding table contents are sanitized, it > will be ignored. > > So, from may past information dump, the only true side effect > other than mentioned in the draft (clean flag for the forwarding > table should remove the table sanity issue) are the issues of the > reflooding bandwidth of early grace-LSAs, just in case the router > has an unplanned restart. And the extra work that is placed on > helper routers to "monitor" the network for topology changes, > and its other assigned helper duties. > > Thus, I believe that I have more than sufficiently identified > a graceful restart mechanism that removes the AFTER requirement > and allows the planned graceful restart method to be used in a > unplanned way. Plus, I agree that a knob/CLI command should be > used to enable or disable this type of feature. > > Mitchell Erblich > Sr Software Engineer > ---------------------- > > Acee Lindem wrote: > >>Erblichs wrote: >> >>>Acee, et al, >>> >>> I didn't really want to continue this thread >>> but I feel, I should restate some items here. :) >>> >>> >>> >>>>As Padma stated, the draft supports unscheduled restarts (there >>>>are multiple interoperable implementations). Your proposal to >>>>announce graceful restart in advance >>> >>> >>> >>> I don't see how one can send out grace-LSAs and possibly be >>> able to retransmit a grace-LSA OTHER than in advance, >>> AND still support unscheduled graceful restarts!!! >> >>Mitchell, >> >>In the case of unscheduled restart you may send the grace LSA a couple >>times but you don't want for an acknowledge (you don't necessarily know your >>neighbors since you are learning the state from the networks). >> >>I suggest you read or review section 5 of the draft. It covers all of your >>concerns below. >> >> >>> You must do it in advance, else it is scheduled.. >>> >>> My definition of unscheduled is that some event occurs and >>> the non-forwarding portion of the router is DOWN... No, >>> time for an sys admin to do anything... >>> >>> The ONLY possible way is to have trap level code call >>> the xmit grace-LSA code section. However, no time to >>> see if acks have been rec'vd and no time for a 5 sec >>> rexmit.... >>> >>> Ok, then WHAT is an UNSCHEDULED GRACEFUL RESTART in your >>> guys opinion???? >>> >>> On the assumption that if the router fails and >>> still abides by the condition that it is still >>> forwarding as if it was still up.., then >>> >>> As long as there isn't any topologoy changes >>> as stated within your document, that is one >>> reason to allow for a graceful restart, I don't >>> see the blackhole.. >>> >>> If the topology changes then it would invalidate >>> my graceful restart, as it would also invalidate >>> the graceful restart specified in the draft. >>> >>> The only deltas that I was asking for was: >>> - the issue of sending out a minimal grace-LSA at >>> adj timeframe, >>> - being able to minimally update our grace-LSA as >>> topology changes, >>> - or we decide that we want to withdraw our grace-LSA >>> via MAXAGE, >>> >>> As of this time, I have not read in your document, >>> EXPLICITLY whether >>> - you suggest to ONLY send out the grace-LSA when you >>> have planned to do a restart (scheduled), >>> - how to withdraw the grace-LSAs from accepted helpers >>> when one proto-helper (to be helper), will not ack >>> your LSA, >>> - etc.. >>> >>> >>> Mitchell Erblich >>> Sr Software Engineer >>> ============================ >>> >>> >>> >>> >>>Acee Lindem wrote: >>> >>> >>>>Erblichs wrote: >>>> >>>> >>>>>Padma, >>>>> >>>>> >>>>> These are my last comments!! >>>>> >>>>> Also inline... >>>>> >>>>> Why doesn't the draft RFC authors want to >>>>> allow non-scheduled restarts in this >>>>> draft? >>>> >>>>Michell, >>>> >>>>As Padma stated, the draft supports unscheduled restarts (there >>>>are multiple interoperable implementations). Your proposal to >>>>announce graceful restart in advance will unnecessarily delay >>>>the detection of a black hole if the restarting router is really dead >>>>or was abruptly decommissioned. The current draft doesn't suffer >>> >>>>from this flaw. >>> >>>> >>>>> Is there something wrong with the idea >>>>> of un-scheduled restarts? >>>>> >>>>> Why restrict it to only scheduled >>>>> restarts??? >>>>> >>>>> Why require >>>>> the grace-LSAs to be reflooded every >>>>> 30 minutes to 1 hr??? >>>>> >>>>> Why not send the grace-LSAs without >>>>> the Type=1, Length=4 grace period field?? >>>>> It will be determined by the helpers >>>>> anyway. >>>>> >>>>> The sentance is. >>>>> >>>>> "The number of seconds that the router's >>>>> neighbors should continue to advertise the >>>>> router as fully adjacent".... >>>>> >>>>> Thus, without the word "MUST", implimentations >>>>> will probably follow their own rules. Thus, the >>>>> grace period field really isn't needed and just >>>>> consumes bandwidth!!! >>>>> >>>>> >>>>> >>>>> Mitchell Erblich >>>>> =================== >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>Padma Pillay-Esnault wrote: >>>>> >>>>> >>>>> >>>>>>Mitchell, >>>>>> >>>>>>I'll try to address your comments >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Acee Lindem, >>>>>>> >>>>>>> Since,, you skipped the inline re-comments, I will assume >>>>>>> that at least you read them.. :) >>>>>>> >>>>>>> I think I have expressed as best as I could (I am not >>>>>>> a tech writer) how I feel that this draft should evolve. >>>>>>> >>>>>>> So in summary... >>>>>>> >>>>>>>` 0) Remove the length (seconds) field from the grace-LSA. >>>>>>> >>>>>> >>>>>>This is using the TLV format .. so you want to keep the length >>>>> >>>>> >>>>> Of course, Type, Length, Value... Fine. Reword.. >>>>> Remove >>>>> the Grace-Period field of (Type =1, Length = 4). >>>>> Why transmit the field value????? >>>>> >>>>> >>>>> >>>>>>> 1) Transmit DNA grace-LSAs at adj creation time. >>>>>>> >>>>>> >>>>>>This is not very useful. Today unless you have DNA lsa you cannot >>>>>>expect to be requesting a grace period of over one hour -- as >>>>>>all the LSA in the other routers database will expire at the >>>>>>most in 1hr. >>>>>>So if you decide to send a grace LSA it would be the most recent one >>>>>>that you built and hence if it has time to expire then the previous >>>>>>would already be gone. >>>>> >>>>> >>>>> Think ahead of tomarrow, not today... >>>>> How should this work in the utopian word? If the graceful >>>>> restart is a good idea, then it NOT should be used for ALL >>>>> possible restarts?? >>>>> >>>>> Why not restrict the amount of flooding with THESE types >>>>> of LSAs if this draft becomes a standard RFC?? >>>>> >>>>> What happens if I send the grace-LSAs at adj formation >>>>> time and then reflood them every 55 minutes?? This >>>>> removes the lightweight mechanism of the draft, but >>>>> still gets me unscheduled restart functionality? Maybe >>>>> i will just do that.. BTW, and also do unscheduled >>>>> restarts with my BGP protocol once it becomes a >>>>> standard. >>>>> >>>>> Thus, a restriction of 1 hr isn't sensible. Else, even if >>>>> I follow your logic, then why do I ask for 1 hr? Should >>>>> my implimentation in the helper not ack the grace-LSA if >>>>> the specified grace-period is over 1 hr from the restarting >>>>> router? This is unspecified behavior!!! >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>> 2) Let the helpers determine amount of time that >>>>>>> they will function as a helper. Suggest a minimum >>>>>>> of 1 hr time. >>>>>>> >>>>>> >>>>>>This is a matter of policy .. even if the helper decides that >>>>>>he is not going to help for the whole period .. as he is not >>>>>>going to signal it to the restarting router .. I do not see >>>>>>the use of doing so. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> 3) Reflood the DNA grace-LSAs anytime the contents >>>>>>> have changed. >>>>>>> >>>>>> >>>>>>See my response in 1. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> 4) If the restart router expects to be down for a period >>>>>>> longer than X, then retransmit the Grace-LSAs as >>>>>>> MAXage LSAs. >>>>>>> >>>>>> >>>>>>I do not see the benefit or I am missing your point >>>>>> >>>>>>Padma >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> This would minimize bandwidth requirements and allow a >>>>>>> restarting router to have either scheduled or unscheduled >>>>>>> restarts. >>>>>>> >>>>>>> I don't know what else to add, except if you adopt one or >>>>>>> more of these suggestions, then please add my name to your >>>>>>> comment list. :) >>>>>>> >>>>>>> Mitchell Erblich >>>>>>> Sr Software Engineer >>>>>>> ============================ >>>>>>> >>>>>>> >>>>>>>Acee Lindem wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Erblichs wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>Acee Lindem, >>>>>>>>> >>>>>>>>> Sometimes my logic is a little obtuse.. >>>>>>>>> >>>>>>>>> Most of it is inline... >>>>>>>>> >>>>>>>>> I will first throw two new questions to you!!!! >>>>>>>>> >>>>>>>>> 1) Why don't you send out the Grace LSA at full >>>>>>>>> adj timeframe. It would take effect after >>>>>>>>> RouterDeadinterval has expired? >>>>>>>> >>>>>>>>How do you know, apriori, that the OSPF instance is >>>>>>>>restarting and not completely dead? >>>>>>> >>>>>>> Why do you care? As long as the topology isn't changing >>>>>>> then everything is ok. >>>>>>> >>>>>>> Wwhy not minimize the effects of unnecessary SPF computations? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> This would also take care of unscheduled restarts >>>>>>>>> and allow you to do an unscheduled graceful >>>>>>>>> restart!!!! >>>>>>>>> >>>>>>>>> You could also send them as DNA LSAs.. See inline. >>>>>>>>> >>>>>>>>> The only new twist is that if you then schedule >>>>>>>>> a restart, you may want to be able to cancel your >>>>>>>>> previous request or update the LSAs over time. >>>>>>>>> But if you conisder a stable topology, then why >>>>>>>>> NOT?? >>>>>>>>> >>>>>>>>> >>>>>>>>> 2) A) 2.1 3rd, paragraph.. >>>>>>>>> "Their age field set to 0," >>>>>>>>> Why can't you send DNA grace-LSAs???? >>>>>>>> >>>>>>>>You wouldn't gain anything since the grace interval cannot >>>>>>>>exceed the LSA refresh time. >>>>>>>> >>>>>>> >>>>>>> So, first why do you need to specify the grace-LSA >>>>>>> timeframe. Let it be implicitly known to be 1 hr! >>>>>>> >>>>>>> With DNA grace-LSAs, we >>>>>>> don't need to reflood them. If I sent them out >>>>>>> at adj creation time and the topology isn't >>>>>>> changing, then I don't need to consume >>>>>>> resources and keep on re-flooding them.. >>>>>>> >>>>>>> Thus, they can last multiple hours or longer.. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> B) 2.1, 4th paragraph. >>>>>>>>> >>>>>>>>> "it should retransmit... until >>>>>>>>> they are acknowledged". If you can't retransmit the >>>>>>>>> same LSA until 5 secs have passed, if a router >>>>>>>>> was congested, you may want to resubmit the grace-LSA >>>>>>>>> with a longer length timeframe to your helpers. I am >>>>>>>>> assuming just bump your instance. Correct? >>>>>>>> >>>>>>>>There are implementations that back off LSA retransmissions and the >>>>>>>>"Prioritized Treatment of Specific OSPF Packets and Congestion >>>>>>>>Avoidance" draft recommends this. However, this is not standard >>>>>>>>OSPF flooding as described in RFC2328 and it is an independent >>>>>>>>issue. >>>>>>>> >>>>>>> >>>>>>> No, no, you are missing my point. Until all of your grace-LSAs are >>>>>>> ack'ed, you can't continue successfully with a graceful-restart. >>>>>>> >>>>>>> This delay consumes time that you specified in your grace-LSA. Yea, >>>>>>> again, I don't know why you need to specify the amount of time!! >>>>>>> The timeframe that the helpers will help you can be set independently >>>>>>> and your spec doesn't allow them to communicate the amount of time >>>>>>> that they will keeep around a grace-LSA. >>>>>>> >>>>>>> Sorry, minor sidetrack. So, the time consumed to get the ack, actually >>>>>>> reduces the amount of time before the grace-LSA expires. >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> Mitchell >>>>>>>>> ================ >>>>>>>>>Acee Lindem wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>Mitchell, >>>>>>>>>> >>>>>>>>>>See answers below. >>>>>>>>>> >>>>>>>>>>Erblichs wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>Group, >>>>>>>>>>> >>>>>>>>>>> 1) Within 2.1 "Entering graceful restart", iff all >>>>>>>>>>> the LSAs were from DC specified NBRs with DNA >>>>>>>>>>> LSAs should the LS RefreshTime still be followed? >>>>>>>>>> >>>>>>>>>>LSA Refresh isn't relevant since the restarting router will >>>>>>>>>>reestablish adjacencies. >>>>>>>>> >>>>>>>>> >>>>>>>>> Then why have a suggestion of 1800 secs for LSReshTime >>>>>>>>> in your draft at the end of the 1st paragraph in section >>>>>>>>> 2.1? >>>>>>>>> >>>>>>>>> In my scenario, there would be no reason not to let the >>>>>>>>> value approach or exceed 3600 secs (1 hr). >>>>>>>>> >>>>>>>>> variation on a theme? Why not let the max value of your >>>>>>>>> grace-LSA length field allow the helper determine what >>>>>>>>> is the max that he will support? >>>>>>>>> -- what happens if you specify a value that is >>>>>>>>> greater than what the helper supports? >>>>>>>>> Ans A: The helper sees it as an invalid request >>>>>>>>> and throws away the whole request, >>>>>>>>> >>>>>>>>> OR >>>>>>>>> Ans B: The helper determines what the length he >>>>>>>>> will support? >>>>>>>>> >>>>>>>>> If it is B, then why have the length field. Just let >>>>>>>>> the helper decide how long to support the request? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> 2) Within 2.2 "When to exit graceful restart", number >>>>>>>>>>> (3) "The grace period expires". >>>>>>>>>>> >>>>>>>>>>> What happens if we follow #3 and your #1 "reestablished >>>>>>>>>>> all its adjacencies" criteria is not met? >>>>>>>>>> >>>>>>>>>>The restarting router will exit graceful restart anyway. >>>>>>>>> >>>>>>>>> >>>>>>>>> Why? If you still have a non-changing topology, why >>>>>>>>> limit the value to what you had said to the helpers? >>>>>>>>> >>>>>>>>> So, what if you asked for x time and it took you >>>>>>>>> x + y time? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> Or are you stating that the specified "grace period" was >>>>>>>>>>> to short to perform what was required? >>>>>>>>>> >>>>>>>>>>Not necessarily - perhaps the topology has changed and graceful restart >>>>>>>>>>cannot be completed successfully. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> 3) Within 2.2. Would seeing a hello without the graceful >>>>>>>>>>> restarting router id", force it to exit? >>>>>>>>>> >>>>>>>>>>No. The adjacency can go all the way down on the helper router. The hello >>>>>>>>>>shouldn't be used as a criteria for exiting helper mode. Do not confuse >>>>>>>>>>this with other graceful restart proposals. >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I see that my question with the hello was answered in the >>>>>>>>> 2. (3) "an hello packet is received".. >>>>>>>>> >>>>>>>>> I am confused. One router may list you as the DR and another >>>>>>>>> may not? If one is a helper, then why would it take the adj >>>>>>>>> down if all the crieria were met? >>>>>>>>> >>>>>>>>> I thought that helpers >>>>>>>>> MUST send hellos as if you (graceful restarting router) were >>>>>>>>> still there!! >>>>>>>>> "an Hello packet is received from a neighbor listing the >>>>>>>>> router as the Designated Router". >>>>>>>>> >>>>>>>>> If it did keep anouncing you in the hellos (you weren't >>>>>>>>> the DR) and lets say that the DR went down. Could you >>>>>>>>> then be elected as the DR while you were still rebooting? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> 4) Within 2.2. Would seeing a hello without the graceful >>>>>>>>>>> restarting router id as the earlier DR or BDR, cause >>>>>>>>>>> it to exit, if it was a DR / BDR? >>>>>>>>>> >>>>>>>>>>Not directly, but an inconsistency with the pre-restart LSA will cause >>>>>>>>>>the restarting router to exist graceful restart prematurely. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> 5) Within 2.2. Is it implimentation dependent on how we >>>>>>>>>>> determine our existing nbrs and place their router ids >>>>>>>>>>> in a hello? >>>>>>>>>> >>>>>>>>>>This isn't changed for graceful restart. >>>>>>>>> >>>>>>>>> >>>>>>>>> I thought that you could save past nbr-ids in NVRAM >>>>>>>>> and then compare to existing hellos... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> 6) Within 2.2 (1), isn't adj establishment partly the >>>>>>>>>>> recieving of hellos, with your own router-id? Shouldn't >>>>>>>>>>> that inform others that we are back and to cancel >>>>>>>>>>> their helper graceful nbr timer? >>>>>>>>>>> >>>>>>>>>>> 7 & 8) Within 2.3 "Actions on exiting graceful restart". >>>>>>>>>>> >>>>>>>>>>> 7) Shouldn't the sending hellos be performed that >>>>>>>>>>> identify full adj be a criteria here? >>>>>>>>>> >>>>>>>>>>No. LSA convergence with the pre-restart LSAs is a much surer >>>>>>>>>>mechanism for determining the graceful restart can be exited. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> 8) I am unsure whether you are specifying the >>>>>>>>>>> storage of part of restarting router's LSDB into >>>>>>>>>>> non-volatile memory. If so, then upon retrieval, >>>>>>>>>>> shouldn't some elements of the LSDB be aged >>>>>>>>>>> by the amount that the actual amount of time >>>>>>>>>>> the LSAs were in NV memory? >>>>>>>>>> >>>>>>>>>>There is no mention of storing LSAs in non-volatile storage. >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Ok, you aren't suggesting saving the LSDB in NVRAM >>>>>>>>> or some other type of storage media.. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> Mitchell Erblich >>>>>>>>>>> ================================== >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>-- >>>>>>>>>>Acee >>>>>>>>> >>>>>>>>> >>>>>>>>-- >>>>>>>>Acee >>>>>>> >>>>-- >>>>Acee >>> >>> >>-- >>Acee > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon Apr 14 11:41:47 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09762 for ; Mon, 14 Apr 2003 11:41:47 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00977624@cherry.ease.lsoft.com>; Mon, 14 Apr 2003 11:44:23 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 747659 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 14 Apr 2003 11:44:23 -0400 Received: from 193.70.192.127 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 14 Apr 2003 11:44:23 -0500 Received: from libero.it (193.70.192.42) by smtp3.libero.it (6.7.015) id 3E68E8E300326AFB for OSPF@DISCUSS.MICROSOFT.COM; Mon, 14 Apr 2003 17:44:22 +0200 MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 X-XaM3-API-Version: 3.2 R29 (B54 pl1) X-type: 0 X-SenderIP: 81.73.170.22 Message-ID: Date: Mon, 14 Apr 2003 17:44:22 +0200 Reply-To: Mailing List Sender: Mailing List From: "=?iso-8859-1?Q?john151@libero.it?=" Subject: =?iso-8859-1?Q?Changing_router_name...?= To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA09762 Hi all, i'd like to make you a question: what problems could be in a network in which there is a router changing its name? I am thinking to a MPLS-TE scenario in which there are RSVP and OSPF and in which i use Explicit Route Objects for Traffic Engineering. Since in OSPF the name of each router is the address of the highest interface, is it possible that this particular interface goes down? In a router (for example CISCO, JUNIPER, ecc...) could it happen? If that particular interface (for example x.y.33.1 ) goes down and/or the operating system of the router eliminates it, after some hellos, we have the generation of LSA Update, so all network will know there is a NEW router in the net (for example x.y.22.1)! What can it happen to the LSPs crossing that router and not interested by the interface's failure? Infact, we have one ERO (explicit route object) for each LSP crossing the router; in each ERO of the LSPs not interested by the failure, we have x.y.33.1; after four hellos, the router x.y.33.1 will not exist more in the net! In the same way if i establish new LSPs, they will have the ERO containing x.y.22.1, so if the interface becomes active after a certain period, the router will return to the name x.y.33.1 and we' l have the same problem. Thanks in advance for your kind answers and observations. Giovanni Coritel - Rome From owner-ospf@DISCUSS.MICROSOFT.COM Mon Apr 14 12:40:18 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11364 for ; Mon, 14 Apr 2003 12:40:17 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00977857@cherry.ease.lsoft.com>; Mon, 14 Apr 2003 12:42:55 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 747954 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 14 Apr 2003 12:42:54 -0400 Received: from 193.70.192.51 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 14 Apr 2003 12:42:54 -0500 Received: from libero.it (193.70.192.47) by smtp1.libero.it (7.0.012) id 3E9546800005F7C5 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 14 Apr 2003 18:42:54 +0200 MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 X-XaM3-API-Version: 3.2 R29 (B54 pl1) X-type: 0 X-SenderIP: 81.73.170.22 Message-ID: Date: Mon, 14 Apr 2003 18:42:53 +0200 Reply-To: Mailing List Sender: Mailing List From: "=?iso-8859-1?Q?john151@libero.it?=" Subject: =?iso-8859-1?Q?Re:_Changing_router_name..._?= To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA11364 Hi Alok, hi all, >it would be router-id yes i intended router-id: router-id is the number of the highest interface on a router, isn' t it? >in general you would make loopback as router-id (i think) NO >>i'd like to make you a question: >>what problems could be in a network in which there is >>a router changing its name? I am thinking to a MPLS-TE >>scenario in which there are RSVP and OSPF and in which i >>use Explicit Route Objects for Traffic Engineering. >>Since in OSPF the name of each router is the address of the highest >>interface, is it possible that this particular interface goes down? >>In a router (for example CISCO, JUNIPER, ecc...) could it happen? >>If that particular interface (for example x.y.33.1 ) goes down and/or >>the operating system of the router eliminates it, after some hellos, >>we have the generation of LSA Update, so all network will know there >>is a NEW router in the net (for example x.y.22.1)! What can it happen >>to the LSPs crossing that router and not interested by the interface's failure? >>Infact, we have one ERO (explicit route object) for each LSP crossing >>the router; in each ERO of the LSPs not interested by the failure, >>we have x.y.33.1; after four hellos, the router x.y.33.1 will not exist >>more in the net! In the same way if i establish new LSPs, >>they will have the ERO containing x.y.22.1, so if the interface becomes >>active after a certain period, the router will return to the name x.y.33.1 >>and we' l have the same problem. Thanks in advance for your kind answers and observations. Giovanni Coritel - Rome From owner-ospf@DISCUSS.MICROSOFT.COM Mon Apr 14 13:14:03 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12647 for ; Mon, 14 Apr 2003 13:14:03 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.009776AD@cherry.ease.lsoft.com>; Mon, 14 Apr 2003 13:16:39 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 748095 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 14 Apr 2003 13:16:38 -0400 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 14 Apr 2003 13:16:38 -0500 Received: from mail.apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h3EHqVJ02865 for ; Mon, 14 Apr 2003 23:22:31 +0530 Received: from alok ([203.124.140.101]) (authenticated) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h3EHqS302859 for ; Mon, 14 Apr 2003 23:22:29 +0530 References: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: <029601c302aa$05beebc0$81c802c0@alok> Date: Mon, 14 Apr 2003 22:49:25 +0530 Reply-To: Mailing List Sender: Mailing List From: alok Subject: Re: Changing router name... To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list ----- Original Message ----- From: john151@libero.it To: Sent: Monday, April 14, 2003 10:12 PM Subject: Re: Changing router name... > Hi Alok, hi all, > > >it would be router-id > yes i intended router-id: router-id is the number of the > highest interface on a router, isn' t it? > > >in general you would make loopback as router-id (i think) > NO why not? From owner-ospf@DISCUSS.MICROSOFT.COM Mon Apr 14 14:15:43 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15058 for ; Mon, 14 Apr 2003 14:15:43 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00977A36@cherry.ease.lsoft.com>; Mon, 14 Apr 2003 14:18:19 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 748285 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 14 Apr 2003 14:18:18 -0400 Received: from 207.217.120.50 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 14 Apr 2003 14:18:18 -0500 Received: from user-2ivfnje.dialup.mindspring.com ([165.247.222.110] helo=earthlink.net) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1958Ws-0002lz-00 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 14 Apr 2003 11:18:08 -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: <029601c302aa$05beebc0$81c802c0@alok> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E9AF59A.EDDEA082@earthlink.net> Date: Mon, 14 Apr 2003 10:53:30 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Changing router name... To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, If you would be running two or more OSPF processes within your router, do you still want them both to use the highest interface or both use the loopback interface as the router-id? Mitchell Erblich Sr . Software Engineer ---------------------------- alok wrote: > > ----- Original Message ----- > From: john151@libero.it > To: > Sent: Monday, April 14, 2003 10:12 PM > Subject: Re: Changing router name... > > > Hi Alok, hi all, > > > > >it would be router-id > > yes i intended router-id: router-id is the number of the > > highest interface on a router, isn' t it? > > > > >in general you would make loopback as router-id (i think) > > NO > > why not? From owner-ospf@DISCUSS.MICROSOFT.COM Mon Apr 14 14:31:20 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15425 for ; Mon, 14 Apr 2003 14:31:19 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00977A6F@cherry.ease.lsoft.com>; Mon, 14 Apr 2003 14:33:55 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 748332 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 14 Apr 2003 14:33:54 -0400 Received: from 65.174.124.37 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 14 Apr 2003 14:23:54 -0500 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 20E0634437 for ; Mon, 14 Apr 2003 10:37:38 -0700 (PDT) Received: from redd4131.procket.com (IDENT:root@redd4131.procket.com [10.1.4.131]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h3EINsYB019865 for ; Mon, 14 Apr 2003 11:23:54 -0700 (PDT) Received: from Procket.com (IDENT:swhyte@localhost.localdomain [127.0.0.1]) by redd4131.procket.com (8.12.1/8.12.1) with ESMTP id h3EINsXi006729 for ; Mon, 14 Apr 2003 11:23:54 -0700 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <029601c302aa$05beebc0$81c802c0@alok> <3E9AF59A.EDDEA082@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E9AFCBA.7080904@Procket.com> Date: Mon, 14 Apr 2003 11:23:54 -0700 Reply-To: Mailing List Sender: Mailing List From: Scott Whyte Organization: Procket Networks Subject: Re: Changing router name... To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Erblichs wrote: > Group, > > If you would be running two or more OSPF > processes within your router, do you > still want them both to use the highest > interface or both use the loopback interface > as the router-id? I would prefer a loopback per process. -Scott > > Mitchell Erblich > Sr . Software Engineer > ---------------------------- > > alok wrote: > >>----- Original Message ----- >>From: john151@libero.it >>To: >>Sent: Monday, April 14, 2003 10:12 PM >>Subject: Re: Changing router name... >> >> >>>Hi Alok, hi all, >>> >>> >>>>it would be router-id >>> >>>yes i intended router-id: router-id is the number of the >>>highest interface on a router, isn' t it? >>> >>> >>>>in general you would make loopback as router-id (i think) >>> >>>NO >> >>why not? > From owner-ospf@DISCUSS.MICROSOFT.COM Mon Apr 14 14:34:51 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15495 for ; Mon, 14 Apr 2003 14:34:51 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00977A10@cherry.ease.lsoft.com>; Mon, 14 Apr 2003 14:37:28 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 748384 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 14 Apr 2003 14:37:27 -0400 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 14 Apr 2003 14:37:27 -0500 Received: from mail.apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h3EJDKJ03492 for ; Tue, 15 Apr 2003 00:43:20 +0530 Received: from apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with SMTP id h3EJDK303486 for ; Tue, 15 Apr 2003 00:43:20 +0530 Received: from 219.65.135.92 (SquirrelMail authenticated user alok.dube) by mail.apara.com with HTTP; Tue, 15 Apr 2003 00:43:20 +0530 (IST) References: <029601c302aa$05beebc0$81c802c0@alok> <3E9AF59A.EDDEA082@earthlink.net> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <1376.219.65.135.92.1050347600.squirrel@mail.apara.com> Date: Tue, 15 Apr 2003 00:43:20 +0530 Reply-To: Mailing List Sender: Mailing List From: Alok Dube Subject: Re: Changing router name... To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E9AF59A.EDDEA082@earthlink.net> Precedence: list Content-Transfer-Encoding: 8bit multiple loopbacks...at least 1 per vrf. "preferably" (thats my preference as i anyways get a /32 for router-id, why introduce a lo0/32 too to make it reachable via tha OSPF process?) each loopback being the "router-id" for that ospf-process? (presuming ospf process are dosjoint sets / 2 seperate OSPF instances not releated to one another).... > Group, > > If you would be running two or more OSPF > processes within your router, do you > still want them both to use the highest > interface or both use the loopback interface > as the router-id? > > Mitchell Erblich > Sr . Software Engineer > ---------------------------- > > alok wrote: >> >> ----- Original Message ----- >> From: john151@libero.it >> To: >> Sent: Monday, April 14, 2003 10:12 PM >> Subject: Re: Changing router name... >> >> > Hi Alok, hi all, >> > >> > >it would be router-id >> > yes i intended router-id: router-id is the number of the >> > highest interface on a router, isn' t it? >> > >> > >in general you would make loopback as router-id (i think) >> > NO >> >> why not? From owner-ospf@DISCUSS.MICROSOFT.COM Mon Apr 14 14:51:24 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16076 for ; Mon, 14 Apr 2003 14:51: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.00977BDC@cherry.ease.lsoft.com>; Mon, 14 Apr 2003 14:53:59 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 748432 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 14 Apr 2003 14:53:58 -0400 Received: from 65.174.124.36 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 14 Apr 2003 14:53:58 -0500 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id B757723C47 for ; Mon, 14 Apr 2003 11:43:20 -0700 (PDT) Received: from redd4131.procket.com (IDENT:root@redd4131.procket.com [10.1.4.131]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h3EIrwYB021465 for ; Mon, 14 Apr 2003 11:53:58 -0700 (PDT) Received: from Procket.com (IDENT:swhyte@localhost.localdomain [127.0.0.1]) by redd4131.procket.com (8.12.1/8.12.1) with ESMTP id h3EIrwXi006824 for ; Mon, 14 Apr 2003 11:53:58 -0700 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <029601c302aa$05beebc0$81c802c0@alok> <3E9AF59A.EDDEA082@earthlink.net> <1376.219.65.135.92.1050347600.squirrel@mail.apara.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E9B03C6.8060304@Procket.com> Date: Mon, 14 Apr 2003 11:53:58 -0700 Reply-To: Mailing List Sender: Mailing List From: Scott Whyte Organization: Procket Networks Subject: Re: Changing router name... To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Alok Dube wrote: > multiple loopbacks...at least 1 per vrf. Why? Do you put multiple VRFs into a single OSPF process? -Scott > > "preferably" (thats my preference as i anyways get a /32 for router-id, > why introduce a lo0/32 too to make it reachable via tha OSPF process?) > each loopback being the "router-id" for that ospf-process? (presuming ospf > process are dosjoint sets / 2 seperate OSPF instances not releated to one > another).... > >>Group, >> >> If you would be running two or more OSPF >> processes within your router, do you >> still want them both to use the highest >> interface or both use the loopback interface >> as the router-id? >> >> Mitchell Erblich >> Sr . Software Engineer >> ---------------------------- >> >>alok wrote: >> >>>----- Original Message ----- >>>From: john151@libero.it >>>To: >>>Sent: Monday, April 14, 2003 10:12 PM >>>Subject: Re: Changing router name... >>> >>> >>>>Hi Alok, hi all, >>>> >>>> >>>>>it would be router-id >>>> >>>>yes i intended router-id: router-id is the number of the >>>>highest interface on a router, isn' t it? >>>> >>>> >>>>>in general you would make loopback as router-id (i think) >>>> >>>>NO >>> >>>why not? >> From owner-ospf@DISCUSS.MICROSOFT.COM Mon Apr 14 14:56:16 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16300 for ; Mon, 14 Apr 2003 14:56:16 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00977B73@cherry.ease.lsoft.com>; Mon, 14 Apr 2003 14:58:51 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 748458 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 14 Apr 2003 14:58:50 -0400 Received: from 64.106.140.220 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 14 Apr 2003 14:58:50 -0500 Received: from mail.apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h3EJYiJ03713 for ; Tue, 15 Apr 2003 01:04:44 +0530 Received: from apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with SMTP id h3EJYi303707 for ; Tue, 15 Apr 2003 01:04:44 +0530 Received: from 219.65.135.92 (SquirrelMail authenticated user alok.dube) by mail.apara.com with HTTP; Tue, 15 Apr 2003 01:04:44 +0530 (IST) References: <029601c302aa$05beebc0$81c802c0@alok> <3E9AF59A.EDDEA082@earthlink.net> <1376.219.65.135.92.1050347600.squirrel@mail.apara.com> <3E9B03C6.8060304@Procket.com> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <1488.219.65.135.92.1050348884.squirrel@mail.apara.com> Date: Tue, 15 Apr 2003 01:04:44 +0530 Reply-To: Mailing List Sender: Mailing List From: Alok Dube Subject: Re: Changing router name... To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E9B03C6.8060304@Procket.com> Precedence: list Content-Transfer-Encoding: 8bit > Alok Dube wrote: >> multiple loopbacks...at least 1 per vrf. > > Why? Do you put multiple VRFs into a single OSPF process? > Hi, no i dont, i could have a loopback interface per process... think i missed your point.... i meant 1 loopback per vrf atleast... (that actually came to me from BGP presuming i was running BGP with the CE and it wasnt 1 hop away)..but yes, same applies for OSPF, the interface is never down and you could have multiple unnumbered P2Ps on it... From owner-ospf@DISCUSS.MICROSOFT.COM Mon Apr 14 16:22:40 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20466 for ; Mon, 14 Apr 2003 16:22:38 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00977E42@cherry.ease.lsoft.com>; Mon, 14 Apr 2003 16:25:02 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 748767 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 14 Apr 2003 16:25:02 -0400 Received: from 207.217.120.48 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 14 Apr 2003 16:25:01 -0500 Received: from user-38lc085.dialup.mindspring.com ([209.86.1.5] helo=earthlink.net) by mallard.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 195AVd-0002kK-00 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 14 Apr 2003 13:24:57 -0700 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <200304120500.h3C504u90560@garnet.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E9B12B7.5FF0E3D1@earthlink.net> Date: Mon, 14 Apr 2003 12:57:43 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Draft : Graceful Restart : : grace period, etc To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Padma, Inline comment. Mitchell Erblich --------------------- Padma Pillay-Esnault wrote: > > > > > Group, > > > > First of all I would want to apologize for continuing > > this discussion thread! > > > > I realize that some implimentions may exist based on > > this draft and what I am suggesting, may effect changes > > to them. > > > > In my past emails I have implicitly ignored the section > > 5 within this draft of "Unplanned outages". I will now > > explicitly state why I have ignored its suggested method. > > > > Why? > > * " must originate grace-LSAs *after* its control > > software resumes operation", we now lose our DR or > > BDR status, if it had existed. > > > > - This forces a SPF recomputation.. > > What makes you think that it forces a SPF computation ? > If I read/interpreted the section 5 correctly.. Then, "*after*" section imples xmiting no LSAs prior to shutdown. With this assumption, during the downtime of the router, all the adjs will timeout. No helpers will be requested before shutdown. Due to this fact the SPF computation interval will probably expire which will result in a SPF computation. Mitchell Erblich > Padma > > > - This can forces many full adj reformations. > > - Removes the helper relationship with > > respect to the restarting router > > (monitoring, continues to (its) advertise its > > LSAs, etc) NIT: remove the first "its". > > - etc.. > > > > Thus this section invalidates many of the reasons > > for the draft's existance. > > > > * If the draft's unplanned outages did not have these > > negative effects and more, then anytime > 1 hr > > graceful restart is planned, then this would be a > > solid alternative. I just cannot see anyone > > forwarding any pkts accross a non-adj, so even if > > your forwarding table contents are sanitized, it > > will be ignored. > > > > So, from may past information dump, the only true side effect > > other than mentioned in the draft (clean flag for the forwarding > > table should remove the table sanity issue) are the issues of the > > reflooding bandwidth of early grace-LSAs, just in case the router > > has an unplanned restart. And the extra work that is placed on > > helper routers to "monitor" the network for topology changes, > > and its other assigned helper duties. > > > > Thus, I believe that I have more than sufficiently identified > > a graceful restart mechanism that removes the AFTER requirement > > and allows the planned graceful restart method to be used in a > > unplanned way. Plus, I agree that a knob/CLI command should be > > used to enable or disable this type of feature. > > > > Mitchell Erblich > > Sr Software Engineer > > ---------------------- > > > > Acee Lindem wrote: > > > > > > Erblichs wrote: > > > > Acee, et al, > > > > > > > > I didn't really want to continue this thread > > > > but I feel, I should restate some items here. :) > > > > > > > > > > > >>As Padma stated, the draft supports unscheduled restarts (there > > > >>are multiple interoperable implementations). Your proposal to > > > >>announce graceful restart in advance > > > > > > > > > > > > > > > > I don't see how one can send out grace-LSAs and possibly be > > > > able to retransmit a grace-LSA OTHER than in advance, > > > > AND still support unscheduled graceful restarts!!! > > > > > > Mitchell, > > > > > > In the case of unscheduled restart you may send the grace LSA a couple > > > times but you don't want for an acknowledge (you don't necessarily know your > > > neighbors since you are learning the state from the networks). > > > > > > I suggest you read or review section 5 of the draft. It covers all of your > > > concerns below. > > > > > > > > > > > You must do it in advance, else it is scheduled.. > > > > > > > > My definition of unscheduled is that some event occurs and > > > > the non-forwarding portion of the router is DOWN... No, > > > > time for an sys admin to do anything... > > > > > > > > The ONLY possible way is to have trap level code call > > > > the xmit grace-LSA code section. However, no time to > > > > see if acks have been rec'vd and no time for a 5 sec > > > > rexmit.... > > > > > > > > Ok, then WHAT is an UNSCHEDULED GRACEFUL RESTART in your > > > > guys opinion???? > > > > > > > > On the assumption that if the router fails and > > > > still abides by the condition that it is still > > > > forwarding as if it was still up.., then > > > > > > > > As long as there isn't any topologoy changes > > > > as stated within your document, that is one > > > > reason to allow for a graceful restart, I don't > > > > see the blackhole.. > > > > > > > > If the topology changes then it would invalidate > > > > my graceful restart, as it would also invalidate > > > > the graceful restart specified in the draft. > > > > > > > > The only deltas that I was asking for was: > > > > - the issue of sending out a minimal grace-LSA at > > > > adj timeframe, > > > > - being able to minimally update our grace-LSA as > > > > topology changes, > > > > - or we decide that we want to withdraw our grace-LSA > > > > via MAXAGE, > > > > > > > > As of this time, I have not read in your document, > > > > EXPLICITLY whether > > > > - you suggest to ONLY send out the grace-LSA when you > > > > have planned to do a restart (scheduled), > > > > - how to withdraw the grace-LSAs from accepted helpers > > > > when one proto-helper (to be helper), will not ack > > > > your LSA, > > > > - etc.. > > > > > > > > > > > > Mitchell Erblich > > > > Sr Software Engineer > > > > ============================ > > > > > > > > > > > > > > > > > > > > Acee Lindem wrote: > > > > > > > >>Erblichs wrote: > > > >> > > > >>>Padma, > > > >>> > > > >>> > > > >>> These are my last comments!! > > > >>> > > > >>> Also inline... > > > >>> > > > >>> Why doesn't the draft RFC authors want to > > > >>> allow non-scheduled restarts in this > > > >>> draft? > > > >> > > > >>Michell, > > > >> > > > >>As Padma stated, the draft supports unscheduled restarts (there > > > >>are multiple interoperable implementations). Your proposal to > > > >>announce graceful restart in advance will unnecessarily delay > > > >>the detection of a black hole if the restarting router is really dead > > > >>or was abruptly decommissioned. The current draft doesn't suffer > > > >>from this flaw. > > > >> > > > >> > > > >>> Is there something wrong with the idea > > > >>> of un-scheduled restarts? > > > >>> > > > >>> Why restrict it to only scheduled > > > >>> restarts??? > > > >>> > > > >>> Why require > > > >>> the grace-LSAs to be reflooded every > > > >>> 30 minutes to 1 hr??? > > > >>> > > > >>> Why not send the grace-LSAs without > > > >>> the Type=1, Length=4 grace period field?? > > > >>> It will be determined by the helpers > > > >>> anyway. > > > >>> > > > >>> The sentance is. > > > >>> > > > >>> "The number of seconds that the router's > > > >>> neighbors should continue to advertise the > > > >>> router as fully adjacent".... > > > >>> > > > >>> Thus, without the word "MUST", implimentations > > > >>> will probably follow their own rules. Thus, the > > > >>> grace period field really isn't needed and just > > > >>> consumes bandwidth!!! > > > >>> > > > >>> > > > >>> > > > >>> Mitchell Erblich > > > >>> =================== > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>>Padma Pillay-Esnault wrote: > > > >>> > > > >>> > > > >>>>Mitchell, > > > >>>> > > > >>>>I'll try to address your comments > > > >>>> > > > >>>> > > > >>>> > > > >>>>>Acee Lindem, > > > >>>>> > > > >>>>> Since,, you skipped the inline re-comments, I will assume > > > >>>>> that at least you read them.. :) > > > >>>>> > > > >>>>> I think I have expressed as best as I could (I am not > > > >>>>> a tech writer) how I feel that this draft should evolve. > > > >>>>> > > > >>>>> So in summary... > > > >>>>> > > > >>>>>` 0) Remove the length (seconds) field from the grace-LSA. > > > >>>>> > > > >>>> > > > >>>>This is using the TLV format .. so you want to keep the length > > > >>> > > > >>> > > > >>> Of course, Type, Length, Value... Fine. Reword.. > > > >>> Remove > > > >>> the Grace-Period field of (Type =1, Length = 4). > > > >>> Why transmit the field value????? > > > >>> > > > >>> > > > >>>>> 1) Transmit DNA grace-LSAs at adj creation time. > > > >>>>> > > > >>>> > > > >>>>This is not very useful. Today unless you have DNA lsa you cannot > > > >>>>expect to be requesting a grace period of over one hour -- as > > > >>>>all the LSA in the other routers database will expire at the > > > >>>>most in 1hr. > > > >>>>So if you decide to send a grace LSA it would be the most recent one > > > >>>>that you built and hence if it has time to expire then the previous > > > >>>>would already be gone. > > > >>> > > > >>> > > > >>> Think ahead of tomarrow, not today... > > > >>> How should this work in the utopian word? If the graceful > > > >>> restart is a good idea, then it NOT should be used for ALL > > > >>> possible restarts?? > > > >>> > > > >>> Why not restrict the amount of flooding with THESE types > > > >>> of LSAs if this draft becomes a standard RFC?? > > > >>> > > > >>> What happens if I send the grace-LSAs at adj formation > > > >>> time and then reflood them every 55 minutes?? This > > > >>> removes the lightweight mechanism of the draft, but > > > >>> still gets me unscheduled restart functionality? Maybe > > > >>> i will just do that.. BTW, and also do unscheduled > > > >>> restarts with my BGP protocol once it becomes a > > > >>> standard. > > > >>> > > > >>> Thus, a restriction of 1 hr isn't sensible. Else, even if > > > >>> I follow your logic, then why do I ask for 1 hr? Should > > > >>> my implimentation in the helper not ack the grace-LSA if > > > >>> the specified grace-period is over 1 hr from the restarting > > > >>> router? This is unspecified behavior!!! > > > >>> > > > >>> > > > >>> > > > >>> > > > >>>>> 2) Let the helpers determine amount of time that > > > >>>>> they will function as a helper. Suggest a minimum > > > >>>>> of 1 hr time. > > > >>>>> > > > >>>> > > > >>>>This is a matter of policy .. even if the helper decides that > > > >>>>he is not going to help for the whole period .. as he is not > > > >>>>going to signal it to the restarting router .. I do not see > > > >>>>the use of doing so. > > > >>>> > > > >>>> > > > >>>> > > > >>>>> 3) Reflood the DNA grace-LSAs anytime the contents > > > >>>>> have changed. > > > >>>>> > > > >>>> > > > >>>>See my response in 1. > > > >>>> > > > >>>> > > > >>>> > > > >>>>> 4) If the restart router expects to be down for a period > > > >>>>> longer than X, then retransmit the Grace-LSAs as > > > >>>>> MAXage LSAs. > > > >>>>> > > > >>>> > > > >>>>I do not see the benefit or I am missing your point > > > >>>> > > > >>>>Padma > > > >>>> > > > >>>> > > > >>>> > > > >>>>> This would minimize bandwidth requirements and allow a > > > >>>>> restarting router to have either scheduled or unscheduled > > > >>>>> restarts. > > > >>>>> > > > >>>>> I don't know what else to add, except if you adopt one or > > > >>>>> more of these suggestions, then please add my name to your > > > >>>>> comment list. :) > > > >>>>> > > > >>>>> Mitchell Erblich > > > >>>>> Sr Software Engineer > > > >>>>> ============================ > > > >>>>> > > > >>>>> > > > >>>>>Acee Lindem wrote: > > > >>>>> > > > >>>>> > > > >>>>>>Erblichs wrote: > > > >>>>>> > > > >>>>>> > > > >>>>>>>Acee Lindem, > > > >>>>>>> > > > >>>>>>> Sometimes my logic is a little obtuse.. > > > >>>>>>> > > > >>>>>>> Most of it is inline... > > > >>>>>>> > > > >>>>>>> I will first throw two new questions to you!!!! > > > >>>>>>> > > > >>>>>>> 1) Why don't you send out the Grace LSA at full > > > >>>>>>> adj timeframe. It would take effect after > > > >>>>>>> RouterDeadinterval has expired? > > > >>>>>> > > > >>>>>>How do you know, apriori, that the OSPF instance is > > > >>>>>>restarting and not completely dead? > > > >>>>> > > > >>>>> Why do you care? As long as the topology isn't changing > > > >>>>> then everything is ok. > > > >>>>> > > > >>>>> Wwhy not minimize the effects of unnecessary SPF computations? > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>>>> This would also take care of unscheduled restarts > > > >>>>>>> and allow you to do an unscheduled graceful > > > >>>>>>> restart!!!! > > > >>>>>>> > > > >>>>>>> You could also send them as DNA LSAs.. See inline. > > > >>>>>>> > > > >>>>>>> The only new twist is that if you then schedule > > > >>>>>>> a restart, you may want to be able to cancel your > > > >>>>>>> previous request or update the LSAs over time. > > > >>>>>>> But if you conisder a stable topology, then why > > > >>>>>>> NOT?? > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> 2) A) 2.1 3rd, paragraph.. > > > >>>>>>> "Their age field set to 0," > > > >>>>>>> Why can't you send DNA grace-LSAs???? > > > >>>>>> > > > >>>>>>You wouldn't gain anything since the grace interval cannot > > > >>>>>>exceed the LSA refresh time. > > > >>>>>> > > > >>>>> > > > >>>>> So, first why do you need to specify the grace-LSA > > > >>>>> timeframe. Let it be implicitly known to be 1 hr! > > > >>>>> > > > >>>>> With DNA grace-LSAs, we > > > >>>>> don't need to reflood them. If I sent them out > > > >>>>> at adj creation time and the topology isn't > > > >>>>> changing, then I don't need to consume > > > >>>>> resources and keep on re-flooding them.. > > > >>>>> > > > >>>>> Thus, they can last multiple hours or longer.. > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>>>> B) 2.1, 4th paragraph. > > > >>>>>>> > > > >>>>>>> "it should retransmit... until > > > >>>>>>> they are acknowledged". If you can't retransmit the > > > >>>>>>> same LSA until 5 secs have passed, if a router > > > >>>>>>> was congested, you may want to resubmit the grace-LSA > > > >>>>>>> with a longer length timeframe to your helpers. I am > > > >>>>>>> assuming just bump your instance. Correct? > > > >>>>>> > > > >>>>>>There are implementations that back off LSA retransmissions and the > > > >>>>>>"Prioritized Treatment of Specific OSPF Packets and Congestion > > > >>>>>>Avoidance" draft recommends this. However, this is not standard > > > >>>>>>OSPF flooding as described in RFC2328 and it is an independent > > > >>>>>>issue. > > > >>>>>> > > > >>>>> > > > >>>>> No, no, you are missing my point. Until all of your grace-LSAs are > > > >>>>> ack'ed, you can't continue successfully with a graceful-restart. > > > >>>>> > > > >>>>> This delay consumes time that you specified in your grace-LSA. Yea, > > > >>>>> again, I don't know why you need to specify the amount of time!! > > > >>>>> The timeframe that the helpers will help you can be set independently > > > >>>>> and your spec doesn't allow them to communicate the amount of time > > > >>>>> that they will keeep around a grace-LSA. > > > >>>>> > > > >>>>> Sorry, minor sidetrack. So, the time consumed to get the ack, actually > > > >>>>> reduces the amount of time before the grace-LSA expires. > > > >>>>> > > > >>>>> > > > >>>>>>> > > > >>>>>>> Mitchell > > > >>>>>>> ================ > > > >>>>>>>Acee Lindem wrote: > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>>>Mitchell, > > > >>>>>>>> > > > >>>>>>>>See answers below. > > > >>>>>>>> > > > >>>>>>>>Erblichs wrote: > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>>>Group, > > > >>>>>>>>> > > > >>>>>>>>> 1) Within 2.1 "Entering graceful restart", iff all > > > >>>>>>>>> the LSAs were from DC specified NBRs with DNA > > > >>>>>>>>> LSAs should the LS RefreshTime still be followed? > > > >>>>>>>> > > > >>>>>>>>LSA Refresh isn't relevant since the restarting router will > > > >>>>>>>>reestablish adjacencies. > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> Then why have a suggestion of 1800 secs for LSReshTime > > > >>>>>>> in your draft at the end of the 1st paragraph in section > > > >>>>>>> 2.1? > > > >>>>>>> > > > >>>>>>> In my scenario, there would be no reason not to let the > > > >>>>>>> value approach or exceed 3600 secs (1 hr). > > > >>>>>>> > > > >>>>>>> variation on a theme? Why not let the max value of your > > > >>>>>>> grace-LSA length field allow the helper determine what > > > >>>>>>> is the max that he will support? > > > >>>>>>> -- what happens if you specify a value that is > > > >>>>>>> greater than what the helper supports? > > > >>>>>>> Ans A: The helper sees it as an invalid request > > > >>>>>>> and throws away the whole request, > > > >>>>>>> > > > >>>>>>> OR > > > >>>>>>> Ans B: The helper determines what the length he > > > >>>>>>> will support? > > > >>>>>>> > > > >>>>>>> If it is B, then why have the length field. Just let > > > >>>>>>> the helper decide how long to support the request? > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>>>> 2) Within 2.2 "When to exit graceful restart", number > > > >>>>>>>>> (3) "The grace period expires". > > > >>>>>>>>> > > > >>>>>>>>> What happens if we follow #3 and your #1 "reestablished > > > >>>>>>>>> all its adjacencies" criteria is not met? > > > >>>>>>>> > > > >>>>>>>>The restarting router will exit graceful restart anyway. > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> Why? If you still have a non-changing topology, why > > > >>>>>>> limit the value to what you had said to the helpers? > > > >>>>>>> > > > >>>>>>> So, what if you asked for x time and it took you > > > >>>>>>> x + y time? > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>>>> Or are you stating that the specified "grace period" was > > > >>>>>>>>> to short to perform what was required? > > > >>>>>>>> > > > >>>>>>>>Not necessarily - perhaps the topology has changed and graceful restart > > > >>>>>>>>cannot be completed successfully. > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>>> 3) Within 2.2. Would seeing a hello without the graceful > > > >>>>>>>>> restarting router id", force it to exit? > > > >>>>>>>> > > > >>>>>>>>No. The adjacency can go all the way down on the helper router. The hello > > > >>>>>>>>shouldn't be used as a criteria for exiting helper mode. Do not confuse > > > >>>>>>>>this with other graceful restart proposals. > > > >>>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> I see that my question with the hello was answered in the > > > >>>>>>> 2. (3) "an hello packet is received".. > > > >>>>>>> > > > >>>>>>> I am confused. One router may list you as the DR and another > > > >>>>>>> may not? If one is a helper, then why would it take the adj > > > >>>>>>> down if all the crieria were met? > > > >>>>>>> > > > >>>>>>> I thought that helpers > > > >>>>>>> MUST send hellos as if you (graceful restarting router) were > > > >>>>>>> still there!! > > > >>>>>>> "an Hello packet is received from a neighbor listing the > > > >>>>>>> router as the Designated Router". > > > >>>>>>> > > > >>>>>>> If it did keep anouncing you in the hellos (you weren't > > > >>>>>>> the DR) and lets say that the DR went down. Could you > > > >>>>>>> then be elected as the DR while you were still rebooting? > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>>>> 4) Within 2.2. Would seeing a hello without the graceful > > > >>>>>>>>> restarting router id as the earlier DR or BDR, cause > > > >>>>>>>>> it to exit, if it was a DR / BDR? > > > >>>>>>>> > > > >>>>>>>>Not directly, but an inconsistency with the pre-restart LSA will cause > > > >>>>>>>>the restarting router to exist graceful restart prematurely. > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>>> 5) Within 2.2. Is it implimentation dependent on how we > > > >>>>>>>>> determine our existing nbrs and place their router ids > > > >>>>>>>>> in a hello? > > > >>>>>>>> > > > >>>>>>>>This isn't changed for graceful restart. > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> I thought that you could save past nbr-ids in NVRAM > > > >>>>>>> and then compare to existing hellos... > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>>>> 6) Within 2.2 (1), isn't adj establishment partly the > > > >>>>>>>>> recieving of hellos, with your own router-id? Shouldn't > > > >>>>>>>>> that inform others that we are back and to cancel > > > >>>>>>>>> their helper graceful nbr timer? > > > >>>>>>>>> > > > >>>>>>>>> 7 & 8) Within 2.3 "Actions on exiting graceful restart". > > > >>>>>>>>> > > > >>>>>>>>> 7) Shouldn't the sending hellos be performed that > > > >>>>>>>>> identify full adj be a criteria here? > > > >>>>>>>> > > > >>>>>>>>No. LSA convergence with the pre-restart LSAs is a much surer > > > >>>>>>>>mechanism for determining the graceful restart can be exited. > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>>> 8) I am unsure whether you are specifying the > > > >>>>>>>>> storage of part of restarting router's LSDB into > > > >>>>>>>>> non-volatile memory. If so, then upon retrieval, > > > >>>>>>>>> shouldn't some elements of the LSDB be aged > > > >>>>>>>>> by the amount that the actual amount of time > > > >>>>>>>>> the LSAs were in NV memory? > > > >>>>>>>> > > > >>>>>>>>There is no mention of storing LSAs in non-volatile storage. > > > >>>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> Ok, you aren't suggesting saving the LSDB in NVRAM > > > >>>>>>> or some other type of storage media.. > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>>>> Mitchell Erblich > > > >>>>>>>>> ================================== > > > >>>>>>>>> > > > >>>>>>>> > > > >>>>>>>>-- > > > >>>>>>>>Acee > > > >>>>>>> > > > >>>>>>> > > > >>>>>>-- > > > >>>>>>Acee > > > >>>>> > > > >>-- > > > >>Acee > > > > > > > > > > > > > > -- > > > Acee > > From owner-ospf@DISCUSS.MICROSOFT.COM Mon Apr 14 16:39:23 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20989 for ; Mon, 14 Apr 2003 16:39:20 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00977DEC@cherry.ease.lsoft.com>; Mon, 14 Apr 2003 16:41:57 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 748842 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 14 Apr 2003 16:41:57 -0400 Received: from 207.217.120.48 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 14 Apr 2003 16:41:57 -0500 Received: from user-38lc085.dialup.mindspring.com ([209.86.1.5] helo=earthlink.net) by mallard.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 195Am0-0006dj-00 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 14 Apr 2003 13:41: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: <200304082356.h38NunH88489@garnet.juniper.net> <3E93755E.1937BC89@earthlink.net> <3E95061B.5060200@redback.com> <3E95BACC.E53FDC89@earthlink.net> <3E95BEDF.2010606@redback.com> <3E975E6E.73A22F08@earthlink.net> <3E99DAD2.9080507@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E9B16AC.EE25CE5F@earthlink.net> Date: Mon, 14 Apr 2003 13:14:36 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Draft : Graceful Restart : : grace period, etc To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Acee Lindem, Inline... Mitchell Erblich ---------------------- Acee Lindem wrote: > > Erblichs wrote: > > Group, > > > > First of all I would want to apologize for continuing > > this discussion thread! > > > > I realize that some implimentions may exist based on > > this draft and what I am suggesting, may effect changes > > to them. > > Mitchell, > > No apologies necessary for discussion of the draft. However, please make > every attempt to read and understand it before suggesting substantive > changes. > > > > > In my past emails I have implicitly ignored the section > > 5 within this draft of "Unplanned outages". I will now > > explicitly state why I have ignored its suggested method. > > > > Why? > > * " must originate grace-LSAs *after* its control > > software resumes operation", we now lose our DR or > > BDR status, if it had existed. > > The restarting router will succeed DR status if it was previously DR. See > section 2 number 3. Also note section 5 for applicablility to unplanned > restarts. Changes in BDR should have no effect on adjacencies or LSA > contents. I am really lost here.. IFF we are unplanned, won't the normal deadrouterinterval timeouts take down the adjs? Remember the "*after*" section. If the restarting router was the DR or a BDR, a new election will occur to re-elect a new DR and/or BDR, and new adjs will form. Now, the premise of minimizing topological changes as a reason to keep the pre-shutdown DR / BDR combo, will no longer apply. Even if we declare ourselves the DR after re-start, there is only a chance that the reason why we were initially elected still applies, thus we may no longer have the highest priority of eligible routers. Mitchell Erblich --------------------------- > > > > > - This forces a SPF recomputation.. > > - This can forces many full adj reformations. > > - Removes the helper relationship with > > respect to the restarting router > > (monitoring, continues to (its) advertise its > > LSAs, etc) NIT: remove the first "its". > > - etc.. > > > > Thus this section invalidates many of the reasons > > for the draft's existance. > > > > * If the draft's unplanned outages did not have these > > negative effects and more, then anytime > 1 hr > > graceful restart is planned, then this would be a > > solid alternative. I just cannot see anyone > > forwarding any pkts accross a non-adj, so even if > > your forwarding table contents are sanitized, it > > will be ignored. > > > > So, from may past information dump, the only true side effect > > other than mentioned in the draft (clean flag for the forwarding > > table should remove the table sanity issue) are the issues of the > > reflooding bandwidth of early grace-LSAs, just in case the router > > has an unplanned restart. And the extra work that is placed on > > helper routers to "monitor" the network for topology changes, > > and its other assigned helper duties. > > > > Thus, I believe that I have more than sufficiently identified > > a graceful restart mechanism that removes the AFTER requirement > > and allows the planned graceful restart method to be used in a > > unplanned way. Plus, I agree that a knob/CLI command should be > > used to enable or disable this type of feature. > > > > Mitchell Erblich > > Sr Software Engineer > > ---------------------- > > > > Acee Lindem wrote: > > > >>Erblichs wrote: > >> > >>>Acee, et al, > >>> > >>> I didn't really want to continue this thread > >>> but I feel, I should restate some items here. :) > >>> > >>> > >>> > >>>>As Padma stated, the draft supports unscheduled restarts (there > >>>>are multiple interoperable implementations). Your proposal to > >>>>announce graceful restart in advance > >>> > >>> > >>> > >>> I don't see how one can send out grace-LSAs and possibly be > >>> able to retransmit a grace-LSA OTHER than in advance, > >>> AND still support unscheduled graceful restarts!!! > >> > >>Mitchell, > >> > >>In the case of unscheduled restart you may send the grace LSA a couple > >>times but you don't want for an acknowledge (you don't necessarily know your > >>neighbors since you are learning the state from the networks). > >> > >>I suggest you read or review section 5 of the draft. It covers all of your > >>concerns below. > >> > >> > >>> You must do it in advance, else it is scheduled.. > >>> > >>> My definition of unscheduled is that some event occurs and > >>> the non-forwarding portion of the router is DOWN... No, > >>> time for an sys admin to do anything... > >>> > >>> The ONLY possible way is to have trap level code call > >>> the xmit grace-LSA code section. However, no time to > >>> see if acks have been rec'vd and no time for a 5 sec > >>> rexmit.... > >>> > >>> Ok, then WHAT is an UNSCHEDULED GRACEFUL RESTART in your > >>> guys opinion???? > >>> > >>> On the assumption that if the router fails and > >>> still abides by the condition that it is still > >>> forwarding as if it was still up.., then > >>> > >>> As long as there isn't any topologoy changes > >>> as stated within your document, that is one > >>> reason to allow for a graceful restart, I don't > >>> see the blackhole.. > >>> > >>> If the topology changes then it would invalidate > >>> my graceful restart, as it would also invalidate > >>> the graceful restart specified in the draft. > >>> > >>> The only deltas that I was asking for was: > >>> - the issue of sending out a minimal grace-LSA at > >>> adj timeframe, > >>> - being able to minimally update our grace-LSA as > >>> topology changes, > >>> - or we decide that we want to withdraw our grace-LSA > >>> via MAXAGE, > >>> > >>> As of this time, I have not read in your document, > >>> EXPLICITLY whether > >>> - you suggest to ONLY send out the grace-LSA when you > >>> have planned to do a restart (scheduled), > >>> - how to withdraw the grace-LSAs from accepted helpers > >>> when one proto-helper (to be helper), will not ack > >>> your LSA, > >>> - etc.. > >>> > >>> > >>> Mitchell Erblich > >>> Sr Software Engineer > >>> ============================ > >>> > >>> > >>> > >>> > >>>Acee Lindem wrote: > >>> > >>> > >>>>Erblichs wrote: > >>>> > >>>> > >>>>>Padma, > >>>>> > >>>>> > >>>>> These are my last comments!! > >>>>> > >>>>> Also inline... > >>>>> > >>>>> Why doesn't the draft RFC authors want to > >>>>> allow non-scheduled restarts in this > >>>>> draft? > >>>> > >>>>Michell, > >>>> > >>>>As Padma stated, the draft supports unscheduled restarts (there > >>>>are multiple interoperable implementations). Your proposal to > >>>>announce graceful restart in advance will unnecessarily delay > >>>>the detection of a black hole if the restarting router is really dead > >>>>or was abruptly decommissioned. The current draft doesn't suffer > >>> > >>>>from this flaw. > >>> > >>>> > >>>>> Is there something wrong with the idea > >>>>> of un-scheduled restarts? > >>>>> > >>>>> Why restrict it to only scheduled > >>>>> restarts??? > >>>>> > >>>>> Why require > >>>>> the grace-LSAs to be reflooded every > >>>>> 30 minutes to 1 hr??? > >>>>> > >>>>> Why not send the grace-LSAs without > >>>>> the Type=1, Length=4 grace period field?? > >>>>> It will be determined by the helpers > >>>>> anyway. > >>>>> > >>>>> The sentance is. > >>>>> > >>>>> "The number of seconds that the router's > >>>>> neighbors should continue to advertise the > >>>>> router as fully adjacent".... > >>>>> > >>>>> Thus, without the word "MUST", implimentations > >>>>> will probably follow their own rules. Thus, the > >>>>> grace period field really isn't needed and just > >>>>> consumes bandwidth!!! > >>>>> > >>>>> > >>>>> > >>>>> Mitchell Erblich > >>>>> =================== > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>Padma Pillay-Esnault wrote: > >>>>> > >>>>> > >>>>> > >>>>>>Mitchell, > >>>>>> > >>>>>>I'll try to address your comments > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>>Acee Lindem, > >>>>>>> > >>>>>>> Since,, you skipped the inline re-comments, I will assume > >>>>>>> that at least you read them.. :) > >>>>>>> > >>>>>>> I think I have expressed as best as I could (I am not > >>>>>>> a tech writer) how I feel that this draft should evolve. > >>>>>>> > >>>>>>> So in summary... > >>>>>>> > >>>>>>>` 0) Remove the length (seconds) field from the grace-LSA. > >>>>>>> > >>>>>> > >>>>>>This is using the TLV format .. so you want to keep the length > >>>>> > >>>>> > >>>>> Of course, Type, Length, Value... Fine. Reword.. > >>>>> Remove > >>>>> the Grace-Period field of (Type =1, Length = 4). > >>>>> Why transmit the field value????? > >>>>> > >>>>> > >>>>> > >>>>>>> 1) Transmit DNA grace-LSAs at adj creation time. > >>>>>>> > >>>>>> > >>>>>>This is not very useful. Today unless you have DNA lsa you cannot > >>>>>>expect to be requesting a grace period of over one hour -- as > >>>>>>all the LSA in the other routers database will expire at the > >>>>>>most in 1hr. > >>>>>>So if you decide to send a grace LSA it would be the most recent one > >>>>>>that you built and hence if it has time to expire then the previous > >>>>>>would already be gone. > >>>>> > >>>>> > >>>>> Think ahead of tomarrow, not today... > >>>>> How should this work in the utopian word? If the graceful > >>>>> restart is a good idea, then it NOT should be used for ALL > >>>>> possible restarts?? > >>>>> > >>>>> Why not restrict the amount of flooding with THESE types > >>>>> of LSAs if this draft becomes a standard RFC?? > >>>>> > >>>>> What happens if I send the grace-LSAs at adj formation > >>>>> time and then reflood them every 55 minutes?? This > >>>>> removes the lightweight mechanism of the draft, but > >>>>> still gets me unscheduled restart functionality? Maybe > >>>>> i will just do that.. BTW, and also do unscheduled > >>>>> restarts with my BGP protocol once it becomes a > >>>>> standard. > >>>>> > >>>>> Thus, a restriction of 1 hr isn't sensible. Else, even if > >>>>> I follow your logic, then why do I ask for 1 hr? Should > >>>>> my implimentation in the helper not ack the grace-LSA if > >>>>> the specified grace-period is over 1 hr from the restarting > >>>>> router? This is unspecified behavior!!! > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>> 2) Let the helpers determine amount of time that > >>>>>>> they will function as a helper. Suggest a minimum > >>>>>>> of 1 hr time. > >>>>>>> > >>>>>> > >>>>>>This is a matter of policy .. even if the helper decides that > >>>>>>he is not going to help for the whole period .. as he is not > >>>>>>going to signal it to the restarting router .. I do not see > >>>>>>the use of doing so. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> 3) Reflood the DNA grace-LSAs anytime the contents > >>>>>>> have changed. > >>>>>>> > >>>>>> > >>>>>>See my response in 1. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> 4) If the restart router expects to be down for a period > >>>>>>> longer than X, then retransmit the Grace-LSAs as > >>>>>>> MAXage LSAs. > >>>>>>> > >>>>>> > >>>>>>I do not see the benefit or I am missing your point > >>>>>> > >>>>>>Padma > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> This would minimize bandwidth requirements and allow a > >>>>>>> restarting router to have either scheduled or unscheduled > >>>>>>> restarts. > >>>>>>> > >>>>>>> I don't know what else to add, except if you adopt one or > >>>>>>> more of these suggestions, then please add my name to your > >>>>>>> comment list. :) > >>>>>>> > >>>>>>> Mitchell Erblich > >>>>>>> Sr Software Engineer > >>>>>>> ============================ > >>>>>>> > >>>>>>> > >>>>>>>Acee Lindem wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>Erblichs wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>Acee Lindem, > >>>>>>>>> > >>>>>>>>> Sometimes my logic is a little obtuse.. > >>>>>>>>> > >>>>>>>>> Most of it is inline... > >>>>>>>>> > >>>>>>>>> I will first throw two new questions to you!!!! > >>>>>>>>> > >>>>>>>>> 1) Why don't you send out the Grace LSA at full > >>>>>>>>> adj timeframe. It would take effect after > >>>>>>>>> RouterDeadinterval has expired? > >>>>>>>> > >>>>>>>>How do you know, apriori, that the OSPF instance is > >>>>>>>>restarting and not completely dead? > >>>>>>> > >>>>>>> Why do you care? As long as the topology isn't changing > >>>>>>> then everything is ok. > >>>>>>> > >>>>>>> Wwhy not minimize the effects of unnecessary SPF computations? > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>> This would also take care of unscheduled restarts > >>>>>>>>> and allow you to do an unscheduled graceful > >>>>>>>>> restart!!!! > >>>>>>>>> > >>>>>>>>> You could also send them as DNA LSAs.. See inline. > >>>>>>>>> > >>>>>>>>> The only new twist is that if you then schedule > >>>>>>>>> a restart, you may want to be able to cancel your > >>>>>>>>> previous request or update the LSAs over time. > >>>>>>>>> But if you conisder a stable topology, then why > >>>>>>>>> NOT?? > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> 2) A) 2.1 3rd, paragraph.. > >>>>>>>>> "Their age field set to 0," > >>>>>>>>> Why can't you send DNA grace-LSAs???? > >>>>>>>> > >>>>>>>>You wouldn't gain anything since the grace interval cannot > >>>>>>>>exceed the LSA refresh time. > >>>>>>>> > >>>>>>> > >>>>>>> So, first why do you need to specify the grace-LSA > >>>>>>> timeframe. Let it be implicitly known to be 1 hr! > >>>>>>> > >>>>>>> With DNA grace-LSAs, we > >>>>>>> don't need to reflood them. If I sent them out > >>>>>>> at adj creation time and the topology isn't > >>>>>>> changing, then I don't need to consume > >>>>>>> resources and keep on re-flooding them.. > >>>>>>> > >>>>>>> Thus, they can last multiple hours or longer.. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>> B) 2.1, 4th paragraph. > >>>>>>>>> > >>>>>>>>> "it should retransmit... until > >>>>>>>>> they are acknowledged". If you can't retransmit the > >>>>>>>>> same LSA until 5 secs have passed, if a router > >>>>>>>>> was congested, you may want to resubmit the grace-LSA > >>>>>>>>> with a longer length timeframe to your helpers. I am > >>>>>>>>> assuming just bump your instance. Correct? > >>>>>>>> > >>>>>>>>There are implementations that back off LSA retransmissions and the > >>>>>>>>"Prioritized Treatment of Specific OSPF Packets and Congestion > >>>>>>>>Avoidance" draft recommends this. However, this is not standard > >>>>>>>>OSPF flooding as described in RFC2328 and it is an independent > >>>>>>>>issue. > >>>>>>>> > >>>>>>> > >>>>>>> No, no, you are missing my point. Until all of your grace-LSAs are > >>>>>>> ack'ed, you can't continue successfully with a graceful-restart. > >>>>>>> > >>>>>>> This delay consumes time that you specified in your grace-LSA. Yea, > >>>>>>> again, I don't know why you need to specify the amount of time!! > >>>>>>> The timeframe that the helpers will help you can be set independently > >>>>>>> and your spec doesn't allow them to communicate the amount of time > >>>>>>> that they will keeep around a grace-LSA. > >>>>>>> > >>>>>>> Sorry, minor sidetrack. So, the time consumed to get the ack, actually > >>>>>>> reduces the amount of time before the grace-LSA expires. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>> Mitchell > >>>>>>>>> ================ > >>>>>>>>>Acee Lindem wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>Mitchell, > >>>>>>>>>> > >>>>>>>>>>See answers below. > >>>>>>>>>> > >>>>>>>>>>Erblichs wrote: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>Group, > >>>>>>>>>>> > >>>>>>>>>>> 1) Within 2.1 "Entering graceful restart", iff all > >>>>>>>>>>> the LSAs were from DC specified NBRs with DNA > >>>>>>>>>>> LSAs should the LS RefreshTime still be followed? > >>>>>>>>>> > >>>>>>>>>>LSA Refresh isn't relevant since the restarting router will > >>>>>>>>>>reestablish adjacencies. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Then why have a suggestion of 1800 secs for LSReshTime > >>>>>>>>> in your draft at the end of the 1st paragraph in section > >>>>>>>>> 2.1? > >>>>>>>>> > >>>>>>>>> In my scenario, there would be no reason not to let the > >>>>>>>>> value approach or exceed 3600 secs (1 hr). > >>>>>>>>> > >>>>>>>>> variation on a theme? Why not let the max value of your > >>>>>>>>> grace-LSA length field allow the helper determine what > >>>>>>>>> is the max that he will support? > >>>>>>>>> -- what happens if you specify a value that is > >>>>>>>>> greater than what the helper supports? > >>>>>>>>> Ans A: The helper sees it as an invalid request > >>>>>>>>> and throws away the whole request, > >>>>>>>>> > >>>>>>>>> OR > >>>>>>>>> Ans B: The helper determines what the length he > >>>>>>>>> will support? > >>>>>>>>> > >>>>>>>>> If it is B, then why have the length field. Just let > >>>>>>>>> the helper decide how long to support the request? > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> 2) Within 2.2 "When to exit graceful restart", number > >>>>>>>>>>> (3) "The grace period expires". > >>>>>>>>>>> > >>>>>>>>>>> What happens if we follow #3 and your #1 "reestablished > >>>>>>>>>>> all its adjacencies" criteria is not met? > >>>>>>>>>> > >>>>>>>>>>The restarting router will exit graceful restart anyway. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Why? If you still have a non-changing topology, why > >>>>>>>>> limit the value to what you had said to the helpers? > >>>>>>>>> > >>>>>>>>> So, what if you asked for x time and it took you > >>>>>>>>> x + y time? > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> Or are you stating that the specified "grace period" was > >>>>>>>>>>> to short to perform what was required? > >>>>>>>>>> > >>>>>>>>>>Not necessarily - perhaps the topology has changed and graceful restart > >>>>>>>>>>cannot be completed successfully. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> 3) Within 2.2. Would seeing a hello without the graceful > >>>>>>>>>>> restarting router id", force it to exit? > >>>>>>>>>> > >>>>>>>>>>No. The adjacency can go all the way down on the helper router. The hello > >>>>>>>>>>shouldn't be used as a criteria for exiting helper mode. Do not confuse > >>>>>>>>>>this with other graceful restart proposals. > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> I see that my question with the hello was answered in the > >>>>>>>>> 2. (3) "an hello packet is received".. > >>>>>>>>> > >>>>>>>>> I am confused. One router may list you as the DR and another > >>>>>>>>> may not? If one is a helper, then why would it take the adj > >>>>>>>>> down if all the crieria were met? > >>>>>>>>> > >>>>>>>>> I thought that helpers > >>>>>>>>> MUST send hellos as if you (graceful restarting router) were > >>>>>>>>> still there!! > >>>>>>>>> "an Hello packet is received from a neighbor listing the > >>>>>>>>> router as the Designated Router". > >>>>>>>>> > >>>>>>>>> If it did keep anouncing you in the hellos (you weren't > >>>>>>>>> the DR) and lets say that the DR went down. Could you > >>>>>>>>> then be elected as the DR while you were still rebooting? > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> 4) Within 2.2. Would seeing a hello without the graceful > >>>>>>>>>>> restarting router id as the earlier DR or BDR, cause > >>>>>>>>>>> it to exit, if it was a DR / BDR? > >>>>>>>>>> > >>>>>>>>>>Not directly, but an inconsistency with the pre-restart LSA will cause > >>>>>>>>>>the restarting router to exist graceful restart prematurely. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> 5) Within 2.2. Is it implimentation dependent on how we > >>>>>>>>>>> determine our existing nbrs and place their router ids > >>>>>>>>>>> in a hello? > >>>>>>>>>> > >>>>>>>>>>This isn't changed for graceful restart. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> I thought that you could save past nbr-ids in NVRAM > >>>>>>>>> and then compare to existing hellos... > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> 6) Within 2.2 (1), isn't adj establishment partly the > >>>>>>>>>>> recieving of hellos, with your own router-id? Shouldn't > >>>>>>>>>>> that inform others that we are back and to cancel > >>>>>>>>>>> their helper graceful nbr timer? > >>>>>>>>>>> > >>>>>>>>>>> 7 & 8) Within 2.3 "Actions on exiting graceful restart". > >>>>>>>>>>> > >>>>>>>>>>> 7) Shouldn't the sending hellos be performed that > >>>>>>>>>>> identify full adj be a criteria here? > >>>>>>>>>> > >>>>>>>>>>No. LSA convergence with the pre-restart LSAs is a much surer > >>>>>>>>>>mechanism for determining the graceful restart can be exited. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> 8) I am unsure whether you are specifying the > >>>>>>>>>>> storage of part of restarting router's LSDB into > >>>>>>>>>>> non-volatile memory. If so, then upon retrieval, > >>>>>>>>>>> shouldn't some elements of the LSDB be aged > >>>>>>>>>>> by the amount that the actual amount of time > >>>>>>>>>>> the LSAs were in NV memory? > >>>>>>>>>> > >>>>>>>>>>There is no mention of storing LSAs in non-volatile storage. > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Ok, you aren't suggesting saving the LSDB in NVRAM > >>>>>>>>> or some other type of storage media.. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> Mitchell Erblich > >>>>>>>>>>> ================================== > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>-- > >>>>>>>>>>Acee > >>>>>>>>> > >>>>>>>>> > >>>>>>>>-- > >>>>>>>>Acee > >>>>>>> > >>>>-- > >>>>Acee > >>> > >>> > >>-- > >>Acee > > > > > > -- > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon Apr 14 16:39:56 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21017 for ; Mon, 14 Apr 2003 16:39:56 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00977DB0@cherry.ease.lsoft.com>; Mon, 14 Apr 2003 16:42:33 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 748854 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 14 Apr 2003 16:42:33 -0400 Received: from 65.174.124.37 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 14 Apr 2003 16:42:33 -0500 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id F277A34437 for ; Mon, 14 Apr 2003 12:56:15 -0700 (PDT) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h3EKgWYB025541 for ; Mon, 14 Apr 2003 13:42:32 -0700 (PDT) Received: from procket.com ([10.1.5.93]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 14 Apr 2003 13:42:32 -0700 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030404 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <029601c302aa$05beebc0$81c802c0@alok> <3E9AF59A.EDDEA082@earthlink.net> <1376.219.65.135.92.1050347600.squirrel@mail.apara.com> <3E9B03C6.8060304@Procket.com> <1488.219.65.135.92.1050348884.squirrel@mail.apara.com> X-Enigmail-Version: 0.73.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Apr 2003 20:42:32.0627 (UTC) FILETIME=[5F8B9830:01C302C6] Message-ID: <3E9B1D38.3050504@procket.com> Date: Mon, 14 Apr 2003 13:42:32 -0700 Reply-To: Mailing List Sender: Mailing List From: Scott Whyte Subject: Re: Changing router name... To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <1488.219.65.135.92.1050348884.squirrel@mail.apara.com> Precedence: list Content-Transfer-Encoding: 7bit Alok Dube wrote: >>Alok Dube wrote: >> >>>multiple loopbacks...at least 1 per vrf. >> >>Why? Do you put multiple VRFs into a single OSPF process? >> > > > Hi, > > no i dont, i could have a loopback interface per process... Then VRFs are irrelvant to Mitchell's original question, since you have one OSPF process per VRF what you are really saying is at least 1 loopback/OSPF process. > > think i missed your point.... > > > i meant 1 loopback per vrf atleast... (that actually came to me from BGP > presuming i was running BGP with the CE and it wasnt 1 hop away)..but yes, > same applies for OSPF, the interface is never down and you could have > multiple unnumbered P2Ps on it... BGP is also irrelvant to this question. -Scott From owner-ospf@DISCUSS.MICROSOFT.COM Mon Apr 14 16:45:36 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21122 for ; Mon, 14 Apr 2003 16:45:35 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00977E1A@cherry.ease.lsoft.com>; Mon, 14 Apr 2003 16:48:11 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 748886 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 14 Apr 2003 16:48:11 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 14 Apr 2003 16:48:10 -0500 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 322A66787C3 for ; Mon, 14 Apr 2003 13:48:08 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <200304082356.h38NunH88489@garnet.juniper.net> <3E93755E.1937BC89@earthlink.net> <3E95061B.5060200@redback.com> <3E95BACC.E53FDC89@earthlink.net> <3E95BEDF.2010606@redback.com> <3E975E6E.73A22F08@earthlink.net> <3E99DAD2.9080507@redback.com> <3E9B16AC.EE25CE5F@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E9B1E03.40803@redback.com> Date: Mon, 14 Apr 2003 16:45:55 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Draft : Graceful Restart : : grace period, etc To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Erblichs wrote: > Acee Lindem, > > Inline... > > Mitchell Erblich > ---------------------- > > Acee Lindem wrote: > >>Erblichs wrote: >> >>>Group, >>> >>> First of all I would want to apologize for continuing >>> this discussion thread! >>> >>> I realize that some implimentions may exist based on >>> this draft and what I am suggesting, may effect changes >>> to them. >> >>Mitchell, >> >>No apologies necessary for discussion of the draft. However, please make >>every attempt to read and understand it before suggesting substantive >>changes. >> >> >>> In my past emails I have implicitly ignored the section >>> 5 within this draft of "Unplanned outages". I will now >>> explicitly state why I have ignored its suggested method. >>> >>> Why? >>> * " must originate grace-LSAs *after* its control >>> software resumes operation", we now lose our DR or >>> BDR status, if it had existed. >> >>The restarting router will succeed DR status if it was previously DR. See >>section 2 number 3. Also note section 5 for applicablility to unplanned >>restarts. Changes in BDR should have no effect on adjacencies or LSA >>contents. > > > I am really lost here.. > > IFF we are unplanned, won't the normal deadrouterinterval > timeouts take down the adjs? Remember the "*after*" > section. What you are missing is that for unplanned restarts the restarting OSPF router (or process) must at least start graceful restart within the RouterDeadInterval period. For planned restarts, this is not a restriction. > > If the restarting router was the DR or a BDR, a new election > will occur to re-elect a new DR and/or BDR, and new adjs > will form. Now, the premise of minimizing topological changes > as a reason to keep the pre-shutdown DR / BDR combo, will > no longer apply. > > Even if we declare ourselves the DR after re-start, there > is only a chance that the reason why we were initially > elected still applies, thus we may no longer have the > highest priority of eligible routers. > > Mitchell Erblich > --------------------------- > > > > >>> - This forces a SPF recomputation.. >>> - This can forces many full adj reformations. >>> - Removes the helper relationship with >>> respect to the restarting router >>> (monitoring, continues to (its) advertise its >>> LSAs, etc) NIT: remove the first "its". >>> - etc.. >>> >>> Thus this section invalidates many of the reasons >>> for the draft's existance. >>> >>> * If the draft's unplanned outages did not have these >>> negative effects and more, then anytime > 1 hr >>> graceful restart is planned, then this would be a >>> solid alternative. I just cannot see anyone >>> forwarding any pkts accross a non-adj, so even if >>> your forwarding table contents are sanitized, it >>> will be ignored. >>> >>> So, from may past information dump, the only true side effect >>> other than mentioned in the draft (clean flag for the forwarding >>> table should remove the table sanity issue) are the issues of the >>> reflooding bandwidth of early grace-LSAs, just in case the router >>> has an unplanned restart. And the extra work that is placed on >>> helper routers to "monitor" the network for topology changes, >>> and its other assigned helper duties. >>> >>> Thus, I believe that I have more than sufficiently identified >>> a graceful restart mechanism that removes the AFTER requirement >>> and allows the planned graceful restart method to be used in a >>> unplanned way. Plus, I agree that a knob/CLI command should be >>> used to enable or disable this type of feature. >>> >>> Mitchell Erblich >>> Sr Software Engineer >>> ---------------------- >>> >>>Acee Lindem wrote: >>> >>> >>>>Erblichs wrote: >>>> >>>> >>>>>Acee, et al, >>>>> >>>>> I didn't really want to continue this thread >>>>> but I feel, I should restate some items here. :) >>>>> >>>>> >>>>> >>>>> >>>>>>As Padma stated, the draft supports unscheduled restarts (there >>>>>>are multiple interoperable implementations). Your proposal to >>>>>>announce graceful restart in advance >>>>> >>>>> >>>>> >>>>> I don't see how one can send out grace-LSAs and possibly be >>>>> able to retransmit a grace-LSA OTHER than in advance, >>>>> AND still support unscheduled graceful restarts!!! >>>> >>>>Mitchell, >>>> >>>>In the case of unscheduled restart you may send the grace LSA a couple >>>>times but you don't want for an acknowledge (you don't necessarily know your >>>>neighbors since you are learning the state from the networks). >>>> >>>>I suggest you read or review section 5 of the draft. It covers all of your >>>>concerns below. >>>> >>>> >>>> >>>>> You must do it in advance, else it is scheduled.. >>>>> >>>>> My definition of unscheduled is that some event occurs and >>>>> the non-forwarding portion of the router is DOWN... No, >>>>> time for an sys admin to do anything... >>>>> >>>>> The ONLY possible way is to have trap level code call >>>>> the xmit grace-LSA code section. However, no time to >>>>> see if acks have been rec'vd and no time for a 5 sec >>>>> rexmit.... >>>>> >>>>> Ok, then WHAT is an UNSCHEDULED GRACEFUL RESTART in your >>>>> guys opinion???? >>>>> >>>>> On the assumption that if the router fails and >>>>> still abides by the condition that it is still >>>>> forwarding as if it was still up.., then >>>>> >>>>> As long as there isn't any topologoy changes >>>>> as stated within your document, that is one >>>>> reason to allow for a graceful restart, I don't >>>>> see the blackhole.. >>>>> >>>>> If the topology changes then it would invalidate >>>>> my graceful restart, as it would also invalidate >>>>> the graceful restart specified in the draft. >>>>> >>>>> The only deltas that I was asking for was: >>>>> - the issue of sending out a minimal grace-LSA at >>>>> adj timeframe, >>>>> - being able to minimally update our grace-LSA as >>>>> topology changes, >>>>> - or we decide that we want to withdraw our grace-LSA >>>>> via MAXAGE, >>>>> >>>>> As of this time, I have not read in your document, >>>>> EXPLICITLY whether >>>>> - you suggest to ONLY send out the grace-LSA when you >>>>> have planned to do a restart (scheduled), >>>>> - how to withdraw the grace-LSAs from accepted helpers >>>>> when one proto-helper (to be helper), will not ack >>>>> your LSA, >>>>> - etc.. >>>>> >>>>> >>>>> Mitchell Erblich >>>>> Sr Software Engineer >>>>> ============================ >>>>> >>>>> >>>>> >>>>> >>>>>Acee Lindem wrote: >>>>> >>>>> >>>>> >>>>>>Erblichs wrote: >>>>>> >>>>>> >>>>>> >>>>>>>Padma, >>>>>>> >>>>>>> >>>>>>> These are my last comments!! >>>>>>> >>>>>>> Also inline... >>>>>>> >>>>>>> Why doesn't the draft RFC authors want to >>>>>>> allow non-scheduled restarts in this >>>>>>> draft? >>>>>> >>>>>>Michell, >>>>>> >>>>>>As Padma stated, the draft supports unscheduled restarts (there >>>>>>are multiple interoperable implementations). Your proposal to >>>>>>announce graceful restart in advance will unnecessarily delay >>>>>>the detection of a black hole if the restarting router is really dead >>>>>>or was abruptly decommissioned. The current draft doesn't suffer >>>>> >>>>>>from this flaw. >>>>> >>>>> >>>>>>> Is there something wrong with the idea >>>>>>> of un-scheduled restarts? >>>>>>> >>>>>>> Why restrict it to only scheduled >>>>>>> restarts??? >>>>>>> >>>>>>> Why require >>>>>>> the grace-LSAs to be reflooded every >>>>>>> 30 minutes to 1 hr??? >>>>>>> >>>>>>> Why not send the grace-LSAs without >>>>>>> the Type=1, Length=4 grace period field?? >>>>>>> It will be determined by the helpers >>>>>>> anyway. >>>>>>> >>>>>>> The sentance is. >>>>>>> >>>>>>> "The number of seconds that the router's >>>>>>> neighbors should continue to advertise the >>>>>>> router as fully adjacent".... >>>>>>> >>>>>>> Thus, without the word "MUST", implimentations >>>>>>> will probably follow their own rules. Thus, the >>>>>>> grace period field really isn't needed and just >>>>>>> consumes bandwidth!!! >>>>>>> >>>>>>> >>>>>>> >>>>>>> Mitchell Erblich >>>>>>> =================== >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>Padma Pillay-Esnault wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Mitchell, >>>>>>>> >>>>>>>>I'll try to address your comments >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>Acee Lindem, >>>>>>>>> >>>>>>>>> Since,, you skipped the inline re-comments, I will assume >>>>>>>>> that at least you read them.. :) >>>>>>>>> >>>>>>>>> I think I have expressed as best as I could (I am not >>>>>>>>> a tech writer) how I feel that this draft should evolve. >>>>>>>>> >>>>>>>>> So in summary... >>>>>>>>> >>>>>>>>>` 0) Remove the length (seconds) field from the grace-LSA. >>>>>>>>> >>>>>>>> >>>>>>>>This is using the TLV format .. so you want to keep the length >>>>>>> >>>>>>> >>>>>>> Of course, Type, Length, Value... Fine. Reword.. >>>>>>> Remove >>>>>>> the Grace-Period field of (Type =1, Length = 4). >>>>>>> Why transmit the field value????? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> 1) Transmit DNA grace-LSAs at adj creation time. >>>>>>>>> >>>>>>>> >>>>>>>>This is not very useful. Today unless you have DNA lsa you cannot >>>>>>>>expect to be requesting a grace period of over one hour -- as >>>>>>>>all the LSA in the other routers database will expire at the >>>>>>>>most in 1hr. >>>>>>>>So if you decide to send a grace LSA it would be the most recent one >>>>>>>>that you built and hence if it has time to expire then the previous >>>>>>>>would already be gone. >>>>>>> >>>>>>> >>>>>>> Think ahead of tomarrow, not today... >>>>>>> How should this work in the utopian word? If the graceful >>>>>>> restart is a good idea, then it NOT should be used for ALL >>>>>>> possible restarts?? >>>>>>> >>>>>>> Why not restrict the amount of flooding with THESE types >>>>>>> of LSAs if this draft becomes a standard RFC?? >>>>>>> >>>>>>> What happens if I send the grace-LSAs at adj formation >>>>>>> time and then reflood them every 55 minutes?? This >>>>>>> removes the lightweight mechanism of the draft, but >>>>>>> still gets me unscheduled restart functionality? Maybe >>>>>>> i will just do that.. BTW, and also do unscheduled >>>>>>> restarts with my BGP protocol once it becomes a >>>>>>> standard. >>>>>>> >>>>>>> Thus, a restriction of 1 hr isn't sensible. Else, even if >>>>>>> I follow your logic, then why do I ask for 1 hr? Should >>>>>>> my implimentation in the helper not ack the grace-LSA if >>>>>>> the specified grace-period is over 1 hr from the restarting >>>>>>> router? This is unspecified behavior!!! >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> 2) Let the helpers determine amount of time that >>>>>>>>> they will function as a helper. Suggest a minimum >>>>>>>>> of 1 hr time. >>>>>>>>> >>>>>>>> >>>>>>>>This is a matter of policy .. even if the helper decides that >>>>>>>>he is not going to help for the whole period .. as he is not >>>>>>>>going to signal it to the restarting router .. I do not see >>>>>>>>the use of doing so. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> 3) Reflood the DNA grace-LSAs anytime the contents >>>>>>>>> have changed. >>>>>>>>> >>>>>>>> >>>>>>>>See my response in 1. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> 4) If the restart router expects to be down for a period >>>>>>>>> longer than X, then retransmit the Grace-LSAs as >>>>>>>>> MAXage LSAs. >>>>>>>>> >>>>>>>> >>>>>>>>I do not see the benefit or I am missing your point >>>>>>>> >>>>>>>>Padma >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> This would minimize bandwidth requirements and allow a >>>>>>>>> restarting router to have either scheduled or unscheduled >>>>>>>>> restarts. >>>>>>>>> >>>>>>>>> I don't know what else to add, except if you adopt one or >>>>>>>>> more of these suggestions, then please add my name to your >>>>>>>>> comment list. :) >>>>>>>>> >>>>>>>>> Mitchell Erblich >>>>>>>>> Sr Software Engineer >>>>>>>>> ============================ >>>>>>>>> >>>>>>>>> >>>>>>>>>Acee Lindem wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>Erblichs wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>Acee Lindem, >>>>>>>>>>> >>>>>>>>>>> Sometimes my logic is a little obtuse.. >>>>>>>>>>> >>>>>>>>>>> Most of it is inline... >>>>>>>>>>> >>>>>>>>>>> I will first throw two new questions to you!!!! >>>>>>>>>>> >>>>>>>>>>> 1) Why don't you send out the Grace LSA at full >>>>>>>>>>> adj timeframe. It would take effect after >>>>>>>>>>> RouterDeadinterval has expired? >>>>>>>>>> >>>>>>>>>>How do you know, apriori, that the OSPF instance is >>>>>>>>>>restarting and not completely dead? >>>>>>>>> >>>>>>>>> Why do you care? As long as the topology isn't changing >>>>>>>>> then everything is ok. >>>>>>>>> >>>>>>>>> Wwhy not minimize the effects of unnecessary SPF computations? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> This would also take care of unscheduled restarts >>>>>>>>>>> and allow you to do an unscheduled graceful >>>>>>>>>>> restart!!!! >>>>>>>>>>> >>>>>>>>>>> You could also send them as DNA LSAs.. See inline. >>>>>>>>>>> >>>>>>>>>>> The only new twist is that if you then schedule >>>>>>>>>>> a restart, you may want to be able to cancel your >>>>>>>>>>> previous request or update the LSAs over time. >>>>>>>>>>> But if you conisder a stable topology, then why >>>>>>>>>>> NOT?? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2) A) 2.1 3rd, paragraph.. >>>>>>>>>>> "Their age field set to 0," >>>>>>>>>>> Why can't you send DNA grace-LSAs???? >>>>>>>>>> >>>>>>>>>>You wouldn't gain anything since the grace interval cannot >>>>>>>>>>exceed the LSA refresh time. >>>>>>>>>> >>>>>>>>> >>>>>>>>> So, first why do you need to specify the grace-LSA >>>>>>>>> timeframe. Let it be implicitly known to be 1 hr! >>>>>>>>> >>>>>>>>> With DNA grace-LSAs, we >>>>>>>>> don't need to reflood them. If I sent them out >>>>>>>>> at adj creation time and the topology isn't >>>>>>>>> changing, then I don't need to consume >>>>>>>>> resources and keep on re-flooding them.. >>>>>>>>> >>>>>>>>> Thus, they can last multiple hours or longer.. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> B) 2.1, 4th paragraph. >>>>>>>>>>> >>>>>>>>>>> "it should retransmit... until >>>>>>>>>>> they are acknowledged". If you can't retransmit the >>>>>>>>>>> same LSA until 5 secs have passed, if a router >>>>>>>>>>> was congested, you may want to resubmit the grace-LSA >>>>>>>>>>> with a longer length timeframe to your helpers. I am >>>>>>>>>>> assuming just bump your instance. Correct? >>>>>>>>>> >>>>>>>>>>There are implementations that back off LSA retransmissions and the >>>>>>>>>>"Prioritized Treatment of Specific OSPF Packets and Congestion >>>>>>>>>>Avoidance" draft recommends this. However, this is not standard >>>>>>>>>>OSPF flooding as described in RFC2328 and it is an independent >>>>>>>>>>issue. >>>>>>>>>> >>>>>>>>> >>>>>>>>> No, no, you are missing my point. Until all of your grace-LSAs are >>>>>>>>> ack'ed, you can't continue successfully with a graceful-restart. >>>>>>>>> >>>>>>>>> This delay consumes time that you specified in your grace-LSA. Yea, >>>>>>>>> again, I don't know why you need to specify the amount of time!! >>>>>>>>> The timeframe that the helpers will help you can be set independently >>>>>>>>> and your spec doesn't allow them to communicate the amount of time >>>>>>>>> that they will keeep around a grace-LSA. >>>>>>>>> >>>>>>>>> Sorry, minor sidetrack. So, the time consumed to get the ack, actually >>>>>>>>> reduces the amount of time before the grace-LSA expires. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> Mitchell >>>>>>>>>>> ================ >>>>>>>>>>>Acee Lindem wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>Mitchell, >>>>>>>>>>>> >>>>>>>>>>>>See answers below. >>>>>>>>>>>> >>>>>>>>>>>>Erblichs wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>Group, >>>>>>>>>>>>> >>>>>>>>>>>>> 1) Within 2.1 "Entering graceful restart", iff all >>>>>>>>>>>>> the LSAs were from DC specified NBRs with DNA >>>>>>>>>>>>> LSAs should the LS RefreshTime still be followed? >>>>>>>>>>>> >>>>>>>>>>>>LSA Refresh isn't relevant since the restarting router will >>>>>>>>>>>>reestablish adjacencies. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Then why have a suggestion of 1800 secs for LSReshTime >>>>>>>>>>> in your draft at the end of the 1st paragraph in section >>>>>>>>>>> 2.1? >>>>>>>>>>> >>>>>>>>>>> In my scenario, there would be no reason not to let the >>>>>>>>>>> value approach or exceed 3600 secs (1 hr). >>>>>>>>>>> >>>>>>>>>>> variation on a theme? Why not let the max value of your >>>>>>>>>>> grace-LSA length field allow the helper determine what >>>>>>>>>>> is the max that he will support? >>>>>>>>>>> -- what happens if you specify a value that is >>>>>>>>>>> greater than what the helper supports? >>>>>>>>>>> Ans A: The helper sees it as an invalid request >>>>>>>>>>> and throws away the whole request, >>>>>>>>>>> >>>>>>>>>>> OR >>>>>>>>>>> Ans B: The helper determines what the length he >>>>>>>>>>> will support? >>>>>>>>>>> >>>>>>>>>>> If it is B, then why have the length field. Just let >>>>>>>>>>> the helper decide how long to support the request? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> 2) Within 2.2 "When to exit graceful restart", number >>>>>>>>>>>>> (3) "The grace period expires". >>>>>>>>>>>>> >>>>>>>>>>>>> What happens if we follow #3 and your #1 "reestablished >>>>>>>>>>>>> all its adjacencies" criteria is not met? >>>>>>>>>>>> >>>>>>>>>>>>The restarting router will exit graceful restart anyway. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Why? If you still have a non-changing topology, why >>>>>>>>>>> limit the value to what you had said to the helpers? >>>>>>>>>>> >>>>>>>>>>> So, what if you asked for x time and it took you >>>>>>>>>>> x + y time? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> Or are you stating that the specified "grace period" was >>>>>>>>>>>>> to short to perform what was required? >>>>>>>>>>>> >>>>>>>>>>>>Not necessarily - perhaps the topology has changed and graceful restart >>>>>>>>>>>>cannot be completed successfully. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> 3) Within 2.2. Would seeing a hello without the graceful >>>>>>>>>>>>> restarting router id", force it to exit? >>>>>>>>>>>> >>>>>>>>>>>>No. The adjacency can go all the way down on the helper router. The hello >>>>>>>>>>>>shouldn't be used as a criteria for exiting helper mode. Do not confuse >>>>>>>>>>>>this with other graceful restart proposals. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I see that my question with the hello was answered in the >>>>>>>>>>> 2. (3) "an hello packet is received".. >>>>>>>>>>> >>>>>>>>>>> I am confused. One router may list you as the DR and another >>>>>>>>>>> may not? If one is a helper, then why would it take the adj >>>>>>>>>>> down if all the crieria were met? >>>>>>>>>>> >>>>>>>>>>> I thought that helpers >>>>>>>>>>> MUST send hellos as if you (graceful restarting router) were >>>>>>>>>>> still there!! >>>>>>>>>>> "an Hello packet is received from a neighbor listing the >>>>>>>>>>> router as the Designated Router". >>>>>>>>>>> >>>>>>>>>>> If it did keep anouncing you in the hellos (you weren't >>>>>>>>>>> the DR) and lets say that the DR went down. Could you >>>>>>>>>>> then be elected as the DR while you were still rebooting? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> 4) Within 2.2. Would seeing a hello without the graceful >>>>>>>>>>>>> restarting router id as the earlier DR or BDR, cause >>>>>>>>>>>>> it to exit, if it was a DR / BDR? >>>>>>>>>>>> >>>>>>>>>>>>Not directly, but an inconsistency with the pre-restart LSA will cause >>>>>>>>>>>>the restarting router to exist graceful restart prematurely. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> 5) Within 2.2. Is it implimentation dependent on how we >>>>>>>>>>>>> determine our existing nbrs and place their router ids >>>>>>>>>>>>> in a hello? >>>>>>>>>>>> >>>>>>>>>>>>This isn't changed for graceful restart. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I thought that you could save past nbr-ids in NVRAM >>>>>>>>>>> and then compare to existing hellos... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> 6) Within 2.2 (1), isn't adj establishment partly the >>>>>>>>>>>>> recieving of hellos, with your own router-id? Shouldn't >>>>>>>>>>>>> that inform others that we are back and to cancel >>>>>>>>>>>>> their helper graceful nbr timer? >>>>>>>>>>>>> >>>>>>>>>>>>> 7 & 8) Within 2.3 "Actions on exiting graceful restart". >>>>>>>>>>>>> >>>>>>>>>>>>> 7) Shouldn't the sending hellos be performed that >>>>>>>>>>>>> identify full adj be a criteria here? >>>>>>>>>>>> >>>>>>>>>>>>No. LSA convergence with the pre-restart LSAs is a much surer >>>>>>>>>>>>mechanism for determining the graceful restart can be exited. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> 8) I am unsure whether you are specifying the >>>>>>>>>>>>> storage of part of restarting router's LSDB into >>>>>>>>>>>>> non-volatile memory. If so, then upon retrieval, >>>>>>>>>>>>> shouldn't some elements of the LSDB be aged >>>>>>>>>>>>> by the amount that the actual amount of time >>>>>>>>>>>>> the LSAs were in NV memory? >>>>>>>>>>>> >>>>>>>>>>>>There is no mention of storing LSAs in non-volatile storage. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Ok, you aren't suggesting saving the LSDB in NVRAM >>>>>>>>>>> or some other type of storage media.. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> Mitchell Erblich >>>>>>>>>>>>> ================================== >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>-- >>>>>>>>>>>>Acee >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>-- >>>>>>>>>>Acee >>>>>>>>> >>>>>>-- >>>>>>Acee >>>>> >>>>> >>>>-- >>>>Acee >>> >>> >>-- >>Acee > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon Apr 14 17:47:01 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23232 for ; Mon, 14 Apr 2003 17:47:01 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.009781C6@cherry.ease.lsoft.com>; Mon, 14 Apr 2003 17:49:37 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 663178 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 14 Apr 2003 17:49:37 -0400 Received: from 207.217.120.232 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 14 Apr 2003 17:49:37 -0400 Received: from user-38lc085.dialup.mindspring.com ([209.86.1.5] helo=earthlink.net) by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 195BpX-0004OA-00 for ospf@discuss.microsoft.com; Mon, 14 Apr 2003 14:49:36 -0700 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E9B2683.906AF31B@earthlink.net> Date: Mon, 14 Apr 2003 14:22:11 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Graceful restart vs max-metric graceful ... To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, Max-metric vs graceful restart ------------------------------- There are a number of routers that currently support advertising max-metric LSAs for a period of time during router bootup and at shutdown. The reason behind this is due to the fact that we don't want to handle transit packets until we have basicly completed our SPF calculations and inserted the majority of the forwarding entries. After a period of time has passed (some companies call it announce-time), we then re-originate our LSAs with the normal metrics. I would like to know whether there is a belief that the max-metric functionality and graceful restart is compatible OR whether their is a belief that max-metric functionality is obsoleted by graceful restart??? Also .... Blackhole event Upon restart, when a a topology change has occured on possibly just 1 interface. Then packets transiting from a valid helper interface segment to a now non-valid interface segment will be dropped for the duration that can approach 1 hr. Right??? How does one helper on 1 interface know about other helpers (or non-helpers) on other interfaces/ segments. If OSPF control functionality is inoperable, then we are unable to transmit LSAs to inform that an interface has gone down between the time that we transmitted our grace-LSAs and the time that are are now restarting. Thus, should a graceful restarting router transmit max-metric LSAs before shutdown to minimize transiting packets in case we loose a helper on one OR more of our interfaces? Mitchell Erblich Sr. Software Engineer ----------------------------- From owner-ospf@DISCUSS.MICROSOFT.COM Mon Apr 14 18:34:45 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25523 for ; Mon, 14 Apr 2003 18:34:44 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.009782F3@cherry.ease.lsoft.com>; Mon, 14 Apr 2003 18:37:21 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 663316 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 14 Apr 2003 18:37:20 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 14 Apr 2003 18:37:20 -0400 Received: from juniper.net (localhost [127.0.0.1]) by padma-bsd.juniper.net (8.12.6/8.12.3) with ESMTP id h3EMbI0R049367 for ; Mon, 14 Apr 2003 15:37:19 -0700 (PDT) (envelope-from padma@juniper.net) User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 References: <3E9B2683.906AF31B@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E9B381D.30203@juniper.net> Date: Mon, 14 Apr 2003 15:37:17 -0700 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Organization: Juniper Networks Subject: Re: Graceful restart vs max-metric graceful ... To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Mitchell, See inline comments Erblichs wrote: >Group, > > Max-metric vs graceful restart > ------------------------------- > > There are a number of routers that currently support > advertising max-metric LSAs for a period of time > during router bootup and at shutdown. > > The reason behind this is due to the fact that we > don't want to handle transit packets until we > have basicly completed our SPF calculations and > inserted the majority of the forwarding entries. > > After a period of time has passed (some companies > call it announce-time), we then re-originate our > LSAs with the normal metrics. > > I would like to know whether there is a > belief that the max-metric functionality and > graceful restart is compatible OR whether their > is a belief that max-metric functionality is > obsoleted by graceful restart??? > The two problems are orthogonal .. In the case of overloading a router - the router is avoided because it doesn't have the routes in its routing table. In the graceful restart case we assume that the router has its forwarding plane functioning and hence is able to forward packets. > > Also .... Blackhole event > > Upon restart, when a a topology > change has occured on possibly just 1 interface. > Then packets transiting from a valid helper interface > segment to a now non-valid interface segment > will be dropped for the duration that can > approach 1 hr. Right??? > I suppose you mean that the change in topology is in the restarting router itself or else graceful restart is aborted. Now remember that a graceful restart means that all is fine in the router .. any change in topology should abort the restart. > > How does one helper on 1 interface know about > other helpers (or non-helpers) on other interfaces/ > segments. If OSPF control functionality is inoperable, > then we are unable to transmit LSAs to inform that > an interface has gone down between the time that > we transmitted our grace-LSAs and the time that > are are now restarting. > Again, we are under the assumption that the forwarding capabilities are intact .. if it isn't then we cannot magically get the packets across graceful restart or not. > > Thus, should a graceful restarting router > transmit max-metric LSAs before shutdown > to minimize transiting packets > in case we loose a helper on one OR more > of our interfaces? > We will be avoiding the restart router .. which is not what we intend Padma > > Mitchell Erblich > Sr. Software Engineer > ----------------------------- > > From owner-ospf@DISCUSS.MICROSOFT.COM Mon Apr 14 18:53:51 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26071 for ; Mon, 14 Apr 2003 18:53:50 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.0097839A@cherry.ease.lsoft.com>; Mon, 14 Apr 2003 18:56:26 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 663360 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 14 Apr 2003 18:56:26 -0400 Received: from 207.217.120.50 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 14 Apr 2003 18:56:26 -0400 Received: from user-38lc085.dialup.mindspring.com ([209.86.1.5] helo=earthlink.net) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 195Cs9-0006pQ-00 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 14 Apr 2003 15:56:21 -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: <200304082356.h38NunH88489@garnet.juniper.net> <3E93755E.1937BC89@earthlink.net> <3E95061B.5060200@redback.com> <3E95BACC.E53FDC89@earthlink.net> <3E95BEDF.2010606@redback.com> <3E975E6E.73A22F08@earthlink.net> <3E99DAD2.9080507@redback.com> <3E9B16AC.EE25CE5F@earthlink.net> <3E9B1E03.40803@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E9B361F.CD83ACDC@earthlink.net> Date: Mon, 14 Apr 2003 15:28:47 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Draft : Graceful Restart : : grace period, etc To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Acee Lindem,, Inline.. Mitchell Erblich Sr Software Engineer ----------- Acee Lindem wrote: > > Erblichs wrote: > > Acee Lindem, > > > > Inline... > > > > Mitchell Erblich > > ---------------------- > > > > Acee Lindem wrote: > > > >>Erblichs wrote: > >> > >>>Group, > >>> > >>> First of all I would want to apologize for continuing > >>> this discussion thread! > >>> > >>> I realize that some implimentions may exist based on > >>> this draft and what I am suggesting, may effect changes > >>> to them. > >> > >>Mitchell, > >> > >>No apologies necessary for discussion of the draft. However, please make > >>every attempt to read and understand it before suggesting substantive > >>changes. > >> > >> > >>> In my past emails I have implicitly ignored the section > >>> 5 within this draft of "Unplanned outages". I will now > >>> explicitly state why I have ignored its suggested method. > >>> > >>> Why? > >>> * " must originate grace-LSAs *after* its control > >>> software resumes operation", we now lose our DR or > >>> BDR status, if it had existed. > >> > >>The restarting router will succeed DR status if it was previously DR. See > >>section 2 number 3. Also note section 5 for applicablility to unplanned > >>restarts. Changes in BDR should have no effect on adjacencies or LSA > >>contents. > > > > > > I am really lost here.. > > > > IFF we are unplanned, won't the normal deadrouterinterval > > timeouts take down the adjs? Remember the "*after*" > > section. > > What you are missing is that for unplanned restarts the restarting OSPF > router (or process) must at least start graceful restart within > the RouterDeadInterval period. For planned restarts, this is not a > restriction. That is nice.................... No, not "start graceful restart" process. Start sending hellos within routerdeadinterval which is after grace-LSAs are sent and recived. Yes, sending multiple grace-LSAs, but don't they need to be 5 secs apart? So, to send three will take 15 secs. Right?? In Version 07, section 5, of the draft where is that ROUTERDEADINTERVAL stated??? Isn't that an important enough concept to be explicitly stated here? I only see "restarted router has no adjacencies and no knowledge of previous adjacencies". As a statement about adj in section 5. Wow.. Can I second and third my unplanned restart as an option that follows the planned restart logic without the routerdeadinterval restriction???? :) > > > > > If the restarting router was the DR or a BDR, a new election > > will occur to re-elect a new DR and/or BDR, and new adjs > > will form. Now, the premise of minimizing topological changes > > as a reason to keep the pre-shutdown DR / BDR combo, will > > no longer apply. > > > > Even if we declare ourselves the DR after re-start, there > > is only a chance that the reason why we were initially > > elected still applies, thus we may no longer have the > > highest priority of eligible routers. > > > > Mitchell Erblich > > --------------------------- > > > > > > > > > >>> - This forces a SPF recomputation.. > >>> - This can forces many full adj reformations. > >>> - Removes the helper relationship with > >>> respect to the restarting router > >>> (monitoring, continues to (its) advertise its > >>> LSAs, etc) NIT: remove the first "its". > >>> - etc.. > >>> > >>> Thus this section invalidates many of the reasons > >>> for the draft's existance. > >>> > >>> * If the draft's unplanned outages did not have these > >>> negative effects and more, then anytime > 1 hr > >>> graceful restart is planned, then this would be a > >>> solid alternative. I just cannot see anyone > >>> forwarding any pkts accross a non-adj, so even if > >>> your forwarding table contents are sanitized, it > >>> will be ignored. > >>> > >>> So, from may past information dump, the only true side effect > >>> other than mentioned in the draft (clean flag for the forwarding > >>> table should remove the table sanity issue) are the issues of the > >>> reflooding bandwidth of early grace-LSAs, just in case the router > >>> has an unplanned restart. And the extra work that is placed on > >>> helper routers to "monitor" the network for topology changes, > >>> and its other assigned helper duties. > >>> > >>> Thus, I believe that I have more than sufficiently identified > >>> a graceful restart mechanism that removes the AFTER requirement > >>> and allows the planned graceful restart method to be used in a > >>> unplanned way. Plus, I agree that a knob/CLI command should be > >>> used to enable or disable this type of feature. > >>> > >>> Mitchell Erblich > >>> Sr Software Engineer > >>> ---------------------- > >>> > >>>Acee Lindem wrote: > >>> > >>> > >>>>Erblichs wrote: > >>>> > >>>> > >>>>>Acee, et al, > >>>>> > >>>>> I didn't really want to continue this thread > >>>>> but I feel, I should restate some items here. :) > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>As Padma stated, the draft supports unscheduled restarts (there > >>>>>>are multiple interoperable implementations). Your proposal to > >>>>>>announce graceful restart in advance > >>>>> > >>>>> > >>>>> > >>>>> I don't see how one can send out grace-LSAs and possibly be > >>>>> able to retransmit a grace-LSA OTHER than in advance, > >>>>> AND still support unscheduled graceful restarts!!! > >>>> > >>>>Mitchell, > >>>> > >>>>In the case of unscheduled restart you may send the grace LSA a couple > >>>>times but you don't want for an acknowledge (you don't necessarily know your > >>>>neighbors since you are learning the state from the networks). > >>>> > >>>>I suggest you read or review section 5 of the draft. It covers all of your > >>>>concerns below. > >>>> > >>>> > >>>> > >>>>> You must do it in advance, else it is scheduled.. > >>>>> > >>>>> My definition of unscheduled is that some event occurs and > >>>>> the non-forwarding portion of the router is DOWN... No, > >>>>> time for an sys admin to do anything... > >>>>> > >>>>> The ONLY possible way is to have trap level code call > >>>>> the xmit grace-LSA code section. However, no time to > >>>>> see if acks have been rec'vd and no time for a 5 sec > >>>>> rexmit.... > >>>>> > >>>>> Ok, then WHAT is an UNSCHEDULED GRACEFUL RESTART in your > >>>>> guys opinion???? > >>>>> > >>>>> On the assumption that if the router fails and > >>>>> still abides by the condition that it is still > >>>>> forwarding as if it was still up.., then > >>>>> > >>>>> As long as there isn't any topologoy changes > >>>>> as stated within your document, that is one > >>>>> reason to allow for a graceful restart, I don't > >>>>> see the blackhole.. > >>>>> > >>>>> If the topology changes then it would invalidate > >>>>> my graceful restart, as it would also invalidate > >>>>> the graceful restart specified in the draft. > >>>>> > >>>>> The only deltas that I was asking for was: > >>>>> - the issue of sending out a minimal grace-LSA at > >>>>> adj timeframe, > >>>>> - being able to minimally update our grace-LSA as > >>>>> topology changes, > >>>>> - or we decide that we want to withdraw our grace-LSA > >>>>> via MAXAGE, > >>>>> > >>>>> As of this time, I have not read in your document, > >>>>> EXPLICITLY whether > >>>>> - you suggest to ONLY send out the grace-LSA when you > >>>>> have planned to do a restart (scheduled), > >>>>> - how to withdraw the grace-LSAs from accepted helpers > >>>>> when one proto-helper (to be helper), will not ack > >>>>> your LSA, > >>>>> - etc.. > >>>>> > >>>>> > >>>>> Mitchell Erblich > >>>>> Sr Software Engineer > >>>>> ============================ > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>Acee Lindem wrote: > >>>>> > >>>>> > >>>>> > >>>>>>Erblichs wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>>Padma, > >>>>>>> > >>>>>>> > >>>>>>> These are my last comments!! > >>>>>>> > >>>>>>> Also inline... > >>>>>>> > >>>>>>> Why doesn't the draft RFC authors want to > >>>>>>> allow non-scheduled restarts in this > >>>>>>> draft? > >>>>>> > >>>>>>Michell, > >>>>>> > >>>>>>As Padma stated, the draft supports unscheduled restarts (there > >>>>>>are multiple interoperable implementations). Your proposal to > >>>>>>announce graceful restart in advance will unnecessarily delay > >>>>>>the detection of a black hole if the restarting router is really dead > >>>>>>or was abruptly decommissioned. The current draft doesn't suffer > >>>>> > >>>>>>from this flaw. > >>>>> > >>>>> > >>>>>>> Is there something wrong with the idea > >>>>>>> of un-scheduled restarts? > >>>>>>> > >>>>>>> Why restrict it to only scheduled > >>>>>>> restarts??? > >>>>>>> > >>>>>>> Why require > >>>>>>> the grace-LSAs to be reflooded every > >>>>>>> 30 minutes to 1 hr??? > >>>>>>> > >>>>>>> Why not send the grace-LSAs without > >>>>>>> the Type=1, Length=4 grace period field?? > >>>>>>> It will be determined by the helpers > >>>>>>> anyway. > >>>>>>> > >>>>>>> The sentance is. > >>>>>>> > >>>>>>> "The number of seconds that the router's > >>>>>>> neighbors should continue to advertise the > >>>>>>> router as fully adjacent".... > >>>>>>> > >>>>>>> Thus, without the word "MUST", implimentations > >>>>>>> will probably follow their own rules. Thus, the > >>>>>>> grace period field really isn't needed and just > >>>>>>> consumes bandwidth!!! > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Mitchell Erblich > >>>>>>> =================== > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>Padma Pillay-Esnault wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>Mitchell, > >>>>>>>> > >>>>>>>>I'll try to address your comments > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>Acee Lindem, > >>>>>>>>> > >>>>>>>>> Since,, you skipped the inline re-comments, I will assume > >>>>>>>>> that at least you read them.. :) > >>>>>>>>> > >>>>>>>>> I think I have expressed as best as I could (I am not > >>>>>>>>> a tech writer) how I feel that this draft should evolve. > >>>>>>>>> > >>>>>>>>> So in summary... > >>>>>>>>> > >>>>>>>>>` 0) Remove the length (seconds) field from the grace-LSA. > >>>>>>>>> > >>>>>>>> > >>>>>>>>This is using the TLV format .. so you want to keep the length > >>>>>>> > >>>>>>> > >>>>>>> Of course, Type, Length, Value... Fine. Reword.. > >>>>>>> Remove > >>>>>>> the Grace-Period field of (Type =1, Length = 4). > >>>>>>> Why transmit the field value????? > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>> 1) Transmit DNA grace-LSAs at adj creation time. > >>>>>>>>> > >>>>>>>> > >>>>>>>>This is not very useful. Today unless you have DNA lsa you cannot > >>>>>>>>expect to be requesting a grace period of over one hour -- as > >>>>>>>>all the LSA in the other routers database will expire at the > >>>>>>>>most in 1hr. > >>>>>>>>So if you decide to send a grace LSA it would be the most recent one > >>>>>>>>that you built and hence if it has time to expire then the previous > >>>>>>>>would already be gone. > >>>>>>> > >>>>>>> > >>>>>>> Think ahead of tomarrow, not today... > >>>>>>> How should this work in the utopian word? If the graceful > >>>>>>> restart is a good idea, then it NOT should be used for ALL > >>>>>>> possible restarts?? > >>>>>>> > >>>>>>> Why not restrict the amount of flooding with THESE types > >>>>>>> of LSAs if this draft becomes a standard RFC?? > >>>>>>> > >>>>>>> What happens if I send the grace-LSAs at adj formation > >>>>>>> time and then reflood them every 55 minutes?? This > >>>>>>> removes the lightweight mechanism of the draft, but > >>>>>>> still gets me unscheduled restart functionality? Maybe > >>>>>>> i will just do that.. BTW, and also do unscheduled > >>>>>>> restarts with my BGP protocol once it becomes a > >>>>>>> standard. > >>>>>>> > >>>>>>> Thus, a restriction of 1 hr isn't sensible. Else, even if > >>>>>>> I follow your logic, then why do I ask for 1 hr? Should > >>>>>>> my implimentation in the helper not ack the grace-LSA if > >>>>>>> the specified grace-period is over 1 hr from the restarting > >>>>>>> router? This is unspecified behavior!!! > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>> 2) Let the helpers determine amount of time that > >>>>>>>>> they will function as a helper. Suggest a minimum > >>>>>>>>> of 1 hr time. > >>>>>>>>> > >>>>>>>> > >>>>>>>>This is a matter of policy .. even if the helper decides that > >>>>>>>>he is not going to help for the whole period .. as he is not > >>>>>>>>going to signal it to the restarting router .. I do not see > >>>>>>>>the use of doing so. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> 3) Reflood the DNA grace-LSAs anytime the contents > >>>>>>>>> have changed. > >>>>>>>>> > >>>>>>>> > >>>>>>>>See my response in 1. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> 4) If the restart router expects to be down for a period > >>>>>>>>> longer than X, then retransmit the Grace-LSAs as > >>>>>>>>> MAXage LSAs. > >>>>>>>>> > >>>>>>>> > >>>>>>>>I do not see the benefit or I am missing your point > >>>>>>>> > >>>>>>>>Padma > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> This would minimize bandwidth requirements and allow a > >>>>>>>>> restarting router to have either scheduled or unscheduled > >>>>>>>>> restarts. > >>>>>>>>> > >>>>>>>>> I don't know what else to add, except if you adopt one or > >>>>>>>>> more of these suggestions, then please add my name to your > >>>>>>>>> comment list. :) > >>>>>>>>> > >>>>>>>>> Mitchell Erblich > >>>>>>>>> Sr Software Engineer > >>>>>>>>> ============================ > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>Acee Lindem wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>Erblichs wrote: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>Acee Lindem, > >>>>>>>>>>> > >>>>>>>>>>> Sometimes my logic is a little obtuse.. > >>>>>>>>>>> > >>>>>>>>>>> Most of it is inline... > >>>>>>>>>>> > >>>>>>>>>>> I will first throw two new questions to you!!!! > >>>>>>>>>>> > >>>>>>>>>>> 1) Why don't you send out the Grace LSA at full > >>>>>>>>>>> adj timeframe. It would take effect after > >>>>>>>>>>> RouterDeadinterval has expired? > >>>>>>>>>> > >>>>>>>>>>How do you know, apriori, that the OSPF instance is > >>>>>>>>>>restarting and not completely dead? > >>>>>>>>> > >>>>>>>>> Why do you care? As long as the topology isn't changing > >>>>>>>>> then everything is ok. > >>>>>>>>> > >>>>>>>>> Wwhy not minimize the effects of unnecessary SPF computations? > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> This would also take care of unscheduled restarts > >>>>>>>>>>> and allow you to do an unscheduled graceful > >>>>>>>>>>> restart!!!! > >>>>>>>>>>> > >>>>>>>>>>> You could also send them as DNA LSAs.. See inline. > >>>>>>>>>>> > >>>>>>>>>>> The only new twist is that if you then schedule > >>>>>>>>>>> a restart, you may want to be able to cancel your > >>>>>>>>>>> previous request or update the LSAs over time. > >>>>>>>>>>> But if you conisder a stable topology, then why > >>>>>>>>>>> NOT?? > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> 2) A) 2.1 3rd, paragraph.. > >>>>>>>>>>> "Their age field set to 0," > >>>>>>>>>>> Why can't you send DNA grace-LSAs???? > >>>>>>>>>> > >>>>>>>>>>You wouldn't gain anything since the grace interval cannot > >>>>>>>>>>exceed the LSA refresh time. > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> So, first why do you need to specify the grace-LSA > >>>>>>>>> timeframe. Let it be implicitly known to be 1 hr! > >>>>>>>>> > >>>>>>>>> With DNA grace-LSAs, we > >>>>>>>>> don't need to reflood them. If I sent them out > >>>>>>>>> at adj creation time and the topology isn't > >>>>>>>>> changing, then I don't need to consume > >>>>>>>>> resources and keep on re-flooding them.. > >>>>>>>>> > >>>>>>>>> Thus, they can last multiple hours or longer.. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> B) 2.1, 4th paragraph. > >>>>>>>>>>> > >>>>>>>>>>> "it should retransmit... until > >>>>>>>>>>> they are acknowledged". If you can't retransmit the > >>>>>>>>>>> same LSA until 5 secs have passed, if a router > >>>>>>>>>>> was congested, you may want to resubmit the grace-LSA > >>>>>>>>>>> with a longer length timeframe to your helpers. I am > >>>>>>>>>>> assuming just bump your instance. Correct? > >>>>>>>>>> > >>>>>>>>>>There are implementations that back off LSA retransmissions and the > >>>>>>>>>>"Prioritized Treatment of Specific OSPF Packets and Congestion > >>>>>>>>>>Avoidance" draft recommends this. However, this is not standard > >>>>>>>>>>OSPF flooding as described in RFC2328 and it is an independent > >>>>>>>>>>issue. > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> No, no, you are missing my point. Until all of your grace-LSAs are > >>>>>>>>> ack'ed, you can't continue successfully with a graceful-restart. > >>>>>>>>> > >>>>>>>>> This delay consumes time that you specified in your grace-LSA. Yea, > >>>>>>>>> again, I don't know why you need to specify the amount of time!! > >>>>>>>>> The timeframe that the helpers will help you can be set independently > >>>>>>>>> and your spec doesn't allow them to communicate the amount of time > >>>>>>>>> that they will keeep around a grace-LSA. > >>>>>>>>> > >>>>>>>>> Sorry, minor sidetrack. So, the time consumed to get the ack, actually > >>>>>>>>> reduces the amount of time before the grace-LSA expires. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> Mitchell > >>>>>>>>>>> ================ > >>>>>>>>>>>Acee Lindem wrote: > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>Mitchell, > >>>>>>>>>>>> > >>>>>>>>>>>>See answers below. > >>>>>>>>>>>> > >>>>>>>>>>>>Erblichs wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>>Group, > >>>>>>>>>>>>> > >>>>>>>>>>>>> 1) Within 2.1 "Entering graceful restart", iff all > >>>>>>>>>>>>> the LSAs were from DC specified NBRs with DNA > >>>>>>>>>>>>> LSAs should the LS RefreshTime still be followed? > >>>>>>>>>>>> > >>>>>>>>>>>>LSA Refresh isn't relevant since the restarting router will > >>>>>>>>>>>>reestablish adjacencies. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Then why have a suggestion of 1800 secs for LSReshTime > >>>>>>>>>>> in your draft at the end of the 1st paragraph in section > >>>>>>>>>>> 2.1? > >>>>>>>>>>> > >>>>>>>>>>> In my scenario, there would be no reason not to let the > >>>>>>>>>>> value approach or exceed 3600 secs (1 hr). > >>>>>>>>>>> > >>>>>>>>>>> variation on a theme? Why not let the max value of your > >>>>>>>>>>> grace-LSA length field allow the helper determine what > >>>>>>>>>>> is the max that he will support? > >>>>>>>>>>> -- what happens if you specify a value that is > >>>>>>>>>>> greater than what the helper supports? > >>>>>>>>>>> Ans A: The helper sees it as an invalid request > >>>>>>>>>>> and throws away the whole request, > >>>>>>>>>>> > >>>>>>>>>>> OR > >>>>>>>>>>> Ans B: The helper determines what the length he > >>>>>>>>>>> will support? > >>>>>>>>>>> > >>>>>>>>>>> If it is B, then why have the length field. Just let > >>>>>>>>>>> the helper decide how long to support the request? > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> 2) Within 2.2 "When to exit graceful restart", number > >>>>>>>>>>>>> (3) "The grace period expires". > >>>>>>>>>>>>> > >>>>>>>>>>>>> What happens if we follow #3 and your #1 "reestablished > >>>>>>>>>>>>> all its adjacencies" criteria is not met? > >>>>>>>>>>>> > >>>>>>>>>>>>The restarting router will exit graceful restart anyway. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Why? If you still have a non-changing topology, why > >>>>>>>>>>> limit the value to what you had said to the helpers? > >>>>>>>>>>> > >>>>>>>>>>> So, what if you asked for x time and it took you > >>>>>>>>>>> x + y time? > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> Or are you stating that the specified "grace period" was > >>>>>>>>>>>>> to short to perform what was required? > >>>>>>>>>>>> > >>>>>>>>>>>>Not necessarily - perhaps the topology has changed and graceful restart > >>>>>>>>>>>>cannot be completed successfully. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> 3) Within 2.2. Would seeing a hello without the graceful > >>>>>>>>>>>>> restarting router id", force it to exit? > >>>>>>>>>>>> > >>>>>>>>>>>>No. The adjacency can go all the way down on the helper router. The hello > >>>>>>>>>>>>shouldn't be used as a criteria for exiting helper mode. Do not confuse > >>>>>>>>>>>>this with other graceful restart proposals. > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> I see that my question with the hello was answered in the > >>>>>>>>>>> 2. (3) "an hello packet is received".. > >>>>>>>>>>> > >>>>>>>>>>> I am confused. One router may list you as the DR and another > >>>>>>>>>>> may not? If one is a helper, then why would it take the adj > >>>>>>>>>>> down if all the crieria were met? > >>>>>>>>>>> > >>>>>>>>>>> I thought that helpers > >>>>>>>>>>> MUST send hellos as if you (graceful restarting router) were > >>>>>>>>>>> still there!! > >>>>>>>>>>> "an Hello packet is received from a neighbor listing the > >>>>>>>>>>> router as the Designated Router". > >>>>>>>>>>> > >>>>>>>>>>> If it did keep anouncing you in the hellos (you weren't > >>>>>>>>>>> the DR) and lets say that the DR went down. Could you > >>>>>>>>>>> then be elected as the DR while you were still rebooting? > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> 4) Within 2.2. Would seeing a hello without the graceful > >>>>>>>>>>>>> restarting router id as the earlier DR or BDR, cause > >>>>>>>>>>>>> it to exit, if it was a DR / BDR? > >>>>>>>>>>>> > >>>>>>>>>>>>Not directly, but an inconsistency with the pre-restart LSA will cause > >>>>>>>>>>>>the restarting router to exist graceful restart prematurely. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> 5) Within 2.2. Is it implimentation dependent on how we > >>>>>>>>>>>>> determine our existing nbrs and place their router ids > >>>>>>>>>>>>> in a hello? > >>>>>>>>>>>> > >>>>>>>>>>>>This isn't changed for graceful restart. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> I thought that you could save past nbr-ids in NVRAM > >>>>>>>>>>> and then compare to existing hellos... > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> 6) Within 2.2 (1), isn't adj establishment partly the > >>>>>>>>>>>>> recieving of hellos, with your own router-id? Shouldn't > >>>>>>>>>>>>> that inform others that we are back and to cancel > >>>>>>>>>>>>> their helper graceful nbr timer? > >>>>>>>>>>>>> > >>>>>>>>>>>>> 7 & 8) Within 2.3 "Actions on exiting graceful restart". > >>>>>>>>>>>>> > >>>>>>>>>>>>> 7) Shouldn't the sending hellos be performed that > >>>>>>>>>>>>> identify full adj be a criteria here? > >>>>>>>>>>>> > >>>>>>>>>>>>No. LSA convergence with the pre-restart LSAs is a much surer > >>>>>>>>>>>>mechanism for determining the graceful restart can be exited. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> 8) I am unsure whether you are specifying the > >>>>>>>>>>>>> storage of part of restarting router's LSDB into > >>>>>>>>>>>>> non-volatile memory. If so, then upon retrieval, > >>>>>>>>>>>>> shouldn't some elements of the LSDB be aged > >>>>>>>>>>>>> by the amount that the actual amount of time > >>>>>>>>>>>>> the LSAs were in NV memory? > >>>>>>>>>>>> > >>>>>>>>>>>>There is no mention of storing LSAs in non-volatile storage. > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Ok, you aren't suggesting saving the LSDB in NVRAM > >>>>>>>>>>> or some other type of storage media.. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> Mitchell Erblich > >>>>>>>>>>>>> ================================== > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>-- > >>>>>>>>>>>>Acee > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>-- > >>>>>>>>>>Acee > >>>>>>>>> > >>>>>>-- > >>>>>>Acee > >>>>> > >>>>> > >>>>-- > >>>>Acee > >>> > >>> > >>-- > >>Acee > > > > > > -- > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon Apr 14 19:24:46 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26628 for ; Mon, 14 Apr 2003 19:24:46 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.009788B7@cherry.ease.lsoft.com>; Mon, 14 Apr 2003 19:27:23 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 663520 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 14 Apr 2003 19:27:23 -0400 Received: from 207.217.120.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 14 Apr 2003 19:27:23 -0400 Received: from user-38lc085.dialup.mindspring.com ([209.86.1.5] helo=earthlink.net) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 195DM9-0001SL-00 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 14 Apr 2003 16:27:22 -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: <3E9B2683.906AF31B@earthlink.net> <3E9B381D.30203@juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E9B3D5E.BC54D84C@earthlink.net> Date: Mon, 14 Apr 2003 15:59:42 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Graceful restart vs max-metric graceful ... To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Inlin... Mitchell.... Padma Pillay-Esnault wrote: > > Mitchell, > > See inline comments > > Erblichs wrote: > > >Group, > > > > Max-metric vs graceful restart > > ------------------------------- > > > > There are a number of routers that currently support > > advertising max-metric LSAs for a period of time > > during router bootup and at shutdown. > > > > The reason behind this is due to the fact that we > > don't want to handle transit packets until we > > have basicly completed our SPF calculations and > > inserted the majority of the forwarding entries. > > > > After a period of time has passed (some companies > > call it announce-time), we then re-originate our > > LSAs with the normal metrics. > > > > I would like to know whether there is a > > belief that the max-metric functionality and > > graceful restart is compatible OR whether their > > is a belief that max-metric functionality is > > obsoleted by graceful restart??? > > > The two problems are orthogonal .. In the case of overloading > a router - the router is avoided because it doesn't have the routes > in its routing table. In the graceful restart case we assume that the > router has its forwarding plane functioning and hence is able to > forward packets. > > > > > Also .... Blackhole event > > > > Upon restart, when a a topology > > change has occured on possibly just 1 interface. > > Then packets transiting from a valid helper interface > > segment to a now non-valid interface segment > > will be dropped for the duration that can > > approach 1 hr. Right??? > > > I suppose you mean that the change in topology is in the restarting > router itself or else graceful restart is aborted. > Now remember that a graceful restart means that all is fine in the > router .. any change in topology should abort the restart. > > > > > How does one helper on 1 interface know about > > other helpers (or non-helpers) on other interfaces/ > > segments. If OSPF control functionality is inoperable, > > then we are unable to transmit LSAs to inform that > > an interface has gone down between the time that > > we transmitted our grace-LSAs and the time that > > are are now restarting. > > > Again, we are under the assumption that the forwarding capabilities > are intact .. if it isn't then we cannot magically get the packets across > graceful restart or not. > Yes, our forwarding is intact. 1) We Sucessfully "enter graceful-restart". 2) We down our control section of the router. 3) A helper on a segment/interface dies ... Our other helpers on different interfaces are ok. 4) We exit graceful restart. and fail it due to #3. At #3, due to the fact that a helper died, and we have no control section, traffic forwarded thru one interface transiting the down helper is lost.. We cannot insert a new forward element in our forwarding table until we get back our control section sometime after #4. In effect, we have 1-way traffic.. that is lost.. Right??? > > Thus, should a graceful restarting router > > transmit max-metric LSAs before shutdown > > to minimize transiting packets > > in case we loose a helper on one OR more > > of our interfaces? > > > > We will be avoiding the restart router .. which is not what we intend > > Padma > > > > > Mitchell Erblich > > Sr. Software Engineer > > ----------------------------- > > > > From owner-ospf@DISCUSS.MICROSOFT.COM Mon Apr 14 19:36:34 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26837 for ; Mon, 14 Apr 2003 19:36:34 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00978A94@cherry.ease.lsoft.com>; Mon, 14 Apr 2003 19:39:11 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 663636 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 14 Apr 2003 19:39:11 -0400 Received: from 207.217.120.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 14 Apr 2003 19:39:11 -0400 Received: from user-38lc085.dialup.mindspring.com ([209.86.1.5] helo=earthlink.net) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 195DXZ-000327-00 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 14 Apr 2003 16:39:10 -0700 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <029601c302aa$05beebc0$81c802c0@alok> <3E9AF59A.EDDEA082@earthlink.net> <1376.219.65.135.92.1050347600.squirrel@mail.apara.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E9B4022.E2672125@earthlink.net> Date: Mon, 14 Apr 2003 16:11:30 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Changing router name... To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Alok, Simplying, multiple OSPF process support has additional requirements. One CAN NOT just takes the highest value interface or select a loopback. If there are multiple interfaces or loopbacks, then one must be able to identify that the object in question has been allocated to a particular process and thus is not eligible to be allocated a 2nd time.. Mitchell Erblich Sr Software Engineer ---------------------------------- Alok Dube wrote: > > multiple loopbacks...at least 1 per vrf. > > "preferably" (thats my preference as i anyways get a /32 for router-id, > why introduce a lo0/32 too to make it reachable via tha OSPF process?) > each loopback being the "router-id" for that ospf-process? (presuming ospf > process are dosjoint sets / 2 seperate OSPF instances not releated to one > another).... > > Group, > > > > If you would be running two or more OSPF > > processes within your router, do you > > still want them both to use the highest > > interface or both use the loopback interface > > as the router-id? > > > > Mitchell Erblich > > Sr . Software Engineer > > ---------------------------- > > > > alok wrote: > >> > >> ----- Original Message ----- > >> From: john151@libero.it > >> To: > >> Sent: Monday, April 14, 2003 10:12 PM > >> Subject: Re: Changing router name... > >> > >> > Hi Alok, hi all, > >> > > >> > >it would be router-id > >> > yes i intended router-id: router-id is the number of the > >> > highest interface on a router, isn' t it? > >> > > >> > >in general you would make loopback as router-id (i think) > >> > NO > >> > >> why not? From owner-ospf@DISCUSS.MICROSOFT.COM Mon Apr 14 21:04:37 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29338 for ; Mon, 14 Apr 2003 21:04:36 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00978BDD@cherry.ease.lsoft.com>; Mon, 14 Apr 2003 21:07:12 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 663923 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 14 Apr 2003 21:07:12 -0400 Received: from 203.178.143.91 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 14 Apr 2003 21:07:12 -0400 Received: from localhost (localhost [127.0.0.1]) by plant.sfc.wide.ad.jp (Postfix) with ESMTP id 78BB52D162; Tue, 15 Apr 2003 10:07:10 +0900 (JST) References: <3E9AF59A.EDDEA082@earthlink.net> <1376.219.65.135.92.1050347600.squirrel@mail.apara.com> <3E9B4022.E2672125@earthlink.net> X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20030415.100708.115585230.yasu@sfc.wide.ad.jp> Date: Tue, 15 Apr 2003 10:07:08 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: Changing router name... Comments: To: erblichs@EARTHLINK.NET To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E9B4022.E2672125@earthlink.net> Precedence: list Content-Transfer-Encoding: 7bit Hi, Erblichs > Simplying, multiple OSPF process support has > additional requirements. > > One CAN NOT just takes the highest value > interface or select a loopback. I don't think so. To be more precise, taking the highest value as RID for a particular OSPF process will be above "the interfaces enabled for that OSPF process". Generally it is likely that the operational interfaces differs per OSPF processes (and it may not be even overlapped). Changing which interface to enable per OSPF processes is the easiest way to controlling RID for the process, on the simplest algorithm to choose RID (i.e. choosing highest value). Configuring multiple loopback interface implies this I guess. > If there are multiple interfaces or > loopbacks, then one must be able to identify > that the object in question has been allocated > to a particular process and thus is not eligible > to be allocated a 2nd time.. Besides all, using the same RID for multiple OSPF process will have no problem. What RID require is just to be unique within a OSPF domain. If OSPF domain differs, duplication of RID does not break anything. regards, yasu From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 15 00:28:26 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03177 for ; Tue, 15 Apr 2003 00:28:26 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00979419@cherry.ease.lsoft.com>; Tue, 15 Apr 2003 0:28:18 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 664379 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 15 Apr 2003 00:28:17 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 15 Apr 2003 00:28:17 -0400 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 1221BA29161 for ; Mon, 14 Apr 2003 21:27:01 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030413161512.92837.qmail@web10908.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E9B898C.9050304@redback.com> Date: Tue, 15 Apr 2003 00:24:44 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Multiple un-numbered serial links between two routers To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit j j wrote: > Can OSPF support this? Seems like there isn't enough > information in Router LSA to distinctly identify the > interfaces for nexthop information. JJ, You are correct - a router link in a router LSA doesn't provide you with enough information to distinctly identify parallel unnumbered links. Note that an IP next hop address is not necessary for a point-to-point link (see section 16.1.1 in RFC 2328). > > Or is this an invalid configuration on a router? There are a number of implementation choices one could make. One is to consider all the advertised parallel unnumbered links valid as long there is bi-directional connectivity via one of them. Another would be to consider the configuration invalid. > > > thanks > > __________________________________________________ > Do you Yahoo!? > Yahoo! Tax Center - File online, calculators, forms, and more > http://tax.yahoo.com > Hope this helps, -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 15 00:34:25 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03338 for ; Tue, 15 Apr 2003 00:34:25 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00979552@cherry.ease.lsoft.com>; Tue, 15 Apr 2003 0:37:03 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 664424 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 15 Apr 2003 00:37:03 -0400 Received: from 136.182.1.10 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 15 Apr 2003 00:37:02 -0400 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h3F4b2d9016310 for ; Mon, 14 Apr 2003 21:37:02 -0700 (MST) Received: [from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id VAA00824 for ; Mon, 14 Apr 2003 21:37:02 -0700 (MST)] Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id <2D45CSF7>; Tue, 15 Apr 2003 00:36:53 -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, 15 Apr 2003 00:38:47 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Multiple un-numbered serial links between two routers To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Jj, I agree with Acee. I am not sure why we compulsarily need to have multiple parallel links between two routers advertized in the LSA, for normal SPF. I think if we advertize the minimum cost unnumbered parallel link, it would serve the same purpose for SPF calculations. I think something similar is done for "neighbor reachability"(something similar to a link in Router LSA) in case of ISIS, in most implementations. Thanks, Vishwas -----Original Message----- From: Acee Lindem [mailto:acee@REDBACK.COM] Sent: Tuesday, April 15, 2003 9:55 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Multiple un-numbered serial links between two routers j j wrote: > Can OSPF support this? Seems like there isn't enough > information in Router LSA to distinctly identify the > interfaces for nexthop information. JJ, You are correct - a router link in a router LSA doesn't provide you with enough information to distinctly identify parallel unnumbered links. Note that an IP next hop address is not necessary for a point-to-point link (see section 16.1.1 in RFC 2328). > > Or is this an invalid configuration on a router? There are a number of implementation choices one could make. One is to consider all the advertised parallel unnumbered links valid as long there is bi-directional connectivity via one of them. Another would be to consider the configuration invalid. > > > thanks > Hope this helps, -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 15 11:32:37 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01530 for ; Tue, 15 Apr 2003 11:32:37 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.0097A470@cherry.ease.lsoft.com>; Tue, 15 Apr 2003 11:35:13 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 663281 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 15 Apr 2003 11:35:13 -0400 Received: from 216.136.131.37 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 15 Apr 2003 11:35:13 -0400 Received: from [209.179.250.86] by web10901.mail.yahoo.com via HTTP; Tue, 15 Apr 2003 08:35:12 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20030415153512.39094.qmail@web10901.mail.yahoo.com> Date: Tue, 15 Apr 2003 08:35:12 -0700 Reply-To: Mailing List Sender: Mailing List From: j j Subject: Re: Multiple un-numbered serial links between two routers To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Hi Vishwas, You ask why we need to have multiple links advertised. How can we do equal cost multipath if there were other vertices behind the second router? For e.g. R1 and R2 has multiple unnumbered links. Behind R2 are other vertices. R1 is the calculating router. These vertices should have multiple nexthops. I agree that nexthop IP address is not needed. But my dilemma is that as SPF is going through the links in R2's rtr LSA, there isn't enough information to map those link id's to egress ifnum on R1. thanks --- "Manral, Vishwas" wrote: > Hi Jj, > > I agree with Acee. I am not sure why we compulsarily > need to have multiple > parallel links between two routers advertized in the > LSA, for normal SPF. > > I think if we advertize the minimum cost unnumbered > parallel link, it would > serve the same purpose for SPF calculations. I think > something similar is > done for "neighbor reachability"(something similar > to a link in Router LSA) > in case of ISIS, in most implementations. > > Thanks, > Vishwas > > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Tuesday, April 15, 2003 9:55 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: Multiple un-numbered serial links > between two routers > > > j j wrote: > > Can OSPF support this? Seems like there isn't > enough > > information in Router LSA to distinctly identify > the > > interfaces for nexthop information. > > JJ, > > You are correct - a router link in a router LSA > doesn't > provide you with enough information to distinctly > identify > parallel unnumbered links. Note that an IP next hop > address is not necessary for a point-to-point link > (see section > 16.1.1 in RFC 2328). > > > > > Or is this an invalid configuration on a router? > > There are a number of implementation choices one > could > make. One is to consider all the advertised parallel > unnumbered > links valid as long there is bi-directional > connectivity > via one of them. Another would be to consider the > configuration > invalid. > > > > > > > thanks > > > > Hope this helps, > -- > Acee __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 15 12:35:04 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03393 for ; Tue, 15 Apr 2003 12:35:04 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0097A88C@cherry.ease.lsoft.com>; Tue, 15 Apr 2003 12:37:38 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 663489 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 15 Apr 2003 12:37:38 -0400 Received: from 144.189.100.105 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 15 Apr 2003 12:37:37 -0400 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h3FGbaNb013249 for ; Tue, 15 Apr 2003 09:37:37 -0700 (MST) Received: [from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id JAA10628 for ; Tue, 15 Apr 2003 09:37:36 -0700 (MST)] Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id <2D45CTHZ>; Tue, 15 Apr 2003 12:37:28 -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, 15 Apr 2003 12:39:24 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: Multiple un-numbered serial links between two routers To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi JJ, Let me explain L1 ---------- L3 A L2 B ----------C ---------- Assume a topology like the above, where A, S, C are routers and L1, L2 and L3 are networks. If L1 and L2 are equal costs at A. In A's routing table the path to destination learnt from C would be thru both L1 and L2, and as A knows the costs of the two interfaces is the same, so it will create ECMP's. Now in case of C there will be just one path to any destination learnt from D that is thru L3. B will have the ECMP in this case. Let me know if I am any clearer now. Thanks, Vishwas -----Original Message----- From: j j [mailto:jsangh2002@YAHOO.COM] Sent: Tuesday, April 15, 2003 9:05 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: Multiple un-numbered serial links between two routers Hi Vishwas, You ask why we need to have multiple links advertised. How can we do equal cost multipath if there were other vertices behind the second router? For e.g. R1 and R2 has multiple unnumbered links. Behind R2 are other vertices. R1 is the calculating router. These vertices should have multiple nexthops. I agree that nexthop IP address is not needed. But my dilemma is that as SPF is going through the links in R2's rtr LSA, there isn't enough information to map those link id's to egress ifnum on R1. thanks --- "Manral, Vishwas" wrote: > Hi Jj, > > I agree with Acee. I am not sure why we compulsarily > need to have multiple > parallel links between two routers advertized in the > LSA, for normal SPF. > > I think if we advertize the minimum cost unnumbered > parallel link, it would > serve the same purpose for SPF calculations. I think > something similar is > done for "neighbor reachability"(something similar > to a link in Router LSA) > in case of ISIS, in most implementations. > > Thanks, > Vishwas > > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Tuesday, April 15, 2003 9:55 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: Multiple un-numbered serial links > between two routers > > > j j wrote: > > Can OSPF support this? Seems like there isn't > enough > > information in Router LSA to distinctly identify > the > > interfaces for nexthop information. > > JJ, > > You are correct - a router link in a router LSA > doesn't > provide you with enough information to distinctly > identify > parallel unnumbered links. Note that an IP next hop > address is not necessary for a point-to-point link > (see section > 16.1.1 in RFC 2328). > > > > > Or is this an invalid configuration on a router? > > There are a number of implementation choices one > could > make. One is to consider all the advertised parallel > unnumbered > links valid as long there is bi-directional > connectivity > via one of them. Another would be to consider the > configuration > invalid. > > > > > > > thanks > > > > Hope this helps, > -- > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 15 13:11:03 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04366 for ; Tue, 15 Apr 2003 13:11: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.0097AACC@cherry.ease.lsoft.com>; Tue, 15 Apr 2003 13:13:40 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 663633 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 15 Apr 2003 13:13:39 -0400 Received: from 216.136.131.40 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 15 Apr 2003 13:13:39 -0400 Received: from [63.251.235.202] by web10904.mail.yahoo.com via HTTP; Tue, 15 Apr 2003 10:13:39 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20030415171339.36237.qmail@web10904.mail.yahoo.com> Date: Tue, 15 Apr 2003 10:13:39 -0700 Reply-To: Mailing List Sender: Mailing List From: j j Subject: Re: Multiple un-numbered serial links between two routers To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list I was only pointing out the fact that if routers advertised only one link, we would not be able to do ecmp. All I am saying is that If I took your example and went through the steps as listed in rfc2328 for nexthop calculations, I would not be able to get correct results. --- "Manral, Vishwas" wrote: > Hi JJ, > > Let me explain > L1 > ---------- L3 > A L2 B ----------C > ---------- > > Assume a topology like the above, where A, S, C are > routers and L1, L2 and > L3 are networks. > > If L1 and L2 are equal costs at A. > > In A's routing table the path to destination learnt > from C would be thru > both L1 and L2, and as A knows the costs of the two > interfaces is the same, > so it will create ECMP's. > > Now in case of C there will be just one path to any > destination learnt from > D that is thru L3. B will have the ECMP in this > case. > > Let me know if I am any clearer now. > > Thanks, > Vishwas > > -----Original Message----- > From: j j [mailto:jsangh2002@YAHOO.COM] > Sent: Tuesday, April 15, 2003 9:05 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: Multiple un-numbered serial links > between two routers > > > Hi Vishwas, > > You ask why we need to have multiple links > advertised. > How can we do equal cost multipath if there were > other vertices behind the second router? For e.g. > R1 and R2 has multiple unnumbered links. Behind R2 > are other vertices. R1 is the calculating router. > > These vertices should have multiple nexthops. I > agree > that nexthop IP address is not needed. But my > dilemma > is that as SPF is going through the links in R2's > rtr > LSA, there isn't enough information to map those > link > id's to egress ifnum on R1. > > > > thanks > > > > > > --- "Manral, Vishwas" wrote: > > Hi Jj, > > > > I agree with Acee. I am not sure why we > compulsarily > > need to have multiple > > parallel links between two routers advertized in > the > > LSA, for normal SPF. > > > > I think if we advertize the minimum cost > unnumbered > > parallel link, it would > > serve the same purpose for SPF calculations. I > think > > something similar is > > done for "neighbor reachability"(something similar > > to a link in Router LSA) > > in case of ISIS, in most implementations. > > > > Thanks, > > Vishwas > > > > -----Original Message----- > > From: Acee Lindem [mailto:acee@REDBACK.COM] > > Sent: Tuesday, April 15, 2003 9:55 AM > > To: OSPF@DISCUSS.MICROSOFT.COM > > Subject: Re: Multiple un-numbered serial links > > between two routers > > > > > > j j wrote: > > > Can OSPF support this? Seems like there isn't > > enough > > > information in Router LSA to distinctly identify > > the > > > interfaces for nexthop information. > > > > JJ, > > > > You are correct - a router link in a router LSA > > doesn't > > provide you with enough information to distinctly > > identify > > parallel unnumbered links. Note that an IP next > hop > > address is not necessary for a point-to-point link > > (see section > > 16.1.1 in RFC 2328). > > > > > > > > Or is this an invalid configuration on a router? > > > > There are a number of implementation choices one > > could > > make. One is to consider all the advertised > parallel > > unnumbered > > links valid as long there is bi-directional > > connectivity > > via one of them. Another would be to consider the > > configuration > > invalid. > > > > > > > > > > > thanks > > > > > > > Hope this helps, > > -- > > Acee __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 15 14:04:58 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05738 for ; Tue, 15 Apr 2003 14:04:57 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.0097AAC0@cherry.ease.lsoft.com>; Tue, 15 Apr 2003 14:07:35 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 663761 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 15 Apr 2003 14:07:34 -0400 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 15 Apr 2003 14:07:34 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA20829 for ; Tue, 15 Apr 2003 14:07:33 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA02719 for ; Tue, 15 Apr 2003 14:07:33 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <2BD2BKJ7>; Tue, 15 Apr 2003 14:07:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC557635E0@vie-msgusr-01.dc.fore.com> Date: Tue, 15 Apr 2003 14:07:28 -0400 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: Multiple un-numbered serial links between two routers To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list -> I agree with Acee. I am not sure why we compulsarily need to -> have multiple -> parallel links between two routers advertized in the LSA, -> for normal SPF. Recently, the same design issue has been discussed in MANET routing. It is in fact a wrong choice in OSPFv2 regarding *identifying* unnumbered links. OSPFv3 uses the link local address to solve the problem. GMPLS Unnumbered also solved this problem using link local LSAs. One of the excellent extracts from Fred's mail: In a number of cases, it is possible to come up with more than one way to get to a specified neighbor and it is important for operational reasons which route you take. If you can't identify them easily, you can't do this. So it is not sufficient to say "I have two routes to this neighbor", you have to be able to identify them. Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 15 14:48:09 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06960 for ; Tue, 15 Apr 2003 14:48: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.0097ACAD@cherry.ease.lsoft.com>; Tue, 15 Apr 2003 14:50:46 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 663897 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 15 Apr 2003 14:50:46 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 15 Apr 2003 14:50:46 -0400 Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 95B67531445; Tue, 15 Apr 2003 11:50:45 -0700 (PDT) Message-ID: <20030415185045.95B67531445@prattle.redback.com> Date: Tue, 15 Apr 2003 11:50:45 -0700 Reply-To: Mailing List Sender: Mailing List From: Naiming Shen Subject: Re: Multiple un-numbered serial links between two routers To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Mail from j j dated Tue, 15 Apr 2003 10:13:39 PDT <20030415171339.36237.qmail@web10904.mail.yahoo.com> Precedence: list ] I was only pointing out the fact that if routers ] advertised only one link, we would not be able to ] do ecmp. Just imagine the L1 and L2 belong to a link bundle between A and B. From C's point of view, it does not need to know this link bundle has only one link or 5 links. From B's point of view, it knows exactly how many links it needs to do ecmp over that link bundle. (my example is a little extreme, but it should serve the purpose). cheers. ] ] All I am saying is that If I took your example and ] went through the steps as listed in rfc2328 for ] nexthop calculations, I would not be able ] to get correct results. ] ] ] ] --- "Manral, Vishwas" wrote: ] > Hi JJ, ] > ] > Let me explain ] > L1 ] > ---------- L3 ] > A L2 B ----------C ] > ---------- ] > ] > Assume a topology like the above, where A, S, C are ] > routers and L1, L2 and ] > L3 are networks. ] > ] > If L1 and L2 are equal costs at A. ] > ] > In A's routing table the path to destination learnt ] > from C would be thru ] > both L1 and L2, and as A knows the costs of the two ] > interfaces is the same, ] > so it will create ECMP's. ] > ] > Now in case of C there will be just one path to any ] > destination learnt from ] > D that is thru L3. B will have the ECMP in this ] > case. ] > ] > Let me know if I am any clearer now. ] > ] > Thanks, ] > Vishwas ] > ] > -----Original Message----- ] > From: j j [mailto:jsangh2002@YAHOO.COM] ] > Sent: Tuesday, April 15, 2003 9:05 PM ] > To: OSPF@DISCUSS.MICROSOFT.COM ] > Subject: Re: Multiple un-numbered serial links ] > between two routers ] > ] > ] > Hi Vishwas, ] > ] > You ask why we need to have multiple links ] > advertised. ] > How can we do equal cost multipath if there were ] > other vertices behind the second router? For e.g. ] > R1 and R2 has multiple unnumbered links. Behind R2 ] > are other vertices. R1 is the calculating router. ] > ] > These vertices should have multiple nexthops. I ] > agree ] > that nexthop IP address is not needed. But my ] > dilemma ] > is that as SPF is going through the links in R2's ] > rtr ] > LSA, there isn't enough information to map those ] > link ] > id's to egress ifnum on R1. ] > ] > ] > ] > thanks ] > ] > ] > ] > ] > ] > --- "Manral, Vishwas" wrote: ] > > Hi Jj, ] > > ] > > I agree with Acee. I am not sure why we ] > compulsarily ] > > need to have multiple ] > > parallel links between two routers advertized in ] > the ] > > LSA, for normal SPF. ] > > ] > > I think if we advertize the minimum cost ] > unnumbered ] > > parallel link, it would ] > > serve the same purpose for SPF calculations. I ] > think ] > > something similar is ] > > done for "neighbor reachability"(something similar ] > > to a link in Router LSA) ] > > in case of ISIS, in most implementations. ] > > ] > > Thanks, ] > > Vishwas ] > > ] > > -----Original Message----- ] > > From: Acee Lindem [mailto:acee@REDBACK.COM] ] > > Sent: Tuesday, April 15, 2003 9:55 AM ] > > To: OSPF@DISCUSS.MICROSOFT.COM ] > > Subject: Re: Multiple un-numbered serial links ] > > between two routers ] > > ] > > ] > > j j wrote: ] > > > Can OSPF support this? Seems like there isn't ] > > enough ] > > > information in Router LSA to distinctly identify ] > > the ] > > > interfaces for nexthop information. ] > > ] > > JJ, ] > > ] > > You are correct - a router link in a router LSA ] > > doesn't ] > > provide you with enough information to distinctly ] > > identify ] > > parallel unnumbered links. Note that an IP next ] > hop ] > > address is not necessary for a point-to-point link ] > > (see section ] > > 16.1.1 in RFC 2328). ] > > ] > > > ] > > > Or is this an invalid configuration on a router? ] > > ] > > There are a number of implementation choices one ] > > could ] > > make. One is to consider all the advertised ] > parallel ] > > unnumbered ] > > links valid as long there is bi-directional ] > > connectivity ] > > via one of them. Another would be to consider the ] > > configuration ] > > invalid. ] > > ] > > > ] > > > ] > > > thanks ] > > > ] > > ] > > Hope this helps, ] > > -- ] > > Acee ] ] ] __________________________________________________ ] Do you Yahoo!? ] The New Yahoo! Search - Faster. Easier. Bingo ] http://search.yahoo.com - Naiming From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 15 14:51:07 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07047 for ; Tue, 15 Apr 2003 14:51:07 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0097AE9E@cherry.ease.lsoft.com>; Tue, 15 Apr 2003 14:53:46 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 663921 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 15 Apr 2003 14:53:46 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 15 Apr 2003 14:53:46 -0400 Received: from redback.com (login005.redback.com [155.53.12.60]) by prattle.redback.com (Postfix) with ESMTP id D7746531445 for ; Tue, 15 Apr 2003 11:52:33 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <39469E08BD83D411A3D900204840EC557635E0@vie-msgusr-01.dc.fore.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E9C5461.4030901@redback.com> Date: Tue, 15 Apr 2003 14:50:09 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Multiple un-numbered serial links between two routers To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Naidu, Venkata wrote: > -> I agree with Acee. I am not sure why we compulsarily need to > -> have multiple > -> parallel links between two routers advertized in the LSA, > -> for normal SPF. > > Recently, the same design issue has been discussed in > MANET routing. It is in fact a wrong choice in OSPFv2 > regarding *identifying* unnumbered links. OSPFv3 uses > the link local address to solve the problem. GMPLS > Unnumbered also solved this problem using link local LSAs. > > One of the excellent extracts from Fred's mail: > In a number of cases, it is possible to come up with > more than one way to get to a specified neighbor and > it is important for operational reasons which route > you take. If you can't identify them easily, you can't > do this. So it is not sufficient to say > "I have two routes to this neighbor", you have to be > able to identify them. What can't be done with parallel unnumbered link is the back link check described in RFC 2328 section 16.1 (2)(b). The base OSPF protocol doesn't provide a solution. I still see it as an implementation choice as what to do. You can: 1. Use them all the parallel unnumbered links. 2. Only use one an unnumbered link if it is not a parallel link. 3. Use a mechanism outside the base protocol (as discussed above). Thanks, Acee > > Venkata. > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 15 19:28:42 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16492 for ; Tue, 15 Apr 2003 19:28:41 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.0097B88D@cherry.ease.lsoft.com>; Tue, 15 Apr 2003 19:31:19 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 664885 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 15 Apr 2003 19:31:19 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 15 Apr 2003 19:31:19 -0400 Received: from juniper.net (wawa.juniper.net [172.17.20.55]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h3FNVIu95363 for ; Tue, 15 Apr 2003 16:31:18 -0700 (PDT) (envelope-from dennis@juniper.net) X-Mailer: exmh version 2.0.2 2/24/98 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200304152331.h3FNVIu95363@merlot.juniper.net> Date: Tue, 15 Apr 2003 16:31:18 -0700 Reply-To: Mailing List Sender: Mailing List From: Dennis Ferguson Subject: Re: Multiple un-numbered serial links between two routers To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Your message of "Tue, 15 Apr 2003 14:50:09 EDT." <3E9C5461.4030901@redback.com> Precedence: list Acee Lindem wrote: > Naidu, Venkata wrote: > > -> I agree with Acee. I am not sure why we compulsarily need to > > -> have multiple > > -> parallel links between two routers advertized in the LSA, > > -> for normal SPF. > > > > Recently, the same design issue has been discussed in > > MANET routing. It is in fact a wrong choice in OSPFv2 > > regarding *identifying* unnumbered links. OSPFv3 uses > > the link local address to solve the problem. GMPLS > > Unnumbered also solved this problem using link local LSAs. > > > > One of the excellent extracts from Fred's mail: > > In a number of cases, it is possible to come up with > > more than one way to get to a specified neighbor and > > it is important for operational reasons which route > > you take. If you can't identify them easily, you can't > > do this. So it is not sufficient to say > > "I have two routes to this neighbor", you have to be > > able to identify them. > > What can't be done with parallel unnumbered link is the > back link check described in RFC 2328 section 16.1 (2)(b). > The base OSPF protocol doesn't provide a solution. I still > see it as an implementation choice as what to do. You can: > > 1. Use them all the parallel unnumbered links. > 2. Only use one an unnumbered link if it is not a parallel > link. > 3. Use a mechanism outside the base protocol (as discussed > above). I may just be dumb but I don't get how putting addresses on the p2p links fixes much of anything compared to not having them. Even if you've got addresses configured on the p2p links there is nothing in the base protocol which requires both ends to agree on this configuration, or which would guarantee that the addresses are unique, or which would prevent circuits from being used (or even make it desirable to not use the circuit) if there were a mismatch, so within the base protocol you can't really depend on address configuration on p2p links even if it is there. It doesn't seem to change anything. That is, the routers attached to the links will need to depend on their adjacency databases to determine which of the circuits are bidirectional, addresses or not, while routers not attached to the links won't have any certain idea of which of the links are actually in service, addresses or not. What part of RFC 2328 makes section 16.1(2)(b) work better when you have addresses on the p2p links? It seems like trying to use addresses to tell you anything more than you would know without the addresses is a mechanism as far outside the protocol as, say, configuring or exchanging the ifindices for unnumbered links would be. Dennis Ferguson From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 16 00:36:01 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22570 for ; Wed, 16 Apr 2003 00: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 <19.0097C7EC@cherry.ease.lsoft.com>; Wed, 16 Apr 2003 0:38:38 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 665816 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 16 Apr 2003 00:38:37 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 16 Apr 2003 00:38:37 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id CF4194A6F24 for ; Tue, 15 Apr 2003 21:38:35 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <200304152331.h3FNVIu95363@merlot.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E9CDDB5.308@redback.com> Date: Wed, 16 Apr 2003 00:36:05 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Multiple un-numbered serial links between two routers To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Dennis Ferguson wrote: > Acee Lindem wrote: > >>Naidu, Venkata wrote: >> >>>-> I agree with Acee. I am not sure why we compulsarily need to >>>-> have multiple >>>-> parallel links between two routers advertized in the LSA, >>>-> for normal SPF. >>> >>> Recently, the same design issue has been discussed in >>> MANET routing. It is in fact a wrong choice in OSPFv2 >>> regarding *identifying* unnumbered links. OSPFv3 uses >>> the link local address to solve the problem. GMPLS >>> Unnumbered also solved this problem using link local LSAs. >>> >>> One of the excellent extracts from Fred's mail: >>> In a number of cases, it is possible to come up with >>> more than one way to get to a specified neighbor and >>> it is important for operational reasons which route >>> you take. If you can't identify them easily, you can't >>> do this. So it is not sufficient to say >>> "I have two routes to this neighbor", you have to be >>> able to identify them. >> >>What can't be done with parallel unnumbered link is the >>back link check described in RFC 2328 section 16.1 (2)(b). >>The base OSPF protocol doesn't provide a solution. I still >>see it as an implementation choice as what to do. You can: >> >> 1. Use them all the parallel unnumbered links. >> 2. Only use one an unnumbered link if it is not a parallel >> link. >> 3. Use a mechanism outside the base protocol (as discussed >> above). > > > I may just be dumb but I don't get how putting addresses on the p2p links > fixes much of anything compared to not having them. Even if you've > got addresses configured on the p2p links there is nothing in the base > protocol which requires both ends to agree on this configuration, or > which would guarantee that the addresses are unique, or which would > prevent circuits from being used (or even make it desirable to not use > the circuit) if there were a mismatch, so within the base protocol > you can't really depend on address configuration on p2p links even if it > is there. It doesn't seem to change anything. That is, the routers > attached to the links will need to depend on their adjacency databases > to determine which of the circuits are bidirectional, addresses or not, > while routers not attached to the links won't have any certain idea of > which of the links are actually in service, addresses or not. > > What part of RFC 2328 makes section 16.1(2)(b) work better when you > have addresses on the p2p links? It seems like trying to use addresses > to tell you anything more than you would know without the addresses is > a mechanism as far outside the protocol as, say, configuring or > exchanging the ifindices for unnumbered links would be. Dennis, Good point - the base protocol doesn't require the subnets for neighbors on numbered P2P links to match so you really don't want to try and match the interface address (link data) in a router LSA's type 1 link with the corresponding LSA's type 1 link data or its type 3 links. There are implementations that require a subnet match for neighbor adjacency on numbered P2P interfaces but this is contrary to RFC 2328. So the issues and implementation choices are similar for parallel numbered and unnumbered P2P links. Currently, I've implemented a fairly liberal bi-directional check (one back-link will suffice). What is your take on this issue? Thanks, Acee > > Dennis Ferguson > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 16 01:13:08 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22936 for ; Wed, 16 Apr 2003 01:13:08 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.0097C932@cherry.ease.lsoft.com>; Wed, 16 Apr 2003 1:15:45 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 665872 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 16 Apr 2003 01:15:45 -0400 Received: from 203.199.83.247 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 16 Apr 2003 01:05:45 -0400 Received: (qmail 16932 invoked by uid 510); 16 Apr 2003 05:03:24 -0000 Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 16 apr 2003 05:03:24 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20030416050324.16930.qmail@mailweb34.rediffmail.com> Date: Wed, 16 Apr 2003 05:03:24 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: draft - ospf-scalability-03.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, Section 2: 2) Reset the Inactivity Timer for an interface whenever any OSPF packet is received over that interface (currently this is done only for the Hello packet). So OSPF would declare the interface to be down only if no OSPF packet is received over that interface for a period equaling or exceeding the RouterDeadInterval. Here what the paragraph implies seems little unclear. a) Inactivity timer are neighbor specific, so why should the one for interface be restarted ? b) Why should Ospf interface be made down if no packets are received on it ? c) Probably it should be something like this: "Reset the inactivity timer for a Neighbor whenever any Ospf packet is received from that neighbor" Or i missed the point the draft tries to make ???? vivek From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 16 01:17:43 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23025 for ; Wed, 16 Apr 2003 01:17:43 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0097CA66@cherry.ease.lsoft.com>; Wed, 16 Apr 2003 1:20:21 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 665914 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 16 Apr 2003 01:20:21 -0400 Received: from 136.182.1.10 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 16 Apr 2003 01:20:21 -0400 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h3G5KLd9004366 for ; Tue, 15 Apr 2003 22:20:21 -0700 (MST) Received: [from xover.corp.mot.com (xover.corp.mot.com [10.1.148.18]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id WAA09302 for ; Tue, 15 Apr 2003 22:20:20 -0700 (MST)] Received: by xover.corp.mot.com with Internet Mail Service (5.5.2653.19) id <2D45C4FB>; Wed, 16 Apr 2003 01:19:23 -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, 16 Apr 2003 01:21:17 -0400 Reply-To: Mailing List Sender: Mailing List From: "Manral, Vishwas" Subject: Re: draft - ospf-scalability-03.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Vivek, This has been updated in version 4 of the draft, which has recently been completed. The current text reads: - " reset the Inactivity Timer for an adjacency whenever any OSPF packet is received over that adjacency " Thanks, Vishwas -----Original Message----- From: Vivek Dubey [mailto:vivek_ospf@REDIFFMAIL.COM] Sent: Wednesday, April 16, 2003 10:33 AM To: OSPF@DISCUSS.MICROSOFT.COM Subject: draft - ospf-scalability-03.txt Hi, Section 2: 2) Reset the Inactivity Timer for an interface whenever any OSPF packet is received over that interface (currently this is done only for the Hello packet). So OSPF would declare the interface to be down only if no OSPF packet is received over that interface for a period equaling or exceeding the RouterDeadInterval. Here what the paragraph implies seems little unclear. a) Inactivity timer are neighbor specific, so why should the one for interface be restarted ? b) Why should Ospf interface be made down if no packets are received on it ? c) Probably it should be something like this: "Reset the inactivity timer for a Neighbor whenever any Ospf packet is received from that neighbor" Or i missed the point the draft tries to make ???? vivek From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 16 01:36:33 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23229 for ; Wed, 16 Apr 2003 01:36:32 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0097CA81@cherry.ease.lsoft.com>; Wed, 16 Apr 2003 1:39:10 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 665972 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 16 Apr 2003 01:39:10 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 16 Apr 2003 01:39:10 -0400 Received: from garnet.juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h3G5d9u12105 for ; Tue, 15 Apr 2003 22:39:09 -0700 (PDT) (envelope-from padma@juniper.net) Received: (from padma@localhost) by garnet.juniper.net (8.11.5/8.11.3) id h3G5d9348355 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 15 Apr 2003 22:39:09 -0700 (PDT) (envelope-from padma) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <200304160539.h3G5d9348355@garnet.juniper.net> Date: Tue, 15 Apr 2003 22:39:09 -0700 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: Graceful restart vs max-metric graceful ... To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E9B3D5E.BC54D84C@earthlink.net> from "Erblichs" at Apr 14, 2003 03:59:42 PM Precedence: list Content-Transfer-Encoding: 7bit > > > Also .... Blackhole event > > > > > > Upon restart, when a a topology > > > change has occured on possibly just 1 interface. > > > Then packets transiting from a valid helper interface > > > segment to a now non-valid interface segment > > > will be dropped for the duration that can > > > approach 1 hr. Right??? > > > > > I suppose you mean that the change in topology is in the restarting > > router itself or else graceful restart is aborted. > > Now remember that a graceful restart means that all is fine in the > > router .. any change in topology should abort the restart. > > > > > > > > How does one helper on 1 interface know about > > > other helpers (or non-helpers) on other interfaces/ > > > segments. If OSPF control functionality is inoperable, > > > then we are unable to transmit LSAs to inform that > > > an interface has gone down between the time that > > > we transmitted our grace-LSAs and the time that > > > are are now restarting. > > > > > Again, we are under the assumption that the forwarding capabilities > > are intact .. if it isn't then we cannot magically get the packets across > > graceful restart or not. > > > > Yes, our forwarding is intact. > > 1) We Sucessfully "enter graceful-restart". > > 2) We down our control section of the router. > > 3) A helper on a segment/interface dies ... > Our other helpers on different interfaces > are ok. > This helper could be having other neighbors that are fine and they will detect it and cause a change in topology. > 4) We exit graceful restart. and fail it due to #3. > > At #3, due to the fact that a helper died, and > we have no control section, traffic forwarded thru > one interface transiting the down helper is lost.. > We cannot insert a new forward element in our > forwarding table until we get back our control > section sometime after #4. > > In effect, we have 1-way traffic.. that is lost.. > Right??? > > The case that you are indicating above has multiple failures and I do not think that any protocol will be able to sustain it without packet loss even in the normal case. In the graceful restart the max amount of time you will have a packet loss eventually in case of multiple failures is the grace-period which is configurable. Note that if you had a large DeadRouterInterval you would have the same problem. Padma From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 16 05:17:37 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23351 for ; Wed, 16 Apr 2003 05:17:36 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.0097CD74@cherry.ease.lsoft.com>; Wed, 16 Apr 2003 5:19:56 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 666487 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 16 Apr 2003 05:19:56 -0400 Received: from 207.217.120.120 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 16 Apr 2003 05:19:56 -0400 Received: from user-2ivfje5.dialup.mindspring.com ([165.247.205.197] helo=earthlink.net) by albatross.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 195j57-0004kJ-00 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 16 Apr 2003 02:19:54 -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: <200304160539.h3G5d9348355@garnet.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E9D16FE.54D522D2@earthlink.net> Date: Wed, 16 Apr 2003 01:40:30 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Graceful restart vs max-metric graceful ... To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Padma Pillay-Esnault wrote: > > > > > > Also .... Blackhole event > > > > > > > > Upon restart, when a a topology > > > > change has occured on possibly just 1 interface. > > > > Then packets transiting from a valid helper interface > > > > segment to a now non-valid interface segment > > > > will be dropped for the duration that can > > > > approach 1 hr. Right??? > > > > > > > I suppose you mean that the change in topology is in the restarting > > > router itself or else graceful restart is aborted. > > > Now remember that a graceful restart means that all is fine in the > > > router .. any change in topology should abort the restart. > > > > > > > > > > > How does one helper on 1 interface know about > > > > other helpers (or non-helpers) on other interfaces/ > > > > segments. If OSPF control functionality is inoperable, > > > > then we are unable to transmit LSAs to inform that > > > > an interface has gone down between the time that > > > > we transmitted our grace-LSAs and the time that > > > > are are now restarting. > > > > > > > Again, we are under the assumption that the forwarding capabilities > > > are intact .. if it isn't then we cannot magically get the packets across > > > graceful restart or not. > > > > > > > Yes, our forwarding is intact. > > > > 1) We Sucessfully "enter graceful-restart". > > > > 2) We down our control section of the router. > > > > 3) A helper on a segment/interface dies ... > > Our other helpers on different interfaces > > are ok. > > > This helper could be having other neighbors that are fine and they will > detect it and cause a change in topology. I agree somewhat. But please le me repeat, we have lost 1 helper on 1 segment/interface. The topology change will only help with the loss of pkts coming from the past-helper and will be correctly redirected. The problem is that the other interface helpers won't see the topology change because our flooding functionality is based on our control section with our router functioning. It isn't until sometime in #4 that we restore flooding. So, our other helpers on our other interfaces are still directing traffic accross our valid helper interfaces. --- IFF you are familiar with route reflector logic within BGP, I am assuming that the helpers/clients are unaware of each others status if they are on different interface segments and require OSPF flooding. Only during sometime in #4 when we realize that we have lost only 1 helper, can we start to make corrective action with our forwarding tables. Of course, it is implimention dependent. .. So, should we max-metric our LSAs until we re-start if their are alternate paths? Doing so would force additional SPF computations as the tradeoff until we can have our control section back and can make corrective action to our forwarding table(s) if need be. With only a single path transiting our restarting router a max-LSA should still allow the flow, but the loss would have happened anyway if we had completely shutdown the router. > > > 4) We exit graceful restart. and fail it due to #3. > > > > At #3, due to the fact that a helper died, and > > we have no control section, traffic forwarded thru > > one interface transiting the down helper is lost.. > > We cannot insert a new forward element in our > > forwarding table until we get back our control > > section sometime after #4. > > > > In effect, we have 1-way traffic.. that is lost.. > > Right??? > > > > > > > The case that you are indicating above has multiple failures and > I do not think that any protocol will be able to sustain it > without packet loss even in the normal case. > In the graceful restart the max amount of time you will have > a packet loss eventually in case of multiple failures is the > grace-period which is configurable. Note that if you had > a large DeadRouterInterval you would have the same problem. > > Padma From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 16 10:12:03 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02517 for ; Wed, 16 Apr 2003 10:12:02 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.0097D33C@cherry.ease.lsoft.com>; Wed, 16 Apr 2003 10:14:35 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 667437 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 16 Apr 2003 10:14:35 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 16 Apr 2003 10:14:34 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 5D3088B1F60 for ; Wed, 16 Apr 2003 07:14:32 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <200304082356.h38NunH88489@garnet.juniper.net> <3E93755E.1937BC89@earthlink.net> <3E95061B.5060200@redback.com> <3E95BACC.E53FDC89@earthlink.net> <3E95BEDF.2010606@redback.com> <3E975E6E.73A22F08@earthlink.net> <3E99DAD2.9080507@redback.com> <3E9B16AC.EE25CE5F@earthlink.net> <3E9B1E03.40803@redback.com> <3E9B361F.CD83ACDC@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E9D64AD.6010908@redback.com> Date: Wed, 16 Apr 2003 10:11:57 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Draft : Graceful Restart : : grace period, etc To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Erblichs wrote: > Acee Lindem,, > > Inline.. > > Mitchell Erblich Sr Software Engineer -----------, Inline... > > > > Acee Lindem wrote: > >>Erblichs wrote: >> >>>Acee Lindem, >>> >>> Inline... >>> >>> Mitchell Erblich >>> ---------------------- >>> >>>Acee Lindem wrote: >>> >>> >>>>Erblichs wrote: >>>> >>>> >>>>>Group, >>>>> >>>>> First of all I would want to apologize for continuing >>>>> this discussion thread! >>>>> >>>>> I realize that some implimentions may exist based on >>>>> this draft and what I am suggesting, may effect changes >>>>> to them. >>>> >>>>Mitchell, >>>> >>>>No apologies necessary for discussion of the draft. However, please make >>>>every attempt to read and understand it before suggesting substantive >>>>changes. >>>> >>>> >>>> >>>>> In my past emails I have implicitly ignored the section >>>>> 5 within this draft of "Unplanned outages". I will now >>>>> explicitly state why I have ignored its suggested method. >>>>> >>>>> Why? >>>>> * " must originate grace-LSAs *after* its control >>>>> software resumes operation", we now lose our DR or >>>>> BDR status, if it had existed. >>>> >>>>The restarting router will succeed DR status if it was previously DR. See >>>>section 2 number 3. Also note section 5 for applicablility to unplanned >>>>restarts. Changes in BDR should have no effect on adjacencies or LSA >>>>contents. >>> >>> >>> I am really lost here.. >>> >>> IFF we are unplanned, won't the normal deadrouterinterval >>> timeouts take down the adjs? Remember the "*after*" >>> section. >> >>What you are missing is that for unplanned restarts the restarting OSPF >>router (or process) must at least start graceful restart within >>the RouterDeadInterval period. For planned restarts, this is not a >>restriction. > > > > That is nice.................... > > No, not "start graceful restart" process. Start sending hellos within > routerdeadinterval which is after grace-LSAs are sent and recived. > > Yes, sending multiple grace-LSAs, but don't they need to be > 5 secs apart? So, to send three will take 15 secs. Right?? In the case of implementation, I only wait 1 second between grace LSAs for unplanned restart. > > In Version 07, section 5, of the draft where is that > ROUTERDEADINTERVAL stated??? > Isn't that an important enough concept to be explicitly stated > here? It seems obvious to me. Did anyone else miss this? I'll see about adding something during the AD comments. > > I only see "restarted router has no adjacencies and no > knowledge of previous adjacencies". As a statement about > adj in section 5. > > Wow.. Can I second and third my unplanned restart as an > option that follows the planned restart logic without > the routerdeadinterval restriction???? :) You are welcome to submit an alternate proposal but please do it in the form of a draft rather than E-mails extolling the benefits. I believe the current draft is a reasonable approach to unplanned restart. One cannot signal unplanned graceful restart apriori since you don't know whether the router or OSPF process is going to come back. > > >>> If the restarting router was the DR or a BDR, a new election >>> will occur to re-elect a new DR and/or BDR, and new adjs >>> will form. Now, the premise of minimizing topological changes >>> as a reason to keep the pre-shutdown DR / BDR combo, will >>> no longer apply. >>> >>> Even if we declare ourselves the DR after re-start, there >>> is only a chance that the reason why we were initially >>> elected still applies, thus we may no longer have the >>> highest priority of eligible routers. >>> >>> Mitchell Erblich >>> --------------------------- >>> >>> >>> >>> >>> >>>>> - This forces a SPF recomputation.. >>>>> - This can forces many full adj reformations. >>>>> - Removes the helper relationship with >>>>> respect to the restarting router >>>>> (monitoring, continues to (its) advertise its >>>>> LSAs, etc) NIT: remove the first "its". >>>>> - etc.. >>>>> >>>>> Thus this section invalidates many of the reasons >>>>> for the draft's existance. >>>>> >>>>> * If the draft's unplanned outages did not have these >>>>> negative effects and more, then anytime > 1 hr >>>>> graceful restart is planned, then this would be a >>>>> solid alternative. I just cannot see anyone >>>>> forwarding any pkts accross a non-adj, so even if >>>>> your forwarding table contents are sanitized, it >>>>> will be ignored. >>>>> >>>>> So, from may past information dump, the only true side effect >>>>> other than mentioned in the draft (clean flag for the forwarding >>>>> table should remove the table sanity issue) are the issues of the >>>>> reflooding bandwidth of early grace-LSAs, just in case the router >>>>> has an unplanned restart. And the extra work that is placed on >>>>> helper routers to "monitor" the network for topology changes, >>>>> and its other assigned helper duties. >>>>> >>>>> Thus, I believe that I have more than sufficiently identified >>>>> a graceful restart mechanism that removes the AFTER requirement >>>>> and allows the planned graceful restart method to be used in a >>>>> unplanned way. Plus, I agree that a knob/CLI command should be >>>>> used to enable or disable this type of feature. >>>>> >>>>> Mitchell Erblich >>>>> Sr Software Engineer >>>>> ---------------------- >>>>> >>>>>Acee Lindem wrote: >>>>> >>>>> >>>>> >>>>>>Erblichs wrote: >>>>>> >>>>>> >>>>>> >>>>>>>Acee, et al, >>>>>>> >>>>>>> I didn't really want to continue this thread >>>>>>> but I feel, I should restate some items here. :) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>As Padma stated, the draft supports unscheduled restarts (there >>>>>>>>are multiple interoperable implementations). Your proposal to >>>>>>>>announce graceful restart in advance >>>>>>> >>>>>>> >>>>>>> >>>>>>> I don't see how one can send out grace-LSAs and possibly be >>>>>>> able to retransmit a grace-LSA OTHER than in advance, >>>>>>> AND still support unscheduled graceful restarts!!! >>>>>> >>>>>>Mitchell, >>>>>> >>>>>>In the case of unscheduled restart you may send the grace LSA a couple >>>>>>times but you don't want for an acknowledge (you don't necessarily know your >>>>>>neighbors since you are learning the state from the networks). >>>>>> >>>>>>I suggest you read or review section 5 of the draft. It covers all of your >>>>>>concerns below. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> You must do it in advance, else it is scheduled.. >>>>>>> >>>>>>> My definition of unscheduled is that some event occurs and >>>>>>> the non-forwarding portion of the router is DOWN... No, >>>>>>> time for an sys admin to do anything... >>>>>>> >>>>>>> The ONLY possible way is to have trap level code call >>>>>>> the xmit grace-LSA code section. However, no time to >>>>>>> see if acks have been rec'vd and no time for a 5 sec >>>>>>> rexmit.... >>>>>>> >>>>>>> Ok, then WHAT is an UNSCHEDULED GRACEFUL RESTART in your >>>>>>> guys opinion???? >>>>>>> >>>>>>> On the assumption that if the router fails and >>>>>>> still abides by the condition that it is still >>>>>>> forwarding as if it was still up.., then >>>>>>> >>>>>>> As long as there isn't any topologoy changes >>>>>>> as stated within your document, that is one >>>>>>> reason to allow for a graceful restart, I don't >>>>>>> see the blackhole.. >>>>>>> >>>>>>> If the topology changes then it would invalidate >>>>>>> my graceful restart, as it would also invalidate >>>>>>> the graceful restart specified in the draft. >>>>>>> >>>>>>> The only deltas that I was asking for was: >>>>>>> - the issue of sending out a minimal grace-LSA at >>>>>>> adj timeframe, >>>>>>> - being able to minimally update our grace-LSA as >>>>>>> topology changes, >>>>>>> - or we decide that we want to withdraw our grace-LSA >>>>>>> via MAXAGE, >>>>>>> >>>>>>> As of this time, I have not read in your document, >>>>>>> EXPLICITLY whether >>>>>>> - you suggest to ONLY send out the grace-LSA when you >>>>>>> have planned to do a restart (scheduled), >>>>>>> - how to withdraw the grace-LSAs from accepted helpers >>>>>>> when one proto-helper (to be helper), will not ack >>>>>>> your LSA, >>>>>>> - etc.. >>>>>>> >>>>>>> >>>>>>> Mitchell Erblich >>>>>>> Sr Software Engineer >>>>>>> ============================ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>Acee Lindem wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Erblichs wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>Padma, >>>>>>>>> >>>>>>>>> >>>>>>>>> These are my last comments!! >>>>>>>>> >>>>>>>>> Also inline... >>>>>>>>> >>>>>>>>> Why doesn't the draft RFC authors want to >>>>>>>>> allow non-scheduled restarts in this >>>>>>>>> draft? >>>>>>>> >>>>>>>>Michell, >>>>>>>> >>>>>>>>As Padma stated, the draft supports unscheduled restarts (there >>>>>>>>are multiple interoperable implementations). Your proposal to >>>>>>>>announce graceful restart in advance will unnecessarily delay >>>>>>>>the detection of a black hole if the restarting router is really dead >>>>>>>>or was abruptly decommissioned. The current draft doesn't suffer >>>>>>> >>>>>>>>from this flaw. >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> Is there something wrong with the idea >>>>>>>>> of un-scheduled restarts? >>>>>>>>> >>>>>>>>> Why restrict it to only scheduled >>>>>>>>> restarts??? >>>>>>>>> >>>>>>>>> Why require >>>>>>>>> the grace-LSAs to be reflooded every >>>>>>>>> 30 minutes to 1 hr??? >>>>>>>>> >>>>>>>>> Why not send the grace-LSAs without >>>>>>>>> the Type=1, Length=4 grace period field?? >>>>>>>>> It will be determined by the helpers >>>>>>>>> anyway. >>>>>>>>> >>>>>>>>> The sentance is. >>>>>>>>> >>>>>>>>> "The number of seconds that the router's >>>>>>>>> neighbors should continue to advertise the >>>>>>>>> router as fully adjacent".... >>>>>>>>> >>>>>>>>> Thus, without the word "MUST", implimentations >>>>>>>>> will probably follow their own rules. Thus, the >>>>>>>>> grace period field really isn't needed and just >>>>>>>>> consumes bandwidth!!! >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Mitchell Erblich >>>>>>>>> =================== >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>Padma Pillay-Esnault wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>Mitchell, >>>>>>>>>> >>>>>>>>>>I'll try to address your comments >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>Acee Lindem, >>>>>>>>>>> >>>>>>>>>>> Since,, you skipped the inline re-comments, I will assume >>>>>>>>>>> that at least you read them.. :) >>>>>>>>>>> >>>>>>>>>>> I think I have expressed as best as I could (I am not >>>>>>>>>>> a tech writer) how I feel that this draft should evolve. >>>>>>>>>>> >>>>>>>>>>> So in summary... >>>>>>>>>>> >>>>>>>>>>>` 0) Remove the length (seconds) field from the grace-LSA. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>This is using the TLV format .. so you want to keep the length >>>>>>>>> >>>>>>>>> >>>>>>>>> Of course, Type, Length, Value... Fine. Reword.. >>>>>>>>> Remove >>>>>>>>> the Grace-Period field of (Type =1, Length = 4). >>>>>>>>> Why transmit the field value????? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> 1) Transmit DNA grace-LSAs at adj creation time. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>This is not very useful. Today unless you have DNA lsa you cannot >>>>>>>>>>expect to be requesting a grace period of over one hour -- as >>>>>>>>>>all the LSA in the other routers database will expire at the >>>>>>>>>>most in 1hr. >>>>>>>>>>So if you decide to send a grace LSA it would be the most recent one >>>>>>>>>>that you built and hence if it has time to expire then the previous >>>>>>>>>>would already be gone. >>>>>>>>> >>>>>>>>> >>>>>>>>> Think ahead of tomarrow, not today... >>>>>>>>> How should this work in the utopian word? If the graceful >>>>>>>>> restart is a good idea, then it NOT should be used for ALL >>>>>>>>> possible restarts?? >>>>>>>>> >>>>>>>>> Why not restrict the amount of flooding with THESE types >>>>>>>>> of LSAs if this draft becomes a standard RFC?? >>>>>>>>> >>>>>>>>> What happens if I send the grace-LSAs at adj formation >>>>>>>>> time and then reflood them every 55 minutes?? This >>>>>>>>> removes the lightweight mechanism of the draft, but >>>>>>>>> still gets me unscheduled restart functionality? Maybe >>>>>>>>> i will just do that.. BTW, and also do unscheduled >>>>>>>>> restarts with my BGP protocol once it becomes a >>>>>>>>> standard. >>>>>>>>> >>>>>>>>> Thus, a restriction of 1 hr isn't sensible. Else, even if >>>>>>>>> I follow your logic, then why do I ask for 1 hr? Should >>>>>>>>> my implimentation in the helper not ack the grace-LSA if >>>>>>>>> the specified grace-period is over 1 hr from the restarting >>>>>>>>> router? This is unspecified behavior!!! >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> 2) Let the helpers determine amount of time that >>>>>>>>>>> they will function as a helper. Suggest a minimum >>>>>>>>>>> of 1 hr time. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>This is a matter of policy .. even if the helper decides that >>>>>>>>>>he is not going to help for the whole period .. as he is not >>>>>>>>>>going to signal it to the restarting router .. I do not see >>>>>>>>>>the use of doing so. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> 3) Reflood the DNA grace-LSAs anytime the contents >>>>>>>>>>> have changed. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>See my response in 1. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> 4) If the restart router expects to be down for a period >>>>>>>>>>> longer than X, then retransmit the Grace-LSAs as >>>>>>>>>>> MAXage LSAs. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>I do not see the benefit or I am missing your point >>>>>>>>>> >>>>>>>>>>Padma >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> This would minimize bandwidth requirements and allow a >>>>>>>>>>> restarting router to have either scheduled or unscheduled >>>>>>>>>>> restarts. >>>>>>>>>>> >>>>>>>>>>> I don't know what else to add, except if you adopt one or >>>>>>>>>>> more of these suggestions, then please add my name to your >>>>>>>>>>> comment list. :) >>>>>>>>>>> >>>>>>>>>>> Mitchell Erblich >>>>>>>>>>> Sr Software Engineer >>>>>>>>>>> ============================ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>Acee Lindem wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>Erblichs wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>Acee Lindem, >>>>>>>>>>>>> >>>>>>>>>>>>> Sometimes my logic is a little obtuse.. >>>>>>>>>>>>> >>>>>>>>>>>>> Most of it is inline... >>>>>>>>>>>>> >>>>>>>>>>>>> I will first throw two new questions to you!!!! >>>>>>>>>>>>> >>>>>>>>>>>>> 1) Why don't you send out the Grace LSA at full >>>>>>>>>>>>> adj timeframe. It would take effect after >>>>>>>>>>>>> RouterDeadinterval has expired? >>>>>>>>>>>> >>>>>>>>>>>>How do you know, apriori, that the OSPF instance is >>>>>>>>>>>>restarting and not completely dead? >>>>>>>>>>> >>>>>>>>>>> Why do you care? As long as the topology isn't changing >>>>>>>>>>> then everything is ok. >>>>>>>>>>> >>>>>>>>>>> Wwhy not minimize the effects of unnecessary SPF computations? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> This would also take care of unscheduled restarts >>>>>>>>>>>>> and allow you to do an unscheduled graceful >>>>>>>>>>>>> restart!!!! >>>>>>>>>>>>> >>>>>>>>>>>>> You could also send them as DNA LSAs.. See inline. >>>>>>>>>>>>> >>>>>>>>>>>>> The only new twist is that if you then schedule >>>>>>>>>>>>> a restart, you may want to be able to cancel your >>>>>>>>>>>>> previous request or update the LSAs over time. >>>>>>>>>>>>> But if you conisder a stable topology, then why >>>>>>>>>>>>> NOT?? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2) A) 2.1 3rd, paragraph.. >>>>>>>>>>>>> "Their age field set to 0," >>>>>>>>>>>>> Why can't you send DNA grace-LSAs???? >>>>>>>>>>>> >>>>>>>>>>>>You wouldn't gain anything since the grace interval cannot >>>>>>>>>>>>exceed the LSA refresh time. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> So, first why do you need to specify the grace-LSA >>>>>>>>>>> timeframe. Let it be implicitly known to be 1 hr! >>>>>>>>>>> >>>>>>>>>>> With DNA grace-LSAs, we >>>>>>>>>>> don't need to reflood them. If I sent them out >>>>>>>>>>> at adj creation time and the topology isn't >>>>>>>>>>> changing, then I don't need to consume >>>>>>>>>>> resources and keep on re-flooding them.. >>>>>>>>>>> >>>>>>>>>>> Thus, they can last multiple hours or longer.. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> B) 2.1, 4th paragraph. >>>>>>>>>>>>> >>>>>>>>>>>>> "it should retransmit... until >>>>>>>>>>>>> they are acknowledged". If you can't retransmit the >>>>>>>>>>>>> same LSA until 5 secs have passed, if a router >>>>>>>>>>>>> was congested, you may want to resubmit the grace-LSA >>>>>>>>>>>>> with a longer length timeframe to your helpers. I am >>>>>>>>>>>>> assuming just bump your instance. Correct? >>>>>>>>>>>> >>>>>>>>>>>>There are implementations that back off LSA retransmissions and the >>>>>>>>>>>>"Prioritized Treatment of Specific OSPF Packets and Congestion >>>>>>>>>>>>Avoidance" draft recommends this. However, this is not standard >>>>>>>>>>>>OSPF flooding as described in RFC2328 and it is an independent >>>>>>>>>>>>issue. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> No, no, you are missing my point. Until all of your grace-LSAs are >>>>>>>>>>> ack'ed, you can't continue successfully with a graceful-restart. >>>>>>>>>>> >>>>>>>>>>> This delay consumes time that you specified in your grace-LSA. Yea, >>>>>>>>>>> again, I don't know why you need to specify the amount of time!! >>>>>>>>>>> The timeframe that the helpers will help you can be set independently >>>>>>>>>>> and your spec doesn't allow them to communicate the amount of time >>>>>>>>>>> that they will keeep around a grace-LSA. >>>>>>>>>>> >>>>>>>>>>> Sorry, minor sidetrack. So, the time consumed to get the ack, actually >>>>>>>>>>> reduces the amount of time before the grace-LSA expires. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> Mitchell >>>>>>>>>>>>> ================ >>>>>>>>>>>>>Acee Lindem wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>Mitchell, >>>>>>>>>>>>>> >>>>>>>>>>>>>>See answers below. >>>>>>>>>>>>>> >>>>>>>>>>>>>>Erblichs wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>>Group, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1) Within 2.1 "Entering graceful restart", iff all >>>>>>>>>>>>>>> the LSAs were from DC specified NBRs with DNA >>>>>>>>>>>>>>> LSAs should the LS RefreshTime still be followed? >>>>>>>>>>>>>> >>>>>>>>>>>>>>LSA Refresh isn't relevant since the restarting router will >>>>>>>>>>>>>>reestablish adjacencies. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Then why have a suggestion of 1800 secs for LSReshTime >>>>>>>>>>>>> in your draft at the end of the 1st paragraph in section >>>>>>>>>>>>> 2.1? >>>>>>>>>>>>> >>>>>>>>>>>>> In my scenario, there would be no reason not to let the >>>>>>>>>>>>> value approach or exceed 3600 secs (1 hr). >>>>>>>>>>>>> >>>>>>>>>>>>> variation on a theme? Why not let the max value of your >>>>>>>>>>>>> grace-LSA length field allow the helper determine what >>>>>>>>>>>>> is the max that he will support? >>>>>>>>>>>>> -- what happens if you specify a value that is >>>>>>>>>>>>> greater than what the helper supports? >>>>>>>>>>>>> Ans A: The helper sees it as an invalid request >>>>>>>>>>>>> and throws away the whole request, >>>>>>>>>>>>> >>>>>>>>>>>>> OR >>>>>>>>>>>>> Ans B: The helper determines what the length he >>>>>>>>>>>>> will support? >>>>>>>>>>>>> >>>>>>>>>>>>> If it is B, then why have the length field. Just let >>>>>>>>>>>>> the helper decide how long to support the request? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> 2) Within 2.2 "When to exit graceful restart", number >>>>>>>>>>>>>>> (3) "The grace period expires". >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> What happens if we follow #3 and your #1 "reestablished >>>>>>>>>>>>>>> all its adjacencies" criteria is not met? >>>>>>>>>>>>>> >>>>>>>>>>>>>>The restarting router will exit graceful restart anyway. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Why? If you still have a non-changing topology, why >>>>>>>>>>>>> limit the value to what you had said to the helpers? >>>>>>>>>>>>> >>>>>>>>>>>>> So, what if you asked for x time and it took you >>>>>>>>>>>>> x + y time? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> Or are you stating that the specified "grace period" was >>>>>>>>>>>>>>> to short to perform what was required? >>>>>>>>>>>>>> >>>>>>>>>>>>>>Not necessarily - perhaps the topology has changed and graceful restart >>>>>>>>>>>>>>cannot be completed successfully. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> 3) Within 2.2. Would seeing a hello without the graceful >>>>>>>>>>>>>>> restarting router id", force it to exit? >>>>>>>>>>>>>> >>>>>>>>>>>>>>No. The adjacency can go all the way down on the helper router. The hello >>>>>>>>>>>>>>shouldn't be used as a criteria for exiting helper mode. Do not confuse >>>>>>>>>>>>>>this with other graceful restart proposals. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I see that my question with the hello was answered in the >>>>>>>>>>>>> 2. (3) "an hello packet is received".. >>>>>>>>>>>>> >>>>>>>>>>>>> I am confused. One router may list you as the DR and another >>>>>>>>>>>>> may not? If one is a helper, then why would it take the adj >>>>>>>>>>>>> down if all the crieria were met? >>>>>>>>>>>>> >>>>>>>>>>>>> I thought that helpers >>>>>>>>>>>>> MUST send hellos as if you (graceful restarting router) were >>>>>>>>>>>>> still there!! >>>>>>>>>>>>> "an Hello packet is received from a neighbor listing the >>>>>>>>>>>>> router as the Designated Router". >>>>>>>>>>>>> >>>>>>>>>>>>> If it did keep anouncing you in the hellos (you weren't >>>>>>>>>>>>> the DR) and lets say that the DR went down. Could you >>>>>>>>>>>>> then be elected as the DR while you were still rebooting? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> 4) Within 2.2. Would seeing a hello without the graceful >>>>>>>>>>>>>>> restarting router id as the earlier DR or BDR, cause >>>>>>>>>>>>>>> it to exit, if it was a DR / BDR? >>>>>>>>>>>>>> >>>>>>>>>>>>>>Not directly, but an inconsistency with the pre-restart LSA will cause >>>>>>>>>>>>>>the restarting router to exist graceful restart prematurely. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> 5) Within 2.2. Is it implimentation dependent on how we >>>>>>>>>>>>>>> determine our existing nbrs and place their router ids >>>>>>>>>>>>>>> in a hello? >>>>>>>>>>>>>> >>>>>>>>>>>>>>This isn't changed for graceful restart. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I thought that you could save past nbr-ids in NVRAM >>>>>>>>>>>>> and then compare to existing hellos... >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> 6) Within 2.2 (1), isn't adj establishment partly the >>>>>>>>>>>>>>> recieving of hellos, with your own router-id? Shouldn't >>>>>>>>>>>>>>> that inform others that we are back and to cancel >>>>>>>>>>>>>>> their helper graceful nbr timer? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 7 & 8) Within 2.3 "Actions on exiting graceful restart". >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 7) Shouldn't the sending hellos be performed that >>>>>>>>>>>>>>> identify full adj be a criteria here? >>>>>>>>>>>>>> >>>>>>>>>>>>>>No. LSA convergence with the pre-restart LSAs is a much surer >>>>>>>>>>>>>>mechanism for determining the graceful restart can be exited. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> 8) I am unsure whether you are specifying the >>>>>>>>>>>>>>> storage of part of restarting router's LSDB into >>>>>>>>>>>>>>> non-volatile memory. If so, then upon retrieval, >>>>>>>>>>>>>>> shouldn't some elements of the LSDB be aged >>>>>>>>>>>>>>> by the amount that the actual amount of time >>>>>>>>>>>>>>> the LSAs were in NV memory? >>>>>>>>>>>>>> >>>>>>>>>>>>>>There is no mention of storing LSAs in non-volatile storage. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Ok, you aren't suggesting saving the LSDB in NVRAM >>>>>>>>>>>>> or some other type of storage media.. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> Mitchell Erblich >>>>>>>>>>>>>>> ================================== >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>-- >>>>>>>>>>>>>>Acee >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>-- >>>>>>>>>>>>Acee >>>>>>>>>>> >>>>>>>>-- >>>>>>>>Acee >>>>>>> >>>>>>> >>>>>>-- >>>>>>Acee >>>>> >>>>> >>>>-- >>>>Acee >>> >>> >>-- >>Acee > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 16 11:10:19 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05218 for ; Wed, 16 Apr 2003 11:10:19 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0097D520@cherry.ease.lsoft.com>; Wed, 16 Apr 2003 11:12:56 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 667697 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 16 Apr 2003 11:12:56 -0400 Received: from 193.70.192.51 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 16 Apr 2003 11:12:56 -0400 Received: from libero.it (193.70.192.91) by smtp1.libero.it (7.0.012) id 3E954680000983FC for OSPF@DISCUSS.MICROSOFT.COM; Wed, 16 Apr 2003 17:12:55 +0200 MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 X-XaM3-API-Version: 3.2 R29 (B54 pl1) X-type: 0 X-SenderIP: 81.73.170.22 Message-ID: Date: Wed, 16 Apr 2003 17:12:55 +0200 Reply-To: Mailing List Sender: Mailing List From: "=?iso-8859-1?Q?john151@libero.it?=" Subject: =?iso-8859-1?Q?Two_Opaque_Timers_to_Ospf...?= To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA05218 Hi all, i'd like to do some considerations about the use of Timer in RFC2370 Opaque LSA; i understood this use of Timer for opaque LSA: suppose we refer to a simple starting situation in which for a long time there is no opaque LSA propagation; in a certain time t0, one router (R1) in the net receives a bandwidth update and so an opaque LSA flooding starts; if new updates arrive to R1 about bandwidth, color, ecc, these updates are stored and NOT flooded through the net until (t0 + MinLSInterval sec) when one opaque LSA is flooded with the latest updates. If it's right, thinking to a MPLS scenario in which bandwidth updates come from RSVP and other fields updates in Opaque LSA come from a different module in each router (in example an administative module), could it be more reasonable the use of two timer: for example one timer considering all the opaque fields updates excepts administrative group field updates and one considering only the administrative field updates? I see the reason for this complication in the logical independence between each entity detecting its own fields variation; also condider that an hypothetical admistrative module in the most cases will send few updates regarding to RSVP bandwidth updates ( i would not wait MinLSInterval seconds to send, for example, a color field update, but i would still maintain a time filter for rapid changes in link color attributes ). Do you see stability problems in this change or an incompatibility in the standard? Thanks in advance for your kind answers and observations. Giovanni Coritel Rome From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 16 11:40:45 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06161 for ; Wed, 16 Apr 2003 11:40:43 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.0097D547@cherry.ease.lsoft.com>; Wed, 16 Apr 2003 11:43:19 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 667849 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 16 Apr 2003 11:43:18 -0400 Received: from 169.144.68.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 16 Apr 2003 11:43:18 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA16636 for ; Wed, 16 Apr 2003 11:43:16 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA23029 for ; Wed, 16 Apr 2003 11:43:16 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <2BD2CA5Z>; Wed, 16 Apr 2003 11:43:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <39469E08BD83D411A3D900204840EC557635E2@vie-msgusr-01.dc.fore.com> Date: Wed, 16 Apr 2003 11:43:14 -0400 Reply-To: Mailing List Sender: Mailing List From: "Naidu, Venkata" Subject: Re: Multiple un-numbered serial links between two routers To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Dennis, -> What part of RFC 2328 makes section 16.1(2)(b) work better when you -> have addresses on the p2p links? When we make the shortest path tree (actually a directed acyclic graph - DAG), we always assume that base OSPFv2 is designed for bi-directional links. When we make a graph using the link-state database, we must be able to visualize the graph *unambiguously* (which half-link from A to B matches to half-link from B to A). At least, we can do that using IP addresses with little bit of careful subnet addressing. RFC 2328 page 166 reads... The specification does not require that the above two stage method be used to calculate the shortest path tree. However, if another algorithm is used, an identical tree must be produced. For this reason, it is important to note that links between transit vertices must be bidirectional in order to be included in the above tree. ... That said, UDLR for OSPF does more than required when OSPF runs over unidirectional links. -> It seems like trying to use addresses -> to tell you anything more than you would know without the -> addresses is -> a mechanism as far outside the protocol as, say, configuring or -> exchanging the ifindices for unnumbered links would be. The *identifiers* between A to B are irrelevant to the discussion whether the ids are addresses or ifindices. The only requirement is that the "ids" must be unique in the router. W.r.t A and/or B (directly connected neighbors) IP addresses and if indices serves the same purpose. If in GMPLS the exchange of IF_IDs are outside the TE framework, I don't think we are able to establish tunnels unambiguously. The birectionality test in CSPF is crucial (remember that, there is no hello protocol to do the bidirectinality test). -> Dennis Ferguson Venkata. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 16 11:47:59 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06305 for ; Wed, 16 Apr 2003 11:47:58 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.0097D6A4@cherry.ease.lsoft.com>; Wed, 16 Apr 2003 11:50:37 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 667885 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 16 Apr 2003 11:50:37 -0400 Received: from 193.70.192.51 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 16 Apr 2003 11:50:37 -0400 Received: from libero.it (193.70.192.38) by smtp1.libero.it (7.0.012) id 3E95468000099586 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 16 Apr 2003 17:50:36 +0200 MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 X-XaM3-API-Version: 3.2 R29 (B54 pl1) X-type: 0 X-SenderIP: 81.73.170.22 Message-ID: Date: Wed, 16 Apr 2003 17:50:35 +0200 Reply-To: Mailing List Sender: Mailing List From: "=?iso-8859-1?Q?john151@libero.it?=" Subject: =?iso-8859-1?Q?Problems_in_changing_router's_name?= To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA06305 Hi all, i wanted to refer to a potential problem in a network: in a MPLS scenario using RSVP and OSPF protocols, could it happen this situation? EXAMPLE: router R1 has interfaces eth0 x.y.100.2 eth1 x.y.150.2 eth2 x.y.200.2 Suppose OSPF and ZEBRA running in all the net except R1. When ZEBRA and OSPF daemons start in R1, after a certain period the net will know R1 with the name x.y.200.2 (I think with ZEBRA it's so, isn't it?). If R1 is a router Cisco, Juniper, ecc, is it possible that interface eth2 disappears and eth0, eth1 continue their job? ( for example system administrator could deactivate by operating system the eth2? ). In Rfc2328 cap 5 is said that if the smallest interface (router ID; in ZEBRA i saw that router ID was the HIGHEST interface! Is it possible or am i mistaking?) goes down, router ID changes and OSPF software should be restarted before new router ID takes effect. Again, in draft-katz-yeung-ospf-traffic-09.txt 2.4.1 is said that Router address TLV contains a "stable" IP address of the advertising router that is always reachable! Stable means that IP address router doesn't change? But if i disable the interface that names a Linux router, OSPF could update the topology or could maintain the old router name even if that interface is down. I think there will be this situation if eth2 becomes disabled: since R1 eth2 was the highest R1 interface, after some seconds, router x.y.200.2 will disappear and an new router will appear (x.y.150.2)! Now the potential problem: what could it happen to LSPs not using eth2 on R1, but using eth0 or eth1? In their ERO (explicit route object) there is the first R1 name: x.y.200.2; if these LSPs remain active, the ERO will not change and after some seconds we have no more a x.y.200.2 router in the net! RSVP will continue the refresh? OSPF will change the routing tables to contain x.y.150.2, but the ERO of each LPS for R1 will continue having x.y.200.2! Thanks in advance for your kind answers and observations From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 16 12:01:43 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06872 for ; Wed, 16 Apr 2003 12:01:42 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.0097D5AB@cherry.ease.lsoft.com>; Wed, 16 Apr 2003 12:04:21 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 667935 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 16 Apr 2003 12:04:21 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 16 Apr 2003 12:04:20 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 5A6B962B2AE for ; Wed, 16 Apr 2003 09:03:10 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E9D7E21.6020401@redback.com> Date: Wed, 16 Apr 2003 12:00:33 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Two Opaque Timers to Ospf... To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit John, There have been suggestions in the past to reduce or ignore MinLSInterval and MinLSArrival. However, there haven't been any formal proposals addressing (or at least describing) all the issues. IMHO, adding another timer for TE Opaque LSAs is limited and shouldn't be pursued. Thanks, Acee john151@libero.it wrote: > Hi all, > i'd like to do some considerations about the use of Timer > in RFC2370 Opaque LSA; > > i understood this use of Timer for opaque LSA: > suppose we refer to a simple starting situation in which for a long time there is > no opaque LSA propagation; in a certain time t0, one router (R1) in the net > receives a bandwidth update and so an opaque LSA flooding starts; > if new updates arrive to R1 about bandwidth, color, ecc, these updates > are stored and NOT flooded through the net until (t0 + MinLSInterval sec) when > one opaque LSA is flooded with the latest updates. > > If it's right, thinking to a MPLS scenario in which bandwidth > updates come from RSVP and other fields updates in Opaque LSA > come from a different module in each router (in example an administative > module), could it be more > reasonable the use of two timer: for example one timer > considering all the opaque fields updates excepts administrative group > field updates and one considering only the administrative field updates? > > I see the reason for this complication in the logical > independence between each entity detecting its own fields variation; > also condider that an hypothetical admistrative module in the most cases > will send few updates regarding to RSVP bandwidth updates > ( i would not wait MinLSInterval seconds to send, for example, > a color field update, but i would still maintain a time filter for > rapid changes in link color attributes ). > > Do you see stability problems in this change or an > incompatibility in the standard? > > Thanks in advance for your kind answers and observations. > > Giovanni > > Coritel Rome > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 16 12:14:29 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07302 for ; Wed, 16 Apr 2003 12:14:28 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.0097D72D@cherry.ease.lsoft.com>; Wed, 16 Apr 2003 12:17:06 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 668021 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 16 Apr 2003 12:17:06 -0400 Received: from 12.145.55.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 16 Apr 2003 12:17:06 -0400 Received: from WTN10069.opnet.com (wtn10069.opnet.com [172.16.10.69]) by newpostman.opnet.com (8.12.9/8.12.1) with ESMTP id h3GGH4xv028988; Wed, 16 Apr 2003 12:17:05 -0400 (EDT) X-Sender: svenkatachalam@mailserver.opnet.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 References: <200304152331.h3FNVIu95363@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <5.1.0.14.2.20030416121234.09218c40@mailserver.opnet.com> Date: Wed, 16 Apr 2003 12:17:04 -0400 Reply-To: Mailing List Sender: Mailing List From: "Senthil K. Venkatachalam" Subject: Re: Multiple un-numbered serial links between two routers To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3E9CDDB5.308@redback.com> Precedence: list At 12:36 AM 4/16/2003 -0400, Acee Lindem wrote: >Dennis, > >Good point - the base protocol doesn't require the subnets for >neighbors on numbered P2P links to match so you really don't want >to try and match the interface address (link data) in a router LSA's >type 1 link with the corresponding LSA's type 1 link data or its type 3 >links. There are implementations that require a subnet match for >neighbor adjacency on numbered P2P interfaces but this is contrary >to RFC 2328. > >So the issues and implementation choices are similar for parallel >numbered and unnumbered P2P links. Currently, I've implemented a >fairly liberal bi-directional check (one back-link will suffice). >What is your take on this issue? > >Thanks, >Acee I think the bi-directional check mentioned above should be enough for general SPF, which is the goal of RFC 2328. It may not be sufficient for TE CSPF, where a path has be computed from a remote node, and there has to be a way of identifying the unnumbered interface of a node several hops away. Regards, Senthil. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 16 14:12:55 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10503 for ; Wed, 16 Apr 2003 14:12:53 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.0097D84C@cherry.ease.lsoft.com>; Wed, 16 Apr 2003 14:15:30 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 668696 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 16 Apr 2003 14:15:30 -0400 Received: from 207.217.120.116 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 16 Apr 2003 14:15:30 -0400 Received: from user-38lc062.dialup.mindspring.com ([209.86.0.194] helo=earthlink.net) by grouse.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 195rRM-0001K2-00 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 16 Apr 2003 11:15:25 -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: <200304082356.h38NunH88489@garnet.juniper.net> <3E93755E.1937BC89@earthlink.net> <3E95061B.5060200@redback.com> <3E95BACC.E53FDC89@earthlink.net> <3E95BEDF.2010606@redback.com> <3E975E6E.73A22F08@earthlink.net> <3E99DAD2.9080507@redback.com> <3E9B16AC.EE25CE5F@earthlink.net> <3E9B1E03.40803@redback.com> <3E9B361F.CD83ACDC@earthlink.net> <3E9D64AD.6010908@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E9D93D3.7080182C@earthlink.net> Date: Wed, 16 Apr 2003 10:33:07 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Draft : Graceful Restart : : grace period, etc To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Acee, Inline.. Mitchell Erblich --------------------- Acee Lindem wrote: > > Erblichs wrote: > > Acee Lindem,, > > > > Inline.. > > > > > Mitchell Erblich > Sr Software Engineer > -----------, > > Inline... > > > > > > > > > Acee Lindem wrote: > > > >>Erblichs wrote: > >> > >>>Acee Lindem, > >>> > >>> Inline... > >>> > >>> Mitchell Erblich > >>> ---------------------- > >>> > >>>Acee Lindem wrote: > >>> > >>> > >>>>Erblichs wrote: > >>>> > >>>> > >>>>>Group, > >>>>> > >>>>> First of all I would want to apologize for continuing > >>>>> this discussion thread! > >>>>> > >>>>> I realize that some implimentions may exist based on > >>>>> this draft and what I am suggesting, may effect changes > >>>>> to them. > >>>> > >>>>Mitchell, > >>>> > >>>>No apologies necessary for discussion of the draft. However, please make > >>>>every attempt to read and understand it before suggesting substantive > >>>>changes. > >>>> > >>>> > >>>> > >>>>> In my past emails I have implicitly ignored the section > >>>>> 5 within this draft of "Unplanned outages". I will now > >>>>> explicitly state why I have ignored its suggested method. > >>>>> > >>>>> Why? > >>>>> * " must originate grace-LSAs *after* its control > >>>>> software resumes operation", we now lose our DR or > >>>>> BDR status, if it had existed. > >>>> > >>>>The restarting router will succeed DR status if it was previously DR. See > >>>>section 2 number 3. Also note section 5 for applicablility to unplanned > >>>>restarts. Changes in BDR should have no effect on adjacencies or LSA > >>>>contents. > >>> > >>> > >>> I am really lost here.. > >>> > >>> IFF we are unplanned, won't the normal deadrouterinterval > >>> timeouts take down the adjs? Remember the "*after*" > >>> section. > >> > >>What you are missing is that for unplanned restarts the restarting OSPF > >>router (or process) must at least start graceful restart within > >>the RouterDeadInterval period. For planned restarts, this is not a > >>restriction. > > > > > > > > That is nice.................... > > > > No, not "start graceful restart" process. Start sending hellos within > > routerdeadinterval which is after grace-LSAs are sent and recived. > > > > Yes, sending multiple grace-LSAs, but don't they need to be > > 5 secs apart? So, to send three will take 15 secs. Right?? > > In the case of implementation, I only wait 1 second between grace LSAs for > unplanned restart. > > > > > In Version 07, section 5, of the draft where is that > > ROUTERDEADINTERVAL stated??? > > Isn't that an important enough concept to be explicitly stated > > here? > > It seems obvious to me. Did anyone else miss this? I'll see about > adding something during the AD comments. > > > > > I only see "restarted router has no adjacencies and no > > knowledge of previous adjacencies". As a statement about > > adj in section 5. > > > > Wow.. Can I second and third my unplanned restart as an > > option that follows the planned restart logic without > > the routerdeadinterval restriction???? :) > > You are welcome to submit an alternate proposal but please do it > in the form of a draft rather than E-mails extolling the benefits. > I believe the current draft is a reasonable approach to unplanned > restart. One cannot signal unplanned graceful restart apriori since > you don't know whether the router or OSPF process is going to > come back. > I am first planning on submitting a draft on another feature. I will consider an experimental draft on what I am suggesting in May. > > > > > >>> If the restarting router was the DR or a BDR, a new election > >>> will occur to re-elect a new DR and/or BDR, and new adjs > >>> will form. Now, the premise of minimizing topological changes > >>> as a reason to keep the pre-shutdown DR / BDR combo, will > >>> no longer apply. > >>> > >>> Even if we declare ourselves the DR after re-start, there > >>> is only a chance that the reason why we were initially > >>> elected still applies, thus we may no longer have the > >>> highest priority of eligible routers. > >>> > >>> Mitchell Erblich > >>> --------------------------- > >>> > >>> > >>> > >>> > >>> > >>>>> - This forces a SPF recomputation.. > >>>>> - This can forces many full adj reformations. > >>>>> - Removes the helper relationship with > >>>>> respect to the restarting router > >>>>> (monitoring, continues to (its) advertise its > >>>>> LSAs, etc) NIT: remove the first "its". > >>>>> - etc.. > >>>>> > >>>>> Thus this section invalidates many of the reasons > >>>>> for the draft's existance. > >>>>> > >>>>> * If the draft's unplanned outages did not have these > >>>>> negative effects and more, then anytime > 1 hr > >>>>> graceful restart is planned, then this would be a > >>>>> solid alternative. I just cannot see anyone > >>>>> forwarding any pkts accross a non-adj, so even if > >>>>> your forwarding table contents are sanitized, it > >>>>> will be ignored. > >>>>> > >>>>> So, from may past information dump, the only true side effect > >>>>> other than mentioned in the draft (clean flag for the forwarding > >>>>> table should remove the table sanity issue) are the issues of the > >>>>> reflooding bandwidth of early grace-LSAs, just in case the router > >>>>> has an unplanned restart. And the extra work that is placed on > >>>>> helper routers to "monitor" the network for topology changes, > >>>>> and its other assigned helper duties. > >>>>> > >>>>> Thus, I believe that I have more than sufficiently identified > >>>>> a graceful restart mechanism that removes the AFTER requirement > >>>>> and allows the planned graceful restart method to be used in a > >>>>> unplanned way. Plus, I agree that a knob/CLI command should be > >>>>> used to enable or disable this type of feature. > >>>>> > >>>>> Mitchell Erblich > >>>>> Sr Software Engineer > >>>>> ---------------------- > >>>>> > >>>>>Acee Lindem wrote: > >>>>> > >>>>> > >>>>> > >>>>>>Erblichs wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>>Acee, et al, > >>>>>>> > >>>>>>> I didn't really want to continue this thread > >>>>>>> but I feel, I should restate some items here. :) > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>As Padma stated, the draft supports unscheduled restarts (there > >>>>>>>>are multiple interoperable implementations). Your proposal to > >>>>>>>>announce graceful restart in advance > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> I don't see how one can send out grace-LSAs and possibly be > >>>>>>> able to retransmit a grace-LSA OTHER than in advance, > >>>>>>> AND still support unscheduled graceful restarts!!! > >>>>>> > >>>>>>Mitchell, > >>>>>> > >>>>>>In the case of unscheduled restart you may send the grace LSA a couple > >>>>>>times but you don't want for an acknowledge (you don't necessarily know your > >>>>>>neighbors since you are learning the state from the networks). > >>>>>> > >>>>>>I suggest you read or review section 5 of the draft. It covers all of your > >>>>>>concerns below. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> You must do it in advance, else it is scheduled.. > >>>>>>> > >>>>>>> My definition of unscheduled is that some event occurs and > >>>>>>> the non-forwarding portion of the router is DOWN... No, > >>>>>>> time for an sys admin to do anything... > >>>>>>> > >>>>>>> The ONLY possible way is to have trap level code call > >>>>>>> the xmit grace-LSA code section. However, no time to > >>>>>>> see if acks have been rec'vd and no time for a 5 sec > >>>>>>> rexmit.... > >>>>>>> > >>>>>>> Ok, then WHAT is an UNSCHEDULED GRACEFUL RESTART in your > >>>>>>> guys opinion???? > >>>>>>> > >>>>>>> On the assumption that if the router fails and > >>>>>>> still abides by the condition that it is still > >>>>>>> forwarding as if it was still up.., then > >>>>>>> > >>>>>>> As long as there isn't any topologoy changes > >>>>>>> as stated within your document, that is one > >>>>>>> reason to allow for a graceful restart, I don't > >>>>>>> see the blackhole.. > >>>>>>> > >>>>>>> If the topology changes then it would invalidate > >>>>>>> my graceful restart, as it would also invalidate > >>>>>>> the graceful restart specified in the draft. > >>>>>>> > >>>>>>> The only deltas that I was asking for was: > >>>>>>> - the issue of sending out a minimal grace-LSA at > >>>>>>> adj timeframe, > >>>>>>> - being able to minimally update our grace-LSA as > >>>>>>> topology changes, > >>>>>>> - or we decide that we want to withdraw our grace-LSA > >>>>>>> via MAXAGE, > >>>>>>> > >>>>>>> As of this time, I have not read in your document, > >>>>>>> EXPLICITLY whether > >>>>>>> - you suggest to ONLY send out the grace-LSA when you > >>>>>>> have planned to do a restart (scheduled), > >>>>>>> - how to withdraw the grace-LSAs from accepted helpers > >>>>>>> when one proto-helper (to be helper), will not ack > >>>>>>> your LSA, > >>>>>>> - etc.. > >>>>>>> > >>>>>>> > >>>>>>> Mitchell Erblich > >>>>>>> Sr Software Engineer > >>>>>>> ============================ > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>Acee Lindem wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>Erblichs wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>Padma, > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> These are my last comments!! > >>>>>>>>> > >>>>>>>>> Also inline... > >>>>>>>>> > >>>>>>>>> Why doesn't the draft RFC authors want to > >>>>>>>>> allow non-scheduled restarts in this > >>>>>>>>> draft? > >>>>>>>> > >>>>>>>>Michell, > >>>>>>>> > >>>>>>>>As Padma stated, the draft supports unscheduled restarts (there > >>>>>>>>are multiple interoperable implementations). Your proposal to > >>>>>>>>announce graceful restart in advance will unnecessarily delay > >>>>>>>>the detection of a black hole if the restarting router is really dead > >>>>>>>>or was abruptly decommissioned. The current draft doesn't suffer > >>>>>>> > >>>>>>>>from this flaw. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>> Is there something wrong with the idea > >>>>>>>>> of un-scheduled restarts? > >>>>>>>>> > >>>>>>>>> Why restrict it to only scheduled > >>>>>>>>> restarts??? > >>>>>>>>> > >>>>>>>>> Why require > >>>>>>>>> the grace-LSAs to be reflooded every > >>>>>>>>> 30 minutes to 1 hr??? > >>>>>>>>> > >>>>>>>>> Why not send the grace-LSAs without > >>>>>>>>> the Type=1, Length=4 grace period field?? > >>>>>>>>> It will be determined by the helpers > >>>>>>>>> anyway. > >>>>>>>>> > >>>>>>>>> The sentance is. > >>>>>>>>> > >>>>>>>>> "The number of seconds that the router's > >>>>>>>>> neighbors should continue to advertise the > >>>>>>>>> router as fully adjacent".... > >>>>>>>>> > >>>>>>>>> Thus, without the word "MUST", implimentations > >>>>>>>>> will probably follow their own rules. Thus, the > >>>>>>>>> grace period field really isn't needed and just > >>>>>>>>> consumes bandwidth!!! > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Mitchell Erblich > >>>>>>>>> =================== > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>Padma Pillay-Esnault wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>Mitchell, > >>>>>>>>>> > >>>>>>>>>>I'll try to address your comments > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>Acee Lindem, > >>>>>>>>>>> > >>>>>>>>>>> Since,, you skipped the inline re-comments, I will assume > >>>>>>>>>>> that at least you read them.. :) > >>>>>>>>>>> > >>>>>>>>>>> I think I have expressed as best as I could (I am not > >>>>>>>>>>> a tech writer) how I feel that this draft should evolve. > >>>>>>>>>>> > >>>>>>>>>>> So in summary... > >>>>>>>>>>> > >>>>>>>>>>>` 0) Remove the length (seconds) field from the grace-LSA. > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>This is using the TLV format .. so you want to keep the length > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Of course, Type, Length, Value... Fine. Reword.. > >>>>>>>>> Remove > >>>>>>>>> the Grace-Period field of (Type =1, Length = 4). > >>>>>>>>> Why transmit the field value????? > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> 1) Transmit DNA grace-LSAs at adj creation time. > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>This is not very useful. Today unless you have DNA lsa you cannot > >>>>>>>>>>expect to be requesting a grace period of over one hour -- as > >>>>>>>>>>all the LSA in the other routers database will expire at the > >>>>>>>>>>most in 1hr. > >>>>>>>>>>So if you decide to send a grace LSA it would be the most recent one > >>>>>>>>>>that you built and hence if it has time to expire then the previous > >>>>>>>>>>would already be gone. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Think ahead of tomarrow, not today... > >>>>>>>>> How should this work in the utopian word? If the graceful > >>>>>>>>> restart is a good idea, then it NOT should be used for ALL > >>>>>>>>> possible restarts?? > >>>>>>>>> > >>>>>>>>> Why not restrict the amount of flooding with THESE types > >>>>>>>>> of LSAs if this draft becomes a standard RFC?? > >>>>>>>>> > >>>>>>>>> What happens if I send the grace-LSAs at adj formation > >>>>>>>>> time and then reflood them every 55 minutes?? This > >>>>>>>>> removes the lightweight mechanism of the draft, but > >>>>>>>>> still gets me unscheduled restart functionality? Maybe > >>>>>>>>> i will just do that.. BTW, and also do unscheduled > >>>>>>>>> restarts with my BGP protocol once it becomes a > >>>>>>>>> standard. > >>>>>>>>> > >>>>>>>>> Thus, a restriction of 1 hr isn't sensible. Else, even if > >>>>>>>>> I follow your logic, then why do I ask for 1 hr? Should > >>>>>>>>> my implimentation in the helper not ack the grace-LSA if > >>>>>>>>> the specified grace-period is over 1 hr from the restarting > >>>>>>>>> router? This is unspecified behavior!!! > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> 2) Let the helpers determine amount of time that > >>>>>>>>>>> they will function as a helper. Suggest a minimum > >>>>>>>>>>> of 1 hr time. > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>This is a matter of policy .. even if the helper decides that > >>>>>>>>>>he is not going to help for the whole period .. as he is not > >>>>>>>>>>going to signal it to the restarting router .. I do not see > >>>>>>>>>>the use of doing so. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> 3) Reflood the DNA grace-LSAs anytime the contents > >>>>>>>>>>> have changed. > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>See my response in 1. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> 4) If the restart router expects to be down for a period > >>>>>>>>>>> longer than X, then retransmit the Grace-LSAs as > >>>>>>>>>>> MAXage LSAs. > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>I do not see the benefit or I am missing your point > >>>>>>>>>> > >>>>>>>>>>Padma > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> This would minimize bandwidth requirements and allow a > >>>>>>>>>>> restarting router to have either scheduled or unscheduled > >>>>>>>>>>> restarts. > >>>>>>>>>>> > >>>>>>>>>>> I don't know what else to add, except if you adopt one or > >>>>>>>>>>> more of these suggestions, then please add my name to your > >>>>>>>>>>> comment list. :) > >>>>>>>>>>> > >>>>>>>>>>> Mitchell Erblich > >>>>>>>>>>> Sr Software Engineer > >>>>>>>>>>> ============================ > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>Acee Lindem wrote: > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>Erblichs wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>>Acee Lindem, > >>>>>>>>>>>>> > >>>>>>>>>>>>> Sometimes my logic is a little obtuse.. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Most of it is inline... > >>>>>>>>>>>>> > >>>>>>>>>>>>> I will first throw two new questions to you!!!! > >>>>>>>>>>>>> > >>>>>>>>>>>>> 1) Why don't you send out the Grace LSA at full > >>>>>>>>>>>>> adj timeframe. It would take effect after > >>>>>>>>>>>>> RouterDeadinterval has expired? > >>>>>>>>>>>> > >>>>>>>>>>>>How do you know, apriori, that the OSPF instance is > >>>>>>>>>>>>restarting and not completely dead? > >>>>>>>>>>> > >>>>>>>>>>> Why do you care? As long as the topology isn't changing > >>>>>>>>>>> then everything is ok. > >>>>>>>>>>> > >>>>>>>>>>> Wwhy not minimize the effects of unnecessary SPF computations? > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> This would also take care of unscheduled restarts > >>>>>>>>>>>>> and allow you to do an unscheduled graceful > >>>>>>>>>>>>> restart!!!! > >>>>>>>>>>>>> > >>>>>>>>>>>>> You could also send them as DNA LSAs.. See inline. > >>>>>>>>>>>>> > >>>>>>>>>>>>> The only new twist is that if you then schedule > >>>>>>>>>>>>> a restart, you may want to be able to cancel your > >>>>>>>>>>>>> previous request or update the LSAs over time. > >>>>>>>>>>>>> But if you conisder a stable topology, then why > >>>>>>>>>>>>> NOT?? > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> 2) A) 2.1 3rd, paragraph.. > >>>>>>>>>>>>> "Their age field set to 0," > >>>>>>>>>>>>> Why can't you send DNA grace-LSAs???? > >>>>>>>>>>>> > >>>>>>>>>>>>You wouldn't gain anything since the grace interval cannot > >>>>>>>>>>>>exceed the LSA refresh time. > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> So, first why do you need to specify the grace-LSA > >>>>>>>>>>> timeframe. Let it be implicitly known to be 1 hr! > >>>>>>>>>>> > >>>>>>>>>>> With DNA grace-LSAs, we > >>>>>>>>>>> don't need to reflood them. If I sent them out > >>>>>>>>>>> at adj creation time and the topology isn't > >>>>>>>>>>> changing, then I don't need to consume > >>>>>>>>>>> resources and keep on re-flooding them.. > >>>>>>>>>>> > >>>>>>>>>>> Thus, they can last multiple hours or longer.. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> B) 2.1, 4th paragraph. > >>>>>>>>>>>>> > >>>>>>>>>>>>> "it should retransmit... until > >>>>>>>>>>>>> they are acknowledged". If you can't retransmit the > >>>>>>>>>>>>> same LSA until 5 secs have passed, if a router > >>>>>>>>>>>>> was congested, you may want to resubmit the grace-LSA > >>>>>>>>>>>>> with a longer length timeframe to your helpers. I am > >>>>>>>>>>>>> assuming just bump your instance. Correct? > >>>>>>>>>>>> > >>>>>>>>>>>>There are implementations that back off LSA retransmissions and the > >>>>>>>>>>>>"Prioritized Treatment of Specific OSPF Packets and Congestion > >>>>>>>>>>>>Avoidance" draft recommends this. However, this is not standard > >>>>>>>>>>>>OSPF flooding as described in RFC2328 and it is an independent > >>>>>>>>>>>>issue. > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> No, no, you are missing my point. Until all of your grace-LSAs are > >>>>>>>>>>> ack'ed, you can't continue successfully with a graceful-restart. > >>>>>>>>>>> > >>>>>>>>>>> This delay consumes time that you specified in your grace-LSA. Yea, > >>>>>>>>>>> again, I don't know why you need to specify the amount of time!! > >>>>>>>>>>> The timeframe that the helpers will help you can be set independently > >>>>>>>>>>> and your spec doesn't allow them to communicate the amount of time > >>>>>>>>>>> that they will keeep around a grace-LSA. > >>>>>>>>>>> > >>>>>>>>>>> Sorry, minor sidetrack. So, the time consumed to get the ack, actually > >>>>>>>>>>> reduces the amount of time before the grace-LSA expires. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> Mitchell > >>>>>>>>>>>>> ================ > >>>>>>>>>>>>>Acee Lindem wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>>Mitchell, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>See answers below. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>Erblichs wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>>Group, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> 1) Within 2.1 "Entering graceful restart", iff all > >>>>>>>>>>>>>>> the LSAs were from DC specified NBRs with DNA > >>>>>>>>>>>>>>> LSAs should the LS RefreshTime still be followed? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>LSA Refresh isn't relevant since the restarting router will > >>>>>>>>>>>>>>reestablish adjacencies. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Then why have a suggestion of 1800 secs for LSReshTime > >>>>>>>>>>>>> in your draft at the end of the 1st paragraph in section > >>>>>>>>>>>>> 2.1? > >>>>>>>>>>>>> > >>>>>>>>>>>>> In my scenario, there would be no reason not to let the > >>>>>>>>>>>>> value approach or exceed 3600 secs (1 hr). > >>>>>>>>>>>>> > >>>>>>>>>>>>> variation on a theme? Why not let the max value of your > >>>>>>>>>>>>> grace-LSA length field allow the helper determine what > >>>>>>>>>>>>> is the max that he will support? > >>>>>>>>>>>>> -- what happens if you specify a value that is > >>>>>>>>>>>>> greater than what the helper supports? > >>>>>>>>>>>>> Ans A: The helper sees it as an invalid request > >>>>>>>>>>>>> and throws away the whole request, > >>>>>>>>>>>>> > >>>>>>>>>>>>> OR > >>>>>>>>>>>>> Ans B: The helper determines what the length he > >>>>>>>>>>>>> will support? > >>>>>>>>>>>>> > >>>>>>>>>>>>> If it is B, then why have the length field. Just let > >>>>>>>>>>>>> the helper decide how long to support the request? > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>>> 2) Within 2.2 "When to exit graceful restart", number > >>>>>>>>>>>>>>> (3) "The grace period expires". > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> What happens if we follow #3 and your #1 "reestablished > >>>>>>>>>>>>>>> all its adjacencies" criteria is not met? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>The restarting router will exit graceful restart anyway. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Why? If you still have a non-changing topology, why > >>>>>>>>>>>>> limit the value to what you had said to the helpers? > >>>>>>>>>>>>> > >>>>>>>>>>>>> So, what if you asked for x time and it took you > >>>>>>>>>>>>> x + y time? > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>>> Or are you stating that the specified "grace period" was > >>>>>>>>>>>>>>> to short to perform what was required? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>Not necessarily - perhaps the topology has changed and graceful restart > >>>>>>>>>>>>>>cannot be completed successfully. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> 3) Within 2.2. Would seeing a hello without the graceful > >>>>>>>>>>>>>>> restarting router id", force it to exit? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>No. The adjacency can go all the way down on the helper router. The hello > >>>>>>>>>>>>>>shouldn't be used as a criteria for exiting helper mode. Do not confuse > >>>>>>>>>>>>>>this with other graceful restart proposals. > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> I see that my question with the hello was answered in the > >>>>>>>>>>>>> 2. (3) "an hello packet is received".. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I am confused. One router may list you as the DR and another > >>>>>>>>>>>>> may not? If one is a helper, then why would it take the adj > >>>>>>>>>>>>> down if all the crieria were met? > >>>>>>>>>>>>> > >>>>>>>>>>>>> I thought that helpers > >>>>>>>>>>>>> MUST send hellos as if you (graceful restarting router) were > >>>>>>>>>>>>> still there!! > >>>>>>>>>>>>> "an Hello packet is received from a neighbor listing the > >>>>>>>>>>>>> router as the Designated Router". > >>>>>>>>>>>>> > >>>>>>>>>>>>> If it did keep anouncing you in the hellos (you weren't > >>>>>>>>>>>>> the DR) and lets say that the DR went down. Could you > >>>>>>>>>>>>> then be elected as the DR while you were still rebooting? > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>>> 4) Within 2.2. Would seeing a hello without the graceful > >>>>>>>>>>>>>>> restarting router id as the earlier DR or BDR, cause > >>>>>>>>>>>>>>> it to exit, if it was a DR / BDR? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>Not directly, but an inconsistency with the pre-restart LSA will cause > >>>>>>>>>>>>>>the restarting router to exist graceful restart prematurely. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> 5) Within 2.2. Is it implimentation dependent on how we > >>>>>>>>>>>>>>> determine our existing nbrs and place their router ids > >>>>>>>>>>>>>>> in a hello? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>This isn't changed for graceful restart. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> I thought that you could save past nbr-ids in NVRAM > >>>>>>>>>>>>> and then compare to existing hellos... > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>>> 6) Within 2.2 (1), isn't adj establishment partly the > >>>>>>>>>>>>>>> recieving of hellos, with your own router-id? Shouldn't > >>>>>>>>>>>>>>> that inform others that we are back and to cancel > >>>>>>>>>>>>>>> their helper graceful nbr timer? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> 7 & 8) Within 2.3 "Actions on exiting graceful restart". > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> 7) Shouldn't the sending hellos be performed that > >>>>>>>>>>>>>>> identify full adj be a criteria here? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>No. LSA convergence with the pre-restart LSAs is a much surer > >>>>>>>>>>>>>>mechanism for determining the graceful restart can be exited. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> 8) I am unsure whether you are specifying the > >>>>>>>>>>>>>>> storage of part of restarting router's LSDB into > >>>>>>>>>>>>>>> non-volatile memory. If so, then upon retrieval, > >>>>>>>>>>>>>>> shouldn't some elements of the LSDB be aged > >>>>>>>>>>>>>>> by the amount that the actual amount of time > >>>>>>>>>>>>>>> the LSAs were in NV memory? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>There is no mention of storing LSAs in non-volatile storage. > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Ok, you aren't suggesting saving the LSDB in NVRAM > >>>>>>>>>>>>> or some other type of storage media.. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>>> Mitchell Erblich > >>>>>>>>>>>>>>> ================================== > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>-- > >>>>>>>>>>>>>>Acee > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>-- > >>>>>>>>>>>>Acee > >>>>>>>>>>> > >>>>>>>>-- > >>>>>>>>Acee > >>>>>>> > >>>>>>> > >>>>>>-- > >>>>>>Acee > >>>>> > >>>>> > >>>>-- > >>>>Acee > >>> > >>> > >>-- > >>Acee > > > > > > -- > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 16 14:54:44 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11841 for ; Wed, 16 Apr 2003 14:54:43 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.0097DB55@cherry.ease.lsoft.com>; Wed, 16 Apr 2003 14:57:22 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 668893 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 16 Apr 2003 14:57:22 -0400 Received: from 207.217.120.126 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 16 Apr 2003 14:57:21 -0400 Received: from user-38lc062.dialup.mindspring.com ([209.86.0.194] helo=earthlink.net) by turkey.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 195s5q-0007cQ-00; Wed, 16 Apr 2003 11:57:15 -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: <3E9AF59A.EDDEA082@earthlink.net> <1376.219.65.135.92.1050347600.squirrel@mail.apara.com> <3E9B4022.E2672125@earthlink.net> <20030415.100708.115585230.yasu@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3E9D9D9A.5091B926@earthlink.net> Date: Wed, 16 Apr 2003 11:14:50 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Changing router name... Comments: To: Yasuhiro Ohara To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Yasuhiro Ohara wrote: > > Hi, Erblichs > > > Simplying, multiple OSPF process support has > > additional requirements. > > > > One CAN NOT just takes the highest value > > interface or select a loopback. > > I don't think so. To be more precise, taking the highest value as RID > for a particular OSPF process will be above "the interfaces enabled > for that OSPF process". Generally it is likely that the operational > interfaces differs per OSPF processes (and it may not be even overlapped). > > Changing which interface to enable per OSPF processes is the easiest way > to controlling RID for the process, on the simplest algorithm to choose > RID (i.e. choosing highest value). Configuring multiple loopback interface > implies this I guess. If the interfaces of your router are separated by different domains, THEN your argument holds true. What I was going for was.. Within a multiple OSPF process environment, as RIDs are selected, their should be some algorithm that verifies that each of them are unique. Since, the selection of a BMA environment uses RIDs as the 2nd component in DR/BDR elections (the first being priority), selecting the highest available interface value for your process RID, is not necessary the best option. > > > If there are multiple interfaces or > > loopbacks, then one must be able to identify > > that the object in question has been allocated > > to a particular process and thus is not eligible > > to be allocated a 2nd time.. > > Besides all, using the same RID for multiple OSPF process will > have no problem. What RID require is just to be unique within > a OSPF domain. If OSPF domain differs, duplication of RID > does not break anything. > To assume no interaction of OSPF proceess's is risky at best. At worst, you are dealing with duplicate RIDs. In my mind, not creating duplicate RIDs is just easier. > regards, > yasu From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 16 22:23:07 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24332 for ; Wed, 16 Apr 2003 22:23:06 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.0097F382@cherry.ease.lsoft.com>; Wed, 16 Apr 2003 22:25:43 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 670629 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 16 Apr 2003 22:25:42 -0400 Received: from 207.172.4.61 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 16 Apr 2003 22:15:42 -0400 X-Info: This message was accepted for relay by smtp02.mrf.mail.rcn.net as the sender used SMTP authentication X-Trace: UmFuZG9tSVYUo0nPsWiqld+2sQu6LCW0siaJagbNQT/R+XAj7xUyildeGHoAwVpq Received: from pool-141-154-71-73.bos.east.verizon.net ([141.154.71.73] helo=rcn.com) by smtp02.mrf.mail.rcn.net with asmtp (Exim 3.35 #4) id 195ywA-0000r3-00 for OSPF@discuss.microsoft.com; Wed, 16 Apr 2003 22:15:42 -0400 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E9E1C3F.8050603@rcn.com> Date: Wed, 16 Apr 2003 22:15:11 -0500 Reply-To: Mailing List Sender: Mailing List From: David Hudek Subject: Re: Multiple un-numbered serial links between two routers To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit >So the issues and implementation choices are similar for parallel >numbered and unnumbered P2P links. Currently, I've implemented a >fairly liberal bi-directional check (one back-link will suffice). >What is your take on this issue? Just a quick note that such a liberal approach would seem to be well supported by Sec 16.1, step 2(b) in its reference to footnote [23] "...Note that the presence of any link back to V is sufficient; it need not be the matching half of the link under consideration from V to W..." dave hudek dhudek@rcn.com From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 17 07:36:25 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16337 for ; Thu, 17 Apr 2003 07: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 <23.00980A39@cherry.ease.lsoft.com>; Thu, 17 Apr 2003 7:39:03 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 672725 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 17 Apr 2003 07:39:02 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 17 Apr 2003 07:29:01 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15828; Thu, 17 Apr 2003 07:26:20 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200304171126.HAA15828@ietf.org> Date: Thu, 17 Apr 2003 07:26:20 -0400 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-mib-update-06.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : OSPF Version 2 Management Information Base Author(s) : S. Giacalone, D. Joyal, R. Coltun, F. Baker Filename : draft-ietf-ospf-mib-update-06.txt Pages : 102 Date : 2003-4-16 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Open Shortest Path First Routing Protocol. This memo is intended to update and possibly obsolete RFC 1850, however, it is designed to be backwards compatible. The functional differences between this memo and RFC 1580 are explained in Appendix B. Please send comments to ospf@discuss.microsoft.com. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-mib-update-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-mib-update-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-mib-update-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-16135703.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-mib-update-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-mib-update-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-16135703.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 17 13:05:55 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28666 for ; Thu, 17 Apr 2003 13:05:55 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00981016@cherry.ease.lsoft.com>; Thu, 17 Apr 2003 13:08:33 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 673689 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 17 Apr 2003 13:08:33 -0400 Received: from 207.172.4.61 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 17 Apr 2003 13:08:33 -0400 X-Info: This message was accepted for relay by smtp02.mrf.mail.rcn.net as the sender used SMTP authentication X-Trace: UmFuZG9tSVaIV4tKAjlJ3zTesVRm+vj6Bb+9NwiW4OMdCQwHfneMUVD92LOymTSk Received: from pool-68-160-134-177.bos.east.verizon.net ([68.160.134.177] helo=rcn.com) by smtp02.mrf.mail.rcn.net with asmtp (Exim 3.35 #4) id 196CsC-0007We-00 for ospf@discuss.microsoft.com; Thu, 17 Apr 2003 13:08:32 -0400 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3E9EED8C.9050002@rcn.com> Date: Thu, 17 Apr 2003 13:08:12 -0500 Reply-To: Mailing List Sender: Mailing List From: David Hudek Subject: Problems in changing router's name To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit >In Rfc2328 chap 5 is said that if the smallest interface >(router ID; in ZEBRA i saw that router ID was the HIGHEST >interface! Is it possible or am i mistaking?) >goes down, router ID changes and OSPF software should be >restarted before new router ID takes effect. > >Again, in draft-katz-yeung-ospf-traffic-09.txt 2.4.1 is >said that Router address TLV contains a "stable" IP address >of the advertising router that is always reachable! >Stable means that IP address router doesn't change? >But if i disable the interface that names a Linux router, >OSPF could update the topology or could >maintain the old router name even if that interface is down. I believe that the note in chapter 5 of rfc2328 only mentions a "possible implementation strategy", not a mandatory one, and not necessarily the best for all circumstances. In any event, router ID flapping is not a "good thing" and you might want to use a strategy that avoids unwarranted changes. dave hudek dhudek@rcn.com From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 18 07:26:06 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09071 for ; Fri, 18 Apr 2003 07:26:05 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00983284@cherry.ease.lsoft.com>; Fri, 18 Apr 2003 7:28:43 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 676322 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 18 Apr 2003 07:28:43 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 18 Apr 2003 07:18:43 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08502; Fri, 18 Apr 2003 07:16:01 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200304181116.HAA08502@ietf.org> Date: Fri, 18 Apr 2003 07:16:01 -0400 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-ospfv3-traffic-00.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Traffic Engineering Extensions to OSPF version 3 Author(s) : K. Ishiguro, T. Takada Filename : draft-ietf-ospf-ospfv3-traffic-00.txt Pages : 5 Date : 2003-4-17 This document describes extensions to the OSPF version 3 to support intra-area Traffic Engineering. This document expands OSPFv2 traffic engineering to make both IPv4 and IPv6 network applicable. New sub-TLVs are defined to support IPv6 network. Use of these new sub-TLVs are not limited in OSPF version 3. They can be used in OSPF version 2. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-traffic-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-ospfv3-traffic-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-ospfv3-traffic-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-17132222.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-ospfv3-traffic-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-ospfv3-traffic-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-17132222.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 18 09:59:04 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13706 for ; Fri, 18 Apr 2003 09:59:04 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00983747@cherry.ease.lsoft.com>; Fri, 18 Apr 2003 10:01:42 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 676558 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 18 Apr 2003 10:01:41 -0400 Received: from 193.70.192.127 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 18 Apr 2003 10:01:41 -0400 Received: from libero.it (193.70.192.37) by smtp3.libero.it (7.0.012) id 3E9BEF520005D81E for OSPF@DISCUSS.MICROSOFT.COM; Fri, 18 Apr 2003 16:01:40 +0200 MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 X-XaM3-API-Version: 3.2 R29 (B54 pl1) X-type: 0 X-SenderIP: 81.73.170.22 Message-ID: Date: Fri, 18 Apr 2003 16:01:40 +0200 Reply-To: Mailing List Sender: Mailing List From: "=?iso-8859-1?Q?john151@libero.it?=" Subject: =?iso-8859-1?Q?Opaque_LSA_Timers...?= To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA13706 Hi all, i excuse me for this and previous observation, but i considered the administrative group information very important, because i think they can come from network administrator or from any administrative tool and perhaps the administrator doesn' t want to wait MinLSInterval seconds to send his update; so i thought was reasonable to do a separate timer for this particular and important opaque field. Do you agree? I read there was proposals in the past to reduce or ignore MinLSInterval, but i agree with the important presence of MinLSInterval; i only think to a separate management. Was this proposals (or drafts ) specific to my consideration and did they refer to the only Opaque administrative field? Thanks in advance for your answers and kindness. Giovanni Coritel - Rome From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 18 13:57:01 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20896 for ; Fri, 18 Apr 2003 13:57:01 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00983DD6@cherry.ease.lsoft.com>; Fri, 18 Apr 2003 13:59:40 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 677192 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 18 Apr 2003 13:59:39 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 18 Apr 2003 13:59:39 -0400 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 0E524130F20 for ; Fri, 18 Apr 2003 10:59:38 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3EA03D1C.900@redback.com> Date: Fri, 18 Apr 2003 13:59:56 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Opaque LSA Timers... To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit john151@libero.it wrote: > Hi all, > i excuse me for this and previous observation, but > i considered the administrative group information very important, > because i think they can come from network administrator or from > any administrative tool and perhaps the administrator doesn' t want > to wait MinLSInterval seconds to send his update; > so i thought was reasonable to do a separate timer for this > particular and important opaque field. Do you agree? Giovanni, I don't agree for (at least) the following reasons: 1. This is just one variation of the "re-originate the LSA faster" requirement. We can't afford to have a separate solution for each variation. 2. Multiple timers LSA Interval timers (which I assume you use to advertise if any interval is satisfied) would add undue complexity and overhead. 3. While we have Not-So-Stubby Areas I don't think we want Not-So-Opaque LSAs. If the contents of the LSAs are truly opaque they should not have ramifications on the base flooding algorithm. Thanks, Acee > > I read there was proposals in the past to reduce or ignore > MinLSInterval, but i agree with the important presence of MinLSInterval; > i only think to a separate management. > > Was this proposals (or drafts ) specific to my consideration and did they refer > to the only Opaque administrative field? > > Thanks in advance for your answers and kindness. > > Giovanni > Coritel - Rome > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 18 18:33:09 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29880 for ; Fri, 18 Apr 2003 18:33:09 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0098451F@cherry.ease.lsoft.com>; Fri, 18 Apr 2003 18:35:49 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 677752 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 18 Apr 2003 18:35:49 -0400 Received: from 207.217.120.116 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 18 Apr 2003 18:35:49 -0400 Received: from user-2ivfk55.dialup.mindspring.com ([165.247.208.165] helo=earthlink.net) by grouse.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 196eSR-00036g-00 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 18 Apr 2003 15:35:47 -0700 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3EA07DBD.6A3D8C6E@earthlink.net> Date: Fri, 18 Apr 2003 15:35:41 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: draft - ospf-scalability-03.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, Ignoring the reasons for possibly implimenting the below feature... As a past contributor to an ARC (architecture review committee), a frequent question was, is that proposal downward scalable? I question whether implimentating, the ability for every OSPF packet over an adj to reset the Inactivity timer could cause more harm than good. Given a 50k LSDB, with a normal amount of flooding is isn't unlikely that we would see about 100k worth of update pkts per hr. Would 100k per hr of inactivity timer resets cause harm in routers? Does anybody else have a concern, that this type of item should be explicitly stated within the doc? With each 10 sec hello interval, I would expect to see 360 resets per nbr of the Inactivity timers. Mitchell Erblich Sr Software Engineer ------------------------------- "Manral, Vishwas" wrote: > > Hi Vivek, > > This has been updated in version 4 of the draft, which has recently been > completed. The current text reads: - > > " reset the Inactivity Timer for an adjacency whenever any OSPF > packet is received over that adjacency " > > Thanks, > Vishwas > > -----Original Message----- > From: Vivek Dubey [mailto:vivek_ospf@REDIFFMAIL.COM] > Sent: Wednesday, April 16, 2003 10:33 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: draft - ospf-scalability-03.txt > > Hi, > Section 2: > 2) Reset the Inactivity Timer for an interface whenever any OSPF > packet is received over that interface (currently this is done > only > for the Hello packet). > So OSPF would declare the interface to be down only if no > OSPF packet is received over that interface for a period > equaling or exceeding the RouterDeadInterval. > > Here what the paragraph implies seems little unclear. > a) Inactivity timer are neighbor specific, so > why should the one for interface be restarted ? > b) Why should Ospf interface be made down if no packets > are received on it ? > c) Probably it should be something like this: > "Reset the inactivity timer for a Neighbor whenever any > Ospf packet is received from that neighbor" > > Or i missed the point the draft tries to make ???? > > vivek From owner-ospf@DISCUSS.MICROSOFT.COM Fri Apr 18 20:01:05 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01728 for ; Fri, 18 Apr 2003 20:01: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.0098488F@cherry.ease.lsoft.com>; Fri, 18 Apr 2003 20:03:44 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 677946 for OSPF@DISCUSS.MICROSOFT.COM; Fri, 18 Apr 2003 20:03:44 -0400 Received: from 207.17.136.129 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 18 Apr 2003 20:03:44 -0400 Received: from cirrus.juniper.net (cirrus.juniper.net [172.17.20.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h3J03hu42760 for ; Fri, 18 Apr 2003 17:03:43 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: (from dkatz@localhost) by cirrus.juniper.net (8.11.6/8.11.6) id h3J03hX80447; Fri, 18 Apr 2003 17:03:43 -0700 (PDT) (envelope-from dkatz@cirrus.juniper.net) References: <3EA07DBD.6A3D8C6E@earthlink.net> Message-ID: <200304190003.h3J03hX80447@cirrus.juniper.net> Date: Fri, 18 Apr 2003 17:03:43 -0700 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: draft - ospf-scalability-03.txt To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3EA07DBD.6A3D8C6E@earthlink.net> (message from Erblichs on Fri, 18 Apr 2003 15:35:41 -0700) Precedence: list Ignoring the reasons for possibly implimenting the below feature... As a past contributor to an ARC (architecture review committee), a frequent question was, is that proposal downward scalable? I question whether implimentating, the ability for every OSPF packet over an adj to reset the Inactivity timer could cause more harm than good. Given a 50k LSDB, with a normal amount of flooding is isn't unlikely that we would see about 100k worth of update pkts per hr. Would 100k per hr of inactivity timer resets cause harm in routers? This is an implementation issue. Those who are sufficiently clever will succeed, those who are not will fail. Protocols like OSPF are filled with scalability issues, and the ability to deal with them efficiently is one of the few product differentiators. (Full BGP routing in OSPF anyone?) From owner-ospf@DISCUSS.MICROSOFT.COM Sat Apr 19 03:28:50 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20018 for ; Sat, 19 Apr 2003 03:28:50 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00985374@cherry.ease.lsoft.com>; Sat, 19 Apr 2003 3:31:29 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 678597 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 19 Apr 2003 03:31:29 -0400 Received: from 203.199.83.25 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 19 Apr 2003 03:31:29 -0400 Received: (qmail 15370 invoked by uid 510); 19 Apr 2003 07:37:15 -0000 Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 19 apr 2003 07:37:15 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20030419073715.15369.qmail@webmail15.rediffmail.com> Date: Sat, 19 Apr 2003 07:37:15 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: Re: draft - ospf-scalability-03.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, If network is stable and there is no congestion and outage problems, restart of inactivity timer (for every OSPF packet over adjacency) might be overhead. But if "Congestion Detection" leads to ways to prevent outages "resettting of inactivity timer" this overhead might be worth it. "draft-ash-manral-ospf-congestion-control-00.txt " talks about possible ways of detecting and avoiding congestion. Again implementations may vary depending upon requirenments. For Vishwas: Is there any new version of "draft-ash-manral-ospf-congestion-control-00.txt " ??? thanks, vivek On Sat, 19 Apr 2003 Dave Katz wrote : > Ignoring the reasons for possibly implimenting > the below feature... > > As a past contributor to an ARC (architecture >review > committee), a frequent question was, is that >proposal > downward scalable? > > I question whether implimentating, the ability for > every OSPF packet over an adj to reset the >Inactivity > timer could cause more harm than good. > > Given a 50k LSDB, with a normal amount of flooding > is isn't unlikely that we would see about 100k >worth > of update pkts per hr. > > Would 100k per hr of inactivity timer resets cause > harm in routers? > >This is an implementation issue. Those who are sufficiently >clever will succeed, those who are not will fail. > >Protocols like OSPF are filled with scalability issues, and the >ability to deal with them efficiently is one of the few product >differentiators. (Full BGP routing in OSPF anyone?) From owner-ospf@DISCUSS.MICROSOFT.COM Sat Apr 19 03:37:00 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20126 for ; Sat, 19 Apr 2003 03:37: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.0098532C@cherry.ease.lsoft.com>; Sat, 19 Apr 2003 3:39:41 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 678618 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 19 Apr 2003 03:39:41 -0400 Received: from 203.199.83.38 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 19 Apr 2003 03:39:40 -0400 Received: (qmail 11574 invoked by uid 510); 19 Apr 2003 07:45:26 -0000 Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 19 apr 2003 07:45:26 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20030419074526.11573.qmail@webmail28.rediffmail.com> Date: Sat, 19 Apr 2003 07:45:26 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: Re: Opaque LSA Timers... To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi Acee, Your reasons for not supporting such variations are agreeable but: "If Ospf is providing a service to application (by mean of Opaque LSA), there is every reason for an application to except some priority service in case of requirements." Because flooding of application specific information shouldn't be entirely retricted by base protocol flooding algorithm. Possibly there is scope to explore ways to handle such requirments in a generalized way. thanks, vivek On Fri, 18 Apr 2003 Acee Lindem wrote : >john151@libero.it wrote: >>Hi all, >>i excuse me for this and previous observation, but >>i considered the administrative group information very >>important, >>because i think they can come from network administrator or >> from >>any administrative tool and perhaps the administrator doesn' t >>want >>to wait MinLSInterval seconds to send his update; >>so i thought was reasonable to do a separate timer for this >>particular and important opaque field. Do you agree? > >Giovanni, > >I don't agree for (at least) the following reasons: > > 1. This is just one variation of the "re-originate the LSA >faster" > requirement. We can't afford to have a separate solution >for > each variation. > 2. Multiple timers LSA Interval timers (which I assume you >use > to advertise if any interval is satisfied) would add >undue > complexity and overhead. > 3. While we have Not-So-Stubby Areas I don't think we want > Not-So-Opaque LSAs. If the contents of the LSAs are truly > opaque they should not have ramifications on the base > flooding algorithm. > >Thanks, >Acee > > >> >>I read there was proposals in the past to reduce or ignore >>MinLSInterval, but i agree with the important presence of >>MinLSInterval; >>i only think to a separate management. >> >>Was this proposals (or drafts ) specific to my consideration and >>did they refer >>to the only Opaque administrative field? >> >>Thanks in advance for your answers and kindness. >> >>Giovanni >>Coritel - Rome >> > > >-- >Acee From owner-ospf@DISCUSS.MICROSOFT.COM Sat Apr 19 06:18:49 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22443 for ; Sat, 19 Apr 2003 06:18: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.009856B7@cherry.ease.lsoft.com>; Sat, 19 Apr 2003 6:21:25 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 679080 for OSPF@DISCUSS.MICROSOFT.COM; Sat, 19 Apr 2003 06:21:25 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 19 Apr 2003 06:21:24 -0400 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 7CDA6918080 for ; Sat, 19 Apr 2003 03:21:23 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030419074526.11573.qmail@webmail28.rediffmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3EA1232D.4090007@redback.com> Date: Sat, 19 Apr 2003 06:21:33 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Opaque LSA Timers... To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Vivek Dubey wrote: > Hi Acee, > Your reasons for not supporting such variations > are agreeable but: > "If Ospf is providing a service to application (by > mean of Opaque LSA), there is every reason for > an application to except some priority service > in case of requirements." > > Because flooding of application specific information > shouldn't be entirely retricted by base protocol > flooding algorithm. > > Possibly there is scope to explore ways to handle > such requirments in a generalized way. Hi Vivek, A generalized solution to decrease flooding latency would be the only thing that makes any sense. Personally, I don't buy the argument that MinLSInterval is too large an upper bound for the delay on administrative TE changes to be flooded. However, that really isn't the most important issue here. > > thanks, > vivek > > > > > > On Fri, 18 Apr 2003 Acee Lindem wrote : > >> john151@libero.it wrote: >> >>> Hi all, >>> i excuse me for this and previous observation, but >>> i considered the administrative group information very >>> important, >>> because i think they can come from network administrator or >>> from >>> any administrative tool and perhaps the administrator doesn' t >>> want >>> to wait MinLSInterval seconds to send his update; >>> so i thought was reasonable to do a separate timer for this >>> particular and important opaque field. Do you agree? >> >> >> Giovanni, >> >> I don't agree for (at least) the following reasons: >> >> 1. This is just one variation of the "re-originate the LSA >> faster" >> requirement. We can't afford to have a separate solution >> for >> each variation. >> 2. Multiple timers LSA Interval timers (which I assume you >> use >> to advertise if any interval is satisfied) would add >> undue >> complexity and overhead. >> 3. While we have Not-So-Stubby Areas I don't think we want >> Not-So-Opaque LSAs. If the contents of the LSAs are truly >> opaque they should not have ramifications on the base >> flooding algorithm. >> >> Thanks, >> Acee >> >> >>> >>> I read there was proposals in the past to reduce or ignore >>> MinLSInterval, but i agree with the important presence of >>> MinLSInterval; >>> i only think to a separate management. >>> >>> Was this proposals (or drafts ) specific to my consideration and >>> did they refer >>> to the only Opaque administrative field? >>> >>> Thanks in advance for your answers and kindness. >>> >>> Giovanni >>> Coritel - Rome >>> >> >> >> -- >> Acee > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Sun Apr 20 15:17:58 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12872 for ; Sun, 20 Apr 2003 15:17:58 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00986E38@cherry.ease.lsoft.com>; 20 Apr 2003 15:20:38 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 681581 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 20 Apr 2003 15:20:38 -0400 Received: from 216.136.131.42 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 20 Apr 2003 15:20:38 -0400 Received: from [209.179.252.234] by web10906.mail.yahoo.com via HTTP; Sun, 20 Apr 2003 12:20:37 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20030420192037.84909.qmail@web10906.mail.yahoo.com> Date: Sun, 20 Apr 2003 12:20:37 -0700 Reply-To: Mailing List Sender: Mailing List From: j j Subject: Multiple Ethernet interfaces on same subnet To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list is this allowed on routers? for e.g. can I configure router with eth0 10.1.1.1/24 and eth1 as 10.1.1.2/24? thanks, __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Sun Apr 20 19:53:03 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19204 for ; Sun, 20 Apr 2003 19:53:02 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.009873C9@cherry.ease.lsoft.com>; 20 Apr 2003 19:55:44 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 681942 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 20 Apr 2003 19:55:43 -0400 Received: from 192.128.134.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 20 Apr 2003 19:55:43 -0400 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id h3KNmHLM023654 for ; Sun, 20 Apr 2003 18:55:42 -0500 (CDT) Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.89) by attrh5i.attrh.att.com (6.5.032) id 3E7A3143010209DE for OSPF@DISCUSS.MICROSOFT.COM; Sun, 20 Apr 2003 19:55:42 -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: draft - ospf-scalability-03.txt Thread-Index: AcMF+ud+aX1QpclSQyqzIbFDgiBTjwBnQ8CA Message-ID: <73656AE8EE4C9C4D9FFF9DBFEAE9A00F09E8CF@KCCLUST06EVS1.ugd.att.com> Date: Sun, 20 Apr 2003 18:55:30 -0500 Reply-To: Mailing List Sender: Mailing List From: "Choudhury, Gagan L, ALABS" Subject: Re: draft - ospf-scalability-03.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA19204 Hi Mitchell, Your comment is regarding Recommendation 2 in the draft and the benefit of this recommendation is that during a period of congestion it does not declare a adjacency to be down due to excessively delayed Hello packets as long as other OSPF packets are received over it. However, Recommendation 1 of the draft (prioritizing Hello) also does the same job. Based on comments on the list, in the next version we will point out that Recommendation 2 is not to be implemented if Recommendation 1 is already being implemented. Hopefully this will satisfy your concern. Now in case Recommendation 1 is not implemented then we do propose Recommendation 2. We feel that in that case the benefit of not declaring an adjacency down due to delayed Hellos during periods of congestion outweighs the extra overhead of more frequent resetting of Inactivity timer. Please also see the comment from Vivek Dube which seem to support this position. Thanks to yourself, Vivek and others for the comments which are improving the quality of the draft. With regards, Gagan Choudhury -----Original Message----- From: Erblichs [mailto:erblichs@EARTHLINK.NET] Sent: Friday, April 18, 2003 6:36 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: draft - ospf-scalability-03.txt Group, Ignoring the reasons for possibly implimenting the below feature... As a past contributor to an ARC (architecture review committee), a frequent question was, is that proposal downward scalable? I question whether implimentating, the ability for every OSPF packet over an adj to reset the Inactivity timer could cause more harm than good. Given a 50k LSDB, with a normal amount of flooding is isn't unlikely that we would see about 100k worth of update pkts per hr. Would 100k per hr of inactivity timer resets cause harm in routers? Does anybody else have a concern, that this type of item should be explicitly stated within the doc? With each 10 sec hello interval, I would expect to see 360 resets per nbr of the Inactivity timers. Mitchell Erblich Sr Software Engineer ------------------------------- "Manral, Vishwas" wrote: > > Hi Vivek, > > This has been updated in version 4 of the draft, which has recently been > completed. The current text reads: - > > " reset the Inactivity Timer for an adjacency whenever any OSPF > packet is received over that adjacency " > > Thanks, > Vishwas > > -----Original Message----- > From: Vivek Dubey [mailto:vivek_ospf@REDIFFMAIL.COM] > Sent: Wednesday, April 16, 2003 10:33 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: draft - ospf-scalability-03.txt > > Hi, > Section 2: > 2) Reset the Inactivity Timer for an interface whenever any OSPF > packet is received over that interface (currently this is done > only > for the Hello packet). > So OSPF would declare the interface to be down only if no > OSPF packet is received over that interface for a period > equaling or exceeding the RouterDeadInterval. > > Here what the paragraph implies seems little unclear. > a) Inactivity timer are neighbor specific, so > why should the one for interface be restarted ? > b) Why should Ospf interface be made down if no packets > are received on it ? > c) Probably it should be something like this: > "Reset the inactivity timer for a Neighbor whenever any > Ospf packet is received from that neighbor" > > Or i missed the point the draft tries to make ???? > > vivek From owner-ospf@DISCUSS.MICROSOFT.COM Sun Apr 20 20:42:40 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20016 for ; Sun, 20 Apr 2003 20:42:40 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.009874FE@cherry.ease.lsoft.com>; 20 Apr 2003 20:45:23 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 681983 for OSPF@DISCUSS.MICROSOFT.COM; Sun, 20 Apr 2003 20:45:22 -0400 Received: from 216.136.131.44 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 20 Apr 2003 20:45:22 -0400 Received: from [209.179.211.20] by web10908.mail.yahoo.com via HTTP; Sun, 20 Apr 2003 17:45:22 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20030421004522.65579.qmail@web10908.mail.yahoo.com> Date: Sun, 20 Apr 2003 17:45:22 -0700 Reply-To: Mailing List Sender: Mailing List From: j j Subject: Re: Multiple Ethernet interfaces on same subnet To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <20030420192037.84909.qmail@web10906.mail.yahoo.com> Precedence: list Well, the reason for me asking the question is this -- Rfc2328 section 16.1.1 says following: "In the second case, the parent vertex is a network that directly connects the calculating router to the destination router. The list of next hops is then determined by examining the destination's router-LSA. FOR EACH LINK IN THE ROUTER-LSA THAT POINTS BACK TO THE PARENT NETWORK, the link's Link Data field provides the IP address of a next hop router." If I understand this properly, there can be multiple links in the router lsa that can point back to parent network only if the router has multiple interfaces on the same subnet. Am I missing something? thanks, --- j j wrote: > is this allowed on routers? > > for e.g. can I configure router with eth0 > 10.1.1.1/24 > and eth1 as 10.1.1.2/24? > > thanks, > > > __________________________________________________ > Do you Yahoo!? > The New Yahoo! Search - Faster. Easier. Bingo > http://search.yahoo.com __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com From owner-ospf*ospf-archive**LISTS*-IETF*-ORG@DISCUSS.MICROSOFT.COM Mon Apr 21 00:37:27 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23161 for ; Mon, 21 Apr 2003 00:37:27 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00987A93@cherry.ease.lsoft.com>; Mon, 21 Apr 2003 0:40:09 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 682324 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 21 Apr 2003 00:40:08 -0400 Received: from 203.199.83.32 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 21 Apr 2003 00:40:08 -0400 Received: (qmail 10075 invoked by uid 510); 21 Apr 2003 04:45:45 -0000 Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 21 apr 2003 04:45:45 -0000 MIME-Version: 1.0 Content-type: text/plain; format=flowed Content-Disposition: inline Message-ID: <20030421044545.10072.qmail@webmail32.rediffmail.com> Date: Mon, 21 Apr 2003 04:45:45 -0000 Reply-To: Mailing List Sender: Mailing List From: Vivek Dubey Subject: Re: Multiple Ethernet interfaces on same subnet To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Hi, Check RFC 2328: Appendix ----------- F. Multiple interfaces to the same network/subnet vivek On Mon, 21 Apr 2003 j j wrote : >is this allowed on routers? > >for e.g. can I configure router with eth0 10.1.1.1/24 >and eth1 as 10.1.1.2/24? > >thanks, > > >__________________________________________________ >Do you Yahoo!? >The New Yahoo! Search - Faster. Easier. Bingo >http://search.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Mon Apr 21 07:42:15 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10272 for ; Mon, 21 Apr 2003 07:42:15 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00988506@cherry.ease.lsoft.com>; Mon, 21 Apr 2003 7:44:57 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 683058 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 21 Apr 2003 07:44:56 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 21 Apr 2003 07:34:54 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09850; Mon, 21 Apr 2003 07:32:09 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200304211132.HAA09850@ietf.org> Date: Mon, 21 Apr 2003 07:32:09 -0400 Reply-To: Mailing List Sender: Mailing List Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-ospfv3-auth-01.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Authentication/Confidentiality for OSPFv3 Author(s) : M. Gupta, N. Melam Filename : draft-ietf-ospf-ospfv3-auth-01.txt Pages : 7 Date : 2003-4-18 This document describes means/mechanisms to provide authentication/confidentiality to OSPFv3 using IPv6 AH/ESP Extension Header. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-ospfv3-auth-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-ospfv3-auth-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-18131844.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-ospfv3-auth-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-ospfv3-auth-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-18131844.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@DISCUSS.MICROSOFT.COM Mon Apr 21 11:21:21 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19480 for ; Mon, 21 Apr 2003 11:21:20 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.009888CD@cherry.ease.lsoft.com>; Mon, 21 Apr 2003 11:24:02 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 683453 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 21 Apr 2003 11:24:01 -0400 Received: from 63.78.179.217 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 21 Apr 2003 11:24:01 -0400 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3LFNwb20789 for ; Mon, 21 Apr 2003 10:23:59 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 21 Apr 2003 10:23:56 -0500 Received: from daebe009.NOE.Nokia.com ([172.18.242.190]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 21 Apr 2003 08:23:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: I-D ACTION:draft-ietf-ospf-ospfv3-auth-01.txt Thread-Index: AcMIAJNsdu5vN+8BRZmI1A9xKjjFHQAGTjFw X-OriginalArrivalTime: 21 Apr 2003 15:23:26.0693 (UTC) FILETIME=[F4922950:01C30819] Message-ID: <8D260779A766FB4A9C1739A476F84FA42AC582@daebe009.americas.nokia.com> Date: Mon, 21 Apr 2003 10:23:26 -0500 Reply-To: Mailing List Sender: Mailing List From: Mukesh Gupta Subject: Re: I-D ACTION:draft-ietf-ospf-ospfv3-auth-01.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA19480 The changes to the draft: - Section 5 points to the RFCs instead of dictating the mandatory algorithms - Corrected link local address mask to 10 from 16 in section 9. - Details about what interfaces rules for virtual links should be installed on. - Mandate using first prefix with "LA-bit" set from the intra-area-prefix-LSAs, as the source address of the packets exchanged over the virtual links. regards Mukesh > -----Original Message----- > From: ext Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Monday, April 21, 2003 4:32 AM > Cc: ospf@discuss.microsoft.com > Subject: I-D ACTION:draft-ietf-ospf-ospfv3-auth-01.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Open Shortest Path First IGP > Working Group of the IETF. > > Title : Authentication/Confidentiality for OSPFv3 > Author(s) : M. Gupta, N. Melam > Filename : draft-ietf-ospf-ospfv3-auth-01.txt > Pages : 7 > Date : 2003-4-18 > > This document describes means/mechanisms to provide > authentication/confidentiality to OSPFv3 using IPv6 AH/ESP Extension > Header. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-01.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body > of the message. > > Internet-Drafts are also available by anonymous FTP. Login > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ospf-ospfv3-auth-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ospf-ospfv3-auth-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From owner-ospf@DISCUSS.MICROSOFT.COM Mon Apr 21 14:01:37 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24468 for ; Mon, 21 Apr 2003 14:01:36 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.0098908E@cherry.ease.lsoft.com>; Mon, 21 Apr 2003 14:04:17 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 683828 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 21 Apr 2003 14:04:17 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 21 Apr 2003 13:54:17 -0400 Received: from redback.com (montreal.redback.com [155.53.34.71]) by prattle.redback.com (Postfix) with ESMTP id 634DA9ADA04 for ; Mon, 21 Apr 2003 10:54:16 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.1) Gecko/20020829 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030421004522.65579.qmail@web10908.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3EA43047.6030003@redback.com> Date: Mon, 21 Apr 2003 10:54:15 -0700 Reply-To: Mailing List Sender: Mailing List From: Rikki Nguyen Subject: Re: Multiple Ethernet interfaces on same subnet To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Not necessarily. Two routers could have multiple P2P interfaces between them. That would force them to have different subnets or none at all. j j wrote: > Well, the reason for me asking the question is this -- > > Rfc2328 section 16.1.1 says following: > > "In the second case, the parent vertex is a network > that directly connects the calculating router to the > destination router. The list of next hops is then > determined by examining the destination's router-LSA. > FOR EACH LINK IN THE ROUTER-LSA THAT POINTS BACK TO > THE PARENT NETWORK, the link's Link Data field > provides the IP address of a next hop router." > > If I understand this properly, there can be multiple > links in the router lsa that can point back to parent > network only if the router has multiple interfaces on > the same subnet. > > Am I missing something? > > thanks, > > > > > > > > > > --- j j wrote: > >>is this allowed on routers? >> >>for e.g. can I configure router with eth0 >>10.1.1.1/24 >>and eth1 as 10.1.1.2/24? >> >>thanks, >> >> >>__________________________________________________ >>Do you Yahoo!? >>The New Yahoo! Search - Faster. Easier. Bingo >>http://search.yahoo.com > > > > __________________________________________________ > Do you Yahoo!? > The New Yahoo! Search - Faster. Easier. Bingo > http://search.yahoo.com > From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 23 01:55:50 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08775 for ; Wed, 23 Apr 2003 01:55:50 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.0098D0D7@cherry.ease.lsoft.com>; Wed, 23 Apr 2003 1:58:25 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 667936 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 23 Apr 2003 01:58:25 -0400 Received: from 216.136.131.42 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 23 Apr 2003 01:58:25 -0400 Received: from [209.179.212.111] by web10906.mail.yahoo.com via HTTP; Tue, 22 Apr 2003 22:58:24 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20030423055824.92641.qmail@web10906.mail.yahoo.com> Date: Tue, 22 Apr 2003 22:58:24 -0700 Reply-To: Mailing List Sender: Mailing List From: j j Subject: Re: Multiple Ethernet interfaces on same subnet To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: <3EA43047.6030003@redback.com> Precedence: list Why would P2P links point to network LSA? Please read the question carefully. The parent vertex is a network (i.e. network LSA). thanks --- Rikki Nguyen wrote: > Not necessarily. Two routers could have multiple > P2P > interfaces between them. That would force them to > have different subnets or none at all. > > j j wrote: > > Well, the reason for me asking the question is > this -- > > > > Rfc2328 section 16.1.1 says following: > > > > "In the second case, the parent vertex is a > network > > that directly connects the calculating router to > the > > destination router. The list of next hops is then > > determined by examining the destination's > router-LSA. > > FOR EACH LINK IN THE ROUTER-LSA THAT POINTS BACK > TO > > THE PARENT NETWORK, the link's Link Data field > > provides the IP address of a next hop router." > > > > If I understand this properly, there can be > multiple > > links in the router lsa that can point back to > parent > > network only if the router has multiple interfaces > on > > the same subnet. > > > > Am I missing something? > > > > thanks, > > > > > > > > > > > > > > > > > > > > --- j j wrote: > > > >>is this allowed on routers? > >> > >>for e.g. can I configure router with eth0 > >>10.1.1.1/24 > >>and eth1 as 10.1.1.2/24? > >> > >>thanks, > >> > >> > >>__________________________________________________ > >>Do you Yahoo!? > >>The New Yahoo! Search - Faster. Easier. Bingo > >>http://search.yahoo.com > > > > > > > > __________________________________________________ > > Do you Yahoo!? > > The New Yahoo! Search - Faster. Easier. Bingo > > http://search.yahoo.com > > __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 23 10:52:47 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21721 for ; Wed, 23 Apr 2003 10:52:47 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.0098E185@cherry.ease.lsoft.com>; Wed, 23 Apr 2003 10:55:31 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 669270 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 23 Apr 2003 10:55:31 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 23 Apr 2003 10:55:31 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 00A335DE8D5 for ; Wed, 23 Apr 2003 07:55:30 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3EA6A934.1050904@redback.com> Date: Wed, 23 Apr 2003 10:54:44 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Working Group Last Call for draft-ietf-ospf-mib-update-06.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit This is the start of a Working Group last call for draft-ietf-ospf-mib-update-06.txt, OSPF Version 2 Management Information Base. All comments must be received by Wednesday, May 7th, 2003. This document reached the AD review phase once before but we decided to add MIB support for recent OSPF extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-mib-update-06.txt -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 23 14:28:08 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29404 for ; Wed, 23 Apr 2003 14: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 <8.0098E72B@cherry.ease.lsoft.com>; Wed, 23 Apr 2003 14:30:50 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 669812 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 23 Apr 2003 14:30:49 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 23 Apr 2003 14:30:49 -0400 Received: from redback.com (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 5CF0D901585 for ; Wed, 23 Apr 2003 11:30:48 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <3EA6A934.1050904@redback.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3EA6DBA8.8000509@redback.com> Date: Wed, 23 Apr 2003 14:30:00 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Working Group Last Call for draft-ietf-ospf-mib-update-06.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit We've decided do another revision of this draft prior to WG last call. If you forward comments quickly (I don't have an exact date), they can be incorporated into the next revision. Thanks, Acee Acee Lindem wrote: > This is the start of a Working Group last call for > draft-ietf-ospf-mib-update-06.txt, OSPF Version 2 Management > Information Base. All comments must be received by Wednesday, > May 7th, 2003. > > This document reached the AD review phase once before but > we decided to add MIB support for recent OSPF extensions. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ospf-mib-update-06.txt -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 23 16:52:01 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06590 for ; Wed, 23 Apr 2003 16:52:00 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.0098EC97@cherry.ease.lsoft.com>; Wed, 23 Apr 2003 16:54:44 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 670115 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 23 Apr 2003 16:54:44 -0400 Received: from 207.217.120.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 23 Apr 2003 16:54:43 -0400 Received: from user-38ldsni.dialup.mindspring.com ([209.86.242.242] helo=earthlink.net) by conure.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 198RGL-00038w-00 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 23 Apr 2003 13:54:42 -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: <3EA6A934.1050904@redback.com> <3EA6DBA8.8000509@redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3EA6FD97.F72A727B@earthlink.net> Date: Wed, 23 Apr 2003 13:54:47 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Working Group Last Call for draft-ietf-ospf-mib-update-06.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Acee, After a quick look here are a few possible changes/additions for you and your group... 1) No "Wait timer" with the other timers in 1.6 Default configuration. 1b) Don't see a ospfIfWaitinterval object.. Yes, the value is RouterDeadInterval by default and it applies only to BMA. 2) Associated with ospfExternLsaChksumSum Why don't you support a query of the number of ChkSum failures within the LSDB since bootup? 3) Query of Overflow state. Current and past. Past tells you whether you have ever entered the OverflowState due to exceeding the ospfExtLsdbLimit.. I am only seiing OverlowInterval... 4) Query on CongestionState. Current and past. This I know is a stretch! 5) Ability to Reset counters ((ospRxNewLsas, ospfSpfRuns, et) ATOMICLY.. These would be reset to 0. Yes, in effect it does change the state to READ-WRITE from READ-ONLY. Mitchell Erblich Sr Software Engineer ========================== Acee Lindem wrote: > > We've decided do another revision of this draft prior to WG > last call. If you forward comments quickly (I don't have an > exact date), they can be incorporated into the next revision. > > Thanks, > Acee > > Acee Lindem wrote: > > This is the start of a Working Group last call for > > draft-ietf-ospf-mib-update-06.txt, OSPF Version 2 Management > > Information Base. All comments must be received by Wednesday, > > May 7th, 2003. > > > > This document reached the AD review phase once before but > > we decided to add MIB support for recent OSPF extensions. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-ospf-mib-update-06.txt > > -- > Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 23 18:38:35 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12206 for ; Wed, 23 Apr 2003 18:38:35 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.0098F5FD@cherry.ease.lsoft.com>; Wed, 23 Apr 2003 18:41:18 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 670491 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 23 Apr 2003 18:41:18 -0400 Received: from 203.14.180.204 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 23 Apr 2003 18:31:18 -0400 Received: (qmail 24222 invoked from network); 23 Apr 2003 22:55:42 -0000 Received: from mailmon2.aapt.com.au (172.19.200.193) by 0 with SMTP; 23 Apr 2003 22:55:42 -0000 Received: from QMAIL-Message_Server by aapt-gwia2.aapt.com.au with Novell_GroupWise; Thu, 24 Apr 2003 08:31:12 +1000 X-Mailer: Novell GroupWise 5.5.4 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Message-ID: Date: Thu, 24 Apr 2003 08:31:04 +1000 Reply-To: Mailing List Sender: Mailing List From: Paresh Khatri Subject: Neighbor state change To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA12206 Hi, From reading rfc2328, it would appear that it is possible for a neighbor in a 'Down' state to receive a '2-Way Received' event. However, the state diagram (Figure 12) does not include this possibility and there is no explicit mention of that anywhere else. Am I reading this wrong or is it really possible ? TIA, Paresh Khatri. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 23 18:56:55 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12845 for ; Wed, 23 Apr 2003 18:56:54 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.0098F703@cherry.ease.lsoft.com>; Wed, 23 Apr 2003 18:59:37 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 670551 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 23 Apr 2003 18:59:37 -0400 Received: from 12.145.55.23 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 23 Apr 2003 18:49:37 -0400 Received: from wtn10068.opnet.com (wtn10068.opnet.com [172.16.10.68]) by mailserver1.opnet.com (8.12.9/8.12.8) with ESMTP id h3NMnau5007514 for ; Wed, 23 Apr 2003 18:49:36 -0400 (EDT) X-Sender: azalani@mailserver.opnet.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-MailScanner: Not scanned: Message-ID: <5.1.0.14.2.20030423184725.020a2550@mailserver.opnet.com> Date: Wed, 23 Apr 2003 18:49:36 -0400 Reply-To: Mailing List Sender: Mailing List From: Ashish Zalani Subject: Re: Neighbor state change To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Paresh, > >From reading rfc2328, it would appear that it is possible for a neighbor > in a 'Down' state to receive a '2-Way Received' event. However, the > state diagram (Figure 12) does not include this possibility and there is > no explicit mention of that anywhere else. > >Am I reading this wrong or is it really possible ? I do not believe "2-Way Received" is a valid event for a neighbor in "Down" state. The only valid events in the "Down" state are "Start" or "Hello Received". Hope this helps. -Ashish. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 23 19:13:07 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13732 for ; Wed, 23 Apr 2003 19:13:07 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.0098F735@cherry.ease.lsoft.com>; Wed, 23 Apr 2003 19:15:50 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 670609 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 23 Apr 2003 19:15:50 -0400 Received: from 203.14.180.204 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 23 Apr 2003 19:15:49 -0400 Received: (qmail 26278 invoked from network); 23 Apr 2003 23:40:17 -0000 Received: from mailmon2.aapt.com.au (172.19.200.193) by 0 with SMTP; 23 Apr 2003 23:40:17 -0000 Received: from QMAIL-Message_Server by aapt-gwia2.aapt.com.au with Novell_GroupWise; Thu, 24 Apr 2003 09:15:47 +1000 X-Mailer: Novell GroupWise 5.5.4 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Message-ID: Date: Thu, 24 Apr 2003 09:15:39 +1000 Reply-To: Mailing List Sender: Mailing List From: Paresh Khatri Subject: Re: Neighbor state change To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA13732 Thanks Ashish, Say you have this scenario. You have two routers, RT1 and RT2 on a broadcast network. RT1 comes online first and sends out a Hello packet that is received by RT2. Having seen the hello from RT1, RT2 transitions to Init. Since it is now in Init, it sends out a Hello packet which includes RT1 in its list of neighbors seen. Rt1 (which is still in a Down state), receives the hello and interprets its as '2-Way Received', since it can see itself in the list of neighbors in the hello packet. Therefore, a router in a 'Down' state has received a '2-Way Received' event. Is this then possible ? This example is a subset of the example given in Section 10.10 of rfc2328... +---+ +---+ |RT1| |RT2| +---+ +---+ Down Down Hello(DR=0,seen=0) ------------------------------> Hello (DR=RT2,seen=RT1,...) Init <------------------------------ Regards, Paresh. >>> azalani@OPNET.COM 04/24/03 08:49AM >>> Paresh, > >From reading rfc2328, it would appear that it is possible for a neighbor > in a 'Down' state to receive a '2-Way Received' event. However, the > state diagram (Figure 12) does not include this possibility and there is > no explicit mention of that anywhere else. > >Am I reading this wrong or is it really possible ? I do not believe "2-Way Received" is a valid event for a neighbor in "Down" state. The only valid events in the "Down" state are "Start" or "Hello Received". Hope this helps. -Ashish. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 23 19:33:26 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14324 for ; Wed, 23 Apr 2003 19:33: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.0098F7B3@cherry.ease.lsoft.com>; Wed, 23 Apr 2003 19:36:10 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 670645 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 23 Apr 2003 19:36:09 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 23 Apr 2003 19:36:09 -0400 Received: from redback.com (montreal.redback.com [155.53.34.71]) by prattle.redback.com (Postfix) with ESMTP id 3E210292C37 for ; Wed, 23 Apr 2003 16:36:08 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.1) Gecko/20020829 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3EA72368.4010201@redback.com> Date: Wed, 23 Apr 2003 16:36:08 -0700 Reply-To: Mailing List Sender: Mailing List From: Rikki Nguyen Subject: Re: Neighbor state change To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit The reason why you can't have a 2-Way Received event in Down state is because you have to receive a hello packet first to consider it a 2-Way Received. Having received the hello packet, a Hello Received event is generated which transitions the neighbor from Down state to Init state. Then upon examining the packet, you'll generate a 2-Way Received event for the neighbor, who is now in Init state. Paresh Khatri wrote: > Thanks Ashish, > > Say you have this scenario. You have two routers, RT1 and RT2 on a broadcast network. RT1 comes online first and sends out a Hello packet that is received by RT2. Having seen the hello from RT1, RT2 transitions to Init. Since it is now in Init, it sends out a Hello packet which includes RT1 in its list of neighbors seen. Rt1 (which is still in a Down state), receives the hello and interprets its as '2-Way Received', since it can see itself in the list of neighbors in the hello packet. Therefore, a router in a 'Down' state has received a '2-Way Received' event. Is this then possible ? This example is a subset of the example given in Section 10.10 of rfc2328... > > +---+ +---+ > |RT1| |RT2| > +---+ +---+ > > Down Down > Hello(DR=0,seen=0) > ------------------------------> > Hello (DR=RT2,seen=RT1,...) Init > <------------------------------ > > Regards, > Paresh. > > > > >>>>azalani@OPNET.COM 04/24/03 08:49AM >>> >>> > Paresh, > > >>>From reading rfc2328, it would appear that it is possible for a neighbor >>in a 'Down' state to receive a '2-Way Received' event. However, the >>state diagram (Figure 12) does not include this possibility and there is >>no explicit mention of that anywhere else. >> >>Am I reading this wrong or is it really possible ? > > > > I do not believe "2-Way Received" is a valid event for a neighbor in "Down" > state. The only valid events in the "Down" state are "Start" or "Hello > Received". > > Hope this helps. > > -Ashish. > From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 23 19:38:05 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14555 for ; Wed, 23 Apr 2003 19: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 <9.0098F70E@cherry.ease.lsoft.com>; Wed, 23 Apr 2003 19:40:48 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 670657 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 23 Apr 2003 19:40:48 -0400 Received: from 12.145.55.23 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 23 Apr 2003 19:40:47 -0400 Received: from wtn10068.opnet.com (wtn10068.opnet.com [172.16.10.68]) by mailserver1.opnet.com (8.12.9/8.12.8) with ESMTP id h3NNeeu5014871 for ; Wed, 23 Apr 2003 19:40:40 -0400 (EDT) X-Sender: azalani@mailserver.opnet.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-MailScanner: Not scanned: Message-ID: <5.1.0.14.2.20030423192552.0209d740@mailserver.opnet.com> Date: Wed, 23 Apr 2003 19:40:40 -0400 Reply-To: Mailing List Sender: Mailing List From: Ashish Zalani Subject: Re: Neighbor state change To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Paresh, >Say you have this scenario. You have two routers, RT1 and RT2 on a >broadcast network. RT1 comes online first and sends out a Hello packet >that is received by RT2. Having seen the hello from RT1, RT2 transitions >to Init. Since it is now in Init, it sends out a Hello packet which >includes RT1 in its list of neighbors seen. Rt1 (which is still in a Down >state), receives the hello and interprets its as '2-Way Received', since >it can see itself in the list of neighbors in the hello >packet. Therefore, a router in a 'Down' state has received a '2-Way >Received' event. Is this then possible ? This example is a subset of the >example given in Section 10.10 of rfc2328... > > +---+ +---+ > |RT1| |RT2| > +---+ +---+ > > Down Down > Hello(DR=0,seen=0) > ------------------------------> > Hello (DR=RT2,seen=RT1,...) Init > <------------------------------ First two bullet points on page 98 (section 10.5 - Receiving Hello Packets): > o Each Hello Packet causes the neighbor state machine to be > executed with the event HelloReceived. > > o Then the list of neighbors contained in the Hello Packet is > examined. If the router itself appears in this list, the > neighbor state machine should be executed with the event 2- > WayReceived. Otherwise, the neighbor state machine should > be executed with the event 1-WayReceived, and the processing > of the packet stops. The first point will cause the HelloReceived event, causing the neighbor FSM to transition from Down to Init. The second point will cause the 2-WayReceived event but the neighbor FSM has already transitioned to Init. The 2-WayReceived is a valid event for the Init state. Further actions will be as described in section 10.3. Hope this helps. -Ashish. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 23 19:41:41 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14757 for ; Wed, 23 Apr 2003 19:41:41 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.0098F81E@cherry.ease.lsoft.com>; Wed, 23 Apr 2003 19:44:24 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 670678 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 23 Apr 2003 19:44:24 -0400 Received: from 203.14.180.204 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 23 Apr 2003 19:44:24 -0400 Received: (qmail 28139 invoked from network); 24 Apr 2003 00:08:50 -0000 Received: from mailmon2.aapt.com.au (172.19.200.193) by 0 with SMTP; 24 Apr 2003 00:08:50 -0000 Received: from QMAIL-Message_Server by aapt-gwia2.aapt.com.au with Novell_GroupWise; Thu, 24 Apr 2003 09:44:20 +1000 X-Mailer: Novell GroupWise 5.5.4 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Message-ID: Date: Thu, 24 Apr 2003 09:44:17 +1000 Reply-To: Mailing List Sender: Mailing List From: Paresh Khatri Subject: Re: Neighbor state change To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA14757 Thanks guys, I finally understand !! Regards, Paresh. >>> azalani@OPNET.COM 04/24/03 09:40AM >>> Paresh, >Say you have this scenario. You have two routers, RT1 and RT2 on a >broadcast network. RT1 comes online first and sends out a Hello packet >that is received by RT2. Having seen the hello from RT1, RT2 transitions >to Init. Since it is now in Init, it sends out a Hello packet which >includes RT1 in its list of neighbors seen. Rt1 (which is still in a Down >state), receives the hello and interprets its as '2-Way Received', since >it can see itself in the list of neighbors in the hello >packet. Therefore, a router in a 'Down' state has received a '2-Way >Received' event. Is this then possible ? This example is a subset of the >example given in Section 10.10 of rfc2328... > > +---+ +---+ > |RT1| |RT2| > +---+ +---+ > > Down Down > Hello(DR=0,seen=0) > ------------------------------> > Hello (DR=RT2,seen=RT1,...) Init > <------------------------------ First two bullet points on page 98 (section 10.5 - Receiving Hello Packets): > o Each Hello Packet causes the neighbor state machine to be > executed with the event HelloReceived. > > o Then the list of neighbors contained in the Hello Packet is > examined. If the router itself appears in this list, the > neighbor state machine should be executed with the event 2- > WayReceived. Otherwise, the neighbor state machine should > be executed with the event 1-WayReceived, and the processing > of the packet stops. The first point will cause the HelloReceived event, causing the neighbor FSM to transition from Down to Init. The second point will cause the 2-WayReceived event but the neighbor FSM has already transitioned to Init. The 2-WayReceived is a valid event for the Init state. Further actions will be as described in section 10.3. Hope this helps. -Ashish. From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 24 08:38:49 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14591 for ; Thu, 24 Apr 2003 08:38:48 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00990B76@cherry.ease.lsoft.com>; Thu, 24 Apr 2003 8:41:32 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 672664 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 24 Apr 2003 08:41:32 -0400 Received: from 216.136.131.40 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 24 Apr 2003 08:41:31 -0400 Received: from [192.100.124.219] by web10904.mail.yahoo.com via HTTP; Thu, 24 Apr 2003 13:41:31 BST MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-295941354-1051188091=:45295" Content-Transfer-Encoding: 8bit Message-ID: <20030424124131.46085.qmail@web10904.mail.yahoo.com> Date: Thu, 24 Apr 2003 13:41:31 +0100 Reply-To: Mailing List Sender: Mailing List From: =?iso-8859-1?q?df=20klsd?= Subject: A mistake of RFC 2328 (in chapter 13 OSPF flooding, step 4) ? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list --0-295941354-1051188091=:45295 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi. I have an issue to be clarified on the flooding LSA (§ 13 of RFC 2328). I am expecting somebody give me some answer for this issue. Considering router-A sending LSA with MaxAge to router-B for flushing an instance x. However, the instance x of the LSA is not existing in the router B. What the router B will do? According to RFC 2328, §13, step (4): If "none of router's neighbours are in states Exchange or Loading, then take the following actions: a) Acknowledge the receipt of the LSA by sending a Link State Acknowledgement packet back to the sending neighbour (see Section 13.5), and b) Discard the LSA and examine the next LSA (if any) listed in the Link State Update packet." If "one of router's neighbours is in states Exchange or Loading, According to RFC 2328, it shall proceed the step (5). After carefully checking the substep (a)-(f), I don't find any action is done by router B except for the substep (b). My questions are: 1. What is the point of flooding the non-existing instance with MaxAge? 2. the original sender router A will continually send the non-existing instance of the MaxAge LSA to router B because no ACK is received. However, RFC 2178 and previous version will not have such a problem. Why RFC 2328 was made such a change? Is a bug in the RFC 2328? The right action for the router B should be also done: 1. directly send ACK. 2. discarding the MaxAge LSA which has no corresponding instance in the database even though "one of router's neighbours is in states Exchange or Loading. Am I right? BR Shaoji Ni --------------------------------- Yahoo! Plus - For a better Internet experience --0-295941354-1051188091=:45295 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi.
 
I have an issue to be clarified on the flooding LSA (§ 13 of RFC 2328). I am expecting somebody give me some answer for this issue.
 
Considering router-A sending LSA with MaxAge to router-B for flushing an instance x. However, the instance x of the LSA is not existing in the router B. What the router B will do?
 
 According to RFC 2328, §13, step (4):
                             
If  "none of router's neighbours are in states Exchange or Loading, then take the following actions: a) Acknowledge the receipt of the LSA by sending a Link State Acknowledgement packet back to the sending neighbour (see Section 13.5), and b) Discard the LSA and examine the next LSA (if any) listed in the Link State Update packet."
 
If  "one of router's neighbours is in states Exchange or Loading, According to RFC 2328, it shall proceed the step (5).
 
After carefully checking the substep (a)-(f), I don't find any action is done by router B except for the substep (b). 
 
My questions are:
 
1. What is the point of flooding the non-existing instance with MaxAge?
2. the original sender router A will continually send the non-existing instance of the MaxAge LSA to router B because no ACK is received. 
However, RFC 2178 and previous version will not have such a problem. Why RFC 2328 was made such a change? Is a bug in the RFC 2328?
 
The right action for the router B should be also done: 1. directly send ACK. 2. discarding the MaxAge LSA which has no corresponding instance in the database even though "one of router's neighbours is in states Exchange or Loading. Am I right?
 
BR
 
Shaoji Ni

 


Yahoo! Plus - For a better Internet experience
--0-295941354-1051188091=:45295-- From owner-ospf@DISCUSS.MICROSOFT.COM Thu Apr 24 09:06:24 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15498 for ; Thu, 24 Apr 2003 09:06:23 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00990C81@cherry.ease.lsoft.com>; Thu, 24 Apr 2003 9:09:08 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 672713 for OSPF@DISCUSS.MICROSOFT.COM; Thu, 24 Apr 2003 09:09:07 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 24 Apr 2003 09:09:07 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 863B53E8DF7 for ; Thu, 24 Apr 2003 06:09:06 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030424124131.46085.qmail@web10904.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Message-ID: <3EA7E1B8.6050101@redback.com> Date: Thu, 24 Apr 2003 09:08:08 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: A mistake of RFC 2328 (in chapter 13 OSPF flooding, step 4) ? To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 8bit Hi Shaoji, Wasn't this discussed previously? Anyway, if router B has neighbors in exchange or loading state it should treat the non-existent MaxAge LSA as if it had an instance in its database. This implies that it will ack and flood the LSA. The reason for this action is to improve the robustness of the flooding algorithm in the event that router B was restarted prior to completing flooding of the MaxAge LSA (which would explain why it doesn't have an instance in its database). I agree that this may not be necessary since the a stale instance of the LSA should eventually make its way back to router A and be purged. Thanks, Acee df klsd wrote: > Hi. > > I have an issue to be clarified on the flooding LSA (§ 13 of RFC 2328). > I am expecting somebody give me some answer for this issue. > > Considering router-A sending LSA with MaxAge to router-B for flushing an > instance x. However, the instance x of the LSA is not existing in the > router B. What the router B will do? > > According to RFC 2328, §13, step (4): > > If "none of router's neighbours are in states Exchange or Loading, then > take the following actions: a) Acknowledge the receipt of the LSA by > sending a Link State Acknowledgement packet back to the sending > neighbour (see Section 13.5), and b) Discard the LSA and examine the > next LSA (if any) listed in the Link State Update packet." > > If "one of router's neighbours is in states Exchange or Loading, > According to RFC 2328, it shall proceed the step (5). > > After carefully checking the substep (a)-(f), I don't find any action is > done by router B except for the substep (b). > > My questions are: > > 1. What is the point of flooding the non-existing instance with MaxAge? > 2. the original sender router A will continually send the non-existing > instance of the MaxAge LSA to router B because no ACK is received. > However, RFC 2178 and previous version will not have such a problem. Why > RFC 2328 was made such a change? Is a bug in the RFC 2328? > > The right action for the router B should be also done: 1. directly send > ACK. 2. discarding the MaxAge LSA which has no corresponding instance in > the database even though "one of router's neighbours is in states > Exchange or Loading. Am I right? > > BR > > Shaoji Ni > > > > > ------------------------------------------------------------------------ > Yahoo! Plus - For a better Internet experience > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Mon Apr 28 18:46:41 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17898 for ; Mon, 28 Apr 2003 18:46:40 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.0099B21D@cherry.ease.lsoft.com>; Mon, 28 Apr 2003 18:49:27 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 686887 for OSPF@DISCUSS.MICROSOFT.COM; Mon, 28 Apr 2003 18:49:27 -0400 Received: from 207.159.120.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 28 Apr 2003 18:49:27 -0400 Received: by xmxpita.excite.com (Postfix, from userid 110) id 09A603DCE; Mon, 28 Apr 2003 18:49:24 -0400 (EDT) Received: from [64.47.48.10] by xprdmailfe6.nwk.excite.com via HTTP; Mon, 28 Apr 2003 18:49:24 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = ce00c10647f1b9e7db16a67db0936ee4 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: <20030428224924.09A603DCE@xmxpita.excite.com> Date: Mon, 28 Apr 2003 18:49:24 -0400 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: Working Group Last Call for draft-ietf-ospf-mib-update-06.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit All, From my review of the diff's file between these two revisions, I have one specific comment and two general comments. 1. (specific comment) At the end of page 17, the description for the new ospfStubRouterAdvertisement attribute needs to end with a double-quote. I see an o with an umlaut above it. 2. (general comment) In the description for all of the new restart objects and notifications, replace the text "hitless restart" with "graceful restart". This reflects the recent name change of that draft from Acee's last update (Graceful OSPF Restart). 3. (general comment) All in all, the objects, their definitions, etc., look well thought out and well-defined. In my last email on this MIB, I suggested including all the needed items to "complete" this MIB update per most common implementations and per the most recent drafts. I think we've met this goal. Thanks for moving this forward, Don Goodspeed --- On Wed 04/23, Acee Lindem < acee@REDBACK.COM > wrote: From: Acee Lindem [mailto: acee@REDBACK.COM] To: OSPF@DISCUSS.MICROSOFT.COM Date: Wed, 23 Apr 2003 14:30:00 -0400 Subject: Re: Working Group Last Call for draft-ietf-ospf-mib-update-06.txt We've decided do another revision of this draft prior to WG
last call. If you forward comments quickly (I don't have an
exact date), they can be incorporated into the next revision.

Thanks,
Acee

Acee Lindem wrote:
> This is the start of a Working Group last call for
> draft-ietf-ospf-mib-update-06.txt, OSPF Version 2 Management
> Information Base. All comments must be received by Wednesday,
> May 7th, 2003.
>
> This document reached the AD review phase once before but
> we decided to add MIB support for recent OSPF extensions.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ospf-mib-update-06.txt


--
Acee
_______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 29 09:55:16 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19499 for ; Tue, 29 Apr 2003 09:55:15 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.0099CA39@cherry.ease.lsoft.com>; Tue, 29 Apr 2003 9:58:03 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 688737 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 29 Apr 2003 09:58:03 -0400 Received: from 47.129.242.157 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 29 Apr 2003 09:58:03 -0400 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3TDw0729557 for ; Tue, 29 Apr 2003 09:58:01 -0400 (EDT) Received: by zbl6c012.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Apr 2003 09:58:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30E57.57DD0212" Message-ID: <6204FDDE129D364D8040A98BCCB290EF0440AC1B@zbl6c004.corpeast.baynetworks.com> Date: Tue, 29 Apr 2003 09:57:59 -0400 Reply-To: Mailing List Sender: Mailing List From: Daniel Joyal Subject: Re: Working Group Last Call for draft-ietf-ospf-mib-update-06.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C30E57.57DD0212 Content-Type: text/plain Version -06 of the OSPFv2 MIB update includes: - Add General group object for configuring reference bandwidth - Change General group object ospfOpaqueLsaSupport MAX-ACCESS from read-write to read-only - Deprecate ospfExtLsdbTable and add ospfAsLsdbTable - Add external route tag object to ospfAreaAggregateTable for NSSA (RFC 3101) - Change status of RFC 1850 compliance and conformance groups from "deprecated" to "current" - Add support for Graceful Restart Pending updates for version -07 - Configuration objects to support detection of inactive neighbors - Resolution of issues raised by IESG's OAM expert reviewer on version -05 - Remaining open issues on traps - Add section on MIB support for multiple OSPF instances - Fix smilint errors/warnings - Fix ospfStubRouterAdvertisement Description clause per Don's comment - Change "hitless restart" to "graceful restart" per Don's comment - Any additional issues from WG -Dan > -----Original Message----- > From: Don Goodspeed [mailto:dgoodspe@EXCITE.COM] > Sent: Monday, April 28, 2003 6:49 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: Working Group Last Call for > draft-ietf-ospf-mib-update-06.txt > > > All, > > From my review of the diff's file between these two > revisions, I have one specific comment and two general comments. > > 1. (specific comment) At the end of page 17, the description > for the new ospfStubRouterAdvertisement attribute needs to > end with a double-quote. I see an o with an umlaut above it. > > 2. (general comment) In the description for all of the new > restart objects and notifications, replace the text "hitless > restart" with "graceful restart". This reflects the recent > name change of that draft from Acee's last update (Graceful > OSPF Restart). > > 3. (general comment) All in all, the objects, their > definitions, etc., look well thought out and well-defined. > In my last email on this MIB, I suggested including all the > needed items to "complete" this MIB update per most common > implementations and per the most recent drafts. I think > we've met this goal. > > Thanks for moving this forward, > Don Goodspeed > > --- On Wed 04/23, Acee Lindem < acee@REDBACK.COM > wrote: > From: Acee Lindem [mailto: acee@REDBACK.COM] > To: OSPF@DISCUSS.MICROSOFT.COM > Date: Wed, 23 Apr 2003 14:30:00 -0400 > Subject: Re: Working Group Last Call for > draft-ietf-ospf-mib-update-06.txt > > We've decided do another revision of this draft prior to > WG
last call. If you forward comments quickly (I don't > have an
exact date), they can be incorporated into the > next revision.

Thanks,
Acee

Acee Lindem > wrote:
> This is the start of a Working Group last call > for
> draft-ietf-ospf-mib-update-06.txt, OSPF Version 2 > Management
> Information Base. All comments must be > received by Wednesday,
> May 7th, 2003.
>
> This > document reached the AD review phase once before but
> we > decided to add MIB support for recent OSPF > extensions.
>
>
> A URL for this Internet-Draft > is:
> http://www.ietf.org/internet-drafts/draft-ietf-ospf-mib-update-06.txt


--
Acee
_______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! ------_=_NextPart_001_01C30E57.57DD0212 Content-Type: text/html RE: Working Group Last Call for draft-ietf-ospf-mib-update-06.txt

Version -06 of the OSPFv2 MIB update includes:

- Add General group object for configuring reference bandwidth
- Change General group object ospfOpaqueLsaSupport MAX-ACCESS from read-write to read-only
- Deprecate ospfExtLsdbTable and add ospfAsLsdbTable
- Add external route tag object to ospfAreaAggregateTable for NSSA (RFC 3101)
- Change status of RFC 1850 compliance and conformance groups from "deprecated" to
  "current"
- Add support for Graceful Restart

Pending updates for version -07

- Configuration objects to support detection of inactive neighbors
- Resolution of issues raised by IESG's OAM expert reviewer on version -05
- Remaining open issues on traps
- Add section on MIB support for multiple OSPF instances
- Fix smilint errors/warnings
- Fix ospfStubRouterAdvertisement Description clause per Don's comment
- Change "hitless restart" to "graceful restart" per Don's comment
- Any additional issues from WG

-Dan

> -----Original Message-----
> From: Don Goodspeed [mailto:dgoodspe@EXCITE.COM]
> Sent: Monday, April 28, 2003 6:49 PM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Re: Working Group Last Call for
> draft-ietf-ospf-mib-update-06.txt
>
>
> All,
>
> From my review of the diff's file between these two
> revisions, I have one specific comment and two general comments.
>
> 1. (specific comment)  At the end of page 17, the description
> for the new ospfStubRouterAdvertisement attribute needs to
> end with a double-quote.  I see an o with an umlaut above it.
>
> 2. (general comment)  In the description for all of the new
> restart objects and notifications, replace the text "hitless
> restart" with "graceful restart".  This reflects the recent
> name change of that draft from Acee's last update (Graceful
> OSPF Restart).
>
> 3. (general comment)  All in all, the objects, their
> definitions, etc., look well thought out and well-defined. 
> In my last email on this MIB, I suggested including all the
> needed items to "complete" this MIB update per most common
> implementations and per the most recent drafts.  I think
> we've met this goal.
>
> Thanks for moving this forward,
> Don Goodspeed
>
> --- On Wed 04/23, Acee Lindem < acee@REDBACK.COM > wrote:
> From: Acee Lindem [mailto: acee@REDBACK.COM]
> To: OSPF@DISCUSS.MICROSOFT.COM
> Date: Wed, 23 Apr 2003 14:30:00 -0400
> Subject: Re: Working Group Last Call for
> draft-ietf-ospf-mib-update-06.txt
>
> We've decided do another revision of this draft prior to
> WG<br>last call. If you forward comments quickly (I don't
> have an<br>exact date), they can be incorporated into the
> next revision.<br><br>Thanks,<br>Acee<br><br>Acee Lindem
> wrote:<br>> This is the start of a Working Group last call
> for<br>> draft-ietf-ospf-mib-update-06.txt, OSPF Version 2
> Management<br>> Information Base. All comments must be
> received by Wednesday,<br>> May 7th, 2003.<br>><br>> This
> document reached the AD review phase once before but<br>> we
> decided to add MIB support for recent OSPF
> extensions.<br>><br>><br>> A URL for this Internet-Draft
> is:<br>>
http://www.ietf.org/internet-drafts/draft-ietf-ospf-mib-update-06.txt<br><br><br>--<br>Acee<br>

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

------_=_NextPart_001_01C30E57.57DD0212-- From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 29 17:38:43 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11988 for ; Tue, 29 Apr 2003 17:38:27 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0099DFC1@cherry.ease.lsoft.com>; Tue, 29 Apr 2003 17:41:17 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 690564 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 29 Apr 2003 17:41:16 -0400 Received: from 207.159.120.61 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 29 Apr 2003 17:41:16 -0400 Received: by xmxpita.excite.com (Postfix, from userid 110) id 6557C3D3A; Tue, 29 Apr 2003 17:41:15 -0400 (EDT) Received: from [64.47.48.10] by xprdmailfe10.nwk.excite.com via HTTP; Tue, 29 Apr 2003 17:41:15 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = ce00c10647f1b9e7db16a67db0936ee4 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: <20030429214115.6557C3D3A@xmxpita.excite.com> Date: Tue, 29 Apr 2003 17:41:15 -0400 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: Working Group Last Call for draft-ietf-ospf-mib-update-06.txt Comments: cc: djoyal@NORTELNETWORKS.COM To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Dan and all, Couple of things from my second review that I don't know if we want to address or not: 1. Configuration of a TE metric at the interface level (like ISIS). 2. Text regarding the issue that some SNMP agents may not be able to query the largest size of the ospfLsdbAdvertisement attribute. 3. Adding new error codes to ospfConfigErrorType: invalidLength (actual packet size did not match), duplicateRouterIdReceived. 4. Is it permitted (I can't remember) to add a single var-bind to a previously defined notification. If it is, can I suggest adding new attributes for ospfIfEventType and ospfNbrEventType to the IfStateChange and NbrStateChange traps? Thanks in advance, Don --- On Tue 04/29, Daniel Joyal < djoyal@NORTELNETWORKS.COM > wrote: From: Daniel Joyal [mailto: djoyal@NORTELNETWORKS.COM] To: OSPF@DISCUSS.MICROSOFT.COM Date: Tue, 29 Apr 2003 09:57:59 -0400 Subject: Re: Working Group Last Call for draft-ietf-ospf-mib-update-06.txt Version -06 of the OSPFv2 MIB update includes: - Add General group object for configuring reference bandwidth - Change General group object ospfOpaqueLsaSupport MAX-ACCESS from read-write to read-only - Deprecate ospfExtLsdbTable and add ospfAsLsdbTable - Add external route tag object to ospfAreaAggregateTable for NSSA (RFC 3101) - Change status of RFC 1850 compliance and conformance groups from "deprecated" to "current" - Add support for Graceful Restart Pending updates for version -07 - Configuration objects to support detection of inactive neighbors - Resolution of issues raised by IESG's OAM expert reviewer on version -05 - Remaining open issues on traps - Add section on MIB support for multiple OSPF instances - Fix smilint errors/warnings - Fix ospfStubRouterAdvertisement Description clause per Don's comment - Change "hitless restart" to "graceful restart" per Don's comment - Any additional issues from WG -Dan _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ospf@DISCUSS.MICROSOFT.COM Tue Apr 29 18:19:28 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14498 for ; Tue, 29 Apr 2003 18:19:27 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.0099E11C@cherry.ease.lsoft.com>; Tue, 29 Apr 2003 18:22:17 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 690745 for OSPF@DISCUSS.MICROSOFT.COM; Tue, 29 Apr 2003 18:22:17 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 29 Apr 2003 18:22:17 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id E61601D1174 for ; Tue, 29 Apr 2003 15:22:15 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030429214115.6557C3D3A@xmxpita.excite.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3EAEFA96.6020204@redback.com> Date: Tue, 29 Apr 2003 18:20:06 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Working Group Last Call for draft-ietf-ospf-mib-update-06.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Don, Some questions below: Don Goodspeed wrote: > Dan and all, > > Couple of things from my second review that I don't know if we > want to address or not: > 1. Configuration of a TE metric at the interface level (like ISIS). Do we really want this? It seems that if this were added, other TE stuff should be added as well. > 2. Text regarding the issue that some SNMP agents may not be > able to query the largest size of the ospfLsdbAdvertisement attribute. > 3. Adding new error codes to ospfConfigErrorType: invalidLength > (actual packet size did not match) What does this mean? That the OSPF packet length didn't match the IP packet length? I don't think we want people to check this since there is at least one extension that requires them not to match. > , duplicateRouterIdReceived. > 4. Is it permitted (I can't remember) to add a single var-bind > to a previously defined notification. If it is, can I suggest > adding new attributes for ospfIfEventType and ospfNbrEventType > to the IfStateChange and NbrStateChange traps? Thanks, Acee > > Thanks in advance, > Don > > --- On Tue 04/29, Daniel Joyal < djoyal@NORTELNETWORKS.COM > wrote: > From: Daniel Joyal [mailto: djoyal@NORTELNETWORKS.COM] > To: OSPF@DISCUSS.MICROSOFT.COM > Date: Tue, 29 Apr 2003 09:57:59 -0400 > Subject: Re: Working Group Last Call for draft-ietf-ospf-mib-update-06.txt > > Version -06 of the OSPFv2 MIB update includes: > > - Add General group object for configuring reference bandwidth > - Change General group object ospfOpaqueLsaSupport MAX-ACCESS from read-write to read-only > - Deprecate ospfExtLsdbTable and add ospfAsLsdbTable > - Add external route tag object to ospfAreaAggregateTable for NSSA (RFC 3101) > - Change status of RFC 1850 compliance and conformance groups from "deprecated" to > "current" > - Add support for Graceful Restart > > Pending updates for version -07 > > - Configuration objects to support detection of inactive neighbors > - Resolution of issues raised by IESG's OAM expert reviewer on version -05 > - Remaining open issues on traps > - Add section on MIB support for multiple OSPF instances > - Fix smilint errors/warnings > - Fix ospfStubRouterAdvertisement Description clause per Don's comment > - Change "hitless restart" to "graceful restart" per Don's comment > - Any additional issues from WG > > -Dan > > _______________________________________________ > Join Excite! - http://www.excite.com > The most personalized portal on the Web! > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 30 11:07:43 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08131 for ; Wed, 30 Apr 2003 11:07:39 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.009A03EA@cherry.ease.lsoft.com>; Wed, 30 Apr 2003 11:09:39 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 693658 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 30 Apr 2003 11:09:38 -0400 Received: from 47.129.242.157 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 30 Apr 2003 11:09:38 -0400 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3UF9VT13366 for ; Wed, 30 Apr 2003 11:09:32 -0400 (EDT) Received: by zbl6c012.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Apr 2003 11:09:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30F2A.7FE44418" Message-ID: <6204FDDE129D364D8040A98BCCB290EF0440AC26@zbl6c004.corpeast.baynetworks.com> Date: Wed, 30 Apr 2003 11:09:30 -0400 Reply-To: Mailing List Sender: Mailing List From: Daniel Joyal Subject: Re: Working Group Last Call for draft-ietf-ospf-mib-update-06.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C30F2A.7FE44418 Content-Type: text/plain > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Tuesday, April 29, 2003 6:20 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: Working Group Last Call for > draft-ietf-ospf-mib-update-06.txt > > > Hi Don, > > Some questions below: > > Don Goodspeed wrote: > > Dan and all, > > > > Couple of things from my second review that I don't know if > we want to > > address or not: 1. Configuration of a TE metric at the > interface level > > (like ISIS). > > Do we really want this? It seems that if this were added, > other TE stuff should be added as well. What other TE stuff would we need? > > > 2. Text regarding the issue that some SNMP agents may not > be able to > > query the largest size of the ospfLsdbAdvertisement attribute. I'll add some text. > 3. > > Adding new error codes to ospfConfigErrorType: > invalidLength (actual > > packet size did not match) > > What does this mean? That the OSPF packet length didn't match > the IP packet length? I don't think we want people to check > this since there is at least one extension that requires them > not to match. Do you mean cryptographic authentication? > > > , duplicateRouterIdReceived. I will add this. It was previously suggested. > > 4. Is it permitted (I can't remember) to add a single var-bind to a > > previously defined notification. If it is, can I suggest > adding new > > attributes for ospfIfEventType and ospfNbrEventType to the > > IfStateChange and NbrStateChange traps? I will check and add if allowed. -Dan > > Thanks, > Acee > > > > > Thanks in advance, > > Don > > > > --- On Tue 04/29, Daniel Joyal < djoyal@NORTELNETWORKS.COM > wrote: > > From: Daniel Joyal [mailto: djoyal@NORTELNETWORKS.COM] > > To: OSPF@DISCUSS.MICROSOFT.COM > > Date: Tue, 29 Apr 2003 09:57:59 -0400 > > Subject: Re: Working Group Last Call for > > draft-ietf-ospf-mib-update-06.txt > > > > Version -06 of the OSPFv2 MIB update includes: > > > > - Add General group object for configuring reference bandwidth > > - Change General group object ospfOpaqueLsaSupport MAX-ACCESS from > > read-write to read-only > > - Deprecate ospfExtLsdbTable and add ospfAsLsdbTable > > - Add external route tag object to ospfAreaAggregateTable > for NSSA (RFC 3101) > > - Change status of RFC 1850 compliance and conformance > groups from "deprecated" to > > "current" > > - Add support for Graceful Restart > > > > Pending updates for version -07 > > > > - Configuration objects to support detection of inactive neighbors > > - Resolution of issues raised by IESG's OAM expert reviewer > on version > > -05 > > - Remaining open issues on traps > > - Add section on MIB support for multiple OSPF instances > > - Fix smilint errors/warnings > > - Fix ospfStubRouterAdvertisement Description clause per > Don's comment > > - Change "hitless restart" to "graceful restart" per Don's comment > > - Any additional issues from WG > > > > -Dan > > > > _______________________________________________ > > Join Excite! - http://www.excite.com > > The most personalized portal on the Web! > > > > > -- > Acee > ------_=_NextPart_001_01C30F2A.7FE44418 Content-Type: text/html RE: Working Group Last Call for draft-ietf-ospf-mib-update-06.txt

> -----Original Message-----
> From: Acee Lindem [mailto:acee@REDBACK.COM]
> Sent: Tuesday, April 29, 2003 6:20 PM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Re: Working Group Last Call for
> draft-ietf-ospf-mib-update-06.txt
>
>
> Hi Don,
>
> Some questions below:
>
> Don Goodspeed wrote:
> > Dan and all,
> >
> > Couple of things from my second review that I don't know if
> we want to
> > address or not: 1. Configuration of a TE metric at the
> interface level
> > (like ISIS).
>
> Do we really want this? It seems that if this were added,
> other TE stuff should be added as well.

What other TE stuff would we need?

>
> > 2. Text regarding the issue that some SNMP agents may not
> be able to
> > query the largest size of the ospfLsdbAdvertisement attribute.

I'll add some text.

> 3.
> > Adding new error codes to ospfConfigErrorType:
> invalidLength (actual
> > packet size did not match)
>
> What does this mean? That the OSPF packet length didn't match
> the IP packet length? I don't think we want people to check
> this since there is at least one extension that requires them
> not to match.

Do you mean cryptographic authentication?

>
> > , duplicateRouterIdReceived.

I will add this. It was previously suggested.

> > 4. Is it permitted (I can't remember) to add a single var-bind to a
> > previously defined notification.  If it is, can I suggest
> adding new
> > attributes for ospfIfEventType and ospfNbrEventType to the
> > IfStateChange and NbrStateChange traps?

I will check and add if allowed.

-Dan
>
> Thanks,
> Acee
>
> >
> > Thanks in advance,
> > Don
> >
> >  --- On Tue 04/29, Daniel Joyal < djoyal@NORTELNETWORKS.COM > wrote:
> > From: Daniel Joyal [mailto: djoyal@NORTELNETWORKS.COM]
> > To: OSPF@DISCUSS.MICROSOFT.COM
> > Date: Tue, 29 Apr 2003 09:57:59 -0400
> > Subject: Re: Working Group Last Call for
> > draft-ietf-ospf-mib-update-06.txt
> >
> > Version -06 of the OSPFv2 MIB update includes:
> >
> > - Add General group object for configuring reference bandwidth
> > - Change General group object ospfOpaqueLsaSupport MAX-ACCESS from
> > read-write to read-only
> > - Deprecate ospfExtLsdbTable and add ospfAsLsdbTable
> > - Add external route tag object to ospfAreaAggregateTable
> for NSSA (RFC 3101)
> > - Change status of RFC 1850 compliance and conformance
> groups from "deprecated" to
> >   "current"
> > - Add support for Graceful Restart
> >
> > Pending updates for version -07
> >
> > - Configuration objects to support detection of inactive neighbors
> > - Resolution of issues raised by IESG's OAM expert reviewer
> on version
> > -05
> > - Remaining open issues on traps
> > - Add section on MIB support for multiple OSPF instances
> > - Fix smilint errors/warnings
> > - Fix ospfStubRouterAdvertisement Description clause per
> Don's comment
> > - Change "hitless restart" to "graceful restart" per Don's comment
> > - Any additional issues from WG
> >
> > -Dan
> >
> > _______________________________________________
> > Join Excite! - http://www.excite.com
> > The most personalized portal on the Web!
> >
>
>
> --
> Acee
>

------_=_NextPart_001_01C30F2A.7FE44418-- From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 30 11:27:42 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08672 for ; Wed, 30 Apr 2003 11:27:40 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.009A0385@cherry.ease.lsoft.com>; Wed, 30 Apr 2003 11:29:35 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 693776 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 30 Apr 2003 11:29:34 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 30 Apr 2003 11:29:34 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id 8ECC65EDA82 for ; Wed, 30 Apr 2003 08:29:25 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <6204FDDE129D364D8040A98BCCB290EF0440AC26@zbl6c004.corpeast.baynetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3EAFEB4B.7030203@redback.com> Date: Wed, 30 Apr 2003 11:27:07 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Working Group Last Call for draft-ietf-ospf-mib-update-06.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Dan, Daniel Joyal wrote: > > > > -----Original Message----- > > From: Acee Lindem [mailto:acee@REDBACK.COM] > > Sent: Tuesday, April 29, 2003 6:20 PM > > To: OSPF@DISCUSS.MICROSOFT.COM > > Subject: Re: Working Group Last Call for > > draft-ietf-ospf-mib-update-06.txt > > > > > > Hi Don, > > > > Some questions below: > > > > Don Goodspeed wrote: > > > Dan and all, > > > > > > Couple of things from my second review that I don't know if > > we want to > > > address or not: 1. Configuration of a TE metric at the > > interface level > > > (like ISIS). > > > > Do we really want this? It seems that if this were added, > > other TE stuff should be added as well. > > What other TE stuff would we need? From a configuration standpoint, there is also TE color. From a monitoring standpoint, there is all the bandwidth state. How did ISIS handle this? > > > > > > 2. Text regarding the issue that some SNMP agents may not > > be able to > > > query the largest size of the ospfLsdbAdvertisement attribute. > > I'll add some text. > > > 3. > > > Adding new error codes to ospfConfigErrorType: > > invalidLength (actual > > > packet size did not match) > > > > What does this mean? That the OSPF packet length didn't match > > the IP packet length? I don't think we want people to check > > this since there is at least one extension that requires them > > not to match. > > Do you mean cryptographic authentication? Nope - I mean link local signaling. Even though it is not a standard I don't think we should add checking to make it more difficult to deploy if we ever decide to standardise it. > > > > > > , duplicateRouterIdReceived. > > I will add this. It was previously suggested. > > > > 4. Is it permitted (I can't remember) to add a single var-bind to a > > > previously defined notification. If it is, can I suggest > > adding new > > > attributes for ospfIfEventType and ospfNbrEventType to the > > > IfStateChange and NbrStateChange traps? > > I will check and add if allowed. > > -Dan > > > > Thanks, > > Acee > > > > > > > > Thanks in advance, > > > Don > > > > > > --- On Tue 04/29, Daniel Joyal < djoyal@NORTELNETWORKS.COM > wrote: > > > From: Daniel Joyal [mailto: djoyal@NORTELNETWORKS.COM] > > > To: OSPF@DISCUSS.MICROSOFT.COM > > > Date: Tue, 29 Apr 2003 09:57:59 -0400 > > > Subject: Re: Working Group Last Call for > > > draft-ietf-ospf-mib-update-06.txt > > > > > > Version -06 of the OSPFv2 MIB update includes: > > > > > > - Add General group object for configuring reference bandwidth > > > - Change General group object ospfOpaqueLsaSupport MAX-ACCESS from > > > read-write to read-only > > > - Deprecate ospfExtLsdbTable and add ospfAsLsdbTable > > > - Add external route tag object to ospfAreaAggregateTable > > for NSSA (RFC 3101) > > > - Change status of RFC 1850 compliance and conformance > > groups from "deprecated" to > > > "current" > > > - Add support for Graceful Restart > > > > > > Pending updates for version -07 > > > > > > - Configuration objects to support detection of inactive neighbors > > > - Resolution of issues raised by IESG's OAM expert reviewer > > on version > > > -05 > > > - Remaining open issues on traps > > > - Add section on MIB support for multiple OSPF instances > > > - Fix smilint errors/warnings > > > - Fix ospfStubRouterAdvertisement Description clause per > > Don's comment > > > - Change "hitless restart" to "graceful restart" per Don's comment > > > - Any additional issues from WG > > > > > > -Dan > > > > > > _______________________________________________ > > > Join Excite! - http://www.excite.com > > > The most personalized portal on the Web! > > > > > > > > > -- > > Acee > > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 30 11:34:08 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08882 for ; Wed, 30 Apr 2003 11:33:47 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.009A05E4@cherry.ease.lsoft.com>; Wed, 30 Apr 2003 11:36:25 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 693884 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 30 Apr 2003 11:36:25 -0400 Received: from 64.115.125.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 30 Apr 2003 11:36:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 30 Apr 2003 11:36:04 -0400 Reply-To: Mailing List Sender: Mailing List From: Jeff Parker Subject: Re: Working Group Last Call for draft-ietf-ospf-mib-update-06.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list > > What other TE stuff would we need? > > From a configuration standpoint, there is also TE color. From a > monitoring standpoint, there is all the bandwidth state. How did > ISIS handle this? IS-IS doesn't configure TE information, anymore than it configures the MTU. It just finds stuff through some implementation dependant method and reports it. This is visible through the LSP Database (Link State PDU, not Label Switched Path) which allows someone to see what is being flooded. - jeff parker From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 30 11:40:24 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09045 for ; Wed, 30 Apr 2003 11:40:23 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.009A05E3@cherry.ease.lsoft.com>; Wed, 30 Apr 2003 11:39:03 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 693905 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 30 Apr 2003 11:39:03 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 30 Apr 2003 11:39:03 -0400 Received: from redback.com (login001.redback.com [155.53.12.18]) by prattle.redback.com (Postfix) with ESMTP id B3BB25EDA83 for ; Wed, 30 Apr 2003 08:38:49 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3EAFED7F.6060005@redback.com> Date: Wed, 30 Apr 2003 11:36:31 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Working Group Last Call for draft-ietf-ospf-mib-update-06.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Jeff Parker wrote: >>>What other TE stuff would we need? >> >> From a configuration standpoint, there is also TE color. From a >>monitoring standpoint, there is all the bandwidth state. How did >>ISIS handle this? > > > IS-IS doesn't configure TE information, anymore than it configures > the MTU. It just finds stuff through some implementation dependant > method and reports it. > > This is visible through the LSP Database (Link State PDU, not > Label Switched Path) which allows someone to see what is being > flooded. Sounds reasonable. So why would we want to allow configuration or visibility of TE information in the OSPF MIB? Thanks, -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 30 14:57:50 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18999 for ; Wed, 30 Apr 2003 14:57:49 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.009A143A@cherry.ease.lsoft.com>; Wed, 30 Apr 2003 15:00:37 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 695306 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 30 Apr 2003 15:00:37 -0400 Received: from 47.129.242.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 30 Apr 2003 15:00:37 -0400 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3UJ0ZL15154 for ; Wed, 30 Apr 2003 15:00:35 -0400 (EDT) Received: by zbl6c012.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Apr 2003 15:00:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30F4A.C767B548" Message-ID: <6204FDDE129D364D8040A98BCCB290EF0440AC28@zbl6c004.corpeast.baynetworks.com> Date: Wed, 30 Apr 2003 15:00:34 -0400 Reply-To: Mailing List Sender: Mailing List From: Daniel Joyal Subject: Re: Working Group Last Call for draft-ietf-ospf-mib-update-06.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C30F4A.C767B548 Content-Type: text/plain > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Wednesday, April 30, 2003 11:37 AM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: Working Group Last Call for > draft-ietf-ospf-mib-update-06.txt > > > Jeff Parker wrote: > >>>What other TE stuff would we need? > >> > >> From a configuration standpoint, there is also TE color. From a > >>monitoring standpoint, there is all the bandwidth state. > How did ISIS > >>handle this? > > > > > > IS-IS doesn't configure TE information, anymore than it > configures the > > MTU. It just finds stuff through some implementation > dependant method > > and reports it. > > > > This is visible through the LSP Database (Link State PDU, not Label > > Switched Path) which allows someone to see what is being flooded. Likewise for OSPF through the TE LSAs in the Area LSDB Table. > > Sounds reasonable. So why would we want to allow > configuration or visibility of TE information in the OSPF MIB? I think we might want to configure protocol-specific TE information in the protocol MIBs and non-protocol-specific information in the TE MIB. Both the IS-IS MIB and the updated OSPF MIB currently support the configuration of the enabling/disabling of TE for the protocol. isisSysLevelTEEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Do we do Traffic Engineering at this level?" DEFVAL { false } ::= { isisSysLevelEntry 9 } ospfTrafficEngineeringSupport OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "The router's support for OSPF traffic engineering." ::= { ospfGeneralGroup 17 } In the "Traffic Engineering Extensions to OSPF Version 2" document, the traffic engineering metric sub-TLV seems to be specific to OSPF. From section 2.5.5. "The Traffic Engineering Metric sub-TLV specifies the link metric for traffic engineering purposes. This metric may be different than the standard OSPF link metric. Typically, this metric is assigned by a network admistrator." Similarly, the "IS-IS extensions for Traffic Engineering" document defines sub-TLV 18. From section 3.7. "This sub-TLV contains a 24-bit unsigned integer. This metric is administratively assigned and can be used to present a differently weighted topology to traffic engineering SPF calculations." As Don suggested, these might be candidates for a new configuration objects in the protocol MIBs. Bandwidth, Admin Groups, etc. are covered in the TE MIB. -Dan > > Thanks, > -- > Acee > ------_=_NextPart_001_01C30F4A.C767B548 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Working Group Last Call for = draft-ietf-ospf-mib-update-06.txt

> -----Original Message-----
> From: Acee Lindem [mailto:acee@REDBACK.COM]
> Sent: Wednesday, April 30, 2003 11:37 AM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Re: Working Group Last Call for =
> draft-ietf-ospf-mib-update-06.txt
>
>
> Jeff Parker wrote:
> >>>What other TE stuff would we = need?
> >>
> >> From a configuration standpoint, there = is also TE color. From a
> >>monitoring standpoint, there is all the = bandwidth state.
> How did ISIS
> >>handle this?
> >
> >
> > IS-IS doesn't configure TE information, = anymore than it
> configures the
> > MTU.  It just finds stuff through = some implementation
> dependant method
> > and reports it.
> >
> > This is visible through the LSP Database = (Link State PDU, not Label
> > Switched Path) which allows someone to see = what is being flooded.

Likewise for OSPF through the TE LSAs in the Area = LSDB Table.

>
> Sounds reasonable. So why would we want to = allow
> configuration or visibility of TE information = in the OSPF MIB?

I think we might want to configure protocol-specific = TE information
in the protocol MIBs and non-protocol-specific = information in the TE MIB.
Both the IS-IS MIB and the updated OSPF MIB = currently support the
configuration of the enabling/disabling of TE for = the protocol.

isisSysLevelTEEnabled OBJECT-TYPE
        SYNTAX = TruthValue
        = MAX-ACCESS read-create
        STATUS = current
        = DESCRIPTION
          &nb= sp; "Do we do Traffic Engineering at this level?"
        DEFVAL { = false }
    ::=3D { isisSysLevelEntry 9 = }

ospfTrafficEngineeringSupport OBJECT-TYPE
        = SYNTAX       TruthValue
        = MAX-ACCESS   read-write
        = STATUS       current
        = DESCRIPTION
           = "The router's support for OSPF traffic engineering."
        ::=3D { = ospfGeneralGroup 17 }

In the "Traffic Engineering Extensions to OSPF = Version 2" document,
the traffic engineering metric sub-TLV seems to be = specific to OSPF.
From section 2.5.5.

   "The Traffic Engineering Metric = sub-TLV specifies the link metric for
   traffic engineering purposes.  = This metric may be different than the
   standard OSPF link metric.  = Typically, this metric is assigned by a
   network admistrator."

Similarly, the "IS-IS extensions for Traffic = Engineering" document
defines sub-TLV 18.
From section 3.7.

   "This sub-TLV contains a 24-bit = unsigned integer.  This metric is
   administratively assigned and can be = used to present a differently
   weighted topology to traffic = engineering SPF calculations."

As Don suggested, these might be candidates for a new = configuration objects
in the protocol MIBs. Bandwidth, Admin Groups, etc. = are covered in the TE MIB.

-Dan

>
> Thanks,
> --
> Acee
>

------_=_NextPart_001_01C30F4A.C767B548-- From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 30 15:26:37 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21371 for ; Wed, 30 Apr 2003 15:26:36 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.009A146D@cherry.ease.lsoft.com>; Wed, 30 Apr 2003 15:29:25 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 695384 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 30 Apr 2003 15:29:25 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 30 Apr 2003 15:29:24 -0400 Received: from redback.com (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 68BC34BAFC3 for ; Wed, 30 Apr 2003 12:28:38 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <6204FDDE129D364D8040A98BCCB290EF0440AC28@zbl6c004.corpeast.baynetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3EB02359.4010609@redback.com> Date: Wed, 30 Apr 2003 15:26:17 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Working Group Last Call for draft-ietf-ospf-mib-update-06.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Daniel Joyal wrote: > > > > -----Original Message----- > > From: Acee Lindem [mailto:acee@REDBACK.COM] > > Sent: Wednesday, April 30, 2003 11:37 AM > > To: OSPF@DISCUSS.MICROSOFT.COM > > Subject: Re: Working Group Last Call for > > draft-ietf-ospf-mib-update-06.txt > > > > > > Jeff Parker wrote: > > >>>What other TE stuff would we need? > > >> > > >> From a configuration standpoint, there is also TE color. From a > > >>monitoring standpoint, there is all the bandwidth state. > > How did ISIS > > >>handle this? > > > > > > > > > IS-IS doesn't configure TE information, anymore than it > > configures the > > > MTU. It just finds stuff through some implementation > > dependant method > > > and reports it. > > > > > > This is visible through the LSP Database (Link State PDU, not Label > > > Switched Path) which allows someone to see what is being flooded. > > Likewise for OSPF through the TE LSAs in the Area LSDB Table. > > > > > Sounds reasonable. So why would we want to allow > > configuration or visibility of TE information in the OSPF MIB? > > I think we might want to configure protocol-specific TE information > in the protocol MIBs and non-protocol-specific information in the TE MIB. > Both the IS-IS MIB and the updated OSPF MIB currently support the > configuration of the enabling/disabling of TE for the protocol. > > isisSysLevelTEEnabled OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Do we do Traffic Engineering at this level?" > DEFVAL { false } > ::= { isisSysLevelEntry 9 } > > ospfTrafficEngineeringSupport OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The router's support for OSPF traffic engineering." > ::= { ospfGeneralGroup 17 } > > In the "Traffic Engineering Extensions to OSPF Version 2" document, > the traffic engineering metric sub-TLV seems to be specific to OSPF. > From section 2.5.5. > > "The Traffic Engineering Metric sub-TLV specifies the link metric for > traffic engineering purposes. This metric may be different than the > standard OSPF link metric. Typically, this metric is assigned by a > network admistrator." > > Similarly, the "IS-IS extensions for Traffic Engineering" document > defines sub-TLV 18. > From section 3.7. > > "This sub-TLV contains a 24-bit unsigned integer. This metric is > administratively assigned and can be used to present a differently > weighted topology to traffic engineering SPF calculations." > > As Don suggested, these might be candidates for a new configuration objects > in the protocol MIBs. Bandwidth, Admin Groups, etc. are covered in the > TE MIB. draft-ietf-tewg-mib-04.txt Okay - I'm not strongly opposed. However, I took a look at the TE MIB (draft-ietf-tewg-mib-04.txt) and its tunnel table is relative to a complete TE'ed path (e.g., LSP). Whereas, the OSPF TE stuff applies to a specific interface. It almost seems to me like all this TE stuff should be included or go in a separate MIB. The problem with included it is that the extensions go on an on. > > -Dan > > > > > Thanks, > > -- > > Acee > > > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 30 15:37:14 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21844 for ; Wed, 30 Apr 2003 15:37:14 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.009A1512@cherry.ease.lsoft.com>; Wed, 30 Apr 2003 15:40:04 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 695409 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 30 Apr 2003 15:40:03 -0400 Received: from 204.192.44.242 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 30 Apr 2003 15:40:03 -0400 Received: (qmail 16490 invoked from network); 30 Apr 2003 19:40:03 -0000 Received: from bigbird.xebeo.com (192.168.0.21) by lxmail.xebeo.com with SMTP; 30 Apr 2003 19:40:03 -0000 Received: from bigbird.xebeo.com (localhost.localdomain [127.0.0.1]) by bigbird.xebeo.com (8.9.3/8.9.3) with ESMTP id PAA03765; Wed, 30 Apr 2003 15:40:03 -0400 X-Mailer: exmh version 2.1.1 10/15/1999 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <200304301940.PAA03765@bigbird.xebeo.com> Date: Wed, 30 Apr 2003 15:40:03 -0400 Reply-To: Mailing List Sender: Mailing List From: Rohit Dube Subject: Re: Working Group Last Call for draft-ietf-ospf-mib-update-06.txt To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Message from Acee Lindem of "Wed, 30 Apr 2003 15:26:17 EDT." <3EB02359.4010609@redback.com> Precedence: list On Wed, 30 Apr 2003 15:26:17 -0400 Acee Lindem writes: =>> As Don suggested, these might be candidates for a new configuration objects =>> in the protocol MIBs. Bandwidth, Admin Groups, etc. are covered in the =>> TE MIB. draft-ietf-tewg-mib-04.txt => =>Okay - I'm not strongly opposed. However, I took a look at the =>TE MIB (draft-ietf-tewg-mib-04.txt) and its tunnel table is relative =>to a complete TE'ed path (e.g., LSP). Whereas, the OSPF TE stuff =>applies to a specific interface. It almost seems to me like all this TE =>stuff should be included or go in a separate MIB. The problem with =>included it is that the extensions go on an on. FWIW, I would be mildly opposed to putting the TE stuff into the MIB for exactly the reasons that Acee suggests : o if we decide to work on this, this should go into a separate MIB. o TE extensions may go on for a while and we can't wait on these to push the ospf-mib-update through. For instance if the diffserv te work is standardized, there may be objects from there that would need to be pulled into such a MIB. Regards, --rohit. From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 30 16:04:26 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22418 for ; Wed, 30 Apr 2003 16:04:25 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.009A15AF@cherry.ease.lsoft.com>; Wed, 30 Apr 2003 16:07:14 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 695486 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 30 Apr 2003 16:07:14 -0400 Received: from 47.129.242.157 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 30 Apr 2003 16:07:14 -0400 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3UK7CT19873 for ; Wed, 30 Apr 2003 16:07:12 -0400 (EDT) Received: by zbl6c012.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Apr 2003 16:07:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30F54.14952DBA" Message-ID: <6204FDDE129D364D8040A98BCCB290EF0440AC29@zbl6c004.corpeast.baynetworks.com> Date: Wed, 30 Apr 2003 16:07:09 -0400 Reply-To: Mailing List Sender: Mailing List From: Daniel Joyal Subject: Re: Working Group Last Call for draft-ietf-ospf-mib-update-06.txt To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C30F54.14952DBA Content-Type: text/plain > -----Original Message----- > From: Acee Lindem [mailto:acee@REDBACK.COM] > Sent: Wednesday, April 30, 2003 3:26 PM > To: OSPF@DISCUSS.MICROSOFT.COM > Subject: Re: Working Group Last Call for > draft-ietf-ospf-mib-update-06.txt > > > Daniel Joyal wrote: > > > > > > > -----Original Message----- > > > From: Acee Lindem [mailto:acee@REDBACK.COM] > > > Sent: Wednesday, April 30, 2003 11:37 AM > > > To: OSPF@DISCUSS.MICROSOFT.COM > > > Subject: Re: Working Group Last Call for > > > draft-ietf-ospf-mib-update-06.txt > > > > > > > > > Jeff Parker wrote: > > > >>>What other TE stuff would we need? > > > >> > > > >> From a configuration standpoint, there is also TE > color. From a > > > >>monitoring standpoint, there is all the bandwidth state. > How > > did ISIS > >>handle this? > > > > > > > > > > > > IS-IS doesn't configure TE information, anymore than it > > > configures the > > > > MTU. It just finds stuff through some implementation > > > dependant method > > > > and reports it. > > > > > > > > This is visible through the LSP Database (Link State > PDU, not Label > > > > Switched Path) which allows someone to see what is > being flooded. > > > > Likewise for OSPF through the TE LSAs in the Area LSDB Table. > > > > > > > > Sounds reasonable. So why would we want to allow > > > configuration or visibility of TE information in the OSPF MIB? > > > > I think we might want to configure protocol-specific TE > information in > > the protocol MIBs and non-protocol-specific information in > the TE MIB. > > Both the IS-IS MIB and the updated OSPF MIB currently support the > > configuration of the enabling/disabling of TE for the protocol. > > > > isisSysLevelTEEnabled OBJECT-TYPE > > SYNTAX TruthValue > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "Do we do Traffic Engineering at this level?" > > DEFVAL { false } > > ::= { isisSysLevelEntry 9 } > > > > ospfTrafficEngineeringSupport OBJECT-TYPE > > SYNTAX TruthValue > > MAX-ACCESS read-write > > STATUS current > > DESCRIPTION > > "The router's support for OSPF traffic engineering." > > ::= { ospfGeneralGroup 17 } > > > > In the "Traffic Engineering Extensions to OSPF Version 2" document, > > the traffic engineering metric sub-TLV seems to be specific > to OSPF. > > From section 2.5.5. > > > > "The Traffic Engineering Metric sub-TLV specifies the > link metric for > > traffic engineering purposes. This metric may be > different than the > > standard OSPF link metric. Typically, this metric is > assigned by a > > network admistrator." > > > > Similarly, the "IS-IS extensions for Traffic Engineering" document > > defines sub-TLV 18. From section 3.7. > > > > "This sub-TLV contains a 24-bit unsigned integer. This metric is > > administratively assigned and can be used to present a > differently > > weighted topology to traffic engineering SPF calculations." > > > > As Don suggested, these might be candidates for a new configuration > > objects in the protocol MIBs. Bandwidth, Admin Groups, etc. are > > covered in the TE MIB. draft-ietf-tewg-mib-04.txt > > Okay - I'm not strongly opposed. However, I took a look at > the TE MIB (draft-ietf-tewg-mib-04.txt) and its tunnel table > is relative to a complete TE'ed path (e.g., LSP). Whereas, > the OSPF TE stuff applies to a specific interface. It almost > seems to me like all this TE stuff should be included or go > in a separate MIB. The problem with included it is that the > extensions go on an on. > If we want to go with a separate OSPF TE MIB, that's OK. I'll remove the ospfTrafficEngineeringSupport object from the next revision of the OSPF MIB draft. I think someone in the WG once volunteered to write a TE MIB for OSPF. -Dan > > > > > -Dan > > > > > > > > Thanks, > > > -- > > > Acee > > > > > > > > -- > Acee > ------_=_NextPart_001_01C30F54.14952DBA Content-Type: text/html RE: Working Group Last Call for draft-ietf-ospf-mib-update-06.txt

> -----Original Message-----
> From: Acee Lindem [mailto:acee@REDBACK.COM]
> Sent: Wednesday, April 30, 2003 3:26 PM
> To: OSPF@DISCUSS.MICROSOFT.COM
> Subject: Re: Working Group Last Call for
> draft-ietf-ospf-mib-update-06.txt
>
>
> Daniel Joyal wrote:
> >
> >
> >  > -----Original Message-----
> >  > From: Acee Lindem [mailto:acee@REDBACK.COM]
> >  > Sent: Wednesday, April 30, 2003 11:37 AM
> >  > To: OSPF@DISCUSS.MICROSOFT.COM
> >  > Subject: Re: Working Group Last Call for
> >  > draft-ietf-ospf-mib-update-06.txt
> >  >
> >  >
> >  > Jeff Parker wrote:
> >  > >>>What other TE stuff would we need?
> >  > >>
> >  > >> From a configuration standpoint, there is also TE
> color. From a 
> > > >>monitoring standpoint, there is all the bandwidth state.  > How
> > did ISIS  > >>handle this?
> >  > >
> >  > >
> >  > > IS-IS doesn't configure TE information, anymore than it
> >  > configures the
> >  > > MTU.  It just finds stuff through some implementation
> >  > dependant method
> >  > > and reports it.
> >  > >
> >  > > This is visible through the LSP Database (Link State
> PDU, not Label
> >  > > Switched Path) which allows someone to see what is
> being flooded.
> >
> > Likewise for OSPF through the TE LSAs in the Area LSDB Table.
> >
> >  >
> >  > Sounds reasonable. So why would we want to allow
> >  > configuration or visibility of TE information in the OSPF MIB?
> >
> > I think we might want to configure protocol-specific TE
> information in
> > the protocol MIBs and non-protocol-specific information in
> the TE MIB.
> > Both the IS-IS MIB and the updated OSPF MIB currently support the
> > configuration of the enabling/disabling of TE for the protocol.
> >
> > isisSysLevelTEEnabled OBJECT-TYPE
> >         SYNTAX TruthValue
> >         MAX-ACCESS read-create
> >         STATUS current
> >         DESCRIPTION
> >             "Do we do Traffic Engineering at this level?"
> >         DEFVAL { false }
> >     ::= { isisSysLevelEntry 9 }
> >
> > ospfTrafficEngineeringSupport OBJECT-TYPE
> >         SYNTAX       TruthValue
> >         MAX-ACCESS   read-write
> >         STATUS       current
> >         DESCRIPTION
> >            "The router's support for OSPF traffic engineering."
> >         ::= { ospfGeneralGroup 17 }
> >
> > In the "Traffic Engineering Extensions to OSPF Version 2" document,
> > the traffic engineering metric sub-TLV seems to be specific
> to OSPF. 
> > From section 2.5.5.
> >
> >    "The Traffic Engineering Metric sub-TLV specifies the
> link metric for
> >    traffic engineering purposes.  This metric may be
> different than the
> >    standard OSPF link metric.  Typically, this metric is
> assigned by a
> >    network admistrator."
> >
> > Similarly, the "IS-IS extensions for Traffic Engineering" document
> > defines sub-TLV 18.  From section 3.7.
> >
> >    "This sub-TLV contains a 24-bit unsigned integer.  This metric is
> >    administratively assigned and can be used to present a
> differently
> >    weighted topology to traffic engineering SPF calculations."
> >
> > As Don suggested, these might be candidates for a new configuration
> > objects in the protocol MIBs. Bandwidth, Admin Groups, etc. are
> > covered in the TE MIB.  draft-ietf-tewg-mib-04.txt
>
> Okay - I'm not strongly opposed. However, I took a look at
> the TE MIB (draft-ietf-tewg-mib-04.txt) and its tunnel table
> is relative to a complete TE'ed path (e.g., LSP). Whereas,
> the OSPF TE stuff applies to a specific interface. It almost
> seems to me like all this TE stuff should be included or go
> in a separate MIB. The problem with included it is that the
> extensions go on an on.
>

If we want to go with a separate OSPF TE MIB, that's OK. I'll
remove the ospfTrafficEngineeringSupport object from the next
revision of the OSPF MIB draft. I think someone in the WG once
volunteered to write a TE MIB for OSPF.

-Dan
>
> >
> > -Dan
> >
> >  >
> >  > Thanks,
> >  > --
> >  > Acee
> >  >
> >
>
>
> --
> Acee
>

------_=_NextPart_001_01C30F54.14952DBA-- From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 30 18:39:45 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28089 for ; Wed, 30 Apr 2003 18:39:44 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.009A1B2C@cherry.ease.lsoft.com>; Wed, 30 Apr 2003 18:41:35 -0400 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 696141 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 30 Apr 2003 18:41:35 -0400 Received: from 207.159.120.60 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 30 Apr 2003 18:41:35 -0400 Received: by xmxpita.excite.com (Postfix, from userid 110) id 1731EB6F7; Wed, 30 Apr 2003 18:41:29 -0400 (EDT) Received: from [64.47.48.10] by xprdmailfe18.nwk.excite.com via HTTP; Wed, 30 Apr 2003 18:41:29 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = ce00c10647f1b9e7db16a67db0936ee4 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: <20030430224129.1731EB6F7@xmxpita.excite.com> Date: Wed, 30 Apr 2003 18:41:29 -0400 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: progress summary of my last set of comments To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit All, So then, to summarize the results of the last two days of email chain (see inline notes): > Dan and all, > > Couple of things from my second review that I don't know if we > want to address or not: > 1. Configuration of a TE metric at the interface level (like ISIS). All TE items to be moved to separate MIB > 2. Text regarding the issue that some SNMP agents may not be > able to query the largest size of the ospfLsdbAdvertisement attribute. Text to be added. > 3. Adding new error codes to ospfConfigErrorType: invalidLength > (actual packet size did not match) Will not be added. > , duplicateRouterIdReceived. In progress to be added. > 4. Is it permitted (I can't remember) to add a single var-bind > to a previously defined notification. If it is, can I suggest > adding new attributes for ospfIfEventType and ospfNbrEventType > to the IfStateChange and NbrStateChange traps? Being investigated if this is allowed. Thanks for all your comments, Don _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 30 22:07:49 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02901 for ; Wed, 30 Apr 2003 22:07:34 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.009A2126@cherry.ease.lsoft.com>; Thu, 1 May 2003 22:09:53 +2000 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 696590 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 30 Apr 2003 22:09:52 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 30 Apr 2003 22:09:52 -0400 Received: from redback.com (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 6CBF5A56DB6 for ; Wed, 30 Apr 2003 19:08:24 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <20030430224129.1731EB6F7@xmxpita.excite.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <3EB08108.8000706@redback.com> Date: Wed, 30 Apr 2003 22:06:00 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: progress summary of my last set of comments To: OSPF@DISCUSS.MICROSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Don, I believe this is consistent with my interpretation of the discussions. Thanks, Acee Don Goodspeed wrote: > All, > > So then, to summarize the results of the last two days of email > chain (see inline notes): > > >>Dan and all, >> >>Couple of things from my second review that I don't know if we >>want to address or not: >>1. Configuration of a TE metric at the interface level (like ISIS). > > All TE items to be moved to separate MIB > > >>2. Text regarding the issue that some SNMP agents may not be >>able to query the largest size of the ospfLsdbAdvertisement attribute. > > Text to be added. > > >>3. Adding new error codes to ospfConfigErrorType: invalidLength >>(actual packet size did not match) > > Will not be added. > > >>, duplicateRouterIdReceived. > > In progress to be added. > > >>4. Is it permitted (I can't remember) to add a single var-bind >>to a previously defined notification. If it is, can I suggest >>adding new attributes for ospfIfEventType and ospfNbrEventType >>to the IfStateChange and NbrStateChange traps? > > Being investigated if this is allowed. > > Thanks for all your comments, > Don > > _______________________________________________ > Join Excite! - http://www.excite.com > The most personalized portal on the Web! > -- Acee From owner-ospf@DISCUSS.MICROSOFT.COM Wed Apr 30 23:29:59 2003 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04118 for ; Wed, 30 Apr 2003 23:29:59 -0400 (EDT) Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.009A2734@cherry.ease.lsoft.com>; Thu, 1 May 2003 23:32:47 +2000 Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 696714 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 30 Apr 2003 23:32:47 -0400 Received: from 164.107.115.5 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 30 Apr 2003 23:32:47 -0400 Received: from iota.cis.ohio-state.edu (daemon@iota.cis.ohio-state.edu [164.107.112.17]) by cis.ohio-state.edu (8.11.6/8.11.6) with ESMTP id h413Wk707187 for ; Wed, 30 Apr 2003 23:32:46 -0400 (EDT) Received: from localhost (mukul@localhost) by iota.cis.ohio-state.edu (8.11.6/8.11.6) with ESMTP id h413Wk214566 for ; Wed, 30 Apr 2003 23:32:46 -0400 (EDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Wed, 30 Apr 2003 23:32:46 -0400 Reply-To: Mailing List Sender: Mailing List From: mukul goyal Subject: Pacing/SPFDelay/SPFHoldTime in Freeware OSPF To: OSPF@DISCUSS.MICROSOFT.COM In-Reply-To: Precedence: list Hi all, I was curious if freeware OSPF implementations like GateD/Zebra support non-standard features like LSA pacing and spfDelay/spfHoldTime. Thanks, Mukul Goyal