Ah I see that now. Okay cool, glad to hear. Thanks Dhruv!
Andrew On 2021-01-20, 1:26 PM, "Dhruv Dhody" <[email protected]> wrote: Hi Andrew, Thanks for your message. The PCECC capability comes into play only when PCE also controls the label space and it is the PCECC that is allocating the label completely on its own. The other case is for PCE to pick a specific value for BSID and ask for the PCC to allocate and that does not require PCECC capability, it remains distinct as noted in section 4. If a PCE requires a PCC to allocate a specific binding value, it may do so by sending a PCUpd or PCInitiate message containing a TE-PATH- BINDING TLV. If the value can be successfully allocated, the PCC reports the binding value to the PCE. I can tighten up the text in section 7 to make it clearer and avoid any confusion. Thanks! Dhruv (as a WG participant) On Wed, Jan 20, 2021 at 10:18 PM Stone, Andrew (Nokia - CA/Ottawa) <[email protected]> wrote: > > Hi Dhruv, > > I agree that pce sending down binding SID should be in the binding SID document, however I have some concerns regarding some of the text that requires PCECC capability exchange in order to allocate the value and erroring otherwise for a PCE-INIT. While the binding SID document is independent of SR Policy, one of its key usage is for SR Policy Candidate path. If a user wants to manually program an SR Policy CP and define a specific BSID and deploy it via PCEP PCE-INIT, I do not think there should be a requirement on PCECC capabilities to do so. While PCEP is not BGP of course, I can manually configure an SR Policy Candidate path with a BSID and inject with BGP without any pre-negotiations. This applies to Replication Segment as well. The BSID needs to be valid in SRLB, not necessarily a valid CCI related value? > > Thanks! > Andrew > > > On 2021-01-20, 8:42 AM, "Pce on behalf of Dhruv Dhody" <[email protected] on behalf of [email protected]> wrote: > > Hi WG, Authors, > > As part of the handling of RTGDIR comments [1] for the PCECC I-D [2], > it was discovered that it is a better idea to handle the Binding SID > allocation by the PCE in the BSID I-D [3]. Julien and I agree. > > Also, it makes sense to move the new P-flag in the LSP object here > (from path segment WG I-D [4]). > > Cheng and I have this proposed update - > > Diff: https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-pce-binding-label-sid-05&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-binding-label-sid-06.txt > > Please let us know if anyone has any concerns with this approach. This > draft is in our WG LC Queue [5]. > > Thanks! > Dhruv/Cheng > > [1] https://mailarchive.ietf.org/arch/msg/rtg-dir/4n6FpBoDHjnGppKH4bcVotUu_hE/ > [2] https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for-pce-controller/ > [3] https://datatracker.ietf.org/doc/draft-ietf-pce-binding-label-sid/ > [4] https://datatracker.ietf.org/doc/draft-ietf-pce-sr-path-segment/ > [5] https://trac.ietf.org/trac/pce/wiki/WikiStart#WGLastCallQueue > > _______________________________________________ > Pce mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/pce > _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
