See inline...
On 12.05.24 16:05, Jeff Haas wrote:
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].
OK. So the padding is added outside the BFD packet before any
encapsulation.
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:
I am looking for clarity so that I know what the padding means I am
configuring without having to dig out the specification.
"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.
Perhaps "The size of the BFD control packet including padding
before encapsulation." or something like that. I am trying to make
it clear how to set this value correctly.
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.
Sure, I missed that in section 3, this does not need to be in the YANG
description.
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
--
Jürgen Schönwälder Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
