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

Dhruv Dhody <dd@dhruvdhody.com> Fri, 06 November 2020 10:15 UTC

Return-Path: <dd@dhruvdhody.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423BB3A1039 for <pce@ietfa.amsl.com>; Fri, 6 Nov 2020 02:15:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dhruvdhody-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KoTH2KxEF01M for <pce@ietfa.amsl.com>; Fri, 6 Nov 2020 02:15:34 -0800 (PST)
Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 178A03A103A for <pce@ietf.org>; Fri, 6 Nov 2020 02:15:33 -0800 (PST)
Received: by mail-pl1-x634.google.com with SMTP id t18so461945plo.0 for <pce@ietf.org>; Fri, 06 Nov 2020 02:15:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dhruvdhody-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=C2PCrd1T7FrqTnu7sUjVD++lD+jTUE1Qr6Gwogb/ldw=; b=JKOdz6x6sxYjSRulRyWiYQwtkgS0ZvrmYiucx26U9t/PsHGt8Xop+vuWHgDij8ejfQ tBBuQN57nDBOzTMUs2cuDj2LqYuRnzwM/L4Lln/mz0ieZHc0X/hTWeRgweoDEPlfNl0q TDaGwBsTnYSh2/KYvXtfVa0B5fC28y8BUshDTSZGf4FA/qEiVn29Ylg1qXDw7kWSB/ZA U7FNjwm+xmN6vX1AUh5nGP8qqKWaueAHuW5PEK3+LGRdqk7k3E7qHcYI/KePhBud9qhr LaZMSq7boa6ecPlPoJ5RkcwpRvo6JJBkxHzF/CMCpxMMu4mcz0CVL/GUIYnTIkjnK7mx 62gQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=C2PCrd1T7FrqTnu7sUjVD++lD+jTUE1Qr6Gwogb/ldw=; b=e35n7Jnv7UqcUcrwlaKNzpNYSUAxsj3jo+dAkpSBeB107t7j2bLnqiAul4IoBRdr/X vPLLAkbXJMbY92T+wkMGqYLJXk/+6ybn8YiIEe7zdHQ08UwEpMj/vPYLsiwqHyySjdYl p+zMuuCKINgaRS97YKv08FPCU7BQGfbsQpcFDVx/RjGy2iSYQBF6RyBu3lAawUyE9g73 SkL2d/s4fAMMNQEmenyl1ZmMHKCwTQJQdnWlhOylfUrMKGE3KWpvfY6hOs8vj+x98Q+C 3MkeVDXfer15/HVxqFqDlw3gwkJpBp4UWp61L7GWIyJ1pROFrUDM66CIMRvqNFyyR7yh HROg==
X-Gm-Message-State: AOAM531e5mo2+XK6uz71ACv1bMdn54owagDegJXbOoxmigA9phlx73le OHfPjwLhKmrxd0kjBByzPTr+jV9iYLsL2z87knXw9Q==
X-Google-Smtp-Source: ABdhPJzbjjPIBlb4ApUFGFi7bcUMqVb8/CZZBPAmlRJNYGZ4p5e3dbTR06ZwitEHvrFg/aTtqo7Uq1o7I/QjbbSCj5o=
X-Received: by 2002:a17:902:bc82:b029:d6:4ee5:87d0 with SMTP id bb2-20020a170902bc82b02900d64ee587d0mr1175612plb.40.1604657733239; Fri, 06 Nov 2020 02:15:33 -0800 (PST)
MIME-Version: 1.0
References: <160381151685.9996.2859530250089756904@ietfa.amsl.com> <CAP7zK5YOtdr1=MzErfcNh8Gf6PvFCA7YAAk=tuS=ntRA4OjnaQ@mail.gmail.com> <DM6PR11MB3802A59D7A3A7C9EB9EAD39CD3EE0@DM6PR11MB3802.namprd11.prod.outlook.com> <CAP7zK5Yfo4_O956y2aJkkNfpCgBZJmBhqUkcO+TCzwwW6-VP2w@mail.gmail.com> <DM6PR11MB38022F27FF41E28F16F9E899D3EE0@DM6PR11MB3802.namprd11.prod.outlook.com> <CAP7zK5b-kr9LZenvgFiMzqVT-YUCaPgMub+t4peEV=HQ17HL_g@mail.gmail.com> <CADOd8-t5ZD3KUF1xbmrCGWiqipNB3MhEhxZvzQDeuhEeUvyFwA@mail.gmail.com> <DM6PR11MB3802E5451065366739A8A385D3EE0@DM6PR11MB3802.namprd11.prod.outlook.com> <571AB173-2A35-4037-967B-87C3797809CF@nokia.com> <DM6PR11MB38021AE20504CD3522A03034D3ED0@DM6PR11MB3802.namprd11.prod.outlook.com>
In-Reply-To: <DM6PR11MB38021AE20504CD3522A03034D3ED0@DM6PR11MB3802.namprd11.prod.outlook.com>
From: Dhruv Dhody <dd@dhruvdhody.com>
Date: Fri, 06 Nov 2020 15:44:57 +0530
Message-ID: <CAP7zK5YAQFYDeJJ7YErcgtks94jq9pLvdEUvxeMxi1ZVOzgROg@mail.gmail.com>
To: "Mike Koldychev (mkoldych)" <mkoldych@cisco.com>
Cc: "Stone, Andrew (Nokia - CA/Ottawa)" <andrew.stone@nokia.com>, Cyril Margaria <cyril.margaria@gmail.com>, "pce@ietf.org" <pce@ietf.org>, "draft-ietf-pce-segment-routing-policy-cp@ietf.org" <draft-ietf-pce-segment-routing-policy-cp@ietf.org>, pce-chairs <pce-chairs@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/7eNrP_e_GbkJdslhmCbJsMMcCrw>
Subject: Re: [Pce] Association Source in draft-ietf-pce-segment-routing-policy-cp-01
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Nov 2020 10:15:37 -0000

Hi Mike, Andrew, Cyril,

Thanks for a great discussion, more inline...

On Fri, Nov 6, 2020 at 7:23 AM Mike Koldychev (mkoldych)
<mkoldych@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-bounces@ietf.org> on behalf of "Mike Koldychev (mkoldych)" <mkoldych=40cisco.com@dmarc.ietf.org>
> Date: Thursday, November 5, 2020 at 1:30 PM
> To: Cyril Margaria <cyril.margaria@gmail.com>, Dhruv Dhody <dd@dhruvdhody.com>
> Cc: "pce@ietf.org" <pce@ietf.org>, "draft-ietf-pce-segment-routing-policy-cp@ietf.org" <draft-ietf-pce-segment-routing-policy-cp@ietf.org>, pce-chairs <pce-chairs@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.margaria@gmail.com>
> Sent: Thursday, November 5, 2020 11:35 AM
> To: Dhruv Dhody <dd@dhruvdhody.com>
> Cc: Mike Koldychev (mkoldych) <mkoldych@cisco.com>; pce@ietf.org; pce-chairs <pce-chairs@ietf.org>; draft-ietf-pce-segment-routing-policy-cp@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 <dd@dhruvdhody.com> wrote:
>
> Hi Mike,
>
> On Thu, Nov 5, 2020 at 9:34 PM Mike Koldychev (mkoldych)
> <mkoldych@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 <dd@dhruvdhody.com>
> > Sent: Thursday, November 5, 2020 10:43 AM
> > To: Mike Koldychev (mkoldych) <mkoldych@cisco.com>
> > Cc: draft-ietf-pce-segment-routing-policy-cp@ietf.org; pce@ietf.org; pce-chairs <pce-chairs@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) <mkoldych@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 <dd@dhruvdhody.com>
> > Sent: Thursday, November 5, 2020 1:59 AM
> > To: draft-ietf-pce-segment-routing-policy-cp@ietf.org
> > Cc: pce@ietf.org; pce-chairs <pce-chairs@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-drafts@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-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
> > Pce@ietf.org
> > https://www.ietf.org/mailman/listinfo/pce
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce