Jeff - First I would like to reemphasize that I support the draft - so we aren't on opposite sides here. It is just that Last Call seems premature.
As for the comparison with authentication... Authentication added new functionality which cost CPU time. The tradeoff there was clear - performance/scale vs security. But there was no concern that the addition of the authentication bytes in and of itself might introduce a problem. Large packets introduces MTU sized packets - which in and of itself is unlikely to cause a performance issue. But, having spent a fair number of hours debugging MTU related issues of various flavors, I do think it is likely to expose bugs in packet processing related to size. It shouldn't - in a perfect world - but what chips/software does with sub-MTU sized packets doesn't always translate to MTU size packets. And since the definition of what MTU is isn't consistent across vendors (let alone even within a single vendor's products) there are many ways to screw up configuration here. Throw in all the various flavors of encaps...I think we can expect deployment issues - and maybe bugs as well. Just my thoughts... Les > -----Original Message----- > From: Jeffrey Haas <jh...@pfrc.org> > Sent: Wednesday, September 18, 2019 7:01 PM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> > Cc: Ketan Talaulikar (ketant) <ket...@cisco.com>; Reshad Rahman > (rrahman) <rrah...@cisco.com>; rtg-bfd@ietf.org > Subject: Re: WGLC for draft-ietf-bfd-large-packets > > Les, > > On Thu, Sep 19, 2019 at 12:06:13AM +0000, Les Ginsberg (ginsberg) wrote: > > > > If these protocol changes are to be made, shouldn't they be specified in > > > this document?? Otherwise the document would seem just > informational. > > > > > > No. There's not really any room in BFD v1 for negotiation. That would > take > > > something like BFDv2, as we've started discussing in the working group. > > > > > > > [Les:] I am not fully comfortable with the notion that it is OK to deploy > > this > w/o regard for whether existing implementations can handle it. I think there > is some risk here and I would like the WG to discuss this point and - if > agreed > to - have the draft explicitly state that the risks of deploying this w/o > negotiation have been considered and deemed acceptable. The fact that one > implementation had no issue with it isn't compelling. > > FWIW, I'm not blowing off your considerations. Mostly, I'm highlighting > that we get them regularly. TSV review of BFD in every flavor over the > entire life of the protocol has been some variety of this conversation. We > just get to replay the entire life of BFD RFCs within such considerations > with every new TSV area director. :-) > > Obviously it's up to Reshad as the shepherding chair how this process plays > forward, but I suspect it'll resemble: > - Getting further consensus from the rest of the WG whether this > consideration is a sticking point. > - If it is, do we force this to be deferred to BFD v2? > - Alternatively, can we cleverly figure out some way to wedge negotiation on > top of the existing feature in a backward compatible way? (My answer: > possibly. Whether it's worth the complexity bump is the arguable > component > since simplicity of the protocol has been a stronger driving factor for > implementors than scaling considerations.) > > I'd like to hear from other implementors whether they share your concerns.. > But either way, this exact conversation will play out again with the TSV ADs > during IESG review. This is expected. > > > > However, this isn't particularly different from any other BFD > considerations > > > we've had over the years across all uses of BFD. Your scale for sessions > > > vs. timers will depend on transport, whether it's distributed to the line > > > card or not, hardware support vs. general purpose CPU, etc. BFD > > > implementors and users expect to do some level of tuning. This is > normal. > > > > > > > [Les:] The point I am highlighting is that we already have (at least for > > some > deployments) a way to detect this within a scale of several seconds (or at > least 10s of seconds). > > You're over-simplifying your point slightly. That's true for one protocol, > IS-IS, where the padding can be done. For those that can benefit from that > scenario, great! But I suspect you'd agree that not everyone is going to > enable IS-IS on a link just to test MTU liveness. > > > If the argument is that this is not fast enough, what is fast enough? > > Much as you aren't a fan of RFC 7419, that's exactly why that document > existed. Some level of commonality was desired in order to develop more > uniform scaling comparisons. > > It's entirely possible that some implementations will take zero hit to run > BFD at exactly the same wire rate. A BFD PDU every 3.3ms is not that much > in the way of pps. And, if your forwarding silicon does its job of > isolating IP validation in the pipeline before punting to the BFD code, BFD > itself may not take any hit in terms of cycles. However, if you're software > only, you may now be congesting a host path. > > We already run into flavors of these considerations for regular 5880 BFD > over various transports. The timer and session granularities vary. No one > freaks out at this. > > > The conclusion I drew from the earlier discussion was that existing > detection times for BFD were what was wanted. But the text in the draft > suggests that the addition of MTU checking might justify accepting a slower > detection time. > > I'm going to simply point out that such considerations apply to built-in BFD > features such as authentication. If you enable some classes of > authentication, you've impacted your detection interval. > > I'd like to know why you think that this feature is any scarier than the > impact of authentication. > > -- Jeff
