Subject: Re: I-D Action: draft-akiya-bfd-intervals-00.txt

From: Marc Binderberger <[email-masked]>
Date: Mon, 2 Apr 2012 11:29:36 +0200

Hello BFD experts,

Nobo and me would like to start a discussion about BFD interval values.

Many of you are about to implement BFD "in hardware", which typically means the periodic transmit and the timeout detection is done by some special processor to achieve more aggressive intervals and/or higher scale numbers. The gain in speed/scale comes with a price: the supported interval values are often less, either a few fixed values or a coarse granularity.

What we have seen in interop tests was that both systems ended up at the next-lowest interval both systems supported - and that was far away from the original, intended value. The submitted draft proposes to have some commonly supported interval values so the systems find an agreeable interval quick and at reasonable value.

Discussions are welcome! :-)

Best regards,
Marc & Nobo

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : Mandatory interval support in BFD
> 	Author(s)       : Nobo Akiya
>                          Marc Binderberger
> 	Filename        : draft-akiya-bfd-intervals-00.txt
> 	Pages           : 5
> 	Date            : 2012-04-02
> 
>   This document defines a set of interval values that must be supported
>   for transmitting BFD control packets and for calculating the
>   detection time in the receive direction.  Implementations are allowed
>   to define a lower limit for the interval so that only set values
>   equal or larger than the lower limit needs to be supported.
> 
>   This solves the problem of finding an interval value that both BFD
>   speakers can support while allowing a simplified implementation as
>   seen for hardware-based BFD.
> 
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-akiya-bfd-intervals-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-akiya-bfd-intervals-00.txt
> 

--
Marc Binderberger           <[email-masked]>

---

From: binny jeshan <[email-masked]>
Date: Mon, 2 Apr 2012 15:50:25 +0530

Hello Marc,

I may not have understood your draft full intentions, but AFAIK, most of
the device manufacturers who complies to BFD and supports it as a Fault
detection mechanism, will always support the industry required time
intervals, so as a fault is recovered quickly.

BUT, some device may not be able to give a requested time interval due to
any reason, depending on the situation that the
device sees. One example could be that if the device is already occupied
with more traffic, it may choose to offer a 30ms timer. rather than the
peer who is expecting a 10ms.

Moreover, the supported timer intervals of BFD is in the data sheet, and so
operator driven configurations should be made with attention. And IMHO i
think that any device manufacturer should be able to provide a timer
configuration that enables a <50 ms recovery time (a well known industry
expectation) along with the use of detect multiplier , and IMHO there need
not be any mandate for further support.

Thanks,
Binny J

On 2 April 2012 14:59, Marc Binderberger <[email-masked]> wrote:

> Many of you are about to implement BFD "in hardware", which typically
> means the periodic transmit and the timeout detection is done by some
> special processor to achieve more aggressive intervals and/or higher scale
> numbers. The gain in speed/scale comes with a price: the supported interval
> values are often less, either a few fixed values or a coarse granularity.
>
> What we have seen in interop tests was that both systems ended up at the
> next-lowest interval both systems supported - and that was far away from
> the original, intended value. The submitted draft proposes to have some
> commonly supported interval values so the systems find an agreeable
> interval quick and at reasonable value.
>
>

---

From: Marc Binderberger <[email-masked]>
Date: Mon, 2 Apr 2012 14:34:21 +0200

Hello Binny,

> will always support the industry required time intervals

that is exactly the point: there are no defined values. And as the draft in section 2 shows even when both vendors for themselves support reasonably fast values this still does not guarantee a fast detection time when they interop.

Btw, the example is section 2 was - with slightly different values - a real life experience. This is not academic.

I take your email as a feedback that the draft should be more explicit in mentioning this is about a problem between two different devices/vendors here. You won't see this between two devices of the same kind.

Thanks & Regards,
Marc

On 2012-04-02, at 12:20 , binny jeshan wrote:

> Hello Marc,
>  
> I may not have understood your draft full intentions, but AFAIK, most of the device manufacturers who complies to BFD and supports it as a Fault detection mechanism, will always support the industry required time intervals, so as a fault is recovered quickly.
>  
> BUT, some device may not be able to give a requested time interval due to any reason, depending on the situation that the
> device sees. One example could be that if the device is already occupied with more traffic, it may choose to offer a 30ms timer. rather than the peer who is expecting a 10ms.
>  
> Moreover, the supported timer intervals of BFD is in the data sheet, and so operator driven configurations should be made with attention. And IMHO i think that any device manufacturer should be able to provide a timer configuration that enables a <50 ms recovery time (a well known industry expectation) along with the use of detect multiplier , and IMHO there need not be any mandate for further support.
>  
> Thanks,
> Binny J
>