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 <pce-boun...@ietf.org> On Behalf Of xiong.q...@zte.com.cn Sent: 28 November 2019 03:44 To: andrew.st...@nokia.com; dhruv.i...@gmail.com; l...@pi.nu Cc: pce@ietf.org 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 原始邮件 发件人：internet-dra...@ietf.org <mailto:internet-dra...@ietf.org> <internet-dra...@ietf.org <mailto:internet-dra...@ietf.org> > 收件人：熊泉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 Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
