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

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

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
Content-Type: multipart/alternative; boundary="_000_3bb69b0a0b514806909cc35ea7ce751ahuaweicom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/SdQbL_yOavuqQxSJqOvJK_d7qTg>
Subject: [Teas] A question about the design of TE TOPOLOGY objects' identifier
Precedence: list

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!

B.R.
Chaode

[Teas] A question about the design of TE TOPOLOGY… yuchaode