Jeff - A few more thoughts - maybe these are more helpful than my previous comments - maybe not. I am sure you will let me know.
Protocol extensions allowing negotiation and/or advertisement of support for larger PDUs may well be useful - but let's agree that it is desirable to deploy this without protocol extensions just to keep the interoperability bar low. My primary angst is with the following paragraph in Section 3: "It is also worthy of note that even if an implementation can function with larger transport PDUs, that additional packet size may have impact on BFD scaling. Such systems may support a lower transmission interval (bfd.DesiredMinTxInterval) when operating in large packet mode. This interval may depend on the size of the transport PDU." Given long experience that CPU use correlates more highly with number of packets than with number of bytes, the first sentence would seem to be weakly supported. Given the previously mentioned concerns about detection time, the second sentence seems to compromise the value of the extension. What might be better? 1)Some statement that MTU isn't necessarily a consistent value for all systems connected to an interface - which can impact the results when large BFD packets are used. Implementations might then want to consider supporting "bfd-mtu" configuration and/or iterating across a range of packet sizes to determine what works and what doesn't. 2)Use of both padded and unpadded packets in combination with draft-ietf-bfd-stability to determine whether a BFD failure is due to padding or a generic forwarding failure. Either of these suggestions are really "diagnostic modes" which may help diagnose a problem but aren't meant to be used continuously as part of fast failure detection. Les > -----Original Message----- > From: Jeffrey Haas <jh...@pfrc.org> > Sent: Thursday, September 19, 2019 5:17 AM > 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 Sep 18, 2019, at 10:37 PM, Les Ginsberg (ginsberg) > <ginsb...@cisco.com> wrote: > > > > 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. > > The purpose of WGLC is to shake out final comments when things have > otherwise stalled. If it's not ready, we're not bothered by that. :-) > > That said, we need to match concerns with something actionable. That's > what I'm hunting for. > > > 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. > > Most of your commentary was focused around the impact on detection time, > hence the response you got regarding other features that have similar > impact. > > So, if we've moved on from detection time impact of features to other > issues, that's fine. > > > > > 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. > > I think Albert is happy to see this text. :-) > > The primary purpose of this feature is to shake loose issues related to MTU > sized packets and try to remove such paths from service when we can't > forward through them. The path detection at speed is a general good fit for > BFD. > > What I'm concerned about is you're trying to point out "when there are > issues, this doesn't help - and at best exacerbates them". If so... well, > this > feature isn't intended to be a debugging layer for those sort of issues. > However, since BFD is riding on top of various transports to do this job, if > the > encapsulation can carry additional information that permits such debugging > information, we're amenable to discussing what to do with it. > > -- Jeff
