[Teas] A question about the design of TE TOPOLOGY objects' identifier

yuchaode <yuchaode@huawei.com> Fri, 15 July 2022 07:47 UTC

Return-Path: <yuchaode@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 CCDF3C15A721 for <teas@ietfa.amsl.com>; Fri, 15 Jul 2022 00:47:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id IgV844mpvDlr for <teas@ietfa.amsl.com>; Fri, 15 Jul 2022 00:47:22 -0700 (PDT)
Received: from sinmsgout02.his.huawei.com (sinmsgout02.his.huawei.com []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BBABC159493 for <teas@ietf.org>; Fri, 15 Jul 2022 00:47:21 -0700 (PDT)
Received: from fraeml705-chm.china.huawei.com (unknown []) by sinmsgout02.his.huawei.com (SkyGuard) with ESMTP id 4Lkk2502w3z9v7J0 for <teas@ietf.org>; Fri, 15 Jul 2022 15:46:20 +0800 (CST)
Received: from canpemm100003.china.huawei.com ( by fraeml705-chm.china.huawei.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2375.24; Fri, 15 Jul 2022 09:47:09 +0200
Received: from canpemm500002.china.huawei.com ( by canpemm100003.china.huawei.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Fri, 15 Jul 2022 15:47:08 +0800
Received: from canpemm500002.china.huawei.com ([]) by canpemm500002.china.huawei.com ([]) with mapi id 15.01.2375.024; Fri, 15 Jul 2022 15:47:08 +0800
From: yuchaode <yuchaode@huawei.com>
To: TEAS WG <teas@ietf.org>
Thread-Topic: A question about the design of TE TOPOLOGY objects' identifier
Thread-Index: AdiYHHiZKNL9cI/xR+Ghg6UswO0Crw==
Date: Fri, 15 Jul 2022 07:47:08 +0000
Message-ID: <3bb69b0a0b514806909cc35ea7ce751a@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_3bb69b0a0b514806909cc35ea7ce751ahuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/SdQbL_yOavuqQxSJqOvJK_d7qTg>
Subject: [Teas] A question about the design of TE TOPOLOGY objects' identifier
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 15 Jul 2022 07:47:23 -0000

Hello friends,

I have a question about model which I think could be taken into account when designing the updated draft, draft-ietf-teas-rfc8776-update, based on some issues identified when integrating the IETF TE topology and tunnel models implementations with existing OSS implementations.
In my consideration, the ietf-te-types model serves for ietf-te-topology & ietf-te models. At the same time, we should notice that the TE topology model augments both the network model and the network topology models.
In the network model and network topology model, they have defined network, link, node and termination point objects and their identifiers (network-id, link-id, node-id and tp-id) as URIs. When the clients want to retrieve these objects from server, the clients need to use the identifier system defined by network model and network topology model.
But we notice that te-topology defines another identifier system, based on provider-id, client-id and topology-id for topology, link-index for link, te-node-id for node and te-tp-id for termination point. And this ID system is the only one used by the TE tunnel model.
There could be an odd scenario that the client uses the network ID system for TE topology retrieval and uses the TE topology ID system for TE tunnel provisioning.
>From YANG syntax perspective, the identifiers defined in the TE topology model could not replace the identifiers defined in the network topology model.  If TE topology model still want to provide its own identifier system, IMHO, it should allow the server to implement it following the same identifier system used by the network topology model to have a unified ID system.
It is possible to request a client to maintain a mapping table between the two identifier systems but some clients (e.g., existing OSS implementations) are not willing to implement this mapping and there is no other solution to avoid this issue on the server side. We could not change the identifiers defined in te-types model to URI directly in case some vendors or OSS have implemented these identifiers. So I suggest to change the types of the te-node-id, link-index and te-tp-id to become a union type which should include the previous type definition for compatibility consideration and include type definition in network types for unified ID consideration.
And in TE tunnel model, if the object's identifier is defined in te-types model, it should reference the type in te types model instead of defining it directly even if it is same type semantically, in case TE tunnel model needs to be refreshed when te-types model is updated.

This is my rough idea towards te-types model, please feel free to give your comments. Thank you!