[Pce] Association Source in draft-ietf-pce-segment-routing-policy-cp-01
Hi Authors, In https://tools.ietf.org/html/draft-ietf-pce-segment-routing-policy-cp-01#section-4.2 , you state - The Association Source MUST be set to the PCC's address. This >applies for both PCC-initiated and PCE-initiated candidate paths. >The reasoning for this is that if different PCEs could set their own >Association Source, then the candidate paths instantiated by >different PCEs would by definition be in different PCEP Associations, >which contradicts our requirement that the SR Policy is represented >by an Association. > >The Association ID MUST be chosen by the PCC when the SR policy is >allocated. In PCRpt messages from the PCC, the Association ID MUST >be set to the unique value that was allocated by the PCC at the time >of policy creation. In PCInit messages from the PCE, the Association >ID MUST be set to the reserved value 0, which indicates that the PCE >is asking the PCC to choose an ID value. The PCE MUST NOT send the >Extended Association ID TLV in the PCInit messages. But the base RFC 8697 https://www.rfc-editor.org/rfc/rfc8697.html#section-6.1.3 gave quite a bit of leeway while setting the association source. Consider 2 PCEs - PCE1 & PCE2, I am assuming if candidate paths are created via two different PCEs both will be aware of SR Policy identifiers (color, end-point, etc). When PCE1 initiates CP1, it could use the association source as Virtual-IP or NMS (instead of PCE1). The PCE2 will learn about the association and the corresponding SR policy parameters via the PCRpt message which is sent to both PCEs. So when the PCE2 initiates CP2, it could use the same association! This was the very reason to include the flexibility in setting the association source in RFC 8697. Julien and I discussed this and we feel you are trying to solve the issue of sharing an association ID between several PCEs by using a new mean than the one in RFC 8697. If you have other reasons then please state them, otherwise, RFC 8697 should take precedence. Thanks! Dhruv & Julien PS. I quickly drew a figure if that helps (see attached)! On Tue, Oct 27, 2020 at 8:42 PM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Path Computation Element WG of the IETF. > > Title : PCEP extension to support Segment Routing Policy > Candidate Paths > Authors : Mike Koldychev > Siva Sivabalan > Colby Barth > Shuping Peng > Hooman Bidgoli > Filename: draft-ietf-pce-segment-routing-policy-cp-01.txt > Pages : 20 > Date: 2020-10-27 > > Abstract: >This document introduces a mechanism to specify a Segment Routing >(SR) policy, as a collection of SR candidate paths. An SR policy is >identified by tuple. An SR policy can >contain one or more candidate paths where each candidate path is >identified in PCEP via an PLSP-ID. This document proposes extension >to PCEP to support association among candidate paths of a given SR >policy. The mechanism proposed in this document is applicable to >both MPLS and IPv6 data planes of SR. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-pce-segment-routing-policy-cp-01 > > https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-01 > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-segment-routing-policy-cp-01 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > ___ > 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
Re: [Pce] WG adoption poll for draft-stone-pce-local-protection-enforcement-02.
Hi Tarek, There is a proposal [1] to extend the support for the P (Processing-Rule) and I (Ignore) flag in the common object header (of PCEP objects, originally from RFC 5440) to stateful PCEP messages. Do check it out and let the WG know if that covers what you have in mind. Thanks! Dhruv [1] https://datatracker.ietf.org/doc/draft-dhody-pce-stateful-pce-optional/ On Wed, Nov 4, 2020 at 11:44 PM Tarek Saad wrote: > > I believe the issue the draft is tackling is useful and I support adoption. I > also believe the idea of "enforcing" a constraint can be generalized (e.g. to > other constraints). Ideally, we can consider an approach that can be extended > to other constraints in future too. > > Regards, > Tarek > > On 10/21/20, 5:14 PM, "Pce on behalf of Stone, Andrew (Nokia - CA/Ottawa)" > wrote: > > Hello, > > As co-author, I support the adoption. Document describes various use case > needs, has implementations, and has been updated based on existing feedback. > Would be good to have adopted to move to early IANA codepoint allocations to > allow implementation to progress further, as well as further WG refinement. > > Thank you > Andrew > > On 2020-10-21, 9:41 AM, "Pce on behalf of Dhruv Dhody" > wrote: > > Hi WG, > > This email begins the WG adoption poll for > draft-stone-pce-local-protection-enforcement-02. > > > https://datatracker.ietf.org/doc/html/draft-stone-pce-local-protection-enforcement-02 > > Should this draft be adopted by the PCE WG? Please state your reasons > - Why / Why not? What needs to be fixed before or after adoption? Are > you willing to work on this draft? Review comments should be posted to > the list. > > This adoption poll will end on 9th Nov 2020 (Monday). > > Thanks! > Dhruv & Julien > > ___ > 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 ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG adoption poll for draft-stone-pce-local-protection-enforcement-02.
I believe the issue the draft is tackling is useful and I support adoption. I also believe the idea of "enforcing" a constraint can be generalized (e.g. to other constraints). Ideally, we can consider an approach that can be extended to other constraints in future too. Regards, Tarek On 10/21/20, 5:14 PM, "Pce on behalf of Stone, Andrew (Nokia - CA/Ottawa)" wrote: Hello, As co-author, I support the adoption. Document describes various use case needs, has implementations, and has been updated based on existing feedback. Would be good to have adopted to move to early IANA codepoint allocations to allow implementation to progress further, as well as further WG refinement. Thank you Andrew On 2020-10-21, 9:41 AM, "Pce on behalf of Dhruv Dhody" wrote: Hi WG, This email begins the WG adoption poll for draft-stone-pce-local-protection-enforcement-02. https://datatracker.ietf.org/doc/html/draft-stone-pce-local-protection-enforcement-02 Should this draft be adopted by the PCE WG? Please state your reasons - Why / Why not? What needs to be fixed before or after adoption? Are you willing to work on this draft? Review comments should be posted to the list. This adoption poll will end on 9th Nov 2020 (Monday). Thanks! Dhruv & Julien ___ 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 ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG adoption poll for draft-stone-pce-local-protection-enforcement-02.
Hi WG, Just a reminder, the WG Adoption poll ends on Monday 9th Nov, please respond to the call with your support (or not), comments, etc. Please be more vocal on the list [1]. Thanks! Dhruv & Julien [1] https://www.ietf.org/proceedings/108/slides/slides-108-pce-1-introduction-01 > Please be Vocal > > o During WG Adoption and WG LC calls, the response is less. > > o Please be vocal on the list to help us gauge the consensus better. > > o The working group mailing lists are looked at by the IESG, IAB, and others (internal and external to IETF) to determine interest/participation level in our standards process. > > o Please review ideas from your peers, these are community outputs of the working group as a whole. > On Wed, Oct 21, 2020 at 7:10 PM Dhruv Dhody wrote: > Hi WG, > > This email begins the WG adoption poll for > draft-stone-pce-local-protection-enforcement-02. > > > https://datatracker.ietf.org/doc/html/draft-stone-pce-local-protection-enforcement-02 > > Should this draft be adopted by the PCE WG? Please state your reasons > - Why / Why not? What needs to be fixed before or after adoption? Are > you willing to work on this draft? Review comments should be posted to > the list. > > This adoption poll will end on 9th Nov 2020 (Monday). > > Thanks! > Dhruv & Julien > ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
