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

[Jeff Tantsura <[e-mail]>]

Jeff/Les,

Point taken,  thanks!

Regards,
Jeff

> On Nov 22, 2019, at 15:44, 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
>