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

[Vishwas Manral <[e-mail]>]

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