Re: [Pce] [pce] :New Version Notification for draft-xiong-pce-lsp-flag-00.txt

[Dhruv Dhody <[e-mail]>]

Hi Quan, Adrian,

As a WG contributor, I agree with Adrian that just the presence of this TLV
is good enough to require the processing of extended flags. Other I-Ds that
define extended flags can make the TLV as mandatory for that feature.

Also if we go this route, we do not need to make this I-D as an update to
RFC 8231, it could be just be an extension and business as usual.

Thanks!
Dhruv

On Thu, Nov 28, 2019 at 5:48 PM Adrian Farrel <[e-mail]> wrote:

> Hi Quan,
>
>
>
> Thanks for picking up this work. You are right that we need a solution.
>
>
>
> A couple of points about your draft…
>
>
>
> I don’t think it is necessary or advisable to repeat the format of the
> existing PLSP-ID object, or to list the currently-assigned bits and
> meanings. Doing so creates potential conflict between two different
> normative documents.
>
>
>
> I believe that processing the TLVs in the object is mandatory, so I do not
> believe that you need to use a bit (bit 0) in the existing flags field to
> indicate that the LSP-Extended-Flags TLV is present. It will be found if it
> is there. (I don’t feel strongly about this, and other may find the
> indication to be useful).
>
>
>
> You have not given a value for the Length field in the LSP-Extended-Flags
> TLV. Is this because you intend that the TLV should scale if more than 32
> bits are needed? If so, you should give some clues about processing. If
> not, you should just set the value.
>
>
>
> You need to describe backwards compatibility. How will legacy
> implementations process this TLV and what will be the effect on the setting
> of any bits?
>
>
>
> I think that in Singapore someone suggested comparing with the work done
> for RSVP-TE LSP Attributes. See RFC 5420. In that work we defined two TLVs
> to cover attributes that must be processed, and attributes that may be
> ignored. I’m not sure you need this, but think about it.
>
>
>
> I think section 6.1 is broken. You don’t need two flags, do you?
>
>
>
> You need to ask IANA for a new TLV type for your new TLV.
>
>
>
> You need to ask IANA for a new registry to track the bits in your new TLV.
>
>
>
> Cheers,
>
> Adrian
>
>
>
> *From:* Pce <[e-mail]> *On Behalf Of *[e-mail]
> *Sent:* 28 November 2019 03:44
> *To:* [e-mail]; [e-mail]; [e-mail]
> *Cc:* [e-mail]
> *Subject:* [Pce] [pce] :New Version Notification for
> draft-xiong-pce-lsp-flag-00.txt
>
>
>
> Hi all,
>
>
>
> I  have summitted the draft which proposes a
> new LSP-EXTENDED-FLAG TLV for LSP object to extend the length of the flag
> field.
>
> Could you please give me some suggestions about the format?
>
>
>
> Thanks,
>
> Quan
>
>
>
>
>
> 原始邮件
>
> *发件人：*[e-mail] <[e-mail]>
>
> *收件人：*熊泉00091065;
>
> *日* *期* *：*2019年11月27日 15:54
>
> *主* *题* *：**New Version Notification for draft-xiong-pce-lsp-flag-00.txt*
>
>
> A new version of I-D, draft-xiong-pce-lsp-flag-00.txt
> has been successfully submitted by Quan Xiong and posted to the
> IETF repository.
>
> Name:        draft-xiong-pce-lsp-flag
> Revision:    00
> Title:        LSP Object Flag field of Stateful PCE
> Document date:    2019-11-26
> Group:        Individual Submission
> Pages:        6
> URL:
> https://www.ietf.org/internet-drafts/draft-xiong-pce-lsp-flag-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-xiong-pce-lsp-flag/
> Htmlized:       https://tools.ietf.org/html/draft-xiong-pce-lsp-flag-00
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-xiong-pce-lsp-flag
>
>
> Abstract:
>    RFC8231 describes a set of extensions to PCEP to enable stateful
>    control of MPLS-TE and GMPLS Label Switched Paths(LSPs) via PCEP.
>    One of the extensions is the LSP object which includes a Flag field
>    and the length is 12 bits.  However, 11 bits of the Flag field has
>    been assigned in RFC8231, RFC8281 and RFC8623 respectively.
>
>    This document updates RFC8231 by defining a new LSP-EXTENDED-FLAG TLV
>    for LSP object to extend the length of the flag.
>
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>