Hi Dhruv and Aijun, Thanks for your review and discussion! In my veiw, 32 bits (seems good enough at the present) and variable-length ( if more bits are ever needed) are both OK to the LSP-EXTENDED-FLAG. I suggest to keep in consistency with the existing RFC such as RFC5088. I am also happy to get the feedback from others in PCE WG.
Best Regards, Quan >Hi Aijun, >On Thu, May 12, 2022 at 11:54 AM Aijun Wang >"><wangai...@tsinghua.org.cn>wrote: > 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. > >The MSB bit is marked as zero and will be allocated in that >order by the >IANA. The check for a specific bit is not overly complicated >because of the >variable length of the TLV. > 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. > > >Yes, most likely the implementation will >use length = 4 for a long time >while sending but will be prepared to receive >length as 4*n and simply >ignore all bits that are unassigned. > And for the >variable length flag, there need t o 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? > > >Nope, it would not be an error, this would fall under handling backward >compatibility - i.e. what happens when the peer does not support the new >features and send the TLV with L=4, the receiving peer would consider the >bits beyond 32 to be unset. >This is the same behavior if one party understands/supports more flags than >the other, even when L=4 for both. > 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. > > >Of course, fixed-length is simpler, but va riable length is not overly >complex. Implem! entation knows how to handle this already. >But if the WG disagrees, I am happy to be in the rough to make progress! >Thanks! >Dhruv (continue to speak as a WG member) > > 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 rec! ommend 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 u s 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] WGLC for draft-ietf-pce-lsp-extended-flags-… Dhruv Dhody Re: [Pce] WGLC for draft-ietf-pce-lsp-extended-fl… Aijun Wang Re: [Pce] WGLC for draft-ietf-pce-lsp-extended-fl… Dhruv Dhody Re: [Pce] WGLC for draft-ietf-pce-lsp-extended-fl… Aijun Wang Re: [Pce] WGLC for draft-ietf-pce-lsp-extended-fl… Dhruv Dhody _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
