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

[Jürgen Schönwälder <[e-mail]>]

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" <[e-mail] <mailto:[e-mail]>> 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany