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

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Tue, 11 June 2019 17:19 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE4E12010C; Tue, 11 Jun 2019 10:19:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 D9MwlXLfZJCB; Tue, 11 Jun 2019 10:19:13 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1798712015D; Tue, 11 Jun 2019 10:19:04 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 9068376; Tue, 11 Jun 2019 19:19:02 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id QHKPJlaL5IMk; Tue, 11 Jun 2019 19:19:02 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 11 Jun 2019 19:19:02 +0200 (CEST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4806F2012C; Tue, 11 Jun 2019 19:19:02 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id PgPcw8JNEwTe; Tue, 11 Jun 2019 19:19:01 +0200 (CEST)
Received: from exchange.jacobs-university.de (sxchmb04.jacobs.jacobs-university.de [10.70.0.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 549DB20126; Tue, 11 Jun 2019 19:19:01 +0200 (CEST)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Tue, 11 Jun 2019 19:19:00 +0200
Received: by anna.localdomain (Postfix, from userid 501) id 7F75B300A2A461; Tue, 11 Jun 2019 19:19:00 +0200 (CEST)
Date: Tue, 11 Jun 2019 19:19:00 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Italo Busi <Italo.Busi@huawei.com>
CC: Andy Bierman <andy@yumaworks.com>, "teas@ietf.org" <teas@ietf.org>, Tarek Saad <tsaad.net@gmail.com>, "netmod@ietf.org" <netmod@ietf.org>
Message-ID: <20190611171900.xzzwofx5nwtj77cv@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Italo Busi <Italo.Busi@huawei.com>, Andy Bierman <andy@yumaworks.com>, "teas@ietf.org" <teas@ietf.org>, Tarek Saad <tsaad.net@gmail.com>, "netmod@ietf.org" <netmod@ietf.org>
References: <91E3A1BD737FDF4FA14118387FF6766B2774DF6C@lhreml504-mbs> <062401d5160d$a568ea80$4001a8c0@gateway.2wire.net> <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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <91E3A1BD737FDF4FA14118387FF6766B2775D052@lhreml504-mbs>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB02.jacobs.jacobs-university.de (10.70.0.121) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/eikRmtw15uoFSHw5A8ca3V88bIA>
Subject: Re: [Teas] [netmod] Key collision between configured and ephemeral list entries
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Jun 2019 17:19:15 -0000

On Tue, Jun 11, 2019 at 04:36:08PM +0000, Italo Busi wrote:
> 
> I agree with your statements as long as we consider two sources for the same information/instance. In this case, my understanding is that the same key value is intentionally assigned by the two sources to indicate that they are representing the same information/instance and only one instance needs to be applied within the operational DS
>
> The issue we are trying to solve is slightly different. We have two different instances from different sources and both of them need to be applied within the operational DS, but unfortunately they have got assigned the same key value ...
>

It does not really matter whether the name clash is intentional or
not. Only one can be used and it should be clear which one will be
the winner.

I do understand that you want to design the models so that name
clashes can be avoided and this is likely fine for what you need but
you need to think through all cases.

- Will names not matching the pattern be rejected? If so, what happens
  to existing entries if the allowed name pattern is changed? Or is
  the pattern cast into stone?

- Another option, in principle, is to suggest that names are chosen
  such that they have a low probability to collide. This sometimes
  leads to simpler implementations since clients do not have to
  generate names conforming to some (configurable?) patterns and
  instead create a name with low collision probability and if the
  config does not make it into <operational>, the client handles the
  name clash. Note that some clients may want to tag their entries
  with specific IDs anyway so that they can easily recognize their
  entries, i.e., clients may have other good reasons to avoid
  generating names that have a high probability to clash.

/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/>