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

[David Ward <[e-mail]>]

Could be both, directions are negotiated separately. What should be  
obvious is that it is impossible to tell what sort of congestion is  
being witnessed. Could be on the wire, could be a scheduler (if SW  
based implementation) ... either way, response is the same.

-DWard

On Jul 20, 2009, at 7:01 PM, Vishwas Manral wrote:

> Hi David,
>
> Thats correct, detection can only be done in the rx direction.
>
> But reaction can be to slow the rate of packet send/ receive or both.
> I was wondering what would be the suggested action?
>
> Thanks,
> Vishwas
>
> On Mon, Jul 20, 2009 at 3:33 PM, David Ward<[e-mail]> wrote:
>>
>> 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
>>>>>>
>>>>
>>>>
>>
>>