Re: Gracefu-Restart & RFC 3623
Vishwas Manral <Vishwas@SINETT.COM> Thu, 08 December 2005 08:50 UTC
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 <ospf-archive@LISTS.IETF.ORG>; 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: <BB6D74C75CC76A419B6D6FA7C38317B2B87470@sinett-sbs.SiNett.LAN>
Date: Thu, 08 Dec 2005 00:54:34 -0800
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Vishwas Manral <Vishwas@SINETT.COM>
Subject: Re: Gracefu-Restart & RFC 3623
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
List-Help: <http://peach.ease.lsoft.com/scripts/wa.exe?LIST=OSPF>, <mailto:LISTSERV@PEACH.EASE.LSOFT.COM?body=INFO+OSPF>
List-Unsubscribe: <mailto:OSPF-unsubscribe-request@PEACH.EASE.LSOFT.COM>
List-Subscribe: <mailto:OSPF-subscribe-request@PEACH.EASE.LSOFT.COM>
List-Owner: <mailto:OSPF-request@PEACH.EASE.LSOFT.COM>
List-Archive: <http://peach.ease.lsoft.com/scripts/wa.exe?LIST=OSPF>
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=ind0203&L=ospf&T=0&F=&S=&P =1888 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 >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. >> >> >> >> >> >> >> >> > > >
- Re: Gracefu-Restart & RFC 3623 Vishwas Manral
- Re: Gracefu-Restart & RFC 3623 Vishwas Manral
- Re: Gracefu-Restart & RFC 3623 Vishwas Manral