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

Andy Bierman <andy@yumaworks.com> Tue, 11 June 2019 15:54 UTC

Return-Path: <andy@yumaworks.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 48EAE1202BF for <netmod@ietfa.amsl.com>; Tue, 11 Jun 2019 08:54:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-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 cjgQCXXwSOmw for <netmod@ietfa.amsl.com>; Tue, 11 Jun 2019 08:54:25 -0700 (PDT)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 A28B6120157 for <netmod@ietf.org>; Tue, 11 Jun 2019 08:54:24 -0700 (PDT)
Received: by mail-lf1-x12c.google.com with SMTP id a9so9705231lff.7 for <netmod@ietf.org>; Tue, 11 Jun 2019 08:54:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aRiOKxUhCfX8/APQ1V3NPxi0UUKB9wu8LJ0u5yxdZcU=; b=A26q/3XLrGaAGT8qIdKq7Jbd5Nj8HjZMqGGioCfOPAP7cBDk2g/EGHhBwwh/an2xXH SwgQPZAnDcI1kXWLQB0fsRHSnImPXSrATgOK80lIxAEBYc1YOU/F/JFnraj+1zVDsYuI o1EjI+GCSWPjbY+hMf5D/0K3pt+tLTyom47+pUgaVMQPShdRYw9iEnCivAveJu1Os9go geBLFDVDyl7xymbV/WXw7LSAUK1BKiBr7t4bbJrXZ1Sr63ZK4IjK9QmX4pMn13DgE1gH IhSvE/JyoJLNlbAYuqbLWEfh40JZSXsgJ9ygzU9C6F3RTueT4ckuNRmh+MSfym6Q0CDf DZCg==
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; bh=aRiOKxUhCfX8/APQ1V3NPxi0UUKB9wu8LJ0u5yxdZcU=; b=LvzseG4mTSHR7+FOuVbtbnmifdo48TZxY+Sg9sOoE/9b/wYkw2HUKZK2ScKCCuRhwx dU9hYejlAv8lLPJzxAmzXl2GEcMIt7JLmwQhc4DK+tCFuZHjifJMJu6AYaDy/WZHD/Et t4VOjgaNZgnUUdLZxDGFFCy9j3/0cSWcVtcXvlBjtSzL9/odaC7XlSSjeeDMtP4e2HYs iCciHieSkUrlwEU5zJAgxWWPVIJShdaMXzeQjsrLCaQ64pD0JAgvWfM88kKMRk2i0ghF xfoQY3/cv/ALmMY8zVr0U2VAJNM+q023dUEJjAeQ6WpV5/0tK/Pi0ZQDXURHUIjy4PYf Y54A==
X-Gm-Message-State: APjAAAXZSd5s9nwT0onfO+g97vQ308WsW5Iu5e0LIsA8kRw8on+WTsKc lRkTodH08Awd3Nk9Hz91AGeuuxD+uaI6sC1lcfEdCw==
X-Google-Smtp-Source: APXvYqxtYCeEGaPuuKsBXygZwXmBTrsMmO8NDOGIp6huQIUPd8rWlSseA5xnlcZhnFARCNdK6Eg4H+DqgsAGsElwx6I=
X-Received: by 2002:ac2:514b:: with SMTP id q11mr4408701lfd.33.1560268462701; Tue, 11 Jun 2019 08:54:22 -0700 (PDT)
MIME-Version: 1.0
References: <91E3A1BD737FDF4FA14118387FF6766B2774D314@lhreml504-mbs> <017f01d515f9$d0c662c0$4001a8c0@gateway.2wire.net> <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>
In-Reply-To: <91E3A1BD737FDF4FA14118387FF6766B2775CF49@lhreml504-mbs>
From: Andy Bierman <andy@yumaworks.com>
Date: Tue, 11 Jun 2019 08:54:11 -0700
Message-ID: <CABCOCHTFSfizdqszABgyv+SBHW2+5W5WF-HJvVo=EAJFcUnvJA@mail.gmail.com>
To: Italo Busi <Italo.Busi@huawei.com>
Cc: tom petch <ietfc@btconnect.com>, Tarek Saad <tsaad.net@gmail.com>, "Rob Wilton (rwilton)" <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>, "teas@ietf.org" <teas@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000079565f058b0e4f58"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/FYKj2YmLBqOeUZX7CUCo9Aj2tWo>
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: Tue, 11 Jun 2019 15:54:29 -0000

On Tue, Jun 11, 2019 at 8:40 AM Italo Busi <Italo.Busi@huawei.com>; wrote:

> Hi Tom,
>
> My understanding is that the running DS contains only the list entries
> configured by the client and therefore there is no key collision (the key
> values are all assigned by the client)
>
> The issue is that the operational DS will contain two types of list
> entries:
> - list entries representing the applied configuration of the list entries
> in the running DS (the key values are all assigned by the client)
> - list entries representing ephemeral list entries representing dynamic
> configuration (the key values are all assigned by the server)
>
> Without any rule, it is possible that the client and the server assigns
> the same key value to two different list entries
>
>
NMDA has the "origin" attribute so that it is clear to clients the source
of the instances
that are being used in <operational>.  It doesn't matter if the data is a
container, a list, etc.
There can be only 1 instance that is being used by the server at a time
(except
for remnant config).

There are no instance naming collisions within <running> or <ephemeral>.
Only if you try to combine them, which is not how it works. The server
chooses
what to put in <operational> and sets the origin attribute accordingly.



> If, as proposed below, the server assign key values ephemeral list entries
> using a prefix which is known to the client, the client can assign key
> values to the configured list entries not using that prefix thus solving
> any conflict
>
> I think this solution works as long as we understand how to make the
> client aware of the prefix being used by the server
>
> My 2 cents
>
> Italo
>
>

Andy


> -----Original Message-----
> From: tom petch [mailto:ietfc@btconnect.com]
> Sent: domenica 2 giugno 2019 13:09
> To: Italo Busi <Italo.Busi@huawei.com>;; Tarek Saad <tsaad.net@gmail.com>;;
> Rob Wilton (rwilton) <rwilton@cisco.com>;; netmod@ietf.org
> Cc: teas@ietf.org
> Subject: Re: [netmod] [Teas] Key collision between configured and
> ephemeral list entries
>
> ----- Original Message -----
> From: "Italo Busi" <Italo.Busi@huawei.com>;
> Sent: Wednesday, May 29, 2019 7:00 PM
>
> > Rob, Tarek,
> >
> > Thanks for following-up this discussion
> >
> > I like the suggestion to use a prefix string: those who prefers using
> one character (e.g., '#') could use a single character string
> >
> > Regarding the configuration, one possible issue that just jumped into
> my mind is what happens when the prefix is (re-)configured by the client
> after some ephemeral tunnels have been created ...
>
> Many years ago, there was a similar discussion about interface names which
> never really got resolved but which was a factor in driving NMDA.
> Some boxes create their own interface names, others have interface names
> configured; and with interfaces, there was a need to use a match of the
> identifier to add configured attributes to a entry that the box had created
> but to create a new entry if there was not a match.  Roll on multiple
> datastores.
>
> Which makes me ask; which datastores are we talking about? I know where
> entries configured via NETCONF will go but which datastores will hold the
> details of these ephemeral tunnels? Needs clarifying IMHO.
>
> Tom Petch
>
> > An alternative solution could be to let the server decide which prefix
> to use (server implementation issue) and to provide a read-only YANG leaf
> to report this information to the client, such that the client knows it
> could not use this prefix for the configured tunnels
> >
> > My 2 cents
> >
> > Italo
> >
> > -----Original Message-----
> > From: Tarek Saad [mailto:tsaad.net@gmail.com]
> > Sent: mercoledì 29 maggio 2019 17:22
> > To: Rob Wilton (rwilton) <rwilton@cisco.com>;; tom petch
> <ietfc@btconnect.com>;; Italo Busi <Italo.Busi@huawei.com>;; netmod@ietf.org
> > Cc: teas@ietf.org
> > Subject: Re: [Teas] [netmod] Key collision between configured and
> ephemeral list entries
> >
> > Hi Rob,
> >
> > Inline..
> >
> > On 5/29/19, 9:05 AM, "Teas on behalf of Rob Wilton (rwilton)"
> <teas-bounces@ietf.org on behalf of rwilton@cisco.com>; wrote:
> >
> >     Are these ephemeral tunnels created and named by the device
> itself?
> > [TS]: yes, some of those are auto-created by the device (e.g.
> triggered by some local event).
> >
> >     Possibly using a human readable prefix (or suffix) might be better
> than using a symbol.
> >
> >     E.g. perhaps a prefix of "sys-" as an abbreviation for system.
> > [TS]: I tend to agree here. I had suggested making this prefix
> configurable - not sure if this brings more trouble.
> >
> > [TS]: On a similar note, on the controller, some tunnels from
> different ingress routers will be reported up to the controller. One way
> to avoid collision of same tunnel name existing on multiple ingress
> devices, we thought of is for that controller to (automatically) append the
> ingress router name (or IP address) before consuming the reported tunnel
> into the controller tunnel list. Thoughts?
> >
> > Regards,
> > Tarek
> >
> >     Thanks,
> >     Rob
> >
> >     -----Original Message-----
> >     From: Teas <teas-bounces@ietf.org>; On Behalf Of tom petch
> >     Sent: 29 May 2019 12:04
> >     To: Italo Busi <Italo.Busi@huawei.com>;; netmod@ietf.org
> >     Cc: teas@ietf.org
> >     Subject: Re: [Teas] [netmod] Key collision between configured and
> ephemeral list entries
> >
> >
> >     ----- Original Message -----
> >     From: "Italo Busi" <Italo.Busi@huawei.com>;
> >     Sent: Wednesday, May 29, 2019 11:02 AM
> >
> >     Hi Tom,
> >
> >     Thanks for your reply
> >
> >     It seems to me that the text you have quoted is from:
> >     https://tools.ietf.org/html/rfc7950#section-6.2
> >
> >     If I can understand correctly, especially for section 6.2.1, this
> constraints does not apply to name attributes whose syntax is defined as a
> string and used as key of a list, such as the tunnel list defined in the TE
> YANG model:
> >
> >          |  +--rw tunnel* [name]
> >          |  |  +--ro operational-state?                  identityref
> >          |  |  +--rw name                                string
> >
> >     My understanding is that a tunnel list entry with a name starting
> with '#' can exist in a YANG DS
> >
> >     <tp>
> >
> >     Italo
> >
> >     Ah yes, my misunderstanding.  'string' type is a bit more flexible
> i.e.
> >
> >        The string built-in type represents human-readable strings in
> YANG.
> >        Legal characters are the Unicode and ISO/IEC 10646 [ISO.10646]
> >        characters, including tab, carriage return, and line feed but
> >        excluding the other C0 control characters, the surrogate
> blocks, and
> >        the noncharacters.
> >
> >     Plenty of scope there!
> >
> >
> >     If this approach is taken, then I agree that hash is a good choice
> as it stands out, unlike, say, underscore which vanishes in the line of
> text.
> >
> >     Tom Petch
> >
> >     Thanks, Italo
> >
> >     -----Original Message-----
> >     From: tom petch [mailto:ietfc@btconnect.com]
> >     Sent: mercoledì 29 maggio 2019 10:42
> >     To: Italo Busi <Italo.Busi@huawei.com>;; netmod@ietf.org
> >     Cc: teas@ietf.org
> >     Subject: Re: [netmod] Key collision between configured and
> ephemeral list entries
> >
> >     <inline>
> >
> >     Tom Petch
> >
> >     ----- Original Message -----
> >     From: "Italo Busi" <Italo.Busi@huawei.com>;
> >     To: <netmod@ietf.org>;
> >     Cc: <teas@ietf.org>;
> >     Sent: Monday, May 27, 2019 2:16 PM
> >     Subject: [netmod] Key collision between configured and ephemeral
> list entries
> >
> >
> >     On Friday within the TEAS WG, we have discussed an issue which
> seems generic and therefore agreed to ask for guidelines to the Netmod WG
> >
> >     In the TE YANG model we have defined a tunnel list with a name
> attribute used as a key:
> >
> >          |  +--rw tunnel* [name]
> >          |  |  +--ro operational-state?                  identityref
> >          |  |  +--rw name                                string
> >
> >     See: https://tools.ietf.org/html/draft-ietf-teas-yang-te-21
> >
> >     The issue we are facing is how to avoid name collision between
> configured and ephemeral tunnels. In other words, the issue we are trying
> to address is how to avoid the client to assign to a configured tunnel a
> name which have been already assigned by the server to another ephemeral
> tunnel and vice-versa, in particular considering NMDA rules
> >
> >     We believe that the issue is generic and apply to any configured
> and ephemeral list entries
> >
> >     Has this issue been already discussed/resolved in Netmod WG?
> >
> >     If not, what is the Netmod WG opinion/suggestion? We are currently
> considering the following option:
> >
> >        Use a special character for ephemeral names - e.g. such names
> always are prepended by special character "#"
> >        Make the special character changeable by configuration - the
> default can be "#" and user can change if they desire..
> >
> >     <tp>
> >
> >     If this is to conform with YANG 1.1, RFC7950, then the constraint
> is
> >
> >        Identifiers are used to identify different kinds of YANG items
> by
> >        name.  Each identifier starts with an uppercase or lowercase
> ASCII
> >        letter or an underscore character, followed by zero or more
> ASCII
> >        letters, digits, underscore characters, hyphens, and dots.
> >
> >
> >     No # (hash) anywhere so I suspect that a lot of tooling will fail
> in an unpredictable way if it encounters an illegal character in an
> identifier.
> >
> >     Tom Petch
> >
> >
> >     Thanks, Italo
> >
> >     Italo Busi
> >     Principal Optical Transport Network Research Engineer Huawei
> Technologies Co., Ltd.
> >     Tel : +39 345 4721946
> >     Email : italo.busi@huawei.com
> >     [cid:image002.png@01D5149F.354EF420]
> >
> >     This e-mail and its attachments contain confidential information
> from HUAWEI, which is intended only for the person or entity whose address
> is listed above. Any use of the information contained herein in any way
> (including, but not limited to, total or partial disclosure, reproduction,
> or dissemination) by persons other than the intended
> >     recipient(s) is prohibited. If you receive this e-mail in error,
> please notify the sender by phone or email immediately and delete it!
> >
> >     From: Tarek Saad [mailto:tsaad.net@gmail.com]
> >     Sent: venerdì 24 maggio 2019 23:13
> >     To: Igor Bryskin <Igor.Bryskin@huawei.com>;; Rakesh Gandhi
> <rgandhi@cisco.com>;; Xufeng <xufeng.liu.ietf@gmail.com>;; Vishnu Pavan
> Beeram <vbeeram@juniper.net>;; Italo Busi <Italo.Busi@huawei.com>;
> >     Cc: teas@ietf.org
> >     Subject: Discussion on modelling container TE tunnels in YANG
> >
> >     The team on "to" list met to discuss this subject topic. Notes
> from today's discussion (please add if I missed):
> >
> >     Name collision between configured and ephemeral tunnels:
> >       This is a generic problem in NMDA.
> >       How to handle collisions between configured and ephemeral (or
> >     auto-created) objects of a list, if the list uses the object
> (string
> >     based) name as the key?
> >       Both configured and ephemeral can have the same object name but
> they are different objects - how to avoid such collision.
> >      Proposed solution:
> >        Option 1:
> >        Use a special character for ephemeral names - e.g. such names
> always are prepended by special character "#"
> >        Make the special character changeable by configuration - the
> default can be "#" and user can change if they desire..
> >       Others?
> >     AI (Italo): to send email to netmod group.
> >
> >     Container TE tunnels discussion:
> >     -          Container tunnels are grouping of tunnels between same
> 2
> >     endpoints to share incoming traffic towards the egress
> >     -          Member tunnels of a container tunnel can be
> >     auto-created/deleted on-demand and controlled by thresholds
> specified under the container
> >     -          Some attributes may apply on the container tunnel and
> >     inherited down to member tunnels of the container
> >     -          Q: Should model allow member tunnel to override
> inherited
> >     attributes from container tunnel?
> >     -          Q: Should all auto-created member tunnels of a
> container have
> >     the same prefix/suffix - i..e prefix/suffix can be configurable
> >
> >     Regards,
> >     Tarek
> >
> >
> >
> >
> >
> >
> >     ------------------------------------------------------------------
> ------
> >     --------
> >
> >
> >     > _______________________________________________
> >     > netmod mailing list
> >     > netmod@ietf.org
> >     > https://www.ietf.org/mailman/listinfo/netmod
> >     >
> >
> >     _______________________________________________
> >     Teas mailing list
> >     Teas@ietf.org
> >     https://www.ietf.org/mailman/listinfo/teas
> >
> >     _______________________________________________
> >     Teas mailing list
> >     Teas@ietf.org
> >     https://www.ietf.org/mailman/listinfo/teas
> >
> >
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>