[Teas] TE tunnel name collision between configured and ephemeral list entries

Italo Busi <Italo.Busi@huawei.com> Mon, 04 May 2020 22:22 UTC

Return-Path: <Italo.Busi@huawei.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 032F73A1174 for <teas@ietfa.amsl.com>; Mon, 4 May 2020 15:22:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.102
X-Spam-Level: *
X-Spam-Status: No, score=1.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEXHASH_WORD=2.999, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id j6o1Dj_J19Dt for <teas@ietfa.amsl.com>; Mon, 4 May 2020 15:22:16 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com []) (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 A9CF03A1172 for <teas@ietf.org>; Mon, 4 May 2020 15:22:16 -0700 (PDT)
Received: from lhreml721-chm.china.huawei.com (unknown []) by Forcepoint Email with ESMTP id BCD669E0EB3C2D7AC0CD for <teas@ietf.org>; Mon, 4 May 2020 23:22:14 +0100 (IST)
Received: from fraeml707-chm.china.huawei.com ( by lhreml721-chm.china.huawei.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 4 May 2020 23:22:14 +0100
Received: from fraeml715-chm.china.huawei.com ( by fraeml707-chm.china.huawei.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 5 May 2020 00:22:13 +0200
Received: from fraeml715-chm.china.huawei.com ([]) by fraeml715-chm.china.huawei.com ([]) with mapi id 15.01.1913.007; Tue, 5 May 2020 00:22:13 +0200
From: Italo Busi <Italo.Busi@huawei.com>
To: "teas@ietf.org" <teas@ietf.org>
Thread-Topic: TE tunnel name collision between configured and ephemeral list entries
Thread-Index: AdYiXe0cINdHrUEbRLG3OPdiibNoIQ==
Date: Mon, 4 May 2020 22:22:13 +0000
Message-ID: <c12291921ff34a35896051176538f140@huawei.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/related; boundary="_004_c12291921ff34a35896051176538f140huaweicom_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/-Ymg8z8u38U_VNSA3lEKwIDUzuQ>
Subject: [Teas] TE tunnel name 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, 04 May 2020 22:22:19 -0000

This issue has been discussed during IETF 105 (slides 5 and 6):


However, I am not sure the proposed solution could cover all the cases of potential conflicts

For example, a possible rule could be to add the prefix “auto-” for auto-created tunnels on a device

If the same rule is applied for auto-created tunnels on a controller, we would get into a potential name collision between auto-created tunnels on a device and on the controller on the device-controller interface

Another rule is to add the prefix “remote-R1-” to the tunnel names learnt by a controller from a device.

If the name/address of R1 is not globally unique but only unique in the context of the controller, a hierarchical controller can learn tunnels with the same name starting with the prefix “remote-R1-” from different controllers. If we apply this rule recursively, we could get prefixes like “remove-NC1-remote-R1-” and run into the risk to have tunnel names with long prefixes, making the tunnel name less readable

Another potential risk is that embedding the R1 name/address within tunnel names’ prefixes, it could be difficult form a controller in an higher level of control hierarchy to hide the R1 name/address for privacy/security reasons

I think it would be worthwhile reconsidering the proposal made by Dhruv at the microphone to use both a namespace + name as keys of the tunnel list

Alternatively, in order to avoid adding a new key to the tunnel list, the key of the tunnel list could be redefined to be something like an URI with the namespace and tunnel name built into it (e.g., /R1/foo) and, to improve the readability, the tunnel name can be re-defined to be another leaf, not being used as a key for the tunnel list

What do you think?

Thanks, Italo

Italo Busi
Principal Optical Transport Network Research Engineer


Huawei Technologies Italia S.r.l.
Address: Centro Direzionale Milano 2, Palazzo Verrocchio, 20090 Segrate (MI)
Tel: +39 345 4721946 - Mobile: Italo.busi@huawei.com<mailto:Italo.busi@huawei.com>

Huawei Technologies Italia S.r.l. is a company registered in Italy at the Company Registration Office of Milan, with registered number 04501190963 and equity capital €3,000,000 fully paid up, whose registered office is in Milan, Via Lorenteggio 240, Tower A, 20147 Milan, Italy. Huawei Technologies Italia S.r.l. is 100% owned by Huawei Technologies Cooperatief U.A.
CONAI Reg. No. cc 12639454 - A.E.E. Registry No. IT10010000006521 - Batteries and Accumulators Registry No. IT12050P00002839.
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! Thank you.
PRIVACY NOTICE: Pursuant to Art. 13 of the General Data Protection Regulation 2016/679 (GDPR), Huawei Technologies Italia S.r.l. informs you that the personal data contained in this email will be collected and treated for the acquisition of information preliminary to the conclusion of contracts, for the definition of the contractual relationship, as well as for the fulfillment of legal requirements related to civil, tax and accounting law or any other legal obligation to which Huawei may be subject. Personal data will not be subject to disclosure and spread unless otherwise required by law. Huawei will take appropriate security measures to protect personal data against loss, misuse disclosure or destruction of the information. Personal Data held may be transferred to countries outside the European Union, however Huawei Italia has put in place appropriate safeguards for the transfer of personal data to third countries by adopting the standard data protection clauses of the EU Commission. Personal Data are kept for a period necessary for the fulfillment of contract obligations unless otherwise required by law. You can exercise your rights under Art. 15 and following of the GDPR (i.e. right of access, rectification, erasure, restriction, portability, object) by contacting Huawei at this email address: dataprotection@huawei.com<mailto:dataprotection@huawei.com> or through the following channel: www.huawei.com/en/personal-data-request<http://www.huawei.com/en/personal-data-request>st>. You have also the right to lodge a complaint with the competent supervisory authorities. If you need any further information or have any queries on how Huawei process your personal data, please send an email to our Data Protection Officer at dpo@huawei.com<mailto:dpo@huawei.com>.The Data Controller is Huawei Technologies Italia S.r.l. with registered office in Milan, Via Lorenteggio 240 Tower A, 20147.