Re: draft-palanivelan-bfd-v2-gr-02

[David Ward <[e-mail]>]

One change to the BFD base spec as requested by the IESG is a  
congestion control mechanism. We've come to conclusion with the  
transport, internet and routing ADs on the algorithm and you will see  
it in the last rev of the base spec. In a very short summary, if one  
can detect that there is persistent congestion then use the adaptive  
timers to send fewer packets and see if the congestion clears. Then  
ramp them back up slowly until self-stabilized and no observable,  
persistent congestion is detected.

In the case described below, there doesn't need to be protocol  
extensions to cover this issue.  There are many ways system design  
choices can impact your implementation.

-DWard

On Jul 16, 2009, at 11:40 AM, Vishwas Manral wrote:

> Hi A. Palanivelan,
>
> I agree with Nitin here. If BFD packets are not prioritized over
> others, we need to fix that instead of any other changes.
>
> Thanks,
> Vishwas
>
> On Thu, Jul 16, 2009 at 8:49 AM, Nitin Bahadur<[e-mail]>  
> wrote:
>> Hi,
>>
>>      I would think that if there are multiple things happening at  
>> the same time...then the system needs to prioritize
>> BFD over other things in some way or offload bfd to some place that  
>> would prevent bfd from getting affected.
>>
>> Thanks
>> Nitin
>>
>> On 7/16/09 2:11 AM, "Palanivelan A (apvelan)" <[e-mail]>  
>> wrote:
>>
>> Hi Nitin,
>> It is very true that BFD works well in planned restarts and we  
>> don't need GR extensions there.
>> But, we have seen issues when bfd is working along with other time  
>> intensive, high priority events.
>>
>> In such a scenario, for GR, we are likely to hit bfd timer expiry  
>> which will be treated as a failure, thus bringing down the  
>> adjacencies (ISIS/OSPF).
>> One such example is when there are scaled number of PPPoE sessions  
>> on a SP router that also has bfd enabled (with strict timers).
>>
>> This would mean looking for a workaround at the architecture level  
>> of your router to make this work.
>>
>> In fact, this sort of experience let me into writing this draft.
>> Do revert back for more discussion.
>> PS: sorry for that late reply. I had a recent road accident that  
>> put me off for a longer time.
>> Regards,
>> A.Palanivelan
>> To: <apvelan at cisco.com <mailto:[e-mail]> >, <rtg- 
>> bfd at ietf.org <mailto:[e-mail]> >
>>
>> ________________________________
>>
>> Hi,
>>
>>  You really do not need GR extensions to BFD to help with
>> planned restart. There is enough text in draft-ietf-bfd-generic
>> (Section 4.3.2.2) to help you accomplish what you want.
>>
>>  At the top of my head, I can think of 2 ways:
>>
>> 1) Restarting router brings down BFD session with diag code of
>>   ADMIN_DOWN. ADMIN_DOWN should not bring down the adjacency
>>   on the peer. So the peer BFD session will go down but ISIS/OSPF
>>   will not treat it as an adjacency down event.
>>
>> 2) Restarting router increases the BFD session timer to XXX
>>   seconds (XXX > restart time). It can save some state locally
>>   to note this. After restart, the restarting router reads the local
>>   state and continues the BFD session from the UP state.
>>
>> Thanks
>> Nitin
>>