Re: [Pce] Association Source in draft-ietf-pce-segment-routing-policy-cp-01

[Dhruv Dhody <[e-mail]>]

Hi Mike,

On Thu, Nov 5, 2020 at 7:51 PM Mike Koldychev (mkoldych) <[e-mail]>
wrote:

> Hi Dhruv,
>
>
>
> Thanks for bringing this up.
>
>
>
> By setting ASSO_SOURCE = PCC_ADDRESS, we guarantee that:
>
>    1. all 3 parties: PCC, PCE1 and PCE2 agree on the same source, AND
>    2. 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 <[e-mail]>
> *Sent:* Thursday, November 5, 2020 1:59 AM
> *To:* [e-mail]
> *Cc:* [e-mail]; pce-chairs <[e-mail]>
> *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 <[e-mail]> 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-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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pce
>
>