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

From: Pablo Frank <[email-masked]>
Date: Wed, 8 Aug 2012 17:38:09 -0400

Hi Marc,

Thanks for considering my comments.

See additional comments below PF>>

On Tue, Jul 31, 2012 at 6:57 PM, Marc Binderberger <[email-masked]> wrote:

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

PF>> I think the main issue I have with 20msec is that it doesn't
necessarily meet any particular application requirement.  It is likely too
slow to be useful for sub 50msec protection-switching.  For customers who
require sub-50ms protection-switching, this is a hard requirement and they
will test for it.  Being 50ms-ish is usually not good enough, especially
when one considers that this is supposed to include restoration time as
well as propagation delay over long links.  I'm vary wary of adding
normative text that requires hardware implementations to support additional
intervals, especially if that increases the cost of such solutions.

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

PF>> Strictly speaking, you have interoperability, just not at the desired
rates.  But this strikes me as a nice-to-have as opposed to a mandatory
requirement.  I think there's some need to specify minimum requirements
that have clear application needs (such as 3.3/10ms for
protection-switching, 100ms for performance-monitoring, etc.) but the
remaining proposed rates can probably be specified as SHOULD/RECOMMENDED
requirements.

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

PF>>  Be careful with the assumption that "slow" rates like 50ms or 300ms
is not imposing a requirement on hardware.  If you work on very large
devices which are dealing with thousands and tens of thousands of tunnels,
even a rate like 50ms / 300ms will require hardware to achieve scale.  This
is precisely what worries me, in fact.

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

PF>>  Yes, the 0.5 that I'm adding is definitely trying to recognize the
reality that I've seen in a lot of hardware implementations.  A typical
hardware implementation does not use dedicated cancellable one-shot timers.
 For example, a typical implementation uses a sliding window to keep track
of how many CCs have been received within a set of intervals.  This will
lead to some inaccuracy but the inaccuracy is well bounded.  802.1ag
recognized this reality and even has normative text requiring that an
implementation must detect discontinuity between 3.25 and 3.5 x the CCM
interval.

RFC 6371 (which I admit is NOT normative) makes a similar suggestion of
waiting until 3.5 CC intervals have passed before declaring a defect.  IMO,
none of this necessarily conflicts with the text that you've cited.  The
'detection time' is the definition for a timer and, technically, RFC 5880
has no normative text describing how quickly an implementation must respond
to the expiry of this timer.  Probably, when the spec was originally
written, responsiveness of timers was considered a negligible/irrelevant
factor.  But as we push the speed limits of software (and hardware), this
is no longer negligible.  For example, I've seen a few software
implementations that claim 10ms CC intervals but when said implementations
are hit by a storm of say, 1000 tunnels failing, the 1000th timer expiry is
certainly not handled immediately.  Even for a small number of failures,
such implementations have difficulty responding without some significant
slip.

Perhaps it's worth having your draft attempt to specify such timer
responsiveness requirements?  This could also help in improving
interoperability.

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

PF>> I'm ambivalent about any interval larger than 1s since I have a hard
time imagining that such intervals would ever be implemented in hardware
(famous last words).  However, since the focus of your draft is
interoperability, specifying these larger intervals and making them
consistent with 802.1ag seems like it might be useful.

cheers,
Pablo

>
> 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<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:
>
>> 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.
>>>
>>> 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]>
>>>
>>>
>>
>
> --
> Marc Binderberger           <[email-masked]>
>
>