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

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 <xiong.quan@zte.com.cn> wrote:

>
> 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 <cyril.margaria@gmail.com> Thu, 04 February 2021 10:36 UTCShow
> header
> <https://mailarchive.ietf.org/arch/msg/pce/jL4ZD31H1ZUWSvjItgwQItZ2pjw/#>
>
> 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 <dd@dhruvdhody.com> 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 <gregimirsky@gmail.com> 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 <dd@dhruvdhody.com> 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
> >>> Pce@ietf.org>>> https://www.ietf.org/mailman/listinfo/pce>>>
> >> _______________________________________________
> > Pce mailing list
> > Pce@ietf.org> https://www.ietf.org/mailman/listinfo/pce>
>
>
>