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

From: Nitin Bahadur <[email-masked]>
Date: Thu, 16 Jul 2009 08:49:13 -0700

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)" <[email-masked]> 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:[email-masked]> >, <rtg-bfd at ietf.org <mailto:[email-masked]> >

________________________________

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

---

From: "Palanivelan A (apvelan)" <[email-masked]>
Date: Thu, 16 Jul 2009 22:00:58 +0530

Nitin,

That's right and system need to prioritize BFD and how easy or how
difficult that would be is dependent on the system's design
and that is why if bfd as a standard, could provide a easier way out, I
guess implementers would prefer it.

Also, we cannot always set bfd the highest priority and there would be
always be certain events that need to have a higher priority.
I have tried explaining that in the draft.

Thanks and Regards,
A.Palanivelan 

-----Original Message-----
From: Nitin Bahadur [mailto:[email-masked]] 
Sent: Thursday, July 16, 2009 9:19 PM
To: Palanivelan A (apvelan); [email-masked]
Subject: Re: draft-palanivelan-bfd-v2-gr-02

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

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:[email-masked]> >, <rtg-bfd at
ietf.org <mailto:[email-masked]> >

Hi,

Thanks
Nitin

---

From: Vishwas Manral <[email-masked]>
Date: Thu, 16 Jul 2009 09:40:40 -0700

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

---

From: "Palanivelan A (apvelan)" <[email-masked]>
Date: Thu, 16 Jul 2009 22:22:39 +0530

Hi Vishwas,

Like I have explained in section 3.2, a SP responding to a session renewal request from the subscribers 
will be the highest priority and when this happens during a GR, and with scaled subscribers(very likely in real scenario),
implementers need to look at other ways to prevent bfd from getting affected.

And again don't you think a standards way of handling this scenario would benefit the customers, using equipments from multiple vendors.

Thanks and Regards,
A.Palanivelan

-----Original Message-----
From: Vishwas Manral [mailto:[email-masked]] 
Sent: Thursday, July 16, 2009 10:11 PM
To: Nitin Bahadur
Cc: Palanivelan A (apvelan); [email-masked]
Subject: Re: draft-palanivelan-bfd-v2-gr-02

Hi A. Palanivelan,

Thanks,
Vishwas

---

From: Vishwas Manral <[email-masked]>
Date: Thu, 16 Jul 2009 11:22:48 -0700

Hi A.Palanivel,

A simple solution to this is treat the session renewal trigger
messages as triggers for BFD to say that the peer is up. So whenever I
get a valid packet from the peer, treat it as if you got a valid BFD
packet (ofcourse you need to be careful when doing this - based on
your system).

Thanks,
Vishwas

---

From: Satyam Sinha <[email-masked]>
Date: Thu, 16 Jul 2009 16:49:40 -0700

Hi,

As Nitin explained, the base draft can support this functionality. If we add the new "easier" ways, others will have to implement it as well for no potential benefit as their architecture can take care of the prioritizing.

I think this is a system architecture issue and so we should make minor changes to the architecture as opposed to changing the standard.

Regards,

Satyam  

> Subject: RE: draft-palanivelan-bfd-v2-gr-02
> Date: Thu, 16 Jul 2009 22:22:39 +0530
> From: [email-masked]
> To: [email-masked]; [email-masked]
> CC: [email-masked]
> 
> Hi Vishwas,
> 

_________________________________________________________________
Hotmail® has ever-growing storage! Don’t worry about storage limits. 
http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage_062009

---

From: David Ward <[email-masked]>
Date: Thu, 16 Jul 2009 19:42:01 -0500

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:

>>      I would think that if there are multiple things happening at  
>> the same time...then the system needs to prioritize
>> 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).
>>
>> To: <apvelan at cisco.com <mailto:[email-masked]> >, <rtg- 
>> bfd at ietf.org <mailto:[email-masked]> >
>>

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 20 Jul 2009 14:21:37 -0700

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<[email-masked]> 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
>
>>>     I would think that if there are multiple things happening at the same
>>> time...then the system needs to prioritize

---

From: David Ward <[email-masked]>
Date: Mon, 20 Jul 2009 17:33:50 -0500

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:

>> congestion
>> extensions to
>>>> the same
>>>> BFD over other things in some way or offload bfd to some place  
>>>> that would
>>>> prevent bfd from getting affected.
>>>>
>>>> Thanks
>>>> Nitin
>>>>
>>>> It is very true that BFD works well in planned restarts and we  
>>>> don't need
>>>> GR extensions there.
>>>> which
>>>> bfd at

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 20 Jul 2009 17:01:33 -0700

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<[email-masked]> 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
>
>
>>>>> same
>>>>> need

---

From: David Ward <[email-masked]>
Date: Mon, 20 Jul 2009 19:11:37 -0500

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:

>>>> 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
>>>> 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
>>>> extensions
>>>> to
>>>> cover this issue.  There are many ways system design choices can  
>>>> impact
>>>> your
>>>> implementation.
>>>>
>>>> -DWard
>>>>
>>>>>> the
>>>>>> that
>>>>>> don't