Hi Aijun, As a WG member...
On Thu, May 12, 2022 at 6:58 AM Aijun Wang <wangai...@tsinghua.org.cn> wrote: > Hi, Dhruv and Quan: > Is there any reason to define the extended flag in variable length? > The aim was to fix it once and not worry about running out of flags ever again. Moreover, there is a precedence of this technique in the context of PCE, so the implementations already handle these cases well. https://www.rfc-editor.org/rfc/rfc5088.html#section-4.5 https://www.rfc-editor.org/rfc/rfc5089.html#section-4.5 > Should it be more reasonable that just define one 32 bit extended flag and > if necessary, define another extended flag TLV? > Yes, it can be done that way. Is it more reasonable? That is debatable... Open to feedback from the WG. > 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? > > A (TLV L=8) ------ B (TLV L=4) When A receives an LSP-EXTENDED-FLAG TLV with Length = 4, even though it understands/supports more flags than 32, it considers that those other flags are unset for B. When B receives an LSP-EXTENDED-FLAG TLV with Length = 8, since B only understands limited bits, it considers all the other ones as unassigned and ignores them. Note that this behavior is similar to how considering A supports 10 flags and B supports 3 flags would be handled even though the L=4 for both. What am I missing? Anyway, I recommend the fixed length(then the length field is unnecessary) > and clear description/usages of each bit of the flag. > > This document creates the TLV and a registry. The actual bits and their usage belong in other documents. Thanks! Dhruv (as a WG member) > 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
