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 >
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
