Subject: Re: [Pce] Adoption of draft-xiong-pce-lsp-flag-03

From: <[email-masked]>
Date: Fri, 5 Feb 2021 14:46:56 +0800 (CST)

Hi Cyril,

Thanks for your review and comments! It is a good point.

In my opinion, the TLV and the flag could be used in other PCEP Objects. 

But if the defination of extended flags are different, then the TLV is different.

I think that would be a new TLV, not the LSP-EXTENDED-FLAG TLV.

What are the thoughts of others?

Thanks,

Quan

>Re: [Pce] Adoption of draft-xiong-pce-lsp-flag-03
Cyril Margaria <[email-masked]> Thu, 04 February 2021 10:36 UTCShow header

Support,

I have the following comments:
 - The TLV is, as specified, is not forbidden in other PCEP Objects,
 - It might be only defined as LSP object TLV and error code defined for
other cases, but it could also be allowed in any object and the extended
flags defined themselves within the context of an object.

BR
Cyril

On Thu, 4 Feb 2021 at 09:14, Dhruv Dhody <[email-masked]> wrote:

> Hi WG,
>
> Greg, Quan, and I discussed this offline and have this proposed text -
>
> Note that, PCEP peers MAY encounter different length of the
> LSP-EXTENDED-FLAG TLV.
>
> o 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.
>
> o 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.
>
> Thoughts?
>
> Dhruv (as a WG member)
>
>
> On Thu, Feb 4, 2021 at 2:34 AM Greg Mirsky <[email-masked]> wrote:
>
>> Dear All,
>> I've read the draft and support it being adopted by the PCE WG. The draft
>> provides an elegant future-proof solution to the real problem. I have one
>> suggestion for a future revision of this document. You've already
>> considered backward compatibility between implementations that support the
>> new TLV and ones that do not. I think we can envision a situation when
>> implementations with, for example, 32 bit-long LSP Extended Flags field
>> interwork with implementations that use 64 bit-long field. Such a situation
>> might be far away today but it might help developers later. Also, might be
>> helpful to explicitly note that the value in the Length field equals the
>> length of the LSP Extended Flags field in octets (some bytes used to be
>> only seven-bit-long).
>>
>> Regards,
>> Greg
>>
>> On Mon, Feb 1, 2021 at 9:48 AM Dhruv Dhody <[email-masked]> wrote:
>>
>>> Hi WG,
>>>
>>> This email begins the WG adoption poll for draft-xiong-pce-lsp-flag-03.
>>>
>>> https://datatracker.ietf.org/doc/html/draft-xiong-pce-lsp-flag-03>>>
>>> This is a small draft that extends the flags in the LSP Objects by
>>> defining a new LSP-EXTENDED-FLAG TLV. Note that the existing
>>> sub-registry "LSP Object Flag Field" is almost fully assigned.
>>>
>>> https://www.iana.org/assignments/pcep/pcep.xhtml#lsp-object-flag-field>>>
>>> Should this draft be adopted by the PCE WG? Please state your reasons
>>> - Why / Why not? What needs to be fixed before or after adoption? Are
>>> you willing to work on this draft? Review comments should be posted to
>>> the list.
>>>
>>> Please respond by Monday 15th Feb.
>>>
>>> Thanks!
>>> Dhruv & Julien
>>>
>>> _______________________________________________
>>> Pce mailing list
>>> [email-masked]>>> https://www.ietf.org/mailman/listinfo/pce>>>
>> _______________________________________________
> Pce mailing list
> [email-masked]> https://www.ietf.org/mailman/listinfo/pce>

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 5 Feb 2021 14:18:06 +0530

Hi,

While it is an interesting idea to make this generic, I think we should
limit this TLV to be used with the LSP object only to keep this focused and
avoid complexity.

Regarding sending errors, I don't think we have specified such an error
before for any other TLVs which are specific to an Object. Applying the
robustness principle and ignoring the TLV (if received in other
objects) would make sense IMHO.

Thanks!
Dhruv (as a WG member)

On Fri, Feb 5, 2021 at 12:17 PM <[email-masked]> wrote:

> <https://mailarchive.ietf.org/arch/msg/pce/jL4ZD31H1ZUWSvjItgwQItZ2pjw/#>
>
> Support,
>

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 12 Feb 2021 03:31:14 -0500

I support WG adoption by the PCE WG.

I agree with Dhruv that maybe we should limit TLV to LSP object only.  I
don’t mind complexity if their is a significant gain with making it
generic.  I think we have to weigh the pros and cons.

Thanks

Gyan

On Fri, Feb 5, 2021 at 3:48 AM Dhruv Dhody <[email-masked]> wrote:

> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD