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
