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

[Siva Sivabalan <[e-mail]>]

Hi Gyan,

BSID can be allocated for RSVP-TE as well, and yes, there are use-cases for
that. The proposed PCEP extension is equally applicable to both SR-TE and
RSVP-TE.

Thanks,
Siva

On Sat, Mar 27, 2021 at 1:40 PM Gyan Mishra <[e-mail]> wrote:

>
>
> 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) <[e-mail]> wrote:
>
>> Thanks again for your help!
>>
>> Cheng
>>
>>
>>
>> -----Original Message-----
>> From: Stone, Andrew (Nokia - CA/Ottawa) [mailto:[e-mail]]
>> Sent: Saturday, March 27, 2021 2:42 AM
>> To: Chengli (Cheng Li) <[e-mail]>; [e-mail];
>> [e-mail]
>> Cc: [e-mail]
>> 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)" <
>> [e-mail] on behalf of [e-mail]> 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:
>> [e-mail]]
>>     Sent: Saturday, March 20, 2021 4:21 AM
>>     To: [e-mail]; [e-mail]
>>     Cc: [e-mail]
>>     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 [e-mail]" <
>> [e-mail] on behalf of [e-mail]> 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
>>         [e-mail]
>>         https://www.ietf.org/mailman/listinfo/pce
>>
>>
>> _______________________________________________
>> 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*
>
>