Hi Eric, John and Dhruv, Thanks for your discussions and suggestions! I have updated the draft as Eric's comments in version -08. I revised the text in section 1 with "This document extends the flag field of the LSP Object for other use." I also revised the text in section 3.1 as Dhruv's suggestion with "Length (16 bits): indicates the length of the value portion in bytes. It MUST be in multiples of 4 and greater than 0." Hope that will help to improve this draft and let me know if you have other suggestions.
Thanks, Quan >From: EricVyncke(evyncke) <evyn...@cisco.com> >To: John Scudder <j...@juniper.net>;Dhruv Dhody <d...@dhruvdhody.com>; >Cc: The IESG <i...@ietf.org>;draft-ietf-pce-lsp-extended-fl...@ietf.org ><draft-ietf-pce-lsp-extended-fl...@ietf.org>;pce-cha...@ietf.org ><pce-cha...@ietf.org>;pce@ietf.org <pce@ietf.org>; Date: 2022年10月18日 05:19 Subject: Re: Éric Vyncke's No Objection on draft-ietf-pce-lsp-extended-flags-07: (with COMMENT) It is also fine with me, except that I would prefer 'octet' rather than 'byte' ;-) (mostly joking BTW) -éric On 17/10/2022, 21:34, "John Scudder" <j...@juniper.net> wrote: It’s Éric’s ballot :-) but your proposal looks OK to me. Personally, I would copy the language from RFC 5440 verbatim ("MUST always be a multiple of 4, and at least 4”) but what you have works too. —John > On Oct 17, 2022, at 3:31 PM, Dhruv Dhody <d...@dhruvdhody.com> wrote: > > > [External Email. Be cautious of content] > > > Hi Eric/John, > > How about this text - > > Length (16 bits): indicates the length of the value portion in bytes. > It MUST be in multiples of 4 and greater than 0. > > Thanks! > Dhruv > > On Mon, Oct 17, 2022 at 9:18 PM Eric Vyncke (evyncke) <evyn...@cisco.com> wrote: > John > > I got the information from the section 7.1 indeed and when the value parts are in 32-bit words, then it is a multiple of 4 octets, i.e., 0, 4, 8, ... while my first reading would be 0, 1, 2 (as the unit appeared to be 32-bit words and not octets) > > -éric > > On 17/10/2022, 15:30, "John Scudder" <j...@juniper.net> wrote: > > One additional comment to Éric’s point -- > > > On Oct 17, 2022, at 3:44 AM, Éric Vyncke via Datatracker <nore...@ietf.org> 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 Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce