Hi, Dhruv and Quan:
Is there any reason to define the extended flag in variable length?
Should it be more reasonable that just define one 32 bit extended flag and if 
necessary, define another extended flag TLV?
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?

Anyway, I recommend the fixed length(then the length field is unnecessary) and 
clear description/usages of each bit of the flag.

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

Reply via email to