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 <hayabusa...@gmail.com> 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) <c...@huawei.com> wrote: > >> Thanks again for your help! >> >> Cheng >> >> >> >> -----Original Message----- >> From: Stone, Andrew (Nokia - CA/Ottawa) [mailto:andrew.st...@nokia.com] >> Sent: Saturday, March 27, 2021 2:42 AM >> To: Chengli (Cheng Li) <c...@huawei.com>; julien.meu...@orange.com; >> pce@ietf.org >> Cc: draft-ietf-pce-binding-label-...@ietf.org >> 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)" < >> pce-boun...@ietf.org on behalf of c...@huawei.com> 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: >> andrew.st...@nokia.com] >> Sent: Saturday, March 20, 2021 4:21 AM >> To: julien.meu...@orange.com; pce@ietf.org >> Cc: draft-ietf-pce-binding-label-...@ietf.org >> 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 julien.meu...@orange.com" < >> pce-boun...@ietf.org on behalf of julien.meu...@orange.com> 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 >> Pce@ietf.org >> https://www.ietf.org/mailman/listinfo/pce >> >> >> _______________________________________________ >> Pce mailing list >> Pce@ietf.org >> https://www.ietf.org/mailman/listinfo/pce >> > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* > > > > *M 301 502-1347* > >
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
