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

+1

On Mon, Mar 29, 2021 at 10:06 AM Dhruv Dhody <dhruv.ietf@gmail.com> 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 <hayabusagsm@gmail.com> 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) <
>> mkoldych@cisco.com> 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 <pce-bounces@ietf.org> *On Behalf Of * Gyan Mishra
>>> *Sent:* Sunday, March 28, 2021 7:53 PM
>>> *To:* Siva Sivabalan <msiva282@gmail.com>
>>> *Cc:* pce@ietf.org; draft-ietf-pce-binding-label-sid@ietf.org; Stone,
>>> Andrew (Nokia - CA/Ottawa) <andrew.stone@nokia.com>
>>> *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 <msiva282@gmail.com>
>>> 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 <hayabusagsm@gmail.com>
>>> 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 <msiva282@gmail.com>
>>> 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 <hayabusagsm@gmail.com>
>>> 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) <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
>>>
>>> --
>>>
>>> [image: Image removed by sender.] <http://www.verizon.com/>
>>>
>>> *Gyan Mishra*
>>>
>>> *Network Solutions Architect *
>>>
>>> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>>>
>>> *M 301 502-1347*
>>>
>>>
>>>
>>> --
>>>
>>> [image: Image removed by sender.] <http://www.verizon.com/>
>>>
>>> *Gyan Mishra*
>>>
>>> *Network Solutions Architect *
>>>
>>> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>>>
>>> *M 301 502-1347*
>>>
>>>
>>>
>>> --
>>>
>>> [image: Image removed by sender.] <http://www.verizon.com/>
>>>
>>> *Gyan Mishra*
>>>
>>> *Network Solutions Architect *
>>>
>>> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>>>
>>> *M 301 502-1347*
>>>
>>>
>>>
>> --
>>
>> <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*
>>
>> _______________________________________________
>> Pce mailing list
>> Pce@ietf.org
>> https://www.ietf.org/mailman/listinfo/pce
>>
>

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

Attachment: image001.jpg