[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