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

Tarek Saad <tsaad.net@gmail.com> Wed, 29 May 2019 15:22 UTC

Return-Path: <tsaad.net@gmail.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 C0DEE12015E; Wed, 29 May 2019 08:22:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level:
X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 uJ4cz4dXcNbY; Wed, 29 May 2019 08:22:31 -0700 (PDT)
Received: from mail-it1-x12b.google.com (mail-it1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 1103B120154; Wed, 29 May 2019 08:22:31 -0700 (PDT)
Received: by mail-it1-x12b.google.com with SMTP id i63so4196394ita.3; Wed, 29 May 2019 08:22:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=uR/aQpBM/1CuFxQWALAF6uFoVRTQJw+RLX/Ze4DhwiI=; b=uBDO7N4mTORA9BNayX/15wjGEH+ToDbgWtQtmy9OoEISAmYT7uv0oydprpBLgjG9em WxrZYIZ3UctrjMaz0QoS/wdVDZ8Gc/1NvQNuA55Of8jeskkVApVOmtNFRS4eS2VHksyS x0pVaE8oCm3k5S6l8lLrIdfFoe5+0c55l/8uJDjaEwlsFqWK9YP7bbhX+OtS3QNwFX3b /lcrtmVK1xeD7cd/EHpmaQLSByU4Iiy7QAjZWZUqn0g4KZ2FX+SNAvnFahAmZ/Tg38XL k1AS7yqWKYMdzNLGrLFr7x+UorrBeanqk6MZASwS1mlnhiwn1SXPtV1+C3NmeshKLUrN hRCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-transfer-encoding:mime-version; bh=uR/aQpBM/1CuFxQWALAF6uFoVRTQJw+RLX/Ze4DhwiI=; b=F9r1ciIhC1cjXSf+cZEtO3mNcbaKZQ1J1OzAIkzg0jftJ6TerFM8IrYr3dsXjmQYb+ MwqHF5Ps4YS29wm2/ch1iH8k/qxiclIs2S8jk6uuf1cdOhBgrz9aXUljDRNVu7ckeYRs YVFsOiUNuwwTKQXf9EduPYhjZRblf1SW0uUtiLywgD1yPZUAnXs9pTTVFcU+k3VdR+xk PP9tK0grszYH2FKM8CuFvF1mW9F8jGOyMMaM1TFqjVtSAOKfs9tANCT9AuQOqD93+wAh dF77QwwxFdLjxq+Fi2hge6aJmgrN9+kNs6ImQCYKdced4rY0TFtl1MXEzkxWooG/hDDy ZmsA==
X-Gm-Message-State: APjAAAWi4MjeE8z8POHnnVewd2SMQH6Rj4K9xFbZdYmO6Dv2EZl/1De4 mXhAMreUVT/pHVf8dEbVM3I=
X-Google-Smtp-Source: APXvYqz3zreqjULrEx7O8D/W9VIsHv7a7KSXoV76Bk1JL28a9fnlYyK3iDS7yEq7eUz68Nmtz2Y+0w==
X-Received: by 2002:a05:6638:24b:: with SMTP id w11mr2238899jaq.125.1559143349340; Wed, 29 May 2019 08:22:29 -0700 (PDT)
Received: from BL0PR06MB4321.namprd06.prod.outlook.com ([52.96.9.149]) by smtp.gmail.com with ESMTPSA id x99sm1147820ita.28.2019.05.29.08.22.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 May 2019 08:22:28 -0700 (PDT)
From: Tarek Saad <tsaad.net@gmail.com>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>, tom petch <ietfc@btconnect.com>, Italo Busi <Italo.Busi@huawei.com>, "netmod@ietf.org" <netmod@ietf.org>
CC: "teas@ietf.org" <teas@ietf.org>
Thread-Topic: [Teas] [netmod] Key collision between configured and ephemeral list entries
Thread-Index: ATRCOEZEU+Y4lZVgfPjE1wAi8EmuvjAwNjkxQ0I4RkQwMGVkMTA2RTIyuwkrULg=
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Wed, 29 May 2019 15:22:27 +0000
Message-ID: <BL0PR06MB4321DA01042ECAAD88E8420AFC1F0@BL0PR06MB4321.namprd06.prod.outlook.com>
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>
In-Reply-To: <BYAPR11MB26314CD2365C6AEC39E696EDB51F0@BYAPR11MB2631.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/-PUjZirE-Cd7OCjz__Om8CWD3C0>
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, 29 May 2019 15:22:34 -0000

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