Jeff/Les, Point taken, thanks!
Regards, Jeff > On Nov 22, 2019, at 15:44, Les Ginsberg (ginsberg) <[email protected]> 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 <[email protected]> On Behalf Of Jeffrey Haas >> Sent: Thursday, November 21, 2019 6:53 PM >> To: [email protected] >> Cc: [email protected] >> 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 > _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
