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

"Mike Koldychev (mkoldych)" <mkoldych@cisco.com> Fri, 06 November 2020 19:38 UTC

Return-Path: <mkoldych@cisco.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 EAF5E3A0B83; Fri, 6 Nov 2020 11:38:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=lm8Yj8qC; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=bCaus/1/
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 RbIDgeXlLiXf; Fri, 6 Nov 2020 11:38:46 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F5BA3A0B76; Fri, 6 Nov 2020 11:38:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24636; q=dns/txt; s=iport; t=1604691526; x=1605901126; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=cPDNpYIQcEugPnVQ2H+vpiZ2du7LccjTO03w9usrkjQ=; b=lm8Yj8qCWvw76ilHFmuRvL0y0BNkOdMdVBw7TLdc0hD1mqHgUbMg+V5q fsLL6A6SCxu70MPkq5w04PUWu56Pr3WnD1IU8/WYRSVjRjlFxhzEck0M2 gCHGM3MPtSFQEAET7pa1GGPhh+Bob/HClt8DRAH58/adcEQtGRlsW/335 4=;
X-IPAS-Result: A0DwAQDopKVf/49dJa1iGwEBAQEBAQEBBQEBARIBAQEDAwEBAUCBT4FSIwYoB4FMLy6EPYNJA41TihWObIFCgREDVAsBAQENAQEtAgQBAYRKAheBeAIlOBMCAwEBAQMCAwEBAQEFAQEBAgEGBHGFNAglDIVyAQEBAQIBEhERDAEBNwEEBwQCAQgOAwMBAQEBAgImAgICHxEVCAgCBA4FCBMHhVoDDiABpH4CgTuIaHaBMoMEAQEFhRANC4IQCYEOKoJyg3OBBoVRG4FBP4EQAUOBUX4+ghtCBIEoARIBIySCcTOCLJAZIAE1A4I1AT2HQ4sEYpAQOFQKgm2VeoU1gxiKEoooih6TSIIEi2mOIoQ9AgQCBAUCDgEBBYFrI2dwcBWDJFAXAg2BNIxrDBeBAgEMgj+KVwF0AjYCBgEJAQEDCXyNTAEB
IronPort-PHdr: 9a23:TyjoKxNIJ5I8Nipdokol6mtXPHoupqn0MwgJ65Eul7NJdOG58o//OFDEvK8x3lPJR5jF5/JDh/uQuKflCiQM4peE5XYFdpEEFxoIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFHSuGCs4T4VFgS5Pg1wdaz5H4fIhJGx0Oa/s5TYfwRPgm+7ZrV/ZBW7pAncrI8Ym4xnf60w0RDO5HBPfrdb
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.77,457,1596499200"; d="scan'208";a="574132452"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Nov 2020 19:38:44 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 0A6Jci86001509 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 Nov 2020 19:38:44 GMT
Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 6 Nov 2020 13:38:44 -0600
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 6 Nov 2020 13:38:43 -0600
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 6 Nov 2020 13:38:43 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AJTcmIM6kQTQVeGCWldLx0eKkh6oyV5FXguUr1Y9giPRnLsbbq/CdNrKithCbotz8lHwt6Elv3JN6YQKQw9p6Lpn+UN7CXO85cVaS+EJ32bZeMCUzqmLUuWqDumvQyCozNUJaosgUE+UyFLFP8op4ObcjRWil/vDiYUaZyIynMwXW7tNYYI/ypq1+UmD4/QuCqAEi0kBtbwP7uj7ijj77kOagXyf4BUwxxG3joGD3V7ouPurytalTBpeBQPpSgyeG/gJoo4PanXgCAJeuFQcpDAhoNU1yV/JC/2GF9mQ1TtKmY47QLbqZaKnZI6wxNTZO6K2EO5gizUDniXHb4anXQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cPDNpYIQcEugPnVQ2H+vpiZ2du7LccjTO03w9usrkjQ=; b=nBv4aLutbMfwV7DuhMjq3c6/qL5INq24CD3yPlB5SzMkKtc+jZA4IhZKRFGgJf4IGQw1YPT5h5Q2d6FgWsiHxq2bXYngLGRvQQIl0qqbNWFHnYRaC20SeH4r/b6KNudf93MIzZ7egG3RiiZzaaM1RMxD7U7xr43c8kWYvqIYVrq49jNRkrTXUj6KOLKolUhmVUcaQ+sQeV8jaDgZ6+PM/i1qxmVGWVNnAQOFVFaXoNMsjpJc8CD4IteO4/vpc/rUFz7r/XCKWNL/0uij7Y0/I0HJiRtPw+bewFxhDd3ZzaVO1PtiLnTgIhGzilj1vMM9JlQq/hWIqi/pZQHGJJWMCw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cPDNpYIQcEugPnVQ2H+vpiZ2du7LccjTO03w9usrkjQ=; b=bCaus/1/UpZj/u5229NslG1W8QKFnZ8gltPOpBS7rT+pwOSomMvknn9rx2A68BNTxnyYe50NwIQ77hI5EH7HTDMk4wfFU7Is9OdsgZTm10maV7nEMXNBUfAeBCVKfiAvEuDjchj/2RzNwsc72CIQHoe0hcmUrDx+Kn0pxO9NauA=
Received: from DM6PR11MB3802.namprd11.prod.outlook.com (2603:10b6:5:143::30) by DM6PR11MB4530.namprd11.prod.outlook.com (2603:10b6:5:2a4::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.28; Fri, 6 Nov 2020 19:38:42 +0000
Received: from DM6PR11MB3802.namprd11.prod.outlook.com ([fe80::74ba:9dd3:1dcf:1de8]) by DM6PR11MB3802.namprd11.prod.outlook.com ([fe80::74ba:9dd3:1dcf:1de8%6]) with mapi id 15.20.3541.022; Fri, 6 Nov 2020 19:38:41 +0000
From: "Mike Koldychev (mkoldych)" <mkoldych@cisco.com>
To: Dhruv Dhody <dd@dhruvdhody.com>
CC: Dhruv Dhody <dhruv.ietf@gmail.com>, "Mike Koldychev (mkoldych)" <mkoldych=40cisco.com@dmarc.ietf.org>, pce-chairs <pce-chairs@ietf.org>, "pce@ietf.org" <pce@ietf.org>, "draft-ietf-pce-segment-routing-policy-cp@ietf.org" <draft-ietf-pce-segment-routing-policy-cp@ietf.org>, Cyril Margaria <cyril.margaria@gmail.com>, "Stone, Andrew (Nokia - CA/Ottawa)" <andrew.stone@nokia.com>
Thread-Topic: [Pce] Association Source in draft-ietf-pce-segment-routing-policy-cp-01
Thread-Index: AQHWs0FDpv7QUwBDr0CmS9tu2ryFnKm5kByggAAeEQCAAASBcIAABMEAgAAFWwCAAB488IAAKGYAgABP1tCAAJGWgIAAEWHwgAAkXICAAAIDAIAAJeEAgAA9MmA=
Date: Fri, 06 Nov 2020 19:38:41 +0000
Message-ID: <DM6PR11MB3802B4F0DD343F7B3E56470FD3ED0@DM6PR11MB3802.namprd11.prod.outlook.com>
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> <CAP7zK5YAQFYDeJJ7YErcgtks94jq9pLvdEUvxeMxi1ZVOzgROg@mail.gmail.com> <DM6PR11MB38027F03573AE34EFA3FDC1AD3ED0@DM6PR11MB3802.namprd11.prod.outlook.com> <CAB75xn6P0q026F8YNZnRTHQ-CuY_PDrvVyVHMRrLSQnUxPZbsQ@mail.gmail.com> <DM6PR11MB380259C08B1A125853CEB6B3D3ED0@DM6PR11MB3802.namprd11.prod.outlook.com> <CAP7zK5aXLGrFKr9+8ehVxwqrOcUz2Wwbc0g8Zd+RbiWHywpHRA@mail.gmail.com>
In-Reply-To: <CAP7zK5aXLGrFKr9+8ehVxwqrOcUz2Wwbc0g8Zd+RbiWHywpHRA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dhruvdhody.com; dkim=none (message not signed) header.d=none;dhruvdhody.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2607:fea8:e3a0:e690:1535:772b:69e1:1725]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f0587c9c-0146-4dd2-e234-08d8828b911d
x-ms-traffictypediagnostic: DM6PR11MB4530:
x-microsoft-antispam-prvs: <DM6PR11MB453022FB28DB5B3D891EA7D2D3ED0@DM6PR11MB4530.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: CZbbYuzw3UVmwhXg8goOuQ2Sfgq2OXwGDjLGHR+wSVOqYErYU4oPagBegz9O7QhyPQFZpatZVp0NcE+cfYnTnQfWUnohVZ0aMEFDhlK55aDJiKZr928JNo0YMweJrO2QJVau3ZBcgpsQLsmvPnU1CE3yj30JzuAA81wSu9WMNLqPg49HFMbUdumxjJtAaZDvPE6/hZaebFMHHur1hYvyeXz6hXfQl8KXpb0E6E18T1ApUOTEO1P1RptSZ6hXhHovxdkYHhl+gWmHrQDLjNtLOexD0bFHzNCaUxOaF8SHFflK8V/UiFYyAlOxekT8PpGRqDhmdP7vi355THh97xxXAwl0CDwcikokx9j4tQzfRMAJFoklrAyU2LEfsqTwOYEY
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3802.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(136003)(39860400002)(366004)(376002)(396003)(66476007)(66946007)(53546011)(7696005)(66446008)(66574015)(71200400001)(2906002)(478600001)(8676002)(83380400001)(6916009)(6506007)(316002)(64756008)(5660300002)(76116006)(8936002)(52536014)(9686003)(55016002)(4326008)(33656002)(30864003)(54906003)(86362001)(186003)(66556008)(60764002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: MtXCeh4SJdNBwb1myDz0zphDS5dGU4mo+lvAo7s6IW6/rko6/wyYw1SuvuE9N7x2jLHh7MkK/far4BxGDJch9iYhenWKe8bsgwChk8hW/FjTQ7rMxUseye4oxJQLKGiD5RDqFF4V1shI1R1iEqrw3NsGuc+P0ts+ehIs1ayRYChBMIeEHVYlWDjKnchoXAGTGKruuJcrrwASpVYdQCYjuJYLlR9Bq1ABPzcBq7VH7etoMShvor3VIEMBgjgX2dKy5ry45n0P1lhlegreQR3j9JGaGD8/OLlo8CAUWK09Ln5pEuyApd2rpAW/swuFL6z7gQ4jaoNXr5qAxiQEQgSjxeMx2K7Vg3Ve9iN+EQ8ANgMhA65UsGCtS9KWvvi/9fvpZkt/vESMcFJ39OEfqWRFdE9V/lWXkBkHS+Ln+TZnGUJKhdOA2Xejhpws/m+CYZwCfJ0ab+dkei2/2vRQ9kdp2OUW/2gfo/FocK8RiV8Q1j2ZD0pw38UFgEKxoRXPXDwaO3wdFyzVO4VELiHnWOjyh3f7j7Xr3h4hfaO4gWsyOOLSiq1Bd/JSEbNn7P+My2PTru8cWy84gdXlleW8wU7hgBeYU6NP/HOLnkQTaUJMR7ICFLmbSOs4vczZCz4BJ1dL+R6lBO0nQ+wX1X3sIsqpP6YHSXdvo8ycGuo08filyewTYJUagtoZ+7w5o98aBbPPfpLkwfPFjd37GWD4uPJT3w==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3802.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f0587c9c-0146-4dd2-e234-08d8828b911d
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2020 19:38:41.8355 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: OEOn9FDMHOI3oyc6HK+PZGWGCLY8N6gZMNseqLQoTG0BxTcOoP/zytkL58JbNqKbLQzp/eucuCVknwsuzI5+JA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4530
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/LNYWBkIEi96wybvj1VsYCCkTu8I>
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 19:38:49 -0000

Hi Dhruv,

Thanks again for bringing up this topic. Let's think some more about the possible solutions and also let other people provide feedback. Perhaps a side-meeting can be held as well.

Have a good weekend,
Mike.

-----Original Message-----
From: Dhruv Dhody <dd@dhruvdhody.com> 
Sent: Friday, November 6, 2020 10:50 AM
To: Mike Koldychev (mkoldych) <mkoldych@cisco.com>
Cc: Dhruv Dhody <dhruv.ietf@gmail.com>; Mike Koldychev (mkoldych) <mkoldych=40cisco.com@dmarc.ietf.org>; pce-chairs <pce-chairs@ietf.org>; pce@ietf.org; draft-ietf-pce-segment-routing-policy-cp@ietf.org; Cyril Margaria <cyril.margaria@gmail.com>; Stone, Andrew (Nokia - CA/Ottawa) <andrew.stone@nokia.com>
Subject: Re: [Pce] Association Source in draft-ietf-pce-segment-routing-policy-cp-01

Hi Mike,

On Fri, Nov 6, 2020 at 7:39 PM Mike Koldychev (mkoldych) <mkoldych@cisco.com> wrote:
>
> Hi Dhruv,
>
> -----Original Message-----
> From: Dhruv Dhody <dhruv.ietf@gmail.com>
> Sent: Friday, November 6, 2020 8:27 AM
> To: Mike Koldychev (mkoldych) <mkoldych=40cisco.com@dmarc.ietf.org>
> Cc: Dhruv Dhody <dd@dhruvdhody.com>; pce-chairs <pce-chairs@ietf.org>; 
> pce@ietf.org; draft-ietf-pce-segment-routing-policy-cp@ietf.org; Cyril 
> Margaria <cyril.margaria@gmail.com>; Stone, Andrew (Nokia - CA/Ottawa) 
> <andrew.stone@nokia.com>
> 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) <mkoldych=40cisco.com@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.
>
> [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.
>

+1 to what Cyril said. The idea that even when PCE knows about the
existing association created at the PCC and it wants a new CP to join that association, it cannot do so and it must use association-id as zero is weird - there is a reason we maintain associations at the PCE.
So my reading was that the use of 0 was only when the SR Policy association was not known.
Also, you don't mention the PCUpd message in your draft, first an existing SR-TE path (RFC 8664) can join the SR Policy association using the PCUpd message. Also, you may want to update the existing CP and carry the already known association in the PCUpd message. I assume you would want to put "a non-zero PCC allocated ID''!

>
> > 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"!
>
> [MK] I would say "very likely" that you would get a flood of PCError messages in that scenario under scale.
>
>
> > 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.
>
> [MK] The two PCEs may not be under one administrative control. Network A may delegate some tunnels/policies to Network B PCE (for routing through Network B, for example).

Delegation outside of your network domain would open you up to so much more security concern than just knowing another PCE address! Even in the case you mention we would assume there would be a PCEP session between the PCEs across network domains (so hiding PCE address should not be a concern).

> In this case, the internal NMS/PCE addresses of Network A would be leaked. An operator who is not intimate with the PCEP messaging internals might never even realize this leak is happening. I believe we should update RFC 8697, we need to at least state that a privacy violation is possible and that the operator needs to assume that internal NMS/PCE addresses are going to be leaked to other PCEs via the ASSOCIATION object.
>
>
> 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 and be done? Isn't that also a "special value"?
>

You can set association-source as head-end IP address which is known as part of SR-Policy tuple <headend, color, endpoint>. This rule can be scoped under the association-type=SR-Policy (and not applicable anywhere else).

>
> > 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 for its own purpose? Is that allowed/forbidden in the RFC?
>

The issue for me is not so much the use of 0, it is the idea that it MUST always be a PCC that allocates association information (going against an existing standard). I feel a simple rule of association creation at any PCEP peer such as Assoc-Type=SR-Policy, Assoc-ID=0x0, Ext-Assoc-ID=color, Association-source=headend can solve it!

Have a good weekend everyone!

Thanks!
Dhruv



>
> 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 <dd@dhruvdhody.com>
> > Sent: Friday, November 6, 2020 5:15 AM
> > 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; 
> > 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 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, 
> > Mike> AND 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