Re: Gracefu-Restart & RFC 3623

[Vishwas Manral <[e-mail]>]

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:[e-mail]] On Behalf Of Padma
Pillay-Esnault
Sent: Thursday, December 08, 2005 1:33 PM
To: [e-mail]
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:[e-mail]] On Behalf Of
Padma
>Pillay-Esnault
>Sent: Thursday, December 08, 2005 11:40 AM
>To: [e-mail]
>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:[e-mail]] On Behalf Of Don

>>Goodspeed
>>Sent: Thursday, December 08, 2005 4:06 AM
>>To: [e-mail]
>>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: [e-mail] 
>>[mailto:[e-mail]] 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.
>>
>>
>>
>>
>> 
>>
>>    
>>
>
>  
>