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 <[email protected]> Sent: Thursday, November 5, 2020 11:16 AM To: Mike Koldychev (mkoldych) <[email protected]> Cc: [email protected]; [email protected]; pce-chairs <[email protected]> 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) <[email protected]> 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 <[email protected]> > Sent: Thursday, November 5, 2020 10:43 AM > To: Mike Koldychev (mkoldych) <[email protected]> > Cc: [email protected]; [email protected]; > pce-chairs <[email protected]> > 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) <[email protected]> > 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 <[email protected]> > Sent: Thursday, November 5, 2020 1:59 AM > To: [email protected] > Cc: [email protected]; pce-chairs <[email protected]> > 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 <[email protected]> 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-policy > -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-polic > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
