[Last-Call] Re: Yangdoctors last call review of draft-ietf-bfd-large-packets-07

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux