[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [OSPF] Query regarding grace-period in Garceful-restart





On 6/30/06 10:30 AM, "Padma Pillay-Esnault" <ppe at cisco.com> wrote:

> Hasmit Grover wrote:
> 
>> 
>> On 6/30/06 2:11 AM, "Padma Pillay-Esnault" <ppe at cisco.com> wrote:
>> 
>>  
>> 
>>> sujay wrote:
>>> 
>>>    
>>> 
>>>> Padma,
>>>> I do see an inter-op issue for a simple scenario.
>>>> 
>>>> Where the restarting router has assumed the helpers
>>>> have a incremented the lease period to (x+y) , whereas
>>>> one helper has not, but it could have, provided the behaviour was
>>>> defined.
>>>> 
>>>> 
>>>>      
>>>> 
>>> IMHO, it should not assume that.
>>>    
>>> 
>> 
>> Well the reason for restarting router to send two grace LSAs would be to
>> inform its neighbors to increase its restart interval. If such use of grace
>> LSAs is not recommended it should be clearly specified otherwise the results
>> in such a case will become implementation dependent.
>> 
>> - Hasmit
>> 
>>  
>> 
> Hi Hasmit
> 
> I actually don't buy into the argument that the implementation needs
> more time - if you want to be
> safe configure the maximum time allowed and any good implementation
> should get out of GR asap
> on success. This looks more like an operational/usage misconfig to me.
> 

I agree that we should not extend the grace interval on receiving multiple
grace LSAs. I wanted to make sure that this fact is documented so that all
implementations conform to this behavior and we don't have any future
interop issues.

- Hasmit


> Padma
> 
>>>> Results in a pre-mature exit -gr condition for the sole reason of an
>>>> undefined
>>>> behavior.
>>>> 
>>>> Please correct me.
>>>> 
>>>> Regds,
>>>> Sujay G
>>>> My Location;
>>>> http://maps.google.com/maps?ll=14.626109,76.959229&spn=4.724852,7.525085
>>>> &t=h&hl=en
>>>> 
>>>> 
>>>> This e-mail and attachments contain confidential information from
>>>> HUAWEI, which is intended only for the person or entity whose address is
>>>> listed above. Any use of the information contained herein in any way
>>>> (including, but not limited to, total or partial disclosure,
>>>> reproduction, or dissemination) by persons other than the intended
>>>> recipient's) is prohibited. If you receive this e-mail in error, please
>>>> notify the sender by phone or email immediately and delete it!
>>>> 
>>>> -----Original Message-----
>>>> From: Padma Pillay-Esnault [mailto:ppe at cisco.com]
>>>> Sent: Friday, June 30, 2006 1:19 PM
>>>> To: Ashok Chandrashekar Holla
>>>> Cc: ospf at ietf.org
>>>> Subject: Re: [OSPF] Query regarding grace-period in Garceful-restart
>>>> 
>>>> 
>>>> Ashok Chandrashekar Holla wrote:
>>>> 
>>>> 
>>>> 
>>>>      
>>>> 
>>>>> Padma Pillay-Esnault wrote:
>>>>> 
>>>>>   
>>>>> 
>>>>>        
>>>>> 
>>>>>> Vishwas Manral wrote:
>>>>>> 
>>>>>>     
>>>>>> 
>>>>>>          
>>>>>> 
>>>>>>> Hi Acee,
>>>>>>> 
>>>>>>> Good point. More than rate limit, I prefer a hardlimit on the total
>>>>>>> number of such LSA's that can be received, as well as some bounded
>>>>>>> maximum value of time for which hitless restart can go on.
>>>>>>> 
>>>>>>>       
>>>>>>> 
>>>>>>>            
>>>>>>> 
>>>>>> Vishwas
>>>>>> 
>>>>>> I am in favor of having a max number of Grace LSA that can be
>>>>>> received ( from 0 - meaning no other grace lsa is accepted once a
>>>>>> helper received and initiated helping) The maximum value of time a GR
>>>>>>     
>>>>>> 
>>>>>>          
>>>>>> 
>>>> 
>>>> 
>>>>      
>>>> 
>>>>>> can go is anyway going to be 1hr assuming that you do not have DNA
>>>>>> lsas and DC configured.
>>>>>> 
>>>>>> Padma
>>>>>> 
>>>>>>     
>>>>>> 
>>>>>>          
>>>>>> 
>>>>> Actually, I think the 1800 seconds/{configuration defined Max
>>>>> Grace-period on Helper} will suffice to avoid any such problems.
>>>>> The overall grace-period (sum of initial advertisement and all
>>>>> subsequent extensions) should continue to be less than
>>>>> 1800/{configuration limit of Grace period on Helper}.There is no need
>>>>> for a LSA number/rate limit.
>>>>> But, I am wondering whether the RFC, in its current wording, is clear
>>>>> enough to avoid inter-op issues w.r.t to interpretation of the length
>>>>> of grace-period in the case of multiple Grace LSAs..
>>>>> -Ashok
>>>>>   
>>>>> 
>>>>>        
>>>>> 
>>>> I think the RFC is vague enough to allow people to tailor their
>>>> implementations and I don't think that
>>>> there is an interoperability problem per se.
>>>> This is also an internal implemental decision of the helper which
>>>> already has a number of possible
>>>> configs - when to accept to help for example.
>>>> 
>>>> Padma
>>>> 
>>>> 
>>>> 
>>>>      
>>>> 
>>>>>>> Thanks,
>>>>>>> Vishwas
>>>>>>> 
>>>>>>> On 6/30/06, Acee Lindem <acee at cisco.com> wrote:
>>>>>>> 
>>>>>>>       
>>>>>>> 
>>>>>>>            
>>>>>>> 
>>>>>>>> Hi Ashok,
>>>>>>>> 
>>>>>>>> When you accept the new grace LSA as specified in RFC 3623, you'll
>>>>>>>> update
>>>>>>>> your restart timer to the new value (option 3) as specified above.
>>>>>>>>         
>>>>>>>> 
>>>>>>>>           
>>>>>>>> 
>>>> I
>>>> 
>>>> 
>>>>      
>>>> 
>>>>>>>> guess "updated
>>>>>>>> accordingly" could have been more precisely defined.
>>>>>>>> 
>>>>>>>> Hi Don,
>>>>>>>> 
>>>>>>>> When the new grace LSA is originated and the grace interval is
>>>>>>>> different, the checksum will be different (irrespective of the
>>>>>>>> sequence number) and one
>>>>>>>> of the two LSAs (new or previous) will be more recent. Normal RFC
>>>>>>>>         
>>>>>>>> 
>>>>>>>>           
>>>>>>>> 
>>>> 2328
>>>> 
>>>> 
>>>>      
>>>> 
>>>>>>>> processing deals with both cases.  However, anytime the contents
>>>>>>>> of any LSA
>>>>>>>> changes the originator should bump the sequence #.
>>>>>>>> 
>>>>>>>> Implementation Note: I do see the possibility of a DOS attack by a
>>>>>>>> restarting router that keeps changing it's restart interval. You
>>>>>>>> may want to do some
>>>>>>>> rate limit.
>>>>>>>> 
>>>>>>>> Hope this helps,
>>>>>>>> Acee
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Ashok Chandrashekar Holla wrote:
>>>>>>>> 
>>>>>>>>         
>>>>>>>> 
>>>>>>>>           
>>>>>>>> 
>>>>>>>>> Don,
>>>>>>>>> 
>>>>>>>>> In my case, the Grace LSA would be a new instance, with an
>>>>>>>>> incremented/higher sequence number. This scenario is theoretical,
>>>>>>>>>          
>>>>>>>>> 
>>>>>>>>>          
>>>>>>>>> 
>>>>>>>> but
>>>>>>>>         
>>>>>>>> 
>>>>>>>>           
>>>>>>>> 
>>>>>>>>> I am considering handling it for an implementation.
>>>>>>>>> 
>>>>>>>>> Best,
>>>>>>>>> Ashok
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Don Goodspeed wrote:
>>>>>>>>> 
>>>>>>>>>          
>>>>>>>>> 
>>>>>>>>>          
>>>>>>>>> 
>>>>>>>>>> Ashok, Padma,
>>>>>>>>>> 
>>>>>>>>>> I see a case where a router has restarted in between but did not
>>>>>>>>>>         
>>>>>>>>>> 
>>>>>>>>>>         
>>>>>>>>>> 
>>>> 
>>>> 
>>>>      
>>>> 
>>>>>>>>>> maintain the timer it had prior to the restart so it sent the
>>>>>>>>>> configured value (say 200) again after coming back online.
>>>>>>>>>> 
>>>>>>>>>> I'd be curious to know if the sequence # is the same or has
>>>>>>>>>> incremented in Ashok's case (real or theoretical).
>>>>>>>>>> 
>>>>>>>>>> -don
>>>>>>>>>> 
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Ashok Chandrashekar Holla [mailto:ashok_ch at huawei.com]
>>>>>>>>>> Sent: Wednesday, June 28, 2006 9:55 PM
>>>>>>>>>> To: Padma Pillay-Esnault
>>>>>>>>>> Cc: ospf at ietf.org
>>>>>>>>>> Subject: Re: [OSPF] Query regarding grace-period in
>>>>>>>>>>         
>>>>>>>>>> 
>>>>>>>>>>         
>>>>>>>>>> 
>>>>>>>> Garceful-restart
>>>>>>>>         
>>>>>>>> 
>>>>>>>>           
>>>>>>>> 
>>>>>>>>>> Padma Pillay-Esnault wrote:
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>         
>>>>>>>>>> 
>>>>>>>>>>         
>>>>>>>>>> 
>>>>>>>>>>> Ashok
>>>>>>>>>>> 
>>>>>>>>>>> Ashok Chandrashekar Holla wrote:
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>        
>>>>>>>>>>> 
>>>>>>>>>>>        
>>>>>>>>>>> 
>>>>>>>>>>>> Or,
>>>>>>>>>>>> 3. Should it set it to a fresh value of 200s (which means that
>>>>>>>>>>>>       
>>>>>>>>>>>> 
>>>>>>>>>>>>       
>>>>>>>>>>>> 
>>>>>>>> the
>>>>>>>>         
>>>>>>>> 
>>>>>>>>           
>>>>>>>> 
>>>>>>>>>>>> effective grace-period is 230s)?
>>>>>>>>>>>> 
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Ashok
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Ashok Chandrashekar Holla wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>       
>>>>>>>>>>>> 
>>>>>>>>>>>>       
>>>>>>>>>>>> 
>>>>>>>>>>>> Group,
>>>>>>>>>>>> 
>>>>>>>>>>>> I have a doubt regarding the grace-period interpretation in
>>>>>>>>>>>>       
>>>>>>>>>>>> 
>>>>>>>>>>>>       
>>>>>>>>>>>> 
>>>>>>>> RFC 3623.
>>>>>>>>         
>>>>>>>> 
>>>>>>>>           
>>>>>>>> 
>>>>>>>>>>>> If a helper initially received the GR request with
>>>>>>>>>>>> grace-period 100s, and after 30s, receives a new Grace-LSA
>>>>>>>>>>>> with grace-period 200, what should the effective grace-period
>>>>>>>>>>>>       
>>>>>>>>>>>> 
>>>>>>>>>>>>       
>>>>>>>>>>>> 
>>>> 
>>>> 
>>>>      
>>>> 
>>>>>>>>>>>> be?
>>>>>>>>>>>> 
>>>>>>>>>>>>       
>>>>>>>>>>>> 
>>>>>>>>>>>>       
>>>>>>>>>>>> 
>>>>>>>>>>>>       
>>>>>>>>>>>> 
>>>>>>>>>>>>       
>>>>>>>>>>>> 
>>>>>>>>>>> In what type of scenario will it happen ?
>>>>>>>>>>> 
>>>>>>>>>>> Padma
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>        
>>>>>>>>>>> 
>>>>>>>>>>>        
>>>>>>>>>>> 
>>>>>>>>>> Hi Padma,
>>>>>>>>>> The above case will occur when the administrator (or OSPF
>>>>>>>>>> software) initially chose the grace-period to be small. Later,
>>>>>>>>>> realizing that all adjacencies cannot be rebuilt within this
>>>>>>>>>> time, requested
>>>>>>>>>>         
>>>>>>>>>> 
>>>>>>>>>>         
>>>>>>>>>> 
>>>>>>>> for an
>>>>>>>>         
>>>>>>>> 
>>>>>>>>           
>>>>>>>> 
>>>>>>>>>> extension of the grace-period.
>>>>>>>>>> 
>>>>>>>>>> In such cases, how will the new instance of Grace LSA be
>>>>>>>>>>         
>>>>>>>>>> 
>>>>>>>>>>         
>>>>>>>>>> 
>>>>>>>> interpreted
>>>>>>>>         
>>>>>>>> 
>>>>>>>>           
>>>>>>>> 
>>>>>>>>>> by the helper?
>>>>>>>>>> I feel the RFC defaults implicitly to the 3rd option (listed
>>>>>>>>>> above) where the helper resets the Grace-period to the new value
>>>>>>>>>>         
>>>>>>>>>> 
>>>>>>>>>>         
>>>>>>>>>> 
>>>> 
>>>> 
>>>>      
>>>> 
>>>>>>>>>> and
>>>>>>>>>>         
>>>>>>>>>> 
>>>>>>>>>>         
>>>>>>>>>> 
>>>>>>>> ignores
>>>>>>>>         
>>>>>>>> 
>>>>>>>>           
>>>>>>>> 
>>>>>>>>>> the time period that has already elapsed since the original
>>>>>>>>>>         
>>>>>>>>>> 
>>>>>>>>>>         
>>>>>>>>>> 
>>>>>>>> request.
>>>>>>>>         
>>>>>>>> 
>>>>>>>>           
>>>>>>>> 
>>>>>>>>>> Am I correctly interpreting the RFC?
>>>>>>>>>> 
>>>>>>>>>> Regards,
>>>>>>>>>> Ashok
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>         
>>>>>>>>>> 
>>>>>>>>>>         
>>>>>>>>>> 
>>>>>>>>>>>> 1. Should the helper set the grace-period to 200s, of which
>>>>>>>>>>>> 30s have already elapsed? 2. Should the grace-period be 300s
>>>>>>>>>>>> (previous 100s + extended 200s), of which 30s have already
>>>>>>>>>>>> elapsed?
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Ashok
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> OSPF mailing list
>>>>>>>>>>>> OSPF at ietf.org https://www1.ietf.org/mailman/listinfo/ospf
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>       
>>>>>>>>>>>> 
>>>>>>>>>>>>       
>>>>>>>>>>>> 
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> OSPF mailing list
>>>>>>>>>>>> OSPF at ietf.org
>>>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/ospf
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>       
>>>>>>>>>>>> 
>>>>>>>>>>>>       
>>>>>>>>>>>> 
>>>>>>>>>> _______________________________________________
>>>>>>>>>> OSPF mailing list
>>>>>>>>>> OSPF at ietf.org
>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/ospf
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>         
>>>>>>>>>> 
>>>>>>>>>>         
>>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> OSPF mailing list
>>>>>>>>> OSPF at ietf.org
>>>>>>>>> https://www1.ietf.org/mailman/listinfo/ospf
>>>>>>>>> 
>>>>>>>>>          
>>>>>>>>> 
>>>>>>>>>          
>>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> OSPF mailing list
>>>>>>>> OSPF at ietf.org
>>>>>>>> https://www1.ietf.org/mailman/listinfo/ospf
>>>>>>>> 
>>>>>>>>         
>>>>>>>> 
>>>>>>>>           
>>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> OSPF mailing list
>>>>>>> OSPF at ietf.org
>>>>>>> https://www1.ietf.org/mailman/listinfo/ospf
>>>>>>> 
>>>>>>>       
>>>>>>> 
>>>>>>>            
>>>>>>> 
>>>>>> _______________________________________________
>>>>>> OSPF mailing list
>>>>>> OSPF at ietf.org
>>>>>> https://www1.ietf.org/mailman/listinfo/ospf
>>>>>> 
>>>>>>     
>>>>>> 
>>>>>>          
>>>>>> 
>>>> _______________________________________________
>>>> OSPF mailing list
>>>> OSPF at ietf.org
>>>> https://www1.ietf.org/mailman/listinfo/ospf
>>>> 
>>>> 
>>>> 
>>>>      
>>>> 
>>> _______________________________________________
>>> OSPF mailing list
>>> OSPF at ietf.org
>>> https://www1.ietf.org/mailman/listinfo/ospf
>>>    
>>> 
>> 
>> 
>>  
>> 
> 

_______________________________________________
OSPF mailing list
OSPF at ietf.org
https://www1.ietf.org/mailman/listinfo/ospf