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 <[email protected]> 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 <[email protected]> *On Behalf Of *[email protected] > *Sent:* 28 November 2019 03:44 > *To:* [email protected]; [email protected]; [email protected] > *Cc:* [email protected] > *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 > > > > > > 原始邮件 > > *发件人：*[email protected] <[email protected]> > > *收件人：*熊泉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 > > >
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
