Hi Mike, On Fri, Nov 6, 2020 at 5:08 PM Mike Koldychev (mkoldych) <mkoldych=40cisco....@dmarc.ietf.org> wrote: > > Hi Dhruv, > > I don't think it's valid to dismiss race conditions in the protocol because > they are "rare". If they can happen at all means that implementations need to > have extra logic to handle these race conditions. >
Doesn't this "extra" logic exist anyway, as you must make sure there is only one SR policy association with a given set of SR Policy parameters under normal operations. > What is rare today in your deployment, may not be rare tomorrow in another > deployment. I can think of a case where a PCC connects simultaneously to many > PCEs which create many thousands of SR CPs on it. If they all send PCInit > messages before the head-end replies to them with PCRpt, then you will have > this "rare" race condition repeated thousands of times. Each PCE will choose > different Source/ID in PCInit and PCC will have to send PCError back to them. > You make a good point here! What you describe is "possible"! > Furthermore, you need logic on the PCC to choose the right Association out of > many. The logic is the first association created for a given SR policy at the PCC and that's it! > There are also undesirable security/privacy implications of putting PCE/NMS > IP address into the Source. It means that if two PCEs are controlling > different CPs of the same policy, then one of the PCEs can learn the IP > address of the other by reading the Association Source of the PCRpt messages > from the PCC. This is especially bad, because this Association Source has no > semantic meaning in SR Policy and may be hidden in normal show commands. > Furthermore, this IP address of the PCE/NMS that created the policy will be > associated to the Policy even after PCE disconnects from the PCC, as long as > any CP remains in that Policy. > If any of this is really an issue, we got to update RFC 8697! I am not advocating for that BTW :) Privacy of one PCE from another in an SR domain (under same administrative control) is quite a stretch IMHO. BTW, what are your thoughts on the operator-configured association in the previous email? Not viable? > All of this can be avoided if we just allow Source/ID to be 0 in PCInit > messages. Is that really such a big change? > No, but the WG worked on RFC 8697 to make sure all the associations can be handled in a common way as much as possible. When deviating from that, IMHO a higher bar should be met. The WG should ponder if it is met here based on the scenario described above, that's all. Thanks! Dhruv PS. Process comment - If the WG decides this is needed (and I am in rough), the procedure needs to be generic and outside the SR policy draft in a separate I-D, so that other associations can also use it. > Thanks, > Mike. > > -----Original Message----- > From: Dhruv Dhody <d...@dhruvdhody.com> > Sent: Friday, November 6, 2020 5:15 AM > To: Mike Koldychev (mkoldych) <mkold...@cisco.com> > Cc: Stone, Andrew (Nokia - CA/Ottawa) <andrew.st...@nokia.com>; Cyril > Margaria <cyril.marga...@gmail.com>; pce@ietf.org; > draft-ietf-pce-segment-routing-policy...@ietf.org; pce-chairs > <pce-cha...@ietf.org> > Subject: Re: [Pce] Association Source in > draft-ietf-pce-segment-routing-policy-cp-01 > > Hi Mike, Andrew, Cyril, > > Thanks for a great discussion, more inline... > > On Fri, Nov 6, 2020 at 7:23 AM Mike Koldychev (mkoldych) <mkold...@cisco.com> > wrote: > > > > Hi Andrew, > > > > See inline with [MK] > > > > Hi Mike, Dhruv, Cyril: > > > > We do use errors on initiate messages during race conditions, for example, > > symbolic name uniqueness on pce-initiated vanilla LSPs. So error based > > protection to enforce uniqueness and protect race conditions is > > manageable/done today. > > > > [MK] The chances of symbolic-names being the same is much less than the > > chance of Association Sources being different. Also the symbolic-name > > actually has an important meaning, the Association Source has no meaning. > > Getting a flood of PCError messages about a field that has no meaning would > > be bad. If we can eliminate these error messages completely, why not do > > that? > > > > > > [DD] First, the flood of errors is a stretch by any means :) And I agree with > Andrew about the 'initiate' case. > > > > > However: would it make sense for the SRPAG definition, to be defined by the > > ‘first’ entity which created the candidate path? when it’s a shared > > construct with other entities which are now forced to re-use that value? > > Using a Virtual IP on the PCE(s) would certainly help, but wouldn’t work > > correctly with mixed use PCC/PCE init candidate paths (would anyone do > > that?), or different vendor PCE/clusters/different virtual IPs would add > > more complexity. The common element I see is the uniqueness on PCC and the > > fact that SRPAG==SRPolicy. Since Association Source is ‘scoping for the > > association ID’, and there is no association scoping used/needed, then the > > value is essentially unused – therefore just a dummy value assigned by PCC? > > > > [MK] Yes it’s unused! I like the idea of PCC choosing it. > > > > [DD] For a dynamic association, the default is for the local PCEP speaker to > be the association source unless local policy says otherwise. > > Anyways, based on the requirement that you had in the earlier email - > > Mike> 1. all 3 parties: PCC, PCE1 and PCE2 agree on the same source, AND > Mike> 2. they agree without talking to each other. > > One can make the SRPolicy association to be considered as an > operator-configured association (i.e. association parameters configured by > the operator beforehand on the PCEP peers). > > Hear me out, we anyway have the SR Policy configuration happening at all > peers, could we say that the PCEP association parameters > (type/id/source..) need also be set by the operator. If you are worried that > it would be extra configuration, there could be rules set by the operator for > filling the association parameters using SRPolicy such as > Assoc-type=SR-Policy, Assoc-ID/Extended Association ID=Color, > Assoc-source=headend/special value. > > Note that allowing SRPolicy to be both dynamic and operator-configured is > also a possiblity. > > > > > > > I think there is a bit of ambiguity as mentioned (PCEP session? Router ID? > > ), and still run the risk that PCEP is terminating on different addresses > > towards different PCEs / different view of the ‘PCC address’. Requesting > > the PCC to just assign the (unused?) value seems to like a way to avoid all > > of the above. With that said, I could be missing other implications/usage > > of the Association Source field. > > > > [MK] Yes, requesting the PCC to assign a value would resolve this issue. > > But the question is what value would the PCE send in PCInit message when > > first creating a policy? I propose that PCE can send just 0.0.0.0 or 0::0 > > in PCInit messages to indicate to the PCC to pick a value. Alternatively, > > PCE can send any value of Association Source/ID, but the PCC will not honor > > it and just choose its own Association Source/ID. > > > > > > I would like us (as a WG) to explore if we can use existing mechanisms first > (the very reason we have common association groupings). > As of now, I am not sold that the use of error in a 'rare' > race-condition is such a bad protocol design that we need to update > RFC8697 and introduce new rules for dynamic associations, esp when other ways > exist. > > What do others think? > > Thanks! > Dhruv > > > > > Cheers > > Andrew > > > > > > > > From: Pce <pce-boun...@ietf.org> on behalf of "Mike Koldychev > > (mkoldych)" <mkoldych=40cisco....@dmarc.ietf.org> > > Date: Thursday, November 5, 2020 at 1:30 PM > > To: Cyril Margaria <cyril.marga...@gmail.com>, Dhruv Dhody > > <d...@dhruvdhody.com> > > Cc: "pce@ietf.org" <pce@ietf.org>, > > "draft-ietf-pce-segment-routing-policy...@ietf.org" > > <draft-ietf-pce-segment-routing-policy...@ietf.org>, pce-chairs > > <pce-cha...@ietf.org> > > Subject: Re: [Pce] Association Source in > > draft-ietf-pce-segment-routing-policy-cp-01 > > > > > > > > Hi Cyril, > > > > > > > > See inline with [MK] > > > > > > > > From: Cyril Margaria <cyril.marga...@gmail.com> > > Sent: Thursday, November 5, 2020 11:35 AM > > To: Dhruv Dhody <d...@dhruvdhody.com> > > Cc: Mike Koldychev (mkoldych) <mkold...@cisco.com>; pce@ietf.org; > > pce-chairs <pce-cha...@ietf.org>; > > draft-ietf-pce-segment-routing-policy...@ietf.org > > Subject: Re: [Pce] Association Source in > > draft-ietf-pce-segment-routing-policy-cp-01 > > > > > > > > > > > > I have a related question: how do you define the "PCC address", PCEP > > session address , one router id? > > > > [MK] By PCC Address, I meant the IP address of the PCEP session. I believe > > a better approach is actually to set Association Source in PCInitiate > > message to 0.0.0.0 or 0::0 and let the PCC allocate the correct Source, > > same as how Association ID allocation is proposed in the draft. > > > > > > > > > > > > For the association source race condition, the race condition will result > > in a "Conflicting SRPAG TLV" from a PCInitiate/PCUpd, the PCE can use the > > correct SRPAG. > > > > [MK] It’s not a good protocol design to allow PCError messages to appear > > randomly when all the parties are following the protocol. Would really like > > to avoid that. > > > > > > > > > > > > > > > > On Thu, 5 Nov 2020 at 16:16, Dhruv Dhody <d...@dhruvdhody.com> wrote: > > > > 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 > > > -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 <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 > > > -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-pol > > > icy-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 > _______________________________________________ > 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
