Re: [netmod] [Teas] Key collision between configured and ephemeral list entries

"Rob Wilton (rwilton)" <rwilton@cisco.com> Wed, 19 June 2019 09:07 UTC

Return-Path: <rwilton@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE9E1203F5; Wed, 19 Jun 2019 02:07:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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=LTZ1lb/J; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=PYiILSHJ
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 i5K78O9S9eSS; Wed, 19 Jun 2019 02:07:02 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F33A120396; Wed, 19 Jun 2019 02:07:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4561; q=dns/txt; s=iport; t=1560935221; x=1562144821; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Q6CF8/X8O1tiSFc6jA9WIefII9Nu/twiHBom/WvaeNc=; b=LTZ1lb/JqWBrKtBlhse9yCdAe7BRYIqC3vx23WIRK/Zamj0TuJuHemT2 Kr2sa0z/jvzrYRlTPn/M6MarZDhqVqZ/D9NgHWiq8f6Lkx68ziXJKEKCo 57FcLFI4MrgfT5EsLvhosDHuA5bPAGpldOwwKCPgOQo1YpqCo3txdzwPE 0=;
IronPort-PHdr: 9a23:+pxcMROiVErTKkDXWUkl6mtXPHoupqn0MwgJ65Eul7NJdOG58o//OFDEu60/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETBoZkYMTlg0kDtSCDBjhM//ucys8NM9DT1RiuXq8NBsdFQ==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AGAACp+gld/5pdJa1jAxkBAQEBAQEBAQEBAQEHAQEBAQEBgVEEAQEBAQELAYE9UANqVSAECygKh1MDhFKKDYJXfohHjXGBLoEkA1QJAQEBDAEBGAsKAgEBhEACglIjNAkOAQMBAQQBAQIBBG0cDIVKAQEBAQMBARAuAQEsCwELAgICAQgQAQEDAQEBJwcbBgYLFAMGCAIEAQ0FCBMHgwGBagMdAQIMnSoCgTiIX4IignkBAQWFAw0LghADBgWBLwGLXReBQD+BEUaCFwcuPoIaRwEBgUsYBRomgnWCJotPIIdoVpR7PgkCghCPZ4QHlzSNHYkOjVkCBAIEBQIOAQEFgVA4gVhwFTuCbIIPg3AzhCY7hT9ygSmMWAGBIAEB
X-IronPort-AV: E=Sophos;i="5.63,392,1557187200"; d="scan'208";a="572167521"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Jun 2019 09:06:57 +0000
Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x5J96v6p026698 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 19 Jun 2019 09:06:57 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 19 Jun 2019 04:06:56 -0500
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 19 Jun 2019 04:06:56 -0500
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 19 Jun 2019 04:06:56 -0500
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=di5emuZSRVRNWmXpKieHcc1fnuEQXjdN47yHr80FMIk=; b=PYiILSHJZin7iPtwLyE4/FsUV6+wvcj75sVgXF9flN5LomUwiUmOm8MMXM53gmSxfrzaMuM7ErKRVmkptAu4TZ7Tlfi3JpNoESLQ2Pbigznx1bEDHkov8Q575Cd9+V9C8TuL9hH24nTOtiDXyS4WI7DBwXLnzzWLWjjhep09/GY=
Received: from BYAPR11MB2631.namprd11.prod.outlook.com (52.135.227.28) by BYAPR11MB2886.namprd11.prod.outlook.com (20.177.225.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.13; Wed, 19 Jun 2019 09:06:55 +0000
Received: from BYAPR11MB2631.namprd11.prod.outlook.com ([fe80::ed99:b6a8:d6fb:5045]) by BYAPR11MB2631.namprd11.prod.outlook.com ([fe80::ed99:b6a8:d6fb:5045%4]) with mapi id 15.20.1987.014; Wed, 19 Jun 2019 09:06:55 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Italo Busi <Italo.Busi@huawei.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
CC: "netmod@ietf.org" <netmod@ietf.org>, Tarek Saad <tsaad.net@gmail.com>, Andy Bierman <andy@yumaworks.com>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: [Teas] [netmod] Key collision between configured and ephemeral list entries
Thread-Index: AQHVJfq3HbVqJ7wQTku6G+2+NOkmA6airETw
Date: Wed, 19 Jun 2019 09:06:55 +0000
Message-ID: <BYAPR11MB2631B283C5EE2D4676A27F5BB5E50@BYAPR11MB2631.namprd11.prod.outlook.com>
References: <BYAPR11MB26314CD2365C6AEC39E696EDB51F0@BYAPR11MB2631.namprd11.prod.outlook.com> <BL0PR06MB4321DA01042ECAAD88E8420AFC1F0@BL0PR06MB4321.namprd06.prod.outlook.com> <91E3A1BD737FDF4FA14118387FF6766B2774E51F@lhreml504-mbs> <028b01d51933$1015fa80$4001a8c0@gateway.2wire.net> <91E3A1BD737FDF4FA14118387FF6766B2775CF49@lhreml504-mbs> <CABCOCHTFSfizdqszABgyv+SBHW2+5W5WF-HJvVo=EAJFcUnvJA@mail.gmail.com> <20190611160106.5o3pslwmnhaoyjzx@anna.jacobs.jacobs-university.de> <91E3A1BD737FDF4FA14118387FF6766B2775D052@lhreml504-mbs> <20190611171900.xzzwofx5nwtj77cv@anna.jacobs.jacobs-university.de> <91E3A1BD737FDF4FA14118387FF6766B2775D16D@lhreml504-mbs> <20190611183630.4ymx7libdotuqfbo@anna.jacobs.jacobs-university.de> <91E3A1BD737FDF4FA14118387FF6766B27769528@lhreml504-mbs>
In-Reply-To: <91E3A1BD737FDF4FA14118387FF6766B27769528@lhreml504-mbs>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com;
x-originating-ip: [173.38.220.54]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 818e5e03-4f1c-46d2-10a0-08d6f4957a02
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB2886;
x-ms-traffictypediagnostic: BYAPR11MB2886:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <BYAPR11MB2886ED85C5D12469B546CD18B5E50@BYAPR11MB2886.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0073BFEF03
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(376002)(396003)(346002)(39860400002)(199004)(189003)(13464003)(68736007)(25786009)(66066001)(8936002)(11346002)(316002)(102836004)(99286004)(305945005)(54906003)(6306002)(6246003)(3846002)(7696005)(55016002)(76176011)(74316002)(53936002)(6436002)(5660300002)(9686003)(4326008)(7736002)(52536014)(476003)(73956011)(66946007)(81156014)(81166006)(6116002)(66556008)(110136005)(66446008)(64756008)(966005)(66476007)(478600001)(53546011)(6506007)(76116006)(186003)(14454004)(71190400001)(229853002)(8676002)(71200400001)(2906002)(446003)(86362001)(26005)(256004)(33656002)(486006); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2886; H:BYAPR11MB2631.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: fNNH3V2AVsXnxJMuPNOzcFxj8YPg56YRIayZA83MhP0foTSpTxPLoHURxvQLlZgqtPmnutkX+ufhFHr3BwV4dgPm8kTZJSxbxlGuT/Xg8NGCmUwhSfqRDYxpRtz0EJgGDTlYftL+Ai8/wcdduSlZTUrdxsmbDLh9PWgeVb/qU5wGPtiLJ6h19j0ctflOlv/rwxOFekDclF1xwZvNi2X5imvw7mlD1oIKc4fxdf5JZVA2gjt07vQ0HeOL+b1ooCVgorOxKw5JOb+/lrLiHBGQUit6OATv1mmEICrTzb2e7cHzJUt2+OJ6A0dyazOHUuKQbxVgm5l48nbDwj2mqvr+HxOuz8ejnnFvoxpMmTvwnmBnw8o0I3IVNbSQ3K2zV/G1gKDWQermB5LpMx9JsavLFtO3xTtG87r8iE5NHCp5iJE=
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 818e5e03-4f1c-46d2-10a0-08d6f4957a02
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2019 09:06:55.1645 (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: rwilton@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2886
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.23, xch-aln-013.cisco.com
X-Outbound-Node: rcdn-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/zEXnrPnTvGT33C4si0kJptEsg8s>
Subject: Re: [netmod] [Teas] Key collision between configured and ephemeral list entries
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Jun 2019 09:07:04 -0000

Hi Italo,

My interpretation of the NMDA guidelines are thus:

- If multiple clients are writing the same values to <running> then the clients must coordinate between themselves to ensure that the correct values are written to <running>, otherwise the last verified change written to <running> wins.  Locks can be used to coordinate client writes to <running> if required.

- If multiple clients are writing to different datastores, e.g. one client is writing to <running> and another is writing to some form of ephemeral datastore, then the ephemeral datastore definition must specify what mechanism is used to resolve configuration conflicts between configuration datastores.  Naively, my starting point would be to say that configuration in an ephemeral datastore should override configuration that is in <running>.

- If the decision is from a data node configured in <running> and a data node injected by the system into <operational> then it is up to the device to decide how to resolve these (i.e. the system chooses which version of the data node to use, and the result of that decision is tagged in <operational> using the origin metadata).  Generally, I would expect an explicitly configured data node in <running> should take precedence over system generated config, but there might be cases where this doesn't make sense, and perhaps there might be cases where the data model recommends different behaviour.

- I would assume that there is only a single <operational> datastore.  I'm not sure whether NMDA explicitly requires this, but we couldn't think of any scenario where multiple operational datastores would be helpful.

Thanks,
Rob


> -----Original Message-----
> From: Teas <teas-bounces@ietf.org> On Behalf Of Italo Busi
> Sent: 18 June 2019 18:24
> To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
> Cc: netmod@ietf.org; Tarek Saad <tsaad.net@gmail.com>; Andy Bierman
> <andy@yumaworks.com>; teas@ietf.org
> Subject: Re: [Teas] [netmod] Key collision between configured and
> ephemeral list entries
> 
> Hi Juergen,
> 
> What is the DS architecture you have in mind with multiple client creating
> entries?
> 
> Are the two clients creating entries in the same <running> DS or in two
> different <running> DS?
> 
> In the latter case, the two clients could also rely on different
> <operational> DS and therefore can assign the same name to different
> entries (since they will be instantiated in different DS). There is no
> need for them to avoid name clash
> 
> In the former case, a name clash would cause one client to override the
> configuration of another client
> 
> Are the two clients aware of each other?
> 
> I take the opportunity to clarify one point (not sure I have been clear
> about it). I do not think we need to define any rule which is enforced by
> the server to avoid name clashes since the server cannot understand
> whether the name clash is intentional or not. I think we just need to
> define some known/common/standard rules that allow the client(s) to avoid
> creating unintended name clashes.
> 
> Thanks, Italo
> 
> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
> Sent: martedì 11 giugno 2019 20:37
> To: Italo Busi <Italo.Busi@huawei.com>
> Cc: Andy Bierman <andy@yumaworks.com>; teas@ietf.org; Tarek Saad
> <tsaad.net@gmail.com>; netmod@ietf.org
> Subject: Re: [netmod] [Teas] Key collision between configured and
> ephemeral list entries
> 
> On Tue, Jun 11, 2019 at 05:43:27PM +0000, Italo Busi wrote:
> 
> > [Italo Busi] If the client knows the prefix used by the server, it can
> > pick up a different prefix and use it to tag its own entries. I think
> > this rule is not really complex and it seems much simpler than
> > managing unintended name clashes
> 
> A prefix only helps a little. Once you have multiple clients creating
> entries, you will have to handle collisions again. Sometimes solving the
> more general case leads to solutions that also work nicely in simpler
> special cases.
> 
> /js
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas