Subject: Re: [mpls] Commenst on draft-akiya-bfd-intervals-03

From: Marc Binderberger <[email-masked]>
Date: Sat, 1 Jun 2013 22:34:55 +0200

Hello everyone,

my apologies for the late reply. Too many things at once :-)

It looks like we agree towards an "informal" document. This may be 
partially due to a misunderstanding, a "standard" document would define 
a minimum set of to-be-supported intervals, it would not forbid to 
support additional timer interval values, in my view. Anyway, the goal 
to improve interoperability can be reached with "informal" too, so I'm 
fine.

For the split-off of appendix B: I can write a new draft, no problem. 
The question is to the BFD list though: do you think we should dive 
deeper into the timer negotiation area?  If everyone thinks the 
appendix B is "obvious" or "trivial" then there is no point for a new 
document. If implementors think we better do write down these details 
and discuss them - then we have a basis for a new draft :-)

To quickly explain the problem again: RFC5880 and the Poll sequence 
described therein implicitly assume that the peer can accept any timer 
value. Thus the Poll sequence is a simple P-bit, F-bit sequence. With 
hardware-based implementations we may see a more granular timer support 
and the peer can _not_ accept the new interval proposed. More 
negotiations would be required to find a commonly supported timer value 
(which exists when following the draft's minimum set of values). 
Appendix B describes the procedure we propose.

Regards, Marc

On Fri, 10 May 2013 13:24:41 -0400, Jeffrey Haas wrote:
> On Mon, Dec 03, 2012 at 11:53:47AM -0800, Sam Aldrin wrote:
>> I echo what Santiago had said in his email. Good to have an 
>> informational document and do not support the idea of standardizing 
>> the intervals.
> 
> Speaking as chair, while I'm not in favor of have a standardized set of
> intervals (the fights such a document would create would be epic), I am
> highly supportive of such a document having informational status.
> 
> As a suggestion, there may be two actual documents in such a case: 
> - An informational document covering the intervals.
> - A short document, potentially on the standards track, covering the
>   procedure by which timers can negotiate to such an interval.  This may be
>   worth standardizing.  (This is covered by Appendix B.)
> 
> -- Jeff

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sun, 2 Jun 2013 02:27:13 +0000

Hello Marc, et al,

Before going into "timer negotiation deep dive", it'll be beneficial to define the contents of the informational draft. In addition to set of intervals specified, the document can also describe usefulness in implementation supporting multiples of specified intervals. Such implementations will be able to support large set of intervals, and even larger set when jitter considered. I think the result will be very useful to anybody implementing/operating HW BFD. Once we converge on that, then perhaps we can take up the discussion of whether we need additional standard track draft or not, and with what contents.

Regards,
Nobo

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Marc Binderberger
> Sent: Saturday, June 01, 2013 4:35 PM
> To: Jeffrey Haas; Sam Aldrin; Santiago Alvarez (saalvare); Binny Jeshan
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [mpls] Commenst on draft-akiya-bfd-intervals-03
> 
> Hello everyone,
> 
> It looks like we agree towards an "informal" document. This may be partially
> due to a misunderstanding, a "standard" document would define a
> minimum set of to-be-supported intervals, it would not forbid to support
> additional timer interval values, in my view. Anyway, the goal to improve
> interoperability can be reached with "informal" too, so I'm fine.
> 
> 
> The question is to the BFD list though: do you think we should dive deeper
> into the timer negotiation area?  If everyone thinks the appendix B is
> "obvious" or "trivial" then there is no point for a new document. If
> implementors think we better do write down these details and discuss
> them - then we have a basis for a new draft :-)
> 
> hardware-based implementations we may see a more granular timer
> support and the peer can _not_ accept the new interval proposed. More
> > Speaking as chair, while I'm not in favor of have a standardized set
> > of intervals (the fights such a document would create would be epic),
> > I am highly supportive of such a document having informational status.
> >
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Jeffrey Haas <[email-masked]>
Date: Sun, 2 Jun 2013 08:48:08 -0400

> to improve interoperability can be reached with "informal" too, so I'm 

An informational draft on the specific timer values may be of benefit.
One thing to ponder that has standards impact would be whether we'd want to
request an IANA registry to record such "well known values".

> and discuss them - then we have a basis for a new draft :-)

I think, given such a document specifying the well known values, that having
a known mechanism supporting converging on those values may be helpful.

My biggest concern for such a proposal is that it would encourage
implementations to *only* support those values rather than providing targets
for scaling certain specific timers.  Consider, for example, a scenario
where a device going into a temporary maintenance mode may want to
significantly reduce its detection interval (say > 3s) for a short period of
time.  If the remote device didn't have that 3s+ value as one of its "magic
numbers", then it may simply drop the session depending on procedure.

These, of course, are just details to consider for the draft.

-- Jeff