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 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? > > 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 variable length is not overly complex. Implementation 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 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
