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

[Vishwas Manral <[e-mail]>]

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
>>>>>
>>>
>>>
>
>