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

[Cyril Margaria <[e-mail]>]

I have a related question: how do you define the "PCC address", PCEP
session address , one router id?

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.




On Thu, 5 Nov 2020 at 16:16, Dhruv Dhody <[e-mail]> wrote:

> Hi Mike,
>
> On Thu, Nov 5, 2020 at 9:34 PM Mike Koldychev (mkoldych)
> <[e-mail]> 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 <[e-mail]>
> > Sent: Thursday, November 5, 2020 10:43 AM
> > To: Mike Koldychev (mkoldych) <[e-mail]>
> > Cc: [e-mail]; [e-mail];
> pce-chairs <[e-mail]>
> > 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) <
> [e-mail]> 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 <[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
>
> _______________________________________________
> Pce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pce
>