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

From: Jeffrey Haas <[email-masked]>
Date: Fri, 4 May 2012 15:02:36 -0400

Marc,

On Thu, Apr 26, 2012 at 01:43:15AM +0200, Marc Binderberger wrote:
> after some feedback Nobo and me updated the document. We changed the wording from "Mandatory interval support" towards "Standardized interval support". The "Mandatory" was an unfortunate word choice and caused confusion; my apology for this.
> 
> We also added some clarifications.
> 
> To summarize this draft is about an interoperability problem between BFD speakers when the number of supported intervals is small, as it may happen with hardware-based BFD. Such implementations are more difficult to upgrade (or even impossible), compared to software on general-purpose CPU, thus the attempt to avoid a foreseeable problem.
> 
> 
> Discussions are welcome :-)

A good step in the right direction.  Minor comments:

: 3.  Well-defined, standardized intervals
: 
:    The problem can be reduced by defining interval values that must be
:    supported by all implementations.  Then the adjustment mechanism
:    could find a commonly supported interval without deviating too much
:    from the original request.
: 
:    The proposed set of Standard interval values is: 3.3msec, 10msec,
:    20msec, 50msec, 300msec and 1sec.

Your first sentence, while a lower-case "must", still seems very demanding.
Consider something like:

"The problem can be reduced by defining a set of standardized intervals.
Implementations that are capable of supporting one of the standardized
intervals SHOULD do so.  Implementations may then quickly converge on a
commonly supported interval without deviating too much from the original
request."

-- Jeff (speaking as an individual contributor)

---

From: Marc Binderberger <[email-masked]>
Date: Sat, 5 May 2012 20:21:40 +0200

Hello Jeff,

thanks for your comments.

Actually I should have used a MUST instead of must. You say it's demanding but keep in mind that having a guarantee that certain intervals are supported is exactly the reason why we wrote the draft.

Re-reading our draft maybe this is where a misunderstanding is caused: what we wanted to say is

   The problem can be reduced by defining interval values that MUST be
   supported by an implementation when the value is equal or larger than
   the fastest, i.e. lowest, interval a particular BFD implementation
   supports. 

I mentioned this lower limit condition in the abstract but not explicitly later again. Actually it makes it a terribly long sentence. Or maybe as an alternative, providing the idea in some "vague" English and then a technical definition:

   The problem can be reduced by defining interval values that are
   supported by all implementations.  Then the adjustment mechanism
   could find a commonly supported interval without deviating too much
   from the original request.

   In technical terms the requirement is as follows: a BFD implementation
   MUST support all values in the set of Standard interval values which
   are equal or larger than the fastest, i.e. lowest, interval the
   particular BFD implementation supports.

To be very clear: while the set of Standard interval values we propose contains 3.3msec, 10msec and other fast intervals I'm not saying that every vendor must support these values. Would be shooting into my own foot as some of my own products have fastest intervals of 50 or 100msec :-)

> intervals SHOULD do so.

The way I read this would mean that vendor "A" in our example in section 2 would be compatible with such a statement - vendor "A" supports 100msec, which  is in the set of standardized intervals. But Nobo and me argued that "A" is kind of a troublemaker by not supporting interval "20msec".

Does this make sense to you?

Regards, Marc

--
Marc Binderberger           <[email-masked]>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 7 May 2012 14:25:07 -0400

>    particular BFD implementation supports.

I believe the above two paragraphs probably are closer to saying what you
intend to say.

One of the reasons I argue for SHOULD is somewhat vaguely based on concerns
I have whether implementations can fully support the rate rather than simply
get "close enough".  Consider the following contrived example:

One of our standard rates is 10msec.  Due to the clock inputs for a given
chipset providing hardware based BFD, the interval is 9.5msec.  Should the
implementation say "I can do 10msec" or report its actual 9.5msec?

To a large extent, if you're working to be compliant with RFC 5880, you
already report a jitter (up to 25%) over your lowest possible detection
time.  If you can only really detect things at 10msec, you probably should
report 12.5msec as part of BFD session setup.  (Or 10% jitter at detection
interval of 1).

So, what your draft is really saying is "for each interval in set of
standardized intervals, your implementation must support an actual detection
interval a jitter value smaller than the reported interval". 

It still seems to be worthwhile determining some standardized intervals for
all the reasons you cite.  However, by the above observations, it's probably
not worth trying to be too picky about the values as long as they are within
mandated jitter.

-- Jeff