Re: BFD chair response to presentation on draft-mirmin-bfd-extended

[Dave Katz <[e-mail]>]

For what it’s worth, BFD was intended to be simple in semantics and implementation.  It makes a terrible transport protocol because the packet latency is utterly unpredictable (one of the two goals for the protocol was to make the detection time, and thus the interpacket time, changeable in realtime without affecting the session state).  When you throw in Demand Mode, the latency may be unbounded.

Part of the issue is that the IETF hasn’t bothered to put together a set of generic transports to build things like this on top of.  OSPF is a pretty simple routing protocol built on top of a very complex reliable multicast transport with certain semantics;  the world would be a better place if the two had been separated at birth and the transport was generalized.

In the case of BFD, the transport semantic is unicast reliability by periodicity, with liveness detection.  It would be stupid simple to build a protocol that had the same repetitive semantics  but could carry anything.  If the reliable session-down semantics are interesting, these could be included as well.  What’s not needed is any of the higher layer stuff, the adaptive timers, demand mode, echo mode, multipoint mode, etc. etc.

I’ve been quoted in the past that BGP, used as a transport, is “TCP with beard.”  It would have been trivial to split out the minimal semantics the actual BGP protocol brought to the table.

The problem is that this is protocol hackery, plain and simple, and it quickly becomes at cross purposes with the not-really-a-transport-protocol chosen to carry it (“That’s OK, we don’t need variable timers…”)

If BFD’s transport semantics are that interesting, someone could take a week and whip up a transport that looks rather like BFD but is properly suited for the purpose.  That would make all of these issues go away, and would provide a common mechanism that could be used more broadly, and someone would have an RFC to be proud of.

I guess the irony of all of this is that when the BFD WG was formed it was expected to be the shortest-lived WG in history.  Now I suspect it’s going for a record in the other direction.  ;-)

—Dave

> On Nov 22, 2019, at 2:44 AM, Les Ginsberg (ginsberg) <[e-mail]> wrote:
> 
> For the record, I agree with Jeff's summary and comments.
> 
> I was really surprised that Greg did not wait until IETF 107 - which the BFD chairs had already indicated would be the time to resume discussions of this work.
> However well intentioned, both the timing and the WG were inappropriate for this presentation.
> 
>   Les
> 
> 
>> -----Original Message-----
>> From: Rtg-bfd <[e-mail]> On Behalf Of Jeffrey Haas
>> Sent: Thursday, November 21, 2019 6:53 PM
>> To: [e-mail]
>> Cc: [e-mail]
>> Subject: BFD chair response to presentation on draft-mirmin-bfd-extended
>> 
>> In the interest of permitting the presentations to move smoothly at this
>> Friday's rtgwg session, I withheld my comments from microphone.  However,
>> please consider these comments for the record for IETF-106.
>> 
>> Firstly, I'm surprised the chairs had a BFD presentation at rtgwg.  rtgwg is
>> indeed intended to be a general purpose dispatch group for work without a
>> home, but that's not the case for BFD.
>> 
>> Secondly, Reshad and I intentionally did not schedule work on BFD extension
>> work, including Greg's presentation, for this IETF.  This is because there
>> is open charter discussions we're starting with the IESG on this space.
>> 
>> -----
>> 
>> Specific comments on BFD extension work and the charter discussions:
>> 
>> During prior IETFs, and culminating at IETF-105, we've seen regular work to
>> try to stuff BFD with additional features of various forms.  The litmus test
>> generally used for BFD's core use case over the years has been "what do you
>> want to hear every 3.3ms?"  To that end, things that enhance BFD's core
>> continuity verification uses cases have ended up in the protocol.
>> 
>> Somewhat similar to other popular protocols such as DNS and BGP, BFD has
>> nice properties that make it an appealing place to try to extend.  In
>> particular, it's a continuing conversation between two systems.
>> 
>> During IETF-105, the IPPM group members attending explicitly noted that they
>> did not want to see their mechanisms present in BFD and did not consider it
>> a good fit.
>> 
>> As part of that discussion, the chairs noted that one option potentially
>> open is that we permit the "BFDv2" option we have discussed at IETF-105 and
>> previous to permit an option where we do not use the core BFDv1 session used
>> for continuity for these extensions, and use a different protocol version
>> and port set to enable the other use cases.
>> 
>> Thus, the discussion with the IESG is whether BFD hands over the "gift" of a
>> general and mature mechanism for a conversation between two systems that
>> may
>> be generally extended to carry "interesting" information.
>> 
>> This addresses Tony Li's point about "please don't make BFD difficult to
>> implement in hardware".
>> 
>> -----
>> 
>> Specific comments on draft-mirmin-bfd-extended:
>> 
>> The somewhat peculiar extension mechanism shown in Greg's draft was
>> originally seeded by work I started in BFD for draft-ietf-bfd-large-packets.
>> In fairness to history, this was similar to work that was done in OSPF years
>> back for how the authentication mechanism was spliced onto the protocol.
>> The one sentence description of that use case is "make the packet padded to
>> test MTU".  It's a hack, but one that does a reasonable job of its use case.
>> 
>> However, with regard to leveraging this hack for a general purpose extension
>> mechanism, I don't find it a good fit.  BFDv1 does not expect to find
>> information regarding the packet or state machine outside of the main PDU..
>> It is likely a new version number will need to be used to establish future
>> semantics.  (Per prior discussion in the working group.)
>> 
>> The capabilities mechanism will likely require either integration into some
>> form of an updated state machine for the new version header, or a different
>> form.  IMO, I find it likely that a "capability advertisement" mechanism
>> would be necessary rather than negotiation to avoid a wholesale replacement
>> of the BFD state machinery.  And if we replace that much of the machinery,
>> let's just stop calling this BFD at all and move on.
>> 
>> With regard to IPPM style content for the draft, I refer you to the IPPM
>> members comments above from IETF-105.
>> 
>> With regard to authentication, there are two possibilities here:
>> - Faster authentication of BFD style packets is covered by work completing
>>  BFD WGLC draft-ietf-bfd-optimitizing-authentication.  I'd encourage other
>>  working groups in need of a faster per-packet authentication mechanism to
>>  consider whether it's an appropriate fit.
>> - In the case that such a future BFD, or mechanism built on similar
>>  machinery, want a way to autenticate the payload different from the
>>  headers, there will likely need to be discussion about not only what
>>  envelope is used, but also strength vs. periodicity.  (And if you don't need
>>  this stuff periodically, why use something like BFD?)
>> 
>> -- Jeff
>