From owner-ospf@PEACH.EASE.LSOFT.COM Fri Dec 02 16:00:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiI1M-0001qW-PY for ospf-archive@megatron.ietf.org; Fri, 02 Dec 2005 16:00:44 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15517 for ; Fri, 2 Dec 2005 15:59:54 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <0.00004276@wildebeest.ease.lsoft.com>; Fri, 2 Dec 2005 16:00:06 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 92364726 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 2 Dec 2005 16:00:05 -0500 Received: from 132.151.6.50 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 2 Dec 2005 15:50:04 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EiHqz-0003Dm-W5; Fri, 02 Dec 2005 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-ID: Date: Fri, 2 Dec 2005 15:50:01 -0500 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-cap-08.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Extensions to OSPF for Advertising Optional Router Capabilities Author(s) : A. Lindem, et al. Filename : draft-ietf-ospf-cap-08.txt Pages : 14 Date : 2005-12-2 It is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain. This draft proposes extensions to OSPFv2 and OSPFv3 for advertising optional router capabilities. A new Router Information (RI) LSA is proposed for this purpose. In OSPFv2, the RI LSA will be implemented with a new opaque LSA type ID. In OSPFv3, the RI LSA will be implemented with a new LSA type function code. In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or AS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-cap-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-cap-08.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-cap-08.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: <2005-12-2125113.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-cap-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-cap-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-2125113.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Sun Dec 04 15:22:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ej0N9-0001m8-Gm for ospf-archive@megatron.ietf.org; Sun, 04 Dec 2005 15:22:11 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13652 for ; Sun, 4 Dec 2005 15:21:22 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <9.0000453F@wildebeest.ease.lsoft.com>; 4 Dec 2005 15:21:36 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 92537997 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 4 Dec 2005 15:21:36 -0500 Received: from 209.119.0.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 4 Dec 2005 15:21:36 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by LIME.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0003FB6D@LIME.ease.lsoft.com>; 4 Dec 2005 15:21:10 -0500 Message-ID: Date: Sun, 4 Dec 2005 15:21:23 -0500 Reply-To: Mailing List Sender: Mailing List From: SUBSCRIBE OSPF vishnuvardhan B Subject: Re: Ospf3 checksum To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Hi All, From rfc 2740 the ospf header checksum is calculated as follows: The 16-bit one's complement of the one's complement sum of the entire contents of the packet, starting with the OSPF packet header, and prepending a "pseudo-header" of IPv6 header fields, as specified in [Ref14, section 8.1]. As far as i know the pseudo-header contains a destination,src,len,protocol no. So if i want to generate any ospf3 packet, i should generate the checksum based on the destination??? this means an additional work of computing the checksum for each ospf3 packet generated. And also it's pain to know about the destination and calculate the checksum for each ospf3 packet generated. Please give me some pointers on if it is compulsory to generate the ospf3 packet checksum based on the destination. Regards, Vishnu From owner-ospf@PEACH.EASE.LSOFT.COM Mon Dec 05 07:47:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjFkp-0001oO-HX for ospf-archive@megatron.ietf.org; Mon, 05 Dec 2005 07:47:39 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11734 for ; Mon, 5 Dec 2005 07:46:48 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <14.000045B4@wildebeest.ease.lsoft.com>; Mon, 5 Dec 2005 7:47:05 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 92605150 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 5 Dec 2005 07:47:06 -0500 Received: from 192.93.2.39 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 5 Dec 2005 07:37:06 -0500 Received: from [192.168.112.160] (sphinx.lix.polytechnique.fr [129.104.11.1]) (authenticated bits=0) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id jB5Cb1fX011572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 5 Dec 2005 13:37:05 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <77F357662F8BFA4CA7074B0410171B6DC9E6E1@XCH-NW-5V1.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-j-chkmail-Score: MSGID : 4394346D.000 on concorde : j-chkmail score : X : 0/20 1 X-Miltered: at concorde with ID 4394346D.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! Message-ID: <4394346B.7070701@inria.fr> Date: Mon, 5 Dec 2005 13:36:59 +0100 Reply-To: Mailing List Sender: Mailing List From: Philippe Jacquet Organization: inria Subject: Re: evaluation plan for OSPF MANET To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <77F357662F8BFA4CA7074B0410171B6DC9E6E1@XCH-NW-5V1.nw.nos.boeing.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Dear all, I tend to agree with Tom. We should find the most robust and performant solution. And in case of equal performance one should favor the solution that has the largest maturity and broad support from the community. With this respect MPR flooding seems to be the most robust and mature. Simulations show that it has still an edge over other flooding solutions and its robustness allows it to support minimal overhead with still very good performance in extreme scenarios. I would like to point out the fact that if MPR flooding solution is indeed favored then it is not the end of the story for the promising proposals in MDR. As pointed out by Richard, MDR can be adapted with any kind of MPR CDS. However one should be careful with the concept of wireless adjacencies and how it will be exported outside the wireless portion. Clearly we will need to keep the wireless OSPF in the right track with respect to regular OSPF. Best regards, Philippe Henderson, Thomas R wrote: >Note: This message is intended to start new discussions. Replies >**only** to ospf-manet@ietf.org. > >Now that we have established a list for this activity, I would like to >suggest that the first order of business should be to agree upon a fair >process whereby the OSPF WG is in a position to move forward on an OSPF >MANET design by the March meeting. > >A first step should be to agree upon what we are trying to decide. I >believe that we are trying to decide upon whether the basis for >efficient flooding and topology control for OSPF MANET should be a >source-independent connected dominating set (specifically, Ogier's MDR >proposal) or a source-dependent connected dominating set (specifically, >Overlapping Relays with Smart Peering). > >I also believe that, unless it is proven that the two current designs >have significant performance differences in different operating >environments, we are trying to downselect to one OSPF MANET design, not >to define the operating regions most applicable to two separate designs. > >A second step should be to agree on evaluation criteria and scenarios, >to address the comments at the WG meeting that the previously used >scenarios were too narrow. This should be agreed upon within the next >month or so, based on list discussion. The scenarios/criteria need to >be feasible to achieve in the timeframe of this evaluation. > >A third step should be to allow time for the interested parties to study >the proposed approaches in light of the above criteria. Simulation or >implementation experiments can be used to support arguments, but are not >required in any or all cases. I will take the action item to integrate >the new Cisco code and post a new evaluation software release. > >A fourth step is to have any interested party submit a short position >draft on the issue at hand. The position draft should be page limited >(e.g., 10 pages) so that it is more accessible to a wider WG review, >although it may reference additional supporting material. It would be >recommended but not required that any simulation or implementation >scripts used to justify the arguments be made available at this time as >well (private simulation results should probably be treated with less >confidence by the WG). Drafts should not be allowed later than the I-D >cutoff date, and the publishing of such a draft should be required to >make a formal presentation on this topic at the Dallas meeting. > >The fifth step is to have discussion on the list between the I-D cutoff >and the meeting, and presentations and discussions at the Dallas >meeting. > >Comments? > >Tom > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Dec 05 09:16:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjH93-0004uO-Mw for ospf-archive@megatron.ietf.org; Mon, 05 Dec 2005 09:16:45 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23685 for ; Mon, 5 Dec 2005 09:15:54 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <7.000045DD@wildebeest.ease.lsoft.com>; Mon, 5 Dec 2005 9:16:14 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 92611805 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 5 Dec 2005 09:16:14 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 5 Dec 2005 09:16:14 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 05 Dec 2005 06:16:14 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,217,1131350400"; d="scan'208"; a="16563636:sNHT22042352" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB5EG34f006591 for ; Mon, 5 Dec 2005 09:16:11 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Dec 2005 09:16:10 -0500 Received: from [10.82.208.191] ([10.82.208.191]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 5 Dec 2005 09:16:09 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Dec 2005 14:16:09.0997 (UTC) FILETIME=[70A97BD0:01C5F9A6] Message-ID: <43944BA9.70504@cisco.com> Date: Mon, 5 Dec 2005 09:16:09 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Ospf3 checksum To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit OSPF vishnuvardhan B wrote: >Hi All, >>From rfc 2740 the ospf header checksum is calculated as follows: >The 16-bit one's complement of the one's complement > sum of the entire contents of the packet, starting with the OSPF > packet header, and prepending a "pseudo-header" of IPv6 header > fields, as specified in [Ref14, section 8.1]. >As far as i know the pseudo-header contains a destination,src,len,protocol >no. So if i want to generate any ospf3 packet, i should generate the >checksum based on the destination??? this means an additional work of >computing the checksum for each ospf3 packet generated. And also it's pain >to know about the destination and calculate the checksum for each ospf3 >packet generated. Please give me some pointers on if it is compulsory to >generate the ospf3 packet checksum based on the destination. > > Hi Vishnu, Inclusion of pusedo header in the checksum calculation is required. However, I'm not sure why you have a concern. OSPFv3 uses a link-scoped multicast destination for cases where a single packet would be applicable to multiple adjacencies. Thanks, Acee P.S. Please remove "SUBSCRIBE" from your E-mail from-address. It results in replies being rejected. >Regards, >Vishnu > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Dec 05 13:38:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjLEc-0002rk-UY for ospf-archive@megatron.ietf.org; Mon, 05 Dec 2005 13:38:47 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24909 for ; Mon, 5 Dec 2005 13:37:54 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <0.00004656@wildebeest.ease.lsoft.com>; Mon, 5 Dec 2005 13:38:13 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 92635547 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 5 Dec 2005 13:38:12 -0500 Received: from 209.119.1.41 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 5 Dec 2005 13:38:12 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by LIME.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00005259@LIME.ease.lsoft.com>; Mon, 5 Dec 2005 13:37:46 -0500 Message-ID: Date: Mon, 5 Dec 2005 13:38:09 -0500 Reply-To: Mailing List Sender: Mailing List From: vishnuvardhan B Subject: Re: Ospf3 checksum Comments: To: Acee Lindem To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Hi Acee, Thanks for the update. I am refering to the context where you are sending unicast packets to the neighbor. And in cases where you are in non- broadcast multiacess with p2mp/NBMA you need to send to all the destinations . Regards, Vishnu From owner-ospf@PEACH.EASE.LSOFT.COM Wed Dec 07 02:04:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjtLm-0006Z1-Lp for ospf-archive@megatron.ietf.org; Wed, 07 Dec 2005 02:04:26 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23108 for ; Wed, 7 Dec 2005 02:03:32 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <4.00004ABE@wildebeest.ease.lsoft.com>; Wed, 7 Dec 2005 2:03:49 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 92823201 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 7 Dec 2005 02:03:49 -0500 Received: from 61.144.161.55 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 7 Dec 2005 02:03:44 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IR40016J9068H@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 07 Dec 2005 15:04:54 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IR400I5H9060A@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 07 Dec 2005 15:04:54 +0800 (CST) Received: from dell60 ([10.18.4.57]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IR400F9L97TDY@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 07 Dec 2005 15:09:30 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <007d01c5fafb$bde6ec10$3904120a@china.huawei.com> Date: Wed, 7 Dec 2005 12:29:16 +0530 Reply-To: Mailing List Sender: Mailing List From: sujay Subject: Gracefu-Restart & RFC 3623 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43944BA9.70504@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT Group, In reference to; Moy, J.,P. Pillay-Esnault,A. Lindem, "Graceful OSPF Restart", RFC 3623, November 2003. There are certain areas which could be worked upon; 1. The conservative behavior of the Restarting router; - in its reaction on reception of any new lsa where it *always* exits the graceful restart, this behavior may be optimized such that the Restarting router exits GR iff the new lsa actually implies a change in the topology 2. A helper router on the presence of non-refresh lsa's in the retransmit list to the restarting router *always* exits as a gr helper - this reaction again can be ratified only if the lsa's actually specify a topology change. 3. The restarting router detects non participating helpers only via the back link checks In the router and network lsa's - this behavior again may lead to network inconsistency for some time, perhaps an explicit notification from the helper router to the restarting router could be thought of. With the above optimizations as well keeping it downwardly compatible, there are a few pointers to rectify (1) and (2) above using "Topology change Lsa's" and (3) using " Exit-Grace LSA TLV" Where in short "Topology change LSA's" is the group of LSA's which *actually* signify a Topology change And "Exit Grace LSA TLV" is an additional TLV in existing Grace LSA which the router may use to indicate Its non-particiation as a helper. The above has been documented at; www.ietf.org/internet-drafts/draft-holla-ospf-update-graceful-restart-00 .txt While the implementation issues is not much of a hassle and there is at least one vendor likely to support it request your views on the same. Sujay etc. From owner-ospf@PEACH.EASE.LSOFT.COM Wed Dec 07 02:25:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjtgU-0003eO-S1 for ospf-archive@megatron.ietf.org; Wed, 07 Dec 2005 02:25:50 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25141 for ; Wed, 7 Dec 2005 02:24:59 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <5.00004ABF@wildebeest.ease.lsoft.com>; Wed, 7 Dec 2005 2:25:19 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 92823970 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 7 Dec 2005 02:25:19 -0500 Received: from 63.197.255.154 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 7 Dec 2005 02:25:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: Gracefu-Restart & RFC 3623 Thread-Index: AcX6/GQZP4bmvpn6Qp+Sy2lLUHCLfwAAyEIA Message-ID: Date: Tue, 6 Dec 2005 23:30:04 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: Gracefu-Restart & RFC 3623 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable Hi Sujay, My apologies for now having replied any earlier. I had recommended something to the list a long-long while back. John Moy too agreed to the same. http://peach.ease.lsoft.com/scripts/wa.exe?A2=3Dind0203&L=3Dospf&T=3D0&F=3D= &S=3D&P =3D1888 . The comments somehow got dropped in transit. If you are recommending a stricter check, you may want to have a look at that. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of sujay Sent: Wednesday, December 07, 2005 12:29 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Gracefu-Restart & RFC 3623 Group, In reference to; Moy, J.,P. Pillay-Esnault,A. Lindem, "Graceful OSPF Restart", RFC 3623, November 2003.=20 There are certain areas which could be worked upon; 1. The conservative behavior of the Restarting router; - in its reaction on reception of any new lsa where it *always* exits the graceful restart, this behavior may be optimized such that the Restarting router exits GR iff the new lsa actually implies a change=20 in the topology 2. A helper router on the presence of non-refresh lsa's in the retransmit list=20 to the restarting router *always* exits as a gr helper - this reaction again can be ratified only if the lsa's actually specify a topology change. 3. The restarting router detects non participating helpers only via the back link checks=20 In the router and network lsa's - this behavior again may lead to network inconsistency for some time, perhaps an explicit=20 notification from the helper router to the restarting router could be thought of. With the above optimizations as well keeping it downwardly compatible,=20 there are a few pointers to rectify (1) and (2) above using "Topology change Lsa's" and (3) using " Exit-Grace LSA TLV" Where in short "Topology change LSA's" is the group of LSA's which *actually* signify a Topology change And "Exit Grace LSA TLV" is an additional TLV in existing Grace LSA which the router may use to indicate Its non-particiation as a helper. The above has been documented at; www.ietf.org/internet-drafts/draft-holla-ospf-update-graceful-restart-00 .txt While the implementation issues is not much of a hassle and there is at least one vendor likely to support it request your views on the same. Sujay etc. =20 =20 From owner-ospf@PEACH.EASE.LSOFT.COM Wed Dec 07 15:35:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek60v-0001XA-8u for ospf-archive@megatron.ietf.org; Wed, 07 Dec 2005 15:35:45 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23614 for ; Wed, 7 Dec 2005 15:34:52 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <12.00004DCB@wildebeest.ease.lsoft.com>; Wed, 7 Dec 2005 15:35:13 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 92903772 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 7 Dec 2005 15:35:13 -0500 Received: from 143.209.238.161 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 7 Dec 2005 15:35:12 -0500 Received: from mvrelay.mv.usa.alcatel.com (mvrelay.mv.usa.alcatel.com [128.251.10.15]) by audl951.usa.alcatel.com (ALCANET) with ESMTP id jB7K66Lx008352; Wed, 7 Dec 2005 14:06:06 -0600 Received: from dgoodspeedpc (localhost [127.0.0.1]) by mvrelay.mv.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id jB7K6In7026738; Wed, 7 Dec 2005 12:06:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Thread-index: AcX6/GOfUCApXuXjTuWavThMLDfXlQAbNhyQ X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 Message-ID: <200512072006.jB7K6In7026738@mvrelay.mv.usa.alcatel.com> Date: Wed, 7 Dec 2005 12:06:12 -0800 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Organization: Alcatel Subject: Re: Gracefu-Restart & RFC 3623 Comments: To: sujay To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <007d01c5fafb$bde6ec10$3904120a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Having helped review the original RFC during its draft stage, this draft looks like a sound one but this would probably best be addressed by contacting the original authors of the RFC and co-authoring a revised Graceful OSPF Restart draft rather than having the original one and an "enhancement". Broadcasting this to the list seems like you did not contact them. Just my observations, Don -----Original Message----- From: owner-ospf@PEACH.EASE.LSOFT.COM [mailto:owner-ospf@PEACH.EASE.LSOFT.COM] On Behalf Of sujay Sent: Tuesday, December 06, 2005 10:59 PM To: 'Mailing List' Subject: Gracefu-Restart & RFC 3623 Group, In reference to; Moy, J.,P. Pillay-Esnault,A. Lindem, "Graceful OSPF Restart", RFC 3623, November 2003. There are certain areas which could be worked upon; 1. The conservative behavior of the Restarting router; - in its reaction on reception of any new lsa where it *always* exits the graceful restart, this behavior may be optimized such that the Restarting router exits GR iff the new lsa actually implies a change in the topology 2. A helper router on the presence of non-refresh lsa's in the retransmit list to the restarting router *always* exits as a gr helper - this reaction again can be ratified only if the lsa's actually specify a topology change. 3. The restarting router detects non participating helpers only via the back link checks In the router and network lsa's - this behavior again may lead to network inconsistency for some time, perhaps an explicit notification from the helper router to the restarting router could be thought of. With the above optimizations as well keeping it downwardly compatible, there are a few pointers to rectify (1) and (2) above using "Topology change Lsa's" and (3) using " Exit-Grace LSA TLV" Where in short "Topology change LSA's" is the group of LSA's which *actually* signify a Topology change And "Exit Grace LSA TLV" is an additional TLV in existing Grace LSA which the router may use to indicate Its non-particiation as a helper. The above has been documented at; www.ietf.org/internet-drafts/draft-holla-ospf-update-graceful-restart-00 .txt While the implementation issues is not much of a hassle and there is at least one vendor likely to support it request your views on the same. Sujay etc. From owner-ospf@PEACH.EASE.LSOFT.COM Wed Dec 07 15:47:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek6CF-0004hq-OX for ospf-archive@megatron.ietf.org; Wed, 07 Dec 2005 15:47:27 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24713 for ; Wed, 7 Dec 2005 15:46:35 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <3.00004DDD@wildebeest.ease.lsoft.com>; Wed, 7 Dec 2005 15:46:56 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 92905077 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 7 Dec 2005 15:46:56 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 7 Dec 2005 15:46:56 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 07 Dec 2005 15:46:56 -0500 X-IronPort-AV: i="3.99,226,1131339600"; d="scan'208"; a="77333456:sNHT30514728" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB7Kkh4f015913 for ; Wed, 7 Dec 2005 15:46:54 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Dec 2005 15:46:49 -0500 Received: from [10.82.208.191] ([10.82.208.191]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 7 Dec 2005 15:46:49 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <200512072006.jB7K6In7026738@mvrelay.mv.usa.alcatel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Dec 2005 20:46:49.0363 (UTC) FILETIME=[58706630:01C5FB6F] Message-ID: <43974A38.2000507@cisco.com> Date: Wed, 7 Dec 2005 15:46:48 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Gracefu-Restart & RFC 3623 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <200512072006.jB7K6In7026738@mvrelay.mv.usa.alcatel.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Don Goodspeed wrote: >Having helped review the original RFC during its draft >stage, this draft looks like a sound one but this would >probably best be addressed by contacting the original authors >of the RFC and co-authoring a revised Graceful OSPF Restart draft >rather than having the original one and an "enhancement". > >Broadcasting this to the list seems like you did not contact them. > > Hi Don - actually Padma and I did get an advance copy of the document. However, it is better for the WG as a whole to decide whether or not the proposed enhancements justify standardization. Thanks, Acee >Just my observations, >Don > >-----Original Message----- >From: owner-ospf@PEACH.EASE.LSOFT.COM >[mailto:owner-ospf@PEACH.EASE.LSOFT.COM] On Behalf Of sujay >Sent: Tuesday, December 06, 2005 10:59 PM >To: 'Mailing List' >Subject: Gracefu-Restart & RFC 3623 > >Group, > >In reference to; >Moy, J.,P. Pillay-Esnault,A. Lindem, "Graceful OSPF Restart", RFC 3623, >November 2003. > >There are certain areas which could be worked upon; > >1. The conservative behavior of the Restarting router; >- in its reaction on reception of any new lsa where it *always* exits >the graceful restart, this behavior may be optimized such that the >Restarting router exits GR iff the new lsa actually implies a change >in the topology > >2. A helper router on the presence of non-refresh lsa's in the >retransmit list >to the restarting router *always* exits as a gr helper >- this reaction again can be ratified only if the lsa's actually specify >a topology change. > >3. The restarting router detects non participating helpers only via the >back link checks >In the router and network lsa's >- this behavior again may lead to network inconsistency for some time, >perhaps an explicit >notification from the helper router to the restarting router could be >thought of. > >With the above optimizations as well keeping it downwardly compatible, >there are a few pointers to rectify (1) and (2) above using "Topology >change Lsa's" and > (3) using " Exit-Grace LSA TLV" > >Where in short "Topology change LSA's" is the group of LSA's which >*actually* signify a Topology change >And "Exit Grace LSA TLV" is an additional TLV in existing Grace LSA >which the router may use to indicate >Its non-particiation as a helper. > >The above has been documented at; >www.ietf.org/internet-drafts/draft-holla-ospf-update-graceful-restart-00 >.txt > >While the implementation issues is not much of a hassle and there is at >least one vendor likely to support it >request your views on the same. > >Sujay etc. > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Dec 07 22:42:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkCg5-00055P-HD for ospf-archive@megatron.ietf.org; Wed, 07 Dec 2005 22:42:41 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17417 for ; Wed, 7 Dec 2005 22:41:48 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <2.00004F7E@wildebeest.ease.lsoft.com>; Wed, 7 Dec 2005 22:42:08 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 92941840 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 7 Dec 2005 22:42:08 -0500 Received: from 61.144.161.53 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 7 Dec 2005 22:42:08 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IR50011EUO59A@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 08 Dec 2005 11:50:29 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IR50082EUO5JC@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 08 Dec 2005 11:50:29 +0800 (CST) Received: from huaweizfbnwhb5 ([10.110.102.51]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IR5007EHUWX63@szxml01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 08 Dec 2005 11:55:45 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Message-ID: <000001c5fba9$5aeb44e0$33666e0a@china.huawei.com> Date: Thu, 8 Dec 2005 11:42:03 +0800 Reply-To: Mailing List Sender: Mailing List From: "Abhay D.S" Subject: Re: Gracefu-Restart & RFC 3623 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <200512072006.jB7K6In7026738@mvrelay.mv.usa.alcatel.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal With a foresight..and with concerns..as a reviewer for "Update to graceful restart draft". Making a case for revisiting standardization: Standardization has to be 'revisited' and in the pipeline, since "OSPF Capabilities" draft which mentions about graceful Restart capable, helper capable option advertisements are 'useful' in making Graceful restart more robust. The original RFC still lacks the solution for unplanned restarts. (Do you think this the USP for vendors ?):-| OSPF Capabilities draft can address many issues faced by service providers deploying graceful restart. Im also considering the possibility of using a different OSPF version number for some special scenarios. Abhay -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Don Goodspeed Sent: Thursday, December 08, 2005 4:06 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Gracefu-Restart & RFC 3623 Having helped review the original RFC during its draft stage, this draft looks like a sound one but this would probably best be addressed by contacting the original authors of the RFC and co-authoring a revised Graceful OSPF Restart draft rather than having the original one and an "enhancement". Broadcasting this to the list seems like you did not contact them. Just my observations, Don -----Original Message----- From: owner-ospf@PEACH.EASE.LSOFT.COM [mailto:owner-ospf@PEACH.EASE.LSOFT.COM] On Behalf Of sujay Sent: Tuesday, December 06, 2005 10:59 PM To: 'Mailing List' Subject: Gracefu-Restart & RFC 3623 Group, In reference to; Moy, J.,P. Pillay-Esnault,A. Lindem, "Graceful OSPF Restart", RFC 3623, November 2003. There are certain areas which could be worked upon; 1. The conservative behavior of the Restarting router; - in its reaction on reception of any new lsa where it *always* exits the graceful restart, this behavior may be optimized such that the Restarting router exits GR iff the new lsa actually implies a change in the topology 2. A helper router on the presence of non-refresh lsa's in the retransmit list to the restarting router *always* exits as a gr helper - this reaction again can be ratified only if the lsa's actually specify a topology change. 3. The restarting router detects non participating helpers only via the back link checks In the router and network lsa's - this behavior again may lead to network inconsistency for some time, perhaps an explicit notification from the helper router to the restarting router could be thought of. With the above optimizations as well keeping it downwardly compatible, there are a few pointers to rectify (1) and (2) above using "Topology change Lsa's" and (3) using " Exit-Grace LSA TLV" Where in short "Topology change LSA's" is the group of LSA's which *actually* signify a Topology change And "Exit Grace LSA TLV" is an additional TLV in existing Grace LSA which the router may use to indicate Its non-particiation as a helper. The above has been documented at; www.ietf.org/internet-drafts/draft-holla-ospf-update-graceful-restart-00 .txt While the implementation issues is not much of a hassle and there is at least one vendor likely to support it request your views on the same. Sujay etc. From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 08 01:10:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkEzQ-0003jS-0s for ospf-archive@megatron.ietf.org; Thu, 08 Dec 2005 01:10:48 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00869 for ; Thu, 8 Dec 2005 01:09:56 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <0.00004F9E@wildebeest.ease.lsoft.com>; Thu, 8 Dec 2005 1:10:16 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 92955747 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Dec 2005 01:10:17 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 8 Dec 2005 01:10:17 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 07 Dec 2005 22:10:17 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,228,1131350400"; d="scan'208"; a="16828403:sNHT24204772" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB86AE4X009344 for ; Thu, 8 Dec 2005 01:10:14 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 01:10:14 -0500 Received: from [192.168.1.67] ([10.82.216.35]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 01:10:13 -0500 User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <000001c5fba9$5aeb44e0$33666e0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Dec 2005 06:10:13.0569 (UTC) FILETIME=[0D50E310:01C5FBBE] Message-ID: <4397CE43.7030801@cisco.com> Date: Wed, 7 Dec 2005 22:10:11 -0800 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: Gracefu-Restart & RFC 3623 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000001c5fba9$5aeb44e0$33666e0a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit See PPE for comments Abhay D.S wrote: >Importance: Normal >X-Priority: 3 (Normal) >X-MSMail-priority: Normal > > >With a foresight..and with concerns..as a reviewer >for "Update to graceful restart draft". > >Making a case for revisiting standardization: > >Standardization has to be 'revisited' and in the pipeline, since "OSPF >Capabilities" draft which mentions about graceful >Restart capable, helper capable option advertisements >are 'useful' in making Graceful restart more robust. > >The original RFC still lacks the solution for unplanned >restarts. (Do you think this the USP for vendors ?):-| > > > PPE: What ? I beg to differ. What about section 5 - Unplanned Outages ? >OSPF Capabilities draft can address many issues faced >by service providers deploying graceful restart. > >Im also considering the possibility of using a different >OSPF version number for some special scenarios. > >Abhay > > > > > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Don >Goodspeed >Sent: Thursday, December 08, 2005 4:06 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: Gracefu-Restart & RFC 3623 > > >Having helped review the original RFC during its draft >stage, this draft looks like a sound one but this would probably best be >addressed by contacting the original authors of the RFC and >co-authoring a revised Graceful OSPF Restart draft rather than having >the original one and an "enhancement". > >Broadcasting this to the list seems like you did not contact them. > >Just my observations, >Don > >-----Original Message----- >From: owner-ospf@PEACH.EASE.LSOFT.COM >[mailto:owner-ospf@PEACH.EASE.LSOFT.COM] On Behalf Of sujay >Sent: Tuesday, December 06, 2005 10:59 PM >To: 'Mailing List' >Subject: Gracefu-Restart & RFC 3623 > >Group, > >In reference to; >Moy, J.,P. Pillay-Esnault,A. Lindem, "Graceful OSPF Restart", RFC 3623, >November 2003. > >There are certain areas which could be worked upon; > >1. The conservative behavior of the Restarting router; >- in its reaction on reception of any new lsa where it *always* exits >the graceful restart, this behavior may be optimized such that the >Restarting router exits GR iff the new lsa actually implies a change >in the topology > > > PPE : AFAIK Major vendors already implement "non-strict lsa checking" for the restarting router and I have already discussed this on this alias (I seem to recall) way back. I did not agree then for strict-lsa checking and I still don't as it is restrictive. Several reasons In a fairly large topology, it going to be impractical. Is it worth it to exit GR because a acquired a new previously unknown neighbor ? From day 1, my implementation did not support strict lsa checks. The graceful restart implementation report mentions non-strict-lsa-checking as well. This is an implementation decision and does not require helpers to agree on the behavior. >2. A helper router on the presence of non-refresh lsa's in the >retransmit list >to the restarting router *always* exits as a gr helper >- this reaction again can be ratified only if the lsa's actually specify >a topology change. > > PPE : Please see section B2. The RFC already has the non-strict-lsa-checking option - which I believe goes hand in hand - removing strict lsa checking everywhere ( both the GR and helper). At least this was the intention of this author. >3. The restarting router detects non participating helpers only via the >back link checks >In the router and network lsa's >- this behavior again may lead to network inconsistency for some time, >perhaps an explicit >notification from the helper router to the restarting router could be >thought of. > > PPE. Please see 2.1 last sentence. What are you trying to achieve here ? - if there is no helper (router doesn't understand grace or refuses to act as helper) there is no way you are going to achieve graceful restart anyway. - that the rebooting GR router continues to do so is not a problem and you are going to drop packets - just as expected. Are you proposing to stop graceful restart if you cannot achieve it ? What would be the benefit ? as you will then attempt a non-graceful one and drop packets anyway. >With the above optimizations as well keeping it downwardly compatible, >there are a few pointers to rectify (1) and (2) above using "Topology >change Lsa's" and > (3) using " Exit-Grace LSA TLV" > > I don't agree that these optimizations are extensions to the original draft. - (1) non-strict lsa checking is already mentioned - maybe not as clearly as one would wish - (2) -is already mentioned see section B.2 - (3) - see my above comment my 2 cts Padma >Where in short "Topology change LSA's" is the group of LSA's which >*actually* signify a Topology change >And "Exit Grace LSA TLV" is an additional TLV in existing Grace LSA >which the router may use to indicate Its non-particiation as a helper. > >The above has been documented at; >www.ietf.org/internet-drafts/draft-holla-ospf-update-graceful-restart-00 >.txt > >While the implementation issues is not much of a hassle and there is at >least one vendor likely to support it request your views on the same. > >Sujay etc. > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 08 01:42:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkFTx-0001eU-RK for ospf-archive@megatron.ietf.org; Thu, 08 Dec 2005 01:42:22 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03038 for ; Thu, 8 Dec 2005 01:41:29 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <2.00004FA5@wildebeest.ease.lsoft.com>; Thu, 8 Dec 2005 1:41:50 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 92957607 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Dec 2005 01:41:50 -0500 Received: from 61.144.161.53 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 8 Dec 2005 01:41:49 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IR60041G2V14I@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 08 Dec 2005 14:47:25 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IR60032L2V0DL@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 08 Dec 2005 14:47:25 +0800 (CST) Received: from huaweizfbnwhb5 ([10.110.102.51]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IR600A7U33SJ2@szxml01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 08 Dec 2005 14:52:40 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <000101c5fbc2$12021240$33666e0a@china.huawei.com> Date: Thu, 8 Dec 2005 14:38:59 +0800 Reply-To: Mailing List Sender: Mailing List From: "Abhay D.S" Subject: Re: Gracefu-Restart & RFC 3623 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <4397CE43.7030801@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT Addendum... Also look at the RFC's 7th section 7. Possible Future Work Devise a less conservative algorithm for graceful restart helper termination that provides a comparable level of black hole and routing loop avoidance. -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Padma Pillay-Esnault Sent: Thursday, December 08, 2005 2:10 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Gracefu-Restart & RFC 3623 See PPE for comments Abhay D.S wrote: >Importance: Normal >X-Priority: 3 (Normal) >X-MSMail-priority: Normal > > >With a foresight..and with concerns..as a reviewer >for "Update to graceful restart draft". > >Making a case for revisiting standardization: > >Standardization has to be 'revisited' and in the pipeline, since "OSPF >Capabilities" draft which mentions about graceful Restart capable, >helper capable option advertisements are 'useful' in making Graceful >restart more robust. > >The original RFC still lacks the solution for unplanned restarts. (Do >you think this the USP for vendors ?):-| > > > PPE: What ? I beg to differ. What about section 5 - Unplanned Outages ? >OSPF Capabilities draft can address many issues faced >by service providers deploying graceful restart. > >Im also considering the possibility of using a different >OSPF version number for some special scenarios. > >Abhay > > > > > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Don >Goodspeed >Sent: Thursday, December 08, 2005 4:06 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: Gracefu-Restart & RFC 3623 > > >Having helped review the original RFC during its draft >stage, this draft looks like a sound one but this would probably best >be addressed by contacting the original authors of the RFC and >co-authoring a revised Graceful OSPF Restart draft rather than having >the original one and an "enhancement". > >Broadcasting this to the list seems like you did not contact them. > >Just my observations, >Don > >-----Original Message----- >From: owner-ospf@PEACH.EASE.LSOFT.COM >[mailto:owner-ospf@PEACH.EASE.LSOFT.COM] On Behalf Of sujay >Sent: Tuesday, December 06, 2005 10:59 PM >To: 'Mailing List' >Subject: Gracefu-Restart & RFC 3623 > >Group, > >In reference to; >Moy, J.,P. Pillay-Esnault,A. Lindem, "Graceful OSPF Restart", RFC 3623, >November 2003. > >There are certain areas which could be worked upon; > >1. The conservative behavior of the Restarting router; >- in its reaction on reception of any new lsa where it *always* exits >the graceful restart, this behavior may be optimized such that the >Restarting router exits GR iff the new lsa actually implies a change in >the topology > > > PPE : AFAIK Major vendors already implement "non-strict lsa checking" for the restarting router and I have already discussed this on this alias (I seem to recall) way back. I did not agree then for strict-lsa checking and I still don't as it is restrictive. Several reasons In a fairly large topology, it going to be impractical. Is it worth it to exit GR because a acquired a new previously unknown neighbor ? From day 1, my implementation did not support strict lsa checks. The graceful restart implementation report mentions non-strict-lsa-checking as well. This is an implementation decision and does not require helpers to agree on the behavior. >2. A helper router on the presence of non-refresh lsa's in the >retransmit list to the restarting router *always* exits as a gr helper >- this reaction again can be ratified only if the lsa's actually specify >a topology change. > > PPE : Please see section B2. The RFC already has the non-strict-lsa-checking option - which I believe goes hand in hand - removing strict lsa checking everywhere ( both the GR and helper). At least this was the intention of this author. >3. The restarting router detects non participating helpers only via the >back link checks In the router and network lsa's >- this behavior again may lead to network inconsistency for some time, >perhaps an explicit >notification from the helper router to the restarting router could be >thought of. > > PPE. Please see 2.1 last sentence. What are you trying to achieve here ? - if there is no helper (router doesn't understand grace or refuses to act as helper) there is no way you are going to achieve graceful restart anyway. - that the rebooting GR router continues to do so is not a problem and you are going to drop packets - just as expected. Are you proposing to stop graceful restart if you cannot achieve it ? What would be the benefit ? as you will then attempt a non-graceful one and drop packets anyway. >With the above optimizations as well keeping it downwardly compatible, >there are a few pointers to rectify (1) and (2) above using "Topology >change Lsa's" and > (3) using " Exit-Grace LSA TLV" > > I don't agree that these optimizations are extensions to the original draft. - (1) non-strict lsa checking is already mentioned - maybe not as clearly as one would wish - (2) -is already mentioned see section B.2 - (3) - see my above comment my 2 cts Padma >Where in short "Topology change LSA's" is the group of LSA's which >*actually* signify a Topology change >And "Exit Grace LSA TLV" is an additional TLV in existing Grace LSA >which the router may use to indicate Its non-particiation as a helper. > >The above has been documented at; >www.ietf.org/internet-drafts/draft-holla-ospf-update-graceful-restart-0 >0 >.txt > >While the implementation issues is not much of a hassle and there is at >least one vendor likely to support it request your views on the same. > >Sujay etc. > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 08 01:44:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkFVt-00021n-Ne for ospf-archive@megatron.ietf.org; Thu, 08 Dec 2005 01:44:25 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03357 for ; Thu, 8 Dec 2005 01:43:29 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <6.00004F9F@wildebeest.ease.lsoft.com>; Thu, 8 Dec 2005 1:43:50 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 92957702 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Dec 2005 01:43:50 -0500 Received: from 61.144.161.55 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 8 Dec 2005 01:43:49 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IR600BN02O2BF@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 08 Dec 2005 14:43:15 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IR600LZY2O2C4@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 08 Dec 2005 14:43:14 +0800 (CST) Received: from huaweizfbnwhb5 ([10.110.102.51]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IR600ML82VPQU@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 08 Dec 2005 14:47:49 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <000001c5fbc1$e086aeb0$33666e0a@china.huawei.com> Date: Thu, 8 Dec 2005 14:37:36 +0800 Reply-To: Mailing List Sender: Mailing List From: "Abhay D.S" Subject: Re: Gracefu-Restart & RFC 3623 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <4397CE43.7030801@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT Hi Padma !, IMHO. Section 5 has an avoidance approach not preventive. Why ?. Unassuming.. Case X ) Hello packets will be sent eventually to discover some neighbors ,but what if hello packets are received by some routers before they receive the grace LSA.(Only for unplanned case) because of transient network conditions. Case Y) Due to load of neighbors, restart router feels it needs more time to complete Graceful restart. In case of unplanned restart(crash on router processer) Voice over IP call is still running. Do we want to exit Helper mode and get routes down ?. (Case X).Voice call is down. Do you feel OSPF capabilities specification can help provide a solution to ISP ?. Im keeping in mind the options some graph experts had suggested about configuration of exiting helper mode. But that did not cover case X.. Another, Grace period should be able to be changed dynamically, depending on restarting routers load, and period should be derived from a standardized function.(Case y) If I was a ISP operator, I would not refuse all of these .... :-). Abhay -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Padma Pillay-Esnault Sent: Thursday, December 08, 2005 2:10 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Gracefu-Restart & RFC 3623 See PPE for comments Abhay D.S wrote: >Importance: Normal >X-Priority: 3 (Normal) >X-MSMail-priority: Normal > > >With a foresight..and with concerns..as a reviewer >for "Update to graceful restart draft". > >Making a case for revisiting standardization: > >Standardization has to be 'revisited' and in the pipeline, since "OSPF >Capabilities" draft which mentions about graceful Restart capable, >helper capable option advertisements are 'useful' in making Graceful >restart more robust. > >The original RFC still lacks the solution for unplanned restarts. (Do >you think this the USP for vendors ?):-| > > > PPE: What ? I beg to differ. What about section 5 - Unplanned Outages ? >OSPF Capabilities draft can address many issues faced >by service providers deploying graceful restart. > >Im also considering the possibility of using a different >OSPF version number for some special scenarios. > >Abhay > > > > > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Don >Goodspeed >Sent: Thursday, December 08, 2005 4:06 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: Gracefu-Restart & RFC 3623 > > >Having helped review the original RFC during its draft >stage, this draft looks like a sound one but this would probably best >be addressed by contacting the original authors of the RFC and >co-authoring a revised Graceful OSPF Restart draft rather than having >the original one and an "enhancement". > >Broadcasting this to the list seems like you did not contact them. > >Just my observations, >Don > >-----Original Message----- >From: owner-ospf@PEACH.EASE.LSOFT.COM >[mailto:owner-ospf@PEACH.EASE.LSOFT.COM] On Behalf Of sujay >Sent: Tuesday, December 06, 2005 10:59 PM >To: 'Mailing List' >Subject: Gracefu-Restart & RFC 3623 > >Group, > >In reference to; >Moy, J.,P. Pillay-Esnault,A. Lindem, "Graceful OSPF Restart", RFC 3623, >November 2003. > >There are certain areas which could be worked upon; > >1. The conservative behavior of the Restarting router; >- in its reaction on reception of any new lsa where it *always* exits >the graceful restart, this behavior may be optimized such that the >Restarting router exits GR iff the new lsa actually implies a change in >the topology > > > PPE : AFAIK Major vendors already implement "non-strict lsa checking" for the restarting router and I have already discussed this on this alias (I seem to recall) way back. I did not agree then for strict-lsa checking and I still don't as it is restrictive. Several reasons In a fairly large topology, it going to be impractical. Is it worth it to exit GR because a acquired a new previously unknown neighbor ? From day 1, my implementation did not support strict lsa checks. The graceful restart implementation report mentions non-strict-lsa-checking as well. This is an implementation decision and does not require helpers to agree on the behavior. >2. A helper router on the presence of non-refresh lsa's in the >retransmit list to the restarting router *always* exits as a gr helper >- this reaction again can be ratified only if the lsa's actually specify >a topology change. > > PPE : Please see section B2. The RFC already has the non-strict-lsa-checking option - which I believe goes hand in hand - removing strict lsa checking everywhere ( both the GR and helper). At least this was the intention of this author. >3. The restarting router detects non participating helpers only via the >back link checks In the router and network lsa's >- this behavior again may lead to network inconsistency for some time, >perhaps an explicit >notification from the helper router to the restarting router could be >thought of. > > PPE. Please see 2.1 last sentence. What are you trying to achieve here ? - if there is no helper (router doesn't understand grace or refuses to act as helper) there is no way you are going to achieve graceful restart anyway. - that the rebooting GR router continues to do so is not a problem and you are going to drop packets - just as expected. Are you proposing to stop graceful restart if you cannot achieve it ? What would be the benefit ? as you will then attempt a non-graceful one and drop packets anyway. >With the above optimizations as well keeping it downwardly compatible, >there are a few pointers to rectify (1) and (2) above using "Topology >change Lsa's" and > (3) using " Exit-Grace LSA TLV" > > I don't agree that these optimizations are extensions to the original draft. - (1) non-strict lsa checking is already mentioned - maybe not as clearly as one would wish - (2) -is already mentioned see section B.2 - (3) - see my above comment my 2 cts Padma >Where in short "Topology change LSA's" is the group of LSA's which >*actually* signify a Topology change >And "Exit Grace LSA TLV" is an additional TLV in existing Grace LSA >which the router may use to indicate Its non-particiation as a helper. > >The above has been documented at; >www.ietf.org/internet-drafts/draft-holla-ospf-update-graceful-restart-0 >0 >.txt > >While the implementation issues is not much of a hassle and there is at >least one vendor likely to support it request your views on the same. > >Sujay etc. > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 08 02:03:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkFoB-0005eG-AK for ospf-archive@megatron.ietf.org; Thu, 08 Dec 2005 02:03:18 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05210 for ; Thu, 8 Dec 2005 02:02:20 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <7.00004F9E@wildebeest.ease.lsoft.com>; Thu, 8 Dec 2005 2:02:41 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 92958503 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Dec 2005 02:02:41 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 8 Dec 2005 02:02:41 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 08 Dec 2005 02:02:41 -0500 X-IronPort-AV: i="3.99,228,1131339600"; d="scan'208"; a="77363755:sNHT33006392" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB872c4X014890 for ; Thu, 8 Dec 2005 02:02:39 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 02:02:38 -0500 Received: from [192.168.1.67] ([10.82.216.35]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 02:02:38 -0500 User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <000001c5fbc1$e086aeb0$33666e0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Dec 2005 07:02:38.0276 (UTC) FILETIME=[5FB51840:01C5FBC5] Message-ID: <4397DA8F.5070204@cisco.com> Date: Wed, 7 Dec 2005 23:02:39 -0800 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: Gracefu-Restart & RFC 3623 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000001c5fbc1$e086aeb0$33666e0a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Abhay D.S wrote: >Hi Padma !, >IMHO. >Section 5 has an avoidance approach not preventive. > > Humm ... You said there is "no" support - and now you say it is avoidance. I missing something. Not sure I understand what is avoidance and what is preventive ? Can you prevent/avoid a crash ? :-) >Why ?. >Unassuming.. >Case X ) Hello packets will be sent eventually to discover some >neighbors ,but what if hello packets are received by >some routers before they receive the grace LSA.(Only for >unplanned case) because of transient network conditions. > > Why would only the grace lsas ( BTW we do send several of them wait before sending hellos - discussed on this alias in 2001 I believe) get dropped and not the subsequent hello packets ? Makes me think of a french proverb "With a lot of ifs you can put Paris in a bottle ...." These are local link scope - how can you expect the hellos to jump ahead of the grace lsa if you implemented it not to be so - unless you have a buggy implementation. >Case Y) Due to load of neighbors, restart router feels it needs >more time to complete Graceful restart. > > > The router does not feel - you configure it :-) >In case of unplanned restart(crash on router processer) >Voice over IP call is still running. Do we want to exit >Helper mode and get routes down ?. (Case X).Voice call >is down. > > > I am missing your point ..... Unlikely case X ( hellos ahead of grace) and the helper exit - why ? >Do you feel OSPF capabilities specification can help provide >a solution to ISP ?. Im keeping in mind the options some graph >experts had suggested about configuration of exiting helper mode. >But that did not cover case X.. > >Another, Grace period should be able to be changed >dynamically, depending on restarting routers load, and period should >be derived from a standardized function.(Case y) > > > > Actually GR can configured to be a very long period and a good implementation will get end as soon as it is ready. This is the approach in my implementation, let's call it intuitively dynamic and you don't even have to add extra config. >If I was a ISP operator, I would not refuse all of these .... :-). > > I think you already have these :-) Padma >Abhay > > > > > > > > > > > > > > > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Padma >Pillay-Esnault >Sent: Thursday, December 08, 2005 2:10 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: Gracefu-Restart & RFC 3623 > > >See PPE for comments > >Abhay D.S wrote: > > > >>Importance: Normal >>X-Priority: 3 (Normal) >>X-MSMail-priority: Normal >> >> >>With a foresight..and with concerns..as a reviewer >>for "Update to graceful restart draft". >> >>Making a case for revisiting standardization: >> >>Standardization has to be 'revisited' and in the pipeline, since "OSPF >>Capabilities" draft which mentions about graceful Restart capable, >>helper capable option advertisements are 'useful' in making Graceful >>restart more robust. >> >>The original RFC still lacks the solution for unplanned restarts. (Do >>you think this the USP for vendors ?):-| >> >> >> >> >> >PPE: > >What ? I beg to differ. > >What about section 5 - Unplanned Outages ? > > > >>OSPF Capabilities draft can address many issues faced >>by service providers deploying graceful restart. >> >>Im also considering the possibility of using a different >>OSPF version number for some special scenarios. >> >>Abhay >> >> >> >> >> >>-----Original Message----- >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Don >>Goodspeed >>Sent: Thursday, December 08, 2005 4:06 AM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Re: Gracefu-Restart & RFC 3623 >> >> >>Having helped review the original RFC during its draft >>stage, this draft looks like a sound one but this would probably best >>be addressed by contacting the original authors of the RFC and >>co-authoring a revised Graceful OSPF Restart draft rather than having >>the original one and an "enhancement". >> >>Broadcasting this to the list seems like you did not contact them. >> >>Just my observations, >>Don >> >>-----Original Message----- >>From: owner-ospf@PEACH.EASE.LSOFT.COM >>[mailto:owner-ospf@PEACH.EASE.LSOFT.COM] On Behalf Of sujay >>Sent: Tuesday, December 06, 2005 10:59 PM >>To: 'Mailing List' >>Subject: Gracefu-Restart & RFC 3623 >> >>Group, >> >>In reference to; >>Moy, J.,P. Pillay-Esnault,A. Lindem, "Graceful OSPF Restart", RFC 3623, >> >> > > > >>November 2003. >> >>There are certain areas which could be worked upon; >> >>1. The conservative behavior of the Restarting router; >>- in its reaction on reception of any new lsa where it *always* exits >>the graceful restart, this behavior may be optimized such that the >>Restarting router exits GR iff the new lsa actually implies a change in >> >> > > > >>the topology >> >> >> >> >> >PPE : > > >AFAIK Major vendors already implement "non-strict lsa checking" for the >restarting router and I have >already discussed this on this alias (I seem to recall) way back. I did >not agree then for strict-lsa checking and I still don't as it is >restrictive. > >Several reasons >In a fairly large topology, it going to be impractical. >Is it worth it to exit GR because a acquired a new previously unknown >neighbor ? > > From day 1, my implementation did not support strict lsa checks. The >graceful restart implementation report mentions >non-strict-lsa-checking as well. > >This is an implementation decision and does not require helpers to agree > >on the behavior. > > > >>2. A helper router on the presence of non-refresh lsa's in the >>retransmit list to the restarting router *always* exits as a gr helper >>- this reaction again can be ratified only if the lsa's actually >> >> >specify > > >>a topology change. >> >> >> >> > >PPE : >Please see section B2. > >The RFC already has the non-strict-lsa-checking option - which I believe > >goes hand in hand - removing strict lsa checking everywhere ( both the >GR and helper). At least this was the intention of this author. > > > >>3. The restarting router detects non participating helpers only via the >> >> > > > >>back link checks In the router and network lsa's >>- this behavior again may lead to network inconsistency for some time, >>perhaps an explicit >>notification from the helper router to the restarting router could be >>thought of. >> >> >> >> > >PPE. > >Please see 2.1 last sentence. > >What are you trying to achieve here ? >- if there is no helper (router doesn't understand grace or refuses to >act as helper) >there is no way you are going to achieve graceful restart anyway. >- that the rebooting GR router continues to do so is not a problem and >you are going to drop >packets - just as expected. > >Are you proposing to stop graceful restart if you cannot achieve it ? >What would be the benefit ? >as you will then attempt a non-graceful one and drop packets anyway. > > > >>With the above optimizations as well keeping it downwardly compatible, >>there are a few pointers to rectify (1) and (2) above using "Topology >>change Lsa's" and >>(3) using " Exit-Grace LSA TLV" >> >> >> >> >I don't agree that these optimizations are extensions to the original >draft. > >- (1) non-strict lsa checking is already mentioned - maybe not as >clearly as one would wish >- (2) -is already mentioned see section B.2 >- (3) - see my above comment > >my 2 cts > >Padma > > > >>Where in short "Topology change LSA's" is the group of LSA's which >>*actually* signify a Topology change >>And "Exit Grace LSA TLV" is an additional TLV in existing Grace LSA >>which the router may use to indicate Its non-particiation as a helper. >> >>The above has been documented at; >>www.ietf.org/internet-drafts/draft-holla-ospf-update-graceful-restart-0 >>0 >>.txt >> >>While the implementation issues is not much of a hassle and there is at >> >> > > > >>least one vendor likely to support it request your views on the same. >> >>Sujay etc. >> >> >> >> >> >> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 08 02:48:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkGVU-0006N2-TB for ospf-archive@megatron.ietf.org; Thu, 08 Dec 2005 02:48:00 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08759 for ; Thu, 8 Dec 2005 02:47:08 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <12.00004FA1@wildebeest.ease.lsoft.com>; Thu, 8 Dec 2005 2:47:28 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 92960292 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Dec 2005 02:47:28 -0500 Received: from 61.144.161.55 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 8 Dec 2005 02:47:27 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IR6002LA5NU1E@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 08 Dec 2005 15:47:54 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IR600LD05NTC4@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 08 Dec 2005 15:47:54 +0800 (CST) Received: from dell60 ([10.18.4.57]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IR6001L55VGJ3@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 08 Dec 2005 15:52:29 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <000001c5fbca$e88d0a10$3904120a@china.huawei.com> Date: Thu, 8 Dec 2005 13:12:14 +0530 Reply-To: Mailing List Sender: Mailing List From: sujay Subject: Re: Gracefu-Restart & RFC 3623 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <4397CE43.7030801@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT The RFC being the base, has room for improvements, no wonder WG's and mailing lists ! Please See comments Inline SUJ> -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Padma Pillay-Esnault Sent: Thursday, December 08, 2005 11:40 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Gracefu-Restart & RFC 3623 See PPE for comments Abhay D.S wrote: >Importance: Normal >X-Priority: 3 (Normal) >X-MSMail-priority: Normal > > >With a foresight..and with concerns..as a reviewer >for "Update to graceful restart draft". > >Making a case for revisiting standardization: > >Standardization has to be 'revisited' and in the pipeline, since "OSPF >Capabilities" draft which mentions about graceful Restart capable, >helper capable option advertisements are 'useful' in making Graceful >restart more robust. > >The original RFC still lacks the solution for unplanned restarts. (Do >you think this the USP for vendors ?):-| > > > PPE: What ? I beg to differ. What about section 5 - Unplanned Outages ? SUJ> here I guess the issue is, section 5 still has room for work, 'future work' on 3623. >OSPF Capabilities draft can address many issues faced >by service providers deploying graceful restart. > >Im also considering the possibility of using a different >OSPF version number for some special scenarios. > >Abhay > > > > > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Don >Goodspeed >Sent: Thursday, December 08, 2005 4:06 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: Gracefu-Restart & RFC 3623 > > >Having helped review the original RFC during its draft >stage, this draft looks like a sound one but this would probably best >be addressed by contacting the original authors of the RFC and >co-authoring a revised Graceful OSPF Restart draft rather than having >the original one and an "enhancement". > >Broadcasting this to the list seems like you did not contact them. > >Just my observations, >Don > >-----Original Message----- >From: owner-ospf@PEACH.EASE.LSOFT.COM >[mailto:owner-ospf@PEACH.EASE.LSOFT.COM] On Behalf Of sujay >Sent: Tuesday, December 06, 2005 10:59 PM >To: 'Mailing List' >Subject: Gracefu-Restart & RFC 3623 > >Group, > >In reference to; >Moy, J.,P. Pillay-Esnault,A. Lindem, "Graceful OSPF Restart", RFC 3623, >November 2003. > >There are certain areas which could be worked upon; > >1. The conservative behavior of the Restarting router; >- in its reaction on reception of any new lsa where it *always* exits >the graceful restart, this behavior may be optimized such that the >Restarting router exits GR iff the new lsa actually implies a change in >the topology > > > PPE : AFAIK Major vendors already implement "non-strict lsa checking" for the restarting router and I have already discussed this on this alias (I seem to recall) way back. I did not agree then for strict-lsa checking and I still don't as it is restrictive. Several reasons In a fairly large topology, it going to be impractical. Is it worth it to exit GR because a acquired a new previously unknown neighbor ? From day 1, my implementation did not support strict lsa checks. The graceful restart implementation report mentions non-strict-lsa-checking as well. This is an implementation decision and does not require helpers to agree on the behavior. SUJ> IMHO the strict lsa checking option has been provided for in the helper in 3623, not the restarting router See section 3.2, B.2, Considering even it for the restarting router (and the helper), the concept of a 'changed lsa' is too wide. It has been tightly defined with the category as "Topology change LSA's" in the draft. There are quite a few cases Where for a 'changed lsa' is not truly a qualifier for Changing the GR environment ! >2. A helper router on the presence of non-refresh lsa's in the >retransmit list to the restarting router *always* exits as a gr helper >- this reaction again can be ratified only if the lsa's actually specify >a topology change. > > PPE : Please see section B2. The RFC already has the non-strict-lsa-checking option - which I believe goes hand in hand - removing strict lsa checking everywhere ( both the GR and helper). At least this was the intention of this author. SUJ> Please see above comments. >3. The restarting router detects non participating helpers only via the >back link checks In the router and network lsa's >- this behavior again may lead to network inconsistency for some time, >perhaps an explicit >notification from the helper router to the restarting router could be >thought of. > > PPE. Please see 2.1 last sentence. What are you trying to achieve here ? - if there is no helper (router doesn't understand grace or refuses to act as helper) there is no way you are going to achieve graceful restart anyway. SUJ> the point is of knowing the non-participation of *any* helper asap, and getting out of GR Needless to say it serves the common goal of detecting blackholes and routing loops asap - that the rebooting GR router continues to do so is not a problem and you are going to drop packets - just as expected. Are you proposing to stop graceful restart if you cannot achieve it ? What would be the benefit ? as you will then attempt a non-graceful one and drop packets anyway. >With the above optimizations as well keeping it downwardly compatible, >there are a few pointers to rectify (1) and (2) above using "Topology >change Lsa's" and > (3) using " Exit-Grace LSA TLV" > > I don't agree that these optimizations are extensions to the original draft. - (1) non-strict lsa checking is already mentioned - maybe not as clearly as one would wish - (2) -is already mentioned see section B.2 - (3) - see my above comment my 2 cts Padma SUJ> To summarize: 1. The draft in short defines certain elements more clearly and exact. 2. It makes the definitions more terse, specifications exact. 3. It is backwardly compatible with the "large vendors" as reported in the 'graceful restart implementation report' 4. It is an addition over and above the 3623 and nothing out of the blue ! >Where in short "Topology change LSA's" is the group of LSA's which >*actually* signify a Topology change >And "Exit Grace LSA TLV" is an additional TLV in existing Grace LSA >which the router may use to indicate Its non-particiation as a helper. > >The above has been documented at; >www.ietf.org/internet-drafts/draft-holla-ospf-update-graceful-restart-0 >0 >.txt > >While the implementation issues is not much of a hassle and there is at >least one vendor likely to support it request your views on the same. > >Sujay etc. > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 08 02:51:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkGYZ-00075E-6G for ospf-archive@megatron.ietf.org; Thu, 08 Dec 2005 02:51:11 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09105 for ; Thu, 8 Dec 2005 02:50:18 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <3.00004F9D@wildebeest.ease.lsoft.com>; Thu, 8 Dec 2005 2:50:40 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 92960455 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Dec 2005 02:50:40 -0500 Received: from 61.144.161.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 8 Dec 2005 02:50:37 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IR6005IA5UQ3Z@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 08 Dec 2005 15:52:03 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IR6003TC5UQFE@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 08 Dec 2005 15:52:02 +0800 (CST) Received: from huaweizfbnwhb5 ([10.110.102.51]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IR600MKO5UHQU@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 08 Dec 2005 15:51:53 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <000201c5fbca$d36bf380$33666e0a@china.huawei.com> Date: Thu, 8 Dec 2005 15:41:39 +0800 Reply-To: Mailing List Sender: Mailing List From: "Abhay D.S" Subject: Re: Gracefu-Restart & RFC 3623 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <4397DA8F.5070204@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT Hi padma !. Your proverbs are enjoyable ! :-). However, please read inline and think im your customer !(ends at the moment we start thinking about revisiting standardization). -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Padma Pillay-Esnault Sent: Thursday, December 08, 2005 3:03 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Gracefu-Restart & RFC 3623 Abhay D.S wrote: >Hi Padma !, >IMHO. >Section 5 has an avoidance approach not preventive. > > Yes there is "no" support. Humm ... You said there is "no" support - and now you say it is avoidance. I missing something. Not sure I understand what is avoidance and what is preventive ? Can you prevent/avoid a crash ? :-) Abhay)) Yes RFC does not have a mechanism to prevent neighbors from getting down due to receiving hello. Do you remember the robustness variable ?(This is what is avoidance).(Hope you understand and not mislead yourself into thinking what RFC says is perfect,everybody loves their babies). Unplanned restart: Why do you think grace LSA cannot be dropped and hello packets be received in case of unplanned restart,we have still not discovered our neighbors. In planned case I agree that grace LSA's will be received by all neighbors before sending hello. >Why ?. >Unassuming.. >Case X ) Hello packets will be sent eventually to discover some >neighbors ,but what if hello packets are received by some routers >before they receive the grace LSA.(Only for unplanned case) because of >transient network conditions. > > Why would only the grace lsas ( BTW we do send several of them wait before sending hellos - discussed on this alias in 2001 I believe) get dropped and not the subsequent hello packets ? Makes me think of a french proverb "With a lot of ifs you can put Paris in a bottle ...." These are local link scope - how can you expect the hellos to jump ahead of the grace lsa if you implemented it not to be so - unless you have a buggy implementation. Abhay)) You must have heard about packet being dropped(it is justified in draft,sending several times), and about priority handling of hello packets. (suggested by folks at AT&T). >Case Y) Due to load of neighbors, restart router feels it needs more >time to complete Graceful restart. > > > The router does not feel - you configure it :-) Abhay)) I need an router with extra intelligence. As you know that GR deployment is critical in PE's. Feeling is better than configuring it and then saying sorry "we will come up with something soon, I beg you". Configuration is for stable toplogies. >In case of unplanned restart(crash on router processer) >Voice over IP call is still running. Do we want to exit >Helper mode and get routes down ?. (Case X).Voice call >is down. > > > I am missing your point ..... Unlikely case X ( hellos ahead of grace) and the helper exit - why ? Abhay)) It is possible in unplanned case, think more....see reason given Above. >Do you feel OSPF capabilities specification can help provide >a solution to ISP ?. Im keeping in mind the options some graph experts >had suggested about configuration of exiting helper mode. But that did >not cover case X.. > >Another, Grace period should be able to be changed dynamically, >depending on restarting routers load, and period should be derived from >a standardized function.(Case y) > > > > Actually GR can configured to be a very long period and a good implementation will get end as soon as it is ready. This is the approach in my implementation, let's call it intuitively dynamic and you don't even have to add extra config. Abhay)) Do you think all vendors run the same type of mechanisms ?. But just above you said it can be configured ??. >If I was a ISP operator, I would not refuse all of these .... :-). > > I think you already have these :-) Padma Abhay)) Im still not satisfied, I cannot buy your RFC. :-). Please improve section 5 and I will think about it. >Abhay > > > > > > > > > > > > > > > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >Padma Pillay-Esnault >Sent: Thursday, December 08, 2005 2:10 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: Gracefu-Restart & RFC 3623 > > >See PPE for comments > >Abhay D.S wrote: > > > >>Importance: Normal >>X-Priority: 3 (Normal) >>X-MSMail-priority: Normal >> >> >>With a foresight..and with concerns..as a reviewer >>for "Update to graceful restart draft". >> >>Making a case for revisiting standardization: >> >>Standardization has to be 'revisited' and in the pipeline, since "OSPF >>Capabilities" draft which mentions about graceful Restart capable, >>helper capable option advertisements are 'useful' in making Graceful >>restart more robust. >> >>The original RFC still lacks the solution for unplanned restarts. (Do >>you think this the USP for vendors ?):-| >> >> >> >> >> >PPE: > >What ? I beg to differ. > >What about section 5 - Unplanned Outages ? > > > >>OSPF Capabilities draft can address many issues faced >>by service providers deploying graceful restart. >> >>Im also considering the possibility of using a different >>OSPF version number for some special scenarios. >> >>Abhay >> >> >> >> >> >>-----Original Message----- >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Don >>Goodspeed >>Sent: Thursday, December 08, 2005 4:06 AM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Re: Gracefu-Restart & RFC 3623 >> >> >>Having helped review the original RFC during its draft >>stage, this draft looks like a sound one but this would probably best >>be addressed by contacting the original authors of the RFC and >>co-authoring a revised Graceful OSPF Restart draft rather than having >>the original one and an "enhancement". >> >>Broadcasting this to the list seems like you did not contact them. >> >>Just my observations, >>Don >> >>-----Original Message----- >>From: owner-ospf@PEACH.EASE.LSOFT.COM >>[mailto:owner-ospf@PEACH.EASE.LSOFT.COM] On Behalf Of sujay >>Sent: Tuesday, December 06, 2005 10:59 PM >>To: 'Mailing List' >>Subject: Gracefu-Restart & RFC 3623 >> >>Group, >> >>In reference to; >>Moy, J.,P. Pillay-Esnault,A. Lindem, "Graceful OSPF Restart", RFC >>3623, >> >> > > > >>November 2003. >> >>There are certain areas which could be worked upon; >> >>1. The conservative behavior of the Restarting router; >>- in its reaction on reception of any new lsa where it *always* exits >>the graceful restart, this behavior may be optimized such that the >>Restarting router exits GR iff the new lsa actually implies a change in >> >> > > > >>the topology >> >> >> >> >> >PPE : > > >AFAIK Major vendors already implement "non-strict lsa checking" for the >restarting router and I have >already discussed this on this alias (I seem to recall) way back. I did >not agree then for strict-lsa checking and I still don't as it is >restrictive. > >Several reasons >In a fairly large topology, it going to be impractical. >Is it worth it to exit GR because a acquired a new previously unknown >neighbor ? > > From day 1, my implementation did not support strict lsa checks. The >graceful restart implementation report mentions non-strict-lsa-checking >as well. > >This is an implementation decision and does not require helpers to >agree > >on the behavior. > > > >>2. A helper router on the presence of non-refresh lsa's in the >>retransmit list to the restarting router *always* exits as a gr helper >>- this reaction again can be ratified only if the lsa's actually >> >> >specify > > >>a topology change. >> >> >> >> > >PPE : >Please see section B2. > >The RFC already has the non-strict-lsa-checking option - which I >believe > >goes hand in hand - removing strict lsa checking everywhere ( both the >GR and helper). At least this was the intention of this author. > > > >>3. The restarting router detects non participating helpers only via >>the >> >> > > > >>back link checks In the router and network lsa's >>- this behavior again may lead to network inconsistency for some time, >>perhaps an explicit notification from the helper router to the >>restarting router could be thought of. >> >> >> >> > >PPE. > >Please see 2.1 last sentence. > >What are you trying to achieve here ? >- if there is no helper (router doesn't understand grace or refuses to >act as helper) >there is no way you are going to achieve graceful restart anyway. >- that the rebooting GR router continues to do so is not a problem and >you are going to drop >packets - just as expected. > >Are you proposing to stop graceful restart if you cannot achieve it ? >What would be the benefit ? >as you will then attempt a non-graceful one and drop packets anyway. > > > >>With the above optimizations as well keeping it downwardly compatible, >>there are a few pointers to rectify (1) and (2) above using "Topology >>change Lsa's" and >>(3) using " Exit-Grace LSA TLV" >> >> >> >> >I don't agree that these optimizations are extensions to the original >draft. > >- (1) non-strict lsa checking is already mentioned - maybe not as >clearly as one would wish >- (2) -is already mentioned see section B.2 >- (3) - see my above comment > >my 2 cts > >Padma > > > >>Where in short "Topology change LSA's" is the group of LSA's which >>*actually* signify a Topology change >>And "Exit Grace LSA TLV" is an additional TLV in existing Grace LSA >>which the router may use to indicate Its non-particiation as a helper. >> >>The above has been documented at; >>www.ietf.org/internet-drafts/draft-holla-ospf-update-graceful-restart- 0 >>0 >>.txt >> >>While the implementation issues is not much of a hassle and there is >>at >> >> > > > >>least one vendor likely to support it request your views on the same. >> >>Sujay etc. >> >> >> >> >> >> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 08 03:03:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkGkn-000106-Sj for ospf-archive@megatron.ietf.org; Thu, 08 Dec 2005 03:03:50 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09866 for ; Thu, 8 Dec 2005 03:02:57 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <7.00004FA2@wildebeest.ease.lsoft.com>; Thu, 8 Dec 2005 3:03:18 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 92960916 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Dec 2005 03:03:19 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 8 Dec 2005 03:03:19 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 08 Dec 2005 03:03:18 -0500 X-IronPort-AV: i="3.99,228,1131339600"; d="scan'208"; a="77365362:sNHT33851364" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jB883GUR023182 for ; Thu, 8 Dec 2005 03:03:16 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 03:03:16 -0500 Received: from [192.168.1.67] ([10.82.216.35]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 03:03:14 -0500 User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <000001c5fbca$e88d0a10$3904120a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Dec 2005 08:03:14.0331 (UTC) FILETIME=[D6F70EB0:01C5FBCD] Message-ID: <4397E8C2.504@cisco.com> Date: Thu, 8 Dec 2005 00:03:14 -0800 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: Gracefu-Restart & RFC 3623 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000001c5fbca$e88d0a10$3904120a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit See PPE for comments sujay wrote: >The RFC being the base, has room for improvements, >no wonder WG's and mailing lists ! > > >Please See comments Inline >SUJ> > > > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Padma >Pillay-Esnault >Sent: Thursday, December 08, 2005 11:40 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: Gracefu-Restart & RFC 3623 > > >See PPE for comments > >Abhay D.S wrote: > > > >>Importance: Normal >>X-Priority: 3 (Normal) >>X-MSMail-priority: Normal >> >> >>With a foresight..and with concerns..as a reviewer >>for "Update to graceful restart draft". >> >>Making a case for revisiting standardization: >> >>Standardization has to be 'revisited' and in the pipeline, since "OSPF >>Capabilities" draft which mentions about graceful Restart capable, >>helper capable option advertisements are 'useful' in making Graceful >>restart more robust. >> >>The original RFC still lacks the solution for unplanned restarts. (Do >>you think this the USP for vendors ?):-| >> >> >> >> >> >PPE: > >What ? I beg to differ. > >What about section 5 - Unplanned Outages ? > >SUJ> here I guess the issue is, section 5 still has room for work, >'future work' on 3623. > > > PPE - I have yet to see those :-) >>OSPF Capabilities draft can address many issues faced >>by service providers deploying graceful restart. >> >>Im also considering the possibility of using a different >>OSPF version number for some special scenarios. >> >>Abhay >> >> >> >> >> >>-----Original Message----- >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Don >>Goodspeed >>Sent: Thursday, December 08, 2005 4:06 AM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Re: Gracefu-Restart & RFC 3623 >> >> >>Having helped review the original RFC during its draft >>stage, this draft looks like a sound one but this would probably best >>be addressed by contacting the original authors of the RFC and >>co-authoring a revised Graceful OSPF Restart draft rather than having >>the original one and an "enhancement". >> >>Broadcasting this to the list seems like you did not contact them. >> >>Just my observations, >>Don >> >>-----Original Message----- >>From: owner-ospf@PEACH.EASE.LSOFT.COM >>[mailto:owner-ospf@PEACH.EASE.LSOFT.COM] On Behalf Of sujay >>Sent: Tuesday, December 06, 2005 10:59 PM >>To: 'Mailing List' >>Subject: Gracefu-Restart & RFC 3623 >> >>Group, >> >>In reference to; >>Moy, J.,P. Pillay-Esnault,A. Lindem, "Graceful OSPF Restart", RFC 3623, >> >> > > > >>November 2003. >> >>There are certain areas which could be worked upon; >> >>1. The conservative behavior of the Restarting router; >>- in its reaction on reception of any new lsa where it *always* exits >>the graceful restart, this behavior may be optimized such that the >>Restarting router exits GR iff the new lsa actually implies a change in >> >> > > > >>the topology >> >> >> >> >> >PPE : > > >AFAIK Major vendors already implement "non-strict lsa checking" for the >restarting router and I have >already discussed this on this alias (I seem to recall) way back. I did >not agree then for strict-lsa checking and I still don't as it is >restrictive. > >Several reasons >In a fairly large topology, it going to be impractical. >Is it worth it to exit GR because a acquired a new previously unknown >neighbor ? > > From day 1, my implementation did not support strict lsa checks. The >graceful restart implementation report mentions >non-strict-lsa-checking as well. > >This is an implementation decision and does not require helpers to agree > >on the behavior. > > >SUJ> IMHO the strict lsa checking option has been provided for in the >helper in 3623, not the restarting router >See section 3.2, B.2, >Considering even it for the restarting router (and the helper), the >concept of a 'changed lsa' is too wide. >It has been tightly defined with the category as "Topology change LSA's" >in the draft. There are quite a few cases >Where for a 'changed lsa' is not truly a qualifier for Changing the GR >environment ! > > > PPE - As I said before, if you have a helper who does not perform strict lsa checking and floods it to a router with strict lsa checking - this won't work. So to me mention of this couples it for both restarting and helper routers. What you are describing already is done in most implementation using common sense. It is actually documenting what implementations have already done individually. This is where I think these are not extensions but exposing implementation details about common sense. > > >>2. A helper router on the presence of non-refresh lsa's in the >>retransmit list to the restarting router *always* exits as a gr helper >>- this reaction again can be ratified only if the lsa's actually >> >> >specify > > >>a topology change. >> >> >> >> > >PPE : >Please see section B2. > >The RFC already has the non-strict-lsa-checking option - which I believe > >goes hand in hand - removing strict lsa checking everywhere ( both the >GR and helper). At least this was the intention of this author. > >SUJ> Please see above comments. > > PPE - see above - it does not make sense to have a mix and match of restart and helper routers regarding strictlsachecking. The wording might not be great but it really implicitly mean for both. > > >>3. The restarting router detects non participating helpers only via the >> >> > > > >>back link checks In the router and network lsa's >>- this behavior again may lead to network inconsistency for some time, >>perhaps an explicit >>notification from the helper router to the restarting router could be >>thought of. >> >> >> >> > >PPE. > >Please see 2.1 last sentence. > >What are you trying to achieve here ? >- if there is no helper (router doesn't understand grace or refuses to >act as helper) >there is no way you are going to achieve graceful restart anyway. > >SUJ> the point is of knowing the non-participation of *any* helper asap, >and getting out of GR >Needless to say it serves the common goal of detecting blackholes and >routing loops asap > > > PPE I don't think that you responded to my question .... You are going to drop packets anyway and I hardly see how you are going to figure out just by exchange of info of helper capability whether you are going to have less blackhole/loop with or without GR. see below Padma >- that the rebooting GR router continues to do so is not a problem and >you are going to drop >packets - just as expected. > > > > > >Are you proposing to stop graceful restart if you cannot achieve it ? >What would be the benefit ? >as you will then attempt a non-graceful one and drop packets anyway. > > > >>With the above optimizations as well keeping it downwardly compatible, >>there are a few pointers to rectify (1) and (2) above using "Topology >>change Lsa's" and >>(3) using " Exit-Grace LSA TLV" >> >> >> >> >I don't agree that these optimizations are extensions to the original >draft. > >- (1) non-strict lsa checking is already mentioned - maybe not as >clearly as one would wish >- (2) -is already mentioned see section B.2 >- (3) - see my above comment > >my 2 cts > >Padma > > > > >SUJ> To summarize: >1. The draft in short defines certain elements more clearly and exact. >2. It makes the definitions more terse, specifications exact. >3. It is backwardly compatible with the "large vendors" as reported in >the 'graceful restart implementation report' >4. It is an addition over and above the 3623 and nothing out of the blue >! > > > > > >>Where in short "Topology change LSA's" is the group of LSA's which >>*actually* signify a Topology change >>And "Exit Grace LSA TLV" is an additional TLV in existing Grace LSA >>which the router may use to indicate Its non-particiation as a helper. >> >>The above has been documented at; >>www.ietf.org/internet-drafts/draft-holla-ospf-update-graceful-restart-0 >>0 >>.txt >> >>While the implementation issues is not much of a hassle and there is at >> >> > > > >>least one vendor likely to support it request your views on the same. >> >>Sujay etc. >> >> >> >> >> >> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 08 03:34:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkHEw-000789-Kn for ospf-archive@megatron.ietf.org; Thu, 08 Dec 2005 03:34:58 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12632 for ; Thu, 8 Dec 2005 03:34:05 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <5.00004FC1@wildebeest.ease.lsoft.com>; Thu, 8 Dec 2005 3:34:27 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 92963271 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Dec 2005 03:34:27 -0500 Received: from 61.144.161.55 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 8 Dec 2005 03:34:25 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IR600D107W7IY@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 08 Dec 2005 16:36:08 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IR600B1E7W56D@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 08 Dec 2005 16:36:07 +0800 (CST) Received: from dell60 ([10.18.4.57]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IR600CM389KQA@szxml01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 08 Dec 2005 16:44:09 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <000001c5fbd1$a484cb30$3904120a@china.huawei.com> Date: Thu, 8 Dec 2005 14:00:26 +0530 Reply-To: Mailing List Sender: Mailing List From: sujay Subject: Re: Gracefu-Restart & RFC 3623 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <4397E8C2.504@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT See SUJ>> -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Padma Pillay-Esnault Sent: Thursday, December 08, 2005 1:33 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Gracefu-Restart & RFC 3623 See PPE for comments sujay wrote: >The RFC being the base, has room for improvements, >no wonder WG's and mailing lists ! > > >Please See comments Inline >SUJ> > > > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >Padma Pillay-Esnault >Sent: Thursday, December 08, 2005 11:40 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: Gracefu-Restart & RFC 3623 > > >See PPE for comments > >Abhay D.S wrote: > > > >>Importance: Normal >>X-Priority: 3 (Normal) >>X-MSMail-priority: Normal >> >> >>With a foresight..and with concerns..as a reviewer >>for "Update to graceful restart draft". >> >>Making a case for revisiting standardization: >> >>Standardization has to be 'revisited' and in the pipeline, since "OSPF >>Capabilities" draft which mentions about graceful Restart capable, >>helper capable option advertisements are 'useful' in making Graceful >>restart more robust. >> >>The original RFC still lacks the solution for unplanned restarts. (Do >>you think this the USP for vendors ?):-| >> >> >> >> >> >PPE: > >What ? I beg to differ. > >What about section 5 - Unplanned Outages ? > >SUJ> here I guess the issue is, section 5 still has room for work, >'future work' on 3623. > > > PPE - I have yet to see those :-) SUJ>> this is not covered in this draft, as can be read from its objectives. >>OSPF Capabilities draft can address many issues faced >>by service providers deploying graceful restart. >> >>Im also considering the possibility of using a different >>OSPF version number for some special scenarios. >> >>Abhay >> >> >> >> >> >>-----Original Message----- >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Don >>Goodspeed >>Sent: Thursday, December 08, 2005 4:06 AM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Re: Gracefu-Restart & RFC 3623 >> >> >>Having helped review the original RFC during its draft >>stage, this draft looks like a sound one but this would probably best >>be addressed by contacting the original authors of the RFC and >>co-authoring a revised Graceful OSPF Restart draft rather than having >>the original one and an "enhancement". >> >>Broadcasting this to the list seems like you did not contact them. >> >>Just my observations, >>Don >> >>-----Original Message----- >>From: owner-ospf@PEACH.EASE.LSOFT.COM >>[mailto:owner-ospf@PEACH.EASE.LSOFT.COM] On Behalf Of sujay >>Sent: Tuesday, December 06, 2005 10:59 PM >>To: 'Mailing List' >>Subject: Gracefu-Restart & RFC 3623 >> >>Group, >> >>In reference to; >>Moy, J.,P. Pillay-Esnault,A. Lindem, "Graceful OSPF Restart", RFC >>3623, >> >> > > > >>November 2003. >> >>There are certain areas which could be worked upon; >> >>1. The conservative behavior of the Restarting router; >>- in its reaction on reception of any new lsa where it *always* exits >>the graceful restart, this behavior may be optimized such that the >>Restarting router exits GR iff the new lsa actually implies a change in >> >> > > > >>the topology >> >> >> >> >> >PPE : > > >AFAIK Major vendors already implement "non-strict lsa checking" for the >restarting router and I have >already discussed this on this alias (I seem to recall) way back. I did >not agree then for strict-lsa checking and I still don't as it is >restrictive. > >Several reasons >In a fairly large topology, it going to be impractical. >Is it worth it to exit GR because a acquired a new previously unknown >neighbor ? > > From day 1, my implementation did not support strict lsa checks. The >graceful restart implementation report mentions non-strict-lsa-checking >as well. > >This is an implementation decision and does not require helpers to >agree > >on the behavior. > > >SUJ> IMHO the strict lsa checking option has been provided for in the >helper in 3623, not the restarting router >See section 3.2, B.2, >Considering even it for the restarting router (and the helper), the >concept of a 'changed lsa' is too wide. It has been tightly defined >with the category as "Topology change LSA's" in the draft. There are >quite a few cases Where for a 'changed lsa' is not truly a qualifier >for Changing the GR environment ! > > > PPE - As I said before, if you have a helper who does not perform strict lsa checking and floods it to a router with strict lsa checking - this won't work. So to me mention of this couples it for both restarting and helper routers. SUJ>> section B.2 says "RestartHelperStrictLSAChecking" . What you are describing already is done in most implementation using common sense. It is actually documenting what implementations have already done individually. This is where I think these are not extensions but exposing implementation details about common sense. SUJ>> To quote a Spanish proverb "Common sense is the least common of the senses" Sections of Exiting, Entering GR as a Restarting Router or a Helper (in 3623), is not necessary all implementors should be able to guess it , rather can ! Spec's to my understanding should be as clear as possible. Refer 2328 for what clarity is. The purpose is not to overrule 3623, but document,and enhance it, a known fact by the world of men as we know. > > >>2. A helper router on the presence of non-refresh lsa's in the >>retransmit list to the restarting router *always* exits as a gr helper >>- this reaction again can be ratified only if the lsa's actually >> >> >specify > > >>a topology change. >> >> >> >> > >PPE : >Please see section B2. > >The RFC already has the non-strict-lsa-checking option - which I >believe > >goes hand in hand - removing strict lsa checking everywhere ( both the >GR and helper). At least this was the intention of this author. > >SUJ> Please see above comments. > > PPE - see above - it does not make sense to have a mix and match of restart and helper routers regarding strictlsachecking. The wording might not be great but it really implicitly mean for both. > > >>3. The restarting router detects non participating helpers only via >>the >> >> > > > >>back link checks In the router and network lsa's >>- this behavior again may lead to network inconsistency for some time, >>perhaps an explicit notification from the helper router to the >>restarting router could be thought of. >> >> >> >> > >PPE. > >Please see 2.1 last sentence. > >What are you trying to achieve here ? >- if there is no helper (router doesn't understand grace or refuses to >act as helper) >there is no way you are going to achieve graceful restart anyway. > >SUJ> the point is of knowing the non-participation of *any* helper >SUJ> asap, >and getting out of GR >Needless to say it serves the common goal of detecting blackholes and >routing loops asap > > > PPE I don't think that you responded to my question .... You are going to drop packets anyway and I hardly see how you are going to figure out just by exchange of info of helper capability whether you are going to have less blackhole/loop with or without GR. see below SUJ>> The restarting router if informed of a non participating helper, can undergo a Hard restart directly immediately all other routers ( which may be ready as helpers) too Exit the helper process. It hastens the process of detecting that there is something gone wrong in the middle of Grace period to the initial stages. Padma >- that the rebooting GR router continues to do so is not a problem and >you are going to drop >packets - just as expected. > > > > > >Are you proposing to stop graceful restart if you cannot achieve it ? >What would be the benefit ? >as you will then attempt a non-graceful one and drop packets anyway. > > > >>With the above optimizations as well keeping it downwardly compatible, >>there are a few pointers to rectify (1) and (2) above using "Topology >>change Lsa's" and >>(3) using " Exit-Grace LSA TLV" >> >> >> >> >I don't agree that these optimizations are extensions to the original >draft. > >- (1) non-strict lsa checking is already mentioned - maybe not as >clearly as one would wish >- (2) -is already mentioned see section B.2 >- (3) - see my above comment > >my 2 cts > >Padma > > > > >SUJ> To summarize: >1. The draft in short defines certain elements more clearly and exact. >2. It makes the definitions more terse, specifications exact. 3. It is >backwardly compatible with the "large vendors" as reported in the >'graceful restart implementation report' 4. It is an addition over and >above the 3623 and nothing out of the blue ! > > > > > >>Where in short "Topology change LSA's" is the group of LSA's which >>*actually* signify a Topology change >>And "Exit Grace LSA TLV" is an additional TLV in existing Grace LSA >>which the router may use to indicate Its non-particiation as a helper. >> >>The above has been documented at; >>www.ietf.org/internet-drafts/draft-holla-ospf-update-graceful-restart- 0 >>0 >>.txt >> >>While the implementation issues is not much of a hassle and there is >>at >> >> > > > >>least one vendor likely to support it request your views on the same. >> >>Sujay etc. >> >> >> >> >> >> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 08 03:37:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkHHo-0007dK-3n for ospf-archive@megatron.ietf.org; Thu, 08 Dec 2005 03:37:56 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12909 for ; Thu, 8 Dec 2005 03:37:03 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <0.00004FC1@wildebeest.ease.lsoft.com>; Thu, 8 Dec 2005 3:37:25 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 92963437 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Dec 2005 03:37:25 -0500 Received: from 63.197.255.154 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 8 Dec 2005 03:37:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: Gracefu-Restart & RFC 3623 Thread-Index: AcX7zdxi1H0c+N2fSWGAZsyGnZBFywABIAmg Message-ID: Date: Thu, 8 Dec 2005 00:42:10 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: Gracefu-Restart & RFC 3623 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable Hi Padma, I don't see why you cannot call http://peach.ease.lsoft.com/scripts/wa.exe?A2=3Dind0203&L=3Dospf&T=3D0&F=3D= &S=3D&P =3D1888 future work. If I read the draft-ietf-ospf-hitless-restart-01.txt of the RFC, it states that "Add Vishwas's suggested technique for less conservative helper mode termination as possible future work (Section 7)." This, in my view refers to the above discussion we had with John Moy. In fact if you read discussion on version-00 of the draft you will notice I had sent the comments about conservative restart, which got incorporated into the RFC. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Padma Pillay-Esnault Sent: Thursday, December 08, 2005 1:33 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Gracefu-Restart & RFC 3623 See PPE for comments sujay wrote: >The RFC being the base, has room for improvements, >no wonder WG's and mailing lists ! > > >Please See comments Inline=20 >SUJ> > > > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Padma >Pillay-Esnault >Sent: Thursday, December 08, 2005 11:40 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: Gracefu-Restart & RFC 3623 > > >See PPE for comments > >Abhay D.S wrote: > > =20 > >>Importance: Normal >>X-Priority: 3 (Normal) >>X-MSMail-priority: Normal >> >> >>With a foresight..and with concerns..as a reviewer >>for "Update to graceful restart draft". >> >>Making a case for revisiting standardization: >> >>Standardization has to be 'revisited' and in the pipeline, since "OSPF >>Capabilities" draft which mentions about graceful Restart capable,=20 >>helper capable option advertisements are 'useful' in making Graceful=20 >>restart more robust. >> >>The original RFC still lacks the solution for unplanned restarts. (Do=20 >>you think this the USP for vendors ?):-| >> >>=20 >> >> =20 >> >PPE: > >What ? I beg to differ.=20 > >What about section 5 - Unplanned Outages ? > >SUJ> here I guess the issue is, section 5 still has room for work, >'future work' on 3623. > > =20 > PPE - I have yet to see those :-) >>OSPF Capabilities draft can address many issues faced >>by service providers deploying graceful restart. >> >>Im also considering the possibility of using a different >>OSPF version number for some special scenarios. >> >>Abhay >> >> >> >> >> >>-----Original Message----- >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Don >>Goodspeed >>Sent: Thursday, December 08, 2005 4:06 AM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Re: Gracefu-Restart & RFC 3623 >> >> >>Having helped review the original RFC during its draft >>stage, this draft looks like a sound one but this would probably best=20 >>be addressed by contacting the original authors of the RFC and=20 >>co-authoring a revised Graceful OSPF Restart draft rather than having=20 >>the original one and an "enhancement". >> >>Broadcasting this to the list seems like you did not contact them. >> >>Just my observations, >>Don >> >>-----Original Message----- >>From: owner-ospf@PEACH.EASE.LSOFT.COM=20 >>[mailto:owner-ospf@PEACH.EASE.LSOFT.COM] On Behalf Of sujay >>Sent: Tuesday, December 06, 2005 10:59 PM >>To: 'Mailing List' >>Subject: Gracefu-Restart & RFC 3623 >> >>Group, >> >>In reference to; >>Moy, J.,P. Pillay-Esnault,A. Lindem, "Graceful OSPF Restart", RFC 3623, >> =20 >> > > =20 > >>November 2003. >> >>There are certain areas which could be worked upon; >> >>1. The conservative behavior of the Restarting router; >>- in its reaction on reception of any new lsa where it *always* exits=20 >>the graceful restart, this behavior may be optimized such that the=20 >>Restarting router exits GR iff the new lsa actually implies a change in >> =20 >> > > =20 > >>the topology >> >>=20 >> >> =20 >> >PPE : > > >AFAIK Major vendors already implement "non-strict lsa checking" for the >restarting router and I have >already discussed this on this alias (I seem to recall) way back. I did >not agree then for strict-lsa checking and I still don't as it is=20 >restrictive. > >Several reasons >In a fairly large topology, it going to be impractical. >Is it worth it to exit GR because a acquired a new previously unknown=20 >neighbor ? > > From day 1, my implementation did not support strict lsa checks. The >graceful restart implementation report mentions=20 >non-strict-lsa-checking as well. > >This is an implementation decision and does not require helpers to agree > >on the behavior. > > >SUJ> IMHO the strict lsa checking option has been provided for in the >helper in 3623, not the restarting router >See section 3.2, B.2, >Considering even it for the restarting router (and the helper), the >concept of a 'changed lsa' is too wide. >It has been tightly defined with the category as "Topology change LSA's" >in the draft. There are quite a few cases >Where for a 'changed lsa' is not truly a qualifier for Changing the GR >environment ! > > =20 > PPE - As I said before, if you have a helper who does not perform strict lsa checking and floods it to a router with strict lsa checking - this won't work. So to me mention of this couples it for both restarting and helper routers. What you are describing already is done in most implementation using=20 common sense. It is actually documenting what implementations have already done=20 individually. This is where I think these are not extensions but exposing implementation details about=20 common sense. > =20 > >>2. A helper router on the presence of non-refresh lsa's in the=20 >>retransmit list to the restarting router *always* exits as a gr helper >>- this reaction again can be ratified only if the lsa's actually >> =20 >> >specify > =20 > >>a topology change. >>=20 >> >> =20 >> > >PPE : >Please see section B2. > >The RFC already has the non-strict-lsa-checking option - which I believe > >goes hand in hand - removing strict lsa checking everywhere ( both the=20 >GR and helper). At least this was the intention of this author. > >SUJ> Please see above comments. > =20 > PPE - see above - it does not make sense to have a mix and match of=20 restart and helper routers regarding strictlsachecking. The wording might not be great but it=20 really implicitly mean for both. > =20 > >>3. The restarting router detects non participating helpers only via the >> =20 >> > > =20 > >>back link checks In the router and network lsa's >>- this behavior again may lead to network inconsistency for some time, >>perhaps an explicit=20 >>notification from the helper router to the restarting router could be >>thought of. >>=20 >> >> =20 >> > >PPE. > >Please see 2.1 last sentence. > >What are you trying to achieve here ? >- if there is no helper (router doesn't understand grace or refuses to=20 >act as helper) >there is no way you are going to achieve graceful restart anyway. > >SUJ> the point is of knowing the non-participation of *any* helper asap, >and getting out of GR >Needless to say it serves the common goal of detecting blackholes and >routing loops asap > > =20 > PPE I don't think that you responded to my question .... You are going to drop packets anyway and I hardly see how you are going to figure out just by exchange of info of helper capability whether you are going to have less blackhole/loop with or without GR. see below Padma >- that the rebooting GR router continues to do so is not a problem and >you are going to drop >packets - just as expected. > > > > > >Are you proposing to stop graceful restart if you cannot achieve it ?=20 >What would be the benefit ? >as you will then attempt a non-graceful one and drop packets anyway. > > =20 > >>With the above optimizations as well keeping it downwardly compatible, >>there are a few pointers to rectify (1) and (2) above using "Topology >>change Lsa's" and >>(3) using " Exit-Grace LSA TLV" >>=20 >> >> =20 >> >I don't agree that these optimizations are extensions to the original >draft. > >- (1) non-strict lsa checking is already mentioned - maybe not as=20 >clearly as one would wish >- (2) -is already mentioned see section B.2 >- (3) - see my above comment > >my 2 cts > >Padma > > > > >SUJ> To summarize: >1. The draft in short defines certain elements more clearly and exact. >2. It makes the definitions more terse, specifications exact. >3. It is backwardly compatible with the "large vendors" as reported in >the 'graceful restart implementation report' >4. It is an addition over and above the 3623 and nothing out of the blue >! > > > > =20 > >>Where in short "Topology change LSA's" is the group of LSA's which >>*actually* signify a Topology change >>And "Exit Grace LSA TLV" is an additional TLV in existing Grace LSA=20 >>which the router may use to indicate Its non-particiation as a helper. >> >>The above has been documented at;=20 >>www.ietf.org/internet-drafts/draft-holla-ospf-update-graceful-restart- 0 >>0 >>.txt >> >>While the implementation issues is not much of a hassle and there is at >> =20 >> > > =20 > >>least one vendor likely to support it request your views on the same. >> >>Sujay etc. >> >> >> >> >>=20 >> >> =20 >> > > =20 > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 08 03:41:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkHKl-0008MW-Sw for ospf-archive@megatron.ietf.org; Thu, 08 Dec 2005 03:41:00 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13402 for ; Thu, 8 Dec 2005 03:40:07 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <4.00004FC3@wildebeest.ease.lsoft.com>; Thu, 8 Dec 2005 3:40:29 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 92963585 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Dec 2005 03:40:29 -0500 Received: from 61.144.161.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 8 Dec 2005 03:40:24 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IR600GIT8CQII@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 08 Dec 2005 16:46:02 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IR600I358CPQ3@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 08 Dec 2005 16:46:02 +0800 (CST) Received: from common1 ([10.110.94.86]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IR6002IO8CGLT@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 08 Dec 2005 16:45:53 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <000201c5fbd2$5e49dc90$565e6e0a@china.huawei.com> Date: Thu, 8 Dec 2005 16:35:38 +0800 Reply-To: Mailing List Sender: Mailing List From: Ashok Subject: Re: Gracefu-Restart & RFC 3623 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <4397E8C2.504@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT Hi Padma, Regarding the idea behind topology change lsa: In my opinion, disabling strict LSA checking is not the ideal way of going about graceful restart, since this leads to topology inconsistencies and routing holes. What the draft suggests is 'while working in the existing framework with strict lsa checking enabled', we restrict the scope of the topology changes that can and MUST force a gracefully restarting router to terminate the GR. This is better than doing away with the strict lsa checking all together. Therefore this mechanism offers maximum flexibility while adhering to the principle of unbroken forwarding. Regarding the idea behind exit-grace tlv: There may be scenarios, where there are configuration anomalies on routing peers. During such scenarios, if a router on receiving grace lsa, refuses to act as helper, it can immediately inform the restarting router. This helps the restarting router to flush the grace lsas from the domain and ensure the best protection against any further changes. What is perhaps seen as common sense is what the restarting router does AFTER flushing the grace lsas. That as you rightly point out is implementation specific. Our concern should only be that the restarting router flushes the grace lsas asap, in order to provide the correct picture of the routing topology. There are a few other suggestions in the draft like excluding implied acks from the purview of changed lsas (when a rtr enters helper mode). Perhaps, the draft warrants a discussion in greater detail. Regards, Ashok -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Padma Pillay-Esnault Sent: Thursday, December 08, 2005 4:03 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Gracefu-Restart & RFC 3623 See PPE for comments sujay wrote: >The RFC being the base, has room for improvements, >no wonder WG's and mailing lists ! > > >Please See comments Inline >SUJ> > > > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Padma >Pillay-Esnault >Sent: Thursday, December 08, 2005 11:40 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: Gracefu-Restart & RFC 3623 > > >See PPE for comments > >Abhay D.S wrote: > > > >>Importance: Normal >>X-Priority: 3 (Normal) >>X-MSMail-priority: Normal >> >> >>With a foresight..and with concerns..as a reviewer >>for "Update to graceful restart draft". >> >>Making a case for revisiting standardization: >> >>Standardization has to be 'revisited' and in the pipeline, since "OSPF >>Capabilities" draft which mentions about graceful Restart capable, >>helper capable option advertisements are 'useful' in making Graceful >>restart more robust. >> >>The original RFC still lacks the solution for unplanned restarts. (Do >>you think this the USP for vendors ?):-| >> >> >> >> >> >PPE: > >What ? I beg to differ. > >What about section 5 - Unplanned Outages ? > >SUJ> here I guess the issue is, section 5 still has room for work, >'future work' on 3623. > > > PPE - I have yet to see those :-) >>OSPF Capabilities draft can address many issues faced >>by service providers deploying graceful restart. >> >>Im also considering the possibility of using a different >>OSPF version number for some special scenarios. >> >>Abhay >> >> >> >> >> >>-----Original Message----- >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Don >>Goodspeed >>Sent: Thursday, December 08, 2005 4:06 AM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Re: Gracefu-Restart & RFC 3623 >> >> >>Having helped review the original RFC during its draft >>stage, this draft looks like a sound one but this would probably best >>be addressed by contacting the original authors of the RFC and >>co-authoring a revised Graceful OSPF Restart draft rather than having >>the original one and an "enhancement". >> >>Broadcasting this to the list seems like you did not contact them. >> >>Just my observations, >>Don >> >>-----Original Message----- >>From: owner-ospf@PEACH.EASE.LSOFT.COM >>[mailto:owner-ospf@PEACH.EASE.LSOFT.COM] On Behalf Of sujay >>Sent: Tuesday, December 06, 2005 10:59 PM >>To: 'Mailing List' >>Subject: Gracefu-Restart & RFC 3623 >> >>Group, >> >>In reference to; >>Moy, J.,P. Pillay-Esnault,A. Lindem, "Graceful OSPF Restart", RFC 3623, >> >> > > > >>November 2003. >> >>There are certain areas which could be worked upon; >> >>1. The conservative behavior of the Restarting router; >>- in its reaction on reception of any new lsa where it *always* exits >>the graceful restart, this behavior may be optimized such that the >>Restarting router exits GR iff the new lsa actually implies a change in >> >> > > > >>the topology >> >> >> >> >> >PPE : > > >AFAIK Major vendors already implement "non-strict lsa checking" for the >restarting router and I have >already discussed this on this alias (I seem to recall) way back. I did >not agree then for strict-lsa checking and I still don't as it is >restrictive. > >Several reasons >In a fairly large topology, it going to be impractical. >Is it worth it to exit GR because a acquired a new previously unknown >neighbor ? > > From day 1, my implementation did not support strict lsa checks. The >graceful restart implementation report mentions >non-strict-lsa-checking as well. > >This is an implementation decision and does not require helpers to agree > >on the behavior. > > >SUJ> IMHO the strict lsa checking option has been provided for in the >helper in 3623, not the restarting router >See section 3.2, B.2, >Considering even it for the restarting router (and the helper), the >concept of a 'changed lsa' is too wide. >It has been tightly defined with the category as "Topology change LSA's" >in the draft. There are quite a few cases >Where for a 'changed lsa' is not truly a qualifier for Changing the GR >environment ! > > > PPE - As I said before, if you have a helper who does not perform strict lsa checking and floods it to a router with strict lsa checking - this won't work. So to me mention of this couples it for both restarting and helper routers. What you are describing already is done in most implementation using common sense. It is actually documenting what implementations have already done individually. This is where I think these are not extensions but exposing implementation details about common sense. > > >>2. A helper router on the presence of non-refresh lsa's in the >>retransmit list to the restarting router *always* exits as a gr helper >>- this reaction again can be ratified only if the lsa's actually >> >> >specify > > >>a topology change. >> >> >> >> > >PPE : >Please see section B2. > >The RFC already has the non-strict-lsa-checking option - which I believe > >goes hand in hand - removing strict lsa checking everywhere ( both the >GR and helper). At least this was the intention of this author. > >SUJ> Please see above comments. > > PPE - see above - it does not make sense to have a mix and match of restart and helper routers regarding strictlsachecking. The wording might not be great but it really implicitly mean for both. > > >>3. The restarting router detects non participating helpers only via the >> >> > > > >>back link checks In the router and network lsa's >>- this behavior again may lead to network inconsistency for some time, >>perhaps an explicit >>notification from the helper router to the restarting router could be >>thought of. >> >> >> >> > >PPE. > >Please see 2.1 last sentence. > >What are you trying to achieve here ? >- if there is no helper (router doesn't understand grace or refuses to >act as helper) >there is no way you are going to achieve graceful restart anyway. > >SUJ> the point is of knowing the non-participation of *any* helper asap, >and getting out of GR >Needless to say it serves the common goal of detecting blackholes and >routing loops asap > > > PPE I don't think that you responded to my question .... You are going to drop packets anyway and I hardly see how you are going to figure out just by exchange of info of helper capability whether you are going to have less blackhole/loop with or without GR. see below Padma >- that the rebooting GR router continues to do so is not a problem and >you are going to drop >packets - just as expected. > > > > > >Are you proposing to stop graceful restart if you cannot achieve it ? >What would be the benefit ? >as you will then attempt a non-graceful one and drop packets anyway. > > > >>With the above optimizations as well keeping it downwardly compatible, >>there are a few pointers to rectify (1) and (2) above using "Topology >>change Lsa's" and >>(3) using " Exit-Grace LSA TLV" >> >> >> >> >I don't agree that these optimizations are extensions to the original >draft. > >- (1) non-strict lsa checking is already mentioned - maybe not as >clearly as one would wish >- (2) -is already mentioned see section B.2 >- (3) - see my above comment > >my 2 cts > >Padma > > > > >SUJ> To summarize: >1. The draft in short defines certain elements more clearly and exact. >2. It makes the definitions more terse, specifications exact. >3. It is backwardly compatible with the "large vendors" as reported in >the 'graceful restart implementation report' >4. It is an addition over and above the 3623 and nothing out of the blue >! > > > > > >>Where in short "Topology change LSA's" is the group of LSA's which >>*actually* signify a Topology change >>And "Exit Grace LSA TLV" is an additional TLV in existing Grace LSA >>which the router may use to indicate Its non-particiation as a helper. >> >>The above has been documented at; >>www.ietf.org/internet-drafts/draft-holla-ospf-update-graceful-restart- 0 >>0 >>.txt >> >>While the implementation issues is not much of a hassle and there is at >> >> > > > >>least one vendor likely to support it request your views on the same. >> >>Sujay etc. >> >> >> >> >> >> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 08 03:50:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkHTo-00028W-0Q for ospf-archive@megatron.ietf.org; Thu, 08 Dec 2005 03:50:20 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14365 for ; Thu, 8 Dec 2005 03:49:27 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <1.00004FC7@wildebeest.ease.lsoft.com>; Thu, 8 Dec 2005 3:49:48 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 92964278 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Dec 2005 03:49:48 -0500 Received: from 63.197.255.154 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 8 Dec 2005 03:49:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: Gracefu-Restart & RFC 3623 Thread-Index: AcX7zdxi1H0c+N2fSWGAZsyGnZBFywABIAmgAACmodA= Message-ID: Date: Thu, 8 Dec 2005 00:54:34 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: Gracefu-Restart & RFC 3623 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable Its version draft-ietf-ospf-hitless-restart-07.txt. -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Vishwas Manral Sent: Thursday, December 08, 2005 2:12 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Gracefu-Restart & RFC 3623 Hi Padma, I don't see why you cannot call http://peach.ease.lsoft.com/scripts/wa.exe?A2=3Dind0203&L=3Dospf&T=3D0&F=3D= &S=3D&P =3D1888 future work. If I read the draft-ietf-ospf-hitless-restart-01.txt of the RFC, it states that "Add Vishwas's suggested technique for less conservative helper mode termination as possible future work (Section 7)." This, in my view refers to the above discussion we had with John Moy. In fact if you read discussion on version-00 of the draft you will notice I had sent the comments about conservative restart, which got incorporated into the RFC. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Padma Pillay-Esnault Sent: Thursday, December 08, 2005 1:33 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Gracefu-Restart & RFC 3623 See PPE for comments sujay wrote: >The RFC being the base, has room for improvements, >no wonder WG's and mailing lists ! > > >Please See comments Inline=20 >SUJ> > > > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Padma >Pillay-Esnault >Sent: Thursday, December 08, 2005 11:40 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: Gracefu-Restart & RFC 3623 > > >See PPE for comments > >Abhay D.S wrote: > > =20 > >>Importance: Normal >>X-Priority: 3 (Normal) >>X-MSMail-priority: Normal >> >> >>With a foresight..and with concerns..as a reviewer >>for "Update to graceful restart draft". >> >>Making a case for revisiting standardization: >> >>Standardization has to be 'revisited' and in the pipeline, since "OSPF >>Capabilities" draft which mentions about graceful Restart capable,=20 >>helper capable option advertisements are 'useful' in making Graceful=20 >>restart more robust. >> >>The original RFC still lacks the solution for unplanned restarts. (Do=20 >>you think this the USP for vendors ?):-| >> >>=20 >> >> =20 >> >PPE: > >What ? I beg to differ.=20 > >What about section 5 - Unplanned Outages ? > >SUJ> here I guess the issue is, section 5 still has room for work, >'future work' on 3623. > > =20 > PPE - I have yet to see those :-) >>OSPF Capabilities draft can address many issues faced >>by service providers deploying graceful restart. >> >>Im also considering the possibility of using a different >>OSPF version number for some special scenarios. >> >>Abhay >> >> >> >> >> >>-----Original Message----- >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Don >>Goodspeed >>Sent: Thursday, December 08, 2005 4:06 AM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Re: Gracefu-Restart & RFC 3623 >> >> >>Having helped review the original RFC during its draft >>stage, this draft looks like a sound one but this would probably best=20 >>be addressed by contacting the original authors of the RFC and=20 >>co-authoring a revised Graceful OSPF Restart draft rather than having=20 >>the original one and an "enhancement". >> >>Broadcasting this to the list seems like you did not contact them. >> >>Just my observations, >>Don >> >>-----Original Message----- >>From: owner-ospf@PEACH.EASE.LSOFT.COM=20 >>[mailto:owner-ospf@PEACH.EASE.LSOFT.COM] On Behalf Of sujay >>Sent: Tuesday, December 06, 2005 10:59 PM >>To: 'Mailing List' >>Subject: Gracefu-Restart & RFC 3623 >> >>Group, >> >>In reference to; >>Moy, J.,P. Pillay-Esnault,A. Lindem, "Graceful OSPF Restart", RFC 3623, >> =20 >> > > =20 > >>November 2003. >> >>There are certain areas which could be worked upon; >> >>1. The conservative behavior of the Restarting router; >>- in its reaction on reception of any new lsa where it *always* exits=20 >>the graceful restart, this behavior may be optimized such that the=20 >>Restarting router exits GR iff the new lsa actually implies a change in >> =20 >> > > =20 > >>the topology >> >>=20 >> >> =20 >> >PPE : > > >AFAIK Major vendors already implement "non-strict lsa checking" for the >restarting router and I have >already discussed this on this alias (I seem to recall) way back. I did >not agree then for strict-lsa checking and I still don't as it is=20 >restrictive. > >Several reasons >In a fairly large topology, it going to be impractical. >Is it worth it to exit GR because a acquired a new previously unknown=20 >neighbor ? > > From day 1, my implementation did not support strict lsa checks. The >graceful restart implementation report mentions=20 >non-strict-lsa-checking as well. > >This is an implementation decision and does not require helpers to agree > >on the behavior. > > >SUJ> IMHO the strict lsa checking option has been provided for in the >helper in 3623, not the restarting router >See section 3.2, B.2, >Considering even it for the restarting router (and the helper), the >concept of a 'changed lsa' is too wide. >It has been tightly defined with the category as "Topology change LSA's" >in the draft. There are quite a few cases >Where for a 'changed lsa' is not truly a qualifier for Changing the GR >environment ! > > =20 > PPE - As I said before, if you have a helper who does not perform strict lsa checking and floods it to a router with strict lsa checking - this won't work. So to me mention of this couples it for both restarting and helper routers. What you are describing already is done in most implementation using=20 common sense. It is actually documenting what implementations have already done=20 individually. This is where I think these are not extensions but exposing implementation details about=20 common sense. > =20 > >>2. A helper router on the presence of non-refresh lsa's in the=20 >>retransmit list to the restarting router *always* exits as a gr helper >>- this reaction again can be ratified only if the lsa's actually >> =20 >> >specify > =20 > >>a topology change. >>=20 >> >> =20 >> > >PPE : >Please see section B2. > >The RFC already has the non-strict-lsa-checking option - which I believe > >goes hand in hand - removing strict lsa checking everywhere ( both the=20 >GR and helper). At least this was the intention of this author. > >SUJ> Please see above comments. > =20 > PPE - see above - it does not make sense to have a mix and match of=20 restart and helper routers regarding strictlsachecking. The wording might not be great but it=20 really implicitly mean for both. > =20 > >>3. The restarting router detects non participating helpers only via the >> =20 >> > > =20 > >>back link checks In the router and network lsa's >>- this behavior again may lead to network inconsistency for some time, >>perhaps an explicit=20 >>notification from the helper router to the restarting router could be >>thought of. >>=20 >> >> =20 >> > >PPE. > >Please see 2.1 last sentence. > >What are you trying to achieve here ? >- if there is no helper (router doesn't understand grace or refuses to=20 >act as helper) >there is no way you are going to achieve graceful restart anyway. > >SUJ> the point is of knowing the non-participation of *any* helper asap, >and getting out of GR >Needless to say it serves the common goal of detecting blackholes and >routing loops asap > > =20 > PPE I don't think that you responded to my question .... You are going to drop packets anyway and I hardly see how you are going to figure out just by exchange of info of helper capability whether you are going to have less blackhole/loop with or without GR. see below Padma >- that the rebooting GR router continues to do so is not a problem and >you are going to drop >packets - just as expected. > > > > > >Are you proposing to stop graceful restart if you cannot achieve it ?=20 >What would be the benefit ? >as you will then attempt a non-graceful one and drop packets anyway. > > =20 > >>With the above optimizations as well keeping it downwardly compatible, >>there are a few pointers to rectify (1) and (2) above using "Topology >>change Lsa's" and >>(3) using " Exit-Grace LSA TLV" >>=20 >> >> =20 >> >I don't agree that these optimizations are extensions to the original >draft. > >- (1) non-strict lsa checking is already mentioned - maybe not as=20 >clearly as one would wish >- (2) -is already mentioned see section B.2 >- (3) - see my above comment > >my 2 cts > >Padma > > > > >SUJ> To summarize: >1. The draft in short defines certain elements more clearly and exact. >2. It makes the definitions more terse, specifications exact. >3. It is backwardly compatible with the "large vendors" as reported in >the 'graceful restart implementation report' >4. It is an addition over and above the 3623 and nothing out of the blue >! > > > > =20 > >>Where in short "Topology change LSA's" is the group of LSA's which >>*actually* signify a Topology change >>And "Exit Grace LSA TLV" is an additional TLV in existing Grace LSA=20 >>which the router may use to indicate Its non-particiation as a helper. >> >>The above has been documented at;=20 >>www.ietf.org/internet-drafts/draft-holla-ospf-update-graceful-restart- 0 >>0 >>.txt >> >>While the implementation issues is not much of a hassle and there is at >> =20 >> > > =20 > >>least one vendor likely to support it request your views on the same. >> >>Sujay etc. >> >> >> >> >>=20 >> >> =20 >> > > =20 > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 08 04:18:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkHvT-00007C-Jz for ospf-archive@megatron.ietf.org; Thu, 08 Dec 2005 04:18:56 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17618 for ; Thu, 8 Dec 2005 04:18:02 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <9.00004FBD@wildebeest.ease.lsoft.com>; Thu, 8 Dec 2005 4:18:24 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 92966108 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Dec 2005 04:18:24 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 8 Dec 2005 04:18:24 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 08 Dec 2005 04:18:24 -0500 X-IronPort-AV: i="3.99,228,1131339600"; d="scan'208"; a="77367524:sNHT36788868" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jB89ILUR002106 for ; Thu, 8 Dec 2005 04:18:22 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 04:18:21 -0500 Received: from [192.168.1.67] ([10.82.216.35]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 04:18:20 -0500 User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <000201c5fbca$d36bf380$33666e0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Dec 2005 09:18:20.0804 (UTC) FILETIME=[55084440:01C5FBD8] Message-ID: <4397FA59.3090808@cisco.com> Date: Thu, 8 Dec 2005 01:18:17 -0800 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: Gracefu-Restart & RFC 3623 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000201c5fbca$d36bf380$33666e0a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Abhay D.S wrote: >Hi padma !. >Your proverbs are enjoyable ! :-). > > Glad you like them The original in french "Avec des si on metterait Paris en bouteille." responses below >However, please read inline and think >im your customer !(ends at the moment >we start thinking about revisiting standardization). > > > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Padma >Pillay-Esnault >Sent: Thursday, December 08, 2005 3:03 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: Gracefu-Restart & RFC 3623 > > >Abhay D.S wrote: > > > >>Hi Padma !, >>IMHO. >>Section 5 has an avoidance approach not preventive. >> >> >> >> > > > >Yes there is "no" support. > >Humm ... >You said there is "no" support - and now you say it is avoidance. > >I missing something. Not sure I understand what is avoidance and what is > >preventive ? > >Can you prevent/avoid a crash ? :-) > > > > >Abhay)) Yes RFC does not have a mechanism to prevent neighbors from >getting down due to receiving hello. Do you remember the robustness >variable ?(This is what is avoidance).(Hope you understand and not >mislead >yourself into thinking what RFC says is perfect,everybody loves >their babies). > > > PPE - Robustness variable - yeah - send as many grace lsa you think before you send your hellos - when I think that we have feature out now that demands to send packets asap and no drops - but just grace lsa would get dropped !! I don't buy your argument. If your robustness variable is good enough that is prevention. >Unplanned restart: Why do you think grace LSA cannot be dropped and >hello packets be received in >case of unplanned restart,we have still not discovered our neighbors. > > > PPE - what makes you think that only these lsa will get dropped ? I think that you are being biased here - lo! all my grace lsa - for 5 s got dropped but lo and behold all my hellos got thru - well something is wrong and we never said that this should work on faulty equipment did we ? >In planned case I agree that grace LSA's will be received by all >neighbors before >sending hello. > > > > >>Why ?. >>Unassuming.. >>Case X ) Hello packets will be sent eventually to discover some >>neighbors ,but what if hello packets are received by some routers >>before they receive the grace LSA.(Only for unplanned case) because of >>transient network conditions. >> >> >> >> >Why would only the grace lsas ( BTW we do send several of them wait >before sending hellos - >discussed on this alias in 2001 I believe) get dropped and not the >subsequent hello packets ? > > > >Makes me think of a french proverb > >"With a lot of ifs you can put Paris in a bottle ...." > >These are local link scope - how can you expect the hellos to jump ahead > >of the grace lsa if you >implemented it not to be so - unless you have a buggy implementation. > >Abhay)) You must have heard about packet being dropped(it is justified >in draft,sending several times), and about priority handling of hello >packets. >(suggested by folks at AT&T). > > > PPE - this is what I call implementation details- if you write get the grace out first - just do it ! or else you have a buggy implementation of the feature. Suggestion -use the pak priority right :-) >>Case Y) Due to load of neighbors, restart router feels it needs more >>time to complete Graceful restart. >> >> >> >> >> > >The router does not feel - you configure it :-) > >Abhay)) I need an router with extra intelligence. As you know that GR >deployment is critical in PE's. Feeling is better than configuring it >and then saying sorry "we will come up with something soon, I beg you". >Configuration is for stable toplogies. > > > > PPE - I never saw my routers beg :-) Gosh your routers are really different from mine !! :-) Restart with PE could have a very large value - under 1 hr theoretically - and an implementation exit GR as soon as it has completed. Simple and robust. ( Though I don't recommend 1 hr ! - I have done enough of profiling on this one to find a suitable value!) So what do you suggest evaluate DB size. number of routers, may be mtu, may be link robustness and get some number ? How do you evaluate for those famous packet drops ? :-) Renegotiate the time ? By how much - how are you going to "feel" when you are done ? What are the criterias ? Do really want to go there ? I know how to do complex but aim for simplicity. >>In case of unplanned restart(crash on router processer) >>Voice over IP call is still running. Do >> >>we want to exit >>Helper mode and get routes down ?. (Case X).Voice call >>is down. >> >> >> >> >> >I am missing your point ..... > >Unlikely case X ( hellos ahead of grace) and the helper exit - why ? > >Abhay)) It is possible in unplanned case, think more....see reason given >Above. > > > > PPE - sorry I must be slow. I think that a good implementation should avoid X from there nothing makes sense anymore. It's like saying I have OSPF but I can't have multicast ... the basic premise is broken - all kinds of speculations are open. Well don't break the premise and it will work. Further more the restarting router control the premise and can make sure it is not broken. Are you trying to say the GR router send a hello then a grace ? - but the hello should have torn down the adj - the other router is not even a helper at that point as it will receive a hello with no nbr - which will cause a adjacency recycle. >>Do you feel OSPF capabilities specification can help provide >>a solution to ISP ?. Im keeping in mind the options some graph experts >>had suggested about configuration of exiting helper mode. But that did >>not cover case X.. >> >>Another, Grace period should be able to be changed dynamically, >>depending on restarting routers load, and period should be derived from >> >> > > > >>a standardized function.(Case y) >> >> >> >> >> >> >Actually GR can configured to be a very long period and a good >implementation will get end as soon as it >is ready. This is the approach in my implementation, let's call it >intuitively dynamic and you >don't even have to add extra config. > >Abhay)) Do you think all vendors run the same type of mechanisms ?. >But just above you said it can be configured ??. > > PPE - Implementation detail - you don't need a spec for that. I am sure you can figure it out. > > >>If I was a ISP operator, I would not refuse all of these .... :-). >> >> >> >> >I think you already have these :-) > >Padma > >Abhay)) Im still not satisfied, I cannot buy your RFC. :-). Please >improve >section 5 and I will think about it. > > > PPE See my comments above Improve yes as long as it stays simple and robust and usable but brew coffee don't think so :-) Padma >>Abhay >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>-----Original Message----- >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >>Padma Pillay-Esnault >>Sent: Thursday, December 08, 2005 2:10 PM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Re: Gracefu-Restart & RFC 3623 >> >> >>See PPE for comments >> >>Abhay D.S wrote: >> >> >> >> >> >>>Importance: Normal >>>X-Priority: 3 (Normal) >>>X-MSMail-priority: Normal >>> >>> >>>With a foresight..and with concerns..as a reviewer >>>for "Update to graceful restart draft". >>> >>>Making a case for revisiting standardization: >>> >>>Standardization has to be 'revisited' and in the pipeline, since "OSPF >>>Capabilities" draft which mentions about graceful Restart capable, >>>helper capable option advertisements are 'useful' in making Graceful >>>restart more robust. >>> >>>The original RFC still lacks the solution for unplanned restarts. (Do >>>you think this the USP for vendors ?):-| >>> >>> >>> >>> >>> >>> >>> >>PPE: >> >>What ? I beg to differ. >> >>What about section 5 - Unplanned Outages ? >> >> >> >> >> >>>OSPF Capabilities draft can address many issues faced >>>by service providers deploying graceful restart. >>> >>>Im also considering the possibility of using a different >>>OSPF version number for some special scenarios. >>> >>>Abhay >>> >>> >>> >>> >>> >>>-----Original Message----- >>>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Don >>>Goodspeed >>>Sent: Thursday, December 08, 2005 4:06 AM >>>To: OSPF@PEACH.EASE.LSOFT.COM >>>Subject: Re: Gracefu-Restart & RFC 3623 >>> >>> >>>Having helped review the original RFC during its draft >>>stage, this draft looks like a sound one but this would probably best >>>be addressed by contacting the original authors of the RFC and >>>co-authoring a revised Graceful OSPF Restart draft rather than having >>>the original one and an "enhancement". >>> >>>Broadcasting this to the list seems like you did not contact them. >>> >>>Just my observations, >>>Don >>> >>>-----Original Message----- >>>From: owner-ospf@PEACH.EASE.LSOFT.COM >>>[mailto:owner-ospf@PEACH.EASE.LSOFT.COM] On Behalf Of sujay >>>Sent: Tuesday, December 06, 2005 10:59 PM >>>To: 'Mailing List' >>>Subject: Gracefu-Restart & RFC 3623 >>> >>>Group, >>> >>>In reference to; >>>Moy, J.,P. Pillay-Esnault,A. Lindem, "Graceful OSPF Restart", RFC >>>3623, >>> >>> >>> >>> >> >> >> >> >>>November 2003. >>> >>>There are certain areas which could be worked upon; >>> >>>1. The conservative behavior of the Restarting router; >>>- in its reaction on reception of any new lsa where it *always* exits >>>the graceful restart, this behavior may be optimized such that the >>>Restarting router exits GR iff the new lsa actually implies a change >>> >>> >in > > >>> >>> >>> >>> >> >> >> >> >>>the topology >>> >>> >>> >>> >>> >>> >>> >>PPE : >> >> >>AFAIK Major vendors already implement "non-strict lsa checking" for the >>restarting router and I have >>already discussed this on this alias (I seem to recall) way back. I did >>not agree then for strict-lsa checking and I still don't as it is >>restrictive. >> >>Several reasons >>In a fairly large topology, it going to be impractical. >>Is it worth it to exit GR because a acquired a new previously unknown >>neighbor ? >> >>From day 1, my implementation did not support strict lsa checks. The >>graceful restart implementation report mentions non-strict-lsa-checking >> >> > > > >>as well. >> >>This is an implementation decision and does not require helpers to >>agree >> >>on the behavior. >> >> >> >> >> >>>2. A helper router on the presence of non-refresh lsa's in the >>>retransmit list to the restarting router *always* exits as a gr helper >>>- this reaction again can be ratified only if the lsa's actually >>> >>> >>> >>> >>specify >> >> >> >> >>>a topology change. >>> >>> >>> >>> >>> >>> >>PPE : >>Please see section B2. >> >>The RFC already has the non-strict-lsa-checking option - which I >>believe >> >>goes hand in hand - removing strict lsa checking everywhere ( both the >>GR and helper). At least this was the intention of this author. >> >> >> >> >> >>>3. The restarting router detects non participating helpers only via >>>the >>> >>> >>> >>> >> >> >> >> >>>back link checks In the router and network lsa's >>>- this behavior again may lead to network inconsistency for some time, >>> >>> > > > >>>perhaps an explicit notification from the helper router to the >>>restarting router could be thought of. >>> >>> >>> >>> >>> >>> >>PPE. >> >>Please see 2.1 last sentence. >> >>What are you trying to achieve here ? >>- if there is no helper (router doesn't understand grace or refuses to >>act as helper) >>there is no way you are going to achieve graceful restart anyway. >>- that the rebooting GR router continues to do so is not a problem and >> >> > > > >>you are going to drop >>packets - just as expected. >> >>Are you proposing to stop graceful restart if you cannot achieve it ? >>What would be the benefit ? >>as you will then attempt a non-graceful one and drop packets anyway. >> >> >> >> >> >>>With the above optimizations as well keeping it downwardly compatible, >>> >>> > > > >>>there are a few pointers to rectify (1) and (2) above using "Topology >>>change Lsa's" and >>>(3) using " Exit-Grace LSA TLV" >>> >>> >>> >>> >>> >>> >>I don't agree that these optimizations are extensions to the original >>draft. >> >>- (1) non-strict lsa checking is already mentioned - maybe not as >>clearly as one would wish >>- (2) -is already mentioned see section B.2 >>- (3) - see my above comment >> >>my 2 cts >> >>Padma >> >> >> >> >> >>>Where in short "Topology change LSA's" is the group of LSA's which >>>*actually* signify a Topology change >>>And "Exit Grace LSA TLV" is an additional TLV in existing Grace LSA >>>which the router may use to indicate Its non-particiation as a helper. >>> >>>The above has been documented at; >>>www.ietf.org/internet-drafts/draft-holla-ospf-update-graceful-restart- >>> >>> >0 > > >>>0 >>>.txt >>> >>>While the implementation issues is not much of a hassle and there is >>>at >>> >>> >>> >>> >> >> >> >> >>>least one vendor likely to support it request your views on the same. >>> >>>Sujay etc. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 08 04:42:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkIIf-0004lt-Ff for ospf-archive@megatron.ietf.org; Thu, 08 Dec 2005 04:42:53 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20041 for ; Thu, 8 Dec 2005 04:42:00 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <3.00004FC2@wildebeest.ease.lsoft.com>; Thu, 8 Dec 2005 4:42:22 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 92966745 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Dec 2005 04:42:22 -0500 Received: from 217.12.11.34 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 8 Dec 2005 04:32:22 -0500 Received: (qmail 51687 invoked from network); 8 Dec 2005 09:32:22 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Received:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:In-Reply-To:X-MimeOLE:Thread-Index; b=3tP30mh/jLFKj6erq4l37h5xzP2QyOQdLw5UZnPVope7Jl/eTADeJ+uOU1M2OR/NBDUVb5M0fraAHD4ND07fSsYtRi2mRPI/qiIaodkkZVfRUZpqYw/MyEi915D6vS1slKwFHKbCNwtLhziYR/IWWrvvNiNQ8e+cQ1aEuKwsV38= ; Received: from unknown (HELO pfloyd) (manav?bhatia06@202.144.106.189 with login) by smtp003.mail.ukl.yahoo.com with SMTP; 8 Dec 2005 09:32:21 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcX7zBVZcbidHMQPRMezGl771xNlAQADMfgg Message-ID: Date: Thu, 8 Dec 2005 15:00:43 +0530 Reply-To: Mailing List Sender: Mailing List From: Manav Bhatia Subject: Re: Gracefu-Restart & RFC 3623 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000201c5fbca$d36bf380$33666e0a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Abhay, !> !> >Why ?. !> >Unassuming.. !> >Case X ) Hello packets will be sent eventually to discover some !> >neighbors ,but what if hello packets are received by some routers !> >before they receive the grace LSA.(Only for unplanned case) !> because of !> >transient network conditions. !> > !> > !> Why would only the grace lsas ( BTW we do send several of them wait !> before sending hellos - !> discussed on this alias in 2001 I believe) get dropped and not the !> subsequent hello packets ? !> !> !> !> Makes me think of a french proverb !> !> "With a lot of ifs you can put Paris in a bottle ...." !> !> These are local link scope - how can you expect the hellos !> to jump ahead !> !> of the grace lsa if you !> implemented it not to be so - unless you have a buggy !> implementation. !> !> Abhay)) You must have heard about packet being dropped(it is !> justified !> in draft,sending several times), and about priority handling of hello !> packets. !> (suggested by folks at AT&T). What really stops an implementation from prioritizing its grace LSAs? :) A proper implementation would IMO correctly handle the grace LSAs in case of an unplanned outage also. Manav ___________________________________________________________ Yahoo! Exclusive Xmas Game, help Santa with his celebrity party - http://santas-christmas-party.yahoo.net/ From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 08 04:56:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkIVj-0007XC-2Q for ospf-archive@megatron.ietf.org; Thu, 08 Dec 2005 04:56:24 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21196 for ; Thu, 8 Dec 2005 04:55:29 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <4.00004FCC@wildebeest.ease.lsoft.com>; Thu, 8 Dec 2005 4:55:51 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 92967523 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Dec 2005 04:55:51 -0500 Received: from 61.144.161.53 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 8 Dec 2005 04:55:45 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IR6002BSBOUU5@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 08 Dec 2005 17:58:07 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IR600LZ7BOSG7@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 08 Dec 2005 17:58:06 +0800 (CST) Received: from huaweizfbnwhb5 ([10.110.102.51]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IR600E8ABXI33@szxml01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 08 Dec 2005 18:03:18 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <000401c5fbdc$b46741d0$33666e0a@china.huawei.com> Date: Thu, 8 Dec 2005 17:49:38 +0800 Reply-To: Mailing List Sender: Mailing List From: "Abhay D.S" Subject: Re: Gracefu-Restart & RFC 3623 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <4397FA59.3090808@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT Hi Padma ! IMHO We all want to have a KISS implementation(Keep It Simple Stupid). But it is useful only for demonstration not practical. You have no proof to say Grace TLV can be received before receiving Hello. One case: In unplanned case, RFC implementation keeps sending grace TLV to all neighbors, assuming that they have received the TLV.We never Wait for an ACK from all neighbors, since we don't know who they were. And then send hello to discover neighbors. But one end is a remote router which failed to receive Grace LSA(what ever reason,overloaded,dropped due to packet type scheduling). If hello reached the router,What to do ? How about prioritized handling of hello packets many high energy vendors implement. How to inter-operate with them ? Yes in a four router setup, agreed, but not in large networks, you have to consider packet scheduling and router backplane architectures. Please, im talking only about helper router being in danger of receiving out of turn Hello. On restart router, this can be controlled to send Grace LSA. We know our packets well. We also have to consider network conditions. Demonstrability is a requirement for OSPF GR, Usability is the highest priority than Demonstrability. Abhay -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Padma Pillay-Esnault Sent: Thursday, December 08, 2005 5:18 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Gracefu-Restart & RFC 3623 Abhay D.S wrote: >Hi padma !. >Your proverbs are enjoyable ! :-). > > Glad you like them The original in french "Avec des si on metterait Paris en bouteille." responses below >However, please read inline and think >im your customer !(ends at the moment >we start thinking about revisiting standardization). > > > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >Padma Pillay-Esnault >Sent: Thursday, December 08, 2005 3:03 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: Gracefu-Restart & RFC 3623 > > >Abhay D.S wrote: > > > >>Hi Padma !, >>IMHO. >>Section 5 has an avoidance approach not preventive. >> >> >> >> > > > >Yes there is "no" support. > >Humm ... >You said there is "no" support - and now you say it is avoidance. > >I missing something. Not sure I understand what is avoidance and what >is > >preventive ? > >Can you prevent/avoid a crash ? :-) > > > > >Abhay)) Yes RFC does not have a mechanism to prevent neighbors from >getting down due to receiving hello. Do you remember the robustness >variable ?(This is what is avoidance).(Hope you understand and not >mislead yourself into thinking what RFC says is perfect,everybody loves >their babies). > > > PPE - Robustness variable - yeah - send as many grace lsa you think before you send your hellos - when I think that we have feature out now that demands to send packets asap and no drops - but just grace lsa would get dropped !! I don't buy your argument. If your robustness variable is good enough that is prevention. >Unplanned restart: Why do you think grace LSA cannot be dropped and >hello packets be received in case of unplanned restart,we have still >not discovered our neighbors. > > > PPE - what makes you think that only these lsa will get dropped ? I think that you are being biased here - lo! all my grace lsa - for 5 s got dropped but lo and behold all my hellos got thru - well something is wrong and we never said that this should work on faulty equipment did we ? >In planned case I agree that grace LSA's will be received by all >neighbors before sending hello. > > > > >>Why ?. >>Unassuming.. >>Case X ) Hello packets will be sent eventually to discover some >>neighbors ,but what if hello packets are received by some routers >>before they receive the grace LSA.(Only for unplanned case) because of >>transient network conditions. >> >> >> >> >Why would only the grace lsas ( BTW we do send several of them wait >before sending hellos - >discussed on this alias in 2001 I believe) get dropped and not the >subsequent hello packets ? > > > >Makes me think of a french proverb > >"With a lot of ifs you can put Paris in a bottle ...." > >These are local link scope - how can you expect the hellos to jump >ahead > >of the grace lsa if you >implemented it not to be so - unless you have a buggy implementation. > >Abhay)) You must have heard about packet being dropped(it is justified >in draft,sending several times), and about priority handling of hello >packets. (suggested by folks at AT&T). > > > PPE - this is what I call implementation details- if you write get the grace out first - just do it ! or else you have a buggy implementation of the feature. Suggestion -use the pak priority right :-) >>Case Y) Due to load of neighbors, restart router feels it needs more >>time to complete Graceful restart. >> >> >> >> >> > >The router does not feel - you configure it :-) > >Abhay)) I need an router with extra intelligence. As you know that GR >deployment is critical in PE's. Feeling is better than configuring it >and then saying sorry "we will come up with something soon, I beg you". >Configuration is for stable toplogies. > > > > PPE - I never saw my routers beg :-) Gosh your routers are really different from mine !! :-) Restart with PE could have a very large value - under 1 hr theoretically - and an implementation exit GR as soon as it has completed. Simple and robust. ( Though I don't recommend 1 hr ! - I have done enough of profiling on this one to find a suitable value!) So what do you suggest evaluate DB size. number of routers, may be mtu, may be link robustness and get some number ? How do you evaluate for those famous packet drops ? :-) Renegotiate the time ? By how much - how are you going to "feel" when you are done ? What are the criterias ? Do really want to go there ? I know how to do complex but aim for simplicity. >>In case of unplanned restart(crash on router processer) >>Voice over IP call is still running. Do >> >>we want to exit >>Helper mode and get routes down ?. (Case X).Voice call >>is down. >> >> >> >> >> >I am missing your point ..... > >Unlikely case X ( hellos ahead of grace) and the helper exit - why ? > >Abhay)) It is possible in unplanned case, think more....see reason given >Above. > > > > PPE - sorry I must be slow. I think that a good implementation should avoid X from there nothing makes sense anymore. It's like saying I have OSPF but I can't have multicast ... the basic premise is broken - all kinds of speculations are open. Well don't break the premise and it will work. Further more the restarting router control the premise and can make sure it is not broken. Are you trying to say the GR router send a hello then a grace ? - but the hello should have torn down the adj - the other router is not even a helper at that point as it will receive a hello with no nbr - which will cause a adjacency recycle. >>Do you feel OSPF capabilities specification can help provide >>a solution to ISP ?. Im keeping in mind the options some graph experts >>had suggested about configuration of exiting helper mode. But that did >>not cover case X.. >> >>Another, Grace period should be able to be changed dynamically, >>depending on restarting routers load, and period should be derived from >> >> > > > >>a standardized function.(Case y) >> >> >> >> >> >> >Actually GR can configured to be a very long period and a good >implementation will get end as soon as it >is ready. This is the approach in my implementation, let's call it >intuitively dynamic and you >don't even have to add extra config. > >Abhay)) Do you think all vendors run the same type of mechanisms ?. >But just above you said it can be configured ??. > > PPE - Implementation detail - you don't need a spec for that. I am sure you can figure it out. > > >>If I was a ISP operator, I would not refuse all of these .... :-). >> >> >> >> >I think you already have these :-) > >Padma > >Abhay)) Im still not satisfied, I cannot buy your RFC. :-). Please >improve >section 5 and I will think about it. > > > PPE See my comments above Improve yes as long as it stays simple and robust and usable but brew coffee don't think so :-) Padma >>Abhay >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>-----Original Message----- >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >>Padma Pillay-Esnault >>Sent: Thursday, December 08, 2005 2:10 PM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Re: Gracefu-Restart & RFC 3623 >> >> >>See PPE for comments >> >>Abhay D.S wrote: >> >> >> >> >> >>>Importance: Normal >>>X-Priority: 3 (Normal) >>>X-MSMail-priority: Normal >>> >>> >>>With a foresight..and with concerns..as a reviewer >>>for "Update to graceful restart draft". >>> >>>Making a case for revisiting standardization: >>> >>>Standardization has to be 'revisited' and in the pipeline, since "OSPF >>>Capabilities" draft which mentions about graceful Restart capable, >>>helper capable option advertisements are 'useful' in making Graceful >>>restart more robust. >>> >>>The original RFC still lacks the solution for unplanned restarts. (Do >>>you think this the USP for vendors ?):-| >>> >>> >>> >>> >>> >>> >>> >>PPE: >> >>What ? I beg to differ. >> >>What about section 5 - Unplanned Outages ? >> >> >> >> >> >>>OSPF Capabilities draft can address many issues faced >>>by service providers deploying graceful restart. >>> >>>Im also considering the possibility of using a different >>>OSPF version number for some special scenarios. >>> >>>Abhay >>> >>> >>> >>> >>> >>>-----Original Message----- >>>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Don >>>Goodspeed >>>Sent: Thursday, December 08, 2005 4:06 AM >>>To: OSPF@PEACH.EASE.LSOFT.COM >>>Subject: Re: Gracefu-Restart & RFC 3623 >>> >>> >>>Having helped review the original RFC during its draft >>>stage, this draft looks like a sound one but this would probably best >>>be addressed by contacting the original authors of the RFC and >>>co-authoring a revised Graceful OSPF Restart draft rather than having >>>the original one and an "enhancement". >>> >>>Broadcasting this to the list seems like you did not contact them. >>> >>>Just my observations, >>>Don >>> >>>-----Original Message----- >>>From: owner-ospf@PEACH.EASE.LSOFT.COM >>>[mailto:owner-ospf@PEACH.EASE.LSOFT.COM] On Behalf Of sujay >>>Sent: Tuesday, December 06, 2005 10:59 PM >>>To: 'Mailing List' >>>Subject: Gracefu-Restart & RFC 3623 >>> >>>Group, >>> >>>In reference to; >>>Moy, J.,P. Pillay-Esnault,A. Lindem, "Graceful OSPF Restart", RFC >>>3623, >>> >>> >>> >>> >> >> >> >> >>>November 2003. >>> >>>There are certain areas which could be worked upon; >>> >>>1. The conservative behavior of the Restarting router; >>>- in its reaction on reception of any new lsa where it *always* exits >>>the graceful restart, this behavior may be optimized such that the >>>Restarting router exits GR iff the new lsa actually implies a change >>> >>> >in > > >>> >>> >>> >>> >> >> >> >> >>>the topology >>> >>> >>> >>> >>> >>> >>> >>PPE : >> >> >>AFAIK Major vendors already implement "non-strict lsa checking" for the >>restarting router and I have >>already discussed this on this alias (I seem to recall) way back. I did >>not agree then for strict-lsa checking and I still don't as it is >>restrictive. >> >>Several reasons >>In a fairly large topology, it going to be impractical. >>Is it worth it to exit GR because a acquired a new previously unknown >>neighbor ? >> >>From day 1, my implementation did not support strict lsa checks. The >>graceful restart implementation report mentions non-strict-lsa-checking >> >> > > > >>as well. >> >>This is an implementation decision and does not require helpers to >>agree >> >>on the behavior. >> >> >> >> >> >>>2. A helper router on the presence of non-refresh lsa's in the >>>retransmit list to the restarting router *always* exits as a gr helper >>>- this reaction again can be ratified only if the lsa's actually >>> >>> >>> >>> >>specify >> >> >> >> >>>a topology change. >>> >>> >>> >>> >>> >>> >>PPE : >>Please see section B2. >> >>The RFC already has the non-strict-lsa-checking option - which I >>believe >> >>goes hand in hand - removing strict lsa checking everywhere ( both the >>GR and helper). At least this was the intention of this author. >> >> >> >> >> >>>3. The restarting router detects non participating helpers only via >>>the >>> >>> >>> >>> >> >> >> >> >>>back link checks In the router and network lsa's >>>- this behavior again may lead to network inconsistency for some time, >>> >>> > > > >>>perhaps an explicit notification from the helper router to the >>>restarting router could be thought of. >>> >>> >>> >>> >>> >>> >>PPE. >> >>Please see 2.1 last sentence. >> >>What are you trying to achieve here ? >>- if there is no helper (router doesn't understand grace or refuses to >>act as helper) >>there is no way you are going to achieve graceful restart anyway. >>- that the rebooting GR router continues to do so is not a problem and >> >> > > > >>you are going to drop >>packets - just as expected. >> >>Are you proposing to stop graceful restart if you cannot achieve it ? >>What would be the benefit ? >>as you will then attempt a non-graceful one and drop packets anyway. >> >> >> >> >> >>>With the above optimizations as well keeping it downwardly compatible, >>> >>> > > > >>>there are a few pointers to rectify (1) and (2) above using "Topology >>>change Lsa's" and >>>(3) using " Exit-Grace LSA TLV" >>> >>> >>> >>> >>> >>> >>I don't agree that these optimizations are extensions to the original >>draft. >> >>- (1) non-strict lsa checking is already mentioned - maybe not as >>clearly as one would wish >>- (2) -is already mentioned see section B.2 >>- (3) - see my above comment >> >>my 2 cts >> >>Padma >> >> >> >> >> >>>Where in short "Topology change LSA's" is the group of LSA's which >>>*actually* signify a Topology change >>>And "Exit Grace LSA TLV" is an additional TLV in existing Grace LSA >>>which the router may use to indicate Its non-particiation as a helper. >>> >>>The above has been documented at; >>>www.ietf.org/internet-drafts/draft-holla-ospf-update-graceful-restart - >>> >>> >0 > > >>>0 >>>.txt >>> >>>While the implementation issues is not much of a hassle and there is >>>at >>> >>> >>> >>> >> >> >> >> >>>least one vendor likely to support it request your views on the same. >>> >>>Sujay etc. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 08 05:01:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkIad-00005s-HH for ospf-archive@megatron.ietf.org; Thu, 08 Dec 2005 05:01:27 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21571 for ; Thu, 8 Dec 2005 05:00:34 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <6.00004FCA@wildebeest.ease.lsoft.com>; Thu, 8 Dec 2005 5:00:51 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 92967738 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Dec 2005 05:00:51 -0500 Received: from 61.144.161.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 8 Dec 2005 05:00:50 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IR6004XFC1ZEY@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 08 Dec 2005 18:05:59 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IR600IHTC1ZFP@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 08 Dec 2005 18:05:59 +0800 (CST) Received: from dell60 ([10.18.4.57]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IR6003UIC1PXA@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 08 Dec 2005 18:05:50 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <000601c5fbdd$89dc0850$3904120a@china.huawei.com> Date: Thu, 8 Dec 2005 15:25:35 +0530 Reply-To: Mailing List Sender: Mailing List From: sujay Subject: Re: Gracefu-Restart & RFC 3623 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT Manav: Prioritizing packets , reordering them etc. Is mentioned in the draft-ietf-ospf-scalability. The thought is perhaps of the fine-print with the drafts and RFC's (of what else to do other than sending grace lsa's??) - use a Robustness variable ( already suggested) - use packet prioritization ( not suggested ) - maybe skipped but thought of. - ??? Therefore its nothing to do with implementation details. Talk about implementation I could refer some books. -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Manav Bhatia Sent: Thursday, December 08, 2005 3:01 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Gracefu-Restart & RFC 3623 Abhay, !> !> >Why ?. !> >Unassuming.. !> >Case X ) Hello packets will be sent eventually to discover some !> >neighbors ,but what if hello packets are received by some routers !> >before they receive the grace LSA.(Only for unplanned case) !> because of !> >transient network conditions. !> > !> > !> Why would only the grace lsas ( BTW we do send several of them wait !> before sending hellos - !> discussed on this alias in 2001 I believe) get dropped and not the !> subsequent hello packets ? !> !> !> !> Makes me think of a french proverb !> !> "With a lot of ifs you can put Paris in a bottle ...." !> !> These are local link scope - how can you expect the hellos !> to jump ahead !> !> of the grace lsa if you !> implemented it not to be so - unless you have a buggy !> implementation. !> !> Abhay)) You must have heard about packet being dropped(it is !> justified !> in draft,sending several times), and about priority handling of hello !> packets. !> (suggested by folks at AT&T). What really stops an implementation from prioritizing its grace LSAs? :) A proper implementation would IMO correctly handle the grace LSAs in case of an unplanned outage also. Manav ___________________________________________________________ Yahoo! Exclusive Xmas Game, help Santa with his celebrity party - http://santas-christmas-party.yahoo.net/ From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 08 05:10:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkIjU-00024j-Kq for ospf-archive@megatron.ietf.org; Thu, 08 Dec 2005 05:10:36 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23135 for ; Thu, 8 Dec 2005 05:09:42 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <2.00004FD1@wildebeest.ease.lsoft.com>; Thu, 8 Dec 2005 5:10:04 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 92968002 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Dec 2005 05:10:04 -0500 Received: from 61.144.161.53 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 8 Dec 2005 05:09:51 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IR6002S5CESU5@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 08 Dec 2005 18:13:40 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IR600LEFCESG7@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 08 Dec 2005 18:13:40 +0800 (CST) Received: from huaweizfbnwhb5 ([10.110.102.51]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IR6003N0CHRXA@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 08 Dec 2005 18:15:28 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <000501c5fbde$e1f839e0$33666e0a@china.huawei.com> Date: Thu, 8 Dec 2005 18:05:13 +0800 Reply-To: Mailing List Sender: Mailing List From: "Abhay D.S" Subject: Re: Gracefu-Restart & RFC 3623 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT Manav, If you followed me right... It is helper receiving order, Grace LSA might be dropped and hello received. Do you think Grace LSA can be sent again after a set of hellos were sent. This way: Send Grace LSA many times... Send Hello to discover neighbors. Send Grace LSA many times..... My idea is if helper knows that the router is graceful restart capable, it would wait a while expecting to receive a Grace LSA, even after seeing a one way hello. Please see my scenario: Congestion Restart Router ---------> Send Grace LSA----->Switch --------Nothing---> Helper Congestion Restart Router---------> Send Grace LSA ------> Switch--Nothing--> Helper Congestion Restart Router---------> Send Grace LSA ------> Switch----Nothing--->Helper Normal Restart Router Has no neighbors ---(assumes all helpers received)---Send Hello ---->Switch------>Hello-->Helper(Down) Abhay -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Manav Bhatia Sent: Thursday, December 08, 2005 5:31 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Gracefu-Restart & RFC 3623 Abhay, !> !> >Why ?. !> >Unassuming.. !> >Case X ) Hello packets will be sent eventually to discover some !> >neighbors ,but what if hello packets are received by some routers !> >before they receive the grace LSA.(Only for unplanned case) !> because of !> >transient network conditions. !> > !> > !> Why would only the grace lsas ( BTW we do send several of them wait !> before sending hellos - !> discussed on this alias in 2001 I believe) get dropped and not the !> subsequent hello packets ? !> !> !> !> Makes me think of a french proverb !> !> "With a lot of ifs you can put Paris in a bottle ...." !> !> These are local link scope - how can you expect the hellos !> to jump ahead !> !> of the grace lsa if you !> implemented it not to be so - unless you have a buggy !> implementation. !> !> Abhay)) You must have heard about packet being dropped(it is !> justified !> in draft,sending several times), and about priority handling of hello !> packets. !> (suggested by folks at AT&T). What really stops an implementation from prioritizing its grace LSAs? :) A proper implementation would IMO correctly handle the grace LSAs in case of an unplanned outage also. Manav ___________________________________________________________ Yahoo! Exclusive Xmas Game, help Santa with his celebrity party - http://santas-christmas-party.yahoo.net/ From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 08 05:10:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkIjW-00025C-G4 for ospf-archive@megatron.ietf.org; Thu, 08 Dec 2005 05:10:38 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23158 for ; Thu, 8 Dec 2005 05:09:44 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <7.00004FC9@wildebeest.ease.lsoft.com>; Thu, 8 Dec 2005 5:10:34 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 92968025 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Dec 2005 05:10:33 -0500 Received: from 143.209.238.162 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 8 Dec 2005 05:10:33 -0500 Received: from mvrelay.mv.usa.alcatel.com (mvrelay.mv.usa.alcatel.com [128.251.10.15]) by audl953.usa.alcatel.com (ALCANET) with ESMTP id jB8AAXcA001602 for ; Thu, 8 Dec 2005 04:10:33 -0600 Received: from SPEEDY1PC (localhost [127.0.0.1]) by mvrelay.mv.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id jB8AAin7029215 for ; Thu, 8 Dec 2005 02:10:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-index: AcX73kbbrByY3tkyRJyJpGAM74f7xQAAC/Ng X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 Message-ID: <200512081010.jB8AAin7029215@mvrelay.mv.usa.alcatel.com> Date: Thu, 8 Dec 2005 02:10:29 -0800 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: Gracefu-Restart & RFC 3623 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000601c5fbdd$89dc0850$3904120a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit In all fairness to all implementations involved in this discussion, we are talking about proposed *standards* not about how best everyone should implement a given protocol. Granted, there are numerous papers, books, studies, etc. that can describe how best to implement a protocol but unless I am mistaken, that is not the charter of the IETF. I believe they leave the "wiggle room" up to the individual vendors on how best to implement against the common set of base standards that are defined on how protocols should and must be implemented. There were a couple comments eariler tonight to this effect when discussing the section on "what constitutes a non-refresh" which most vendors have left up to each other to define. I do agree that something like an exit-reason TLV that is sent out on the wire *may* be a nice enhancement. I see the discussion heading in the wrong direction, so I had to speak up at this late (for me, not for others) hour. Cheers and good night from the states, Don -----Original Message----- From: owner-ospf@PEACH.EASE.LSOFT.COM [mailto:owner-ospf@PEACH.EASE.LSOFT.COM] On Behalf Of sujay Sent: Thursday, December 08, 2005 1:56 AM To: 'Mailing List' Subject: RE: Gracefu-Restart & RFC 3623 Manav: Prioritizing packets , reordering them etc. Is mentioned in the draft-ietf-ospf-scalability. The thought is perhaps of the fine-print with the drafts and RFC's (of what else to do other than sending grace lsa's??) - use a Robustness variable ( already suggested) - use packet prioritization ( not suggested ) - maybe skipped but thought of. - ??? Therefore its nothing to do with implementation details. Talk about implementation I could refer some books. -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Manav Bhatia Sent: Thursday, December 08, 2005 3:01 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Gracefu-Restart & RFC 3623 Abhay, !> !> >Why ?. !> >Unassuming.. !> >Case X ) Hello packets will be sent eventually to discover some !> >neighbors ,but what if hello packets are received by some routers !> >before they receive the grace LSA.(Only for unplanned case) !> because of !> >transient network conditions. !> > !> > !> Why would only the grace lsas ( BTW we do send several of them wait !> before sending hellos - !> discussed on this alias in 2001 I believe) get dropped and not the !> subsequent hello packets ? !> !> !> !> Makes me think of a french proverb !> !> "With a lot of ifs you can put Paris in a bottle ...." !> !> These are local link scope - how can you expect the hellos !> to jump ahead !> !> of the grace lsa if you !> implemented it not to be so - unless you have a buggy !> implementation. !> !> Abhay)) You must have heard about packet being dropped(it is !> justified !> in draft,sending several times), and about priority handling of hello !> packets. !> (suggested by folks at AT&T). What really stops an implementation from prioritizing its grace LSAs? :) A proper implementation would IMO correctly handle the grace LSAs in case of an unplanned outage also. Manav ___________________________________________________________ Yahoo! Exclusive Xmas Game, help Santa with his celebrity party - http://santas-christmas-party.yahoo.net/ From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 08 05:49:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkJL2-0001py-Fs for ospf-archive@megatron.ietf.org; Thu, 08 Dec 2005 05:49:24 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27844 for ; Thu, 8 Dec 2005 05:48:30 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <2.00004FD6@wildebeest.ease.lsoft.com>; Thu, 8 Dec 2005 5:48:51 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 92969804 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Dec 2005 05:48:50 -0500 Received: from 217.12.11.33 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 8 Dec 2005 05:48:49 -0500 Received: (qmail 14430 invoked from network); 8 Dec 2005 10:48:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Received:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:In-Reply-To:X-MimeOLE:Thread-Index; b=CnNuf/lHaAkx8Uhbp6CIEkoHLw3/JjncN2NRQaz9cAxNqrdg4BYUbA5IL1LvjTShMWzokoe9r58j1cKQ3Cqns/hMRMme23LnTkxvTD8qshSRv+cL035S96dswtOQXxvW8/nsSb5ExwS2Wyo8hNK4WX/MXEorgku0luroeYtINhA= ; Received: from unknown (HELO pfloyd) (manav?bhatia06@202.144.106.189 with login) by smtp002.mail.ukl.yahoo.com with SMTP; 8 Dec 2005 10:48:49 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcX73kWp5EG+4nZrR8SdxNOxY4MOVQAAv6jQ Message-ID: Date: Thu, 8 Dec 2005 16:17:10 +0530 Reply-To: Mailing List Sender: Mailing List From: Manav Bhatia Subject: Re: Gracefu-Restart & RFC 3623 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000601c5fbdd$89dc0850$3904120a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Sujay, !> Manav: !> Prioritizing packets , reordering them etc. !> Is mentioned in the draft-ietf-ospf-scalability. RFC4222 to be precise. !> !> The thought is perhaps of the fine-print with the drafts and !> RFC's (of what else to do other than sending grace lsa's??) !> - use a Robustness variable ( already suggested) !> - use packet prioritization ( not suggested ) - maybe skipped but !> thought of. !> - ??? !> I am not sure if I understand your point with "fine-print with drafts, etc." and all. I responded to the post that said: "You must have heard about packet being dropped(it is justified in draft,sending several times), and about priority handling of hello packets. (suggested by folks at AT&T)." Note the "priority handling" part. So, if prioritizing HELLOs is the only problem, then you might as well prioritize your grace LSAs. Simple. !> Therefore its nothing to do with implementation details. !> !> Talk about implementation I could refer some books. I would love to! :) I would agree to Don that we are perhaps heading in the wrong direction! Manav !> !> !> !> -----Original Message----- !> From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On !> Behalf Of Manav !> Bhatia !> Sent: Thursday, December 08, 2005 3:01 PM !> To: OSPF@PEACH.EASE.LSOFT.COM !> Subject: Re: Gracefu-Restart & RFC 3623 !> !> !> Abhay, !> !> !> !> !> >Why ?. !> !> >Unassuming.. !> !> >Case X ) Hello packets will be sent eventually to discover some !> !> >neighbors ,but what if hello packets are received by !> some routers !> !> >before they receive the grace LSA.(Only for unplanned case) !> !> because of !> !> >transient network conditions. !> !> > !> !> > !> !> Why would only the grace lsas ( BTW we do send several of !> them wait !> !> before sending hellos - !> !> discussed on this alias in 2001 I believe) get dropped !> and not the !> !> subsequent hello packets ? !> !> !> !> !> !> !> !> Makes me think of a french proverb !> !> !> !> "With a lot of ifs you can put Paris in a bottle ...." !> !> !> !> These are local link scope - how can you expect the hellos !> !> to jump ahead !> !> !> !> of the grace lsa if you !> !> implemented it not to be so - unless you have a buggy !> !> implementation. !> !> !> !> Abhay)) You must have heard about packet being dropped(it is !> !> justified !> !> in draft,sending several times), and about priority !> handling of hello !> !> packets. !> (suggested by folks at AT&T). !> !> What really stops an implementation from prioritizing its !> grace LSAs? :) !> A proper implementation would IMO correctly handle the grace LSAs in !> case of an unplanned outage also. !> !> Manav !> !> !> !> !> ___________________________________________________________ !> Yahoo! Exclusive Xmas Game, help Santa with his celebrity party - !> http://santas-christmas-party.yahoo.net/ ___________________________________________________________ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 08 12:09:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkPGO-0000Gy-O3 for ospf-archive@megatron.ietf.org; Thu, 08 Dec 2005 12:09:00 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11858 for ; Thu, 8 Dec 2005 12:08:06 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <1.0000504F@wildebeest.ease.lsoft.com>; Thu, 8 Dec 2005 12:08:28 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 92996474 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Dec 2005 12:08:28 -0500 Received: from 171.71.176.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 8 Dec 2005 12:08:26 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 08 Dec 2005 09:08:25 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB8H7xA6014523 for ; Thu, 8 Dec 2005 09:08:23 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 09:08:23 -0800 Received: from [192.168.1.67] ([10.21.122.16]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 09:08:23 -0800 User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Dec 2005 17:08:23.0107 (UTC) FILETIME=[FEEA3130:01C5FC19] Message-ID: <43986886.7010304@cisco.com> Date: Thu, 8 Dec 2005 09:08:22 -0800 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: Gracefu-Restart & RFC 3623 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Agree with you and Don - We are going in the wrong direction discussing how implementation should be done. I am trying hard to avoid discussion on premises that are not fulfilled by an implementation as this is really up to the implementation to achieve it. Trying to sift out what is really spec material here. Padma Manav Bhatia wrote: >Sujay, > >!> Manav: >!> Prioritizing packets , reordering them etc. >!> Is mentioned in the draft-ietf-ospf-scalability. > >RFC4222 to be precise. > >!> >!> The thought is perhaps of the fine-print with the drafts and >!> RFC's (of what else to do other than sending grace lsa's??) >!> - use a Robustness variable ( already suggested) >!> - use packet prioritization ( not suggested ) - maybe skipped but >!> thought of. >!> - ??? >!> > >I am not sure if I understand your point with "fine-print with drafts, etc." >and all. I responded to the post that said: > >"You must have heard about packet being dropped(it is justified in >draft,sending several times), and about priority handling of hello packets. >(suggested by folks at AT&T)." > >Note the "priority handling" part. So, if prioritizing HELLOs is the only >problem, then you might as well prioritize your grace LSAs. Simple. > >!> Therefore its nothing to do with implementation details. >!> >!> Talk about implementation I could refer some books. > >I would love to! :) > >I would agree to Don that we are perhaps heading in the wrong direction! > >Manav > >!> >!> >!> >!> -----Original Message----- >!> From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On >!> Behalf Of Manav >!> Bhatia >!> Sent: Thursday, December 08, 2005 3:01 PM >!> To: OSPF@PEACH.EASE.LSOFT.COM >!> Subject: Re: Gracefu-Restart & RFC 3623 >!> >!> >!> Abhay, >!> >!> !> >!> !> >Why ?. >!> !> >Unassuming.. >!> !> >Case X ) Hello packets will be sent eventually to discover some >!> !> >neighbors ,but what if hello packets are received by >!> some routers >!> !> >before they receive the grace LSA.(Only for unplanned case) >!> !> because of >!> !> >transient network conditions. >!> !> > >!> !> > >!> !> Why would only the grace lsas ( BTW we do send several of >!> them wait >!> !> before sending hellos - >!> !> discussed on this alias in 2001 I believe) get dropped >!> and not the >!> !> subsequent hello packets ? >!> !> >!> !> >!> !> >!> !> Makes me think of a french proverb >!> !> >!> !> "With a lot of ifs you can put Paris in a bottle ...." >!> !> >!> !> These are local link scope - how can you expect the hellos >!> !> to jump ahead >!> !> >!> !> of the grace lsa if you >!> !> implemented it not to be so - unless you have a buggy >!> !> implementation. >!> !> >!> !> Abhay)) You must have heard about packet being dropped(it is >!> !> justified >!> !> in draft,sending several times), and about priority >!> handling of hello >!> !> packets. !> (suggested by folks at AT&T). >!> >!> What really stops an implementation from prioritizing its >!> grace LSAs? :) >!> A proper implementation would IMO correctly handle the grace LSAs in >!> case of an unplanned outage also. >!> >!> Manav >!> >!> >!> >!> >!> ___________________________________________________________ >!> Yahoo! Exclusive Xmas Game, help Santa with his celebrity party - >!> http://santas-christmas-party.yahoo.net/ > > > >___________________________________________________________ >How much free photo storage do you get? Store your holiday >snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 08 14:41:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkRe9-0000UN-TM for ospf-archive@megatron.ietf.org; Thu, 08 Dec 2005 14:41:41 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01408 for ; Thu, 8 Dec 2005 14:40:40 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <13.000050A8@wildebeest.ease.lsoft.com>; Thu, 8 Dec 2005 14:41:01 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93009240 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Dec 2005 14:41:01 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 8 Dec 2005 14:41:00 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 08 Dec 2005 14:41:01 -0500 X-IronPort-AV: i="3.99,231,1131339600"; d="scan'208"; a="77405504:sNHT39240378" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB8Jel4j006123 for ; Thu, 8 Dec 2005 14:40:58 -0500 (EST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 14:40:37 -0500 Received: from [10.82.208.191] ([10.82.208.191]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 14:40:37 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <000401c5fbdc$b46741d0$33666e0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Dec 2005 19:40:37.0284 (UTC) FILETIME=[434EFE40:01C5FC2F] Message-ID: <43988C34.1050108@cisco.com> Date: Thu, 8 Dec 2005 14:40:36 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Gracefu-Restart & RFC 3623 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000401c5fbdc$b46741d0$33666e0a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit I meant to read this whole E-mail thread before responding but I'll respond to the discussion immediately. In practice, do any network operators see graceful restart failing due failure to receive grace LSAs prior to a hello? Heretofore, I haven't heard this complaint. If this were to happen, it would imply a somewhat fragile network and I'm not so sure we'd want restart gracefully anyway (assuming the restarting router has delayed sending its first hello a sufficient amount of time and flooded the grace LSAs a couple times as suggested by RFC 3623). If we graceful restart does need to solve this problem and we need a more reliable mechanism (which is yet to be proved), then I don't think we should build a request/response mechanism into the LSAs. Rather, we should migrate to Link Local Signaling (LLS) which we are will be needed for the OSPF MANET extensions anyway (one of the common design points of every flooding reduction proposal is that it uses LLS). http://www.ietf.org/internet-drafts/draft-nguyen-ospf-lls-05.txt Thanks, Acee Abhay D.S wrote: >Hi Padma ! > >IMHO >We all want to have a KISS implementation(Keep It Simple Stupid). > >But it is useful only for demonstration not practical. > >You have no proof to say Grace TLV can be received before receiving >Hello. > >One case: >In unplanned case, RFC implementation keeps sending grace TLV to all >neighbors, assuming that they have received the TLV.We never >Wait for an ACK from all neighbors, since we don't know who they were. > >And then send hello to discover neighbors. > > >But one end is a remote router which failed to receive Grace LSA(what >ever reason,overloaded,dropped due to >packet type scheduling). If hello reached the router,What to do ? > >How about prioritized handling of hello packets many high energy vendors >implement. > >How to inter-operate with them ? > >Yes in a four router setup, agreed, but not in large networks, you have >to consider packet scheduling and router backplane architectures. > >Please, im talking only about helper router being in danger of receiving >out of turn >Hello. > >On restart router, this can be controlled to send Grace LSA. > >We know our packets well. We also have to consider network conditions. > >Demonstrability is a requirement for OSPF GR, Usability is the highest >priority than >Demonstrability. > >Abhay > > > > > > > > > > > > > > > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Padma >Pillay-Esnault >Sent: Thursday, December 08, 2005 5:18 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: Gracefu-Restart & RFC 3623 > > >Abhay D.S wrote: > > > >>Hi padma !. >>Your proverbs are enjoyable ! :-). >> >> >> >> >Glad you like them > >The original in french "Avec des si on metterait Paris en bouteille." > >responses below > > > >>However, please read inline and think >>im your customer !(ends at the moment >>we start thinking about revisiting standardization). >> >> >> >>-----Original Message----- >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >>Padma Pillay-Esnault >>Sent: Thursday, December 08, 2005 3:03 PM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Re: Gracefu-Restart & RFC 3623 >> >> >>Abhay D.S wrote: >> >> >> >> >> >>>Hi Padma !, >>>IMHO. >>>Section 5 has an avoidance approach not preventive. >>> >>> >>> >>> >>> >>> >> >>Yes there is "no" support. >> >>Humm ... >>You said there is "no" support - and now you say it is avoidance. >> >>I missing something. Not sure I understand what is avoidance and what >>is >> >>preventive ? >> >>Can you prevent/avoid a crash ? :-) >> >> >> >> >>Abhay)) Yes RFC does not have a mechanism to prevent neighbors from >>getting down due to receiving hello. Do you remember the robustness >>variable ?(This is what is avoidance).(Hope you understand and not >>mislead yourself into thinking what RFC says is perfect,everybody loves >>their babies). >> >> >> >> >> >PPE - > > Robustness variable - yeah - send as many grace lsa you think before >you send >your hellos - when I think that we have feature out now that demands to >send packets >asap and no drops - but just grace lsa would get dropped !! I don't buy >your argument. > >If your robustness variable is good enough that is prevention. > > > >>Unplanned restart: Why do you think grace LSA cannot be dropped and >>hello packets be received in case of unplanned restart,we have still >>not discovered our neighbors. >> >> >> >> >> >PPE - what makes you think that only these lsa will get dropped ? > >I think that you are being biased here - lo! all my grace lsa - for 5 s >got dropped but lo and behold >all my hellos got thru - well something is wrong and we never said that >this should work on faulty >equipment did we ? > > > >>In planned case I agree that grace LSA's will be received by all >>neighbors before sending hello. >> >> >> >> >> >> >>>Why ?. >>>Unassuming.. >>>Case X ) Hello packets will be sent eventually to discover some >>>neighbors ,but what if hello packets are received by some routers >>>before they receive the grace LSA.(Only for unplanned case) because of >>> >>> > > > >>>transient network conditions. >>> >>> >>> >>> >>> >>> >>Why would only the grace lsas ( BTW we do send several of them wait >>before sending hellos - >>discussed on this alias in 2001 I believe) get dropped and not the >>subsequent hello packets ? >> >> >> >>Makes me think of a french proverb >> >>"With a lot of ifs you can put Paris in a bottle ...." >> >>These are local link scope - how can you expect the hellos to jump >>ahead >> >>of the grace lsa if you >>implemented it not to be so - unless you have a buggy implementation. >> >>Abhay)) You must have heard about packet being dropped(it is justified >>in draft,sending several times), and about priority handling of hello >>packets. (suggested by folks at AT&T). >> >> >> >> >> >PPE - this is what I call implementation details- if you write get the >grace out first - just do it ! >or else you have a buggy implementation of the feature. Suggestion -use > >the pak priority right :-) > > > >>>Case Y) Due to load of neighbors, restart router feels it needs more >>>time to complete Graceful restart. >>> >>> >>> >>> >>> >>> >>> >>The router does not feel - you configure it :-) >> >>Abhay)) I need an router with extra intelligence. As you know that GR >>deployment is critical in PE's. Feeling is better than configuring it >>and then saying sorry "we will come up with something soon, I beg you". >> >> > > > >>Configuration is for stable toplogies. >> >> >> >> >> >> >PPE - > >I never saw my routers beg :-) Gosh your routers are really different >from mine !! :-) > >Restart with PE could have a very large value - under 1 hr theoretically > >- and an implementation exit >GR as soon as it has completed. Simple and robust. >( Though I don't recommend 1 hr ! - I have done enough of profiling on >this one to >find a suitable value!) > >So what do you suggest evaluate DB size. number of routers, may be mtu, >may be link robustness and >get some number ? How do you evaluate for those famous packet drops ? >:-) Renegotiate the time ? By how much - how are you going to "feel" >when >you are done ? >What are the criterias ? > >Do really want to go there ? > >I know how to do complex but aim for simplicity. > > > >>>In case of unplanned restart(crash on router processer) >>>Voice over IP call is still running. Do >>> >>> >>> > > > >>>we want to exit >>>Helper mode and get routes down ?. (Case X).Voice call >>>is down. >>> >>> >>> >>> >>> >>> >>> >>I am missing your point ..... >> >>Unlikely case X ( hellos ahead of grace) and the helper exit - why ? >> >>Abhay)) It is possible in unplanned case, think more....see reason >> >> >given > > >>Above. >> >> >> >> >> >> >PPE - sorry I must be slow. I think that a good implementation should >avoid X from there nothing >makes sense anymore. It's like saying I have OSPF but I can't have >multicast ... the basic premise is >broken - all kinds of speculations are open. Well don't break the >premise and it will work. >Further more the restarting router control the premise and can make sure > >it is not broken. > >Are you trying to say the GR router send a hello then a grace ? - but >the hello should have torn >down the adj - the other router is not even a helper at that point as it > >will receive a hello >with no nbr - which will cause a adjacency recycle. > > > >>>Do you feel OSPF capabilities specification can help provide >>>a solution to ISP ?. Im keeping in mind the options some graph experts >>> >>> > > > >>>had suggested about configuration of exiting helper mode. But that did >>> >>> > > > >>>not cover case X.. >>> >>>Another, Grace period should be able to be changed dynamically, >>>depending on restarting routers load, and period should be derived >>> >>> >from > > >>> >>> >>> >>> >> >> >> >> >>>a standardized function.(Case y) >>> >>> >>> >>> >>> >>> >>> >>> >>Actually GR can configured to be a very long period and a good >>implementation will get end as soon as it >>is ready. This is the approach in my implementation, let's call it >>intuitively dynamic and you >>don't even have to add extra config. >> >>Abhay)) Do you think all vendors run the same type of mechanisms ?. >>But just above you said it can be configured ??. >> >> >> >> >PPE - > >Implementation detail - you don't need a spec for that. >I am sure you can figure it out. > > > >> >> >> >> >>>If I was a ISP operator, I would not refuse all of these .... :-). >>> >>> >>> >>> >>> >>> >>I think you already have these :-) >> >>Padma >> >>Abhay)) Im still not satisfied, I cannot buy your RFC. :-). Please >>improve >>section 5 and I will think about it. >> >> >> >> >> >PPE > >See my comments above > >Improve yes as long as it stays simple and robust and usable >but brew coffee don't think so :-) > > >Padma > > > >>>Abhay >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>-----Original Message----- >>>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >>>Padma Pillay-Esnault >>>Sent: Thursday, December 08, 2005 2:10 PM >>>To: OSPF@PEACH.EASE.LSOFT.COM >>>Subject: Re: Gracefu-Restart & RFC 3623 >>> >>> >>>See PPE for comments >>> >>>Abhay D.S wrote: >>> >>> >>> >>> >>> >>> >>> >>>>Importance: Normal >>>>X-Priority: 3 (Normal) >>>>X-MSMail-priority: Normal >>>> >>>> >>>>With a foresight..and with concerns..as a reviewer >>>>for "Update to graceful restart draft". >>>> >>>>Making a case for revisiting standardization: >>>> >>>>Standardization has to be 'revisited' and in the pipeline, since >>>> >>>> >"OSPF > > >>>>Capabilities" draft which mentions about graceful Restart capable, >>>>helper capable option advertisements are 'useful' in making Graceful >>>>restart more robust. >>>> >>>>The original RFC still lacks the solution for unplanned restarts. (Do >>>>you think this the USP for vendors ?):-| >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>PPE: >>> >>>What ? I beg to differ. >>> >>>What about section 5 - Unplanned Outages ? >>> >>> >>> >>> >>> >>> >>> >>>>OSPF Capabilities draft can address many issues faced >>>>by service providers deploying graceful restart. >>>> >>>>Im also considering the possibility of using a different >>>>OSPF version number for some special scenarios. >>>> >>>>Abhay >>>> >>>> >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >>>> >>>> >Don > > >>>>Goodspeed >>>>Sent: Thursday, December 08, 2005 4:06 AM >>>>To: OSPF@PEACH.EASE.LSOFT.COM >>>>Subject: Re: Gracefu-Restart & RFC 3623 >>>> >>>> >>>>Having helped review the original RFC during its draft >>>>stage, this draft looks like a sound one but this would probably best >>>>be addressed by contacting the original authors of the RFC and >>>>co-authoring a revised Graceful OSPF Restart draft rather than having >>>> >>>> > > > >>>>the original one and an "enhancement". >>>> >>>>Broadcasting this to the list seems like you did not contact them. >>>> >>>>Just my observations, >>>>Don >>>> >>>>-----Original Message----- >>>>From: owner-ospf@PEACH.EASE.LSOFT.COM >>>>[mailto:owner-ospf@PEACH.EASE.LSOFT.COM] On Behalf Of sujay >>>>Sent: Tuesday, December 06, 2005 10:59 PM >>>>To: 'Mailing List' >>>>Subject: Gracefu-Restart & RFC 3623 >>>> >>>>Group, >>>> >>>>In reference to; >>>>Moy, J.,P. Pillay-Esnault,A. Lindem, "Graceful OSPF Restart", RFC >>>>3623, >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>>>November 2003. >>>> >>>>There are certain areas which could be worked upon; >>>> >>>>1. The conservative behavior of the Restarting router; >>>>- in its reaction on reception of any new lsa where it *always* exits >>>>the graceful restart, this behavior may be optimized such that the >>>>Restarting router exits GR iff the new lsa actually implies a change >>>> >>>> >>>> >>>> >>in >> >> >> >> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>>>the topology >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>PPE : >>> >>> >>>AFAIK Major vendors already implement "non-strict lsa checking" for >>> >>> >the > > >>>restarting router and I have >>>already discussed this on this alias (I seem to recall) way back. I >>> >>> >did > > >>>not agree then for strict-lsa checking and I still don't as it is >>>restrictive. >>> >>>Several reasons >>>In a fairly large topology, it going to be impractical. >>>Is it worth it to exit GR because a acquired a new previously unknown >>>neighbor ? >>> >>> >>> >>>From day 1, my implementation did not support strict lsa checks. The >> >> >>>graceful restart implementation report mentions >>> >>> >non-strict-lsa-checking > > >>> >>> >>> >>> >> >> >> >> >>>as well. >>> >>>This is an implementation decision and does not require helpers to >>>agree >>> >>>on the behavior. >>> >>> >>> >>> >>> >>> >>> >>>>2. A helper router on the presence of non-refresh lsa's in the >>>>retransmit list to the restarting router *always* exits as a gr >>>> >>>> >helper > > >>>>- this reaction again can be ratified only if the lsa's actually >>>> >>>> >>>> >>>> >>>> >>>> >>>specify >>> >>> >>> >>> >>> >>> >>>>a topology change. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>PPE : >>>Please see section B2. >>> >>>The RFC already has the non-strict-lsa-checking option - which I >>>believe >>> >>>goes hand in hand - removing strict lsa checking everywhere ( both the >>>GR and helper). At least this was the intention of this author. >>> >>> >>> >>> >>> >>> >>> >>>>3. The restarting router detects non participating helpers only via >>>>the >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>>>back link checks In the router and network lsa's >>>>- this behavior again may lead to network inconsistency for some >>>> >>>> >time, > > >>>> >>>> >>>> >>>> >> >> >> >> >>>>perhaps an explicit notification from the helper router to the >>>>restarting router could be thought of. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>PPE. >>> >>>Please see 2.1 last sentence. >>> >>>What are you trying to achieve here ? >>>- if there is no helper (router doesn't understand grace or refuses to >>>act as helper) >>>there is no way you are going to achieve graceful restart anyway. >>>- that the rebooting GR router continues to do so is not a problem >>> >>> >and > > >>> >>> >>> >>> >> >> >> >> >>>you are going to drop >>>packets - just as expected. >>> >>>Are you proposing to stop graceful restart if you cannot achieve it ? >>>What would be the benefit ? >>>as you will then attempt a non-graceful one and drop packets anyway. >>> >>> >>> >>> >>> >>> >>> >>>>With the above optimizations as well keeping it downwardly >>>> >>>> >compatible, > > >>>> >>>> >>>> >>>> >> >> >> >> >>>>there are a few pointers to rectify (1) and (2) above using "Topology >>>> >>>> > > > >>>>change Lsa's" and >>>>(3) using " Exit-Grace LSA TLV" >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>I don't agree that these optimizations are extensions to the original >>>draft. >>> >>>- (1) non-strict lsa checking is already mentioned - maybe not as >>>clearly as one would wish >>>- (2) -is already mentioned see section B.2 >>>- (3) - see my above comment >>> >>>my 2 cts >>> >>>Padma >>> >>> >>> >>> >>> >>> >>> >>>>Where in short "Topology change LSA's" is the group of LSA's which >>>>*actually* signify a Topology change >>>>And "Exit Grace LSA TLV" is an additional TLV in existing Grace LSA >>>>which the router may use to indicate Its non-particiation as a >>>> >>>> >helper. > > >>>>The above has been documented at; >>>>www.ietf.org/internet-drafts/draft-holla-ospf-update-graceful-restart >>>> >>>> >- > > >>>> >>>> >>>> >>>> >>0 >> >> >> >> >>>>0 >>>>.txt >>>> >>>>While the implementation issues is not much of a hassle and there is >>>>at >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>>>least one vendor likely to support it request your views on the same. >>>> >>>>Sujay etc. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 08 21:18:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkXq7-00009X-V2 for ospf-archive@megatron.ietf.org; Thu, 08 Dec 2005 21:18:30 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21872 for ; Thu, 8 Dec 2005 21:17:26 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <13.0000519D@wildebeest.ease.lsoft.com>; Thu, 8 Dec 2005 21:17:47 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93036109 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Dec 2005 21:17:47 -0500 Received: from 61.144.161.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 8 Dec 2005 21:17:45 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IR70018HL7RF1@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 09 Dec 2005 10:21:28 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IR700L4PL7NF1@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 09 Dec 2005 10:21:27 +0800 (CST) Received: from huaweizfbnwhb5 ([10.110.102.51]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IR700D3FLD54W@szxml01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 09 Dec 2005 10:24:43 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <000801c5fc65$cc7a7100$33666e0a@china.huawei.com> Date: Fri, 9 Dec 2005 10:10:59 +0800 Reply-To: Mailing List Sender: Mailing List From: "Abhay D.S" Subject: Re: Gracefu-Restart & RFC 3623 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43988C34.1050108@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT Acee,Padma,Don, et al... My idea is a standardization for Graceful restart, not modification to RFC 3623. It should generalize all the facts and quote some usable mechanisms,LLS or request/reply. MANET has LLS, so reuse it for GR again ?. Implementation and Standardization go hand in hand.(Implementation need not be discussed) and I think it is *wrong* ...to say discussions about draft shortcomings are discussion of implementations. OSPF WG is one such body where discussions of all sort happen,it gives important to WG. Otherwise WG is useless. We also can do it our own way,but we also want to see what the WG thinks. We want a common set of agreed rules. Thanks, Abhay -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee Lindem Sent: Friday, December 09, 2005 3:41 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Gracefu-Restart & RFC 3623 I meant to read this whole E-mail thread before responding but I'll respond to the discussion immediately. In practice, do any network operators see graceful restart failing due failure to receive grace LSAs prior to a hello? Heretofore, I haven't heard this complaint. If this were to happen, it would imply a somewhat fragile network and I'm not so sure we'd want restart gracefully anyway (assuming the restarting router has delayed sending its first hello a sufficient amount of time and flooded the grace LSAs a couple times as suggested by RFC 3623). If we graceful restart does need to solve this problem and we need a more reliable mechanism (which is yet to be proved), then I don't think we should build a request/response mechanism into the LSAs. Rather, we should migrate to Link Local Signaling (LLS) which we are will be needed for the OSPF MANET extensions anyway (one of the common design points of every flooding reduction proposal is that it uses LLS). http://www.ietf.org/internet-drafts/draft-nguyen-ospf-lls-05.txt Thanks, Acee Abhay D.S wrote: >Hi Padma ! > >IMHO >We all want to have a KISS implementation(Keep It Simple Stupid). > >But it is useful only for demonstration not practical. > >You have no proof to say Grace TLV can be received before receiving >Hello. > >One case: >In unplanned case, RFC implementation keeps sending grace TLV to all >neighbors, assuming that they have received the TLV.We never >Wait for an ACK from all neighbors, since we don't know who they were. > >And then send hello to discover neighbors. > > >But one end is a remote router which failed to receive Grace LSA(what >ever reason,overloaded,dropped due to packet type scheduling). If hello >reached the router,What to do ? > >How about prioritized handling of hello packets many high energy >vendors implement. > >How to inter-operate with them ? > >Yes in a four router setup, agreed, but not in large networks, you have >to consider packet scheduling and router backplane architectures. > >Please, im talking only about helper router being in danger of >receiving out of turn Hello. > >On restart router, this can be controlled to send Grace LSA. > >We know our packets well. We also have to consider network conditions. > >Demonstrability is a requirement for OSPF GR, Usability is the highest >priority than Demonstrability. > >Abhay > > > > > > > > > > > > > > > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >Padma Pillay-Esnault >Sent: Thursday, December 08, 2005 5:18 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: Gracefu-Restart & RFC 3623 > > >Abhay D.S wrote: > > > >>Hi padma !. >>Your proverbs are enjoyable ! :-). >> >> >> >> >Glad you like them > >The original in french "Avec des si on metterait Paris en bouteille." > >responses below > > > >>However, please read inline and think >>im your customer !(ends at the moment >>we start thinking about revisiting standardization). >> >> >> >>-----Original Message----- >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >>Padma Pillay-Esnault >>Sent: Thursday, December 08, 2005 3:03 PM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Re: Gracefu-Restart & RFC 3623 >> >> >>Abhay D.S wrote: >> >> >> >> >> >>>Hi Padma !, >>>IMHO. >>>Section 5 has an avoidance approach not preventive. >>> >>> >>> >>> >>> >>> >> >>Yes there is "no" support. >> >>Humm ... >>You said there is "no" support - and now you say it is avoidance. >> >>I missing something. Not sure I understand what is avoidance and what >>is >> >>preventive ? >> >>Can you prevent/avoid a crash ? :-) >> >> >> >> >>Abhay)) Yes RFC does not have a mechanism to prevent neighbors from >>getting down due to receiving hello. Do you remember the robustness >>variable ?(This is what is avoidance).(Hope you understand and not >>mislead yourself into thinking what RFC says is perfect,everybody loves >>their babies). >> >> >> >> >> >PPE - > > Robustness variable - yeah - send as many grace lsa you think before >you send >your hellos - when I think that we have feature out now that demands to >send packets >asap and no drops - but just grace lsa would get dropped !! I don't buy >your argument. > >If your robustness variable is good enough that is prevention. > > > >>Unplanned restart: Why do you think grace LSA cannot be dropped and >>hello packets be received in case of unplanned restart,we have still >>not discovered our neighbors. >> >> >> >> >> >PPE - what makes you think that only these lsa will get dropped ? > >I think that you are being biased here - lo! all my grace lsa - for 5 s >got dropped but lo and behold >all my hellos got thru - well something is wrong and we never said that >this should work on faulty >equipment did we ? > > > >>In planned case I agree that grace LSA's will be received by all >>neighbors before sending hello. >> >> >> >> >> >> >>>Why ?. >>>Unassuming.. >>>Case X ) Hello packets will be sent eventually to discover some >>>neighbors ,but what if hello packets are received by some routers >>>before they receive the grace LSA.(Only for unplanned case) because >>>of >>> >>> > > > >>>transient network conditions. >>> >>> >>> >>> >>> >>> >>Why would only the grace lsas ( BTW we do send several of them wait >>before sending hellos - discussed on this alias in 2001 I believe) get >>dropped and not the subsequent hello packets ? >> >> >> >>Makes me think of a french proverb >> >>"With a lot of ifs you can put Paris in a bottle ...." >> >>These are local link scope - how can you expect the hellos to jump >>ahead >> >>of the grace lsa if you >>implemented it not to be so - unless you have a buggy implementation. >> >>Abhay)) You must have heard about packet being dropped(it is justified >>in draft,sending several times), and about priority handling of hello >>packets. (suggested by folks at AT&T). >> >> >> >> >> >PPE - this is what I call implementation details- if you write get the >grace out first - just do it ! >or else you have a buggy implementation of the feature. Suggestion -use > >the pak priority right :-) > > > >>>Case Y) Due to load of neighbors, restart router feels it needs more >>>time to complete Graceful restart. >>> >>> >>> >>> >>> >>> >>> >>The router does not feel - you configure it :-) >> >>Abhay)) I need an router with extra intelligence. As you know that GR >>deployment is critical in PE's. Feeling is better than configuring it >>and then saying sorry "we will come up with something soon, I beg you". >> >> > > > >>Configuration is for stable toplogies. >> >> >> >> >> >> >PPE - > >I never saw my routers beg :-) Gosh your routers are really different >from mine !! :-) > >Restart with PE could have a very large value - under 1 hr >theoretically > >- and an implementation exit >GR as soon as it has completed. Simple and robust. >( Though I don't recommend 1 hr ! - I have done enough of profiling on >this one to >find a suitable value!) > >So what do you suggest evaluate DB size. number of routers, may be mtu, >may be link robustness and >get some number ? How do you evaluate for those famous packet drops ? >:-) Renegotiate the time ? By how much - how are you going to "feel" >when >you are done ? >What are the criterias ? > >Do really want to go there ? > >I know how to do complex but aim for simplicity. > > > >>>In case of unplanned restart(crash on router processer) Voice over IP >>>call is still running. Do >>> >>> >>> > > > >>>we want to exit >>>Helper mode and get routes down ?. (Case X).Voice call >>>is down. >>> >>> >>> >>> >>> >>> >>> >>I am missing your point ..... >> >>Unlikely case X ( hellos ahead of grace) and the helper exit - why ? >> >>Abhay)) It is possible in unplanned case, think more....see reason >> >> >given > > >>Above. >> >> >> >> >> >> >PPE - sorry I must be slow. I think that a good implementation should >avoid X from there nothing >makes sense anymore. It's like saying I have OSPF but I can't have >multicast ... the basic premise is >broken - all kinds of speculations are open. Well don't break the >premise and it will work. >Further more the restarting router control the premise and can make sure > >it is not broken. > >Are you trying to say the GR router send a hello then a grace ? - but >the hello should have torn >down the adj - the other router is not even a helper at that point as it > >will receive a hello >with no nbr - which will cause a adjacency recycle. > > > >>>Do you feel OSPF capabilities specification can help provide a >>>solution to ISP ?. Im keeping in mind the options some graph experts >>> >>> > > > >>>had suggested about configuration of exiting helper mode. But that >>>did >>> >>> > > > >>>not cover case X.. >>> >>>Another, Grace period should be able to be changed dynamically, >>>depending on restarting routers load, and period should be derived >>> >>> >from > > >>> >>> >>> >>> >> >> >> >> >>>a standardized function.(Case y) >>> >>> >>> >>> >>> >>> >>> >>> >>Actually GR can configured to be a very long period and a good >>implementation will get end as soon as it >>is ready. This is the approach in my implementation, let's call it >>intuitively dynamic and you >>don't even have to add extra config. >> >>Abhay)) Do you think all vendors run the same type of mechanisms ?. >>But just above you said it can be configured ??. >> >> >> >> >PPE - > >Implementation detail - you don't need a spec for that. >I am sure you can figure it out. > > > >> >> >> >> >>>If I was a ISP operator, I would not refuse all of these .... :-). >>> >>> >>> >>> >>> >>> >>I think you already have these :-) >> >>Padma >> >>Abhay)) Im still not satisfied, I cannot buy your RFC. :-). Please >>improve section 5 and I will think about it. >> >> >> >> >> >PPE > >See my comments above > >Improve yes as long as it stays simple and robust and usable but brew >coffee don't think so :-) > > >Padma > > > >>>Abhay >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>-----Original Message----- >>>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >>>Padma Pillay-Esnault >>>Sent: Thursday, December 08, 2005 2:10 PM >>>To: OSPF@PEACH.EASE.LSOFT.COM >>>Subject: Re: Gracefu-Restart & RFC 3623 >>> >>> >>>See PPE for comments >>> >>>Abhay D.S wrote: >>> >>> >>> >>> >>> >>> >>> >>>>Importance: Normal >>>>X-Priority: 3 (Normal) >>>>X-MSMail-priority: Normal >>>> >>>> >>>>With a foresight..and with concerns..as a reviewer >>>>for "Update to graceful restart draft". >>>> >>>>Making a case for revisiting standardization: >>>> >>>>Standardization has to be 'revisited' and in the pipeline, since >>>> >>>> >"OSPF > > >>>>Capabilities" draft which mentions about graceful Restart capable, >>>>helper capable option advertisements are 'useful' in making Graceful >>>>restart more robust. >>>> >>>>The original RFC still lacks the solution for unplanned restarts. >>>>(Do you think this the USP for vendors ?):-| >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>PPE: >>> >>>What ? I beg to differ. >>> >>>What about section 5 - Unplanned Outages ? >>> >>> >>> >>> >>> >>> >>> >>>>OSPF Capabilities draft can address many issues faced >>>>by service providers deploying graceful restart. >>>> >>>>Im also considering the possibility of using a different OSPF >>>>version number for some special scenarios. >>>> >>>>Abhay >>>> >>>> >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >>>> >>>> >Don > > >>>>Goodspeed >>>>Sent: Thursday, December 08, 2005 4:06 AM >>>>To: OSPF@PEACH.EASE.LSOFT.COM >>>>Subject: Re: Gracefu-Restart & RFC 3623 >>>> >>>> >>>>Having helped review the original RFC during its draft stage, this >>>>draft looks like a sound one but this would probably best be >>>>addressed by contacting the original authors of the RFC and >>>>co-authoring a revised Graceful OSPF Restart draft rather than >>>>having >>>> >>>> > > > >>>>the original one and an "enhancement". >>>> >>>>Broadcasting this to the list seems like you did not contact them. >>>> >>>>Just my observations, >>>>Don >>>> >>>>-----Original Message----- >>>>From: owner-ospf@PEACH.EASE.LSOFT.COM >>>>[mailto:owner-ospf@PEACH.EASE.LSOFT.COM] On Behalf Of sujay >>>>Sent: Tuesday, December 06, 2005 10:59 PM >>>>To: 'Mailing List' >>>>Subject: Gracefu-Restart & RFC 3623 >>>> >>>>Group, >>>> >>>>In reference to; >>>>Moy, J.,P. Pillay-Esnault,A. Lindem, "Graceful OSPF Restart", RFC >>>>3623, >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>>>November 2003. >>>> >>>>There are certain areas which could be worked upon; >>>> >>>>1. The conservative behavior of the Restarting router; >>>>- in its reaction on reception of any new lsa where it *always* >>>>exits the graceful restart, this behavior may be optimized such that >>>>the Restarting router exits GR iff the new lsa actually implies a >>>>change >>>> >>>> >>>> >>>> >>in >> >> >> >> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>>>the topology >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>PPE : >>> >>> >>>AFAIK Major vendors already implement "non-strict lsa checking" for >>> >>> >the > > >>>restarting router and I have >>>already discussed this on this alias (I seem to recall) way back. I >>> >>> >did > > >>>not agree then for strict-lsa checking and I still don't as it is >>>restrictive. >>> >>>Several reasons >>>In a fairly large topology, it going to be impractical. >>>Is it worth it to exit GR because a acquired a new previously unknown >>>neighbor ? >>> >>> >>> >>>From day 1, my implementation did not support strict lsa checks. The >> >> >>>graceful restart implementation report mentions >>> >>> >non-strict-lsa-checking > > >>> >>> >>> >>> >> >> >> >> >>>as well. >>> >>>This is an implementation decision and does not require helpers to >>>agree >>> >>>on the behavior. >>> >>> >>> >>> >>> >>> >>> >>>>2. A helper router on the presence of non-refresh lsa's in the >>>>retransmit list to the restarting router *always* exits as a gr >>>> >>>> >helper > > >>>>- this reaction again can be ratified only if the lsa's actually >>>> >>>> >>>> >>>> >>>> >>>> >>>specify >>> >>> >>> >>> >>> >>> >>>>a topology change. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>PPE : >>>Please see section B2. >>> >>>The RFC already has the non-strict-lsa-checking option - which I >>>believe >>> >>>goes hand in hand - removing strict lsa checking everywhere ( both >>>the GR and helper). At least this was the intention of this author. >>> >>> >>> >>> >>> >>> >>> >>>>3. The restarting router detects non participating helpers only via >>>>the >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>>>back link checks In the router and network lsa's >>>>- this behavior again may lead to network inconsistency for some >>>> >>>> >time, > > >>>> >>>> >>>> >>>> >> >> >> >> >>>>perhaps an explicit notification from the helper router to the >>>>restarting router could be thought of. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>PPE. >>> >>>Please see 2.1 last sentence. >>> >>>What are you trying to achieve here ? >>>- if there is no helper (router doesn't understand grace or refuses >>>to act as helper) there is no way you are going to achieve graceful >>>restart anyway. >>>- that the rebooting GR router continues to do so is not a problem >>> >>> >and > > >>> >>> >>> >>> >> >> >> >> >>>you are going to drop >>>packets - just as expected. >>> >>>Are you proposing to stop graceful restart if you cannot achieve it ? >>>What would be the benefit ? as you will then attempt a non-graceful >>>one and drop packets anyway. >>> >>> >>> >>> >>> >>> >>> >>>>With the above optimizations as well keeping it downwardly >>>> >>>> >compatible, > > >>>> >>>> >>>> >>>> >> >> >> >> >>>>there are a few pointers to rectify (1) and (2) above using >>>>"Topology >>>> >>>> > > > >>>>change Lsa's" and >>>>(3) using " Exit-Grace LSA TLV" >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>I don't agree that these optimizations are extensions to the original >>>draft. >>> >>>- (1) non-strict lsa checking is already mentioned - maybe not as >>>clearly as one would wish >>>- (2) -is already mentioned see section B.2 >>>- (3) - see my above comment >>> >>>my 2 cts >>> >>>Padma >>> >>> >>> >>> >>> >>> >>> >>>>Where in short "Topology change LSA's" is the group of LSA's which >>>>*actually* signify a Topology change >>>>And "Exit Grace LSA TLV" is an additional TLV in existing Grace LSA >>>>which the router may use to indicate Its non-particiation as a >>>> >>>> >helper. > > >>>>The above has been documented at; >>>>www.ietf.org/internet-drafts/draft-holla-ospf-update-graceful-restar >>>>t >>>> >>>> >- > > >>>> >>>> >>>> >>>> >>0 >> >> >> >> >>>>0 >>>>.txt >>>> >>>>While the implementation issues is not much of a hassle and there is >>>>at >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>>>least one vendor likely to support it request your views on the >>>>same. >>>> >>>>Sujay etc. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 08 21:37:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkY8V-0007UO-5M for ospf-archive@megatron.ietf.org; Thu, 08 Dec 2005 21:37:27 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23815 for ; Thu, 8 Dec 2005 21:36:26 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <4.000051A9@wildebeest.ease.lsoft.com>; Thu, 8 Dec 2005 21:36:48 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93037531 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Dec 2005 21:36:47 -0500 Received: from 171.71.176.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 8 Dec 2005 21:36:47 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 08 Dec 2005 18:36:46 -0800 X-IronPort-AV: i="3.99,232,1131350400"; d="scan'208"; a="375944708:sNHT140828634" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jB92aRBT029368 for ; Thu, 8 Dec 2005 18:36:42 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 21:36:27 -0500 Received: from [10.82.208.191] ([10.82.208.191]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 21:36:27 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <000801c5fc65$cc7a7100$33666e0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Dec 2005 02:36:27.0100 (UTC) FILETIME=[5A8EC9C0:01C5FC69] Message-ID: <4398EDAA.50902@cisco.com> Date: Thu, 8 Dec 2005 21:36:26 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Gracefu-Restart & RFC 3623 To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000801c5fc65$cc7a7100$33666e0a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Abhay D.S wrote: >Acee,Padma,Don, et al... > > Abhay, > >My idea is a standardization for Graceful restart, >not modification to RFC 3623. > >It should generalize all the facts and quote some usable >mechanisms,LLS or request/reply. MANET has LLS, so reuse >it for GR again ?. > > LLS was originally introduced for graceful restart. The argue for link local opaque LSA was that they already existed. The argument for LLS was that the signaling coincided with the hello/DD packets so there was no chance for a the initial grace LSA flood(s) to be missed. >Implementation and Standardization go hand in hand.(Implementation >need not be discussed) and I think it is *wrong* ...to say discussions >about draft shortcomings are discussion of implementations. > > I agree. >OSPF WG is one such body where discussions of all >sort happen,it gives important to WG. Otherwise WG is useless. > >We also can do it our own way,but we also want to see what >the WG thinks. > > It would be great to hear as well from folks deploying OSPF network which utilize graceful restart. Thanks, Acee >We want a common set of agreed rules. > >Thanks, >Abhay > > > > > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee >Lindem >Sent: Friday, December 09, 2005 3:41 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: Gracefu-Restart & RFC 3623 > > > > >I meant to read this whole E-mail thread before responding but I'll >respond to the discussion immediately. In practice, do any network >operators see >graceful restart >failing due failure to receive grace LSAs prior to a hello? Heretofore, >I haven't heard this >complaint. > >If this were to happen, it would imply a somewhat fragile network and >I'm not so sure >we'd want restart gracefully anyway (assuming the restarting router has >delayed sending >its first hello a sufficient amount of time and flooded the grace LSAs a > >couple times >as suggested by RFC 3623). > >If we graceful restart does need to solve this problem and we need a >more reliable mechanism (which is yet to be proved), then I don't think >we >should >build a request/response mechanism into the LSAs. Rather, we should >migrate to Link Local Signaling (LLS) which we are will be needed for >the OSPF MANET extensions anyway (one of the common design points of >every flooding >reduction >proposal is that it uses LLS). > >http://www.ietf.org/internet-drafts/draft-nguyen-ospf-lls-05.txt > >Thanks, >Acee > > >Abhay D.S wrote: > > > >>Hi Padma ! >> >>IMHO >>We all want to have a KISS implementation(Keep It Simple Stupid). >> >>But it is useful only for demonstration not practical. >> >>You have no proof to say Grace TLV can be received before receiving >>Hello. >> >>One case: >>In unplanned case, RFC implementation keeps sending grace TLV to all >>neighbors, assuming that they have received the TLV.We never >>Wait for an ACK from all neighbors, since we don't know who they were. >> >>And then send hello to discover neighbors. >> >> >>But one end is a remote router which failed to receive Grace LSA(what >>ever reason,overloaded,dropped due to packet type scheduling). If hello >> >> > > > >>reached the router,What to do ? >> >>How about prioritized handling of hello packets many high energy >>vendors implement. >> >>How to inter-operate with them ? >> >>Yes in a four router setup, agreed, but not in large networks, you have >> >> > > > >>to consider packet scheduling and router backplane architectures. >> >>Please, im talking only about helper router being in danger of >>receiving out of turn Hello. >> >>On restart router, this can be controlled to send Grace LSA. >> >>We know our packets well. We also have to consider network conditions. >> >>Demonstrability is a requirement for OSPF GR, Usability is the highest >>priority than Demonstrability. >> >>Abhay >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>-----Original Message----- >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >>Padma Pillay-Esnault >>Sent: Thursday, December 08, 2005 5:18 PM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: Re: Gracefu-Restart & RFC 3623 >> >> >>Abhay D.S wrote: >> >> >> >> >> >>>Hi padma !. >>>Your proverbs are enjoyable ! :-). >>> >>> >>> >>> >>> >>> >>Glad you like them >> >>The original in french "Avec des si on metterait Paris en bouteille." >> >>responses below >> >> >> >> >> >>>However, please read inline and think >>>im your customer !(ends at the moment >>>we start thinking about revisiting standardization). >>> >>> >>> >>>-----Original Message----- >>>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >>>Padma Pillay-Esnault >>>Sent: Thursday, December 08, 2005 3:03 PM >>>To: OSPF@PEACH.EASE.LSOFT.COM >>>Subject: Re: Gracefu-Restart & RFC 3623 >>> >>> >>>Abhay D.S wrote: >>> >>> >>> >>> >>> >>> >>> >>>>Hi Padma !, >>>>IMHO. >>>>Section 5 has an avoidance approach not preventive. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>Yes there is "no" support. >>> >>>Humm ... >>>You said there is "no" support - and now you say it is avoidance. >>> >>>I missing something. Not sure I understand what is avoidance and what >>>is >>> >>>preventive ? >>> >>>Can you prevent/avoid a crash ? :-) >>> >>> >>> >>> >>>Abhay)) Yes RFC does not have a mechanism to prevent neighbors from >>>getting down due to receiving hello. Do you remember the robustness >>>variable ?(This is what is avoidance).(Hope you understand and not >>>mislead yourself into thinking what RFC says is perfect,everybody >>> >>> >loves > > >>>their babies). >>> >>> >>> >>> >>> >>> >>> >>PPE - >> >>Robustness variable - yeah - send as many grace lsa you think before >>you send >>your hellos - when I think that we have feature out now that demands to >> >> > > > >>send packets >>asap and no drops - but just grace lsa would get dropped !! I don't buy >> >> > > > >>your argument. >> >>If your robustness variable is good enough that is prevention. >> >> >> >> >> >>>Unplanned restart: Why do you think grace LSA cannot be dropped and >>>hello packets be received in case of unplanned restart,we have still >>>not discovered our neighbors. >>> >>> >>> >>> >>> >>> >>> >>PPE - what makes you think that only these lsa will get dropped ? >> >>I think that you are being biased here - lo! all my grace lsa - for 5 s >>got dropped but lo and behold >>all my hellos got thru - well something is wrong and we never said that >> >> > > > >>this should work on faulty >>equipment did we ? >> >> >> >> >> >>>In planned case I agree that grace LSA's will be received by all >>>neighbors before sending hello. >>> >>> >>> >>> >>> >>> >>> >>> >>>>Why ?. >>>>Unassuming.. >>>>Case X ) Hello packets will be sent eventually to discover some >>>>neighbors ,but what if hello packets are received by some routers >>>>before they receive the grace LSA.(Only for unplanned case) because >>>>of >>>> >>>> >>>> >>>> >> >> >> >> >>>>transient network conditions. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>Why would only the grace lsas ( BTW we do send several of them wait >>>before sending hellos - discussed on this alias in 2001 I believe) get >>> >>> > > > >>>dropped and not the subsequent hello packets ? >>> >>> >>> >>>Makes me think of a french proverb >>> >>>"With a lot of ifs you can put Paris in a bottle ...." >>> >>>These are local link scope - how can you expect the hellos to jump >>>ahead >>> >>>of the grace lsa if you >>>implemented it not to be so - unless you have a buggy implementation. >>> >>>Abhay)) You must have heard about packet being dropped(it is justified >>>in draft,sending several times), and about priority handling of hello >>>packets. (suggested by folks at AT&T). >>> >>> >>> >>> >>> >>> >>> >>PPE - this is what I call implementation details- if you write get the >>grace out first - just do it ! >>or else you have a buggy implementation of the feature. Suggestion >> >> >-use > > >>the pak priority right :-) >> >> >> >> >> >>>>Case Y) Due to load of neighbors, restart router feels it needs more >>>>time to complete Graceful restart. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>The router does not feel - you configure it :-) >>> >>>Abhay)) I need an router with extra intelligence. As you know that GR >>>deployment is critical in PE's. Feeling is better than configuring it >>>and then saying sorry "we will come up with something soon, I beg >>> >>> >you". > > >>> >>> >>> >>> >> >> >> >> >>>Configuration is for stable toplogies. >>> >>> >>> >>> >>> >>> >>> >>> >>PPE - >> >>I never saw my routers beg :-) Gosh your routers are really different >> >> >>from mine !! :-) > > >>Restart with PE could have a very large value - under 1 hr >>theoretically >> >>- and an implementation exit >>GR as soon as it has completed. Simple and robust. >>( Though I don't recommend 1 hr ! - I have done enough of profiling on >>this one to >>find a suitable value!) >> >>So what do you suggest evaluate DB size. number of routers, may be mtu, >>may be link robustness and >>get some number ? How do you evaluate for those famous packet drops ? >>:-) Renegotiate the time ? By how much - how are you going to "feel" >>when >>you are done ? >>What are the criterias ? >> >>Do really want to go there ? >> >>I know how to do complex but aim for simplicity. >> >> >> >> >> >>>>In case of unplanned restart(crash on router processer) Voice over IP >>>> >>>> > > > >>>>call is still running. Do >>>> >>>> >>>> >>>> >>>> >> >> >> >> >>>>we want to exit >>>>Helper mode and get routes down ?. (Case X).Voice call >>>>is down. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>I am missing your point ..... >>> >>>Unlikely case X ( hellos ahead of grace) and the helper exit - why ? >>> >>>Abhay)) It is possible in unplanned case, think more....see reason >>> >>> >>> >>> >>given >> >> >> >> >>>Above. >>> >>> >>> >>> >>> >>> >>> >>> >>PPE - sorry I must be slow. I think that a good implementation should >>avoid X from there nothing >>makes sense anymore. It's like saying I have OSPF but I can't have >>multicast ... the basic premise is >>broken - all kinds of speculations are open. Well don't break the >>premise and it will work. >>Further more the restarting router control the premise and can make >> >> >sure > > >>it is not broken. >> >>Are you trying to say the GR router send a hello then a grace ? - but >>the hello should have torn >>down the adj - the other router is not even a helper at that point as >> >> >it > > >>will receive a hello >>with no nbr - which will cause a adjacency recycle. >> >> >> >> >> >>>>Do you feel OSPF capabilities specification can help provide a >>>>solution to ISP ?. Im keeping in mind the options some graph experts >>>> >>>> >>>> >>>> >> >> >> >> >>>>had suggested about configuration of exiting helper mode. But that >>>>did >>>> >>>> >>>> >>>> >> >> >> >> >>>>not cover case X.. >>>> >>>>Another, Grace period should be able to be changed dynamically, >>>>depending on restarting routers load, and period should be derived >>>> >>>> >>>> >>>> >>from >> >> >> >> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>>>a standardized function.(Case y) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>Actually GR can configured to be a very long period and a good >>>implementation will get end as soon as it >>>is ready. This is the approach in my implementation, let's call it >>>intuitively dynamic and you >>>don't even have to add extra config. >>> >>>Abhay)) Do you think all vendors run the same type of mechanisms ?. >>>But just above you said it can be configured ??. >>> >>> >>> >>> >>> >>> >>PPE - >> >>Implementation detail - you don't need a spec for that. >>I am sure you can figure it out. >> >> >> >> >> >>> >>> >>> >>> >>>>If I was a ISP operator, I would not refuse all of these .... :-). >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>I think you already have these :-) >>> >>>Padma >>> >>>Abhay)) Im still not satisfied, I cannot buy your RFC. :-). Please >>>improve section 5 and I will think about it. >>> >>> >>> >>> >>> >>> >>> >>PPE >> >>See my comments above >> >>Improve yes as long as it stays simple and robust and usable but brew >>coffee don't think so :-) >> >> >>Padma >> >> >> >> >> >>>>Abhay >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >>>>Padma Pillay-Esnault >>>>Sent: Thursday, December 08, 2005 2:10 PM >>>>To: OSPF@PEACH.EASE.LSOFT.COM >>>>Subject: Re: Gracefu-Restart & RFC 3623 >>>> >>>> >>>>See PPE for comments >>>> >>>>Abhay D.S wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>Importance: Normal >>>>>X-Priority: 3 (Normal) >>>>>X-MSMail-priority: Normal >>>>> >>>>> >>>>>With a foresight..and with concerns..as a reviewer >>>>>for "Update to graceful restart draft". >>>>> >>>>>Making a case for revisiting standardization: >>>>> >>>>>Standardization has to be 'revisited' and in the pipeline, since >>>>> >>>>> >>>>> >>>>> >>"OSPF >> >> >> >> >>>>>Capabilities" draft which mentions about graceful Restart capable, >>>>>helper capable option advertisements are 'useful' in making Graceful >>>>> >>>>> > > > >>>>>restart more robust. >>>>> >>>>>The original RFC still lacks the solution for unplanned restarts. >>>>>(Do you think this the USP for vendors ?):-| >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>PPE: >>>> >>>>What ? I beg to differ. >>>> >>>>What about section 5 - Unplanned Outages ? >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>OSPF Capabilities draft can address many issues faced >>>>>by service providers deploying graceful restart. >>>>> >>>>>Im also considering the possibility of using a different OSPF >>>>>version number for some special scenarios. >>>>> >>>>>Abhay >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >>>>> >>>>> >>>>> >>>>> >>Don >> >> >> >> >>>>>Goodspeed >>>>>Sent: Thursday, December 08, 2005 4:06 AM >>>>>To: OSPF@PEACH.EASE.LSOFT.COM >>>>>Subject: Re: Gracefu-Restart & RFC 3623 >>>>> >>>>> >>>>>Having helped review the original RFC during its draft stage, this >>>>>draft looks like a sound one but this would probably best be >>>>>addressed by contacting the original authors of the RFC and >>>>>co-authoring a revised Graceful OSPF Restart draft rather than >>>>>having >>>>> >>>>> >>>>> >>>>> >> >> >> >> >>>>>the original one and an "enhancement". >>>>> >>>>>Broadcasting this to the list seems like you did not contact them. >>>>> >>>>>Just my observations, >>>>>Don >>>>> >>>>>-----Original Message----- >>>>>From: owner-ospf@PEACH.EASE.LSOFT.COM >>>>>[mailto:owner-ospf@PEACH.EASE.LSOFT.COM] On Behalf Of sujay >>>>>Sent: Tuesday, December 06, 2005 10:59 PM >>>>>To: 'Mailing List' >>>>>Subject: Gracefu-Restart & RFC 3623 >>>>> >>>>>Group, >>>>> >>>>>In reference to; >>>>>Moy, J.,P. Pillay-Esnault,A. Lindem, "Graceful OSPF Restart", RFC >>>>>3623, >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>November 2003. >>>>> >>>>>There are certain areas which could be worked upon; >>>>> >>>>>1. The conservative behavior of the Restarting router; >>>>>- in its reaction on reception of any new lsa where it *always* >>>>>exits the graceful restart, this behavior may be optimized such that >>>>> >>>>> > > > >>>>>the Restarting router exits GR iff the new lsa actually implies a >>>>>change >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>in >>> >>> >>> >>> >>> >>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>the topology >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>PPE : >>>> >>>> >>>>AFAIK Major vendors already implement "non-strict lsa checking" for >>>> >>>> >>>> >>>> >>the >> >> >> >> >>>>restarting router and I have >>>>already discussed this on this alias (I seem to recall) way back. I >>>> >>>> >>>> >>>> >>did >> >> >> >> >>>>not agree then for strict-lsa checking and I still don't as it is >>>>restrictive. >>>> >>>>Several reasons >>>>In a fairly large topology, it going to be impractical. >>>>Is it worth it to exit GR because a acquired a new previously unknown >>>> >>>> > > > >>>>neighbor ? >>>> >>>> >>>> >>>> >>>> >>>>From day 1, my implementation did not support strict lsa checks. The >>> >>> >>> >>> >>>>graceful restart implementation report mentions >>>> >>>> >>>> >>>> >>non-strict-lsa-checking >> >> >> >> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>>>as well. >>>> >>>>This is an implementation decision and does not require helpers to >>>>agree >>>> >>>>on the behavior. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>2. A helper router on the presence of non-refresh lsa's in the >>>>>retransmit list to the restarting router *always* exits as a gr >>>>> >>>>> >>>>> >>>>> >>helper >> >> >> >> >>>>>- this reaction again can be ratified only if the lsa's actually >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>specify >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>a topology change. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>PPE : >>>>Please see section B2. >>>> >>>>The RFC already has the non-strict-lsa-checking option - which I >>>>believe >>>> >>>>goes hand in hand - removing strict lsa checking everywhere ( both >>>>the GR and helper). At least this was the intention of this author. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>3. The restarting router detects non participating helpers only via >>>>>the >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>back link checks In the router and network lsa's >>>>>- this behavior again may lead to network inconsistency for some >>>>> >>>>> >>>>> >>>>> >>time, >> >> >> >> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> >>> >>> >>>>>perhaps an explicit notification from the helper router to the >>>>>restarting router could be thought of. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>PPE. >>>> >>>>Please see 2.1 last sentence. >>>> >>>>What are you trying to achieve here ? >>>>- if there is no helper (router doesn't understand grace or refuses >>>>to act as helper) there is no way you are going to achieve graceful >>>>restart anyway. >>>>- that the rebooting GR router continues to do so is not a problem >>>> >>>> >>>> >>>> >>and >> >> >> >> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>>>you are going to drop >>>>packets - just as expected. >>>> >>>>Are you proposing to stop graceful restart if you cannot achieve it ? >>>> >>>> > > > >>>>What would be the benefit ? as you will then attempt a non-graceful >>>>one and drop packets anyway. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>With the above optimizations as well keeping it downwardly >>>>> >>>>> >>>>> >>>>> >>compatible, >> >> >> >> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> >>> >>> >>>>>there are a few pointers to rectify (1) and (2) above using >>>>>"Topology >>>>> >>>>> >>>>> >>>>> >> >> >> >> >>>>>change Lsa's" and >>>>>(3) using " Exit-Grace LSA TLV" >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>I don't agree that these optimizations are extensions to the original >>>>draft. >>>> >>>>- (1) non-strict lsa checking is already mentioned - maybe not as >>>>clearly as one would wish >>>>- (2) -is already mentioned see section B.2 >>>>- (3) - see my above comment >>>> >>>>my 2 cts >>>> >>>>Padma >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>Where in short "Topology change LSA's" is the group of LSA's which >>>>>*actually* signify a Topology change >>>>>And "Exit Grace LSA TLV" is an additional TLV in existing Grace LSA >>>>>which the router may use to indicate Its non-particiation as a >>>>> >>>>> >>>>> >>>>> >>helper. >> >> >> >> >>>>>The above has been documented at; >>>>>www.ietf.org/internet-drafts/draft-holla-ospf-update-graceful-restar >>>>>t >>>>> >>>>> >>>>> >>>>> >>- >> >> >> >> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>0 >>> >>> >>> >>> >>> >>> >>>>>0 >>>>>.txt >>>>> >>>>>While the implementation issues is not much of a hassle and there is >>>>>at >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>least one vendor likely to support it request your views on the >>>>>same. >>>>> >>>>>Sujay etc. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 08 22:54:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkZKj-0001Vv-VX for ospf-archive@megatron.ietf.org; Thu, 08 Dec 2005 22:54:10 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00592 for ; Thu, 8 Dec 2005 22:53:08 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <8.000051B9@wildebeest.ease.lsoft.com>; Thu, 8 Dec 2005 22:53:30 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93041856 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 8 Dec 2005 22:53:29 -0500 Received: from 61.144.161.53 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 8 Dec 2005 22:53:26 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IR700B5OPRC2O@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 09 Dec 2005 11:59:36 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IR700C0KPRCW1@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 09 Dec 2005 11:59:36 +0800 (CST) Received: from common1 ([10.110.94.86]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IR700F7NQ03G0@szxml01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 09 Dec 2005 12:04:51 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <000001c5fc73$ca3d9800$565e6e0a@china.huawei.com> Date: Fri, 9 Dec 2005 11:51:08 +0800 Reply-To: Mailing List Sender: Mailing List From: Ashok Subject: draft-holla-ospf-update-graceful-restart -- discussion thread To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <4398EDAA.50902@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT Folks, During the discussion on the enhancement proposal to GR, perhaps a lot of issues were raised and dissolved into incoherence. I have intentionally created a new thread for the discussion that was originally intended. Perhaps this thread can be focused towards debating the ideas in: www.ietf.org/internet-drafts/draft-holla-ospf-update-graceful-restart-00 The main ideas outlined are: * The draft attempts to reduce the conservativeness of the existing GR mechanism. * It proposes a new explicit feedback mechanism for the helpers to communicate their non-participation in GR. Other useful links: RFC 3623: http://www.ietf.org/rfc/rfc3623.txt Vishwas Manral's discussion on the mailing list: http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0203&L=ospf&T=0&F=&S=&P =1888 I suggest that all other issues and ideas for GR can be either continued in the other thread or started as separate threads. Regards, Ashok From owner-ospf@PEACH.EASE.LSOFT.COM Tue Dec 13 15:24:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmGhL-0005dm-8G for ospf-archive@megatron.ietf.org; Tue, 13 Dec 2005 15:24:32 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16778 for ; Tue, 13 Dec 2005 15:23:34 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <10.00005BED@wildebeest.ease.lsoft.com>; Tue, 13 Dec 2005 15:23:55 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93516683 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 13 Dec 2005 15:23:56 -0500 Received: from 209.119.0.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 13 Dec 2005 15:23:56 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by LIME.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.0004C20D@LIME.ease.lsoft.com>; Tue, 13 Dec 2005 15:23:24 -0500 Message-ID: Date: Tue, 13 Dec 2005 15:23:32 -0500 Reply-To: Mailing List Sender: Mailing List From: vishnuvardhan B Subject: Ospfv3 route tables To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Hi All, I am not able to understand the idea behind maintaining per area route tables. Instead of this can't we do with a single route table as in ospfv2? Regards, Vishnu From owner-ospf@PEACH.EASE.LSOFT.COM Tue Dec 13 15:36:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmGsg-00008q-7V for ospf-archive@megatron.ietf.org; Tue, 13 Dec 2005 15:36:14 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18062 for ; Tue, 13 Dec 2005 15:35:09 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <5.00005C01@wildebeest.ease.lsoft.com>; Tue, 13 Dec 2005 15:35:35 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93518426 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 13 Dec 2005 15:35:35 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 13 Dec 2005 15:35:34 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 13 Dec 2005 15:35:35 -0500 X-IronPort-AV: i="3.99,248,1131339600"; d="scan'208"; a="77689315:sNHT29332124" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jBDKYuUx006328 for ; Tue, 13 Dec 2005 15:35:32 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Dec 2005 15:35:29 -0500 Received: from [10.82.240.13] ([10.82.240.13]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Dec 2005 15:35:29 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Dec 2005 20:35:29.0419 (UTC) FILETIME=[C1A3ADB0:01C60024] Message-ID: <439F3090.6090109@cisco.com> Date: Tue, 13 Dec 2005 15:35:28 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Ospfv3 route tables To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit vishnuvardhan B wrote: >Hi All, >I am not able to understand the idea behind maintaining per area route >tables. Instead of this can't we do with a single route table as in >ospfv2? > > Hi Vishnu, Do not confuse the per area route table for OSPFv3 SPT (Shortest Path Tree) vertices with OSPFv3 RIB containing OSPF IPv6 prefixes. You can implement in any way you choose but conceptually, RFC 2740 (and the update) describe the intra-area SPF assuming a per-area route table for SPT verticies. I also believe this is the best way to implement it. Thanks, Acee >Regards, >Vishnu > > > From owner-ospf@PEACH.EASE.LSOFT.COM Tue Dec 13 21:00:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmLwN-0002nL-CT for ospf-archive@megatron.ietf.org; Tue, 13 Dec 2005 21:00:23 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08451 for ; Tue, 13 Dec 2005 20:59:23 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <8.00005CE1@wildebeest.ease.lsoft.com>; Tue, 13 Dec 2005 20:59:48 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93548822 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 13 Dec 2005 20:59:48 -0500 Received: from 171.71.176.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 13 Dec 2005 20:59:48 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 13 Dec 2005 17:59:47 -0800 X-IronPort-AV: i="3.99,249,1131350400"; d="scan'208"; a="377923666:sNHT31919076" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jBE1xg72028130 for ; Tue, 13 Dec 2005 17:59:46 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Dec 2005 20:59:42 -0500 Received: from [10.82.240.13] ([10.82.240.13]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Dec 2005 20:59:42 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Dec 2005 01:59:42.0458 (UTC) FILETIME=[0C8DDDA0:01C60052] Message-ID: <439F7C8C.4070404@cisco.com> Date: Tue, 13 Dec 2005 20:59:40 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit This draft proposes (at least) three separate improvements to RFC 3623 graceful restart. 1. Classification of topology change LSAs as a less conservative criteria for a helper router exiting graceful restart. 2. Use of a explicit exit TLV for a helper router terminating graceful restart. The use of a hello without the restarting router's router-ID is also suggested. 3. Preservation of the backup DR across graceful restarts to avoid new adjacencies. Let's discuss each of these in the context of potential for improvement, requirements, and previous proposals (if any) to meet the requirement. Thanks, Acee From owner-ospf@PEACH.EASE.LSOFT.COM Tue Dec 13 21:21:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmMGe-0001r5-TG for ospf-archive@megatron.ietf.org; Tue, 13 Dec 2005 21:21:20 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10012 for ; Tue, 13 Dec 2005 21:20:23 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <14.00005CDC@wildebeest.ease.lsoft.com>; Tue, 13 Dec 2005 21:20:49 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93549804 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 13 Dec 2005 21:20:49 -0500 Received: from 171.71.176.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 13 Dec 2005 21:20:48 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 13 Dec 2005 18:20:45 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jBE2KD7K006626 for ; Tue, 13 Dec 2005 18:20:43 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Dec 2005 21:20:32 -0500 Received: from [10.82.240.13] ([10.82.240.13]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Dec 2005 21:20:32 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <439F7C8C.4070404@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Dec 2005 02:20:32.0523 (UTC) FILETIME=[F5A6A5B0:01C60054] Message-ID: <439F816F.80502@cisco.com> Date: Tue, 13 Dec 2005 21:20:31 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: draft-holla-ospf-update-graceful-restart-00.txt - Topology Change LSAs and Helper Mode Exit To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <439F7C8C.4070404@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit The draft proposes sub-classification of LSA changes for determining whether or not a helper should terminate graceful restart. RFC 3623 currently has 2 modes: 1. Strict LSA Checking - Any changed LSA which would be flooded to the restarting router will terminate graceful restart. 2. Changed LSAs will not terminate graceful restart (the default for most vendors). The draft further classifies LSA changes as constituting a topology change (in an effort to reduce the cases where graceful restart must be terminated). For example, a new LSA or new link added to a router LSA would not cause GR termination. I have the following concerns: 1. Are people asking for this? Most vendors default to #2. 2. New LSAs can cause the same problems as topology changes to existing ones. Consider the installation of new more specific routes - the characterization of new LSAs or "good" news being innocuous and "bad" news terminating grace restart seems arbitrary. The draft suggests monitoring all route changes involving next hops of the restarting router to avoid this problem. 3. Although my memory is weak, it seems to me that Vishwas' previous proposal was more robust. If there is a requirement for some level of LSA checking but less conservative than any LSA flooded to the restarting router than we should consider that one as well. Thanks, Acee From owner-ospf@PEACH.EASE.LSOFT.COM Tue Dec 13 22:13:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmN4j-00008r-2o for ospf-archive@megatron.ietf.org; Tue, 13 Dec 2005 22:13:05 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14880 for ; Tue, 13 Dec 2005 22:11:59 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <6.00005CF5@wildebeest.ease.lsoft.com>; Tue, 13 Dec 2005 22:12:25 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93552749 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 13 Dec 2005 22:12:25 -0500 Received: from 61.144.161.53 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 13 Dec 2005 22:12:19 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRG00EMVX2FB5@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 14 Dec 2005 11:15:51 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRG009YCX2FNQ@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 14 Dec 2005 11:15:51 +0800 (CST) Received: from common1 ([10.110.94.86]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IRG00I6LX5I6Y@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 14 Dec 2005 11:17:42 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <000001c6005b$7df1a450$565e6e0a@china.huawei.com> Date: Wed, 14 Dec 2005 11:07:17 +0800 Reply-To: Mailing List Sender: Mailing List From: Ashok Subject: Re: draft-holla-ospf-update-graceful-restart-00.txt - Topology Change LSAs and Helper Mode Exit To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <439F816F.80502@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT Hi group, The main objective of the topology change LSA definition is to achieve a balance between unbroken forwarding and restricting the scope of false GR exits. The GR mechanism overrides the basic OSPF protocol behavior. All the checks that have been put in place by OSPF are invalidated by the GR protocol. GR thus necessitates some 'faith' on part of the routers in a topology to adhere to the principle of reacting quickly to bad news. By disabling strict-lsa-checking, this 'faith' is lost. In several scenarios, disabling strict LSA checking will result in the overall convergence time of OSPF routers being worse with graceful restart mechanism than without it. This generally involves unstable topologies and multiple failures. Perhaps, the service providers have not had such scenarios occurring and as a result, have not asked for such changes. However, the protocol must address this possibility. My concern with the existing mechanism is that taking policy decisions like disabling strict lsa checking is incorrect, since we cannot decide the significance of a topology change apriori. It could lead to extended downtimes, which would not have been the case if GR mechanism was not in place. While this is true, what is equally true is that in large networks, many changes keep occurring. Links and routers toggle, policies changed and new routes learnt. This problem is amplified when there are different service providers operating in the same space. Clearly, many of these changes may be irrelevant to the neighborhood of a gracefully restarting router and must not play a part in forcing GR exit. By enabling strict-lsa-checking, this objective is undermined. Therefore I feel that there is a need to make the protocol less conservative and more intelligent, while retaining the strict-lsa-checking. The exact method of achieving this is perhaps still debatable. We have suggested a method with a bias towards maintaining unbroken forwarding. Vishwas, it would be nice if you could refresh the group's memory with your suggestion. I am new to the group and have missed out on the context and content of that discussion. Regards, Ashok -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee Lindem Sent: Wednesday, December 14, 2005 10:21 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: draft-holla-ospf-update-graceful-restart-00.txt - Topology Change LSAs and Helper Mode Exit The draft proposes sub-classification of LSA changes for determining whether or not a helper should terminate graceful restart. RFC 3623 currently has 2 modes: 1. Strict LSA Checking - Any changed LSA which would be flooded to the restarting router will terminate graceful restart. 2. Changed LSAs will not terminate graceful restart (the default for most vendors). The draft further classifies LSA changes as constituting a topology change (in an effort to reduce the cases where graceful restart must be terminated). For example, a new LSA or new link added to a router LSA would not cause GR termination. I have the following concerns: 1. Are people asking for this? Most vendors default to #2. 2. New LSAs can cause the same problems as topology changes to existing ones. Consider the installation of new more specific routes - the characterization of new LSAs or "good" news being innocuous and "bad" news terminating grace restart seems arbitrary. The draft suggests monitoring all route changes involving next hops of the restarting router to avoid this problem. 3. Although my memory is weak, it seems to me that Vishwas' previous proposal was more robust. If there is a requirement for some level of LSA checking but less conservative than any LSA flooded to the restarting router than we should consider that one as well. Thanks, Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed Dec 14 00:00:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmOkc-0004m8-KR for ospf-archive@megatron.ietf.org; Wed, 14 Dec 2005 00:00:26 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25216 for ; Tue, 13 Dec 2005 23:59:25 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <7.00005D0B@wildebeest.ease.lsoft.com>; Tue, 13 Dec 2005 23:59:52 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93560169 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 13 Dec 2005 23:59:52 -0500 Received: from 209.119.0.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 13 Dec 2005 23:59:52 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by LIME.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.0004CF27@LIME.ease.lsoft.com>; Tue, 13 Dec 2005 23:59:20 -0500 Message-ID: Date: Tue, 13 Dec 2005 23:59:50 -0500 Reply-To: Mailing List Sender: Mailing List From: vishnuvardhan B Subject: Re: Ospfv3 route tables Comments: To: Acee Lindem To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Hi Acee Appreciate the response, please clarify me one thing.Now the per-area route tables are the vertices of the SPT? Since rfc specifies they contain an entry for each router in the area and the shortest path to the router, this means they are replacement for the transit vertices? if not please clarify me on how the transit vertices are related with the per area route tables. Thanks, Vishnu From owner-ospf@PEACH.EASE.LSOFT.COM Wed Dec 14 00:51:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmPXW-00030j-Cw for ospf-archive@megatron.ietf.org; Wed, 14 Dec 2005 00:51:00 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29665 for ; Wed, 14 Dec 2005 00:49:51 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <4.00005D2E@wildebeest.ease.lsoft.com>; Wed, 14 Dec 2005 0:50:19 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93567958 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 14 Dec 2005 00:50:19 -0500 Received: from 61.144.161.55 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 14 Dec 2005 00:50:18 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRH00MHY48CS1@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 14 Dec 2005 13:50:37 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRH00LZP48CDC@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 14 Dec 2005 13:50:36 +0800 (CST) Received: from dell60 ([10.18.4.57]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IRH00MLV4G29J@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 14 Dec 2005 13:55:16 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <000001c60071$8041d3e0$3904120a@china.huawei.com> Date: Wed, 14 Dec 2005 11:14:49 +0530 Reply-To: Mailing List Sender: Mailing List From: sujay Subject: Re: draft-holla-ospf-update-graceful-restart-00.txt - Topology Change LSAs and Helper Mode Exit To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000001c6005b$7df1a450$565e6e0a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT Adding to Ashoks comment below: About the issue of the vendors and service providers are unaware of 'strict lsa checking' And 'changed lsa's' and they do not resort to the 'strict lsa checking' concept. Then it would be advisable to go away with the concept of 'strict lsa checking' , ' changed lsa's' In 3623. On the other hand if we propose to keep it, still keeping in mind most( and not all) vendors could use it , the strict lsa checking and changed lsa's definitions need a clear and exact definition. One part of the draft explains this, calling them as "topology change lsa" Talking about the "Exit TLV" it needs merit, as leaving apart the simplicity it provides in Catching outages, there are cases where without it ( i.e using only the implicit checks) routing Inconsistencies go unnoticed ( See section 8) -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Ashok Sent: Wednesday, December 14, 2005 8:37 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: draft-holla-ospf-update-graceful-restart-00.txt - Topology Change LSAs and Helper Mode Exit Hi group, The main objective of the topology change LSA definition is to achieve a balance between unbroken forwarding and restricting the scope of false GR exits. The GR mechanism overrides the basic OSPF protocol behavior. All the checks that have been put in place by OSPF are invalidated by the GR protocol. GR thus necessitates some 'faith' on part of the routers in a topology to adhere to the principle of reacting quickly to bad news. By disabling strict-lsa-checking, this 'faith' is lost. In several scenarios, disabling strict LSA checking will result in the overall convergence time of OSPF routers being worse with graceful restart mechanism than without it. This generally involves unstable topologies and multiple failures. Perhaps, the service providers have not had such scenarios occurring and as a result, have not asked for such changes. However, the protocol must address this possibility. My concern with the existing mechanism is that taking policy decisions like disabling strict lsa checking is incorrect, since we cannot decide the significance of a topology change apriori. It could lead to extended downtimes, which would not have been the case if GR mechanism was not in place. While this is true, what is equally true is that in large networks, many changes keep occurring. Links and routers toggle, policies changed and new routes learnt. This problem is amplified when there are different service providers operating in the same space. Clearly, many of these changes may be irrelevant to the neighborhood of a gracefully restarting router and must not play a part in forcing GR exit. By enabling strict-lsa-checking, this objective is undermined. Therefore I feel that there is a need to make the protocol less conservative and more intelligent, while retaining the strict-lsa-checking. The exact method of achieving this is perhaps still debatable. We have suggested a method with a bias towards maintaining unbroken forwarding. Vishwas, it would be nice if you could refresh the group's memory with your suggestion. I am new to the group and have missed out on the context and content of that discussion. Regards, Ashok -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee Lindem Sent: Wednesday, December 14, 2005 10:21 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: draft-holla-ospf-update-graceful-restart-00.txt - Topology Change LSAs and Helper Mode Exit The draft proposes sub-classification of LSA changes for determining whether or not a helper should terminate graceful restart. RFC 3623 currently has 2 modes: 1. Strict LSA Checking - Any changed LSA which would be flooded to the restarting router will terminate graceful restart. 2. Changed LSAs will not terminate graceful restart (the default for most vendors). The draft further classifies LSA changes as constituting a topology change (in an effort to reduce the cases where graceful restart must be terminated). For example, a new LSA or new link added to a router LSA would not cause GR termination. I have the following concerns: 1. Are people asking for this? Most vendors default to #2. 2. New LSAs can cause the same problems as topology changes to existing ones. Consider the installation of new more specific routes - the characterization of new LSAs or "good" news being innocuous and "bad" news terminating grace restart seems arbitrary. The draft suggests monitoring all route changes involving next hops of the restarting router to avoid this problem. 3. Although my memory is weak, it seems to me that Vishwas' previous proposal was more robust. If there is a requirement for some level of LSA checking but less conservative than any LSA flooded to the restarting router than we should consider that one as well. Thanks, Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed Dec 14 02:18:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmQuX-0001hY-HH for ospf-archive@megatron.ietf.org; Wed, 14 Dec 2005 02:18:51 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09248 for ; Wed, 14 Dec 2005 02:17:50 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <15.00005D49@wildebeest.ease.lsoft.com>; Wed, 14 Dec 2005 2:18:18 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93575321 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 14 Dec 2005 02:18:17 -0500 Received: from 61.144.161.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 14 Dec 2005 02:17:53 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRH001N28K911@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 14 Dec 2005 15:24:09 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRH00LLV8K8MD@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 14 Dec 2005 15:24:09 +0800 (CST) Received: from Abhay1717 ([10.18.4.189]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IRH001PX8JZ8O@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 14 Dec 2005 15:24:01 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: Date: Wed, 14 Dec 2005 12:43:35 +0530 Reply-To: Mailing List Sender: Mailing List From: "Abhay D.S" Subject: Re: draft-holla-ospf-update-graceful-restart-00.txt - Topology Change LSAs and Helper Mode Exit To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000001c60071$8041d3e0$3904120a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT hi, Apart from the drafted ideas. It is time to list out facts which really matter. A balance between "need it" or good to have. We need a Requirements for Graceful restart in general. Regards, Abhay -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of sujay Sent: Wednesday, December 14, 2005 11:15 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: draft-holla-ospf-update-graceful-restart-00.txt - Topology Change LSAs and Helper Mode Exit Adding to Ashoks comment below: About the issue of the vendors and service providers are unaware of 'strict lsa checking' And 'changed lsa's' and they do not resort to the 'strict lsa checking' concept. Then it would be advisable to go away with the concept of 'strict lsa checking' , ' changed lsa's' In 3623. On the other hand if we propose to keep it, still keeping in mind most( and not all) vendors could use it , the strict lsa checking and changed lsa's definitions need a clear and exact definition. One part of the draft explains this, calling them as "topology change lsa" Talking about the "Exit TLV" it needs merit, as leaving apart the simplicity it provides in Catching outages, there are cases where without it ( i.e using only the implicit checks) routing Inconsistencies go unnoticed ( See section 8) -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Ashok Sent: Wednesday, December 14, 2005 8:37 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: draft-holla-ospf-update-graceful-restart-00.txt - Topology Change LSAs and Helper Mode Exit Hi group, The main objective of the topology change LSA definition is to achieve a balance between unbroken forwarding and restricting the scope of false GR exits. The GR mechanism overrides the basic OSPF protocol behavior. All the checks that have been put in place by OSPF are invalidated by the GR protocol. GR thus necessitates some 'faith' on part of the routers in a topology to adhere to the principle of reacting quickly to bad news. By disabling strict-lsa-checking, this 'faith' is lost. In several scenarios, disabling strict LSA checking will result in the overall convergence time of OSPF routers being worse with graceful restart mechanism than without it. This generally involves unstable topologies and multiple failures. Perhaps, the service providers have not had such scenarios occurring and as a result, have not asked for such changes. However, the protocol must address this possibility. My concern with the existing mechanism is that taking policy decisions like disabling strict lsa checking is incorrect, since we cannot decide the significance of a topology change apriori. It could lead to extended downtimes, which would not have been the case if GR mechanism was not in place. While this is true, what is equally true is that in large networks, many changes keep occurring. Links and routers toggle, policies changed and new routes learnt. This problem is amplified when there are different service providers operating in the same space. Clearly, many of these changes may be irrelevant to the neighborhood of a gracefully restarting router and must not play a part in forcing GR exit. By enabling strict-lsa-checking, this objective is undermined. Therefore I feel that there is a need to make the protocol less conservative and more intelligent, while retaining the strict-lsa-checking. The exact method of achieving this is perhaps still debatable. We have suggested a method with a bias towards maintaining unbroken forwarding. Vishwas, it would be nice if you could refresh the group's memory with your suggestion. I am new to the group and have missed out on the context and content of that discussion. Regards, Ashok -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee Lindem Sent: Wednesday, December 14, 2005 10:21 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: draft-holla-ospf-update-graceful-restart-00.txt - Topology Change LSAs and Helper Mode Exit The draft proposes sub-classification of LSA changes for determining whether or not a helper should terminate graceful restart. RFC 3623 currently has 2 modes: 1. Strict LSA Checking - Any changed LSA which would be flooded to the restarting router will terminate graceful restart. 2. Changed LSAs will not terminate graceful restart (the default for most vendors). The draft further classifies LSA changes as constituting a topology change (in an effort to reduce the cases where graceful restart must be terminated). For example, a new LSA or new link added to a router LSA would not cause GR termination. I have the following concerns: 1. Are people asking for this? Most vendors default to #2. 2. New LSAs can cause the same problems as topology changes to existing ones. Consider the installation of new more specific routes - the characterization of new LSAs or "good" news being innocuous and "bad" news terminating grace restart seems arbitrary. The draft suggests monitoring all route changes involving next hops of the restarting router to avoid this problem. 3. Although my memory is weak, it seems to me that Vishwas' previous proposal was more robust. If there is a requirement for some level of LSA checking but less conservative than any LSA flooded to the restarting router than we should consider that one as well. Thanks, Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed Dec 14 05:29:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmTtB-0000rN-DD for ospf-archive@megatron.ietf.org; Wed, 14 Dec 2005 05:29:37 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01755 for ; Wed, 14 Dec 2005 05:28:39 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <2.00005D6C@wildebeest.ease.lsoft.com>; Wed, 14 Dec 2005 5:29:05 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93583648 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 14 Dec 2005 05:29:04 -0500 Received: from 171.71.176.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 14 Dec 2005 05:29:04 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 14 Dec 2005 02:29:04 -0800 X-IronPort-AV: i="3.99,251,1131350400"; d="scan'208"; a="684476074:sNHT31801452" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jBEAT3Qg008010; Wed, 14 Dec 2005 02:29:03 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Dec 2005 05:29:03 -0500 Received: from [10.82.240.13] ([10.82.240.13]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Dec 2005 05:29:02 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Dec 2005 10:29:02.0895 (UTC) FILETIME=[33FE7BF0:01C60099] Message-ID: <439FF3EE.3090508@cisco.com> Date: Wed, 14 Dec 2005 05:29:02 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Ospfv3 route tables Comments: To: vishnuvardhan B To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit vishnuvardhan B wrote: >Hi Acee >Appreciate the response, please clarify me one thing.Now the per-area route >tables are the vertices of the SPT? Since rfc specifies they contain an >entry for each router in the area and the shortest path to the router, this >means they are replacement for the transit vertices? > Hi Vishu, If I understand you right, you are asking whether or not you could maintain the same information in the link state database (LSDB) or some other data structure. The answer is yes. RFC 2740 uses the per-area routing table to precisely describe OSPFv3 protocol behavior. As you noted, it contains entries for all transit vertices in the shortest path tree (SPF). Hope this helps, Acee >if not please clarify >me on how the transit vertices are related with the per area route tables. >Thanks, >Vishnu > > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Dec 14 13:31:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmbPg-0005hK-SO for ospf-archive@megatron.ietf.org; Wed, 14 Dec 2005 13:31:40 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06536 for ; Wed, 14 Dec 2005 13:30:34 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <3.00005E5A@wildebeest.ease.lsoft.com>; Wed, 14 Dec 2005 13:31:00 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93625598 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 14 Dec 2005 13:31:00 -0500 Received: from 80.168.70.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 14 Dec 2005 13:31:00 -0500 Received: from du-069-0153.access.clara.net ([217.158.132.153] helo=Puppy) by relay1.mail.uk.clara.net with esmtp (Exim 4.46) id 1EmbOz-000DaD-IW; Wed, 14 Dec 2005 18:30:58 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: <0c6d01c600dd$04761de0$9d849ed9@Puppy> Date: Wed, 14 Dec 2005 18:31:29 -0000 Reply-To: Mailing List Sender: Mailing List From: Adrian Farrel Subject: Cross-WG review requested Comments: cc: ccamp@ops.ietf.org, Acee Lindem , dube.rohit@gmail.com To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Hi OSPF Working Group, CCAMP has just accepted two I-Ds that may be of interest to you. Routing extensions for discovery of Traffic Engineering Node Capabilities http://www.ietf.org/internet-drafts/draft-ietf-ccamp-te-node-cap-00.txt This I-D specifies OSPF and IS-IS traffic engineering extensions for the advertisement of control plane and data plane traffic engineering node capabilities. This I-D makes use of draft-ietf-ospf-cap by defining a new TLV to be included in the Router Information LSA. Routing extensions for discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) mesh membership http://www.ietf.org/internet-drafts/draft-ietf-ccamp-automesh-00.txt This document specifies OSPF and IS-IS traffic engineering extensions so as to provide an automatic discovery of the set of LSRs members of a mesh, leading to an automatic mechanism to set up TE LSP mesh(es) (also referred to as a mesh-group). This I-D makes use of draft-ietf-ospf-cap by defining a new TLV to be included in the Router Information LSA. We would appreciate your feedback, ideally on the CCAMP mailing list, but alternatively to the WG chairs or to the authors direct. (We will also be consulting the IS-IS mailing list). Since this work is relatively mature, we will be progressing the documents to WG last call in the New Year, after suitable editorial refinement. Many thanks, Adrian per pro CCAMP From owner-ospf@PEACH.EASE.LSOFT.COM Wed Dec 14 22:38:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emjwt-0002O8-UE for ospf-archive@megatron.ietf.org; Wed, 14 Dec 2005 22:38:31 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05127 for ; Wed, 14 Dec 2005 22:37:28 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <4.00005F9D@wildebeest.ease.lsoft.com>; Wed, 14 Dec 2005 22:37:33 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93670219 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 14 Dec 2005 22:37:33 -0500 Received: from 209.119.1.41 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 14 Dec 2005 22:27:33 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by LIME.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.0004EFF1@LIME.ease.lsoft.com>; Wed, 14 Dec 2005 22:27:01 -0500 Message-ID: Date: Wed, 14 Dec 2005 22:27:31 -0500 Reply-To: Mailing List Sender: Mailing List From: Anup Kumar T Subject: Faster DD Exchange To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: According to RFC 2328, we send 1 DD packet, wait till the ack is seen and only then send the next DD pkt. We can improve upon this. The idea is to send N DD packets initially. Then, as and when an ack is seen, send the next DD pkt. The existing DD Exchange procedure will have to be modified. Once the trigger is set by the initial N DD packets, the successive exchanges will be faster (The waiting time is reduced). The routers can be made to negotiate the value of N before they enter into DD Exchange. If they cannot negotiate (may happen during interoperation), they will default to the normal behaviour i.e. to send 1 DD packet. - Anup From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 15 08:56:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emtal-00017M-M2 for ospf-archive@megatron.ietf.org; Thu, 15 Dec 2005 08:56:19 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09519 for ; Thu, 15 Dec 2005 08:55:19 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <3.0000601F@wildebeest.ease.lsoft.com>; Thu, 15 Dec 2005 8:55:44 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93709737 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 15 Dec 2005 08:55:44 -0500 Received: from 171.71.176.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 15 Dec 2005 08:55:43 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 15 Dec 2005 05:55:43 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jBFDtYRG005824 for ; Thu, 15 Dec 2005 05:55:43 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Dec 2005 08:55:42 -0500 Received: from [10.82.240.13] ([10.82.240.13]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Dec 2005 08:55:42 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Dec 2005 13:55:42.0801 (UTC) FILETIME=[3D53BC10:01C6017F] Message-ID: <43A175DE.6060805@cisco.com> Date: Thu, 15 Dec 2005 08:55:42 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Faster DD Exchange To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Anup Kumar T wrote: >According to RFC 2328, we send 1 DD packet, wait till the ack is seen and >only then send the next DD pkt. We can improve upon this. The idea is to >send N DD packets initially. Then, as and when an ack is seen, send the >next DD pkt. The existing DD Exchange procedure will have to be modified. > >Once the trigger is set by the initial N DD packets, the successive >exchanges will be faster (The waiting time is reduced). > >The routers can be made to negotiate the value of N before they enter into >DD Exchange. If they cannot negotiate (may happen during interoperation), >they will default to the normal behaviour i.e. to send 1 DD packet. > > Anup, Why would we want to introduce a non-backward compatible change to OSPF DD Exchange? Have you quantitatively measured the improvement? How does your loosely defined proposal behave in the presence of OSPF packet loss? Since we're not going to entertain this (unless someone can show a significant improvement in overall adjacency bring), I'm not going to even get into the technical details. On a related note, Richard Ogier has proposed a fully backward compatible change to OSPF DD Exchange in the context of the OSPF MANET work. His proposal is for an OSPF router NOT to include LSAs which have been received with the same or more recent instance from the neighbor with whom you are forming an adjacency. This is one of those ideas that once you hear you wonder why you didn't think of it :^). Acee > >- Anup > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 15 16:10:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En0Mf-0002sI-Pj for ospf-archive@megatron.ietf.org; Thu, 15 Dec 2005 16:10:13 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07929 for ; Thu, 15 Dec 2005 16:09:04 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <5.00006123@wildebeest.ease.lsoft.com>; Thu, 15 Dec 2005 16:09:28 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93744646 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 15 Dec 2005 16:09:27 -0500 Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 15 Dec 2005 16:09:27 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 15 Dec 2005 13:09:28 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,258,1131350400"; d="scan'208"; a="17288871:sNHT23033700" Received: from RussPC (rtp-vpn1-181.cisco.com [10.82.224.181]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jBFL9O4Y008177 for ; Thu, 15 Dec 2005 16:09:25 -0500 (EST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Thu, 15 Dec 2005 16:09:25 -0500 X-PGP-Universal: processed; by RussPC on Thu, 15 Dec 2005 16:09:25 -0500 User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <439F7C8C.4070404@cisco.com> <439F816F.80502@cisco.com> X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <43A1DB7E.9080801@cisco.com> Date: Thu, 15 Dec 2005 16:09:18 -0500 Reply-To: Mailing List Sender: Mailing List From: Russ White Subject: Re: draft-holla-ospf-update-graceful-restart-00.txt - Topology Change LSAs and Helper Mode Exit To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <439F816F.80502@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 None of this would be needed, of course, if LLS were used, would it? Why not modify the current standard to allow optional LLS and OOB, and then we could merge the drafts all into one big mess.... (?) :-) Russ Acee Lindem wrote: > > > The draft proposes sub-classification of LSA changes for determining > whether or > not a helper should terminate graceful restart. RFC 3623 currently has 2 > modes: > 1. Strict LSA Checking - Any changed LSA which would be > flooded to the restarting > router will terminate graceful restart. > 2. Changed LSAs will not terminate graceful restart (the > default for most vendors). > > The draft further classifies LSA changes as constituting a topology > change (in an effort to > reduce the cases where graceful restart must be terminated). For > example, a new LSA or > new link added to a router LSA would not cause GR termination. I have > the following > concerns: > > 1. Are people asking for this? Most vendors default to #2. > 2. New LSAs can cause the same problems as topology changes to > existing ones. > Consider the installation of new more specific routes - the > characterization of new LSAs > or "good" news being innocuous and "bad" news terminating > grace restart seems > arbitrary. The draft suggests monitoring all route changes > involving next hops > of the restarting router to avoid this problem. > 3. Although my memory is weak, it seems to me that Vishwas' > previous proposal > was more robust. If there is a requirement for some level of > LSA checking but less > conservative than any LSA flooded to the restarting router > than we should consider > that one as well. > > Thanks, > Acee > - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.3 (Build 2932) iQA/AwUBQ6HbhREdu7FIVPTkEQLcowCg/rB5fh3270DmJiYIqYFr2O5m/zUAnRn9 7ZhOOP/AXNjPXjMlIWlTyuCc =QfZR -----END PGP SIGNATURE----- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 15 16:31:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En0hK-0000yg-7s for ospf-archive@megatron.ietf.org; Thu, 15 Dec 2005 16:31:34 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13286 for ; Thu, 15 Dec 2005 16:30:28 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <4.00006129@wildebeest.ease.lsoft.com>; Thu, 15 Dec 2005 16:30:57 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93745821 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 15 Dec 2005 16:30:57 -0500 Received: from 207.69.195.62 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 15 Dec 2005 16:30:57 -0500 Received: from h-68-164-87-131.snvacaid.dynamic.covad.net ([68.164.87.131] helo=earthlink.net) by pop-altamira.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1En0gi-0000Pa-00 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 15 Dec 2005 16:30:56 -0500 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <43A175DE.6060805@cisco.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43A1E3E6.38265DDC@earthlink.net> Date: Thu, 15 Dec 2005 13:45:10 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Faster DD Exchange To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Group, Yes, filtering of LSAs are possible, but let me suggest something else and then comment on the filtering.. Lets see how can we say get a X speedup for DD pkt xchanges? For those routers that have a multiple connections with a nbr: * split the LSDB into an equal number of groups as the number of nbr connections (hopefully each having approx the same number of hdrs that need to be resolved), * Amdahl's(spelling) law says you can at best get close because the flow workloads can't be perfectly EQUAL. * then process each group concurrently, with each group having a different set of DD pkts, * at the completion of the exchange of DDs or complete LSDB xchange, recombine the LSDB. Thus the speedup can be 2x, 4x, 8x etc when the individual link speeds are a bottleneck. This is mostly helpful with kb/sec links or where we have a overwhelming ability to process pkts in incoming ports simultaneously, The speedup can even be greater if one side has the LSAs that need resolving for we are continually waiting for the next DD pkt. And it is not sent until we see the ACK. So in extreme circumstance we can cut in half our expected DD exchange time. Two links can result in a 4x speedup due to each ACK requiring a min of 1 RTT!!!!! It is also helpful when one wishes to send smaller than MTU size DD pkts for fewer rexmits. This last item assumes that with wireless the chance of say a 9k jumbo has a significantly greater chance needing rexmits than say a 254byte pkt. This is in effect aggregation. Mitchell Erblich PS: On a side note, doesn't the Ogier proposal assume that the effort to filter the LSA headers that are to be removed from DD exchanges beneficial? * Some of the LSA hdrs being xmited CAN to be filtered, * That the number of filtered hdrs is significant. * Doesn't the complete exchange of LSA headers verify synchronization? * Won't the LSAs hdrs that are filtered result in the recvr having a subset of EXPECTED set of hdrs? Doesn't this require a check that missing hdrs are already present? * For short duration lifetimes of LSAs or short remaining lifetimes of LSAs, we can DELAY and update the nbr with a newer instance during DD exhange. ============================== Acee Lindem wrote: > > Anup Kumar T wrote: > > >According to RFC 2328, we send 1 DD packet, wait till the ack is seen and > >only then send the next DD pkt. We can improve upon this. The idea is to > >send N DD packets initially. Then, as and when an ack is seen, send the > >next DD pkt. The existing DD Exchange procedure will have to be modified. > > > >Once the trigger is set by the initial N DD packets, the successive > >exchanges will be faster (The waiting time is reduced). > > > >The routers can be made to negotiate the value of N before they enter into > >DD Exchange. If they cannot negotiate (may happen during interoperation), > >they will default to the normal behaviour i.e. to send 1 DD packet. > > > > > Anup, > > Why would we want to introduce a non-backward compatible change to OSPF > DD Exchange? > Have you quantitatively measured the improvement? How does your loosely > defined proposal > behave in the presence of OSPF packet loss? Since we're not going to > entertain this (unless > someone can show a significant improvement in overall adjacency bring), > I'm not going to > even get into the technical details. > > On a related note, Richard Ogier has proposed a fully backward > compatible change to OSPF > DD Exchange in the context of the OSPF MANET work. His proposal is for > an OSPF router > NOT to include LSAs which have been received with the same or more > recent instance from > the neighbor with whom you are forming an adjacency. This is one of > those ideas that > once you hear you wonder why you didn't think of it :^). > > Acee > > > > >- Anup > > > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 15 16:44:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En0tx-0007sR-Lz for ospf-archive@megatron.ietf.org; Thu, 15 Dec 2005 16:44:37 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18928 for ; Thu, 15 Dec 2005 16:43:39 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <0.0000612B@wildebeest.ease.lsoft.com>; Thu, 15 Dec 2005 16:44:06 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93746765 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 15 Dec 2005 16:44:06 -0500 Received: from 64.102.122.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 15 Dec 2005 16:44:06 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 15 Dec 2005 16:44:05 -0500 X-IronPort-AV: i="3.99,258,1131339600"; d="scan'208"; a="77823789:sNHT31934984" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jBFLhTUx028953 for ; Thu, 15 Dec 2005 16:44:04 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Dec 2005 16:43:51 -0500 Received: from [10.82.240.13] ([10.82.240.13]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Dec 2005 16:43:51 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <439F7C8C.4070404@cisco.com> <439F816F.80502@cisco.com> <43A1DB7E.9080801@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Dec 2005 21:43:51.0641 (UTC) FILETIME=[A3949490:01C601C0] Message-ID: <43A1E397.5030805@cisco.com> Date: Thu, 15 Dec 2005 16:43:51 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: draft-holla-ospf-update-graceful-restart-00.txt - Topology Change LSAs and Helper Mode Exit To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43A1DB7E.9080801@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Hi Russ, Russ White wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > >None of this would be needed, of course, if LLS were used, would it? > IMHO, LLS would definitely be a better alternative than adding the exit GR TLV to the grace LSA. As I proposed in Vancouver, we're bringing LLS to the WG extensions for OSPF MANET anyway. However, I want to discuss that in a mail thread devoted solely this is piece of the Holla draft. >Why >not modify the current standard to allow optional LLS and OOB, and then >we could merge the drafts all into one big mess.... (?) > > With respect to GR, I really don't see much functional difference in whether one does an OOB sync or allows neighbor state to transition while advertising the neighbor as FULL during graceful restart. Thanks, Acee >:-) > >Russ > >Acee Lindem wrote: > > >> >> >>The draft proposes sub-classification of LSA changes for determining >>whether or >>not a helper should terminate graceful restart. RFC 3623 currently has 2 >>modes: >> 1. Strict LSA Checking - Any changed LSA which would be >>flooded to the restarting >> router will terminate graceful restart. >> 2. Changed LSAs will not terminate graceful restart (the >>default for most vendors). >> >>The draft further classifies LSA changes as constituting a topology >>change (in an effort to >>reduce the cases where graceful restart must be terminated). For >>example, a new LSA or >>new link added to a router LSA would not cause GR termination. I have >>the following >>concerns: >> >> 1. Are people asking for this? Most vendors default to #2. >> 2. New LSAs can cause the same problems as topology changes to >>existing ones. >> Consider the installation of new more specific routes - the >>characterization of new LSAs >> or "good" news being innocuous and "bad" news terminating >>grace restart seems >> arbitrary. The draft suggests monitoring all route changes >>involving next hops >> of the restarting router to avoid this problem. >> 3. Although my memory is weak, it seems to me that Vishwas' >>previous proposal >> was more robust. If there is a requirement for some level of >>LSA checking but less >> conservative than any LSA flooded to the restarting router >>than we should consider >> that one as well. >> >>Thanks, >>Acee >> >> >> > >- -- >riw@cisco.com CCIE <>< Grace Alone > > >-----BEGIN PGP SIGNATURE----- >Version: PGP Desktop 9.0.3 (Build 2932) > >iQA/AwUBQ6HbhREdu7FIVPTkEQLcowCg/rB5fh3270DmJiYIqYFr2O5m/zUAnRn9 >7ZhOOP/AXNjPXjMlIWlTyuCc >=QfZR >-----END PGP SIGNATURE----- > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 15 17:31:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En1dI-0002pE-AS for ospf-archive@megatron.ietf.org; Thu, 15 Dec 2005 17:31:28 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25287 for ; Thu, 15 Dec 2005 17:30:29 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <14.0000612F@wildebeest.ease.lsoft.com>; Thu, 15 Dec 2005 17:30:57 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93750640 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 15 Dec 2005 17:30:56 -0500 Received: from 171.71.176.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 15 Dec 2005 17:30:56 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 15 Dec 2005 14:30:56 -0800 X-IronPort-AV: i="3.99,258,1131350400"; d="scan'208"; a="685122131:sNHT35168784" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jBFMUrQs014823 for ; Thu, 15 Dec 2005 14:30:55 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Dec 2005 17:30:13 -0500 Received: from [10.82.240.13] ([10.82.240.13]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Dec 2005 17:30:13 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <439F7C8C.4070404@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Dec 2005 22:30:13.0670 (UTC) FILETIME=[1DCC8460:01C601C7] Message-ID: <43A1EE75.3060808@cisco.com> Date: Thu, 15 Dec 2005 17:30:13 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV to Grace LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <439F7C8C.4070404@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit I'm totally against this extension for the following reasons. 1. It introduces a totally new flooding scope for LSAs. In this context, they are scoped only to the restarting neighbor. 2. It changes the semantics of the LSA from a persistent advertisement to a one-shot signal. The draft proposed that the LSA is not stored in the link state database and need not be purged (it simply ceases to exist once it is ack'ed). IMHO, this changes the semantics of the grace LSA (and LSAs in general) too drastically. To make an analogy, it is like using your level to pound in a nail. It can be made to work but you may find out that you've broken your level. If we do agree there is a requirement for a potential helper router to signal that graceful restart isn't inappropriate or the helper just isn't feeling all that generous, then we should use one of the following mechanisms: 1. Link Local Signaling (LLS) 2. One-Way Hello I reject the supposition that this must wait until the next hello interval. A unicast hello is much better suited to one-shot signaling than a LSA. If you want to make it reliable, you simply continue to signal until the restarting router terminates GR. Thanks, Acee From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 15 17:49:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En1ud-0007l9-NR for ospf-archive@megatron.ietf.org; Thu, 15 Dec 2005 17:49:23 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27069 for ; Thu, 15 Dec 2005 17:48:25 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <7.00006149@wildebeest.ease.lsoft.com>; Thu, 15 Dec 2005 17:48:52 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93751846 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 15 Dec 2005 17:48:52 -0500 Received: from 171.71.176.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 15 Dec 2005 17:48:52 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 15 Dec 2005 14:48:53 -0800 X-IronPort-AV: i="3.99,258,1131350400"; d="scan'208"; a="685127893:sNHT32095820" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jBFMm0Qs025064 for ; Thu, 15 Dec 2005 14:48:50 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Dec 2005 17:48:39 -0500 Received: from [10.82.240.13] ([10.82.240.13]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Dec 2005 17:48:38 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <439F7C8C.4070404@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Dec 2005 22:48:38.0960 (UTC) FILETIME=[B09A6300:01C601C9] Message-ID: <43A1F2C6.8080407@cisco.com> Date: Thu, 15 Dec 2005 17:48:38 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - preservation of BDR status To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <439F7C8C.4070404@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit I don't see that preserving BDR status across restarts buys you anything. If there are N routers on the broadcast or NBMA network and the restarting router is preserved, you have to form (N - 1) adjacencies. If you don't, the new BDR has to form (N - 2) adjacencies (since it is already adjacent with the DR) plus the restarting router must form 2 adjacencies. Of course, the adjacency between the new BDR and restarting router is counted twice so in both cases you form (N - 1) adjacencies on the broadcast or NBMA network. Is there something wrong with my math? Additionally, one could argue that the restarting router already has enough work to do during the graceful restart and you'd rather off-load some of the work to a new BDR (all other things considered equal). Thanks, Acee From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 15 18:15:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En2Jp-0000Qn-P0 for ospf-archive@megatron.ietf.org; Thu, 15 Dec 2005 18:15:27 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00019 for ; Thu, 15 Dec 2005 18:14:26 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <8.00006158@wildebeest.ease.lsoft.com>; Thu, 15 Dec 2005 18:14:54 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93753803 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 15 Dec 2005 18:14:54 -0500 Received: from 171.71.176.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 15 Dec 2005 18:14:54 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 15 Dec 2005 15:14:54 -0800 X-IronPort-AV: i="3.99,258,1131350400"; d="scan'208"; a="378916437:sNHT34271102" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jBFNEi76002254 for ; Thu, 15 Dec 2005 15:14:51 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Dec 2005 18:14:49 -0500 Received: from [10.82.240.13] ([10.82.240.13]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Dec 2005 18:14:49 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <43A175DE.6060805@cisco.com> <43A1E3E6.38265DDC@earthlink.net> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Dec 2005 23:14:49.0789 (UTC) FILETIME=[58E3DED0:01C601CD] Message-ID: <43A1F8E9.6000001@cisco.com> Date: Thu, 15 Dec 2005 18:14:49 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Faster DD Exchange To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43A1E3E6.38265DDC@earthlink.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Hi Mitchell, I won't comment on your proposal (I'll wait for the draft ). However, see inline for answers to your questions. Erblichs wrote: >Group, > > Yes, filtering of LSAs are possible, but let me > suggest something else and then comment on the > filtering.. > > Lets see how can we say get a X speedup for > DD pkt xchanges? > > For those routers that have a multiple connections > with a nbr: > > * split the LSDB into an equal number > of groups as the number of nbr connections > (hopefully each having approx > the same number of hdrs that need to be > resolved), > * Amdahl's(spelling) law says you can at best > get close because the flow workloads can't be > perfectly EQUAL. > > * then process each group concurrently, with > each group having a different set of DD pkts, > > * at the completion of the exchange of DDs > or complete LSDB xchange, recombine the > LSDB. > > Thus the speedup can be 2x, 4x, 8x etc when the > individual link speeds are a bottleneck. This is > mostly helpful with kb/sec links or where we have > a overwhelming ability to process pkts in incoming > ports simultaneously, > > The speedup can even be greater if one side has the > LSAs that need resolving for we are continually waiting > for the next DD pkt. And it is not sent until we see > the ACK. So in extreme circumstance we can cut in half > our expected DD exchange time. Two links can result in > a 4x speedup due to each ACK requiring a min of 1 RTT!!!!! > > It is also helpful > when one wishes to send smaller than MTU size DD > pkts for fewer rexmits. This last item assumes that > with wireless the chance of say a 9k jumbo has a > significantly greater chance needing rexmits than > say a 254byte pkt. > > This is in effect aggregation. > > > Mitchell Erblich > PS: On a side note, doesn't the Ogier proposal assume > that the effort to filter the LSA headers that are to be > removed from DD exchanges beneficial? > > * Some of the LSA hdrs being xmited CAN to be filtered, > > * That the number of filtered hdrs is significant. > > * Doesn't the complete exchange of LSA headers verify > synchronization? > > No - you don't need to advertise LSA you know that your neighbor already has. The Database exchange is a "pull" model. You advertise what you have and the neighbor with whom you are establishing an adjacency decides whether he needs it. > * Won't the LSAs hdrs that are filtered result in > the recvr having a subset of EXPECTED set of hdrs? > Doesn't this require a check that missing hdrs are > already present? > > Nope. See above. > * For short duration lifetimes of LSAs or short remaining > lifetimes of LSAs, we can DELAY and update the nbr with a > newer instance during DD exhange. > > Reliable flooding solves this by flooding to all neighbors that are >= Exchange state. Thanks, Acee > ============================== > >Acee Lindem wrote: > > >>Anup Kumar T wrote: >> >> >> >>>According to RFC 2328, we send 1 DD packet, wait till the ack is seen and >>>only then send the next DD pkt. We can improve upon this. The idea is to >>>send N DD packets initially. Then, as and when an ack is seen, send the >>>next DD pkt. The existing DD Exchange procedure will have to be modified. >>> >>>Once the trigger is set by the initial N DD packets, the successive >>>exchanges will be faster (The waiting time is reduced). >>> >>>The routers can be made to negotiate the value of N before they enter into >>>DD Exchange. If they cannot negotiate (may happen during interoperation), >>>they will default to the normal behaviour i.e. to send 1 DD packet. >>> >>> >>> >>> >>Anup, >> >>Why would we want to introduce a non-backward compatible change to OSPF >>DD Exchange? >>Have you quantitatively measured the improvement? How does your loosely >>defined proposal >>behave in the presence of OSPF packet loss? Since we're not going to >>entertain this (unless >>someone can show a significant improvement in overall adjacency bring), >>I'm not going to >>even get into the technical details. >> >>On a related note, Richard Ogier has proposed a fully backward >>compatible change to OSPF >>DD Exchange in the context of the OSPF MANET work. His proposal is for >>an OSPF router >>NOT to include LSAs which have been received with the same or more >>recent instance from >>the neighbor with whom you are forming an adjacency. This is one of >>those ideas that >>once you hear you wonder why you didn't think of it :^). >> >>Acee >> >> >> >>>- Anup >>> >>> >>> >>> >>> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 15 21:46:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En5bn-0001WH-HU for ospf-archive@megatron.ietf.org; Thu, 15 Dec 2005 21:46:11 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20203 for ; Thu, 15 Dec 2005 21:45:11 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <10.000061A2@wildebeest.ease.lsoft.com>; Thu, 15 Dec 2005 21:45:39 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93769574 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 15 Dec 2005 21:45:38 -0500 Received: from 61.144.161.55 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 15 Dec 2005 21:45:34 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRK00HYGL98I9@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Dec 2005 10:51:08 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRK00HGHL952H@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Dec 2005 10:51:08 +0800 (CST) Received: from common1 ([10.110.94.86]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IRK00B7MLGUA5@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Dec 2005 10:55:47 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <000001c601ea$c13a0d20$565e6e0a@china.huawei.com> Date: Fri, 16 Dec 2005 10:45:15 +0800 Reply-To: Mailing List Sender: Mailing List From: Ashok Subject: Re: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV to Grace LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43A1EE75.3060808@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT Hi Acee, I agree that the use of an LSA to signal a one time event is different from the nature of LSA in OSPF. At the time the draft was written, we were unaware of the Manet proposals and the plan to bring back LLS to augment GR mechanism. Piggybacking the exit signal on the link local grace LSA, was our way of achieving LLS without actually employing the ideas in the expired LLS draft. Also, the requirement that this signal to be not stored in the database or flushed later, is a natural consequence of the Grace LSA format and usage, and does not require any special handling. If LLS is going to be brought back from the dead, then perhaps the LLS method needs discussion on its merit for signaling helper exit. I do have some reservations on using LLS in hello packets to achieve such signaling. The purpose of Hello packets is different and on broadcast networks, it just becomes messy. I am completely against using 1-way in hello packets to signal exit of Helper mode. The meaning of 1-way is defined by the Ospf protocol. It is incorrect to add any implied meaning to it. If the Helper is already in state 2-way or above with the Nbr, then forcefully going to 1-way is completely wrong. The handling of exit signal is upto the restarting router. It may or may not tear down the adjacency (in what ever state it may be) with the helper router. The purpose is merely to flush grace lsas. This was the intention of the exit-grace tlv. Sending 1-way in hello has other undesired consequences due to its primary meaning as defined by 2328. Regards, Ashok -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee Lindem Sent: Friday, December 16, 2005 6:30 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV to Grace LSA I'm totally against this extension for the following reasons. 1. It introduces a totally new flooding scope for LSAs. In this context, they are scoped only to the restarting neighbor. 2. It changes the semantics of the LSA from a persistent advertisement to a one-shot signal. The draft proposed that the LSA is not stored in the link state database and need not be purged (it simply ceases to exist once it is ack'ed). IMHO, this changes the semantics of the grace LSA (and LSAs in general) too drastically. To make an analogy, it is like using your level to pound in a nail. It can be made to work but you may find out that you've broken your level. If we do agree there is a requirement for a potential helper router to signal that graceful restart isn't inappropriate or the helper just isn't feeling all that generous, then we should use one of the following mechanisms: 1. Link Local Signaling (LLS) 2. One-Way Hello I reject the supposition that this must wait until the next hello interval. A unicast hello is much better suited to one-shot signaling than a LSA. If you want to make it reliable, you simply continue to signal until the restarting router terminates GR. Thanks, Acee From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 15 22:10:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En5zY-0008VO-3S for ospf-archive@megatron.ietf.org; Thu, 15 Dec 2005 22:10:44 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22731 for ; Thu, 15 Dec 2005 22:09:43 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <4.000061B5@wildebeest.ease.lsoft.com>; Thu, 15 Dec 2005 22:10:11 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93771399 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 15 Dec 2005 22:10:11 -0500 Received: from 61.144.161.53 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 15 Dec 2005 22:10:03 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRK00CGQMIYVS@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Dec 2005 11:18:34 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRK00FJBMIXPM@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Dec 2005 11:18:34 +0800 (CST) Received: from Nitink20745 ([10.18.4.177]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IRK00B9FMLYA5@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Dec 2005 11:20:23 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: multipart/mixed; boundary="Boundary_(ID_um+mv+SlYYcgyo9n/Ixyvg)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <001201c601ee$30a064e0$b104120a@china.huawei.com> Date: Fri, 16 Dec 2005 08:39:54 +0530 Reply-To: Mailing List Sender: Mailing List From: Nitin Kakkar Subject: Re: Faster DD Exchange To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43A1F8E9.6000001@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: This is a multi-part message in MIME format. --Boundary_(ID_um+mv+SlYYcgyo9n/Ixyvg) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Group, We had submitted a draft on IETF on it. Same is being sent to group for your kind reviews. A copy attached here. Regards Nitin -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee Lindem Sent: Friday, December 16, 2005 4:45 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Faster DD Exchange Hi Mitchell, I won't comment on your proposal (I'll wait for the draft ). However, see inline for answers to your questions. Erblichs wrote: >Group, > > Yes, filtering of LSAs are possible, but let me > suggest something else and then comment on the > filtering.. > > Lets see how can we say get a X speedup for > DD pkt xchanges? > > For those routers that have a multiple connections > with a nbr: > > * split the LSDB into an equal number > of groups as the number of nbr connections > (hopefully each having approx > the same number of hdrs that need to be > resolved), > * Amdahl's(spelling) law says you can at best > get close because the flow workloads can't be > perfectly EQUAL. > > * then process each group concurrently, with > each group having a different set of DD pkts, > > * at the completion of the exchange of DDs > or complete LSDB xchange, recombine the > LSDB. > > Thus the speedup can be 2x, 4x, 8x etc when the > individual link speeds are a bottleneck. This is > mostly helpful with kb/sec links or where we have > a overwhelming ability to process pkts in incoming > ports simultaneously, > > The speedup can even be greater if one side has the > LSAs that need resolving for we are continually waiting > for the next DD pkt. And it is not sent until we see > the ACK. So in extreme circumstance we can cut in half > our expected DD exchange time. Two links can result in > a 4x speedup due to each ACK requiring a min of 1 RTT!!!!! > > It is also helpful > when one wishes to send smaller than MTU size DD > pkts for fewer rexmits. This last item assumes that > with wireless the chance of say a 9k jumbo has a > significantly greater chance needing rexmits than > say a 254byte pkt. > > This is in effect aggregation. > > > Mitchell Erblich > PS: On a side note, doesn't the Ogier proposal assume > that the effort to filter the LSA headers that are to be > removed from DD exchanges beneficial? > > * Some of the LSA hdrs being xmited CAN to be filtered, > > * That the number of filtered hdrs is significant. > > * Doesn't the complete exchange of LSA headers verify > synchronization? > > No - you don't need to advertise LSA you know that your neighbor already has. The Database exchange is a "pull" model. You advertise what you have and the neighbor with whom you are establishing an adjacency decides whether he needs it. > * Won't the LSAs hdrs that are filtered result in > the recvr having a subset of EXPECTED set of hdrs? > Doesn't this require a check that missing hdrs are > already present? > > Nope. See above. > * For short duration lifetimes of LSAs or short remaining > lifetimes of LSAs, we can DELAY and update the nbr with a > newer instance during DD exhange. > > Reliable flooding solves this by flooding to all neighbors that are >= Exchange state. Thanks, Acee > ============================== > >Acee Lindem wrote: > > >>Anup Kumar T wrote: >> >> >> >>>According to RFC 2328, we send 1 DD packet, wait till the ack is seen and >>>only then send the next DD pkt. We can improve upon this. The idea is to >>>send N DD packets initially. Then, as and when an ack is seen, send the >>>next DD pkt. The existing DD Exchange procedure will have to be modified. >>> >>>Once the trigger is set by the initial N DD packets, the successive >>>exchanges will be faster (The waiting time is reduced). >>> >>>The routers can be made to negotiate the value of N before they enter into >>>DD Exchange. If they cannot negotiate (may happen during interoperation), >>>they will default to the normal behaviour i.e. to send 1 DD packet. >>> >>> >>> >>> >>Anup, >> >>Why would we want to introduce a non-backward compatible change to OSPF >>DD Exchange? >>Have you quantitatively measured the improvement? How does your loosely >>defined proposal >>behave in the presence of OSPF packet loss? Since we're not going to >>entertain this (unless >>someone can show a significant improvement in overall adjacency bring), >>I'm not going to >>even get into the technical details. >> >>On a related note, Richard Ogier has proposed a fully backward >>compatible change to OSPF >>DD Exchange in the context of the OSPF MANET work. His proposal is for >>an OSPF router >>NOT to include LSAs which have been received with the same or more >>recent instance from >>the neighbor with whom you are forming an adjacency. This is one of >>those ideas that >>once you hear you wonder why you didn't think of it :^). >> >>Acee >> >> >> >>>- Anup >>> >>> >>> >>> >>> > > > --Boundary_(ID_um+mv+SlYYcgyo9n/Ixyvg) Content-type: text/plain; name=draft-ietf-ospf-multi-links.txt Content-disposition: attachment; filename=draft-ietf-ospf-multi-links.txt Content-Transfer-Encoding: quoted-printable Internet Draft OSPF Multi Links December 2005=20 =20 =20 Network Working Group =20 Internet Draft Nitin Kakkar=20 K.L Srini=20 Document: draft-ietf-ospf-multi-link-00.txt Huawei=20 Technologies=20 Bangalore=20 Expires: June 2006 December 2005=20 =20 =20 OSPF Multiple Interface Optimizations=20 =20 =20 Status of this Memo=20 =20 This document is a submission by the author to IETF Network Working=20 Group of the Internet Engineering Task Force (IETF). Comments should = be submitted to the nitink@huawei.com.=20 =20 By submitting this Internet-Draft, each author represents that any=20 applicable patent or other IPR claims of which he or she is aware=20 have been or will be disclosed, and any of which he or she becomes=20 aware will be disclosed, in accordance with Section 6 of BCP 79. =20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that=20 other groups may also distribute working documents as Internet- Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of six months = and may be updated, replaced, or obsoleted by other documents at any=20 time.It is inappropriate to use Internet-Drafts as reference material = or to cite them other than as "work in progress."=20 =20 The list of current Internet-Drafts can be accessed at =20 http://www.ietf.org/ietf/1id-abstracts.txt. =20 =20 The list of Internet-Draft Shadow Directories can be accessed at =20 http://www.ietf.org/shadow.html.=20 =20 =20 Abstract=20 =20 OSPF is a link state IGP routing protocol, but it does not utilizes=20 multiple links between adjacent routers efficiently.=20 This Memo tries to utilize multiple links between adjacent routers to = make initial adjacency establishment & flooding more optimized, such=20 that these procedures become faster and consumes lesser bandwidth.=20 =20 Conventions used in this document=20 =20 =20 Expires - June 2006 [Page 1]=20 =0CInternet Draft OSPF Multi Links December = 2005=20 =20 =20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this = document are to be interpreted as described in RFC-2119.=20 =20 Table of Contents=20 =20 1. Introduction...................................................2=20 2. Adjacency formation Recommendation.............................2=20 To avoid these problems we provide following recommendations......3=20 3. Flooding Recommendations.......................................4=20 4. Adjacency Switching Recommendations............................6=20 5. Patents........................................................6=20 6. Formal Syntax..................................................6=20 Security Considerations...........................................6=20 References........................................................6=20 Acknowledgments...................................................7=20 Author's Addresses................................................7=20 Disclaimer of Validity............................................7=20 =20 =20 1. =0D Introduction=20 =20 In this document ospf refers to both version 2 and version 3 of open=20 shortest path first protocol.=20 Any large network is likely to have multiple links between routes, if = ospf is running in such environment it is likely to receive multiple=20 requests to form adjacency with peer on . Under large databases=20 adjacency formation put extreme strain on cpu and network resources.=20 Similarly during flooding, LSA=92s are flooded and retransmitted=20 multiple times to the same neighbor because no special handling is=20 provided for topologies involving multiple interfaces between peers.=20 =20 In order to improve cpu and network utilization during initial=20 adjacency establishment and flooding we provide some recommendations=20 in section 2,3 and 4.=20 =20 =20 2. =0D Adjacency formation Recommendation=20 If two adjacent routes have multiple links between them, whenever=20 links/routers come up simultaneously, OSPF tries to form multiple=20 adjacencies with the same neighbor almost simultaneously (Subjected=20 to Maximum Concurrent Adjacencies Number described in [3]).=20 This approach has following problems=20 1) LSDB=92s are traversed multiple times.=20 2) Most of the LSA's are propagated Multiple times =20 =20 =20 Expires - June 2006 [Page 2]=20 =0CInternet Draft OSPF Multi Links December = 2005=20 =20 =20 AS Scope LSA=92s will be propagated multiple times, Area scope=20 LSA's May be propagated multiple times if adjacencies are in same=20 area. =20 2) Subjected to Maximum Concurrent Adjacencies Number [3], some=20 distinct router will have to wait to form adjacency.=20 =20 To avoid these problems we provide following recommendations=20 =20 Classify every adjacency as =91=91Primary=92=92 or = =91=91Secondary=92=92. Always first=20 adjacency with a peer is marked as Primary and subsequent=20 adjacencies with the same peer are marked as =91=91Secondary=92=92.=20 =20 Before entering 2way state with a peer,=20 1. If there is NO existing adjacency with the peer=20 Prepare DB description packet as described in [1].=20 =20 2.If there is already a FULL adjacency with the same peer.=20 A)If there is an existing adjacency in same area with the peer,=20 Only describe Link Scope LSA=92s in Db description packet=20 B)If there is an existing adjacency in different, non stub area=20 with the peer,=20 Only describe Area scope and Link Scope LSA=92s in Db=20 description packet=20 C) If all existing adjacencies with the peer are in stub area and=20 new adjacency is in non-stub area,=20 Prepare DB description packet as described in [1].=20 =20 3.If already an adjacency formation is in progress with the peer=20 (i.e NFSM state 2 way or greater but less then full, irrespective=20 of area and interface).=20 A)Mark adjacency as Secondary=20 B)Prepare DB Description packet as described in 2.A , 2.B and 2.C=20 above.=20 C)If secondary adjacency exhausts its request list first, borrow=20 some external LSA headers(Or area scope LSA=92s if both primary=20 and secondary adjacencies are in same area) from Primary=20 adjacencies request list, Mark secondary adjacency state as=20 =91=91Borrowed=92=92 and request LSA=92s to peer on secondary = adjacency ,=20 till primary adjacency=92s request list also exhausts.=20 D)If to some reason secondary adjacency is terminated abnormally=20 and its state is borrowed, simply copy the retransmit list of=20 Secondary neighbor to Primary adjacency=92s neighbor.=20 E)Do not make secondary adjacency FULL before primary adjacency.=20 =20 =20 Expires - June 2006 [Page 3]=20 =0CInternet Draft OSPF Multi Links December = 2005=20 =20 =20 F)If to some reason Primary adjacency is terminated abnormally,=20 router must restart all secondary adjacencies by sending a=20 deliberate sequence number mismatch,( This is faster method to=20 reestablish adjacency then One way Hello).=20 =20 It is easier to see that in presence of multiple interfaces between=20 peers adjacency establishment will be faster because of 1) Reduced=20 request list size of secondary adjacencies. 2) Concurrent and=20 disjoint usage of link bandwidth for multiple adjacencies.=20 =20 =20 3. =0D Flooding Recommendations=20 Whenever multiple adjacencies exists between same peers it is=20 fruitless to flood LSA=92s multiple times. In this section we will=20 present an approach to optimize flooding by minimizing the=20 duplication of LS updates.=20 We introduce following new flags,=20 In neighbor structure we introduce flag =91=91ASMaster=92=92, used = for AS=20 scope LSA=92s.=20 Whenever multiple adjacencies exist between two peers, it will=20 naturally have multiple neighbor entries. One of these neighbor=20 entries from non stub area will be marked as =91=91ASMaster=92=92 =20 A) If the interface on which it is connected to neighbor is the=20 fastest (highest bandwidth) among all interfaces connected to same=20 neighbor, =20 B) If multiple interfaces are of same bandwidth then interface with=20 highest IP(ipv6 for ospfv3) MTU is preferred., =20 C) If Mtu is also same, interface with highest IF Index is=20 preferred.=20 =20 In Interface structure we introduce a new flag =91=91FloodAS=92=92,=20 Whenever an Interface contains at least one neighbor with = =91=91ASMaster=92=92=20 flag set, its =91=91FloodAS=92=92 flag will be set.=20 =20 Similarly we introduce a flag =91=91AreaMaster=92=92 in neighbor = structure,=20 used for AREA Scope LSA=92s. This flag will be set on per area basis=20 for the neighbor on fastest link. I.e Among adjacencies to same=20 pear in same area, FloodArea will set for the neighbor stucture on =20 fastest interface (Same criteria as described in A,B & C above). =20 Similarly in Interface structure we introduce another new flag=20 =91=91FloodArea=92=92, will be set if there is a neighbor with = =91=91AreaMaster=92=92=20 flag set.=20 =20 =20 =20 Expires - June 2006 [Page 4]=20 =0CInternet Draft OSPF Multi Links December = 2005=20 =20 =20 Example=20 Lets say between two routers A & B there are 4 adjacencies number 1=20 -4, And assume link 1 & 2 are in Area 0, Link 3 & 4 are in Area 1.=20 Further Link capacities are Link1-1Mbps, Link2-100Mbps, Link3- 64kbps, MTU1500, Link4-64Kbps MTU 1280.=20 _____ _____=20 | |--------|1 |=20 | A |--------|2 B |=20 | |--------|3 | =20 |_____|--------|4____|=20 =20 According to algorithm described=20 Link 2 will be marked as =91=91FloodAS=92=92 and also = =91=91FloodArea=92=92 for area 0.=20 Link 3 will be marked as =91=91FloodArea=92=92 for area 1.=20 =20 Flooding Algorithm Modification=20 Flooding remains the same as section 13 of [1] with the flowing=20 additional checks=20 1) Flood an AS scope LSA on an interface only when it=92s = =91=91FloodASE=92=92=20 flag is set=20 2) Add AS Scope LSA=92s to the retransmit list of only neighbors with = =91=91ASEmaster=92=92 flag set,=20 3) Flood an Area scope LSA on an interface only when its = =91=91FloodArea=92=92=20 flag is set.=20 4) Add Area scope LSA=92s to the retransmit list of only neighbors=20 with =91=91AREAMaster=92=92 flag set.=20 5) When Ifdown event occurs for interface marked as=20 =91=91FloodASE=92=92/=92=92FloodArea=92=92, or KillNbr event occur = for neighbors=20 marked as =91=91ASMaster=92=92 or =91=91AreaMaster=92=92, select a = new =91=91ASMaster=92=92 =20 and =91=91AreaMaster=92=92 neighbor and copy the retransmit list = from=20 neighbors to the new =91=91master=92=92. If no new neighbor is = found=20 discard entries from retransmit list.=20 =20 It is easier to see that flooding will be lighter because only one=20 interface is used for retransmission and only a few interfaces will=20 be used for flooding.=20 From our example only Link-2 will be used to flood AS Scope LSA=92s.=20 Further Link-2 will be used to flood Area scope LSA=92s in Area 0 &=20 Link 3 will be used to flood Area Scope LSA=92s in Area 1.=20 =20 =20 =20 =20 Expires - June 2006 [Page 5]=20 =0CInternet Draft OSPF Multi Links December = 2005=20 =20 =20 4. =0D Adjacency Switching Recommendations=20 RFC 4222 explicitly defines max concurrent DD number and advises to=20 throttle more adjacencies. Further RFC4222 prohibits terminating=20 adjacencies in the middle. This approach has a problem that whenever=20 slow interfaces come up first and makeup max dd count number faster=20 interfaces have to wait unusually long time to form adjacencies.=20 For this scenario we recommend=20 1) If a new adjacency request comes up from a neighbor which is=20 already having an adjacency with us do not apply max concurrent=20 DD criteria on it.=20 2) While building BD Description packet, keep a count of all LSA=92s=20 sizes, so that we know the total amount of bytes to be sent to=20 peer.=20 3) Whenever receive an acknowledge packet during dd formation, keep=20 a count of bytes already reached peers.=20 =20 These two count along with interface bandwidth will give us an=20 estimate of remaining time for an adjacency.=20 =20 If Remaining time for forming adjacency >> Time for new adjacency,=20 send sequence number mismatch to first adjacency and form adjacency=20 on the faster interface.=20 =20 =20 5. =0D Patents=20 A Patent has been applied for this mechanism in Peoples Republic of=20 China=92s Beijing patent office. Approval is pending.=20 =20 =20 6. =0D Formal Syntax=20 =20 The following syntax specification uses the augmented Backus-Naur=20 Form (BNF) as described in RFC-2234.=20 =20 =20 Security Considerations=20 =20 This document does not introduce any new security issues to OSPF.=20 =20 =20 References=20 =20 [RFC2328] J Moy, =91=91OSPF Version 2=92=92.=20 [RFC2740] J Moy, R Coltun, D Ferguson, =91=91OSPF for IPV6=92=92.=20 =20 =20 Expires - June 2006 [Page 6]=20 =0CInternet Draft OSPF Multi Links December = 2005=20 =20 =20 [RFC4222] G Chodhury, Ed. " Prioritized Treatment of Specific OSPF=20 Version 2 Packets and Congestion Avoidance=92=92.=20 =20 =20 Acknowledgments=20 =20 We would like to acknowledge the support and helpful comments of Mr=20 Praveen GS, Mr Anup, Mr Raghu, Mr Zhangjinagping ,Mr Fucho.and Mr=20 Prabhu G.Biradar.=20 =20 =20 Author's Addresses=20 =20 Nitin Kakkar =20 Huawei Technologies India Pvt Ltd,=20 Level-3, Leela Galleria,=20 The Leela Palace, #23 Airport Road, =20 Bangalore 560008, India=20 Phone: +91 80 5217192=20 Email: nitink@huawei.com=20 =20 KL Srini =20 Huawei Technologies India Pvt Ltd,=20 Level-3, Leela Galleria,=20 The Leela Palace, #23 Airport Road, =20 Bangalore 560008, India=20 Phone: +91 80 5217192=20 Email: kls@huawei.com=20 =20 =20 Disclaimer of Validity=20 =20 "This document and the information contained herein are provided on = =20 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE =20 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE = =20 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR = IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF =20 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED =20 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." = =20 =20 Copyright Statement =20 =20 Copyright (C) The Internet Society (2005). This document is =20 subject to the rights, licenses and restrictions contained in BCP =20 78, and except as set forth therein, the authors retain all their =20 rights.=20 =20 =20 Expires - June 2006 [Page 7]=20 =0C= --Boundary_(ID_um+mv+SlYYcgyo9n/Ixyvg)-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 15 22:12:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En61Z-0001rF-B0 for ospf-archive@megatron.ietf.org; Thu, 15 Dec 2005 22:12:53 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23066 for ; Thu, 15 Dec 2005 22:11:48 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <9.000061AC@wildebeest.ease.lsoft.com>; Thu, 15 Dec 2005 22:12:17 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93771610 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 15 Dec 2005 22:12:17 -0500 Received: from 61.144.161.55 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 15 Dec 2005 22:12:11 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRK007IWM7WD0@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Dec 2005 11:11:57 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRK002W7M7VGR@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Dec 2005 11:11:56 +0800 (CST) Received: from Nitink20745 ([10.18.4.177]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IRK00M4JMLFJL@szxml01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Dec 2005 11:20:04 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: multipart/mixed; boundary="Boundary_(ID_Txz+5q/O1nK5VsCiWw0T8A)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <000801c601ed$a991a810$b104120a@china.huawei.com> Date: Fri, 16 Dec 2005 08:36:07 +0530 Reply-To: Mailing List Sender: Mailing List From: Nitin Kakkar Subject: OSPF Multi link draft Comments: cc: kls@huawei.com To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43A1E3E6.38265DDC@earthlink.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: This is a multi-part message in MIME format. --Boundary_(ID_Txz+5q/O1nK5VsCiWw0T8A) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT We were working on the same, We have a small draft for it, please have a look and let us know your opinion. Regards Nitin -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Erblichs Sent: Friday, December 16, 2005 3:15 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Faster DD Exchange Group, Yes, filtering of LSAs are possible, but let me suggest something else and then comment on the filtering.. Lets see how can we say get a X speedup for DD pkt xchanges? For those routers that have a multiple connections with a nbr: * split the LSDB into an equal number of groups as the number of nbr connections (hopefully each having approx the same number of hdrs that need to be resolved), * Amdahl's(spelling) law says you can at best get close because the flow workloads can't be perfectly EQUAL. * then process each group concurrently, with each group having a different set of DD pkts, * at the completion of the exchange of DDs or complete LSDB xchange, recombine the LSDB. Thus the speedup can be 2x, 4x, 8x etc when the individual link speeds are a bottleneck. This is mostly helpful with kb/sec links or where we have a overwhelming ability to process pkts in incoming ports simultaneously, The speedup can even be greater if one side has the LSAs that need resolving for we are continually waiting for the next DD pkt. And it is not sent until we see the ACK. So in extreme circumstance we can cut in half our expected DD exchange time. Two links can result in a 4x speedup due to each ACK requiring a min of 1 RTT!!!!! It is also helpful when one wishes to send smaller than MTU size DD pkts for fewer rexmits. This last item assumes that with wireless the chance of say a 9k jumbo has a significantly greater chance needing rexmits than say a 254byte pkt. This is in effect aggregation. Mitchell Erblich PS: On a side note, doesn't the Ogier proposal assume that the effort to filter the LSA headers that are to be removed from DD exchanges beneficial? * Some of the LSA hdrs being xmited CAN to be filtered, * That the number of filtered hdrs is significant. * Doesn't the complete exchange of LSA headers verify synchronization? * Won't the LSAs hdrs that are filtered result in the recvr having a subset of EXPECTED set of hdrs? Doesn't this require a check that missing hdrs are already present? * For short duration lifetimes of LSAs or short remaining lifetimes of LSAs, we can DELAY and update the nbr with a newer instance during DD exhange. ============================== Acee Lindem wrote: > > Anup Kumar T wrote: > > >According to RFC 2328, we send 1 DD packet, wait till the ack is seen and > >only then send the next DD pkt. We can improve upon this. The idea is to > >send N DD packets initially. Then, as and when an ack is seen, send the > >next DD pkt. The existing DD Exchange procedure will have to be modified. > > > >Once the trigger is set by the initial N DD packets, the successive > >exchanges will be faster (The waiting time is reduced). > > > >The routers can be made to negotiate the value of N before they enter into > >DD Exchange. If they cannot negotiate (may happen during interoperation), > >they will default to the normal behaviour i.e. to send 1 DD packet. > > > > > Anup, > > Why would we want to introduce a non-backward compatible change to OSPF > DD Exchange? > Have you quantitatively measured the improvement? How does your loosely > defined proposal > behave in the presence of OSPF packet loss? Since we're not going to > entertain this (unless > someone can show a significant improvement in overall adjacency bring), > I'm not going to > even get into the technical details. > > On a related note, Richard Ogier has proposed a fully backward > compatible change to OSPF > DD Exchange in the context of the OSPF MANET work. His proposal is for > an OSPF router > NOT to include LSAs which have been received with the same or more > recent instance from > the neighbor with whom you are forming an adjacency. This is one of > those ideas that > once you hear you wonder why you didn't think of it :^). > > Acee > > > > >- Anup > > > > > > --Boundary_(ID_Txz+5q/O1nK5VsCiWw0T8A) Content-type: text/plain; name=draft-ietf-ospf-multi-links.txt Content-disposition: attachment; filename=draft-ietf-ospf-multi-links.txt Content-Transfer-Encoding: quoted-printable Internet Draft OSPF Multi Links December 2005=20 =20 =20 Network Working Group =20 Internet Draft Nitin Kakkar=20 K.L Srini=20 Document: draft-ietf-ospf-multi-link-00.txt Huawei=20 Technologies=20 Bangalore=20 Expires: June 2006 December 2005=20 =20 =20 OSPF Multiple Interface Optimizations=20 =20 =20 Status of this Memo=20 =20 This document is a submission by the author to IETF Network Working=20 Group of the Internet Engineering Task Force (IETF). Comments should = be submitted to the nitink@huawei.com.=20 =20 By submitting this Internet-Draft, each author represents that any=20 applicable patent or other IPR claims of which he or she is aware=20 have been or will be disclosed, and any of which he or she becomes=20 aware will be disclosed, in accordance with Section 6 of BCP 79. =20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that=20 other groups may also distribute working documents as Internet- Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of six months = and may be updated, replaced, or obsoleted by other documents at any=20 time.It is inappropriate to use Internet-Drafts as reference material = or to cite them other than as "work in progress."=20 =20 The list of current Internet-Drafts can be accessed at =20 http://www.ietf.org/ietf/1id-abstracts.txt. =20 =20 The list of Internet-Draft Shadow Directories can be accessed at =20 http://www.ietf.org/shadow.html.=20 =20 =20 Abstract=20 =20 OSPF is a link state IGP routing protocol, but it does not utilizes=20 multiple links between adjacent routers efficiently.=20 This Memo tries to utilize multiple links between adjacent routers to = make initial adjacency establishment & flooding more optimized, such=20 that these procedures become faster and consumes lesser bandwidth.=20 =20 Conventions used in this document=20 =20 =20 Expires - June 2006 [Page 1]=20 =0CInternet Draft OSPF Multi Links December = 2005=20 =20 =20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this = document are to be interpreted as described in RFC-2119.=20 =20 Table of Contents=20 =20 1. Introduction...................................................2=20 2. Adjacency formation Recommendation.............................2=20 To avoid these problems we provide following recommendations......3=20 3. Flooding Recommendations.......................................4=20 4. Adjacency Switching Recommendations............................6=20 5. Patents........................................................6=20 6. Formal Syntax..................................................6=20 Security Considerations...........................................6=20 References........................................................6=20 Acknowledgments...................................................7=20 Author's Addresses................................................7=20 Disclaimer of Validity............................................7=20 =20 =20 1. =0D Introduction=20 =20 In this document ospf refers to both version 2 and version 3 of open=20 shortest path first protocol.=20 Any large network is likely to have multiple links between routes, if = ospf is running in such environment it is likely to receive multiple=20 requests to form adjacency with peer on . Under large databases=20 adjacency formation put extreme strain on cpu and network resources.=20 Similarly during flooding, LSA=92s are flooded and retransmitted=20 multiple times to the same neighbor because no special handling is=20 provided for topologies involving multiple interfaces between peers.=20 =20 In order to improve cpu and network utilization during initial=20 adjacency establishment and flooding we provide some recommendations=20 in section 2,3 and 4.=20 =20 =20 2. =0D Adjacency formation Recommendation=20 If two adjacent routes have multiple links between them, whenever=20 links/routers come up simultaneously, OSPF tries to form multiple=20 adjacencies with the same neighbor almost simultaneously (Subjected=20 to Maximum Concurrent Adjacencies Number described in [3]).=20 This approach has following problems=20 1) LSDB=92s are traversed multiple times.=20 2) Most of the LSA's are propagated Multiple times =20 =20 =20 Expires - June 2006 [Page 2]=20 =0CInternet Draft OSPF Multi Links December = 2005=20 =20 =20 AS Scope LSA=92s will be propagated multiple times, Area scope=20 LSA's May be propagated multiple times if adjacencies are in same=20 area. =20 2) Subjected to Maximum Concurrent Adjacencies Number [3], some=20 distinct router will have to wait to form adjacency.=20 =20 To avoid these problems we provide following recommendations=20 =20 Classify every adjacency as =91=91Primary=92=92 or = =91=91Secondary=92=92. Always first=20 adjacency with a peer is marked as Primary and subsequent=20 adjacencies with the same peer are marked as =91=91Secondary=92=92.=20 =20 Before entering 2way state with a peer,=20 1. If there is NO existing adjacency with the peer=20 Prepare DB description packet as described in [1].=20 =20 2.If there is already a FULL adjacency with the same peer.=20 A)If there is an existing adjacency in same area with the peer,=20 Only describe Link Scope LSA=92s in Db description packet=20 B)If there is an existing adjacency in different, non stub area=20 with the peer,=20 Only describe Area scope and Link Scope LSA=92s in Db=20 description packet=20 C) If all existing adjacencies with the peer are in stub area and=20 new adjacency is in non-stub area,=20 Prepare DB description packet as described in [1].=20 =20 3.If already an adjacency formation is in progress with the peer=20 (i.e NFSM state 2 way or greater but less then full, irrespective=20 of area and interface).=20 A)Mark adjacency as Secondary=20 B)Prepare DB Description packet as described in 2.A , 2.B and 2.C=20 above.=20 C)If secondary adjacency exhausts its request list first, borrow=20 some external LSA headers(Or area scope LSA=92s if both primary=20 and secondary adjacencies are in same area) from Primary=20 adjacencies request list, Mark secondary adjacency state as=20 =91=91Borrowed=92=92 and request LSA=92s to peer on secondary = adjacency ,=20 till primary adjacency=92s request list also exhausts.=20 D)If to some reason secondary adjacency is terminated abnormally=20 and its state is borrowed, simply copy the retransmit list of=20 Secondary neighbor to Primary adjacency=92s neighbor.=20 E)Do not make secondary adjacency FULL before primary adjacency.=20 =20 =20 Expires - June 2006 [Page 3]=20 =0CInternet Draft OSPF Multi Links December = 2005=20 =20 =20 F)If to some reason Primary adjacency is terminated abnormally,=20 router must restart all secondary adjacencies by sending a=20 deliberate sequence number mismatch,( This is faster method to=20 reestablish adjacency then One way Hello).=20 =20 It is easier to see that in presence of multiple interfaces between=20 peers adjacency establishment will be faster because of 1) Reduced=20 request list size of secondary adjacencies. 2) Concurrent and=20 disjoint usage of link bandwidth for multiple adjacencies.=20 =20 =20 3. =0D Flooding Recommendations=20 Whenever multiple adjacencies exists between same peers it is=20 fruitless to flood LSA=92s multiple times. In this section we will=20 present an approach to optimize flooding by minimizing the=20 duplication of LS updates.=20 We introduce following new flags,=20 In neighbor structure we introduce flag =91=91ASMaster=92=92, used = for AS=20 scope LSA=92s.=20 Whenever multiple adjacencies exist between two peers, it will=20 naturally have multiple neighbor entries. One of these neighbor=20 entries from non stub area will be marked as =91=91ASMaster=92=92 =20 A) If the interface on which it is connected to neighbor is the=20 fastest (highest bandwidth) among all interfaces connected to same=20 neighbor, =20 B) If multiple interfaces are of same bandwidth then interface with=20 highest IP(ipv6 for ospfv3) MTU is preferred., =20 C) If Mtu is also same, interface with highest IF Index is=20 preferred.=20 =20 In Interface structure we introduce a new flag =91=91FloodAS=92=92,=20 Whenever an Interface contains at least one neighbor with = =91=91ASMaster=92=92=20 flag set, its =91=91FloodAS=92=92 flag will be set.=20 =20 Similarly we introduce a flag =91=91AreaMaster=92=92 in neighbor = structure,=20 used for AREA Scope LSA=92s. This flag will be set on per area basis=20 for the neighbor on fastest link. I.e Among adjacencies to same=20 pear in same area, FloodArea will set for the neighbor stucture on =20 fastest interface (Same criteria as described in A,B & C above). =20 Similarly in Interface structure we introduce another new flag=20 =91=91FloodArea=92=92, will be set if there is a neighbor with = =91=91AreaMaster=92=92=20 flag set.=20 =20 =20 =20 Expires - June 2006 [Page 4]=20 =0CInternet Draft OSPF Multi Links December = 2005=20 =20 =20 Example=20 Lets say between two routers A & B there are 4 adjacencies number 1=20 -4, And assume link 1 & 2 are in Area 0, Link 3 & 4 are in Area 1.=20 Further Link capacities are Link1-1Mbps, Link2-100Mbps, Link3- 64kbps, MTU1500, Link4-64Kbps MTU 1280.=20 _____ _____=20 | |--------|1 |=20 | A |--------|2 B |=20 | |--------|3 | =20 |_____|--------|4____|=20 =20 According to algorithm described=20 Link 2 will be marked as =91=91FloodAS=92=92 and also = =91=91FloodArea=92=92 for area 0.=20 Link 3 will be marked as =91=91FloodArea=92=92 for area 1.=20 =20 Flooding Algorithm Modification=20 Flooding remains the same as section 13 of [1] with the flowing=20 additional checks=20 1) Flood an AS scope LSA on an interface only when it=92s = =91=91FloodASE=92=92=20 flag is set=20 2) Add AS Scope LSA=92s to the retransmit list of only neighbors with = =91=91ASEmaster=92=92 flag set,=20 3) Flood an Area scope LSA on an interface only when its = =91=91FloodArea=92=92=20 flag is set.=20 4) Add Area scope LSA=92s to the retransmit list of only neighbors=20 with =91=91AREAMaster=92=92 flag set.=20 5) When Ifdown event occurs for interface marked as=20 =91=91FloodASE=92=92/=92=92FloodArea=92=92, or KillNbr event occur = for neighbors=20 marked as =91=91ASMaster=92=92 or =91=91AreaMaster=92=92, select a = new =91=91ASMaster=92=92 =20 and =91=91AreaMaster=92=92 neighbor and copy the retransmit list = from=20 neighbors to the new =91=91master=92=92. If no new neighbor is = found=20 discard entries from retransmit list.=20 =20 It is easier to see that flooding will be lighter because only one=20 interface is used for retransmission and only a few interfaces will=20 be used for flooding.=20 From our example only Link-2 will be used to flood AS Scope LSA=92s.=20 Further Link-2 will be used to flood Area scope LSA=92s in Area 0 &=20 Link 3 will be used to flood Area Scope LSA=92s in Area 1.=20 =20 =20 =20 =20 Expires - June 2006 [Page 5]=20 =0CInternet Draft OSPF Multi Links December = 2005=20 =20 =20 4. =0D Adjacency Switching Recommendations=20 RFC 4222 explicitly defines max concurrent DD number and advises to=20 throttle more adjacencies. Further RFC4222 prohibits terminating=20 adjacencies in the middle. This approach has a problem that whenever=20 slow interfaces come up first and makeup max dd count number faster=20 interfaces have to wait unusually long time to form adjacencies.=20 For this scenario we recommend=20 1) If a new adjacency request comes up from a neighbor which is=20 already having an adjacency with us do not apply max concurrent=20 DD criteria on it.=20 2) While building BD Description packet, keep a count of all LSA=92s=20 sizes, so that we know the total amount of bytes to be sent to=20 peer.=20 3) Whenever receive an acknowledge packet during dd formation, keep=20 a count of bytes already reached peers.=20 =20 These two count along with interface bandwidth will give us an=20 estimate of remaining time for an adjacency.=20 =20 If Remaining time for forming adjacency >> Time for new adjacency,=20 send sequence number mismatch to first adjacency and form adjacency=20 on the faster interface.=20 =20 =20 5. =0D Patents=20 A Patent has been applied for this mechanism in Peoples Republic of=20 China=92s Beijing patent office. Approval is pending.=20 =20 =20 6. =0D Formal Syntax=20 =20 The following syntax specification uses the augmented Backus-Naur=20 Form (BNF) as described in RFC-2234.=20 =20 =20 Security Considerations=20 =20 This document does not introduce any new security issues to OSPF.=20 =20 =20 References=20 =20 [RFC2328] J Moy, =91=91OSPF Version 2=92=92.=20 [RFC2740] J Moy, R Coltun, D Ferguson, =91=91OSPF for IPV6=92=92.=20 =20 =20 Expires - June 2006 [Page 6]=20 =0CInternet Draft OSPF Multi Links December = 2005=20 =20 =20 [RFC4222] G Chodhury, Ed. " Prioritized Treatment of Specific OSPF=20 Version 2 Packets and Congestion Avoidance=92=92.=20 =20 =20 Acknowledgments=20 =20 We would like to acknowledge the support and helpful comments of Mr=20 Praveen GS, Mr Anup, Mr Raghu, Mr Zhangjinagping ,Mr Fucho.and Mr=20 Prabhu G.Biradar.=20 =20 =20 Author's Addresses=20 =20 Nitin Kakkar =20 Huawei Technologies India Pvt Ltd,=20 Level-3, Leela Galleria,=20 The Leela Palace, #23 Airport Road, =20 Bangalore 560008, India=20 Phone: +91 80 5217192=20 Email: nitink@huawei.com=20 =20 KL Srini =20 Huawei Technologies India Pvt Ltd,=20 Level-3, Leela Galleria,=20 The Leela Palace, #23 Airport Road, =20 Bangalore 560008, India=20 Phone: +91 80 5217192=20 Email: kls@huawei.com=20 =20 =20 Disclaimer of Validity=20 =20 "This document and the information contained herein are provided on = =20 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE =20 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE = =20 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR = IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF =20 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED =20 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." = =20 =20 Copyright Statement =20 =20 Copyright (C) The Internet Society (2005). This document is =20 subject to the rights, licenses and restrictions contained in BCP =20 78, and except as set forth therein, the authors retain all their =20 rights.=20 =20 =20 Expires - June 2006 [Page 7]=20 =0C= --Boundary_(ID_Txz+5q/O1nK5VsCiWw0T8A)-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 15 22:21:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En69x-0004PT-On for ospf-archive@megatron.ietf.org; Thu, 15 Dec 2005 22:21:29 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23882 for ; Thu, 15 Dec 2005 22:20:29 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <8.000061B5@wildebeest.ease.lsoft.com>; Thu, 15 Dec 2005 22:20:58 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93772060 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 15 Dec 2005 22:20:58 -0500 Received: from 61.144.161.55 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 15 Dec 2005 22:20:57 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRK00773MMOD0@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Dec 2005 11:20:48 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRK006YTML0JS@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Dec 2005 11:20:48 +0800 (CST) Received: from common1 ([10.110.94.86]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IRK00MLBMZJJL@szxml01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Dec 2005 11:28:36 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <000601c601ee$db1c5870$565e6e0a@china.huawei.com> Date: Fri, 16 Dec 2005 11:14:36 +0800 Reply-To: Mailing List Sender: Mailing List From: Ashok Subject: Re: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - preservation of BDR status To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43A1F2C6.8080407@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT Hi Acee, What is saved is the running of the election algorithm, which may be expensive depending on the topology size. Why run it, if it can be avoided? I don't see any harm in keeping the BDR status of the restarting router intact (excluding the possibility of the DR failing when the restarting BDR has not yet come up). Regards, Ashok -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee Lindem Sent: Friday, December 16, 2005 6:49 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - preservation of BDR status I don't see that preserving BDR status across restarts buys you anything. If there are N routers on the broadcast or NBMA network and the restarting router is preserved, you have to form (N - 1) adjacencies. If you don't, the new BDR has to form (N - 2) adjacencies (since it is already adjacent with the DR) plus the restarting router must form 2 adjacencies. Of course, the adjacency between the new BDR and restarting router is counted twice so in both cases you form (N - 1) adjacencies on the broadcast or NBMA network. Is there something wrong with my math? Additionally, one could argue that the restarting router already has enough work to do during the graceful restart and you'd rather off-load some of the work to a new BDR (all other things considered equal). Thanks, Acee From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 15 22:31:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En6Jg-00069m-PD for ospf-archive@megatron.ietf.org; Thu, 15 Dec 2005 22:31:32 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25057 for ; Thu, 15 Dec 2005 22:30:32 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <14.000061A4@wildebeest.ease.lsoft.com>; Thu, 15 Dec 2005 22:31:01 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93772369 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 15 Dec 2005 22:31:01 -0500 Received: from 171.71.176.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 15 Dec 2005 22:31:01 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 15 Dec 2005 19:31:01 -0800 X-IronPort-AV: i="3.99,259,1131350400"; d="scan'208"; a="685278723:sNHT31605536" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jBG3Uo76013515 for ; Thu, 15 Dec 2005 19:30:59 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Dec 2005 22:29:54 -0500 Received: from [10.82.240.13] ([10.82.240.13]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Dec 2005 22:29:54 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <000601c601ee$db1c5870$565e6e0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Dec 2005 03:29:54.0647 (UTC) FILETIME=[FB4BDE70:01C601F0] Message-ID: <43A234B2.6000707@cisco.com> Date: Thu, 15 Dec 2005 22:29:54 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - preservation of BDR status To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000601c601ee$db1c5870$565e6e0a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Hi Ashok, Ashok wrote: >Hi Acee, > >What is saved is the running of the election algorithm, which may be >expensive depending on the topology size. Why run it, if it can be >avoided? > > The BDR/DR election is a simple O(N) loop dependent on the number of routers on the link >I don't see any harm in keeping the BDR status of the restarting router >intact (excluding the possibility of the DR failing when the restarting >BDR has not yet come up). > > No benefit either. Thanks, Acee >Regards, >Ashok > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee >Lindem >Sent: Friday, December 16, 2005 6:49 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: WG Consideration of >draft-holla-ospf-update-graceful-restart-00.txt - preservation of BDR >status > > > >I don't see that preserving BDR status across restarts buys >you anything. If there are N routers on the broadcast or >NBMA network and the restarting router is preserved, >you have to form (N - 1) adjacencies. If you don't, the new >BDR has to form (N - 2) adjacencies (since it is already >adjacent with the DR) plus the restarting router must form >2 adjacencies. Of course, the adjacency between the new BDR >and restarting router is counted twice so in both cases you >form (N - 1) adjacencies on the broadcast or NBMA network. >Is there something wrong with my math? > >Additionally, one could argue that the restarting router already >has enough work to do during the graceful restart and you'd >rather off-load some of the work to a new BDR (all other >things considered equal). > >Thanks, >Acee > > > From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 15 23:33:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En7HT-0004Iq-2w for ospf-archive@megatron.ietf.org; Thu, 15 Dec 2005 23:33:19 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01387 for ; Thu, 15 Dec 2005 23:32:20 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <3.000061BB@wildebeest.ease.lsoft.com>; Thu, 15 Dec 2005 23:32:46 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93777079 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 15 Dec 2005 23:32:46 -0500 Received: from 63.197.255.154 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 15 Dec 2005 23:32:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Thread-Topic: draft-holla-ospf-update-graceful-restart-00.txt - Topology Change LSAs and Helper Mode Exit Thread-Index: AcYAXDjPM5R/+cbASOKiIrjOpO7U4ABmcvsQ Message-ID: Date: Thu, 15 Dec 2005 20:32:45 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: draft-holla-ospf-update-graceful-restart-00.txt - Topology Change LSAs and Helper Mode Exit To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable Hi, > Vishwas, it would be nice if you could refresh the groups=20 > memory with your suggestion. I am new to the group and have=20 > missed out on the context and content of that discussion. The discussion is around 4 years old, however let me try and summarize. The idea is that only if the old or the new route went through the restarting router and it changed from/ to the restarting router. Only in such cases would we need to exit hitless restart. The above will cover all cases of refresh LSA's etc. The exit from hitless restart should be based on the change in the routing table and not just LSA matching. Here is the link for details of proof:=20 http://peach.ease.lsoft.com/scripts/wa.exe?A2=3Dind0203&L=3Dospf&T=3D0&F=3D= &S=3D&P =3D1888 You could look at the thread as well as look at the previous discussion on version-00 of the draft. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Ashok Sent: Wednesday, December 14, 2005 8:37 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: draft-holla-ospf-update-graceful-restart-00.txt - Topology Change LSAs and Helper Mode Exit Hi group, The main objective of the topology change LSA definition is to achieve a balance between unbroken forwarding and restricting the scope of false GR exits. The GR mechanism overrides the basic OSPF protocol behavior. All the checks that have been put in place by OSPF are invalidated by the GR protocol. GR thus necessitates some 'faith' on part of the routers in a topology to adhere to the principle of reacting quickly to bad news.=20 By disabling strict-lsa-checking, this 'faith' is lost.=20 In several scenarios, disabling strict LSA checking will result in the overall convergence time of OSPF routers being worse with graceful restart mechanism than without it. This generally involves unstable topologies and multiple failures. Perhaps, the service providers have not had such scenarios occurring and as a result, have not asked for such changes.=20 However, the protocol must address this possibility. My concern with the existing mechanism is that taking policy decisions like disabling strict lsa checking is incorrect, since we cannot decide the significance of a topology change apriori. It could lead to extended downtimes, which would not have been the case if GR mechanism was not in place.=20 While this is true, what is equally true is that in large networks, many changes keep occurring. Links and routers toggle, policies changed and new routes learnt. This problem is amplified when there are different service providers operating in the same space. Clearly, many of these changes may be irrelevant to the neighborhood of a gracefully restarting router and must not play a part in forcing GR exit. By enabling strict-lsa-checking, this objective is undermined. Therefore I feel that there is a need to make the protocol less conservative and more intelligent, while retaining the strict-lsa-checking.=20 The exact method of achieving this is perhaps still debatable. We have suggested a method with a bias towards maintaining unbroken forwarding. Vishwas, it would be nice if you could refresh the group's memory with your suggestion. I am new to the group and have missed out on the context and content of that discussion. Regards, Ashok -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee Lindem Sent: Wednesday, December 14, 2005 10:21 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: draft-holla-ospf-update-graceful-restart-00.txt - Topology Change LSAs and Helper Mode Exit The draft proposes sub-classification of LSA changes for determining=20 whether or not a helper should terminate graceful restart. RFC 3623 currently has 2 modes: =20 1. Strict LSA Checking - Any changed LSA which would be=20 flooded to the restarting router will terminate graceful restart. 2. Changed LSAs will not terminate graceful restart (the=20 default for most vendors). The draft further classifies LSA changes as constituting a topology=20 change (in an effort to reduce the cases where graceful restart must be terminated). For=20 example, a new LSA or new link added to a router LSA would not cause GR termination. I have=20 the following concerns: 1. Are people asking for this? Most vendors default to #2. 2. New LSAs can cause the same problems as topology changes to=20 existing ones. Consider the installation of new more specific routes - the=20 characterization of new LSAs or "good" news being innocuous and "bad" news terminating=20 grace restart seems arbitrary. The draft suggests monitoring all route changes=20 involving next hops of the restarting router to avoid this problem. 3. Although my memory is weak, it seems to me that Vishwas'=20 previous proposal was more robust. If there is a requirement for some level of LSA checking but less conservative than any LSA flooded to the restarting router=20 than we should consider that one as well. Thanks, Acee =20 From owner-ospf@PEACH.EASE.LSOFT.COM Fri Dec 16 00:25:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En85j-0003Rn-W7 for ospf-archive@megatron.ietf.org; Fri, 16 Dec 2005 00:25:16 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05470 for ; Fri, 16 Dec 2005 00:24:17 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <8.000061DD@wildebeest.ease.lsoft.com>; Fri, 16 Dec 2005 0:24:44 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93780816 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Dec 2005 00:24:45 -0500 Received: from 171.71.176.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 16 Dec 2005 00:24:44 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 15 Dec 2005 21:24:44 -0800 X-IronPort-AV: i="3.99,260,1131350400"; d="scan'208"; a="685336294:sNHT68167768" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jBG5OgRC026802 for ; Thu, 15 Dec 2005 21:24:44 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Dec 2005 21:24:29 -0800 Received: from [192.168.1.67] ([10.21.146.158]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 15 Dec 2005 21:24:29 -0800 User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <000001c601ea$c13a0d20$565e6e0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Dec 2005 05:24:29.0438 (UTC) FILETIME=[FCFDB9E0:01C60200] Message-ID: <43A24F8D.5000903@cisco.com> Date: Thu, 15 Dec 2005 21:24:29 -0800 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV to Grace LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000001c601ea$c13a0d20$565e6e0a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Ashok wrote: >Hi Acee, > >I agree that the use of an LSA to signal a one time event is different >from the nature of LSA in OSPF. At the time the draft was written, we >were unaware of the Manet proposals and the plan to bring back LLS to >augment GR mechanism. Piggybacking the exit signal on the link local >grace LSA, was our way of achieving LLS without actually employing the >ideas in the expired LLS draft. Also, the requirement that this signal >to be not stored in the database or flushed later, is a natural >consequence of the Grace LSA format and usage, and does not require any >special handling. > > I don't think that there was any agreement to bring LLS in GR but rather if such signalling was indeed needed - LLS might be a better choice. I am still not convinced about the need/utility of signalling an exit for the helper. GR is a best effort mechanism and this case will drop packets as well in a non-restart situation. Albeit, we might want to reduce the time of blackholing but I don't think this is the way to go When a helper exits - all its neighbors are aware of its exit and are going to route around it. If it cannot help anymore then the premise of having cooperating routers is broken anyway. Padma >If LLS is going to be brought back from the dead, then perhaps the LLS >method needs discussion on its merit for signaling helper exit. I do >have some reservations on using LLS in hello packets to achieve such >signaling. The purpose of Hello packets is different and on broadcast >networks, it just becomes messy. > >I am completely against using 1-way in hello packets to signal exit of >Helper mode. The meaning of 1-way is defined by the Ospf protocol. It is >incorrect to add any implied meaning to it. If the Helper is already in >state 2-way or above with the Nbr, then forcefully going to 1-way is >completely wrong. The handling of exit signal is upto the restarting >router. >It may or may not tear down the adjacency (in what ever state it may be) >with the helper router. The purpose is merely to flush grace lsas. This >was the intention of the exit-grace tlv. Sending 1-way in hello has >other undesired consequences due to its primary meaning as defined by >2328. > >Regards, >Ashok > > > > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee >Lindem >Sent: Friday, December 16, 2005 6:30 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: WG Consideration of >draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV >to Grace LSA > > > >I'm totally against this extension for the following reasons. > > 1. It introduces a totally new flooding scope for LSAs. In this >context, they are > scoped only to the restarting neighbor. > 2. It changes the semantics of the LSA from a persistent >advertisement to a > one-shot signal. The draft proposed that the LSA is not stored in > >the link > state database and need not be purged (it simply ceases to exist >once > it is ack'ed). > >IMHO, this changes the semantics of the grace LSA (and LSAs in general) >too drastically. To make an analogy, it is like using your level to >pound >in a nail. It can be made to work but you may find out that you've >broken >your level. > > >If we do agree there is a requirement for a potential helper router to >signal >that graceful restart isn't inappropriate or the helper just isn't >feeling all that >generous, then we should use one of the following mechanisms: > > 1. Link Local Signaling (LLS) > 2. One-Way Hello > >I reject the supposition that this must wait until the next hello >interval. A unicast >hello is much better suited to one-shot signaling than a LSA. If you >want to >make it reliable, you simply continue to signal until the restarting >router >terminates GR. > >Thanks, >Acee > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Dec 16 00:31:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En8BY-00053Q-Gc for ospf-archive@megatron.ietf.org; Fri, 16 Dec 2005 00:31:16 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05846 for ; Fri, 16 Dec 2005 00:30:16 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <9.000061D6@wildebeest.ease.lsoft.com>; Fri, 16 Dec 2005 0:30:44 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93781109 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Dec 2005 00:30:44 -0500 Received: from 63.197.255.154 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 16 Dec 2005 00:30:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Thread-Topic: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV to Grace LSA Thread-Index: AcYCAQfUFkzKOwtAQfu5SswMKzdjhwAAUBbA Message-ID: Date: Thu, 15 Dec 2005 21:30:42 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV to Grace LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable Hi, > When a helper exits - all its neighbors are aware of its exit and > are going to route around it. > If it cannot help anymore then the premise of having cooperating=20 > routers is broken anyway. I agree totally with Padma. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Padma Pillay-Esnault Sent: Friday, December 16, 2005 10:54 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV to Grace LSA Ashok wrote: >Hi Acee,=20 > >I agree that the use of an LSA to signal a one time event is different >from the nature of LSA in OSPF. At the time the draft was written, we >were unaware of the Manet proposals and the plan to bring back LLS to >augment GR mechanism. Piggybacking the exit signal on the link local >grace LSA, was our way of achieving LLS without actually employing the >ideas in the expired LLS draft. Also, the requirement that this signal >to be not stored in the database or flushed later, is a natural >consequence of the Grace LSA format and usage, and does not require any >special handling. > =20 > I don't think that there was any agreement to bring LLS in GR but rather if such signalling was indeed needed - LLS might be a better choice. I am still not=20 convinced about the need/utility of signalling an exit for the helper. GR is a best effort mechanism and this case will drop packets as well in a non-restart situation. Albeit, we might want to reduce the time of blackholing but I don't=20 think this is the way to go When a helper exits - all its neighbors are aware of its exit and are=20 going to route around it. If it cannot help anymore then the premise of having cooperating routers is broken anyway. Padma >If LLS is going to be brought back from the dead, then perhaps the LLS >method needs discussion on its merit for signaling helper exit. I do >have some reservations on using LLS in hello packets to achieve such >signaling. The purpose of Hello packets is different and on broadcast >networks, it just becomes messy. > >I am completely against using 1-way in hello packets to signal exit of >Helper mode. The meaning of 1-way is defined by the Ospf protocol. It is >incorrect to add any implied meaning to it. If the Helper is already in >state 2-way or above with the Nbr, then forcefully going to 1-way is >completely wrong. The handling of exit signal is upto the restarting >router. >It may or may not tear down the adjacency (in what ever state it may be) >with the helper router. The purpose is merely to flush grace lsas. This >was the intention of the exit-grace tlv. Sending 1-way in hello has >other undesired consequences due to its primary meaning as defined by >2328. > >Regards, >Ashok > =20 > > > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee >Lindem >Sent: Friday, December 16, 2005 6:30 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: WG Consideration of >draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV >to Grace LSA > > > >I'm totally against this extension for the following reasons. > > 1. It introduces a totally new flooding scope for LSAs. In this=20 >context, they are > scoped only to the restarting neighbor. > 2. It changes the semantics of the LSA from a persistent=20 >advertisement to a > one-shot signal. The draft proposed that the LSA is not stored in > >the link > state database and need not be purged (it simply ceases to exist >once > it is ack'ed). > >IMHO, this changes the semantics of the grace LSA (and LSAs in general) >too drastically. To make an analogy, it is like using your level to >pound >in a nail. It can be made to work but you may find out that you've >broken >your level. > > >If we do agree there is a requirement for a potential helper router to=20 >signal >that graceful restart isn't inappropriate or the helper just isn't=20 >feeling all that >generous, then we should use one of the following mechanisms: > > 1. Link Local Signaling (LLS) > 2. One-Way Hello > >I reject the supposition that this must wait until the next hello=20 >interval. A unicast >hello is much better suited to one-shot signaling than a LSA. If you=20 >want to >make it reliable, you simply continue to signal until the restarting >router >terminates GR. > >Thanks, >Acee > > =20 > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Dec 16 00:55:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En8Ym-0003XE-OS for ospf-archive@megatron.ietf.org; Fri, 16 Dec 2005 00:55:17 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07275 for ; Fri, 16 Dec 2005 00:54:17 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <5.000061E5@wildebeest.ease.lsoft.com>; Fri, 16 Dec 2005 0:54:44 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93782362 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Dec 2005 00:54:44 -0500 Received: from 61.144.161.55 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 16 Dec 2005 00:54:40 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRK00LAMTZZ4W@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Dec 2005 13:59:59 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRK003UFTZYRV@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Dec 2005 13:59:59 +0800 (CST) Received: from common1 ([10.110.94.86]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IRK00CX0U7R7F@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Dec 2005 14:04:40 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <000001c60205$239ad700$565e6e0a@china.huawei.com> Date: Fri, 16 Dec 2005 13:54:11 +0800 Reply-To: Mailing List Sender: Mailing List From: Ashok Subject: Re: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV to Grace LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Vishwas Manral Sent: Friday, December 16, 2005 1:31 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV to Grace LSA Hi, > When a helper exits - all its neighbors are aware of its exit and > are going to route around it. > If it cannot help anymore then the premise of having cooperating > routers is broken anyway. I agree totally with Padma. This depends on an assumption on the kind of topology. It is not the case always that there are other helpers in direct contact with the helper who has exited helper mode. In real scenarios, connectivity between routers may be maintained through other RPAs as well, with OSPF learnt route being the favored one. (I know, the implementation details bugbear :)) So, GR mechanism must ensure the quickest possible reaction to bad news. While GR is best effort, Ospf with GR must not lead to longer convergence times than Ospf without GR. Regards, Ashok Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Padma Pillay-Esnault Sent: Friday, December 16, 2005 10:54 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV to Grace LSA Ashok wrote: >Hi Acee, > >I agree that the use of an LSA to signal a one time event is different >from the nature of LSA in OSPF. At the time the draft was written, we >were unaware of the Manet proposals and the plan to bring back LLS to >augment GR mechanism. Piggybacking the exit signal on the link local >grace LSA, was our way of achieving LLS without actually employing the >ideas in the expired LLS draft. Also, the requirement that this signal >to be not stored in the database or flushed later, is a natural >consequence of the Grace LSA format and usage, and does not require any >special handling. > > I don't think that there was any agreement to bring LLS in GR but rather if such signalling was indeed needed - LLS might be a better choice. I am still not convinced about the need/utility of signalling an exit for the helper. GR is a best effort mechanism and this case will drop packets as well in a non-restart situation. Albeit, we might want to reduce the time of blackholing but I don't think this is the way to go When a helper exits - all its neighbors are aware of its exit and are going to route around it. If it cannot help anymore then the premise of having cooperating routers is broken anyway. Padma >If LLS is going to be brought back from the dead, then perhaps the LLS >method needs discussion on its merit for signaling helper exit. I do >have some reservations on using LLS in hello packets to achieve such >signaling. The purpose of Hello packets is different and on broadcast >networks, it just becomes messy. > >I am completely against using 1-way in hello packets to signal exit of >Helper mode. The meaning of 1-way is defined by the Ospf protocol. It is >incorrect to add any implied meaning to it. If the Helper is already in >state 2-way or above with the Nbr, then forcefully going to 1-way is >completely wrong. The handling of exit signal is upto the restarting >router. >It may or may not tear down the adjacency (in what ever state it may be) >with the helper router. The purpose is merely to flush grace lsas. This >was the intention of the exit-grace tlv. Sending 1-way in hello has >other undesired consequences due to its primary meaning as defined by >2328. > >Regards, >Ashok > > > > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee >Lindem >Sent: Friday, December 16, 2005 6:30 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: WG Consideration of >draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV >to Grace LSA > > > >I'm totally against this extension for the following reasons. > > 1. It introduces a totally new flooding scope for LSAs. In this >context, they are > scoped only to the restarting neighbor. > 2. It changes the semantics of the LSA from a persistent >advertisement to a > one-shot signal. The draft proposed that the LSA is not stored in > >the link > state database and need not be purged (it simply ceases to exist >once > it is ack'ed). > >IMHO, this changes the semantics of the grace LSA (and LSAs in general) >too drastically. To make an analogy, it is like using your level to >pound >in a nail. It can be made to work but you may find out that you've >broken >your level. > > >If we do agree there is a requirement for a potential helper router to >signal >that graceful restart isn't inappropriate or the helper just isn't >feeling all that >generous, then we should use one of the following mechanisms: > > 1. Link Local Signaling (LLS) > 2. One-Way Hello > >I reject the supposition that this must wait until the next hello >interval. A unicast >hello is much better suited to one-shot signaling than a LSA. If you >want to >make it reliable, you simply continue to signal until the restarting >router >terminates GR. > >Thanks, >Acee > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Dec 16 01:28:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En94T-0004ts-QQ for ospf-archive@megatron.ietf.org; Fri, 16 Dec 2005 01:28:02 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09402 for ; Fri, 16 Dec 2005 01:27:02 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <1.000061D3@wildebeest.ease.lsoft.com>; Fri, 16 Dec 2005 1:27:31 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93785338 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Dec 2005 01:27:30 -0500 Received: from 61.144.161.55 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 16 Dec 2005 01:27:30 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRK00LGCVJD4W@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Dec 2005 14:33:14 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRK003ITVJB6H@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Dec 2005 14:33:13 +0800 (CST) Received: from dell60 ([10.18.4.57]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IRK00G5QVR389@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Dec 2005 14:37:52 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <005501c60209$c703bcf0$3904120a@china.huawei.com> Date: Fri, 16 Dec 2005 11:57:23 +0530 Reply-To: Mailing List Sender: Mailing List From: sujay Subject: Re: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV to Grace LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT Hi Vishwas, > When a helper exits - all its neighbors are aware of its exit and are > going to route around it. If it cannot help anymore then the premise > of having cooperating routers is broken anyway. - here all neighbors will be of aware of the helpers exit only after the Nbr dead Interval fires, Other nodes on the network until this point will use the Restarting router in its path. It also implies if the Helper has decided to exit before the Nbr interval timer fires, all it does is recalculate its route tables and sends reoriginates lsa's Using these lsa's again , other helpers may choose to exit Helper mode , subject to interpretation of 'changed lsa's'. Better still let them decide using the definition of 'topology change lsa's' . Couple with the above , send an explicit signalling from the helper to Restarting router, it removes the grace lsa from all other helpers the simplest approach in triggering a router exit helper mode. Best Regards, Sujay -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Vishwas Manral Sent: Friday, December 16, 2005 11:01 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV to Grace LSA Hi, > When a helper exits - all its neighbors are aware of its exit and are > going to route around it. If it cannot help anymore then the premise > of having cooperating routers is broken anyway. I agree totally with Padma. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Padma Pillay-Esnault Sent: Friday, December 16, 2005 10:54 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV to Grace LSA Ashok wrote: >Hi Acee, > >I agree that the use of an LSA to signal a one time event is different >from the nature of LSA in OSPF. At the time the draft was written, we >were unaware of the Manet proposals and the plan to bring back LLS to >augment GR mechanism. Piggybacking the exit signal on the link local >grace LSA, was our way of achieving LLS without actually employing the >ideas in the expired LLS draft. Also, the requirement that this signal >to be not stored in the database or flushed later, is a natural >consequence of the Grace LSA format and usage, and does not require any >special handling. > > I don't think that there was any agreement to bring LLS in GR but rather if such signalling was indeed needed - LLS might be a better choice. I am still not convinced about the need/utility of signalling an exit for the helper. GR is a best effort mechanism and this case will drop packets as well in a non-restart situation. Albeit, we might want to reduce the time of blackholing but I don't think this is the way to go When a helper exits - all its neighbors are aware of its exit and are going to route around it. If it cannot help anymore then the premise of having cooperating routers is broken anyway. Padma >If LLS is going to be brought back from the dead, then perhaps the LLS >method needs discussion on its merit for signaling helper exit. I do >have some reservations on using LLS in hello packets to achieve such >signaling. The purpose of Hello packets is different and on broadcast >networks, it just becomes messy. > >I am completely against using 1-way in hello packets to signal exit of >Helper mode. The meaning of 1-way is defined by the Ospf protocol. It is >incorrect to add any implied meaning to it. If the Helper is already in >state 2-way or above with the Nbr, then forcefully going to 1-way is >completely wrong. The handling of exit signal is upto the restarting >router. >It may or may not tear down the adjacency (in what ever state it may be) >with the helper router. The purpose is merely to flush grace lsas. This >was the intention of the exit-grace tlv. Sending 1-way in hello has >other undesired consequences due to its primary meaning as defined by >2328. > >Regards, >Ashok > > > > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee >Lindem >Sent: Friday, December 16, 2005 6:30 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: WG Consideration of >draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV >to Grace LSA > > > >I'm totally against this extension for the following reasons. > > 1. It introduces a totally new flooding scope for LSAs. In this >context, they are > scoped only to the restarting neighbor. > 2. It changes the semantics of the LSA from a persistent >advertisement to a > one-shot signal. The draft proposed that the LSA is not stored in > >the link > state database and need not be purged (it simply ceases to exist >once > it is ack'ed). > >IMHO, this changes the semantics of the grace LSA (and LSAs in general) >too drastically. To make an analogy, it is like using your level to >pound >in a nail. It can be made to work but you may find out that you've >broken >your level. > > >If we do agree there is a requirement for a potential helper router to >signal >that graceful restart isn't inappropriate or the helper just isn't >feeling all that >generous, then we should use one of the following mechanisms: > > 1. Link Local Signaling (LLS) > 2. One-Way Hello > >I reject the supposition that this must wait until the next hello >interval. A unicast >hello is much better suited to one-shot signaling than a LSA. If you >want to >make it reliable, you simply continue to signal until the restarting >router >terminates GR. > >Thanks, >Acee > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Dec 16 01:51:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En9RE-0002Ym-FO for ospf-archive@megatron.ietf.org; Fri, 16 Dec 2005 01:51:33 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10626 for ; Fri, 16 Dec 2005 01:50:32 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <1.000061D5@wildebeest.ease.lsoft.com>; Fri, 16 Dec 2005 1:51:01 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93786362 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Dec 2005 01:51:00 -0500 Received: from 61.144.161.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 16 Dec 2005 01:50:50 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRK001FUWN4TI@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Dec 2005 14:57:05 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRK00K8BWN4V2@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Dec 2005 14:57:04 +0800 (CST) Received: from Abhay1717 ([10.18.4.189]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IRK004YOWSNC0@szxml01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Dec 2005 15:00:24 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: Date: Fri, 16 Dec 2005 12:16:28 +0530 Reply-To: Mailing List Sender: Mailing List From: "Abhay D.S" Subject: Re: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV to Grace LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000001c60205$239ad700$565e6e0a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT hi Group, Amongst the various ideas (with due respect) of WG minds. I dont see John Moy much in the discussions( do you know what we have done to OSPF now ? ) :-). RFC 3623 is enough for graceful re-start mechanisms. Using Exit Grace TLV modification is useful for RFC 3623. Acee, using LLS is same as using Grace TLV with OSPF capabilities draft. Thanks, Abhay -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Ashok Sent: Friday, December 16, 2005 11:24 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV to Grace LSA -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Vishwas Manral Sent: Friday, December 16, 2005 1:31 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV to Grace LSA Hi, > When a helper exits - all its neighbors are aware of its exit and > are going to route around it. > If it cannot help anymore then the premise of having cooperating > routers is broken anyway. I agree totally with Padma. This depends on an assumption on the kind of topology. It is not the case always that there are other helpers in direct contact with the helper who has exited helper mode. In real scenarios, connectivity between routers may be maintained through other RPAs as well, with OSPF learnt route being the favored one. (I know, the implementation details bugbear :)) So, GR mechanism must ensure the quickest possible reaction to bad news. While GR is best effort, Ospf with GR must not lead to longer convergence times than Ospf without GR. Regards, Ashok Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Padma Pillay-Esnault Sent: Friday, December 16, 2005 10:54 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV to Grace LSA Ashok wrote: >Hi Acee, > >I agree that the use of an LSA to signal a one time event is different >from the nature of LSA in OSPF. At the time the draft was written, we >were unaware of the Manet proposals and the plan to bring back LLS to >augment GR mechanism. Piggybacking the exit signal on the link local >grace LSA, was our way of achieving LLS without actually employing the >ideas in the expired LLS draft. Also, the requirement that this signal >to be not stored in the database or flushed later, is a natural >consequence of the Grace LSA format and usage, and does not require any >special handling. > > I don't think that there was any agreement to bring LLS in GR but rather if such signalling was indeed needed - LLS might be a better choice. I am still not convinced about the need/utility of signalling an exit for the helper. GR is a best effort mechanism and this case will drop packets as well in a non-restart situation. Albeit, we might want to reduce the time of blackholing but I don't think this is the way to go When a helper exits - all its neighbors are aware of its exit and are going to route around it. If it cannot help anymore then the premise of having cooperating routers is broken anyway. Padma >If LLS is going to be brought back from the dead, then perhaps the LLS >method needs discussion on its merit for signaling helper exit. I do >have some reservations on using LLS in hello packets to achieve such >signaling. The purpose of Hello packets is different and on broadcast >networks, it just becomes messy. > >I am completely against using 1-way in hello packets to signal exit of >Helper mode. The meaning of 1-way is defined by the Ospf protocol. It is >incorrect to add any implied meaning to it. If the Helper is already in >state 2-way or above with the Nbr, then forcefully going to 1-way is >completely wrong. The handling of exit signal is upto the restarting >router. >It may or may not tear down the adjacency (in what ever state it may be) >with the helper router. The purpose is merely to flush grace lsas. This >was the intention of the exit-grace tlv. Sending 1-way in hello has >other undesired consequences due to its primary meaning as defined by >2328. > >Regards, >Ashok > > > > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee >Lindem >Sent: Friday, December 16, 2005 6:30 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: WG Consideration of >draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV >to Grace LSA > > > >I'm totally against this extension for the following reasons. > > 1. It introduces a totally new flooding scope for LSAs. In this >context, they are > scoped only to the restarting neighbor. > 2. It changes the semantics of the LSA from a persistent >advertisement to a > one-shot signal. The draft proposed that the LSA is not stored in > >the link > state database and need not be purged (it simply ceases to exist >once > it is ack'ed). > >IMHO, this changes the semantics of the grace LSA (and LSAs in general) >too drastically. To make an analogy, it is like using your level to >pound >in a nail. It can be made to work but you may find out that you've >broken >your level. > > >If we do agree there is a requirement for a potential helper router to >signal >that graceful restart isn't inappropriate or the helper just isn't >feeling all that >generous, then we should use one of the following mechanisms: > > 1. Link Local Signaling (LLS) > 2. One-Way Hello > >I reject the supposition that this must wait until the next hello >interval. A unicast >hello is much better suited to one-shot signaling than a LSA. If you >want to >make it reliable, you simply continue to signal until the restarting >router >terminates GR. > >Thanks, >Acee > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Dec 16 01:51:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En9RH-0002c0-TZ for ospf-archive@megatron.ietf.org; Fri, 16 Dec 2005 01:51:35 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10628 for ; Fri, 16 Dec 2005 01:50:33 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <4.000061E8@wildebeest.ease.lsoft.com>; Fri, 16 Dec 2005 1:51:05 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93786372 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Dec 2005 01:51:05 -0500 Received: from 61.144.161.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 16 Dec 2005 01:51:02 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRK001ZEWSITI@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Dec 2005 15:00:18 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRK001PEWSHSB@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Dec 2005 15:00:18 +0800 (CST) Received: from Abhay1717 ([10.18.4.189]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IRK00FH0WS9NN@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Dec 2005 15:00:10 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: Date: Fri, 16 Dec 2005 12:19:41 +0530 Reply-To: Mailing List Sender: Mailing List From: "Abhay D.S" Subject: Re: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV to Grace LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <005501c60209$c703bcf0$3904120a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT Addendum.... By the way, I dont see using non-helpers into networks in future, unless the administrator is totally crazy and want to make fun of Graceful restart. Thanks, Abhay -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of sujay Sent: Friday, December 16, 2005 11:57 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV to Grace LSA Hi Vishwas, > When a helper exits - all its neighbors are aware of its exit and are > going to route around it. If it cannot help anymore then the premise > of having cooperating routers is broken anyway. - here all neighbors will be of aware of the helpers exit only after the Nbr dead Interval fires, Other nodes on the network until this point will use the Restarting router in its path. It also implies if the Helper has decided to exit before the Nbr interval timer fires, all it does is recalculate its route tables and sends reoriginates lsa's Using these lsa's again , other helpers may choose to exit Helper mode , subject to interpretation of 'changed lsa's'. Better still let them decide using the definition of 'topology change lsa's' . Couple with the above , send an explicit signalling from the helper to Restarting router, it removes the grace lsa from all other helpers the simplest approach in triggering a router exit helper mode. Best Regards, Sujay -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Vishwas Manral Sent: Friday, December 16, 2005 11:01 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV to Grace LSA Hi, > When a helper exits - all its neighbors are aware of its exit and are > going to route around it. If it cannot help anymore then the premise > of having cooperating routers is broken anyway. I agree totally with Padma. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Padma Pillay-Esnault Sent: Friday, December 16, 2005 10:54 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV to Grace LSA Ashok wrote: >Hi Acee, > >I agree that the use of an LSA to signal a one time event is different >from the nature of LSA in OSPF. At the time the draft was written, we >were unaware of the Manet proposals and the plan to bring back LLS to >augment GR mechanism. Piggybacking the exit signal on the link local >grace LSA, was our way of achieving LLS without actually employing the >ideas in the expired LLS draft. Also, the requirement that this signal >to be not stored in the database or flushed later, is a natural >consequence of the Grace LSA format and usage, and does not require any >special handling. > > I don't think that there was any agreement to bring LLS in GR but rather if such signalling was indeed needed - LLS might be a better choice. I am still not convinced about the need/utility of signalling an exit for the helper. GR is a best effort mechanism and this case will drop packets as well in a non-restart situation. Albeit, we might want to reduce the time of blackholing but I don't think this is the way to go When a helper exits - all its neighbors are aware of its exit and are going to route around it. If it cannot help anymore then the premise of having cooperating routers is broken anyway. Padma >If LLS is going to be brought back from the dead, then perhaps the LLS >method needs discussion on its merit for signaling helper exit. I do >have some reservations on using LLS in hello packets to achieve such >signaling. The purpose of Hello packets is different and on broadcast >networks, it just becomes messy. > >I am completely against using 1-way in hello packets to signal exit of >Helper mode. The meaning of 1-way is defined by the Ospf protocol. It is >incorrect to add any implied meaning to it. If the Helper is already in >state 2-way or above with the Nbr, then forcefully going to 1-way is >completely wrong. The handling of exit signal is upto the restarting >router. >It may or may not tear down the adjacency (in what ever state it may be) >with the helper router. The purpose is merely to flush grace lsas. This >was the intention of the exit-grace tlv. Sending 1-way in hello has >other undesired consequences due to its primary meaning as defined by >2328. > >Regards, >Ashok > > > > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee >Lindem >Sent: Friday, December 16, 2005 6:30 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: WG Consideration of >draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV >to Grace LSA > > > >I'm totally against this extension for the following reasons. > > 1. It introduces a totally new flooding scope for LSAs. In this >context, they are > scoped only to the restarting neighbor. > 2. It changes the semantics of the LSA from a persistent >advertisement to a > one-shot signal. The draft proposed that the LSA is not stored in > >the link > state database and need not be purged (it simply ceases to exist >once > it is ack'ed). > >IMHO, this changes the semantics of the grace LSA (and LSAs in general) >too drastically. To make an analogy, it is like using your level to >pound >in a nail. It can be made to work but you may find out that you've >broken >your level. > > >If we do agree there is a requirement for a potential helper router to >signal >that graceful restart isn't inappropriate or the helper just isn't >feeling all that >generous, then we should use one of the following mechanisms: > > 1. Link Local Signaling (LLS) > 2. One-Way Hello > >I reject the supposition that this must wait until the next hello >interval. A unicast >hello is much better suited to one-shot signaling than a LSA. If you >want to >make it reliable, you simply continue to signal until the restarting >router >terminates GR. > >Thanks, >Acee > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Dec 16 11:48:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnIkd-00070a-TM for ospf-archive@megatron.ietf.org; Fri, 16 Dec 2005 11:48:11 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13717 for ; Fri, 16 Dec 2005 11:47:12 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <1.000062FE@wildebeest.ease.lsoft.com>; Fri, 16 Dec 2005 11:47:39 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93830254 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Dec 2005 11:47:39 -0500 Received: from 171.68.10.86 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 16 Dec 2005 11:45:45 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 16 Dec 2005 08:44:43 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jBGGi57W025276 for ; Fri, 16 Dec 2005 08:44:41 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Dec 2005 08:44:40 -0800 Received: from [192.168.1.67] ([10.21.82.55]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Dec 2005 08:44:39 -0800 User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <005501c60209$c703bcf0$3904120a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Dec 2005 16:44:39.0579 (UTC) FILETIME=[01BB0EB0:01C60260] Message-ID: <43A2EEF7.5050004@cisco.com> Date: Fri, 16 Dec 2005 08:44:39 -0800 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV to Grace LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <005501c60209$c703bcf0$3904120a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit sujay wrote: >Hi Vishwas, > > > >>When a helper exits - all its neighbors are aware of its exit and are >>going to route around it. If it cannot help anymore then the premise >>of having cooperating routers is broken anyway. >> >> > >- here all neighbors will be of aware of the helpers exit only after the >Nbr dead >Interval fires, > > and how is that different in normal case OSPF ? >Other nodes on the network until this point will use the Restarting >router >in its path. > > same in a normal ospf situation >It also implies if the Helper has decided to exit before the Nbr >interval timer >fires, all it does is recalculate its route tables and sends >reoriginates lsa's >Using these lsa's again , other helpers may choose to exit Helper mode , >subject >to interpretation of 'changed lsa's'. > > > other helpers maintain the restarting nbr up - it doesn't mean they are not running spf and will reroute according to changes. >Better still let them decide using the definition of 'topology change >lsa's' . > >Couple with the above , send an explicit signalling from the helper >to Restarting router, it removes the grace lsa from all other helpers >the simplest >approach in triggering a router exit helper mode. > > > Don't agree - how about the case you have a lone helper who doesn't interfere with routing path xcept for himself or for a limited set of routers you will bring down GR for everyone else. Doesn't look optimizing to me. Padma >Best Regards, >Sujay > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >Vishwas Manral >Sent: Friday, December 16, 2005 11:01 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: WG Consideration of >draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV >to Grace LSA > > >Hi, > > > >>When a helper exits - all its neighbors are aware of its exit and are >>going to route around it. If it cannot help anymore then the premise >>of having cooperating routers is broken anyway. >> >> >I agree totally with Padma. > >Thanks, >Vishwas >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Padma >Pillay-Esnault >Sent: Friday, December 16, 2005 10:54 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: WG Consideration of >draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV >to Grace LSA > >Ashok wrote: > > > >>Hi Acee, >> >>I agree that the use of an LSA to signal a one time event is different >> >> >>from the nature of LSA in OSPF. At the time the draft was written, we > > >>were unaware of the Manet proposals and the plan to bring back LLS to >>augment GR mechanism. Piggybacking the exit signal on the link local >>grace LSA, was our way of achieving LLS without actually employing the >>ideas in the expired LLS draft. Also, the requirement that this signal >>to be not stored in the database or flushed later, is a natural >>consequence of the Grace LSA format and usage, and does not require any >>special handling. >> >> >> >> > >I don't think that there was any agreement to bring LLS in GR but rather > >if such signalling >was indeed needed - LLS might be a better choice. I am still not >convinced about the need/utility >of signalling an exit for the helper. > >GR is a best effort mechanism and this case will drop packets as well in > >a non-restart situation. >Albeit, we might want to reduce the time of blackholing but I don't >think this is the way to go > >When a helper exits - all its neighbors are aware of its exit and are >going to route around it. >If it cannot help anymore then the premise of having cooperating routers > >is broken anyway. > >Padma > > > >>If LLS is going to be brought back from the dead, then perhaps the LLS >>method needs discussion on its merit for signaling helper exit. I do >>have some reservations on using LLS in hello packets to achieve such >>signaling. The purpose of Hello packets is different and on broadcast >>networks, it just becomes messy. >> >>I am completely against using 1-way in hello packets to signal exit of >>Helper mode. The meaning of 1-way is defined by the Ospf protocol. It >> >> >is > > >>incorrect to add any implied meaning to it. If the Helper is already in >>state 2-way or above with the Nbr, then forcefully going to 1-way is >>completely wrong. The handling of exit signal is upto the restarting >>router. >>It may or may not tear down the adjacency (in what ever state it may >> >> >be) > > >>with the helper router. The purpose is merely to flush grace lsas. This >>was the intention of the exit-grace tlv. Sending 1-way in hello has >>other undesired consequences due to its primary meaning as defined by >>2328. >> >>Regards, >>Ashok >> >> >> >> >>-----Original Message----- >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee >>Lindem >>Sent: Friday, December 16, 2005 6:30 AM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: WG Consideration of >>draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV >>to Grace LSA >> >> >> >>I'm totally against this extension for the following reasons. >> >> 1. It introduces a totally new flooding scope for LSAs. In this >>context, they are >> scoped only to the restarting neighbor. >> 2. It changes the semantics of the LSA from a persistent >>advertisement to a >> one-shot signal. The draft proposed that the LSA is not stored >> >> >in > > >>the link >> state database and need not be purged (it simply ceases to exist >>once >> it is ack'ed). >> >>IMHO, this changes the semantics of the grace LSA (and LSAs in general) >>too drastically. To make an analogy, it is like using your level to >>pound >>in a nail. It can be made to work but you may find out that you've >>broken >>your level. >> >> >>If we do agree there is a requirement for a potential helper router to >>signal >>that graceful restart isn't inappropriate or the helper just isn't >>feeling all that >>generous, then we should use one of the following mechanisms: >> >> 1. Link Local Signaling (LLS) >> 2. One-Way Hello >> >>I reject the supposition that this must wait until the next hello >>interval. A unicast >>hello is much better suited to one-shot signaling than a LSA. If you >>want to >>make it reliable, you simply continue to signal until the restarting >>router >>terminates GR. >> >>Thanks, >>Acee >> >> >> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Dec 16 12:14:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnJA8-0004A6-5B for ospf-archive@megatron.ietf.org; Fri, 16 Dec 2005 12:14:36 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17052 for ; Fri, 16 Dec 2005 12:13:33 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <6.0000631A@wildebeest.ease.lsoft.com>; Fri, 16 Dec 2005 12:14:01 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93831989 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 16 Dec 2005 12:14:00 -0500 Received: from 171.71.176.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 16 Dec 2005 12:14:00 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 16 Dec 2005 09:14:00 -0800 X-IronPort-AV: i="3.99,262,1131350400"; d="scan'208"; a="685728002:sNHT34410572" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jBGHCtQw004464 for ; Fri, 16 Dec 2005 09:13:58 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Dec 2005 09:13:48 -0800 Received: from [192.168.1.67] ([10.21.82.55]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 16 Dec 2005 09:13:48 -0800 User-Agent: Mozilla Thunderbird 0.9 (Macintosh/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <000001c60205$239ad700$565e6e0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Dec 2005 17:13:48.0344 (UTC) FILETIME=[14136B80:01C60264] Message-ID: <43A2F5CB.3070500@cisco.com> Date: Fri, 16 Dec 2005 09:13:47 -0800 Reply-To: Mailing List Sender: Mailing List From: Padma Pillay-Esnault Subject: Re: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV to Grace LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000001c60205$239ad700$565e6e0a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Ashok wrote: >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >Vishwas Manral >Sent: Friday, December 16, 2005 1:31 PM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: WG Consideration of >draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV >to Grace LSA > >Hi, > > > >>When a helper exits - all its neighbors are aware of its exit and >>are going to route around it. >>If it cannot help anymore then the premise of having cooperating >>routers is broken anyway. >> >> >I agree totally with Padma. > > >This depends on an assumption on the kind of topology. It is not the >case always that there are other helpers in direct contact with the >helper who has exited helper mode. In real scenarios, connectivity >between routers may be maintained through other RPAs as well, with OSPF >learnt route being the favored one. (I know, the implementation details >bugbear :)) > > I am missing your point. In any LS protocol - the dead timer interval is going to be a factor. The other helpers in direct contact will reroute eventually after dead interval. >So, GR mechanism must ensure the quickest possible reaction to bad news. >While GR is best effort, Ospf with GR must not lead to longer >convergence times than Ospf without GR. > > You are forgetting that a premise for all this is that you have a forwarding plane that works. I don't see how you are achieving the "must" with the proposal. Padma >Regards, >Ashok > > >Thanks, >Vishwas >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Padma >Pillay-Esnault >Sent: Friday, December 16, 2005 10:54 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: WG Consideration of >draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV >to Grace LSA > >Ashok wrote: > > > >>Hi Acee, >> >>I agree that the use of an LSA to signal a one time event is different >> >> >>from the nature of LSA in OSPF. At the time the draft was written, we > > >>were unaware of the Manet proposals and the plan to bring back LLS to >>augment GR mechanism. Piggybacking the exit signal on the link local >>grace LSA, was our way of achieving LLS without actually employing the >>ideas in the expired LLS draft. Also, the requirement that this signal >>to be not stored in the database or flushed later, is a natural >>consequence of the Grace LSA format and usage, and does not require any >>special handling. >> >> >> >> > >I don't think that there was any agreement to bring LLS in GR but rather > >if such signalling >was indeed needed - LLS might be a better choice. I am still not >convinced about the need/utility >of signalling an exit for the helper. > >GR is a best effort mechanism and this case will drop packets as well in > >a non-restart situation. >Albeit, we might want to reduce the time of blackholing but I don't >think this is the way to go > >When a helper exits - all its neighbors are aware of its exit and are >going to route around it. >If it cannot help anymore then the premise of having cooperating routers > >is broken anyway. > >Padma > > > >>If LLS is going to be brought back from the dead, then perhaps the LLS >>method needs discussion on its merit for signaling helper exit. I do >>have some reservations on using LLS in hello packets to achieve such >>signaling. The purpose of Hello packets is different and on broadcast >>networks, it just becomes messy. >> >>I am completely against using 1-way in hello packets to signal exit of >>Helper mode. The meaning of 1-way is defined by the Ospf protocol. It >> >> >is > > >>incorrect to add any implied meaning to it. If the Helper is already in >>state 2-way or above with the Nbr, then forcefully going to 1-way is >>completely wrong. The handling of exit signal is upto the restarting >>router. >>It may or may not tear down the adjacency (in what ever state it may >> >> >be) > > >>with the helper router. The purpose is merely to flush grace lsas. This >>was the intention of the exit-grace tlv. Sending 1-way in hello has >>other undesired consequences due to its primary meaning as defined by >>2328. >> >>Regards, >>Ashok >> >> >> >> >>-----Original Message----- >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee >>Lindem >>Sent: Friday, December 16, 2005 6:30 AM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: WG Consideration of >>draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV >>to Grace LSA >> >> >> >>I'm totally against this extension for the following reasons. >> >> 1. It introduces a totally new flooding scope for LSAs. In this >>context, they are >> scoped only to the restarting neighbor. >> 2. It changes the semantics of the LSA from a persistent >>advertisement to a >> one-shot signal. The draft proposed that the LSA is not stored >> >> >in > > >>the link >> state database and need not be purged (it simply ceases to exist >>once >> it is ack'ed). >> >>IMHO, this changes the semantics of the grace LSA (and LSAs in general) >>too drastically. To make an analogy, it is like using your level to >>pound >>in a nail. It can be made to work but you may find out that you've >>broken >>your level. >> >> >>If we do agree there is a requirement for a potential helper router to >>signal >>that graceful restart isn't inappropriate or the helper just isn't >>feeling all that >>generous, then we should use one of the following mechanisms: >> >> 1. Link Local Signaling (LLS) >> 2. One-Way Hello >> >>I reject the supposition that this must wait until the next hello >>interval. A unicast >>hello is much better suited to one-shot signaling than a LSA. If you >>want to >>make it reliable, you simply continue to signal until the restarting >>router >>terminates GR. >> >>Thanks, >>Acee >> >> >> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Sun Dec 18 06:08:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnwP6-0002Ok-PO for ospf-archive@megatron.ietf.org; Sun, 18 Dec 2005 06:08:38 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25099 for ; Sun, 18 Dec 2005 06:07:32 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <10.0000658B@wildebeest.ease.lsoft.com>; 18 Dec 2005 6:08:00 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93982633 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 18 Dec 2005 06:07:59 -0500 Received: from 61.144.161.55 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 18 Dec 2005 06:07:54 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRO006PTXU0KI@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Sun, 18 Dec 2005 19:13:12 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRO00IX5XTZUZ@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Sun, 18 Dec 2005 19:13:11 +0800 (CST) Received: from dell60 ([10.18.4.57]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IRO00DSVY1SDM@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Sun, 18 Dec 2005 19:17:53 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <000001c603c3$38225d00$3904120a@china.huawei.com> Date: Sun, 18 Dec 2005 16:37:21 +0530 Reply-To: Mailing List Sender: Mailing List From: sujay Subject: Re: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV to Grace LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43A2EEF7.5050004@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT See Inline SUJ> -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Padma Pillay-Esnault Sent: Friday, December 16, 2005 10:15 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV to Grace LSA sujay wrote: >Hi Vishwas, > > > >>When a helper exits - all its neighbors are aware of its exit and are >>going to route around it. If it cannot help anymore then the premise >>of having cooperating routers is broken anyway. >> >> > >- here all neighbors will be of aware of the helpers exit only after >the Nbr dead Interval fires, > > and how is that different in normal case OSPF ? >Other nodes on the network until this point will use the Restarting >router in its path. > > same in a normal ospf situation >It also implies if the Helper has decided to exit before the Nbr >interval timer fires, all it does is recalculate its route tables and >sends reoriginates lsa's >Using these lsa's again , other helpers may choose to exit Helper mode , >subject >to interpretation of 'changed lsa's'. > > > other helpers maintain the restarting nbr up - it doesn't mean they are not running spf and will reroute according to changes. >Better still let them decide using the definition of 'topology change >lsa's' . > >Couple with the above , send an explicit signalling from the helper to >Restarting router, it removes the grace lsa from all other helpers the >simplest approach in triggering a router exit helper mode. > > > Don't agree - how about the case you have a lone helper who doesn't interfere with routing path xcept for himself or for a limited set of routers you will bring down GR for everyone else. Doesn't look optimizing to me. Padma SUJ> It is a better bet to make the all the helpers go down as well because some thoughts; (a) If there are other app's on the restarting router and they are using the Fwd rout entries( case , ospf soft restart on the control plane, app could be Say bgp) , how do we prevent them from using the invalid routes, without exiting GR? (b) 3623, is based on the same premise as well See section 3.2,1,(b) , *all* helpers would Exit GR as well !( Note the caveat there as well.. " Such an option will, however, increase the risk of transient routing loops and black holes." ) (c) Yet there are cases in which the helper need not exit,as rightly pointed out by Padma, these cases is best decided using the definintion of Topology change lsa's. If the helper does decide that it is a bad news(for the restaring router), the explicit signalling is used. (d) One case which comes easily to mind and cannot be handled using the implicit checks is Mentioned in Section 8 Case B from the draft. Put here for a quick reference; " Since the protocol [OSPFGR] does not provide a method for a helper router to notify the restarting router, its exit of helper mode after the adjacency formation is complete, there are possibilities of routing holes existing for a bounded period of time, grace LSA being flushed or grace period expiry. Ex: Area 0 RT1-----------------X-----------------RT2---------RT3 | Area 1 | | RT4 In the above topology RT1, X, RT2 and RT3 are all in area 0; X and RT4 are in Area 1 which is a stub area. Scenario: X having initiated GR has completed adjacency formation with helpers RT1 and RT2 and still in the process of forming adjacency with RT4. At this point, RT3 originates a new type-5 LSA. Due to the nature of the protocol, RT2 and RT1 will exit helper mode on receipt of this LSA from RT3 and X respectively. Since, X will not send this LSA to RT4, RT4 will not exit helper mode. RT1 and RT2 have no mechanism to inform X about their quitting of helper mode (since they are already full with X). Therefore, X continues with GR WITHOUT adding a route to the destination described by the new LSA, as X will not update the forwarding table during GR. This results in a routing hole being created at X. This condition will persist until X exits GR. " To summarise, Explicit signalling is a better option. >Best Regards, >Sujay > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >Vishwas Manral >Sent: Friday, December 16, 2005 11:01 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: WG Consideration of >draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV >to Grace LSA > > >Hi, > > > >>When a helper exits - all its neighbors are aware of its exit and are >>going to route around it. If it cannot help anymore then the premise >>of having cooperating routers is broken anyway. >> >> >I agree totally with Padma. > >Thanks, >Vishwas >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >Padma Pillay-Esnault >Sent: Friday, December 16, 2005 10:54 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: WG Consideration of >draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV >to Grace LSA > >Ashok wrote: > > > >>Hi Acee, >> >>I agree that the use of an LSA to signal a one time event is different >> >> >>from the nature of LSA in OSPF. At the time the draft was written, we > > >>were unaware of the Manet proposals and the plan to bring back LLS to >>augment GR mechanism. Piggybacking the exit signal on the link local >>grace LSA, was our way of achieving LLS without actually employing the >>ideas in the expired LLS draft. Also, the requirement that this signal >>to be not stored in the database or flushed later, is a natural >>consequence of the Grace LSA format and usage, and does not require >>any special handling. >> >> >> >> > >I don't think that there was any agreement to bring LLS in GR but >rather > >if such signalling >was indeed needed - LLS might be a better choice. I am still not >convinced about the need/utility >of signalling an exit for the helper. > >GR is a best effort mechanism and this case will drop packets as well >in > >a non-restart situation. >Albeit, we might want to reduce the time of blackholing but I don't >think this is the way to go > >When a helper exits - all its neighbors are aware of its exit and are >going to route around it. >If it cannot help anymore then the premise of having cooperating routers > >is broken anyway. > >Padma > > > >>If LLS is going to be brought back from the dead, then perhaps the LLS >>method needs discussion on its merit for signaling helper exit. I do >>have some reservations on using LLS in hello packets to achieve such >>signaling. The purpose of Hello packets is different and on broadcast >>networks, it just becomes messy. >> >>I am completely against using 1-way in hello packets to signal exit of >>Helper mode. The meaning of 1-way is defined by the Ospf protocol. It >> >> >is > > >>incorrect to add any implied meaning to it. If the Helper is already >>in state 2-way or above with the Nbr, then forcefully going to 1-way >>is completely wrong. The handling of exit signal is upto the >>restarting router. It may or may not tear down the adjacency (in what >>ever state it may >> >> >be) > > >>with the helper router. The purpose is merely to flush grace lsas. >>This was the intention of the exit-grace tlv. Sending 1-way in hello >>has other undesired consequences due to its primary meaning as defined >>by 2328. >> >>Regards, >>Ashok >> >> >> >> >>-----Original Message----- >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >>Acee Lindem >>Sent: Friday, December 16, 2005 6:30 AM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: WG Consideration of >>draft-holla-ospf-update-graceful-restart-00.txt - Addition of Exit TLV >>to Grace LSA >> >> >> >>I'm totally against this extension for the following reasons. >> >> 1. It introduces a totally new flooding scope for LSAs. In this >>context, they are >> scoped only to the restarting neighbor. >> 2. It changes the semantics of the LSA from a persistent >>advertisement to a >> one-shot signal. The draft proposed that the LSA is not stored >> >> >in > > >>the link >> state database and need not be purged (it simply ceases to exist >>once >> it is ack'ed). >> >>IMHO, this changes the semantics of the grace LSA (and LSAs in >>general) too drastically. To make an analogy, it is like using your >>level to pound in a nail. It can be made to work but you may find out >>that you've broken >>your level. >> >> >>If we do agree there is a requirement for a potential helper router to >>signal >>that graceful restart isn't inappropriate or the helper just isn't >>feeling all that >>generous, then we should use one of the following mechanisms: >> >> 1. Link Local Signaling (LLS) >> 2. One-Way Hello >> >>I reject the supposition that this must wait until the next hello >>interval. A unicast >>hello is much better suited to one-shot signaling than a LSA. If you >>want to >>make it reliable, you simply continue to signal until the restarting >>router >>terminates GR. >> >>Thanks, >>Acee >> >> >> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Sun Dec 18 06:41:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Enwuh-0008RK-PL for ospf-archive@megatron.ietf.org; Sun, 18 Dec 2005 06:41:15 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27902 for ; Sun, 18 Dec 2005 06:40:13 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <4.00006593@wildebeest.ease.lsoft.com>; 18 Dec 2005 6:40:44 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93984306 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 18 Dec 2005 06:40:44 -0500 Received: from 61.144.161.53 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 18 Dec 2005 06:40:44 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRO00AI3ZI6HZ@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Sun, 18 Dec 2005 19:49:18 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRO000FKZI6QU@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Sun, 18 Dec 2005 19:49:18 +0800 (CST) Received: from dell60 ([10.18.4.57]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IRO0011MZQY51@szxml01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Sun, 18 Dec 2005 19:54:36 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <000001c603c7$dd0c3da0$3904120a@china.huawei.com> Date: Sun, 18 Dec 2005 17:10:35 +0530 Reply-To: Mailing List Sender: Mailing List From: sujay Subject: Re: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - preservation of BDR status To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43A234B2.6000707@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT See Inline SUJ> -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee Lindem Sent: Friday, December 16, 2005 9:00 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - preservation of BDR status Hi Ashok, Ashok wrote: >Hi Acee, > >What is saved is the running of the election algorithm, which may be >expensive depending on the topology size. Why run it, if it can be >avoided? > > The BDR/DR election is a simple O(N) loop dependent on the number of routers on the link SUJ>Acee, Agree with the math :) , adjacencies are about (N-1), +/- 1 in Either case. It cannot be avoided. I would see the election algo as an O(N), but I were to see the system As a whole with (N-1) nodes, that makes the computation O(N*2) ! Else am I missing something? >I don't see any harm in keeping the BDR status of the restarting router >intact (excluding the possibility of the DR failing when the restarting >BDR has not yet come up). > > No benefit either. SUJ> Coming up with the BDR or the DR is not as straight process as the Algorithm, I recall this paper on "OSPF Dynamics On a Broadcast LAN" talking about The actual settling time on LAN's for DR/BDR election. By M Goyal etc. on this list itself. http://doi.ieeecomputersociety.org/10.1109/MASCOT.2005.35 Afraid I cannot put the pdf in the mailing list.Here's the Abstract-"In this paper, we analyze the behavior of OSPF's interface state machine in a broadcast LAN scenario. We derive several interesting properties of this behavior that help us estimate the number of DR elections performed and the time required as each router on the LAN settles on the DR/BDR identity. The analytical results are verified using testbed experiments." To cut the long story short there is a benefit in avoiding it. Same, Section 3.1.5 in the draft *suggests* to avoid it. Best Regards, Sujay Thanks, Acee >Regards, >Ashok > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee >Lindem >Sent: Friday, December 16, 2005 6:49 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: WG Consideration of >draft-holla-ospf-update-graceful-restart-00.txt - preservation of BDR >status > > > >I don't see that preserving BDR status across restarts buys you >anything. If there are N routers on the broadcast or NBMA network and >the restarting router is preserved, you have to form (N - 1) >adjacencies. If you don't, the new BDR has to form (N - 2) adjacencies >(since it is already adjacent with the DR) plus the restarting router >must form 2 adjacencies. Of course, the adjacency between the new BDR >and restarting router is counted twice so in both cases you >form (N - 1) adjacencies on the broadcast or NBMA network. >Is there something wrong with my math? > >Additionally, one could argue that the restarting router already has >enough work to do during the graceful restart and you'd rather off-load >some of the work to a new BDR (all other things considered equal). > >Thanks, >Acee > > > From owner-ospf@PEACH.EASE.LSOFT.COM Sun Dec 18 07:39:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Enxof-0001zC-Rm for ospf-archive@megatron.ietf.org; Sun, 18 Dec 2005 07:39:06 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04484 for ; Sun, 18 Dec 2005 07:38:03 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <9.0000658D@wildebeest.ease.lsoft.com>; 18 Dec 2005 7:38:34 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 93987573 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 18 Dec 2005 07:38:34 -0500 Received: from 171.71.176.72 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 18 Dec 2005 07:38:34 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 18 Dec 2005 04:38:33 -0800 X-IronPort-AV: i="3.99,265,1131350400"; d="scan'208"; a="380225000:sNHT34552336" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jBICcXQg026924 for ; Sun, 18 Dec 2005 04:38:33 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 18 Dec 2005 07:38:32 -0500 Received: from [10.82.241.47] ([10.82.241.47]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 18 Dec 2005 07:38:32 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <000001c603c7$dd0c3da0$3904120a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Dec 2005 12:38:32.0611 (UTC) FILETIME=[F4C20F30:01C603CF] Message-ID: <43A55847.2080106@cisco.com> Date: Sun, 18 Dec 2005 07:38:31 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - preservation of BDR status To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000001c603c7$dd0c3da0$3904120a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Hi Sujay, sujay wrote: >See Inline >SUJ> > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee >Lindem >Sent: Friday, December 16, 2005 9:00 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: WG Consideration of >draft-holla-ospf-update-graceful-restart-00.txt - preservation of BDR >status > > >Hi Ashok, > >Ashok wrote: > > > >>Hi Acee, >> >>What is saved is the running of the election algorithm, which may be >>expensive depending on the topology size. Why run it, if it can be >>avoided? >> >> >> >> >The BDR/DR election is a simple O(N) loop dependent on the number of >routers on the link > >SUJ>Acee, Agree with the math :) , adjacencies are about (N-1), +/- 1 in > >Either case. >It cannot be avoided. > >I would see the election algo as an O(N), but I were to see the system >As a whole with (N-1) nodes, that makes the computation O(N*2) ! >Else am I missing something? > > I've never seen anyone count that way :^). Anyway, if running through these the neighbor loop twice is a big consideration in your implementation, then you can include the BDR preservation. However, my experience is that it is minuscule in comparison to the other protocol processes required. > > > >>I don't see any harm in keeping the BDR status of the restarting router >> >> > > > >>intact (excluding the possibility of the DR failing when the restarting >> >> > > > >>BDR has not yet come up). >> >> >> >> >No benefit either. > > >SUJ> Coming up with the BDR or the DR is not as straight process as the >Algorithm, > >I recall this paper on "OSPF Dynamics On a Broadcast LAN" talking about >The actual settling time on LAN's for DR/BDR election. >By M Goyal etc. on this list itself. >http://doi.ieeecomputersociety.org/10.1109/MASCOT.2005.35 > >Afraid I cannot put the pdf in the mailing list.Here's the >Abstract-"In this paper, we analyze the behavior of OSPF's >interface state machine in a broadcast LAN scenario. We derive >several interesting properties of this behavior that help us >estimate the number of DR elections performed and the time >required as each router on the LAN settles on the DR/BDR identity. >The analytical results are verified using testbed experiments." > >To cut the long story short there is a benefit in avoiding it. >Same, Section 3.1.5 in the draft *suggests* to avoid it. > > If your choice is forming new adjacencies or not forming new adjacencies, then it is a no-brainer that you should avoid it. However, with graceful restart, this is not the case. Thanks, Acee >Best Regards, >Sujay > > >Thanks, >Acee > > > >>Regards, >>Ashok >> >>-----Original Message----- >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee >> >> > > > >>Lindem >>Sent: Friday, December 16, 2005 6:49 AM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: WG Consideration of >>draft-holla-ospf-update-graceful-restart-00.txt - preservation of BDR >>status >> >> >> >>I don't see that preserving BDR status across restarts buys you >>anything. If there are N routers on the broadcast or NBMA network and >>the restarting router is preserved, you have to form (N - 1) >>adjacencies. If you don't, the new BDR has to form (N - 2) adjacencies >>(since it is already adjacent with the DR) plus the restarting router >>must form 2 adjacencies. Of course, the adjacency between the new BDR >>and restarting router is counted twice so in both cases you >>form (N - 1) adjacencies on the broadcast or NBMA network. >>Is there something wrong with my math? >> >>Additionally, one could argue that the restarting router already has >>enough work to do during the graceful restart and you'd rather off-load >> >> > > > >>some of the work to a new BDR (all other things considered equal). >> >>Thanks, >>Acee >> >> >> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Dec 19 02:49:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoFlp-0008Nf-Ky for ospf-archive@megatron.ietf.org; Mon, 19 Dec 2005 02:49:21 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01429 for ; Mon, 19 Dec 2005 02:48:18 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <11.00006635@wildebeest.ease.lsoft.com>; Mon, 19 Dec 2005 2:48:49 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 94053019 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 19 Dec 2005 02:48:48 -0500 Received: from 61.144.161.55 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 19 Dec 2005 02:48:43 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRQ00CJCIY8IO@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Mon, 19 Dec 2005 15:46:56 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRQ00BFHIY75H@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Mon, 19 Dec 2005 15:46:56 +0800 (CST) Received: from dell60 ([10.18.4.57]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IRQ0042SJBUX0@szxml01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Mon, 19 Dec 2005 15:55:07 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <000001c6046f$91b97810$3904120a@china.huawei.com> Date: Mon, 19 Dec 2005 13:11:04 +0530 Reply-To: Mailing List Sender: Mailing List From: sujay Subject: Re: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - preservation of BDR status To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43A55847.2080106@cisco.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT Hi Acee, I concur with you. Albeit there may not be much of an improvement. The draft only suggests it may be avoided without any mishaps.. :) Left to the implementor to consider merit/de-merits. Best Regards, Sujay -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee Lindem Sent: Sunday, December 18, 2005 6:09 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: WG Consideration of draft-holla-ospf-update-graceful-restart-00.txt - preservation of BDR status Hi Sujay, sujay wrote: >See Inline >SUJ> > >-----Original Message----- >From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Acee >Lindem >Sent: Friday, December 16, 2005 9:00 AM >To: OSPF@PEACH.EASE.LSOFT.COM >Subject: Re: WG Consideration of >draft-holla-ospf-update-graceful-restart-00.txt - preservation of BDR >status > > >Hi Ashok, > >Ashok wrote: > > > >>Hi Acee, >> >>What is saved is the running of the election algorithm, which may be >>expensive depending on the topology size. Why run it, if it can be >>avoided? >> >> >> >> >The BDR/DR election is a simple O(N) loop dependent on the number of >routers on the link > >SUJ>Acee, Agree with the math :) , adjacencies are about (N-1), +/- 1 >SUJ>in > >Either case. >It cannot be avoided. > >I would see the election algo as an O(N), but I were to see the system >As a whole with (N-1) nodes, that makes the computation O(N*2) ! >Else am I missing something? > > I've never seen anyone count that way :^). Anyway, if running through these the neighbor loop twice is a big consideration in your implementation, then you can include the BDR preservation. However, my experience is that it is minuscule in comparison to the other protocol processes required. > > > >>I don't see any harm in keeping the BDR status of the restarting >>router >> >> > > > >>intact (excluding the possibility of the DR failing when the >>restarting >> >> > > > >>BDR has not yet come up). >> >> >> >> >No benefit either. > > >SUJ> Coming up with the BDR or the DR is not as straight process as the >Algorithm, > >I recall this paper on "OSPF Dynamics On a Broadcast LAN" talking about >The actual settling time on LAN's for DR/BDR election. By M Goyal etc. >on this list itself. >http://doi.ieeecomputersociety.org/10.1109/MASCOT.2005.35 > >Afraid I cannot put the pdf in the mailing list.Here's the Abstract-"In >this paper, we analyze the behavior of OSPF's interface state machine >in a broadcast LAN scenario. We derive several interesting properties >of this behavior that help us estimate the number of DR elections >performed and the time required as each router on the LAN settles on >the DR/BDR identity. The analytical results are verified using testbed >experiments." > >To cut the long story short there is a benefit in avoiding it. Same, >Section 3.1.5 in the draft *suggests* to avoid it. > > If your choice is forming new adjacencies or not forming new adjacencies, then it is a no-brainer that you should avoid it. However, with graceful restart, this is not the case. Thanks, Acee >Best Regards, >Sujay > > >Thanks, >Acee > > > >>Regards, >>Ashok >> >>-----Original Message----- >>From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >>Acee >> >> > > > >>Lindem >>Sent: Friday, December 16, 2005 6:49 AM >>To: OSPF@PEACH.EASE.LSOFT.COM >>Subject: WG Consideration of >>draft-holla-ospf-update-graceful-restart-00.txt - preservation of BDR >>status >> >> >> >>I don't see that preserving BDR status across restarts buys you >>anything. If there are N routers on the broadcast or NBMA network and >>the restarting router is preserved, you have to form (N - 1) >>adjacencies. If you don't, the new BDR has to form (N - 2) adjacencies >>(since it is already adjacent with the DR) plus the restarting router >>must form 2 adjacencies. Of course, the adjacency between the new BDR >>and restarting router is counted twice so in both cases you >>form (N - 1) adjacencies on the broadcast or NBMA network. >>Is there something wrong with my math? >> >>Additionally, one could argue that the restarting router already has >>enough work to do during the graceful restart and you'd rather off-load >> >> > > > >>some of the work to a new BDR (all other things considered equal). >> >>Thanks, >>Acee >> >> >> >> >> > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Dec 19 13:20:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoPY1-00019i-1e for ospf-archive@megatron.ietf.org; Mon, 19 Dec 2005 13:15:45 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21960 for ; Mon, 19 Dec 2005 13:14:40 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <8.0000684B@wildebeest.ease.lsoft.com>; Mon, 19 Dec 2005 13:15:08 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 94118203 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 19 Dec 2005 13:15:08 -0500 Received: from 209.119.1.41 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 19 Dec 2005 13:15:08 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by LIME.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.0001BA31@LIME.ease.lsoft.com>; Mon, 19 Dec 2005 13:14:33 -0500 Message-ID: Date: Mon, 19 Dec 2005 13:15:01 -0500 Reply-To: Mailing List Sender: Mailing List From: OSPF vishnuvardhan B Subject: Re: Mapping between routerlsa and intra-area prefix lsa To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Hi All, Have a query on rfc 2740. The rfc says that ospfv3 router-lsa still carries the info about the links on the router but the addressing info is present in intra-area prefix Lsa. I am not able to understand how can i get the corresponding prefix for the link in the router-lsa from the intra-area prefix lsa. This means i am not able to map(there is not one -to-one map) regarding link info from the router-lsa to the addressing info in intra- area prefix LSA. Because the intra-area prefix Lsa carries all the prefixes configured in the router.I feel its necessary to have mapping since while computing the spf i.e while adding the candidate vertices from the router-lsa i need to know the prefixes configured on the corresponding link. Thanks&Regards, Vishnu From owner-ospf@PEACH.EASE.LSOFT.COM Mon Dec 19 16:05:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoSBu-00053a-9f for ospf-archive@megatron.ietf.org; Mon, 19 Dec 2005 16:05:06 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12722 for ; Mon, 19 Dec 2005 16:04:02 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <6.00006904@wildebeest.ease.lsoft.com>; Mon, 19 Dec 2005 16:04:35 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 94130149 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 19 Dec 2005 16:04:34 -0500 Received: from 171.71.176.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 19 Dec 2005 16:04:34 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 19 Dec 2005 13:04:34 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jBJL3f7c007052 for ; Mon, 19 Dec 2005 13:04:31 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Dec 2005 16:04:24 -0500 Received: from [10.82.241.47] ([10.82.241.47]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Dec 2005 16:04:24 -0500 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Dec 2005 21:04:24.0405 (UTC) FILETIME=[CA400850:01C604DF] Message-ID: <43A72057.2020305@cisco.com> Date: Mon, 19 Dec 2005 16:04:23 -0500 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Mapping between routerlsa and intra-area prefix lsa To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit OSPF vishnuvardhan B wrote: >Hi All, >Have a query on rfc 2740. The rfc says that ospfv3 router-lsa still >carries >the info about the links on the router but the addressing info is present >in >intra-area prefix Lsa. I am not able to understand how can i get the >corresponding prefix for the link in the router-lsa from the intra-area >prefix lsa. This means i am not able to map(there is not one -to-one map) >regarding link info from the router-lsa to the addressing info in intra- >area >prefix LSA. Because the intra-area prefix Lsa carries all the prefixes >configured in the router.I feel its necessary to have mapping since while >computing the spf i.e while adding the candidate vertices from the >router-lsa i need to know the prefixes configured on the corresponding >link. >Thanks&Regards, >Vishnu > > Hi Vishnu, Why do you think you need this? There are basically 3 cases: 1. Associated vertex is not directly connected - Doesn't matter 2. Associated vertex is connected directly and corresponds to a network LSA. Assume all prefixes advertised by the DR in the intra-area prefix LSA are on-link. 3. Associated vertex is connected directly and corresponds ot a router LSA. In this case, the assumption is that the connecting network is not multi-access and you go through the advertising router to get to those prefixes. Hope this helps, Acee From owner-ospf@PEACH.EASE.LSOFT.COM Tue Dec 20 01:09:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eoah6-0000dj-1V for ospf-archive@megatron.ietf.org; Tue, 20 Dec 2005 01:09:52 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14988 for ; Tue, 20 Dec 2005 01:08:49 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <10.00006A9B@wildebeest.ease.lsoft.com>; Tue, 20 Dec 2005 1:09:20 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 94172791 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 20 Dec 2005 01:09:20 -0500 Received: from 61.144.161.53 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 20 Dec 2005 01:09:15 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRS00HGX92O0F@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 20 Dec 2005 14:08:48 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRS00LYB92OMD@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 20 Dec 2005 14:08:48 +0800 (CST) Received: from Nitink20745 ([10.18.4.177]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IRS0060B9BILJ@szxml01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Tue, 20 Dec 2005 14:14:08 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <000001c6052a$9f3da360$b104120a@china.huawei.com> Date: Tue, 20 Dec 2005 11:30:02 +0530 Reply-To: Mailing List Sender: Mailing List From: Nitin Kakkar Subject: Re: Mapping between routerlsa and intra-area prefix lsa To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT Vishnu, For route calculation you need to know (exitIf, NextHop) Pair for a prefix. After Ist stage of route calculation you would have built SPF tree which would tell indicated (ExitIf, Nexthop) for every router (for Directly connected routers lookup Link LSa's, non directly connected just borrow this pair sec 16.1), Now lookup IntraPrefix LSA extract prefixes and get (Nexthop, ExitIf) from the router which originated this LSA. So there is no need for mapping of prefixes and anything advertised in router LSA. HTH Nitin -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of OSPF vishnuvardhan B Sent: Monday, December 19, 2005 11:45 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Mapping between routerlsa and intra-area prefix lsa Hi All, Have a query on rfc 2740. The rfc says that ospfv3 router-lsa still carries the info about the links on the router but the addressing info is present in intra-area prefix Lsa. I am not able to understand how can i get the corresponding prefix for the link in the router-lsa from the intra-area prefix lsa. This means i am not able to map(there is not one -to-one map) regarding link info from the router-lsa to the addressing info in intra- area prefix LSA. Because the intra-area prefix Lsa carries all the prefixes configured in the router.I feel its necessary to have mapping since while computing the spf i.e while adding the candidate vertices from the router-lsa i need to know the prefixes configured on the corresponding link. Thanks&Regards, Vishnu From owner-ospf*ospf-archive**LISTS*-IETF*-ORG@PEACH.EASE.LSOFT.COM Tue Dec 20 17:49:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoqI9-00008q-Bf for ospf-archive@megatron.ietf.org; Tue, 20 Dec 2005 17:49:09 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10995 for ; Tue, 20 Dec 2005 17:48:06 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <10.00006C3D@wildebeest.ease.lsoft.com>; Tue, 20 Dec 2005 17:48:36 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 94247151 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 20 Dec 2005 17:48:35 -0500 Received: from 207.69.195.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 20 Dec 2005 17:48:35 -0500 Received: from h-68-164-92-107.snvacaid.dynamic.covad.net ([68.164.92.107] helo=earthlink.net) by pop-siberian.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1EoqHb-0006ZB-00 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 20 Dec 2005 17:48:35 -0500 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <006b01c5f0c5$02ab2000$72646e0a@china.huawei.com> <20051124.162840.128462062.yasu@sfc.wide.ad.jp> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43A88D9D.94F7E644@earthlink.net> Date: Tue, 20 Dec 2005 15:02:53 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: About OSPF route flapping To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Yasu, I think I read this paper before and wanted to ask you and the group a few questions. Why are you suggesting black-holing routes and not suggesting a SIMPLER approach? My suggested simpler approach is #4. 0) Are't you effectively black-holing the route and the routers behind the "flapping link"? 1) If a link, route is flapping and it is a low traveled data link (almost a demand circuit) what is the harm if the link is periodicly down for short periods of time? 2) If the link is unstable because it is a "wireless" type link with large packet losses, won't you effectively isolate the wireless links if their are no alternative routes? 3) If the link has random periods of instability isn't your dampening increasing the period that the link CAN'T be used? 3b) If the link has become stable after a period of unstability, won't you have an extended period of down time? Maybe an upcoming Informational RFC if I FIND the time.. 4) WHY don't you just increment the cost of the link during periods of instability? Maybe, a demand type link that doesn't have to be up 100% of the time. Yes, you have to increment the cost as the time of instability increases or assume an initial level of instability and as the link ages, decrease the link cost. * Shouldn't this minimize any effects and supply as much activeness as possible? * As a followup, if hellos are lost and no data is pending to be sent out (must be implimented on all sides of the link), delay dropping the adj. I am assuming that the period of hellos could be too short for short periods of high levels of traffic. * Followup, if just a few LSAs have been sent out this questionable link and no hellos or acks have been returned, identify whether their are any alternatives for the queued pkts. If their is drop the link, else delay dropping the link? Thus, did BGP do the right thing? It is difficult to make a quick decision because TCP will rexmit lost or non acked pkts/segments within time. And TCP will force an initial handshake before data can be sent. Plus we are on a OSPF mail alias! Mitchell Erblich --------------------------- Yasuhiro Ohara wrote: > > We once checked the relation between link flapping and > OSPF fixed timer. In the paper we solved that by applying > dampening function similar with BGP's. > > http://www.sfc.wide.ad.jp/~yasu/saint2003.pdf > > The experiment was done by Zebra ospf6d. > Unfortunately I removed the dampening code since then, > because there seemed no interest. > > Let me know if you want further info. > > regards, > yasu > > From: Kouzengjie > Subject: About OSPF route flapping > Date: Thu, 24 Nov 2005 15:02:18 +0800 > > > hi,all > > How does OSPF route flapping affect? > > Is it important? > > what is the method for solving it? > > > > thanks, > > Kou > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Dec 21 01:35:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoxZ0-0004kt-0U for ospf-archive@megatron.ietf.org; Wed, 21 Dec 2005 01:35:02 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00150 for ; Wed, 21 Dec 2005 01:33:58 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <14.00006CDD@wildebeest.ease.lsoft.com>; Wed, 21 Dec 2005 1:34:30 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 94282284 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 21 Dec 2005 01:34:30 -0500 Received: from 217.12.11.33 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 21 Dec 2005 01:34:30 -0500 Received: (qmail 750 invoked from network); 21 Dec 2005 06:34:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Received:From:To:Cc:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-MimeOLE:Thread-Index:In-Reply-To; b=PGOzTAE8FezDZwiwFzpFvS0bezZE8FiYSX42bf1pAATXaJoymromnuBgdHbq1W2teUc1IeO+8Ij0IRoyDCyA7Jfj022ajZ3gVWSZwKKWIqIAGq0kS8BGTW4ahqtM/30Mvi0RYGGO09pWE2HzfuczT3iBhHhzgfpnt2kHABcwCEQ= ; Received: from unknown (HELO pfloyd) (manav?bhatia06@202.144.106.189 with login) by smtp002.mail.ukl.yahoo.com with SMTP; 21 Dec 2005 06:34:26 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcYFt5AEveaznc5hQz61pmWPFLRxMAAMyiVw Message-ID: Date: Wed, 21 Dec 2005 12:04:25 +0530 Reply-To: Mailing List Sender: Mailing List From: Manav Bhatia Subject: Re: About OSPF route flapping Comments: cc: Erblichs To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43A88D9D.94F7E644@earthlink.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Hi Erblichs, Each time an IGP route/link changes (could be because of a flap) there are a large number of BGP routes that get affected because of this. If the number of routes that get affected is small then it isn't a problem. However, given the current Internet routing table size its likely that a change in IGP will lead to a change in a *large* number of BGP routes. Processing this and updating the FIB on the line cards, etc. can take up quite some time and it may be long enough to prevent time sensitive packets (HELLOs , etc) from being sent, which may in the worst case cause adjacencies to drop. Its not as bad as it sounds and a clever implementation will do it nicely, however my point is to emphasize that an IGP change can cause a LOT of problems when BGP is around. The above would explain, which I am sure you already understand, why a flapping link needs to be damped - or looked into. Coming back to damping scheme. One could apply a less aggressive suppression scheme to the case where no alternate route exists. In the simplest case, a more aggressive suppression could be applied if some alternate route exists. If the only penalty to a flapping link/route is an increase in the cost then this still does not solve our BGP problem. Given no other IGP route, BGP will continue using the unstable IGP route (even if its cost has increased). !> !> I think I read this paper before and wanted to ask !> you and the group a few questions. Why are you suggesting !> black-holing routes and not suggesting a SIMPLER approach? !> !> My suggested simpler approach is #4. !> !> 0) Are't you effectively black-holing the route !> and the routers behind the "flapping link"? !> !> 1) If a link, route is flapping and it is a low traveled !> data link (almost a demand circuit) what is the harm !> if the link is periodicly down for short periods of !> time? For a demand link one could configure different sets of thresholds. Such routes/links are expected to change the state somewhat more often, but should be suppressed if continuous state changes indicate instability. !> !> 2) If the link is unstable because it is a "wireless" !> type link with large packet losses, won't you !> effectively isolate the wireless links if their !> are no alternative routes? !> !> 3) If the link has random periods of instability isn't !> your dampening increasing the period that the link !> CAN'T be used? !> !> 3b) If the link has become stable after a period of !> unstability, won't you have an extended period of !> down time? I'll answer all the 3 together: Its not that a single flap will cause the link/route to be removed. The amount of instability that you are willing to accept before you damp the link/route is totally configurable. Also the amount of time you want this link/route to be suppressed is completely configurable. Thus by changing the initial set of values given to the algorithm you could have a (i) highly sensitive algorithm that quickly recognizes an unstable entity and suppresses it and keeps is suppressed for a long time (ii) a flexible algorithm that accepts a number of flaps before it decides to suppress the route/link and quickly announces it if it remains active for a little time. Lets go back to the basic question. How can one accurately predict the future stability of a link/route? The recent history of how stable the route/link has been is generally regarded as a good basis for estimating the likelihood of future stability. The criterion that is used to distinguish stable routes/links from the unstable ones is therefore based on the recent history of stability of the route/link. So, a link/route is damped only if the past history shows that its likely for the link/route to again flap in future. !> !> Maybe an upcoming Informational RFC if I FIND the time.. !> 4) WHY don't you just increment the cost of the link !> during periods of instability? Maybe, a demand !> type link that doesn't have to be up 100% of the time. !> [clipped] !> !> * As a followup, if hellos are lost and no data !> is pending to be sent out (must be implimented !> on all sides of the link), delay dropping the !> adj. I am assuming that the period of hellos !> could be too short for short periods of high !> levels of traffic. I am not sure if I understand this. !> !> * Followup, if just a few LSAs have been sent out !> this questionable link and no hellos or acks !> have been returned, identify whether their are !> any alternatives for the queued pkts. If their !> is drop the link, else delay dropping the link? I don't see a reason why you would want to delay dropping such a link. In case of BGP, all the BGP routes will get blackholed. Regards, Manav !> !> Thus, did BGP do the right thing? It is difficult to !> make a quick decision because TCP will rexmit lost or !> non acked pkts/segments within time. And TCP will force !> an initial handshake before data can be sent. Plus !> we are on a OSPF mail alias! !> !> Mitchell Erblich !> --------------------------- !> !> !> !> !> !> Yasuhiro Ohara wrote: !> > !> > We once checked the relation between link flapping and !> > OSPF fixed timer. In the paper we solved that by applying !> > dampening function similar with BGP's. !> > !> > http://www.sfc.wide.ad.jp/~yasu/saint2003.pdf !> > !> > The experiment was done by Zebra ospf6d. !> > Unfortunately I removed the dampening code since then, !> > because there seemed no interest. !> > !> > Let me know if you want further info. !> > !> > regards, !> > yasu !> > !> > From: Kouzengjie !> > Subject: About OSPF route flapping !> > Date: Thu, 24 Nov 2005 15:02:18 +0800 !> > !> > > hi,all !> > > How does OSPF route flapping affect? !> > > Is it important? !> > > what is the method for solving it? !> > > !> > > thanks, !> > > Kou !> > > ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com From owner-ospf@PEACH.EASE.LSOFT.COM Sat Dec 24 02:21:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eq3iM-0004b1-Fd for ospf-archive@megatron.ietf.org; Sat, 24 Dec 2005 02:21:16 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13608 for ; Sat, 24 Dec 2005 02:20:05 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <0.0000749A@wildebeest.ease.lsoft.com>; Sat, 24 Dec 2005 2:20:28 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 94581853 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 24 Dec 2005 02:20:28 -0500 Received: from 203.178.142.146 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 24 Dec 2005 02:20:27 -0500 Received: from localhost (p5067-ipad52hodogaya.kanagawa.ocn.ne.jp [60.45.28.67]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 7D63F4CFD2; Sat, 24 Dec 2005 16:20:23 +0900 (JST) References: <006b01c5f0c5$02ab2000$72646e0a@china.huawei.com> <20051124.162840.128462062.yasu@sfc.wide.ad.jp> <43A88D9D.94F7E644@earthlink.net> X-Mailer: Mew version 4.2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20051224.162014.07263228.yasu@sfc.wide.ad.jp> Date: Sat, 24 Dec 2005 16:20:14 +0900 Reply-To: Mailing List Sender: Mailing List From: Yasuhiro Ohara Subject: Re: About OSPF route flapping Comments: To: erblichs@EARTHLINK.NET To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <43A88D9D.94F7E644@earthlink.net> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Hi Erblichs, Here I try to respond your requests by describing my opinion beside what manav have told already. Please see inline. From: Erblichs Subject: Re: About OSPF route flapping Date: Tue, 20 Dec 2005 15:02:53 -0800 Message-ID: <43A88D9D.94F7E644@earthlink.net> erblichs> Yasu, erblichs> erblichs> I think I read this paper before and wanted to ask erblichs> you and the group a few questions. Why are you suggesting erblichs> black-holing routes and not suggesting a SIMPLER approach? We were not suggesting black-holing, we suggest to apply BGP flap dampening also to OSPF events. Black-holing in the experiment just happened because of time lag between result of OSPF computation and the actual link state, and it is regarded as a bad phenomenon. Black-holing is bad because it keep us from using alternative routes. We applied flap dampening so that there would be no black-holing. erblichs> My suggested simpler approach is #4. erblichs> erblichs> 0) Are't you effectively black-holing the route erblichs> and the routers behind the "flapping link"? Please see above. Black-holing was the bad situation resulted from the flapping route. erblichs> 1) If a link, route is flapping and it is a low traveled erblichs> data link (almost a demand circuit) what is the harm erblichs> if the link is periodicly down for short periods of erblichs> time? erblichs> erblichs> 2) If the link is unstable because it is a "wireless" erblichs> type link with large packet losses, won't you erblichs> effectively isolate the wireless links if their erblichs> are no alternative routes? As manav have told, we can configure the threshold of how unstable for the link event to be dampend, and how quickly it starts to damp. What types of link should be dampened or not is beyond the scope of the paper, but I agree that on demand circuit we would not want to dampen the link event. On wireless the dampening feature might be useful, I guess. Regardless of whether it is wireless or not, it is important if we have another alternative route to the same destination other than the flapping route. If we don't have any alternative, then the dampening should leave the link "up" against ordinary dampening method which would leave the link "down". In the paper we only investigate the case when we have a alternative route, so the dampening is made to leave the link as down. I think I don't understand what you've meant by "isolate", so please tell me if I am missing your point. erblichs> 3) If the link has random periods of instability isn't erblichs> your dampening increasing the period that the link erblichs> CAN'T be used? Hmm I don't understand 'random periods of instability' ... What model are you mentioning precisely ? If the duration of previous up/down state is short enough compared to configured threshold settings, then the dampening function will increase the period that the link can't be used. Otherwise, when the previous down duration is long enough, and when the link event just occured is up, the link would be used immediately (dampening function does not effect). erblichs> 3b) If the link has become stable after a period of erblichs> unstability, won't you have an extended period of erblichs> down time? Yes, we will have an extended period of down time just after the unstability. That is from the nature of dampening algorithm. We will leave the link as down even if the link is up until the penalty of the link decreases as time passes. erblichs> Maybe an upcoming Informational RFC if I FIND the time.. erblichs> 4) WHY don't you just increment the cost of the link erblichs> during periods of instability? Maybe, a demand erblichs> type link that doesn't have to be up 100% of the time. erblichs> erblichs> Yes, you have to increment the cost as the time of erblichs> instability increases or assume an initial level of erblichs> instability and as the link ages, decrease the link erblichs> cost. erblichs> erblichs> * Shouldn't this minimize any effects and supply erblichs> as much activeness as possible? I think increasing the link cost as the link's instability increases is not a good thing, because the OSPF cost of the link have totally different meaning in essence. The OSPF's link cost have different measure compared to instability (flapping rate), so intuitively we can't explain what does it mean to reflect flapping rate to the OSPF cost. Reflecting flapping rate to the OSPF cost will result that, say, we will use the flapping link if the flapping duration is longer than every 3 second. Actual flapping rate (or duration) that we will shift to alternative route is decided by the alternative route's total OSPF link cost. Is that making any sense ? I don't think so. The only benefit we get from manipulating OSPF cost would be in the discussion of "leave up or leave down". If we make OSPF cost as LsInfinity, it means that the link is up but almost down. Using LsInfinity is good, but about reflecting flapping rate to OSPF cost, I would disagree. erblichs> * As a followup, if hellos are lost and no data erblichs> is pending to be sent out (must be implimented erblichs> on all sides of the link), delay dropping the erblichs> adj. I am assuming that the period of hellos erblichs> could be too short for short periods of high erblichs> levels of traffic. erblichs> erblichs> * Followup, if just a few LSAs have been sent out erblichs> this questionable link and no hellos or acks erblichs> have been returned, identify whether their are erblichs> any alternatives for the queued pkts. If their erblichs> is drop the link, else delay dropping the link? Why do you consider hello events ? We should consider link up/down events or route appearing/disappearing events, not hello events. We might postpone/defer link or route events, but we will not postpone hello events. Further, how do you detect that a Hello packet has been lost ? "if hellos are lost" can be detected only by timer, and it should mean the link down event. So we don't need to consider about hello event at all. erblichs> Thus, did BGP do the right thing? It is difficult to erblichs> make a quick decision because TCP will rexmit lost or erblichs> non acked pkts/segments within time. And TCP will force erblichs> an initial handshake before data can be sent. Plus erblichs> we are on a OSPF mail alias! erblichs> erblichs> Mitchell Erblich erblichs> --------------------------- Detecting if the packet is lost is difficult, almost impossible. but BGP's flap dampening does not need to detect them. It detect only receiving update or withdrawal, and only dampening if the duration is too short or rate is too high. TCP is not involved if the BGP packet have already been processed. regards, yasu erblichs> erblichs> erblichs> erblichs> erblichs> Yasuhiro Ohara wrote: erblichs> > erblichs> > We once checked the relation between link flapping and erblichs> > OSPF fixed timer. In the paper we solved that by applying erblichs> > dampening function similar with BGP's. erblichs> > erblichs> > http://www.sfc.wide.ad.jp/~yasu/saint2003.pdf erblichs> > erblichs> > The experiment was done by Zebra ospf6d. erblichs> > Unfortunately I removed the dampening code since then, erblichs> > because there seemed no interest. erblichs> > erblichs> > Let me know if you want further info. erblichs> > erblichs> > regards, erblichs> > yasu erblichs> > erblichs> > From: Kouzengjie erblichs> > Subject: About OSPF route flapping erblichs> > Date: Thu, 24 Nov 2005 15:02:18 +0800 erblichs> > erblichs> > > hi,all erblichs> > > How does OSPF route flapping affect? erblichs> > > Is it important? erblichs> > > what is the method for solving it? erblichs> > > erblichs> > > thanks, erblichs> > > Kou erblichs> > > erblichs> From owner-ospf@PEACH.EASE.LSOFT.COM Wed Dec 28 16:00:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EriPY-0005Lh-EG for ospf-archive@megatron.ietf.org; Wed, 28 Dec 2005 16:00:40 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12312 for ; Wed, 28 Dec 2005 15:59:29 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <0.00007AF8@wildebeest.ease.lsoft.com>; Wed, 28 Dec 2005 16:00:03 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 94928629 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 28 Dec 2005 16:00:03 -0500 Received: from 132.151.6.50 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 28 Dec 2005 15:50:02 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EriFG-0002aW-E0; Wed, 28 Dec 2005 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-ID: Date: Wed, 28 Dec 2005 15:50:02 -0500 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-ospfv3-mib-10.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Management Information Base for OSPFv3 Author(s) : D. Joyal, V. Manral Filename : draft-ietf-ospf-ospfv3-mib-10.txt Pages : 67 Date : 2005-12-28 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@peach.ease.lsoft.com. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-mib-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-ospfv3-mib-10.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-10.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: <2005-12-28123215.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-ospfv3-mib-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-ospfv3-mib-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-28123215.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Dec 28 21:13:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErnIK-0003qu-HA for ospf-archive@megatron.ietf.org; Wed, 28 Dec 2005 21:13:34 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21427 for ; Wed, 28 Dec 2005 21:12:22 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <1.00007B94@wildebeest.ease.lsoft.com>; Wed, 28 Dec 2005 21:13:01 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 94946405 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 28 Dec 2005 21:12:59 -0500 Received: from 32.97.110.150 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 28 Dec 2005 21:12:58 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id jBT2CtOl032164 for ; Wed, 28 Dec 2005 21:12:55 -0500 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jBT2EiKp175946 for ; Wed, 28 Dec 2005 19:14:46 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id jBT2Cqxv010232 for ; Wed, 28 Dec 2005 19:12:52 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id jBT2CqUK010227 for ; Wed, 28 Dec 2005 19:12:52 -0700 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 7.0HF90 | November 16, 2005) at 12/28/2005 19:14:43 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=08BBFA75DF9FD3E48f9e8a93df938690918c08BBFA75DF9FD3E4" Content-Disposition: inline Message-ID: Date: Wed, 28 Dec 2005 19:14:43 -0700 Reply-To: Mailing List Sender: Mailing List From: Mike Fox Subject: Mike Fox/Raleigh/IBM is out of the office. To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: --0__=08BBFA75DF9FD3E48f9e8a93df938690918c08BBFA75DF9FD3E4 Content-type: text/plain; charset=US-ASCII I will be out of the office starting December 23, 2005 and will not return until January 9, 2006. I will respond to your message when I return. --0__=08BBFA75DF9FD3E48f9e8a93df938690918c08BBFA75DF9FD3E4 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

I will be out of the office starting December 23, 2005 and will not return until January 9, 2006.

I will respond to your message when I return. --0__=08BBFA75DF9FD3E48f9e8a93df938690918c08BBFA75DF9FD3E4-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Dec 28 21:30:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErnYL-0008Im-2E for ospf-archive@megatron.ietf.org; Wed, 28 Dec 2005 21:30:06 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22973 for ; Wed, 28 Dec 2005 21:28:55 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <11.00007BA2@wildebeest.ease.lsoft.com>; Wed, 28 Dec 2005 21:29:34 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 94947283 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 28 Dec 2005 21:29:34 -0500 Received: from 61.144.161.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 28 Dec 2005 21:28:56 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IS800JILN1WT2@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 29 Dec 2005 10:32:20 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IS8004HJN1V6G@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 29 Dec 2005 10:32:20 +0800 (CST) Received: from k49110 ([10.111.12.97]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IS800KG2N1C4P@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 29 Dec 2005 10:32:12 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: multipart/alternative; boundary="Boundary_(ID_xZ4lNTQHQlGKEe+u35z/0g)" X-Priority: 3 X-MSMail-priority: Normal Message-ID: <017201c60c1e$8f545a20$610c6f0a@china.huawei.com> Date: Thu, 29 Dec 2005 10:21:10 +0800 Reply-To: Mailing List Sender: Mailing List From: Kouzengjie Subject: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: This is a multi-part message in MIME format. --Boundary_(ID_xZ4lNTQHQlGKEe+u35z/0g) Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: base64 QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJu ZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KVGhlIGRyYWZ0IGNhbiBiZSBmb3VuZCBoZXJlOg0KaHR0 cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQta291LW9zcGYtaW1tZWRpYXRl bHktcmVwbHlpbmctaGVsbG8tMDAudHh0DQoNCiBUaGlzIG1lbW8gZG9jdW1lbnRzIGFuIGV4dGVu c2lvbiBvZiB0aGUgT1NQRiBwcm90b2NvbCB0byByZWFjaCANCiAgIKGwRXhTdGFydKGxIHN0YXRl IG1vcmUgcXVpY2tseS4gQ3VycmVudGx5LCB0aGUgT1NQRiBiZWhhdmlvciByZXF1aXJlcyANCiAg IHRoZSBIZWxsbyBQYWNrZXQgdG8gYmUgc2VudCBiZXR3ZWVuIHRoZSBuZWlnaGJvcnMgZXZlcnkg DQogICBIZWxsb0ludGVydmFsLiBUaGlzIGRvY3VtZW50IHByb3Bvc2VzIHRvIGdlbmVyYWxpemUg dGhlIHVzZSBvZiANCiAgIEltbWVkaWF0ZWx5IFJlcGx5aW5nIEhlbGxvIHdoaWNoIGNvdWxkIHJl ZHVjZSB0aGUgdGltZSByZXF1aXJlZCB0byANCiAgIHJlYWNoIHRoZSBPU1BGIKGwRXhTdGFydKGx IHN0YXRlIGFuZCAgZXhwZWRpdGUgdGhlIHJvdXRpbmcgdGFibGUgDQogICBjb252ZXJnZW5jZS4g ICA= --Boundary_(ID_xZ4lNTQHQlGKEe+u35z/0g) Content-type: text/html; charset=gb2312 Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjI4MDIiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWls YWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyANCmRpcmVjdG9yaWVzLjxCUj5U aGUgZHJhZnQgY2FuIGJlIGZvdW5kIGhlcmU6PEJSPjxBIA0KaHJlZj0iaHR0cDovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQta291LW9zcGYtaW1tZWRpYXRlbHktcmVwbHlpbmct aGVsbG8tMDAudHh0Ij5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1r b3Utb3NwZi1pbW1lZGlhdGVseS1yZXBseWluZy1oZWxsby0wMC50eHQ8L0E+PC9ESVY+DQo8RElW PjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwO1RoaXMgbWVtbyBk b2N1bWVudHMgYW4gZXh0ZW5zaW9uIG9mIHRoZSBPU1BGIHByb3RvY29sIHRvIHJlYWNoIA0KPEJS PiZuYnNwOyZuYnNwOyChsEV4U3RhcnShsSBzdGF0ZSBtb3JlIHF1aWNrbHkuIEN1cnJlbnRseSwg dGhlIE9TUEYgYmVoYXZpb3IgDQpyZXF1aXJlcyA8QlI+Jm5ic3A7Jm5ic3A7IHRoZSBIZWxsbyBQ YWNrZXQgdG8gYmUgc2VudCBiZXR3ZWVuIHRoZSBuZWlnaGJvcnMgDQpldmVyeSA8QlI+Jm5ic3A7 Jm5ic3A7IEhlbGxvSW50ZXJ2YWwuIFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgdG8gZ2VuZXJhbGl6 ZSB0aGUgDQp1c2Ugb2YgPEJSPiZuYnNwOyZuYnNwOyBJbW1lZGlhdGVseSBSZXBseWluZyBIZWxs byB3aGljaCBjb3VsZCByZWR1Y2UgdGhlIHRpbWUgDQpyZXF1aXJlZCB0byA8QlI+Jm5ic3A7Jm5i c3A7IHJlYWNoIHRoZSBPU1BGIKGwRXhTdGFydKGxIHN0YXRlIGFuZCZuYnNwOyBleHBlZGl0ZSAN CnRoZSByb3V0aW5nIHRhYmxlIDxCUj4mbmJzcDsmbmJzcDsgY29udmVyZ2VuY2UuJm5ic3A7Jm5i c3A7IDwvRElWPjwvQk9EWT48L0hUTUw+DQo= --Boundary_(ID_xZ4lNTQHQlGKEe+u35z/0g)-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 29 05:29:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Erv2c-0007m6-7D for ospf-archive@megatron.ietf.org; Thu, 29 Dec 2005 05:29:50 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02806 for ; Thu, 29 Dec 2005 05:28:39 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <4.00007C1C@wildebeest.ease.lsoft.com>; Thu, 29 Dec 2005 5:29:18 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 94970900 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 29 Dec 2005 05:29:18 -0500 Received: from 63.197.255.154 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 29 Dec 2005 05:29:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] Thread-Index: AcYMH7Z6Pi4NGNiHTvaL0yBxfi5JRAAQ3AbA Message-ID: Date: Thu, 29 Dec 2005 02:29:17 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable Hi, Why should this not happen for every change in the neighbor status when = received in a hello message?=20 Whenever the contents of the hello message change we could send the = message immediately. Is there a Minimum interval between which if we get = consecutive hello's we do not process them, just like LSA's? Thanks, Vishwas ________________________________________ From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of = Kouzengjie Sent: Thursday, December 29, 2005 7:51 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Update to OSPF Hello = procedure[draft-kou-ospf-immediately-replying-hello-00.txt] A New Internet-Draft is available from the on-line Internet-Drafts = directories. The draft can be found here: http://www.ietf.org/internet-drafts/draft-kou-ospf-immediately-replying-h= ello-00.txt =A0 =A0This memo documents an extension of the OSPF protocol to reach=20 =A0=A0 "ExStart" state more quickly. Currently, the OSPF behavior = requires=20 =A0=A0 the Hello Packet to be sent between the neighbors every=20 =A0=A0 HelloInterval. This document proposes to generalize the use of=20 =A0=A0 Immediately Replying Hello which could reduce the time required = to=20 =A0=A0 reach the OSPF "ExStart" state and=A0 expedite the routing table=20 =A0=A0 convergence.=A0=A0=20 From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 29 06:06:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErvcC-0000I3-Qq for ospf-archive@megatron.ietf.org; Thu, 29 Dec 2005 06:06:38 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07254 for ; Thu, 29 Dec 2005 06:05:25 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <8.00007C1E@wildebeest.ease.lsoft.com>; Thu, 29 Dec 2005 6:06:05 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 94975713 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 29 Dec 2005 06:06:05 -0500 Received: from 61.144.161.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 29 Dec 2005 06:05:53 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IS900DEABAHTX@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 29 Dec 2005 19:15:53 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IS90015HBAHHR@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 29 Dec 2005 19:15:53 +0800 (CST) Received: from Nitink20745 ([10.18.4.177]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IS900K9HBG23A@szxml01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 29 Dec 2005 19:19:16 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: multipart/alternative; boundary="Boundary_(ID_91uVJpfS6fWSLto1txY0HA)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <000001c60c67$b37d83b0$b104120a@china.huawei.com> Date: Thu, 29 Dec 2005 16:34:53 +0530 Reply-To: Mailing List Sender: Mailing List From: Nitin Kakkar Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <017201c60c1e$8f545a20$610c6f0a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: This is a multi-part message in MIME format. --Boundary_(ID_91uVJpfS6fWSLto1txY0HA) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Suppose there are n routers on a Link and all of them come up almost simultaneously. Seems like the routers which were fractionally faster to send hello will be picked for DR/BDR election !!! May be you can think of immediately replying to hello packet "Only when DR is already elected on the link". Rgds Nitin -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Kouzengjie Sent: Thursday, December 29, 2005 7:51 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] A New Internet-Draft is available from the on-line Internet-Drafts directories. The draft can be found here: http://www.ietf.org/internet-drafts/draft-kou-ospf-immediately-replying-hell o-00.txt This memo documents an extension of the OSPF protocol to reach "ExStart" state more quickly. Currently, the OSPF behavior requires the Hello Packet to be sent between the neighbors every HelloInterval. This document proposes to generalize the use of Immediately Replying Hello which could reduce the time required to reach the OSPF "ExStart" state and expedite the routing table convergence. --Boundary_(ID_91uVJpfS6fWSLto1txY0HA) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

Suppose there are n routers on a Link and all of them come up almost simultaneously.

Seems like the routers which were fractionally faster to send hello will be picked for DR/BDR election !!!

 

May be you can think of  immediately replying to hello packet “Only when DR is already elected on the link”.

 

Rgds

Nitin

 

-----Original Message-----
From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Kouzengjie
Sent: Thursday, December 29, 2005 7:51 AM
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt]

 

A New Internet-Draft is available from the on-line Internet-Drafts directories.
The draft can be found here:
http://www.ietf.org/internet-drafts/draft-kou-ospf-immediately-replying-hello-00.txt

 

 This memo documents an extension of the OSPF protocol to reach
   “ExStart” state more quickly. Currently, the OSPF behavior requires
   the Hello Packet to be sent between the neighbors every
   HelloInterval. This document proposes to generalize the use of
   Immediately Replying Hello which could reduce the time required to
   reach the OSPF “ExStart” state and  expedite the routing table
   convergence.  

--Boundary_(ID_91uVJpfS6fWSLto1txY0HA)-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 29 06:28:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ervx7-0005hI-V4 for ospf-archive@megatron.ietf.org; Thu, 29 Dec 2005 06:28:14 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10007 for ; Thu, 29 Dec 2005 06:27:02 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <10.00007C19@wildebeest.ease.lsoft.com>; Thu, 29 Dec 2005 6:27:42 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 94977205 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 29 Dec 2005 06:27:42 -0500 Received: from 217.12.10.135 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 29 Dec 2005 06:27:42 -0500 Received: (qmail 71968 invoked by uid 60001); 29 Dec 2005 11:27:42 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kzbnnYuQGTnRWN1+jLWsNeJd4Scmuf4CAig0hLmtYT93C60SboF98pMcBWj5Ak4Q/Y3OzNyI7iasBnZbgQ3PW9FKyUzAhbVz67SasbaMYrow4OFFO1nF1J5GNq7BqaLRZrwMKJxm8caXq7i7l0vEeqPVLvti0tDtbwe8c4vvgSw= ; Received: from [202.144.106.189] by web25401.mail.ukl.yahoo.com via HTTP; Thu, 29 Dec 2005 11:27:42 GMT MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <20051229112742.71966.qmail@web25401.mail.ukl.yahoo.com> Date: Thu, 29 Dec 2005 11:27:42 +0000 Reply-To: Mailing List Sender: Mailing List From: Manav Bhatia Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000001c60c67$b37d83b0$b104120a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 8bit So whats the harm in this? If you wanted a particular router to become the DR then you would have given it a higher priority. The fact that you havent done that implies that you dont really care which router becomes the DR. Manav --- Nitin Kakkar wrote: > Suppose there are n routers on a Link and all of them come up almost > simultaneously. > > Seems like the routers which were fractionally faster to send hello will be > picked for DR/BDR election !!! > > > > May be you can think of immediately replying to hello packet "Only when DR > is already elected on the link". > > > > Rgds > > Nitin > > > > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > Kouzengjie > Sent: Thursday, December 29, 2005 7:51 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Update to OSPF Hello > procedure[draft-kou-ospf-immediately-replying-hello-00.txt] > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > The draft can be found here: > http://www.ietf.org/internet-drafts/draft-kou-ospf-immediately-replying-hell > o-00.txt > > > > This memo documents an extension of the OSPF protocol to reach > "ExStart" state more quickly. Currently, the OSPF behavior requires > the Hello Packet to be sent between the neighbors every > HelloInterval. This document proposes to generalize the use of > Immediately Replying Hello which could reduce the time required to > reach the OSPF "ExStart" state and expedite the routing table > convergence. > > ___________________________________________________________ NEW Yahoo! Cars - sell your car and browse thousands of new and used cars online! http://uk.cars.yahoo.com/ From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 29 06:43:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErwCD-0001Pj-0o for ospf-archive@megatron.ietf.org; Thu, 29 Dec 2005 06:43:49 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12066 for ; Thu, 29 Dec 2005 06:42:37 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <13.00007C1D@wildebeest.ease.lsoft.com>; Thu, 29 Dec 2005 6:43:17 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 94977830 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 29 Dec 2005 06:43:17 -0500 Received: from 61.144.161.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 29 Dec 2005 06:43:12 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IS900DXYCWPTX@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 29 Dec 2005 19:50:50 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IS90011PCWPHR@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 29 Dec 2005 19:50:49 +0800 (CST) Received: from dell60 ([10.18.4.57]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IS9008QACWFSJ@szxml02-in.huawei.com>; Thu, 29 Dec 2005 19:50:43 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <000c01c60c6c$94f17050$3904120a@china.huawei.com> Date: Thu, 29 Dec 2005 17:09:47 +0530 Reply-To: Mailing List Sender: Mailing List From: sujay Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] Comments: cc: Vishwas Manral To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable Hi Vishwas, For all state changes detected upon reception of a hello message, is there a need to send the hello immediately ? Does it expedite any information? What is needed immediately perhaps a nbr state change and other actions. Regards, Sujay -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Vishwas Manral Sent: Thursday, December 29, 2005 3:59 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] Hi, Why should this not happen for every change in the neighbor status when received in a hello message?=20 Whenever the contents of the hello message change we could send the message immediately. Is there a Minimum interval between which if we get consecutive hello's we do not process them, just like LSA's? Thanks, Vishwas ________________________________________ From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Kouzengjie Sent: Thursday, December 29, 2005 7:51 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] A New Internet-Draft is available from the on-line Internet-Drafts directories. The draft can be found here: http://www.ietf.org/internet-drafts/draft-kou-ospf-immediately-replying- hello-00.txt =A0 =A0This memo documents an extension of the OSPF protocol to reach=20 =A0=A0 "ExStart" state more quickly. Currently, the OSPF behavior = requires=20 =A0=A0 the Hello Packet to be sent between the neighbors every=20 =A0=A0 HelloInterval. This document proposes to generalize the use of=20 =A0=A0 Immediately Replying Hello which could reduce the time required = to=20 =A0=A0 reach the OSPF "ExStart" state and=A0 expedite the routing table=20 =A0=A0 convergence.=A0=A0=20 From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 29 06:47:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErwGF-0002YU-SE for ospf-archive@megatron.ietf.org; Thu, 29 Dec 2005 06:47:59 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12577 for ; Thu, 29 Dec 2005 06:46:48 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <7.00007C1F@wildebeest.ease.lsoft.com>; Thu, 29 Dec 2005 6:47:29 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 94978005 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 29 Dec 2005 06:47:29 -0500 Received: from 63.197.255.154 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 29 Dec 2005 06:47:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] Thread-Index: AcYMbRFKnrfUFHkdRByXe9Y+AVobZgAASHAg Message-ID: Date: Thu, 29 Dec 2005 03:47:28 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable Hi Sujay, What I mean is whenever you receive any information which leads to a = change in the hello we can send the hello immediately. Of course rate limiting could be done, so that we are not overwhelming = the network with too many hellos. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of sujay Sent: Thursday, December 29, 2005 5:10 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Update to OSPF Hello = procedure[draft-kou-ospf-immediately-replying-hello-00.txt] Hi Vishwas, For all state changes detected upon reception of a hello message, is there a need to send the hello immediately ? Does it expedite any information? What is needed immediately perhaps a nbr state change and other actions. Regards, Sujay -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Vishwas Manral Sent: Thursday, December 29, 2005 3:59 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] Hi, Why should this not happen for every change in the neighbor status when received in a hello message?=20 Whenever the contents of the hello message change we could send the message immediately. Is there a Minimum interval between which if we get consecutive hello's we do not process them, just like LSA's? Thanks, Vishwas ________________________________________ From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Kouzengjie Sent: Thursday, December 29, 2005 7:51 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] A New Internet-Draft is available from the on-line Internet-Drafts directories. The draft can be found here: http://www.ietf.org/internet-drafts/draft-kou-ospf-immediately-replying- hello-00.txt =A0 =A0This memo documents an extension of the OSPF protocol to reach=20 =A0=A0 "ExStart" state more quickly. Currently, the OSPF behavior = requires=20 =A0=A0 the Hello Packet to be sent between the neighbors every=20 =A0=A0 HelloInterval. This document proposes to generalize the use of=20 =A0=A0 Immediately Replying Hello which could reduce the time required = to=20 =A0=A0 reach the OSPF "ExStart" state and=A0 expedite the routing table=20 =A0=A0 convergence.=A0=A0=20 From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 29 16:12:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es54z-0000TZ-Kn for ospf-archive@megatron.ietf.org; Thu, 29 Dec 2005 16:12:59 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18518 for ; Thu, 29 Dec 2005 16:11:46 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <11.00007D33@wildebeest.ease.lsoft.com>; Thu, 29 Dec 2005 16:12:25 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95011310 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 29 Dec 2005 16:12:24 -0500 Received: from 207.69.195.69 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 29 Dec 2005 16:12:24 -0500 Received: from h-68-164-85-155.snvacaid.dynamic.covad.net ([68.164.85.155] helo=earthlink.net) by pop-savannah.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1Es54S-00003W-00 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 29 Dec 2005 16:12:24 -0500 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <017201c60c1e$8f545a20$610c6f0a@china.huawei.com> Content-Type: text/plain; charset=iso-8859-2 Message-ID: <43B45416.4FF846D7@earthlink.net> Date: Thu, 29 Dec 2005 13:24:38 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA18518 Group, If my opinion counts for anything.. 0) The text has a number of unusal chars. 1) With a number of routers sending out hellos the moment the interfaces become active, I am not sure of this benefit.. However.. 2) If we are MC hellos, isn't a suggestion of responding with a immediate reply synch hellos. Is this a good thing? 3) On the previous assumption of MC hellos, and we have say 10 pre-nbrs, does that mean we should send out 10 hellos to each nbr? Our hellos inform each nbr about our state. Does this scale? Can we theorectly be sending out close to 90 hellos for 10 nbrs? Each nbr send out a reply to each of their 9 nbrs. If we wait for the hello interval, the nbrs fields should be filled 1 hello interval after the #1 (bring up hello) was sent with 1 hello. Isn't this a good thing? 4) With a hello interval separating hellos, we should minimize a hello storm. Isn't this a good thing? 5) Your section 3. Potential Solution. What is "Fast hello" and "intention"? 5b) Do we ping pong our hellos if our hello parameters don't match? Assuming we can generate 10k hellos per sec, should we because we are less than 2-way? This is why TCP doesn't ACK and ACK! Or are you thinking about a reply only after validation and acceptance? 6) Your section 5. Immediately replying Hello Does "to this nbr" mean UC (unicast)? 7) Your section 5. Immediately ... 3f@ After DR is elected... With no hello wait period, aren't you adding a race condition where the first router annouces the DR and the BDR. The SLOWER routers implicitly according to the spec must stop their=20 election and take the announced DR and BDR as truth in that hello. The other way validates a consensus of a DR / BDR. 8) If we ever communicate with ms hellos, your hellos can consume alot of bandwidth for routers that flap? 9, 10) etc... Overall, I think you are addiing alot of complexity and NOT allowing the hello pkt to accumalate current state before sending out the next hello. It is possible that very small incremental amounts of time are remaining via the hello interval timer. The hello interval is a minor delay that is agreed to be overshadowed by the Waiting time. ("Waiting time accounts for 80% to 90% of the total recovery time"). Thus Amdahls law tells us if we divide a problem in half and make 1/2 infinitely fast we will get at best a 2x speedup. And you are fixing less than 20% of the problem. The Waiting time before a DR / BDR election is their because: * The number of times a wait state needs to be entered should be infrequent. * It is only entered if no-one is announcing a DR / BDR, else it should be approx 1/2 hello interval time. * The wait period assumes that hellos are spread over some time period. * Even if 1 hello is lost, all nbr should be known within this time period. * The most powerful systems have the largest amount of memory and these memory validations take more time with more memory. *etc... I see alot of problems and potential problems with this suggestion.. Gasoline for the fire.... It would make SENSE at least to me, if a DR with max priority was voluntarily brought down with a group of other other-routers,=20 to bring it up announcing itself as the DR. This would remove 80 to 90% of your IGP convergence time. Mitchell Erblich --------------------- =20 > Kouzengjie wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > The draft can be found here: > http://www.ietf.org/internet-drafts/draft-kou-ospf-immediately-replying= -hello-00.txt >=20 > This memo documents an extension of the OSPF protocol to reach > =B7=B0ExStart=B7=B1 state more quickly. Currently, the OSPF behavior > requires > the Hello Packet to be sent between the neighbors every > HelloInterval. This document proposes to generalize the use of > Immediately Replying Hello which could reduce the time required to > reach the OSPF =B7=B0ExStart=B7=B1 state and expedite the routing t= able > convergence. From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 29 21:11:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es9k3-0002Sr-O3 for ospf-archive@megatron.ietf.org; Thu, 29 Dec 2005 21:11:39 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15955 for ; Thu, 29 Dec 2005 21:10:27 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <15.00007DEA@wildebeest.ease.lsoft.com>; Thu, 29 Dec 2005 21:11:08 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95026261 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 29 Dec 2005 21:11:07 -0500 Received: from 61.144.161.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 29 Dec 2005 21:11:06 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ISA006VWH0EV3@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 Dec 2005 10:17:02 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ISA0033EH0C41@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 Dec 2005 10:17:02 +0800 (CST) Received: from k49110 ([10.111.12.97]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ISA0083YH04SR@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 Dec 2005 10:16:53 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Message-ID: <003e01c60ce5$958b0d40$610c6f0a@china.huawei.com> Date: Fri, 30 Dec 2005 10:06:01 +0800 Reply-To: Mailing List Sender: Mailing List From: Zengjie Kou Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT hi,Vishwas The Immediately Hello only reduces the time to reach the "ExStart" state. It is unnecessary to use it when the state is more than "ExStart". ----- Original Message ----- From: "Vishwas Manral" To: Sent: Thursday, December 29, 2005 6:29 PM Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] Hi, Why should this not happen for every change in the neighbor status when received in a hello message? Whenever the contents of the hello message change we could send the message immediately. Is there a Minimum interval between which if we get consecutive hello's we do not process them, just like LSA's? Thanks, Vishwas ________________________________________ From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Kouzengjie Sent: Thursday, December 29, 2005 7:51 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] A New Internet-Draft is available from the on-line Internet-Drafts directories. The draft can be found here: http://www.ietf.org/internet-drafts/draft-kou-ospf-immediately-replying-hello-00.txt This memo documents an extension of the OSPF protocol to reach "ExStart" state more quickly. Currently, the OSPF behavior requires the Hello Packet to be sent between the neighbors every HelloInterval. This document proposes to generalize the use of Immediately Replying Hello which could reduce the time required to reach the OSPF "ExStart" state and expedite the routing table convergence. From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 29 21:25:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es9x5-00077R-5k for ospf-archive@megatron.ietf.org; Thu, 29 Dec 2005 21:25:07 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18291 for ; Thu, 29 Dec 2005 21:23:54 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <1.00007DE1@wildebeest.ease.lsoft.com>; Thu, 29 Dec 2005 21:24:35 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95026801 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 29 Dec 2005 21:24:35 -0500 Received: from 61.144.161.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 29 Dec 2005 21:24:33 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ISA006TSHP4V3@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 Dec 2005 10:31:52 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ISA003QDHP441@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 Dec 2005 10:31:52 +0800 (CST) Received: from k49110 ([10.111.12.97]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ISA00K27HUP36@szxml01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 Dec 2005 10:35:13 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: multipart/alternative; boundary="Boundary_(ID_c4blHY2fuE0MIHuFtCKlNw)" X-Priority: 3 X-MSMail-priority: Normal References: <000001c60c67$b37d83b0$b104120a@china.huawei.com> Message-ID: <005601c60ce7$a86cd040$610c6f0a@china.huawei.com> Date: Fri, 30 Dec 2005 10:20:52 +0800 Reply-To: Mailing List Sender: Mailing List From: Zengjie Kou Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: This is a multi-part message in MIME format. --Boundary_(ID_c4blHY2fuE0MIHuFtCKlNw) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi,Nitin Yes. On broadcast and NBMA networks, the Immediate Hello is very useful only when DR has already existed.In particular, if a router interface attached to OSPF networks goes down and then up, the recovery time will be much shorter than past. ----- Original Message ----- From: Nitin Kakkar To: OSPF@PEACH.EASE.LSOFT.COM Sent: Thursday, December 29, 2005 7:04 PM Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] Suppose there are n routers on a Link and all of them come up almost simultaneously. Seems like the routers which were fractionally faster to send hello will be picked for DR/BDR election !!! May be you can think of immediately replying to hello packet "Only when DR is already elected on the link". Rgds Nitin -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Kouzengjie Sent: Thursday, December 29, 2005 7:51 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] A New Internet-Draft is available from the on-line Internet-Drafts directories. The draft can be found here: http://www.ietf.org/internet-drafts/draft-kou-ospf-immediately-replying-hello-00.txt This memo documents an extension of the OSPF protocol to reach "ExStart" state more quickly. Currently, the OSPF behavior requires the Hello Packet to be sent between the neighbors every HelloInterval. This document proposes to generalize the use of Immediately Replying Hello which could reduce the time required to reach the OSPF "ExStart" state and expedite the routing table convergence. --Boundary_(ID_c4blHY2fuE0MIHuFtCKlNw) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjkwMC4yODAyIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT5AZm9udC1mYWNlIHsNCglm b250LWZhbWlseTogU2ltU3VuOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IFRhaG9t YTsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBAU2ltU3VuOw0KfQ0KQHBhZ2UgU2Vj dGlvbjEge3NpemU6IDguNWluIDExLjBpbjsgbWFyZ2luOiAxLjBpbiAxLjI1aW4gMS4waW4gMS4y NWluOyB9DQpQLk1zb05vcm1hbCB7DQoJRk9OVC1TSVpFOiAxMnB0OyBNQVJHSU46IDBpbiAwaW4g MHB0OyBGT05ULUZBTUlMWTogU2ltU3VuDQp9DQpMSS5Nc29Ob3JtYWwgew0KCUZPTlQtU0laRTog MTJwdDsgTUFSR0lOOiAwaW4gMGluIDBwdDsgRk9OVC1GQU1JTFk6IFNpbVN1bg0KfQ0KRElWLk1z b05vcm1hbCB7DQoJRk9OVC1TSVpFOiAxMnB0OyBNQVJHSU46IDBpbiAwaW4gMHB0OyBGT05ULUZB TUlMWTogU2ltU3VuDQp9DQpBOmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046 IHVuZGVybGluZQ0KfQ0KU1BBTi5Nc29IeXBlcmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURF Q09SQVRJT046IHVuZGVybGluZQ0KfQ0KQTp2aXNpdGVkIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1E RUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rRm9sbG93ZWQgew0KCUNP TE9SOiBibHVlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5FbWFpbFN0eWxl MTcgew0KCUNPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwNCn0NCkRJVi5TZWN0aW9uMSB7 DQoJcGFnZTogU2VjdGlvbjENCn0NCjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9EWSBsYW5nPUVOLVVT IHZMaW5rPWJsdWUgbGluaz1ibHVlIGJnQ29sb3I9d2hpdGU+DQo8RElWPg0KPERJVj48Rk9OVCBm YWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPkhpLE5pdGluPC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyA8L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFllcy48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsm IzIwMzA3OyBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsgT24gYnJv YWRjYXN0IGFuZCBOQk1BIG5ldHdvcmtzLCB0aGUgDQpJbW1lZGlhdGUgSGVsbG8gaXMgdmVyeSB1 c2VmdWwgb25seSB3aGVuIERSIGhhcyBhbHJlYWR5IGV4aXN0ZWQuSW4gDQo8QlI+Jm5ic3A7Jm5i c3A7IHBhcnRpY3VsYXIsIGlmIGEgcm91dGVyJm5ic3A7aW50ZXJmYWNlIGF0dGFjaGVkIHRvIE9T UEYgDQpuZXR3b3JrcyBnb2VzIDxCUj4mbmJzcDsmbmJzcDsgZG93biBhbmQgdGhlbiB1cCwgdGhl IHJlY292ZXJ5IHRpbWUgd2lsbCBiZSBtdWNoIA0Kc2hvcnRlciB0aGFuIHBhc3QuIDwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj48L0ZPTlQ+Jm5i c3A7PC9ESVY+PC9ESVY+DQo8QkxPQ0tRVU9URSBkaXI9bHRyIA0Kc3R5bGU9IlBBRERJTkctUklH SFQ6IDBweDsgUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZU OiAjMDAwMDAwIDJweCBzb2xpZDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICA8RElWIHN0eWxlPSJG T05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8 L0RJVj4NCiAgPERJViBzdHlsZT0iQkFDS0dST1VORDogI2U0ZTRlNDsgRk9OVDogOXB0ICYjMjM0 MzU7JiMyMDMwNzs7IGZvbnQtY29sb3I6IGJsYWNrIj48Qj5Gcm9tOjwvQj4gDQogIDxBIHRpdGxl PW5pdGlua0BodWF3ZWkuY29tIGhyZWY9Im1haWx0bzpuaXRpbmtAaHVhd2VpLmNvbSI+Tml0aW4g S2Fra2FyPC9BPiANCiAgPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYj MjAzMDc7Ij48Qj5Ubzo8L0I+IDxBIHRpdGxlPU9TUEZAUEVBQ0guRUFTRS5MU09GVC5DT00gDQog IGhyZWY9Im1haWx0bzpPU1BGQFBFQUNILkVBU0UuTFNPRlQuQ09NIj5PU1BGQFBFQUNILkVBU0Uu TFNPRlQuQ09NPC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMy MDMwNzsiPjxCPlNlbnQ6PC9CPiBUaHVyc2RheSwgRGVjZW1iZXIgMjksIDIwMDUgNzowNCANCiAg UE08L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlN1 YmplY3Q6PC9CPiBSZTogVXBkYXRlIHRvIE9TUEYgSGVsbG8gDQogIHByb2NlZHVyZVtkcmFmdC1r b3Utb3NwZi1pbW1lZGlhdGVseS1yZXBseWluZy1oZWxsby0wMC50eHRdPC9ESVY+DQogIDxESVY+ PEJSPjwvRElWPg0KICA8RElWIGNsYXNzPVNlY3Rpb24xPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+ PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+U3VwcG9zZSB0aGVy ZSBhcmUgbiANCiAgcm91dGVycyBvbiBhIExpbmsgYW5kIGFsbCBvZiB0aGVtIGNvbWUgdXAgYWxt b3N0IA0KICBzaW11bHRhbmVvdXNseS48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNv Tm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPlNlZW1z IGxpa2UgdGhlIA0KICByb3V0ZXJzIHdoaWNoIHdlcmUgZnJhY3Rpb25hbGx5IGZhc3RlciB0byBz ZW5kIGhlbGxvIHdpbGwgYmUgcGlja2VkIGZvciBEUi9CRFIgDQogIGVsZWN0aW9uICEhITwvU1BB Tj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xv cj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5h dnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L1A+DQogIDxQIGNs YXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0K ICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFs Ij5NYXkgYmUgeW91IGNhbiB0aGluayANCiAgb2YgJm5ic3A7aW1tZWRpYXRlbHkgcmVwbHlpbmcg dG8gaGVsbG8gcGFja2V0IJNPbmx5IHdoZW4gRFIgaXMgYWxyZWFkeSBlbGVjdGVkIA0KICBvbiB0 aGUgbGlua5QuPC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBm YWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj48L1NQQU4+PC9GT05UPiZuYnNw OzwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBz aXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05U LUZBTUlMWTogQXJpYWwiPlJnZHM8L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9y bWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPk5pdGluPC9T UEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNv bG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjog bmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj48L1NQQU4+PC9GT05UPiZuYnNwOzwvUD4NCiAgPFAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4tTEVGVDogMC41aW4iPjxGT05UIGZhY2U9VGFo b21hIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6 IFRhaG9tYSI+LS0tLS1PcmlnaW5hbCANCiAgTWVzc2FnZS0tLS0tPEJSPjxCPjxTUEFOIHN0eWxl PSJGT05ULVdFSUdIVDogYm9sZCI+RnJvbTo8L1NQQU4+PC9CPiBNYWlsaW5nIA0KICBMaXN0IFtt YWlsdG86T1NQRkBQRUFDSC5FQVNFLkxTT0ZULkNPTV0gPEI+PFNQQU4gc3R5bGU9IkZPTlQtV0VJ R0hUOiBib2xkIj5PbiANCiAgQmVoYWxmIE9mIDwvU1BBTj48L0I+S291emVuZ2ppZTxCUj48Qj48 U1BBTiANCiAgc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5TZW50OjwvU1BBTj48L0I+IFRodXJz ZGF5LCBEZWNlbWJlciAyOSwgMjAwNSA3OjUxIA0KICBBTTxCUj48Qj48U1BBTiBzdHlsZT0iRk9O VC1XRUlHSFQ6IGJvbGQiPlRvOjwvU1BBTj48L0I+IA0KICBPU1BGQFBFQUNILkVBU0UuTFNPRlQu Q09NPEJSPjxCPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQiPlN1YmplY3Q6PC9T UEFOPjwvQj4gVXBkYXRlIHRvIE9TUEYgSGVsbG8gDQogIHByb2NlZHVyZVtkcmFmdC1rb3Utb3Nw Zi1pbW1lZGlhdGVseS1yZXBseWluZy1oZWxsby0wMC50eHRdPC9TUEFOPjwvRk9OVD48L1A+DQog IDxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDAuNWluIj48Rk9OVCBmYWNl PVNpbVN1biBzaXplPTM+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPjwvU1BBTj48 L0ZPTlQ+Jm5ic3A7PC9QPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1B UkdJTi1MRUZUOiAwLjVpbiI+PEZPTlQgZmFjZT1TaW1TdW4gc2l6ZT0zPjxTUEFOIA0KICBzdHls ZT0iRk9OVC1TSVpFOiAxMnB0Ij5BIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJv bSB0aGUgb24tbGluZSANCiAgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLjxCUj5UaGUgZHJh ZnQgY2FuIGJlIGZvdW5kIGhlcmU6PEJSPjxBIA0KICBocmVmPSJodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1rb3Utb3NwZi1pbW1lZGlhdGVseS1yZXBseWluZy1oZWxs by0wMC50eHQiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWtvdS1v c3BmLWltbWVkaWF0ZWx5LXJlcGx5aW5nLWhlbGxvLTAwLnR4dDwvQT48L1NQQU4+PC9GT05UPjwv UD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4tTEVG VDogMC41aW4iPjxGT05UIGZhY2U9U2ltU3VuIHNpemU9Mz48U1BBTiANCiAgc3R5bGU9IkZPTlQt U0laRTogMTJwdCI+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L1A+PC9ESVY+DQogIDxESVY+DQogIDxQ IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDAuNWluIj48Rk9OVCBmYWNlPVNp bVN1biBzaXplPTM+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPiZuYnNwO1RoaXMg bWVtbyBkb2N1bWVudHMgYW4gZXh0ZW5zaW9uIG9mIHRoZSBPU1BGIA0KICBwcm90b2NvbCB0byBy ZWFjaCA8QlI+Jm5ic3A7Jm5ic3A7IJNFeFN0YXJ0lCBzdGF0ZSBtb3JlIHF1aWNrbHkuIEN1cnJl bnRseSwgDQogIHRoZSBPU1BGIGJlaGF2aW9yIHJlcXVpcmVzIDxCUj4mbmJzcDsmbmJzcDsgdGhl IEhlbGxvIFBhY2tldCB0byBiZSBzZW50IA0KICBiZXR3ZWVuIHRoZSBuZWlnaGJvcnMgZXZlcnkg PEJSPiZuYnNwOyZuYnNwOyBIZWxsb0ludGVydmFsLiBUaGlzIGRvY3VtZW50IA0KICBwcm9wb3Nl cyB0byBnZW5lcmFsaXplIHRoZSB1c2Ugb2YgPEJSPiZuYnNwOyZuYnNwOyBJbW1lZGlhdGVseSBS ZXBseWluZyBIZWxsbyANCiAgd2hpY2ggY291bGQgcmVkdWNlIHRoZSB0aW1lIHJlcXVpcmVkIHRv IDxCUj4mbmJzcDsmbmJzcDsgcmVhY2ggdGhlIE9TUEYgDQogIJNFeFN0YXJ0lCBzdGF0ZSBhbmQm bmJzcDsgZXhwZWRpdGUgdGhlIHJvdXRpbmcgdGFibGUgPEJSPiZuYnNwOyZuYnNwOyANCiAgY29u dmVyZ2VuY2UuJm5ic3A7Jm5ic3A7IA0KPC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+PC9ESVY+PC9C TE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= --Boundary_(ID_c4blHY2fuE0MIHuFtCKlNw)-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 29 21:40:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsAC8-0004Tf-HL for ospf-archive@megatron.ietf.org; Thu, 29 Dec 2005 21:40:40 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19880 for ; Thu, 29 Dec 2005 21:39:28 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <12.00007DED@wildebeest.ease.lsoft.com>; Thu, 29 Dec 2005 21:40:09 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95027505 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 29 Dec 2005 21:40:08 -0500 Received: from 61.144.161.53 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 29 Dec 2005 21:40:07 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ISA00BFVIHO4E@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 Dec 2005 10:49:00 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ISA009LBIHOAT@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 Dec 2005 10:49:00 +0800 (CST) Received: from k49110 ([10.111.12.97]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ISA00K2MIQO2M@szxml01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 Dec 2005 10:54:24 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20051229112742.71966.qmail@web25401.mail.ukl.yahoo.com> Message-ID: <006001c60cea$56c85d10$610c6f0a@china.huawei.com> Date: Fri, 30 Dec 2005 10:40:04 +0800 Reply-To: Mailing List Sender: Mailing List From: Zengjie Kou Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT Hi,Manav I don't find any harm except a few additional hello packets before the state reaches "ExStart". The Immediate Hello do not affect which router will be elected DR. It only expedite the election. thanks kou. ----- Original Message ----- From: "Manav Bhatia" To: Sent: Thursday, December 29, 2005 7:27 PM Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] > So whats the harm in this? > > If you wanted a particular router to become the DR then you would have given it a higher priority. > The fact that you havent done that implies that you dont really care which router becomes the DR. > > Manav > --- Nitin Kakkar wrote: > >> Suppose there are n routers on a Link and all of them come up almost >> simultaneously. >> >> Seems like the routers which were fractionally faster to send hello will be >> picked for DR/BDR election !!! >> >> >> >> May be you can think of immediately replying to hello packet "Only when DR >> is already elected on the link". >> >> >> >> Rgds >> >> Nitin >> >> >> >> -----Original Message----- >> From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >> Kouzengjie >> Sent: Thursday, December 29, 2005 7:51 AM >> To: OSPF@PEACH.EASE.LSOFT.COM >> Subject: Update to OSPF Hello >> procedure[draft-kou-ospf-immediately-replying-hello-00.txt] >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> The draft can be found here: >> http://www.ietf.org/internet-drafts/draft-kou-ospf-immediately-replying-hell >> o-00.txt >> >> >> >> This memo documents an extension of the OSPF protocol to reach >> "ExStart" state more quickly. Currently, the OSPF behavior requires >> the Hello Packet to be sent between the neighbors every >> HelloInterval. This document proposes to generalize the use of >> Immediately Replying Hello which could reduce the time required to >> reach the OSPF "ExStart" state and expedite the routing table >> convergence. >> >> > > > > > ___________________________________________________________ > NEW Yahoo! Cars - sell your car and browse thousands of new and used cars online! http://uk.cars.yahoo.com/ From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 29 22:22:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsAr3-0001Mo-O6 for ospf-archive@megatron.ietf.org; Thu, 29 Dec 2005 22:22:58 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23738 for ; Thu, 29 Dec 2005 22:21:46 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <1.00007DEC@wildebeest.ease.lsoft.com>; Thu, 29 Dec 2005 22:22:25 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95029254 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 29 Dec 2005 22:22:25 -0500 Received: from 143.209.238.161 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 29 Dec 2005 22:22:25 -0500 Received: from mvrelay.mv.usa.alcatel.com (mvrelay.mv.usa.alcatel.com [128.251.10.15]) by audl951.usa.alcatel.com (ALCANET) with ESMTP id jBU3KGvw027585; Thu, 29 Dec 2005 21:20:16 -0600 Received: from SPEEDY1PC (localhost [127.0.0.1]) by mvrelay.mv.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id jBU3KUn7025902; Thu, 29 Dec 2005 19:20:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcYM6mTR9FfvvAT8QxmKqQSdj9zTngABTT0g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 Message-ID: <200512300320.jBU3KUn7025902@mvrelay.mv.usa.alcatel.com> Date: Thu, 29 Dec 2005 19:20:12 -0800 Reply-To: Mailing List Sender: Mailing List From: Don Goodspeed Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] Comments: To: Zengjie Kou To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <006001c60cea$56c85d10$610c6f0a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Only if everyone of the attached network implement this mechanism, otherwise how could it. A shared hub or switch goes down then comes back up. Two routers implementing the mechanism have a lower priority than a 3rd router that has a higher priority and had been the DR. The two lower priority routers "ack" each other and go to ExStart then Full and one of the two is elected DR, churning the network LSAs. Am I missing something here? -don -----Original Message----- From: owner-ospf@PEACH.EASE.LSOFT.COM [mailto:owner-ospf@PEACH.EASE.LSOFT.COM] On Behalf Of Zengjie Kou Sent: Thursday, December 29, 2005 6:40 PM To: Mailing List Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] Hi,Manav I don't find any harm except a few additional hello packets before the state reaches "ExStart". The Immediate Hello do not affect which router will be elected DR. It only expedite the election. thanks kou. ----- Original Message ----- From: "Manav Bhatia" To: Sent: Thursday, December 29, 2005 7:27 PM Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] > So whats the harm in this? > > If you wanted a particular router to become the DR then you would have given it a higher priority. > The fact that you havent done that implies that you dont really care which router becomes the DR. > > Manav > --- Nitin Kakkar wrote: > >> Suppose there are n routers on a Link and all of them come up almost >> simultaneously. >> >> Seems like the routers which were fractionally faster to send hello will be >> picked for DR/BDR election !!! >> >> >> >> May be you can think of immediately replying to hello packet "Only when DR >> is already elected on the link". >> >> >> >> Rgds >> >> Nitin >> >> >> >> -----Original Message----- >> From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >> Kouzengjie >> Sent: Thursday, December 29, 2005 7:51 AM >> To: OSPF@PEACH.EASE.LSOFT.COM >> Subject: Update to OSPF Hello >> procedure[draft-kou-ospf-immediately-replying-hello-00.txt] >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> The draft can be found here: >> http://www.ietf.org/internet-drafts/draft-kou-ospf-immediately-replying-hell >> o-00.txt >> >> >> >> This memo documents an extension of the OSPF protocol to reach >> "ExStart" state more quickly. Currently, the OSPF behavior requires >> the Hello Packet to be sent between the neighbors every >> HelloInterval. This document proposes to generalize the use of >> Immediately Replying Hello which could reduce the time required to >> reach the OSPF "ExStart" state and expedite the routing table >> convergence. >> >> > > > > > ___________________________________________________________ > NEW Yahoo! Cars - sell your car and browse thousands of new and used cars online! http://uk.cars.yahoo.com/ From owner-ospf@PEACH.EASE.LSOFT.COM Thu Dec 29 23:33:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsBxZ-0007S2-7m for ospf-archive@megatron.ietf.org; Thu, 29 Dec 2005 23:33:45 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29036 for ; Thu, 29 Dec 2005 23:32:34 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <2.00007E09@wildebeest.ease.lsoft.com>; Thu, 29 Dec 2005 23:33:13 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95034734 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 29 Dec 2005 23:33:12 -0500 Received: from 207.69.195.68 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 29 Dec 2005 23:33:12 -0500 Received: from h-68-164-85-155.snvacaid.dynamic.covad.net ([68.164.85.155] helo=earthlink.net) by pop-cowbird.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1EsBx3-0001oR-00 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 29 Dec 2005 23:33:13 -0500 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <20051229112742.71966.qmail@web25401.mail.ukl.yahoo.com> <006001c60cea$56c85d10$610c6f0a@china.huawei.com> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Message-ID: <43B4B2F9.60A807AB@earthlink.net> Date: Thu, 29 Dec 2005 20:09:29 -0800 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7bit Kou, 1) A few extra hellos? You will force a matrix number of hellos? With 10 routers, you will need 90 hellos. With 100 routers, we have 9900 hellos I think, if we need to respond to each nbr's hello. Where we have 2x the number of router's hellos in the standard method with MC hellos (20 and 200). Oh, yours are with ms of each other and the standard hellos are spread along the hello interval. 2) I disagree, this can effect DR election. How? Assume their is a disagreement as to whom should be elected DR in the normal method. Now, with that quick hello, the faster router tells the other routers not just whom he choose, but who is the DR. Anytime before DR is elected, Y informs that X is the DR, then OSPF says X is the DR. You are saving on avg 1/2 hello interval time. Now, why can their be a disagreement? Simply, a late hello informing about a new router with a higher priority before the DR is elected. With the current method, we give an extra few secs, just to allow everyone to make up their own private decision, then publicise the decision, and if their is a disagreement after recieving the multiple public hellos, then resolve it. Yes, some implimentations ignore hellos with DR announcement after election has begun. But some don't. And I am refering to the later ones. Now, it gets complicated. Assume that 2 routers who accept the fast hello and the interruption of the DR process. Won't they form a full ADJ if one or both are the DR / BDR? Now, the 3rd guy heard a hello from the highest priority router and accepted him as the DR? Aren't you needlessly trying to sync the LSDBs with the wrong DR? Mitchell Erblich Zengjie Kou wrote: > > Hi,Manav > I don't find any harm except a few additional hello packets before the state reaches "ExStart". > > The Immediate Hello do not affect which router will be elected DR. It only expedite the election. > > thanks > kou. > > ----- Original Message ----- > From: "Manav Bhatia" > To: > Sent: Thursday, December 29, 2005 7:27 PM > Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] > > > So whats the harm in this? > > > > If you wanted a particular router to become the DR then you would have given it a higher priority. > > The fact that you havent done that implies that you dont really care which router becomes the DR. > > > > Manav > > --- Nitin Kakkar wrote: > > > >> Suppose there are n routers on a Link and all of them come up almost > >> simultaneously. > >> > >> Seems like the routers which were fractionally faster to send hello will be > >> picked for DR/BDR election !!! > >> > >> > >> > >> May be you can think of immediately replying to hello packet "Only when DR > >> is already elected on the link". > >> > >> > >> > >> Rgds > >> > >> Nitin > >> > >> > >> > >> -----Original Message----- > >> From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > >> Kouzengjie > >> Sent: Thursday, December 29, 2005 7:51 AM > >> To: OSPF@PEACH.EASE.LSOFT.COM > >> Subject: Update to OSPF Hello > >> procedure[draft-kou-ospf-immediately-replying-hello-00.txt] > >> > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> The draft can be found here: > >> http://www.ietf.org/internet-drafts/draft-kou-ospf-immediately-replying-hell > >> o-00.txt > >> > >> > >> > >> This memo documents an extension of the OSPF protocol to reach > >> "ExStart" state more quickly. Currently, the OSPF behavior requires > >> the Hello Packet to be sent between the neighbors every > >> HelloInterval. This document proposes to generalize the use of > >> Immediately Replying Hello which could reduce the time required to > >> reach the OSPF "ExStart" state and expedite the routing table > >> convergence. > >> > >> > > > > > > > > > > ___________________________________________________________ > > NEW Yahoo! Cars - sell your car and browse thousands of new and used cars online! http://uk.cars.yahoo.com/ From owner-ospf@PEACH.EASE.LSOFT.COM Fri Dec 30 00:50:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsDA2-0005n3-UE for ospf-archive@megatron.ietf.org; Fri, 30 Dec 2005 00:50:43 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06369 for ; Fri, 30 Dec 2005 00:49:31 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <9.00007E24@wildebeest.ease.lsoft.com>; Fri, 30 Dec 2005 0:50:11 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95040793 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 Dec 2005 00:50:10 -0500 Received: from 63.197.255.154 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 30 Dec 2005 00:50:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Thread-Topic: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] Thread-Index: AcYM5k1OjFRUi2UNQRq8xjZqD48HOgAHdMQw Message-ID: Date: Thu, 29 Dec 2005 21:50:10 -0800 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: quoted-printable Hi Zengjie, Why isn't it good enough to send a hello if the hello interval value is changed? I think you can find many-many other cases. I think to put the draft generally, whenever the content of the hello message changes we could send the hello immediately and then reset the hello timer to expire "Hello interval" seconds later. Another thing is about "Rate limiting Hello's" to prevent overwhelming of the network by hellos being sent. I think it is an essential feature. Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Zengjie Kou Sent: Friday, December 30, 2005 7:36 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Update to OSPF Hello procedure [draft-kou-ospf-immediately-replying-hello-00.txt] hi,Vishwas =20 The Immediately Hello only reduces the time to reach the "ExStart" state. It is unnecessary to use it when the state is more than "ExStart".=20 ----- Original Message -----=20 From: "Vishwas Manral" To: Sent: Thursday, December 29, 2005 6:29 PM Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] Hi, Why should this not happen for every change in the neighbor status when received in a hello message?=20 Whenever the contents of the hello message change we could send the message immediately. Is there a Minimum interval between which if we get consecutive hello's we do not process them, just like LSA's? Thanks, Vishwas ________________________________________ From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Kouzengjie Sent: Thursday, December 29, 2005 7:51 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] A New Internet-Draft is available from the on-line Internet-Drafts directories. The draft can be found here: http://www.ietf.org/internet-drafts/draft-kou-ospf-immediately-replying- hello-00.txt This memo documents an extension of the OSPF protocol to reach=20 "ExStart" state more quickly. Currently, the OSPF behavior requires=20 the Hello Packet to be sent between the neighbors every=20 HelloInterval. This document proposes to generalize the use of=20 Immediately Replying Hello which could reduce the time required to=20 reach the OSPF "ExStart" state and expedite the routing table=20 convergence.=20 From owner-ospf@PEACH.EASE.LSOFT.COM Fri Dec 30 01:01:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsDKa-0000Li-KZ for ospf-archive@megatron.ietf.org; Fri, 30 Dec 2005 01:01:36 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07379 for ; Fri, 30 Dec 2005 01:00:24 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <3.00007E2A@wildebeest.ease.lsoft.com>; Fri, 30 Dec 2005 1:01:04 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95041590 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 Dec 2005 01:01:05 -0500 Received: from 61.144.161.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 30 Dec 2005 01:01:04 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ISA00LJYRSNH4@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 Dec 2005 14:09:59 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ISA00JG1RSN31@szxga02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 Dec 2005 14:09:59 +0800 (CST) Received: from Nitink20745 ([10.18.4.177]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ISA00JCERY7Y7@szxml01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 Dec 2005 14:13:20 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: <000001c60d06$206b36e0$b104120a@china.huawei.com> Date: Fri, 30 Dec 2005 11:28:57 +0530 Reply-To: Mailing List Sender: Mailing List From: Nitin Kakkar Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20051229112742.71966.qmail@web25401.mail.ukl.yahoo.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT Manav, That's the entire point routers with higher priority may not get chance to participate in DR election. Now DR election depends on the order in which routers come up and send hello. There is no grace time for other routers to come up and announce themselves. Nitin -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Manav Bhatia Sent: Thursday, December 29, 2005 4:58 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] So whats the harm in this? If you wanted a particular router to become the DR then you would have given it a higher priority. The fact that you havent done that implies that you dont really care which router becomes the DR. Manav --- Nitin Kakkar wrote: > Suppose there are n routers on a Link and all of them come up almost > simultaneously. > > Seems like the routers which were fractionally faster to send hello will be > picked for DR/BDR election !!! > > > > May be you can think of immediately replying to hello packet "Only when DR > is already elected on the link". > > > > Rgds > > Nitin > > > > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > Kouzengjie > Sent: Thursday, December 29, 2005 7:51 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Update to OSPF Hello > procedure[draft-kou-ospf-immediately-replying-hello-00.txt] > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > The draft can be found here: > http://www.ietf.org/internet-drafts/draft-kou-ospf-immediately-replying-hell > o-00.txt > > > > This memo documents an extension of the OSPF protocol to reach > "ExStart" state more quickly. Currently, the OSPF behavior requires > the Hello Packet to be sent between the neighbors every > HelloInterval. This document proposes to generalize the use of > Immediately Replying Hello which could reduce the time required to > reach the OSPF "ExStart" state and expedite the routing table > convergence. > > ___________________________________________________________ NEW Yahoo! Cars - sell your car and browse thousands of new and used cars online! http://uk.cars.yahoo.com/ From owner-ospf@PEACH.EASE.LSOFT.COM Fri Dec 30 02:28:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsEgJ-0003q8-Kl for ospf-archive@megatron.ietf.org; Fri, 30 Dec 2005 02:28:07 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13604 for ; Fri, 30 Dec 2005 02:26:55 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <12.00007E30@wildebeest.ease.lsoft.com>; Fri, 30 Dec 2005 2:27:35 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95045213 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 Dec 2005 02:27:35 -0500 Received: from 61.144.161.55 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 30 Dec 2005 02:27:33 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ISA003X6V9OOS@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 Dec 2005 15:25:01 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ISA00HA0V3E6C@szxga03-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 Dec 2005 15:25:00 +0800 (CST) Received: from k49110 ([10.111.12.97]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ISA0000QVLUB4@szxml01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Fri, 30 Dec 2005 15:32:18 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=iso-8859-2 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <017201c60c1e$8f545a20$610c6f0a@china.huawei.com> <43B45416.4FF846D7@earthlink.net> Message-ID: <003e01c60d11$28dbb3d0$610c6f0a@china.huawei.com> Date: Fri, 30 Dec 2005 15:17:57 +0800 Reply-To: Mailing List Sender: Mailing List From: Zengjie Kou Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: base64 SGksTWl0Y2hlbGwNCg0KICAgIFBsZWFzZSBzZWUgaW5saW5lIGZvciBhbnN3ZXJzIHRvIHlvdXIg cXVlc3Rpb25zLg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkVyYmxp Y2hzIiA8ZXJibGljaHNARUFSVEhMSU5LLk5FVD4NClRvOiA8T1NQRkBQRUFDSC5FQVNFLkxTT0ZU LkNPTT4NClNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMzAsIDIwMDUgNToyNCBBTQ0KU3ViamVjdDog UmU6IFVwZGF0ZSB0byBPU1BGIEhlbGxvIHByb2NlZHVyZVtkcmFmdC1rb3Utb3NwZi1pbW1lZGlh dGVseS1yZXBseWluZy1oZWxsby0wMC50eHRdDQoNCg0KPiBHcm91cCwNCj4gDQo+IElmIG15IG9w aW5pb24gY291bnRzIGZvciBhbnl0aGluZy4uDQo+IA0KPiAwKSBUaGUgdGV4dCBoYXMgYSBudW1i ZXIgb2YgdW51c2FsIGNoYXJzLg0KICAgIA0KWWVzLCBpdCBtYXkgYmUgYSBxdWVzdGlvbiBhYm91 dCBjaGFyYWN0ZXIgc2V0LiBJIHdpbGwgY29ycmVjdCBpdCBpbiBmdXR1cmUgdmVyaXNvbi4NCg0K PiAxKSBXaXRoIGEgbnVtYmVyIG9mIHJvdXRlcnMgc2VuZGluZyBvdXQgaGVsbG9zDQo+ICAgIHRo ZSBtb21lbnQgdGhlIGludGVyZmFjZXMgYmVjb21lIGFjdGl2ZSwgSSBhbQ0KPiAgICBub3Qgc3Vy ZSBvZiB0aGlzIGJlbmVmaXQuLiBIb3dldmVyLi4NCiAgICBJdCBlY29ub21pemVzIGEgSGVsbG9J bnRlcnZhbC4NCg0KPiAyKSBJZiB3ZSBhcmUgTUMgaGVsbG9zLCBpc24ndCBhIHN1Z2dlc3Rpb24g b2YNCj4gICAgcmVzcG9uZGluZyB3aXRoIGEgaW1tZWRpYXRlIHJlcGx5IHN5bmNoDQo+ICAgIGhl bGxvcy4gSXMgdGhpcyBhIGdvb2QgdGhpbmc/DQoNCiAzKSBPbiB0aGUgcHJldmlvdXMgYXNzdW1w dGlvbiBvZiBNQyBoZWxsb3MsIGFuZA0KPiAgICB3ZSBoYXZlIHNheSAxMCBwcmUtbmJycywgZG9l cyB0aGF0IG1lYW4gd2Ugc2hvdWxkDQo+ICAgIHNlbmQgb3V0IDEwIGhlbGxvcyB0byBlYWNoIG5i cj8gT3VyIGhlbGxvcw0KPiAgICBpbmZvcm0gZWFjaCBuYnIgYWJvdXQgb3VyIHN0YXRlLiBEb2Vz IHRoaXMgc2NhbGU/DQo+ICAgIENhbiB3ZSB0aGVvcmVjdGx5IGJlIHNlbmRpbmcgb3V0IGNsb3Nl IHRvIDkwDQo+ICAgICAgICAgICBoZWxsb3MgZm9yIDEwIG5icnM/IEVhY2ggbmJyIHNlbmQgb3V0 IGEgcmVwbHkNCj4gICAgdG8gZWFjaCBvZiB0aGVpciA5IG5icnMuDQogICAgWW91ciBjYWxjdWxh dGlvbiBpcyBmaXQgd2hlbiBhbGwgcm91dGVyIGJvb3QgZmlyc3QuIEhvd2V2ZXIsZm9yIGludGVy ZmFjZSB1cC9kb3csIGl0IGl0IG9ubHkgMjcgaGVsbG9zLg0KDQo+ICAgIElmIHdlIHdhaXQgZm9y IHRoZSBoZWxsbyBpbnRlcnZhbCwgdGhlIG5icnMNCj4gICAgZmllbGRzIHNob3VsZCBiZSBmaWxs ZWQgMSBoZWxsbyBpbnRlcnZhbA0KPiAgICBhZnRlciB0aGUgIzEgKGJyaW5nIHVwIGhlbGxvKSB3 YXMgc2VudCB3aXRoDQo+ICAgIDEgaGVsbG8uIElzbid0IHRoaXMgYSBnb29kIHRoaW5nPw0KPiAN Cj4gNCkgV2l0aCBhIGhlbGxvIGludGVydmFsIHNlcGFyYXRpbmcgaGVsbG9zLCB3ZQ0KPiAgICBz aG91bGQgbWluaW1pemUgYSBoZWxsbyBzdG9ybS4gSXNuJ3QgdGhpcyBhDQo+ICAgIGdvb2QgdGhp bmc/DQogICAgDQo+IDUpIFlvdXIgc2VjdGlvbiAzLiBQb3RlbnRpYWwgU29sdXRpb24uDQo+ICAg IFdoYXQgaXMgIkZhc3QgaGVsbG8iIGFuZCAiaW50ZW50aW9uIj8NCiAgICBGYXN0IGhlbGxvOiBz aG9ydGVuIEhlbGxvSW50ZXJ2YWwuDQogICAgaW50ZW50aW9uOiByZWR1Y2UgdGhlIHRpbWUgdG8g cmVhY2ggdGhlICJFeFN0YXJ0Ii4NCg0KPiAgIDViKSBEbyB3ZSBwaW5nIHBvbmcgb3VyIGhlbGxv cyBpZiBvdXINCj4gICAgICAgaGVsbG8gcGFyYW1ldGVycyBkb24ndCBtYXRjaD8gQXNzdW1pbmcN Cj4gICAgICAgd2UgY2FuIGdlbmVyYXRlIDEwayBoZWxsb3MgcGVyIHNlYywgc2hvdWxkDQo+ICAg ICAgIHdlIGJlY2F1c2Ugd2UgYXJlIGxlc3MgdGhhbiAyLXdheT8NCj4gICAgICAgVGhpcyBpcyB3 aHkgVENQIGRvZXNuJ3QgQUNLIGFuZCBBQ0shDQo+ICAgICAgIE9yIGFyZSB5b3UgdGhpbmtpbmcg YWJvdXQgYSByZXBseSBvbmx5IGFmdGVyDQo+ICAgICAgIHZhbGlkYXRpb24gYW5kIGFjY2VwdGFu Y2U/DQogICAgVGhlIEltbWVkaWF0ZSBoZWxsbyBpcyBwZXJmb3JtZWQgYWZ0ZXIgaGVsbG8gcGFy YW1ldGVycyBtYXRjaCBlYWNoIG90aGVyLg0KDQo+IDYpIFlvdXIgc2VjdGlvbiA1LiBJbW1lZGlh dGVseSByZXBseWluZyBIZWxsbw0KPiAgICBEb2VzICJ0byB0aGlzIG5iciIgbWVhbiBVQyAodW5p Y2FzdCk/DQogICAgWWVzLg0KDQo+IDcpIFlvdXIgc2VjdGlvbiA1LiBJbW1lZGlhdGVseSAuLi4N Cj4gICAgM2ZAIEFmdGVyIERSIGlzIGVsZWN0ZWQuLi4NCj4gDQo+ICAgIFdpdGggbm8gaGVsbG8g d2FpdCBwZXJpb2QsIGFyZW4ndCB5b3UNCj4gICAgYWRkaW5nIGEgcmFjZSBjb25kaXRpb24gd2hl cmUgdGhlIGZpcnN0IHJvdXRlcg0KPiAgICBhbm5vdWNlcyB0aGUgRFIgYW5kIHRoZSBCRFIuIFRo ZSBTTE9XRVIgcm91dGVycw0KPiAgICBpbXBsaWNpdGx5IGFjY29yZGluZyB0byB0aGUgc3BlYyBt dXN0IHN0b3AgdGhlaXIgDQo+ICAgIGVsZWN0aW9uIGFuZCB0YWtlIHRoZSBhbm5vdW5jZWQgRFIg YW5kIEJEUiBhcw0KPiAgICB0cnV0aCBpbiB0aGF0IGhlbGxvLg0KPiAgICBUaGUgb3RoZXIgd2F5 IHZhbGlkYXRlcyBhIGNvbnNlbnN1cyBvZiBhIERSIC8gQkRSLg0KDQo+IDgpIElmIHdlIGV2ZXIg Y29tbXVuaWNhdGUgd2l0aCBtcyBoZWxsb3MsIHlvdXINCj4gICAgaGVsbG9zIGNhbiBjb25zdW1l IGFsb3Qgb2YgYmFuZHdpZHRoIGZvciByb3V0ZXJzDQo+ICAgIHRoYXQgZmxhcD8NCiAgICB3aGVu IGZsYXBpbmcsIHRoZSBpbW1lZGlhdGUgaGVsbG8gZXhwZWRpYXRlcyB0aGUgbGluayByZWNvdmVy eS4gYSBmZXcgYWRkaXRpb25hbCBoZWxsb3Mgd2lsbCBiZSBicm91Z2h0LCBidXQgaXQgU0hPVUxE IGNvbnN1bWUgYSBsb3Qgb2YgYmFuZHdpZHRoLg0KDQo+IDksIDEwKSBldGMuLi4NCj4gDQo+IE92 ZXJhbGwsIEkgdGhpbmsgeW91IGFyZSBhZGRpaW5nIGFsb3Qgb2YgY29tcGxleGl0eQ0KPiBhbmQg Tk9UIGFsbG93aW5nIHRoZSBoZWxsbyBwa3QgdG8gYWNjdW1hbGF0ZSBjdXJyZW50DQo+ICBzdGF0 ZSBiZWZvcmUgc2VuZGluZyBvdXQgdGhlIG5leHQgaGVsbG8uIEl0IGlzIHBvc3NpYmxlDQo+IHRo YXQgdmVyeSBzbWFsbCBpbmNyZW1lbnRhbCBhbW91bnRzIG9mIHRpbWUgYXJlIHJlbWFpbmluZw0K PiB2aWEgdGhlIGhlbGxvIGludGVydmFsIHRpbWVyLg0KPiANCj4gVGhlIGhlbGxvIGludGVydmFs IGlzIGEgbWlub3IgZGVsYXkgdGhhdCBpcyBhZ3JlZWQgdG8NCj4gYmUgb3ZlcnNoYWRvd2VkIGJ5 IHRoZSBXYWl0aW5nIHRpbWUuDQo+ICgiV2FpdGluZyB0aW1lIGFjY291bnRzIGZvciA4MCUgdG8g OTAlIG9mIHRoZSB0b3RhbA0KPiAgIHJlY292ZXJ5IHRpbWUiKS4NCj4gVGh1cyBBbWRhaGxzIGxh dyB0ZWxscyB1cyBpZiB3ZSBkaXZpZGUgYSBwcm9ibGVtDQo+IGluIGhhbGYgYW5kIG1ha2UgMS8y IGluZmluaXRlbHkgZmFzdCB3ZSB3aWxsIGdldA0KPiBhdCBiZXN0IGEgMnggc3BlZWR1cC4gQW5k IHlvdSBhcmUgZml4aW5nIGxlc3MgdGhhbg0KPiAyMCUgb2YgdGhlIHByb2JsZW0uDQo+IA0KPiBU aGUgV2FpdGluZyB0aW1lIGJlZm9yZSBhIERSIC8gQkRSIGVsZWN0aW9uIGlzIHRoZWlyDQo+IGJl Y2F1c2U6DQo+ICogVGhlIG51bWJlciBvZiB0aW1lcyBhIHdhaXQgc3RhdGUgbmVlZHMgdG8NCj4g ICAgICAgICAgIGJlIGVudGVyZWQgc2hvdWxkIGJlIGluZnJlcXVlbnQuDQo+ICogSXQgaXMgb25s eSBlbnRlcmVkIGlmIG5vLW9uZSBpcyBhbm5vdW5jaW5nDQo+ICAgICAgICAgICBhIERSIC8gQkRS LCBlbHNlIGl0IHNob3VsZCBiZSBhcHByb3ggMS8yDQo+ICAgICAgICAgICBoZWxsbyBpbnRlcnZh bCB0aW1lLg0KPiAqIFRoZSB3YWl0IHBlcmlvZCBhc3N1bWVzIHRoYXQgaGVsbG9zIGFyZQ0KPiAg ICAgICAgICAgc3ByZWFkIG92ZXIgc29tZSB0aW1lIHBlcmlvZC4NCj4gKiBFdmVuIGlmIDEgaGVs bG8gaXMgbG9zdCwgYWxsIG5iciBzaG91bGQNCj4gICAgICAgICAgIGJlIGtub3duIHdpdGhpbiB0 aGlzIHRpbWUgcGVyaW9kLg0KPiAqIFRoZSBtb3N0IHBvd2VyZnVsIHN5c3RlbXMgaGF2ZSB0aGUg bGFyZ2VzdA0KPiAgICAgICAgICAgYW1vdW50IG9mIG1lbW9yeSBhbmQgdGhlc2UgbWVtb3J5IHZh bGlkYXRpb25zDQo+ICAgICAgICAgICB0YWtlIG1vcmUgdGltZSB3aXRoIG1vcmUgbWVtb3J5Lg0K PiAqZXRjLi4uDQo+IA0KPiBJIHNlZSBhbG90IG9mIHByb2JsZW1zIGFuZCBwb3RlbnRpYWwgcHJv YmxlbXMgd2l0aA0KPiB0aGlzIHN1Z2dlc3Rpb24uLg0KPiANCj4gR2Fzb2xpbmUgZm9yIHRoZSBm aXJlLi4uLg0KPiBJdCB3b3VsZCBtYWtlIFNFTlNFIGF0IGxlYXN0IHRvIG1lLCBpZiBhIERSIHdp dGggbWF4IHByaW9yaXR5DQo+IHdhcyB2b2x1bnRhcmlseSBicm91Z2h0IGRvd24gd2l0aCBhIGdy b3VwIG9mIG90aGVyIG90aGVyLXJvdXRlcnMsIA0KPiB0byBicmluZyBpdCB1cCBhbm5vdW5jaW5n IGl0c2VsZiBhcyB0aGUgRFIuIFRoaXMgd291bGQgcmVtb3ZlDQo+IDgwIHRvIDkwJSBvZiB5b3Vy IElHUCBjb252ZXJnZW5jZSB0aW1lLg0KPiANCiBPbiBicm9hZGNhc3QgYW5kIE5CTUEgbmV0d29y a3MsIHRoZSB0aW1lIHRvIHJlYWNoIHRoZSAiRXhTdGFydCIgc3RhdGUgDQogICBpcyByZWR1Y2Vk IHRvIHN1Yi1zZWNvbmQgYnkgSW1tZWRpYXRlbHkgUmVwbHlpbmcgSGVsbG8gd2hlbiBEUiBvciBC RFIgDQogICBleGlzdHMuIEluIHBhcnRpY3VsYXIsIGEgcm91dGVyIGludGVyZmFjZSBnb2VzIGRv d24gdGhlbiB1cCwgaXQgaXMgb2J2aW91cy4NCg0KVGhhbmtzDQprb3UuDQoNCg0KIEVyYmxpY2gN Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ICAgIA0KPiANCj4+IEtvdXplbmdqaWUgd3JvdGU6 DQo+PiANCj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1s aW5lIEludGVybmV0LURyYWZ0cw0KPj4gZGlyZWN0b3JpZXMuDQo+PiBUaGUgZHJhZnQgY2FuIGJl IGZvdW5kIGhlcmU6DQo+PiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1rb3Utb3NwZi1pbW1lZGlhdGVseS1yZXBseWluZy1oZWxsby0wMC50eHQNCj4+IA0KPj4gIFRo aXMgbWVtbyBkb2N1bWVudHMgYW4gZXh0ZW5zaW9uIG9mIHRoZSBPU1BGIHByb3RvY29sIHRvIHJl YWNoDQo+PiAgICC3sEV4U3RhcnS3sSBzdGF0ZSBtb3JlIHF1aWNrbHkuIEN1cnJlbnRseSwgdGhl IE9TUEYgYmVoYXZpb3INCj4+IHJlcXVpcmVzDQo+PiAgICB0aGUgSGVsbG8gUGFja2V0IHRvIGJl IHNlbnQgYmV0d2VlbiB0aGUgbmVpZ2hib3JzIGV2ZXJ5DQo+PiAgICBIZWxsb0ludGVydmFsLiBU aGlzIGRvY3VtZW50IHByb3Bvc2VzIHRvIGdlbmVyYWxpemUgdGhlIHVzZSBvZg0KPj4gICAgSW1t ZWRpYXRlbHkgUmVwbHlpbmcgSGVsbG8gd2hpY2ggY291bGQgcmVkdWNlIHRoZSB0aW1lIHJlcXVp cmVkIHRvDQo+PiAgICByZWFjaCB0aGUgT1NQRiC3sEV4U3RhcnS3sSBzdGF0ZSBhbmQgIGV4cGVk aXRlIHRoZSByb3V0aW5nIHRhYmxlDQo+PiAgICBjb252ZXJnZW5jZS4= From owner-ospf@PEACH.EASE.LSOFT.COM Sat Dec 31 03:29:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Esc7T-0000i9-5o for ospf-archive@megatron.ietf.org; Sat, 31 Dec 2005 03:29:43 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14991 for ; Sat, 31 Dec 2005 03:28:29 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <12.00007FBE@wildebeest.ease.lsoft.com>; Sat, 31 Dec 2005 3:29:10 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95113179 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 31 Dec 2005 03:29:09 -0500 Received: from 61.144.161.53 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 31 Dec 2005 03:29:09 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ISC00L5NTBCBW@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Sat, 31 Dec 2005 16:38:01 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ISC00HHWTBCCO@szxga01-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Sat, 31 Dec 2005 16:38:00 +0800 (CST) Received: from k49110 ([10.111.12.97]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ISC00F3LTEIVT@szxml02-in.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Sat, 31 Dec 2005 16:39:54 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=iso-8859-2 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20051229112742.71966.qmail@web25401.mail.ukl.yahoo.com> <006001c60cea$56c85d10$610c6f0a@china.huawei.com> <43B4B2F9.60A807AB@earthlink.net> Message-ID: <002301c60de4$4074d160$610c6f0a@china.huawei.com> Date: Sat, 31 Dec 2005 16:29:00 +0800 Reply-To: Mailing List Sender: Mailing List From: Zengjie Kou Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Content-Transfer-Encoding: 7BIT Hi,Mitchell Please see inline for answers to your questions. ----- Original Message ----- From: "Erblichs" To: Sent: Friday, December 30, 2005 12:09 PM Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] > Kou, > > 1) A few extra hellos? You will force a matrix number > of hellos? With 10 routers, you will need 90 hellos. > With 100 routers, we have 9900 hellos I think, if > we need to respond to each nbr's hello. Where we have > 2x the number of router's hellos in the standard method > with MC hellos (20 and 200). Oh, yours are with ms of > each other and the standard hellos are spread along the > hello interval. > 1.) Immediate Hello can be enable or disable. 2.) On broadcast and NBMA networks, Immediate Hello expedite link recovery when a link goes down then up and does bring a few extra hellos(with 10 routers, will need 27(9*3) hellos ). At the moment of router booting, the Immediate Hello is not fit. So, we can disable it. > 2) > I disagree, this can effect DR election. > > How? Assume their is a disagreement as to whom > should be elected DR in the normal method. Now, with > that quick hello, the faster router tells the other > routers not just whom he choose, but who is the DR. > > Anytime before DR is elected, Y informs that X is the DR, > then OSPF says X is the DR. You are saving on avg > 1/2 hello interval time. > > Now, why can their be a disagreement? Simply, a late > hello informing about a new router with a higher priority > before the DR is elected. > > With the current method, we give an extra few secs, just > to allow everyone to make up their own private decision, then > publicise the decision, and if their is a disagreement after > recieving the multiple public hellos, then resolve it. > > Yes, some implimentations ignore hellos with DR announcement > after election has begun. But some don't. And I am refering > to the later ones. > > Now, it gets complicated. Assume that 2 routers who accept > the fast hello and the interruption of the DR process. Won't > they form a full ADJ if one or both are the DR / BDR? Now, > the 3rd guy heard a hello from the highest priority router > and accepted him as the DR? Aren't you needlessly trying > to sync the LSDBs with the wrong DR? > > Mitchell Erblich > > > Sorry, I don't know what is your question. 1)Why is DR election interrupted? Why is DR election wrong? With two routers, one is DR, another is BDR, their hello packets include DR/BDR information. Thanks Kou. > Zengjie Kou wrote: >> >> Hi,Manav >> I don't find any harm except a few additional hello packets before the state reaches "ExStart". >> >> The Immediate Hello do not affect which router will be elected DR. It only expedite the election. >> >> thanks >> kou. >> >> ----- Original Message ----- >> From: "Manav Bhatia" >> To: >> Sent: Thursday, December 29, 2005 7:27 PM >> Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] >> >> > So whats the harm in this? >> > >> > If you wanted a particular router to become the DR then you would have given it a higher priority. >> > The fact that you havent done that implies that you dont really care which router becomes the DR. >> > >> > Manav >> > --- Nitin Kakkar wrote: >> > >> >> Suppose there are n routers on a Link and all of them come up almost >> >> simultaneously. >> >> >> >> Seems like the routers which were fractionally faster to send hello will be >> >> picked for DR/BDR election !!! >> >> >> >> >> >> >> >> May be you can think of immediately replying to hello packet "Only when DR >> >> is already elected on the link". >> >> >> >> >> >> >> >> Rgds >> >> >> >> Nitin >> >> >> >> >> >> >> >> -----Original Message----- >> >> From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >> >> Kouzengjie >> >> Sent: Thursday, December 29, 2005 7:51 AM >> >> To: OSPF@PEACH.EASE.LSOFT.COM >> >> Subject: Update to OSPF Hello >> >> procedure[draft-kou-ospf-immediately-replying-hello-00.txt] >> >> >> >> >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> >> directories. >> >> The draft can be found here: >> >> http://www.ietf.org/internet-drafts/draft-kou-ospf-immediately-replying-hell >> >> o-00.txt >> >> >> >> >> >> >> >> This memo documents an extension of the OSPF protocol to reach >> >> "ExStart" state more quickly. Currently, the OSPF behavior requires >> >> the Hello Packet to be sent between the neighbors every >> >> HelloInterval. This document proposes to generalize the use of >> >> Immediately Replying Hello which could reduce the time required to >> >> reach the OSPF "ExStart" state and expedite the routing table >> >> convergence. >> >> >> >> >> > >> > >> > >> > >> > ___________________________________________________________ >> > NEW Yahoo! Cars - sell your car and browse thousands of new and used cars online! http://uk.cars.yahoo.com/ From owner-ospf@PEACH.EASE.LSOFT.COM Sat Dec 31 09:35:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eshp7-0004FN-CV for ospf-archive@megatron.ietf.org; Sat, 31 Dec 2005 09:35:09 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16305 for ; Sat, 31 Dec 2005 09:33:56 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <1.00007FF2@wildebeest.ease.lsoft.com>; Sat, 31 Dec 2005 9:34:38 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95130282 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 31 Dec 2005 09:34:37 -0500 Received: from 212.17.55.49 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 31 Dec 2005 09:34:36 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX18hqvmXYCGIlAtXp/En8sRt8H9kt81wpAQ@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id jBVEYTv4022904 for ; Sat, 31 Dec 2005 14:34:32 GMT X-X-Sender: paul@sheen.jakma.org References: <000001c60d06$206b36e0$b104120a@china.huawei.com> Mail-Copies-To: paul@hibernia.jakma.org Mail-Followup-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.87.1/1219/Wed Dec 28 22:57:59 2005 on hibernia.jakma.org X-Virus-Status: Clean Message-ID: Date: Sat, 31 Dec 2005 14:34:29 +0000 Reply-To: Mailing List Sender: Mailing List From: Paul Jakma Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000001c60d06$206b36e0$b104120a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: On Fri, 30 Dec 2005, Nitin Kakkar wrote: > Manav, > That's the entire point routers with higher priority may not get chance to > participate in DR election. Now DR election depends on the order in which > routers come up and send hello. There is no grace time for other routers to > come up and announce themselves. You'll just get another DR/BDR election in that case. > Nitin regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Never look a gift horse in the mouth. -- Saint Jerome From owner-ospf@PEACH.EASE.LSOFT.COM Sat Dec 31 11:06:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsjFM-0005Y2-Pa for ospf-archive@megatron.ietf.org; Sat, 31 Dec 2005 11:06:20 -0500 Received: from wildebeest.ease.lsoft.com (wildebeest.ease.lsoft.com [209.119.0.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24102 for ; Sat, 31 Dec 2005 11:05:07 -0500 (EST) Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wildebeest.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <7.00008010@wildebeest.ease.lsoft.com>; Sat, 31 Dec 2005 11:05:50 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 95133451 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 31 Dec 2005 11:05:49 -0500 Received: from 212.17.55.49 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 31 Dec 2005 11:05:48 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX1/tkaHiybMu874CgDWQlj0BjH30eFk1XME@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id jBVG5hVo023596 for ; Sat, 31 Dec 2005 16:05:47 GMT X-X-Sender: paul@sheen.jakma.org References: <017201c60c1e$8f545a20$610c6f0a@china.huawei.com> Mail-Copies-To: paul@hibernia.jakma.org Mail-Followup-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.87.1/1219/Wed Dec 28 22:57:59 2005 on hibernia.jakma.org X-Virus-Status: Clean Message-ID: Date: Sat, 31 Dec 2005 16:05:43 +0000 Reply-To: Mailing List Sender: Mailing List From: Paul Jakma Subject: Re: Update to OSPF Hello procedure[draft-kou-ospf-immediately-replying-hello-00.txt] To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <017201c60c1e$8f545a20$610c6f0a@china.huawei.com> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: Hi, On Thu, 29 Dec 2005, Kouzengjie wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > The draft can be found here: > http://www.ietf.org/internet-drafts/draft-kou-ospf-immediately-replying-hello-00.txt GNU Zebra's (and hence Quagga's) ospfd has done something like this for a long time now (a subset at least, send hello immediately if neighbour state changes into state Init). One thing, might it be an idea to specify that the Immediate Hello be /independent/ of the Hello-Interval timer? (ie dont set or reset the interface's Hello timer because of any Immediate Hello sent). Otherwise, there'll be strong tendency for the HelloInterval timers across routers to latch. Not sure how much this matters. Also, it might be an idea to add some state (e.g. a delay factor, some arbitrary protocol constant, 100ms or somesuch) to prevent Immediate-Hello storms if, for whatever reason, neighbour states fail to progress pass ExStart and fall back to Init. Some types of links are quite sensitive to L2 congestion for example. 6.1.1. Is there a good reason why pre-2-Way Immediate-Hellos are to be sent unicast? If you happen to process multiple neighbour state changes (e.g. because of the delay factor on a previous immediate hello, or because the implementation chooses to define 'immediate' as 'very small delay'), one Immediate-Hello to AllSPFRouters can take care of all of them - rather than having to send multiple unicast hellos to each neighbour. I.e. it might be an idea to just drop the modifications proposed in 6.1.1. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Earth men are real men!