Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

I support WG LC advancement of this draft for publication.

I see there are a lot of comments related to a mix of verbiage related to
MPLS label binding and Binding label SID confusion.

Few comments.

The draft title states “carrying binding label/sid in PCE based networks”

In the abstract it states it is possible to associate a BSID with a RSVP
signaled path.

I don’t recall any RSVP extension to support concept of BSID usage on an
active Candidate Path option ERO.  Can you refer me to the RFC that states
how BSID is used with RSVP TE.

For more clarity with this draft can we replace

s/TE/s/SR as TE nomenclature refers to RSVP-TE and does add confusion where
SR is SR.  When mentioned traffic engineered path please spell out or say
SR path for clarity.

Also the “TE-PATH-BINDING TLV” can we change to “SR-PATH-BINDING TLV”.

The word “binding” is very confusing as it’s used interchangeably with
label binding and binding SID.

So I am thinking a more appropriate name for the TLV would be “SR-TE-BSID
TLV”.  Makes it clear and concise the TLV is for SR-TE.

Kind Regards

Gyan

On Fri, Mar 26, 2021 at 9:45 PM Chengli (Cheng Li) <c.l@huawei.com> wrote:

> Thanks again for your help!
>
> Cheng
>
>
>
> -----Original Message-----
> From: Stone, Andrew (Nokia - CA/Ottawa) [mailto:andrew.stone@nokia.com]
> Sent: Saturday, March 27, 2021 2:42 AM
> To: Chengli (Cheng Li) <c.l@huawei.com>; julien.meuric@orange.com;
> pce@ietf.org
> Cc: draft-ietf-pce-binding-label-sid@ietf.org
> Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07
> (and Code Point Allocation)
>
> Hi Cheng,
>
> Thanks for clarifying the text in the document. Diff content looks good to
> me, much clearer. Consider my comments resolved.
>
> Thanks!
> Andrew
>
> On 2021-03-25, 10:49 PM, "Pce on behalf of Chengli (Cheng Li)" <
> pce-bounces@ietf.org on behalf of c.l@huawei.com> wrote:
>
>     Hi Andrew,
>
>     Thanks for your comments, please see my reply inline.
>
>     Also, the diff is attached.
>
>     Respect,
>     Cheng
>
>
>
>
>     -----Original Message-----
>     From: Stone, Andrew (Nokia - CA/Ottawa) [mailto:andrew.stone@nokia.com]
>
>     Sent: Saturday, March 20, 2021 4:21 AM
>     To: julien.meuric@orange.com; pce@ietf.org
>     Cc: draft-ietf-pce-binding-label-sid@ietf.org
>     Subject: Re: [Pce] WG Last Call for
> draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)
>
>     Hi all,
>
>     Overall Support WGLC. It's an important document in the world of SRTE,
> and the document goes to good lengths to describe the various scenarios and
> combinations.
>
>     Only one question I have for the authors and WG, for any further
> clarification on the following text (section 4):
>
>
>       The absence of TE-PATH-BINDING TLV in PCUpd message
>        means that the PCE does not specify a binding value in which case
> the
>        binding value allocation is governed by the PCC's local policy.
>
>
>     I find the "governed by PCC local policy" a bit too vague and could
> lead to implementation interop differences. Assuming a PCInitiated LSP that
> been established with a BSID: If the PCE wants to withdraw the binding SID
> , I interpret the document as the PCE would send a PCUpdate without the
> TLV, but the behaviour is now up to PCC as per that text. if the PCC local
> policy/implementation is to do nothing, how can the PCE explicitly
> force-remove the BSID with a PCUpdate? In a similar manner, If the PCE does
> not want to change the value but PCC local policy is to treat missing TLV
> as remove, then PCE should always send the TLV in every PCUpdate (which I'm
> okay with) which is not stated, otherwise the local policy/implementation
> may interpret it as a removal compared to an implementation which may
> interpret it as being okay to not send the TLV on every PCUpdate since
> there was "no change".
>
>     In summary: might need a bit of a wording to further detail "PCE
> wishes to withdraw" case.
>
>     [Cheng] You are correct, there was some issues with multiple
> TE-PATH-BINDING TLV. This has been updated. See the diff.
>
>     The above text has been updated to -
>
>        The absence of TE-PATH-BINDING TLV in PCUpd message means that the
>        PCE does not specify a binding value in which case any previous
>        allocated binding values are withdraw.
>
>     Further, the PCC's local policy aspect has been seperated out as -
>
>        In the absence of any instruction from the PCE, the PCC's local
>        policy dictates how the binding allocations are made for a given
> LSP.
>
>     Thanks!
>
>
>     Thanks!
>     Andrew
>
>     On 2021-03-18, 7:09 AM, "Pce on behalf of julien.meuric@orange.com" <
> pce-bounces@ietf.org on behalf of julien.meuric@orange.com> wrote:
>
>         Hi all,
>
>         This message initiates a 2-week PCE WG Last Call for
>         draft-ietf-pce-binding-label-sid-07. Please review and share your
>         feedback, whatever it is, using the PCE mailing list. This WGLC
> will end
>         on Thursday April 1st (no kidding).
>
>
>         Moreover, we have received a request from the authors for a code
> point
>         allocation to support interoperability testing.
>
>         RFC 7120 requires to meet the following criteria to proceed:
>
>         b. The format, semantics, processing, and other rules related to
>         handling the protocol entities defined by the code points
>         (henceforth called "specifications") must be adequately described
>         in an Internet-Draft.
>         c. The specifications of these code points must be stable; i.e., if
>         there is a change, implementations based on the earlier and later
>         specifications must be seamlessly interoperable.
>
>         If anyone believes that the draft does not meet these criteria, or
>         believes that early allocation is not appropriate for any other
>         reason, please send an email to the PCE mailing list explaining
> why. If
>         the chairs hear no objections by Thursday, March 25th, we will
> kick off
>         the "early" allocation request.
>
>         Thanks,
>
>         Dhruv & Julien
>
>
>
> _________________________________________________________________________________________________________________________
>
>         Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
>         pas etre diffuses, exploites ou copies sans autorisation. Si vous
> avez recu ce message par erreur, veuillez le signaler
>         a l'expediteur et le detruire ainsi que les pieces jointes. Les
> messages electroniques etant susceptibles d'alteration,
>         Orange decline toute responsabilite si ce message a ete altere,
> deforme ou falsifie. Merci.
>
>         This message and its attachments may contain confidential or
> privileged information that may be protected by law;
>         they should not be distributed, used or copied without
> authorisation.
>         If you have received this email in error, please notify the sender
> and delete this message and its attachments.
>         As emails may be altered, Orange is not liable for messages that
> have been modified, changed or falsified.
>         Thank you.
>
>         _______________________________________________
>         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
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*