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 <[email protected]> wrote: > +1 > > On Mon, Mar 29, 2021 at 10:06 AM Dhruv Dhody <[email protected]> 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 <[email protected]> >> 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) < >>> [email protected]> 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 <[email protected]> *On Behalf Of * Gyan Mishra >>>> *Sent:* Sunday, March 28, 2021 7:53 PM >>>> *To:* Siva Sivabalan <[email protected]> >>>> *Cc:* [email protected]; [email protected]; Stone, >>>> Andrew (Nokia - CA/Ottawa) <[email protected]> >>>> *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 <[email protected]> >>>> 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 <[email protected]> >>>> 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 <[email protected]> >>>> 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 <[email protected]> >>>> 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) <[email protected]> >>>> wrote: >>>> >>>> Thanks again for your help! >>>> >>>> Cheng >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Stone, Andrew (Nokia - CA/Ottawa) [mailto:[email protected]] >>>> >>>> Sent: Saturday, March 27, 2021 2:42 AM >>>> To: Chengli (Cheng Li) <[email protected]>; [email protected]; >>>> [email protected] >>>> Cc: [email protected] >>>> 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)" < >>>> [email protected] on behalf of [email protected]> 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: >>>> [email protected]] >>>> Sent: Saturday, March 20, 2021 4:21 AM >>>> To: [email protected]; [email protected] >>>> Cc: [email protected] >>>> 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 [email protected]" >>>> <[email protected] on behalf of [email protected]> 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 >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/pce >>>> >>>> >>>> _______________________________________________ >>>> Pce mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/pce >>>> >>>> -- >>>> >>>> [image: Image removed by sender.] <http://www.verizon.com/> >>>> >>>> *Gyan Mishra* >>>> >>>> *Network Solutions Architect * >>>> >>>> *Email [email protected] <[email protected]>* >>>> >>>> *M 301 502-1347* >>>> >>>> >>>> >>>> -- >>>> >>>> [image: Image removed by sender.] <http://www.verizon.com/> >>>> >>>> *Gyan Mishra* >>>> >>>> *Network Solutions Architect * >>>> >>>> *Email [email protected] <[email protected]>* >>>> >>>> *M 301 502-1347* >>>> >>>> >>>> >>>> -- >>>> >>>> [image: Image removed by sender.] <http://www.verizon.com/> >>>> >>>> *Gyan Mishra* >>>> >>>> *Network Solutions Architect * >>>> >>>> *Email [email protected] <[email protected]>* >>>> >>>> *M 301 502-1347* >>>> >>>> >>>> >>> -- >>> >>> <http://www.verizon.com/> >>> >>> *Gyan Mishra* >>> >>> *Network Solutions A**rchitect * >>> >>> *Email [email protected] <[email protected]>* >>> >>> >>> >>> *M 301 502-1347* >>> >>> _______________________________________________ >>> Pce mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/pce >>> >> -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
