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

From: Jeffrey Haas <[email-masked]>
Date: Thu, 21 Nov 2019 21:52:55 -0500

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

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Fri, 22 Nov 2019 03:28:39 +0000

Hi WGs,
This was greatly discussed in the BFD WG meeting in Montreal, and that there was NO support to complicate the BFD for IPPM use-cases. There are number of existing protocols (OWAMP, TWAMP, RFC6374, STAMP, IOAM, etc.) designed, implemented and deployed for IPPM use-cases already. I am surprised that the text is still present in the latest version (02) of the draft (Section 3.4) and presented in another WG.

Thanks,
Rakesh

On 2019-11-22, 10:49 AM, "Rtg-bfd on behalf of Jeffrey Haas" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    -----

    

    

    -----

    

    
    
    -- Jeff

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 22 Nov 2019 12:40:40 +0800

Hi Rakesh,
thank you for sharing your thoughts about this work. Please find my notes
in-line tagged GIM>>.

Regards,
Greg

On Fri, Nov 22, 2019 at 11:28 AM Rakesh Gandhi (rgandhi) <[email-masked]>
wrote:

> Hi WGs,
> This was greatly discussed in the BFD WG meeting in Montreal, and that
> there was NO support to complicate the BFD for IPPM use-cases.

GIM>> The draft was presented to RIFT WG some number of meetings ago. The
feedback received was that the ability to use a single OAM protocol for the
failure detection and loss measurement is of interest.

> There are number of existing protocols (OWAMP, TWAMP, RFC6374, STAMP,
> IOAM, etc.) designed, implemented and deployed for IPPM use-cases already.
> I am surprised that the text is still present in the latest version (02) of
> the draft (Section 3.4) and presented in another WG.
>
GIM>> I will remind that this is the individual draft. If you feel strongly
that some content should be removed, please ask WG Chairs for WG Adoption
Poll. Once the draft is adopted, hen, by all means, the WG will define the
scope, add/remove sections.

>
> Thanks,
> Rakesh
>
>
> On 2019-11-22, 10:49 AM, "Rtg-bfd on behalf of Jeffrey Haas" <
> [email-masked] on behalf of [email-masked]> wrote:
>

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 22 Nov 2019 12:49:20 +0800

Hi Jeff,
thank you for sharing the history of discussions at BFD WG related to this
work. There have been many exciting and inspiring discussions, and I've
tried to give credit to everyone who has influenced this work.
It was not our intention to seek a place for this work outside the BFD WG
but to share information, invite comments, and encourage discussion. With
the comments about u-BFD, I think, we've received a helpful and important
case to work on.
If by making this presentation, I've left the impression that authors are
trying to bypass the BFD WG, then I apologize as that has never been our
intention.

Regards,
Greg

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 22 Nov 2019 07:44:39 +0000

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 <[email-masked]> On Behalf Of Jeffrey Haas
> Sent: Thursday, November 21, 2019 6:53 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: BFD chair response to presentation on draft-mirmin-bfd-extended
>

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 22 Nov 2019 15:59:47 +0800

Jeff/Les,

Point taken,  thanks!

Regards,
Jeff

> On Nov 22, 2019, at 15:44, Les Ginsberg (ginsberg) <[email-masked]> wrote:
> 
>> information regarding the packet or state machine outside of the main PDU..

---

From: Dave Katz <[email-masked]>
Date: Fri, 22 Nov 2019 21:35:12 +0000

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) <[email-masked]> wrote:
>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 22 Nov 2019 23:07:50 +0100

Hi Dave,

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

BGP just because "it is there already" now transports link state database
and one SAFI of it is being called a link state protocol. Just because it
is there regardless of its p2mp nature is also being used for p2p
configuration push including ACLs.

It seems that BFD is heading the same way - again on the very same basis -
"it is there" - so let's use it.

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

Spot on !

Except IETF does not ship router's code :). Vendors do.  And till we see a
generic transport perhaps ZeroMQ message bus like OpenR uses being
shipped across at least few vendors existing protocols will get abused more
and more ...

Best,
R.

---

From: Dave Katz <[email-masked]>
Date: Sat, 23 Nov 2019 03:48:49 +0000

On Nov 22, 2019, at 5:07 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Hi Dave,

BGP just because "it is there already" now transports link state database and one SAFI of it is being called a link state protocol. Just because it is there regardless of its p2mp nature is also being used for p2p configuration push including ACLs.

It seems that BFD is heading the same way - again on the very same basis - "it is there" - so let's use it.

Sigh.  Protocol malpractice, IMHO.  I guess other people aren’t embarrassed as easily as I.

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.

Spot on !

Except IETF does not ship router's code :). Vendors do.  And till we see a generic transport perhaps ZeroMQ message bus like OpenR uses being shipped across at least few vendors existing protocols will get abused more and more …

Chickens and eggs.  Perhaps some like-minded vendor folk would like to do something about it…

—Dave

Best,
R.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 27 Nov 2019 15:22:06 -0500

Dave,

On Fri, Nov 22, 2019 at 09:35:12PM +0000, Dave Katz wrote:
> 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.

That's effectively what the discussion needs to be.  And I agree, there's
plumbing like demand and echo that can be gotten rid of.

The adaptive timers are part of the charm that people seem to like, so I
suspect that'd still be a thing people want.  Just not necessarily 3ms
granularity. :-)

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

I still resent Alex Z. and co. for leading me into that trap.

-- Jeff