Les, On Wed, Sep 18, 2019 at 05:24:17AM +0000, Les Ginsberg (ginsberg) wrote: > 1)Sorry to be late in responding - but just back from vacation.
I wouldn't know anything about that sort of problem. :-) > There are very legitimate concerns about the impact supporting padded BFD > PDUs may have on existing hardware implementations - both functionally and in > terms of scalability. > As a standards track document I think more needs to be said about operational > considerations - and I think there may be legitimate reasons to consider > negotiation of the capability. > In particular the statement in Section 3: > > "Additional changes to the base BFD protocol may be required to permit > negotiation of this functionality > and the padding value." > > 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. Your point about the document being potentially informational is certainly possible, albeit probably not what you're really intending. As implementation has already shown us, one side can simply start using this procedure without any support required on the other side. I.e. there's no protocol changes we're doing. > Section 3 also suggests > > "support[ing] a lower transmission interval (bfd.DesiredMinTxInterval)" > > as a means of minimizing scalability impacts. But in early discussions of > this draft it had been suggested that rather than use BFD for PathMTU > validation we could use another protocol (e.g., IS-IS hellos) to do this. But > that was rejected because it was stated that the deployment requirement > required much faster detection. If that argument holds, then the suggestion > in the draft to use longer timers seems inappropriate - or at least without > sufficient context. More context could be added, if there's appropriate text to add. Suggestions are welcome. 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. What you otherwise seem to be implying is that some operational forum should mandate a profile for number of sessions vs. timers vs. MTU size vs. transport on a particular set of hardware. And even then, that's not impacting on this document's procedures. > (BTW, by "lower transmission interval" I assume you mean a longer interval > (i.e., a larger value for bfd.DesiredMinTxInterval)??) Yes. > I think these points need to be addressed in the draft before it is can be > considered complete. -- Jeff
