Re: [Pce] WGLC for draft-ietf-pce-lsp-extended-flags-02

[Gyan Mishra <[e-mail]>]

Dear WG

I read the draft and support publication.

I agree with following the format of RFC 5088 and 5099 PCED discovery
encoding and using variable flag length  is fine as described in section
3.2 processing.

   If a PCEP speaker receives the LSP-EXTENDED-FLAG TLV of a length more
   than it currently supports or understands, it will simply ignore the
   bits beyond that length.

   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.


Thus no interoperability issues.


Kind Regards


Gyan


On Fri, May 13, 2022 at 5:34 AM <[e-mail]> wrote:

> 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 "><
> [e-mail]>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 "><[e-mail]> wrote: > > > Hi Aijun, > >
> As a WG member... > > On Thu, May 12, 2022 at 6:58 AM Aijun Wang "><
> [e-mail]>> 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 "><
> [e-mail]> 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 >>
> [e-mail]>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pce
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*