Hi Cyril, Yes I propose the PCE always send PCInint with 0/0.0.0.0/0::0 (for SR Policy). PCC would then allocate its own Source/ID and send that in PCRpt. That PCC allocated Source/ID would be used to track the Association, not the 0/0.0.0.0/0::0.
Associations in general are useful because they allow to refer to a grouping of PLSPs. Thanks, Mike. From: Cyril Margaria <[email protected]> Sent: Friday, November 6, 2020 9:21 AM To: Mike Koldychev (mkoldych) <[email protected]> Cc: Dhruv Dhody <[email protected]>; Mike Koldychev (mkoldych) <[email protected]>; Dhruv Dhody <[email protected]>; pce-chairs <[email protected]>; [email protected]; [email protected]; Stone, Andrew (Nokia - CA/Ottawa) <[email protected]> Subject: Re: [Pce] Association Source in draft-ietf-pce-segment-routing-policy-cp-01 Hi Mike On Fri, 6 Nov 2020 at 14:09, Mike Koldychev (mkoldych) <[email protected]<mailto:[email protected]>> wrote: Hi Dhruv, -----Original Message----- From: Dhruv Dhody <[email protected]<mailto:[email protected]>> Sent: Friday, November 6, 2020 8:27 AM To: Mike Koldychev (mkoldych) <[email protected]<mailto:[email protected]>> Cc: Dhruv Dhody <[email protected]<mailto:[email protected]>>; pce-chairs <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; Cyril Margaria <[email protected]<mailto:[email protected]>>; Stone, Andrew (Nokia - CA/Ottawa) <[email protected]<mailto:[email protected]>> Subject: Re: [Pce] Association Source in draft-ietf-pce-segment-routing-policy-cp-01 Hi Mike, On Fri, Nov 6, 2020 at 5:08 PM Mike Koldychev (mkoldych) <[email protected]<mailto:[email protected]>> 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. [MK] If the PCC allocates the Association Source/ID, then it's always going to choose a unique value, so there will never be any collision. So no, this "extra" logic won't exist if we go with my proposal. [MC] that's assuming that the PCE always sends 0, and not the previously returned value, at that point why bother using or tracking association ? <cut> BTW, what are your thoughts on the operator-configured association in the previous email? Not viable? [MK] You could set AssocExtID=Color, but I’m not sure what you would set Source to? Can we just set it to 0.0.0.0/0::0<http://0.0.0.0/0::0> and be done? Isn't that also a "special value"? AssocExtID=Color, endpoint Source should be a valid IP address, 0.0.0.0 looks OK, but I am rusty on that. 0 is reserved, 0xFFFF is all assocation, 1 works as a fixed number not in a reserved range. > 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. [MK] I fully understand, but the value of 0 is reserved in that RFC. Can each application use 0/0.0.0.0/0::0<http://0.0.0.0/0::0> for its own purpose? Is that allowed/forbidden in the RFC? <cut>
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
