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

Italo Busi <Italo.Busi@huawei.com> Tue, 11 June 2019 15:40 UTC

Return-Path: <Italo.Busi@huawei.com>
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 9C71F12025F; Tue, 11 Jun 2019 08:40:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 syX5k8hfzyeA; Tue, 11 Jun 2019 08:40:24 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 790961201B8; Tue, 11 Jun 2019 08:40:24 -0700 (PDT)
Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 1F63CCB32058A1F6F74B; Tue, 11 Jun 2019 16:40:22 +0100 (IST)
Received: from LHREML504-MBS.china.huawei.com ([10.201.109.59]) by lhreml703-cah.china.huawei.com ([10.201.108.44]) with mapi id 14.03.0415.000; Tue, 11 Jun 2019 16:40:17 +0100
From: Italo Busi <Italo.Busi@huawei.com>
To: tom petch <ietfc@btconnect.com>, Tarek Saad <tsaad.net@gmail.com>, "Rob Wilton (rwilton)" <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>
CC: "teas@ietf.org" <teas@ietf.org>
Thread-Topic: [netmod] [Teas] Key collision between configured and ephemeral list entries
Thread-Index: AQHVIGv3uNMq5vuvr0+PtfoTsE5mlA==
Date: Tue, 11 Jun 2019 15:40:17 +0000
Message-ID: <91E3A1BD737FDF4FA14118387FF6766B2775CF49@lhreml504-mbs>
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>
In-Reply-To: <028b01d51933$1015fa80$4001a8c0@gateway.2wire.net>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.203.246.126]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/SvSsF01vOArHffhvpvs88nJbwxA>
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 15:40:29 -0000

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

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

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