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

[Gyan Mishra <[e-mail]>]

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
>>>>>
>>>> --
>>>>
>>>> <http://www.verizon.com/>
>>>>
>>>> *Gyan Mishra*
>>>>
>>>> *Network Solutions A**rchitect *
>>>>
>>>> *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*
>>
>> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*