Hi Dhruv, The scenario is when the same SR Policy is created on the PCC and the PCE at the same time (or from multiple PCEs at the same time). If we follow RFC 8697 procedures, it can result in each entity generating its own Association ID and Source.
It's not a good protocol design to use Error messages to resolve timing/race conditions. IMO it's not acceptable that PCError messages can appear at random, even when every party is complying to the protocol. So I propose to enhance the RFC 8697 procedures to allow a PCEP speaker to request Association ID/Source to be allocated from the remote peer, by sending a 0 value, which is reserved today. Thanks, Mike. -----Original Message----- From: Dhruv Dhody <d...@dhruvdhody.com> Sent: Thursday, November 5, 2020 11:35 AM To: Mike Koldychev (mkoldych) <mkold...@cisco.com> Cc: draft-ietf-pce-segment-routing-policy...@ietf.org; pce@ietf.org; pce-chairs <pce-cha...@ietf.org> Subject: Re: Association Source in draft-ietf-pce-segment-routing-policy-cp-01 Hi Mike, And if you want to do that, please explain the scenario that requires the new procedure (and explain why not use RFC 8697 mechanisms itself). That was the original ask in the first email. Thanks! Dhruv PS. IMHO the race condition scenario can be solved by RFC 8697 and the SR Policy parameter check. On Thu, Nov 5, 2020 at 9:55 PM Mike Koldychev (mkoldych) <mkold...@cisco.com> wrote: > > Hi Dhruv, > > Yes, I think we should standardize this mechanism - allowing PCE to request > PCC to allocate Association ID and Source. > > Thanks, > Mike. > > -----Original Message----- > From: Dhruv Dhody <d...@dhruvdhody.com> > Sent: Thursday, November 5, 2020 11:16 AM > To: Mike Koldychev (mkoldych) <mkold...@cisco.com> > Cc: draft-ietf-pce-segment-routing-policy...@ietf.org; pce@ietf.org; > pce-chairs <pce-cha...@ietf.org> > Subject: Re: Association Source in > draft-ietf-pce-segment-routing-policy-cp-01 > > Hi Mike, > > On Thu, Nov 5, 2020 at 9:34 PM Mike Koldychev (mkoldych) <mkold...@cisco.com> > wrote: > > > > Hi Dhruv, > > > > > > > > Perhaps we can avoid this by letting PCE send PCInitiate message with > > Association Source set to some reserved value, like 0. This can mean that > > the PCE is basically requesting the PCC to allocate an Association Source > > and to “own” that Association. We already do this with the Association ID. > > PCE sets the ID to 0 in PCInitiate and PCC chooses an Association ID and > > reports it back. > > > > > > The comment was applicable for association-id as well as association-source! > The use of 0 as association ID is being introduced by your draft and not part > of the base RFC 8697 and that triggered the original email. Julien and I were > uncomfortable with that and wanted to understand what is new here for SR > policy association that requires a new procedure and cant be handled by RFC > 8697. > > Thanks, > Dhruv > > > > > Thanks, > > > > Mike. > > > > > > > > From: Dhruv Dhody <d...@dhruvdhody.com> > > Sent: Thursday, November 5, 2020 10:43 AM > > To: Mike Koldychev (mkoldych) <mkold...@cisco.com> > > Cc: draft-ietf-pce-segment-routing-policy...@ietf.org; pce@ietf.org; > > pce-chairs <pce-cha...@ietf.org> > > Subject: Re: Association Source in > > draft-ietf-pce-segment-routing-policy-cp-01 > > > > > > > > Hi Mike, > > > > > > > > On Thu, Nov 5, 2020 at 7:51 PM Mike Koldychev (mkoldych) > > <mkold...@cisco.com> wrote: > > > > Hi Dhruv, > > > > > > > > Thanks for bringing this up. > > > > > > > > By setting ASSO_SOURCE = PCC_ADDRESS, we guarantee that: > > > > all 3 parties: PCC, PCE1 and PCE2 agree on the same source, AND they > > agree without talking to each other. > > > > > > > > In your proposal below, if we set ASSO_SOURCE = NMS_ADDRESS, it seems that > > condition 1 may be fulfilled, but it requires exchange of PCRupt/PCUpd > > messages between the 3 entities, which violates condition 2. Please correct > > me if I misunderstood something. In the picture that you drew, you say that > > “Policy Endpoint=X” and “Association Source=X”, are you suggesting to use > > the policy endpoint as the ASSO_SOURCE? That would satisfy both conditions, > > but I’m not sure if you intended that? > > > > > > > > > > > > No, I did not! > > > > > > > > > > > > I believe condition 2 is important to satisfy, because otherwise there > > could be race conditions where the 3 parties have different ASSOC_SOURCE > > for the same policy. Consider what happens when all 3 parties try to create > > the same policy at the same time. > > > > > > > > > > > > The SR-Policy association is "dynamic" in nature, and we need to go by the > > association parameters we receive from the PCEP peer. Condition 2 of > > talking to each other is the very nature of a dynamic association! > > > > > > > > If the race condition is the issue to solve, we can use the SR-Policy > > parameters (color, endpoint, source). And make sure there is only one > > SR-Policy-association-group with a given set of SR-Policy parameters (and > > generate an error otherwise). The other PCE would learn about the > > association and can use it subsequently! > > > > > > > > I’m open to any proposal, but IMO we should respect the above two > > requirements. > > > > > > > > > > > > I feel the requirement 2 is not compatible with a dynamic association. > > > > > > > > Thanks! > > > > Dhruv > > > > > > > > > > > > Thanks, > > > > Mike. > > > > > > > > From: Dhruv Dhody <d...@dhruvdhody.com> > > Sent: Thursday, November 5, 2020 1:59 AM > > To: draft-ietf-pce-segment-routing-policy...@ietf.org > > Cc: pce@ietf.org; pce-chairs <pce-cha...@ietf.org> > > Subject: 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 > > -0 > > 1#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 <internet-dra...@ietf.org> 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 <headend, color, end-point> 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-poli > > cy > > -cp/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-pce-segment-routing-policy-cp > > -0 > > 1 > > https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing > > -p > > olicy-cp-01 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-segment-routing-pol > > ic > > y-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
