[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,

Thanks for the review.

Both of your points are addressed in Section 3:

bfd.PaddedPduSize:
The BFD transport protocol payload size is increased to this value. The
contents of this additional payload MUST be zero. The minimum size of this
variable MUST NOT be smaller than permitted by the element of BFD procedure; 24
or 26 - see Section 6.8.6 of [RFC5880].


Juniper Business Use Only
On 5/12/24, 09:02, "Jürgen Schönwälder via Datatracker" <noreply@xxxxxxxx <mailto:noreply@xxxxxxxx>> wrote:
> The definition of the padded-pdu-size type may be a bit confusing:
>
> "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
> MTU of the system.";
>
>
> I _assume_ a value of this type determines the Length field of the BDF
> Control packet. Perhaps define it that way and leave out "for the
> encapsulated BFD control packets", which may be confusing.

The BFD packet itself has a length, X, typically 24 or 26.
It is encapsulated in its transport PDU and is padded to this size.

Given the above, what would you want to see instead? If below:

> "The padded PDU size carried in the Length field of a BDF
> Control packet. 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 MTU of the system.";

... this is incorrect.

> Is there anything to be said about the padding data? All zeros, random
> bits, implementation specific?

Covered in section 3.  Would a section ref in the yang cover the point?
Repeating protocol procedural points is something I'd prefer to avoid in text
describing configuration.

> The value of Appendix A is not clear, perhaps drop it?

It's of low value, but had been brought up multiple times over the original
design discussion of the feature.  I'm fine dropping it, but we're certain to
see the "well, didn't you know about this already existing feature" within days
of doing so.

-- 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