Hi, Dhruv and Quan: Is there any reason to define the extended flag in variable length? Should it be more reasonable that just define one 32 bit extended flag and if necessary, define another extended flag TLV? And, as I read section 3.2: https://www.ietf.org/archive/id/draft-ietf-pce-lsp-extended-flags-02.html#section-3.2 “…. … 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. … ….”
Will the above lead to misbehavior in some situations? Anyway, I recommend the fixed length(then the length field is unnecessary) and clear description/usages of each bit of the flag. Aijun Wang China Telecom > On May 11, 2022, at 21:28, Dhruv Dhody <d...@dhruvdhody.com> wrote: > > > Hi WG, > > This email starts a 2-weeks working group last call for > draft-ietf-pce-lsp-extended-flags-02 [1]. > > Please indicate your support or concern for this draft. If you are opposed to > the progression of the draft to RFC, please articulate your concern. If you > support it, please indicate that you have read the latest version and it is > ready for publication in your opinion. As always, review comments and nits > are most welcome. > > The WG LC will end on Wednesday 25th May 2022. > > A general reminder to the WG to be more vocal during the last-call/adoption > and help us unclog our queues :) > > Thanks, > Dhruv & Julien > > [1] https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-extended-flags/ > _______________________________________________ > 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