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
