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

[Gyan Mishra <[e-mail]>]

Understood.  I-D covers only BSID control plane handling for both RSVP-TE
and SR-TE

However, for RSVP-TE their is only a control plane component where SR both
control and data plane of which the SR-MPLS and SRv6 data plane is handled
in SPRING/MPLS/6MAN.



Gyan

On Mon, Mar 29, 2021 at 10:07 AM Siva Sivabalan <[e-mail]> wrote:

> +1
>
> On Mon, Mar 29, 2021 at 10:06 AM Dhruv Dhody <[e-mail]> wrote:
>
>> Hi Gyan,
>>
>> As a WG member...
>>
>> IMHO PCE I-D should not go into the data-plane handling of BSID, that is
>> SPRING/MPLS/6MAN perview.
>>
>> Thanks!
>> Dhruv
>>
>>
>> On Mon, Mar 29, 2021 at 7:21 PM Gyan Mishra <[e-mail]>
>> wrote:
>>
>>> Hi Mike
>>>
>>> Is the usage for BSID only for control plane signaling as I described
>>> it.
>>>
>>> What other use cases exist and maybe we should add to the draft.
>>>
>>> Thanks
>>>
>>> Gyan
>>>
>>> On Mon, Mar 29, 2021 at 4:50 AM Mike Koldychev (mkoldych) <
>>> [e-mail]> wrote:
>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> I think that BSID is a concept that applies equally well to RSVP-TE and
>>>> SR-TE. There are many use-cases for RSVP tunnels having a BSID and we
>>>> definitely DO NOT want to limit it to just SR-TE.
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Mike.
>>>>
>>>>
>>>>
>>>> *From:* Pce <[e-mail]> *On Behalf Of * Gyan Mishra
>>>> *Sent:* Sunday, March 28, 2021 7:53 PM
>>>> *To:* Siva Sivabalan <[e-mail]>
>>>> *Cc:* [e-mail]; [e-mail]; Stone,
>>>> Andrew (Nokia - CA/Ottawa) <[e-mail]>
>>>> *Subject:* Re: [Pce] WG Last Call for
>>>> draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Hi Siva
>>>>
>>>>
>>>>
>>>> I believe  I was missing the signaling aspect for the PCE to build the
>>>> contiguous end to end LSP and that requires BSID to be signaled over
>>>> RSVP-TE which is although agnostic to data plane BSID component binding the
>>>> candidate path to the forwarding plane, is a requirement for end to end
>>>> control plane signaling for the single LSP end to end path instantiation.
>>>>
>>>>
>>>>
>>>> The BSID signaling concept is somewhat analogous concept to LDP
>>>> tunneling over RSVP-TE tunnel stitching for an end to end LSP instantiation.
>>>>
>>>>
>>>>
>>>> Thank you Siva for the clarification.
>>>>
>>>>
>>>>
>>>> Gyan
>>>>
>>>>
>>>>
>>>> On Sun, Mar 28, 2021 at 7:33 PM Siva Sivabalan <[e-mail]>
>>>> wrote:
>>>>
>>>> Hi Gyan,
>>>>
>>>>
>>>>
>>>> This ID is all about signaling BSID for RSVP-TE tunnels and SR policies
>>>> via PCEP.
>>>>
>>>>
>>>>
>>>> Please do not confuse signaling aspects with how BSID is used.
>>>>
>>>>
>>>>
>>>> There is no change required in the ID.
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Siva
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Sun, Mar 28, 2021 at 7:25 PM Gyan Mishra <[e-mail]>
>>>> wrote:
>>>>
>>>>
>>>>
>>>> All
>>>>
>>>>
>>>>
>>>> After further review with Siva the use case is for connecting SR
>>>> islands over RSVP-TE core.
>>>>
>>>>
>>>>
>>>> So this is for stitching SR-TE on the edge islands binding SID to core
>>>> RSVP-TE tunnel.
>>>>
>>>>
>>>>
>>>> One major gap  of RSVP-TE is the VRF / VPN coloring capability that in
>>>> order to achieve per VRF coloring mapping of VRF to a discrete TE tunnel
>>>> requires a separate loopback and static routes to egress PE so it does not
>>>> scale.  So for as many RSVP mapped tunnels that exist you need that many
>>>> loopbacks and static routes for the next hop rewrite to the RSVP tunnel
>>>> next hop.
>>>>
>>>>
>>>>
>>>> So this Major gap is filled with SR VRF and app flow coloring
>>>> capability that with SR-TE Policy BSID bound to candidate path can provide
>>>> the scalability per VRF coloring.
>>>>
>>>>
>>>>
>>>> So at the edges you may have many 100s of colored RSVP tunnels but as
>>>> the core does not scale you can not provide a 1-1 mapping of SR-TE tunnel
>>>> to RSVP tunnel.  So you would have many to 1 mappings of SR-TE tunnels to
>>>> single or aggregate.
>>>>
>>>>
>>>>
>>>> So in my mind to only way the BSID would come into play is if you could
>>>> do a 1-1 mapping of SR-TE tunnel to RSVP tunnel.  Technically that is not
>>>> possible.
>>>>
>>>>
>>>>
>>>> For PCE to compute end to end path in this scenario does RSVP-TE
>>>> require the BSID for the stitching even if a many SR-TE colors to single
>>>> RSVP-TE tunnel mapping. I would not think so.
>>>>
>>>>
>>>>
>>>> If we think that for PCE to build the end to end path even for the end
>>>> to end path in this scenario requires BSID binding to the RSVP-TE single
>>>> path to make contiguous end to end then I agree technically we do need to
>>>> make this inclusive of RSVP-TE.
>>>>
>>>>
>>>>
>>>> I think we need to clear this up and if this use case is really not
>>>> feasible then we should remove any mention of BSID use with RSVP-TE tunnel.
>>>>
>>>>
>>>>
>>>> Kind Regards
>>>>
>>>>
>>>>
>>>> Gyan
>>>>
>>>>
>>>>
>>>> On Sat, Mar 27, 2021 at 3:05 PM Siva Sivabalan <[e-mail]>
>>>> wrote:
>>>>
>>>> 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
>>>>
>>>> --
>>>>
>>>> [image: Image removed by sender.] <http://www.verizon.com/>
>>>>
>>>> *Gyan Mishra*
>>>>
>>>> *Network Solutions Architect *
>>>>
>>>> *Email [e-mail] <[e-mail]>*
>>>>
>>>> *M 301 502-1347*
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> [image: Image removed by sender.] <http://www.verizon.com/>
>>>>
>>>> *Gyan Mishra*
>>>>
>>>> *Network Solutions Architect *
>>>>
>>>> *Email [e-mail] <[e-mail]>*
>>>>
>>>> *M 301 502-1347*
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> [image: Image removed by sender.] <http://www.verizon.com/>
>>>>
>>>> *Gyan Mishra*
>>>>
>>>> *Network Solutions Architect *
>>>>
>>>> *Email [e-mail] <[e-mail]>*
>>>>
>>>> *M 301 502-1347*
>>>>
>>>>
>>>>
>>> --
>>>
>>> <http://www.verizon.com/>
>>>
>>> *Gyan Mishra*
>>>
>>> *Network Solutions A**rchitect *
>>>
>>> *Email [e-mail] <[e-mail]>*
>>>
>>>
>>>
>>> *M 301 502-1347*
>>>
>>> _______________________________________________
>>> 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*