One additional comment to Éric’s point -- > On Oct 17, 2022, at 3:44 AM, Éric Vyncke via Datatracker <[email protected]> > wrote: > > `Length (16 bits): multiple of 4 octets.` is rather confusing... Is this field > counting 32-bit words ? I had to read RFC 5440 to understand that the 'value' > part is always a multiple of 4 octets. Strongly suggest to say "Length (16 > bits): length of the value expressed in octets”.
This seems like a good change, but if the multiple-of-4 constraint is required I think you’d need to add more words, as in “Length (16 bits): length of the value, expressed in octets. This value MUST be a multiple of 4. (And at least 4? Or is 0 a legal value?) Éric, I took a look at RFC 5440, §7.1, "PCEP TLV Format” seems to be the applicable section. It has this: The Length field defines the length of the value portion in bytes. The TLV is padded to 4-bytes alignment; padding is not included in the Length field (so a 3-byte value would have a length of 3, but the total size of the TLV would be 8 bytes). If that’s what you were thinking of, ISTM it explicitly says the length field does not have to be a multiple of 4. So AFAICT this is indeed a new requirement and should be expressed here, but you’re right that it can be clearer. I believe multiple-of-4 is a genuine requirement, related to "The LSP Extended Flags field is an array of units of 32 flags” (§3.2). If I’ve missed some other part of RFC 5440 that you were referring to, I’d be curious to know what it was. I do see that §7.2 has “MUST always be a multiple of 4, and at least 4”, but that’s for PCEP objects which this spec isn’t, rather it’s a TLV within an object, and AFAICT that doesn’t have the same constraint in the base spec. Thanks, —John _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
