[Teas] Key collision between configured and ephemeral list entries

Italo Busi <Italo.Busi@huawei.com> Mon, 27 May 2019 13:17 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 8BB6F12015E; Mon, 27 May 2019 06:17:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 oh8x2A2gn7cw; Mon, 27 May 2019 06:17:00 -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 03C2612013D; Mon, 27 May 2019 06:17:00 -0700 (PDT)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id F11DE9D072F4F1327141; Mon, 27 May 2019 14:16:57 +0100 (IST)
Received: from LHREML504-MBS.china.huawei.com ([10.201.109.59]) by lhreml701-cah.china.huawei.com ([10.201.108.42]) with mapi id 14.03.0415.000; Mon, 27 May 2019 14:16:54 +0100
From: Italo Busi <Italo.Busi@huawei.com>
To: "netmod@ietf.org" <netmod@ietf.org>
CC: "teas@ietf.org" <teas@ietf.org>
Thread-Topic: Key collision between configured and ephemeral list entries
Thread-Index: AdUUid+3lEIjrS8aR5K2w9jffR4mQA==
Date: Mon, 27 May 2019 13:16:54 +0000
Message-ID: <91E3A1BD737FDF4FA14118387FF6766B2774D314@lhreml504-mbs>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.203.246.126]
Content-Type: multipart/related; boundary="_004_91E3A1BD737FDF4FA14118387FF6766B2774D314lhreml504mbs_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/eB-mhuacUEQ7AEx3nucIGqJRggg>
Subject: [Teas] 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: Mon, 27 May 2019 13:17:02 -0000

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

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