Hi, Dhruv: It’s possible to use variable length, but most of the flag field are fixed size, because this field needs to be compared in bits. Align them with the same width will be more easier. Even with your mentioned examples, the used flags are only 16bits until now(16 years past since RFC5088 published).
The reason that I raised this concern is that I have not imaged another 32bit flag need to be defined for LSP, regardless of the length as 64 or more longer. And for the variable length flag, there need to be more error considerations in the future bit-defined document. For example, if you define bit 35, you should consider the error that the length of received LSP-EXTENDED-FLAG is only 4(32bit), and describes the mismatch reason in the error information? Until now, I have not seen which defined flag has exceeds the 32bit. If there is enough necessary to do so, I don’t object, but currently I don’t see the image, why don’t we keep the thing simple. And, I support the forwarding of this draft. The current flag field has no room for further extension. Aijun Wang China Telecom > On May 12, 2022, at 11:59, Dhruv Dhody <d...@dhruvdhody.com> wrote: > > > 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
