I support WG adoption by the PCE WG. I agree with Dhruv that maybe we should limit TLV to LSP object only. I don’t mind complexity if their is a significant gain with making it generic. I think we have to weigh the pros and cons.
Thanks Gyan On Fri, Feb 5, 2021 at 3:48 AM Dhruv Dhody <d...@dhruvdhody.com> wrote: > Hi, > > While it is an interesting idea to make this generic, I think we should > limit this TLV to be used with the LSP object only to keep this focused and > avoid complexity. > > Regarding sending errors, I don't think we have specified such an error > before for any other TLVs which are specific to an Object. Applying the > robustness principle and ignoring the TLV (if received in other > objects) would make sense IMHO. > > Thanks! > Dhruv (as a WG member) > > On Fri, Feb 5, 2021 at 12:17 PM <xiong.q...@zte.com.cn> wrote: > >> >> Hi Cyril, >> >> >> Thanks for your review and comments! It is a good point. >> >> In my opinion, the TLV and the flag could be used in other PCEP Objects. >> >> But if the defination of extended flags are different, then the TLV is >> different. >> >> I think that would be a new TLV, not the LSP-EXTENDED-FLAG TLV. >> >> What are the thoughts of others? >> >> >> Thanks, >> >> Quan >> >> >> >> >> >> >Re: [Pce] Adoption of draft-xiong-pce-lsp-flag-03 >> >> Cyril Margaria <cyril.marga...@gmail.com> Thu, 04 February 2021 10:36 UTCShow >> header >> <https://mailarchive.ietf.org/arch/msg/pce/jL4ZD31H1ZUWSvjItgwQItZ2pjw/#> >> >> Support, >> >> I have the following comments: >> - The TLV is, as specified, is not forbidden in other PCEP Objects, >> - It might be only defined as LSP object TLV and error code defined for >> other cases, but it could also be allowed in any object and the extended >> flags defined themselves within the context of an object. >> >> BR >> Cyril >> >> On Thu, 4 Feb 2021 at 09:14, Dhruv Dhody <d...@dhruvdhody.com> wrote: >> >> > Hi WG, >> > >> > Greg, Quan, and I discussed this offline and have this proposed text - >> > >> > Note that, PCEP peers MAY encounter different length of the >> > LSP-EXTENDED-FLAG TLV. >> > >> > o If a PCEP speaker receives the LSP-EXTENDED-FLAG TLV >> > of a length more than it currently supports or understands, >> > it will simply ignore the bits beyond that length. >> > >> > o If a PCEP speaker receives the LSP-EXTENDED-FLAG TLV of >> > a length less than the one supported by the implementation, >> > it will consider the bits beyond the length to be unset. >> > >> > Thoughts? >> > >> > Dhruv (as a WG member) >> > >> > >> > On Thu, Feb 4, 2021 at 2:34 AM Greg Mirsky <gregimir...@gmail.com> wrote: >> > >> >> Dear All, >> >> I've read the draft and support it being adopted by the PCE WG. The draft >> >> provides an elegant future-proof solution to the real problem. I have one >> >> suggestion for a future revision of this document. You've already >> >> considered backward compatibility between implementations that support the >> >> new TLV and ones that do not. I think we can envision a situation when >> >> implementations with, for example, 32 bit-long LSP Extended Flags field >> >> interwork with implementations that use 64 bit-long field. Such a >> >> situation >> >> might be far away today but it might help developers later. Also, might be >> >> helpful to explicitly note that the value in the Length field equals the >> >> length of the LSP Extended Flags field in octets (some bytes used to be >> >> only seven-bit-long). >> >> >> >> Regards, >> >> Greg >> >> >> >> On Mon, Feb 1, 2021 at 9:48 AM Dhruv Dhody <d...@dhruvdhody.com> wrote: >> >> >> >>> Hi WG, >> >>> >> >>> This email begins the WG adoption poll for draft-xiong-pce-lsp-flag-03. >> >>> >> >>> https://datatracker.ietf.org/doc/html/draft-xiong-pce-lsp-flag-03>>> >> >>> This is a small draft that extends the flags in the LSP Objects by >> >>> defining a new LSP-EXTENDED-FLAG TLV. Note that the existing >> >>> sub-registry "LSP Object Flag Field" is almost fully assigned. >> >>> >> >>> https://www.iana.org/assignments/pcep/pcep.xhtml#lsp-object-flag-field>>> >> >>> Should this draft be adopted by the PCE WG? Please state your reasons >> >>> - Why / Why not? What needs to be fixed before or after adoption? Are >> >>> you willing to work on this draft? Review comments should be posted to >> >>> the list. >> >>> >> >>> Please respond by Monday 15th Feb. >> >>> >> >>> Thanks! >> >>> Dhruv & Julien >> >>> >> >>> _______________________________________________ >> >>> Pce mailing list >> >>> Pce@ietf.org>>> https://www.ietf.org/mailman/listinfo/pce>>> >> >> _______________________________________________ >> > Pce mailing list >> > Pce@ietf.org> https://www.ietf.org/mailman/listinfo/pce> >> >> >> _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
