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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]>> wrote: Thanks again for your help! Cheng -----Original Message----- From: Stone, Andrew (Nokia - CA/Ottawa) [mailto:[email protected]<mailto:[email protected]>] Sent: Saturday, March 27, 2021 2:42 AM To: Chengli (Cheng Li) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[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]<mailto:[email protected]> on behalf of [email protected]<mailto:[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]<mailto:[email protected]>] Sent: Saturday, March 20, 2021 4:21 AM To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[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]<mailto:[email protected]>" <[email protected]<mailto:[email protected]> on behalf of [email protected]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/pce -- [Image removed by sender.]<http://www.verizon.com/> Gyan Mishra Network Solutions Architect Email [email protected]<mailto:[email protected]> M 301 502-1347 -- [Image removed by sender.]<http://www.verizon.com/> Gyan Mishra Network Solutions Architect Email [email protected]<mailto:[email protected]> M 301 502-1347 -- [Image removed by sender.]<http://www.verizon.com/> Gyan Mishra Network Solutions Architect Email [email protected]<mailto:[email protected]> M 301 502-1347
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
