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
