Re: Gracefu-Restart & RFC 3623

["Abhay D.S" <[e-mail]>]

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:[e-mail]] On Behalf Of Acee
Lindem
Sent: Friday, December 09, 2005 3:41 AM
To: [e-mail]
Subject: Re: Gracefu-Restart & RFC 3623


<Speaking as a somewhat biased WG member :^>

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:[e-mail]] On Behalf Of 
>Padma Pillay-Esnault
>Sent: Thursday, December 08, 2005 5:18 PM
>To: [e-mail]
>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:[e-mail]] On Behalf Of
>>Padma Pillay-Esnault
>>Sent: Thursday, December 08, 2005 3:03 PM
>>To: [e-mail]
>>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:[e-mail]] On Behalf Of
>>>Padma Pillay-Esnault
>>>Sent: Thursday, December 08, 2005 2:10 PM
>>>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 ?
>>>
>>>
>>>
>>>   
>>>
>>>      
>>>
>>>>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.
>>>
>>>
>>>
>>>   
>>>
>>>      
>>>
>>>>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.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>   
>>>
>>>      
>>>
>> 
>>
>>    
>>
>
>  
>