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

[David Ward <[e-mail]>]

V -

The method to detect persistent congestion will have enough rules for  
the BFD packet loss over a stated interval. A system can only usefully  
detect in the rx direction.

-DWard


On Jul 20, 2009, at 4:21 PM, Vishwas Manral wrote:

> Hi David,
>
> Thanks for sharing the updates with us.
>
> So is the mechanism to do detect 'persistent congestion' also
> mentioned, or is that left out of scope. Also during congestion do we
> increase the 'Minimum receive interval' or the 'transmit interval' or
> both. So can the congestion assumed to be in both directions or only
> in the direction of the incoming flow?
>
> Thanks again,
> Vishwas
>
> On Thu, Jul 16, 2009 at 5:42 PM, David Ward<[e-mail]> wrote:
>> 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
>>>>
>>
>>