Subject: Fwd: I-D Action: draft-akiya-bfd-intervals-03.txt

From: Marc Binderberger <[email-masked]>
Date: Mon, 16 Jul 2012 12:31:49 +0200

Hello BFD experts,

Nobo and me have uploaded a new version of draft-akiya-bfd-intervals, mainly fixing some typos and adding one clarification.

We received (unicast) several feedbacks, in general positive. What still may require a closer look is:

(i)  the set of Standard Interval values

(ii) the Poll/Final sequence example in Appendix B

Thanks & Regards,
Marc

Begin forwarded message:

> From: [email-masked]
> Date: July 16, 2012 12:25:32 GMT+02:00
> To: [email-masked]
> Subject: I-D Action: draft-akiya-bfd-intervals-03.txt
> Reply-To: [email-masked]
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title           : Standardized interval support in BFD
> 	Author(s)       : Nobo Akiya
>                          Marc Binderberger
> 	Filename        : draft-akiya-bfd-intervals-03.txt
> 	Pages           : 8
> 	Date            : 2012-07-16
> 
> Abstract:
>   This document defines a set of interval values that we call "Standard
>   intervals".  Values of this set must be supported for transmitting
>   BFD control packets and for calculating the detection time in the
>   receive direction when the value is equal or larger than the fastest,
>   i.e. lowest, interval a particular BFD implementation supports.
> 
>   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.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-akiya-bfd-intervals
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-akiya-bfd-intervals-03
> 
> A diff from previous version is available at:
> http://tools.ietf.org/rfcdiff?url2=draft-akiya-bfd-intervals-03
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 

--
Marc Binderberger           <[email-masked]>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 24 Jul 2012 16:34:16 -0700

Hi Marc, et al.,
I think I'd refer to the set of timer values defined in the
draft-akiya-bfd-intervals as 'Minimally Required Set" rather than as
"Standard".
Second, 3.3 ms interval included in the set for the benefit of MPLS-TP. I'd
note that OAM for packet transport networks would likely to use from set of
intervals defined in IEEE 802.1ag/Y.1731, i.e. [3.3 ms, 10 ms, 100 ms, 1
sec, 10 sec, 1 min, 10 min]. To make two sets more compatible, I propose to
include 100 ms interval into the Minimally Required Set that proposed in
the draft.

Regards,
Greg

On Mon, Jul 16, 2012 at 3:31 AM, Marc Binderberger <[email-masked]> wrote:

> Hello BFD experts,
>
> Nobo and me have uploaded a new version of draft-akiya-bfd-intervals,
> mainly fixing some typos and adding one clarification.
>

---

From: Pablo Frank <[email-masked]>
Date: Tue, 31 Jul 2012 17:28:28 -0400

I'd like to echo Greg's suggestion that we should align the minimum set of
required rates against 802.1ag/Y.1731.  However, I'd like to make the
argument that you should consider *removing* some of the rates suggested in
the draft.  In my mind, the main value in this draft specifying a minimum
set of supported intervals is really to set minimum standards for hardware
implementations.  Software implementations of BFD will typically have the
ability to be very flexible above a certain point.  In other words, a
software implementation that can minimally support 100ms intervals can
likely support nearly any rate that is slower than 100ms.  OTOH, hardware
implementations tend to be fairly restricted in the number of high-speed
rates that they can support.  I've seen merchant silicon implementations
that can really only do 3 or 4 "fast" rates (i.e. <1pps).  Specifying too
many rates will likely increase the cost of these solutions and we should
only do this if there is a strong use-case to justify pushing these
requirements on silicon vendors.

In terms of the suggested rates, both 3.3ms and 10ms are rates suggested
for CC/CV for MPLS-TP in RFC
6371<http://tools.ietf.org/html/rfc6371#section-5.1.3> to
support protection-switching so should be included in the minimum set.  The
draft suggests 20ms (or 15ms) as another rate that can support 50ms
switchovers but this is impractical since worst-case detection time for
faults using 20ms CC/CV is 2.5 x 20ms = 50ms, which leaves you essentially
no time to perform the actual switchover.

The draft also suggests 50ms as a rate that some software implementations
can achieve.  IMHO, this is irrelevant.  There are probably software
implementations that could also achieve 25ms or even 10ms.  That doesn't
seem to be a good reason to add it to the list.  AFAIK, there is no
application that really benefits from 50ms CC/CV that would not be
adequately served by 100ms.  50ms CC/CV certainly won't achieve 50ms
protection switching times, even with a defect multiplier of 1.

As Greg suggests, we should certainly add 100ms to the list.  RFC 6371 also
lists 100ms as a rate that is useful to support performance-monitoring
applications in MPLS-TP networks.  It's worth noting that hardware that
does periodic LM/DM will often share common timer infrastructure with CC/CV
so it's good to align on these rates.  1s is also called out by RFC 6371.

The draft also suggests 300ms to support VOIP applications that require <1s
detection time.  But this makes the same erroneous assumption as the 20ms
rate.  With a 300ms CC/CV interval and a defect multiplier of 3,
defect-entry can occur as late as 3.5 x 300ms = 1050ms which violates the
1s requirement.  I would suggest that the 100ms interval can probably serve
this application just fine.  But it would be good to get the opinions of
any VOIP experts on the list.

In summary, I would suggest 3.3ms, 10ms, 100ms, and 1s as the minimal set.
 I would delete 20ms, 50ms, and 300ms.

regards,
Pablo

On Tue, Jul 24, 2012 at 7:34 PM, Greg Mirsky <[email-masked]> wrote:

> Second, 3.3 ms interval included in the set for the benefit of MPLS-TP.
> I'd note that OAM for packet transport networks would likely to use from
> set of intervals defined in IEEE 802.1ag/Y.1731, i.e. [3.3 ms, 10 ms, 100
> ms, 1 sec, 10 sec, 1 min, 10 min]. To make two sets more compatible, I
> propose to include 100 ms interval into the Minimally Required Set that
> proposed in the draft.
>
> Regards,
> Greg
>
>

---

From: Marc Binderberger <[email-masked]>
Date: Wed, 1 Aug 2012 00:57:37 +0200

Hello Greg and Pablo,

sorry for the late reply, simply busy. And thanks for the feedback!

I'm perfectly fine adding the 100msec. For removing the 300msec, true that 3 x 300msec or 9 x 100msec should cover the same scenarios. I hope that we get some more feedback from vendors (not just routers) if we can drop 300msec.

I do not agree with the sparse list with the large jump from 10msec to 100msec, even if IEEE does. Reality is not black/white and being close to 50-60msec detection time is still better than being off like 200-300msec. Thus the 20msec. It was actually this gap that motivated us writing this draft :-)

> The draft also suggests 50ms as a rate that some software implementations can achieve.  IMHO, this is irrelevant.

With 20msec and 100msec available one may replace 50msec in terms of dection time. On the other hand 50msec is a value I've seen quite often, i.e. it's not irrelevant. This draft is about interoperability in the sense that existing/older software-based implementations can peer with silicon-based BFD while largely maintaining the existing detection times. But again, the discussion just started.

> I've seen merchant silicon implementations that can really only do 3 or 4 "fast" rates

fair point, on the other hand BFD solutions and thus "typical" timer values are out in the world and the silicon vendors are not reinventing BFD. Plus you can use silicon for the really fast BFD and use cheaper software for the not-so-fast timers.

But to find the balance is what this discussion is for :-) 

Regarding the additional ".5" in your detection time calculation, while I guess I understand this from a hardware implementation point of view I somewhat disagree. From RFC5880:

6.8.4.  Calculating the Detection Time
	[...]
   In Asynchronous mode, the Detection Time calculated in the local
   system is equal to the value of Detect Mult received from the remote     
   system, multiplied by the agreed transmit interval of the remote
   system (the greater of bfd.RequiredMinRxInterval and the last
   received Desired Min TX Interval).

So  M * I (M: remote Multiplier, I: remote agreed transmit interval) should be your upper limit until when you have detected that the link or TP tunnel is interrupted. (M-1) * I would be the lower boundary.

For the larger values that Greg mentioned (10 sec, 1 min, 10 min)  I still have to give this a thought. Larger timer (and multiplier) values are one way to achieve "graceful restart" for BFD and I've heard about interop problems with it as well, so maybe worthwhile to cover in this draft as well.

Anyway, thanks again for the feedback and opinion!

Regards, Marc

On 2012-07-31, at 23:28 , Pablo Frank wrote:

> I'd like to echo Greg's suggestion that we should align the minimum set of required rates against 802.1ag/Y.1731.  However, I'd like to make the argument that you should consider *removing* some of the rates suggested in the draft.  In my mind, the main value in this draft specifying a minimum set of supported intervals is really to set minimum standards for hardware implementations.  Software implementations of BFD will typically have the ability to be very flexible above a certain point.  In other words, a software implementation that can minimally support 100ms intervals can likely support nearly any rate that is slower than 100ms.  OTOH, hardware implementations tend to be fairly restricted in the number of high-speed rates that they can support.  I've seen merchant silicon implementations that can really only do 3 or 4 "fast" rates (i.e. <1pps).  Specifying too many rates will likely increase the cost of these solutions and we should only do this if there is a strong use-case to justify pushing these requirements on silicon vendors.
> 
> In terms of the suggested rates, both 3.3ms and 10ms are rates suggested for CC/CV for MPLS-TP in RFC 6371 to support protection-switching so should be included in the minimum set.  The draft suggests 20ms (or 15ms) as another rate that can support 50ms switchovers but this is impractical since worst-case detection time for faults using 20ms CC/CV is 2.5 x 20ms = 50ms, which leaves you essentially no time to perform the actual switchover.  
> 
> The draft also suggests 50ms as a rate that some software implementations can achieve.  IMHO, this is irrelevant.  There are probably software implementations that could also achieve 25ms or even 10ms.  That doesn't seem to be a good reason to add it to the list.  AFAIK, there is no application that really benefits from 50ms CC/CV that would not be adequately served by 100ms.  50ms CC/CV certainly won't achieve 50ms protection switching times, even with a defect multiplier of 1.
> 
> As Greg suggests, we should certainly add 100ms to the list.  RFC 6371 also lists 100ms as a rate that is useful to support performance-monitoring applications in MPLS-TP networks.  It's worth noting that hardware that does periodic LM/DM will often share common timer infrastructure with CC/CV so it's good to align on these rates.  1s is also called out by RFC 6371.
> 
> The draft also suggests 300ms to support VOIP applications that require <1s detection time.  But this makes the same erroneous assumption as the 20ms rate.  With a 300ms CC/CV interval and a defect multiplier of 3, defect-entry can occur as late as 3.5 x 300ms = 1050ms which violates the 1s requirement.  I would suggest that the 100ms interval can probably serve this application just fine.  But it would be good to get the opinions of any VOIP experts on the list.
> 
> In summary, I would suggest 3.3ms, 10ms, 100ms, and 1s as the minimal set.  I would delete 20ms, 50ms, and 300ms.
> 
> regards,
> Pablo
> 
> I think I'd refer to the set of timer values defined in the draft-akiya-bfd-intervals as 'Minimally Required Set" rather than as "Standard".
> Second, 3.3 ms interval included in the set for the benefit of MPLS-TP. I'd note that OAM for packet transport networks would likely to use from set of intervals defined in IEEE 802.1ag/Y.1731, i.e. [3.3 ms, 10 ms, 100 ms, 1 sec, 10 sec, 1 min, 10 min]. To make two sets more compatible, I propose to include 100 ms interval into the Minimally Required Set that proposed in the draft.
> 
> Regards,
> Greg
> 
>