Jürgen, On Wed, May 22, 2024 at 11:32:05AM +0200, Jürgen Schönwälder wrote: > On Mon, May 13, 2024 at 06:37:15PM +0000, Jeff Haas wrote: > > How about the following? > > > > description > > - "The padded PDU size for the encapsulated BFD control packets. > > - The minimum size is 24 or 26; see Section 6.8.6 of RFC 5880. > > - The maximum PDU size may be limited by the supported interface > > + "The size of the padded and encapsulated BFD control packets > > + to be transmitted at layer 3. The BFD minimum control packet > > + size is 24 or 26 octets; see Section 6.8.6 of RFC 5880. > > Thanks, I think this is much clearer. Progress! > > + The effective padded-pdu-size per BFD session will be > > + increased from the configured value to the minimum sized > > + packet for that encapsulation capable of carrying the BFD > > + control packet. > > I assume this paragraph only applies if the configured padded PDU size > is smaller than the achievable encapsulated PDU size. If so, it may > make this condition clearer? > > If the configured padded PDU size is smaller than the minimum sized > packet of a given BFD session, then the minimum sized packet for the > session will be used. I'm happy to use this text and will include it in next update. > > + The maximum padded PDU size may be limited by the supported interface > > Is it a configuration error to configure a padded PDU size that is > impossible for a given BFD session / interface? Or will any large > value be valid configuration since implementations will silently > attempt to use the largest possible value for a given BFD session if > the configured padded PDU size is too large? I don't believe it's guaranteed to be a configuration error, hence this slight ambiguity. For example, even if something in the interfaces module gave us a sense of MTU, the effective MTU may be dyanmic state and we can't create a constraint against that operational state. Some platforms may understand that it's impossible to have such a configuration, and are capable of returning a commit failure. Some platforms may have the value change based on configuration of the interface itself and BFD is simply expected to react to this at the protocol level. This is actually an excellent example of the motivation for the feature. If you presume that interface X has MTU M and the BFD session is setup to pad to that, then the user changes an encapsulation parameter such that M can no longer pass through that interface, BFD will drop the session due to the MTU issues. > Sorry for this level of nitpicking. I am deeply appreciative of the nitpicking. -- Jeff -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
