TEAS Working Group I. Busi Internet-Draft Huawei Intended status: Informational X. Liu Expires: 23 April 2026 Alef Edge I. Bryskin Individual T. Saad Cisco Systems Inc O. Gonzalez de Dios Telefonica 20 October 2025 Profiles for Traffic Engineering (TE) Topology Data Model and Applicability to non-TE-centric Use Cases draft-ietf-teas-te-topology-profiles-04 Abstract This document describes how profiles of the Topology YANG data model, defined in RFC8795, can be used to address applications in Traffic Engineering aware (TE-aware) deployments, irrespective of whether they are TE-centric or not. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 23 April 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Busi, et al. Expires 23 April 2026 [Page 1] Internet-Draft TE Topology Profiles October 2025 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Examples of generic profiles . . . . . . . . . . . . . . . . 4 2.1. UNI Topology Discovery . . . . . . . . . . . . . . . . . 4 2.2. Administrative and Operational status management . . . . 5 2.3. Overlay and Underlay Topologies . . . . . . . . . . . . . 6 2.3.1. Supporting relationships in RFC8345 . . . . . . . . . 8 2.4. Nodes with switching limitations . . . . . . . . . . . . 8 2.5. Multipoint links . . . . . . . . . . . . . . . . . . . . 9 3. Technology-specific augmentations . . . . . . . . . . . . . . 12 3.1. Multi-inheritance . . . . . . . . . . . . . . . . . . . . 14 3.2. Example (Link augmentation) . . . . . . . . . . . . . . . 15 4. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Implemented profiles . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Normative References . . . . . . . . . . . . . . . . . . . . . 17 Informative References . . . . . . . . . . . . . . . . . . . . 18 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction Many network scenarios are being discussed in various IETF Working Groups (WGs) that are not classified as "Traffic Engineering" use cases but can be addressed by a profile (sub-set) of the Topology YANG data model, defined in [RFC8795]. Traffic Engineering (TE) is defined in [I-D.ietf-teas-rfc3272bis] as aspects of Internet network engineering that deal with the issues of performance evaluation and performance optimization of operational IP networks. TE encompasses the application of technology and scientific principles to the measurement, characterization, modeling, and control of Internet traffic. Busi, et al. Expires 23 April 2026 [Page 2] Internet-Draft TE Topology Profiles October 2025 The Topology YANG data model, defined in [RFC8795], augments the Network Topology YANG data model, defined in [RFC8345], with generic and technology-agnostic features that are not only applicable to TE- centric deployments, but also applicable to non-TE-centric yet TE- aware deployments. A TE-aware deployment is one where the topology carries information that can be used to influence how traffic can be engineered within the network. In some scenarios, this information can be leveraged even in use cases where traffic doesn't need to be engineered. Examples of generic TE-aware features that can apply to both TE- centric and non-TE-centric use-cases are: inter-domain link discovery (plug-id), geo-localization, multi-layer topology representation, node-specific switching limitation, link reliability, and topology abstraction. It is also worth noting that also the boundary between the TE- specific model constructs and the core network topology model constructs is also blurred since new applications may need to leverage on constructs which was originally defined to support TE- centric scenarios but that are also needed to support these new applications. An example of a concept that originated from TE-centric scenarios but can be considered a core network topology model construct is the SRLG. New applications such as what-if analysis need to be aware of the SRLG information also for non-TE-centric scenarios to provide reliable results. It is also worth noting that the Topology YANG data model, defined in [RFC8795], is quite an extensive and comprehensive model in which most features are optional. Therefore, even though the full model appears to be complex, at the first glance, a profile (sub-set) of the model can be used to address specific scenarios irrespective of whether they are TE-centric or not. The implementation of profiles can simplify and expedite adoption of the Topology YANG data model, defined [RFC8795], and allow for its reuse even for non-TE-centric use-cases. The key question is whether all or some of the attributes defined in the Topology YANG data model, defined in [RFC8795], are needed to address a given network scenario. Section 2 provides examples where profiles of the Topology YANG data model, defined in [RFC8795], can be used to address some generic use cases applicable to both TE-centric and non-TE-centric deployments. Busi, et al. Expires 23 April 2026 [Page 3] Internet-Draft TE Topology Profiles October 2025 Understanding that these profiles are generic would be more straightforward if the profiled YANG data nodes where defined under a container with a different name than 'te' or directly under the parent YANG data node. However, the 'te' container in the context of [RFC8795], should be understood as the container of YANG data nodes providing TE-aware topology information. 2. Examples of generic profiles 2.1. UNI Topology Discovery The following profile of the Topology YANG data model, defined in [RFC8795], can be used to support the UNI Topology Discovery, or in general, inter-domain link discovery: module: ietf-te-topology augment /nw:networks/nw:network/nw:network-types: +--rw te-topology! augment /nw:networks/nw:network/nw:node/nt:termination-point: +--rw te-tp-id? te-types:te-tp-id +--rw te! +--rw admin-status? | te-types:te-admin-status +--rw inter-domain-plug-id? binary +--ro oper-status? te-types:te-oper-status Figure 1: UNI Topology It is also worth noting that the UNI links can also be TE (e.g. an OTN UNI) or non-TE (e.g., an Ethernet UNI) as well as multi-function UNI links, supporting both TE and non-TE technologies, such as the UNI links, described in Section 4.4 of [I-D.ietf-ccamp-transport-nbi-app-statement], which can be configured either OTN UNI or Ethernet UNI or SDH UNI. The UNI Topology profiled YANG data model shown in Figure 1 can also be used with technology-specific UNI augmentations, as described in Section 3. Technology-specific augmentations can for example describe the capability of the TP to be configured as a UNI for the types of services supported by the UNI (e.g., L2VPN/L3VPN). For example, in [I-D.ietf-ccamp-eth-client-te-topo-yang], the eth-svc container is defined to represent the capabilities of the Termination Point (TP) to be configured as an Ethernet UNI, together with the Ethernet classification and VLAN operations supported by that TP. The [I-D.ietf-ccamp-otn-topo-yang] provides another example, where: Busi, et al. Expires 23 April 2026 [Page 4] Internet-Draft TE Topology Profiles October 2025 * the client-svc container is defined to represent the capabilities of the TP to be configured as an transparent client UNI (e.g., STM-N, Fiber Channel or transparent Ethernet); * the OTN technology-specific Link Termination Point (LTP) augmentations are defined to represent the capabilities of the TP to be configured as an OTN UNI, together with the information about OTN label and bandwidth availability at the OTN UNI. Te UNI Topology profiled YANG data model shown in Figure 1 does not require the network to be a TE network and, therefore, it could be used as a core network topology model to discover UNIs (or in general any external link) for TE and non-TE networks as well as multi-layer networks encompassing both TE and non-TE layers. The advantages of using the UNI Topology profiled YANG data model shown in Figure 1 as a core network topology model is to have a common solutions for: * discovering UNIs as well as inter-domain NNI links, which is applicable to any technology (TE or non TE) used at the UNI or within the network; * modelling non TE UNIs such as Ethernet, and TE UNIs such as OTN, as well as UNIs which can configured as TE or non-TE (e.g., being configured as either Ethernet or OTN UNI). 2.2. Administrative and Operational status management The following profile of the Topology YANG data model, defined in [RFC8795], can be used to manage the administrative and operational for nodes, termination points and links as well as to associate some administrative names to network topologies, nodes, termination points and links: Busi, et al. Expires 23 April 2026 [Page 5] Internet-Draft TE Topology Profiles October 2025 module: ietf-te-topology augment /nw:networks/nw:network/nw:network-types: +--rw te-topology! augment /nw:networks/nw:network: +--rw te-topology-identifier | +--rw provider-id? te-global-id | +--rw client-id? te-global-id | +--rw topology-id? te-topology-id +--rw te! +--rw name? string augment /nw:networks/nw:network/nw:node: +--rw te-node-id? te-types:te-node-id +--rw te! +--rw te-node-attributes | +--rw admin-status? te-types:te-admin-status | +--rw name? string +--ro oper-status? te-types:te-oper-status augment /nw:networks/nw:network/nt:link: +--rw te! +--rw te-link-attributes | +--rw name? string | +--rw admin-status? te-types:te-admin-status +--ro oper-status? te-types:te-oper-status augment /nw:networks/nw:network/nw:node/nt:termination-point: +--rw te-tp-id? te-types:te-tp-id +--rw te! +--rw admin-status? te-types:te-admin-status +--rw name? string +--ro oper-status? te-types:te-oper-status Figure 2: Generic Topology with admin and operational state 2.3. Overlay and Underlay Topologies The following profile of the Topology YANG data model, defined in [RFC8795], can be used to manage the overlay/underlay relationships for nodes and links, as described in section 5.8 of [RFC8795]: Busi, et al. Expires 23 April 2026 [Page 6] Internet-Draft TE Topology Profiles October 2025 module: ietf-te-topology augment /nw:netorks/nw:network/nw:network-types: +--rw te-topology! augment /nw:networks/nw:network/nw:node: +--rw te-node-id? te-types:te-node-id +--rw te! +--rw te-node-attributes +--rw underlay-topology {te-topology-hierarchy}? +--rw network-ref? -> /nw:networks/network/network-id augment /nw:networks/nw:network/nt:link: +--rw te! +--rw te-link-attributes +--rw underlay {te-topology-hierarchy}? +--rw enabled? boolean +--rw primary-path +--rw network-ref? | -> /nw:networks/network/network-id +--rw path-element* [path-element-id] +--rw path-element-id uint32 +--rw (type)? +--:(numbered-link-hop) | +--rw numbered-link-hop | +--rw link-tp-id te-tp-id | +--rw hop-type? te-hop-type | +--rw direction? te-link-direction +--:(unnumbered-link-hop) +--rw unnumbered-link-hop +--rw link-tp-id te-tp-id +--rw node-id te-node-id +--rw hop-type? te-hop-type +--rw direction? te-link-direction Figure 3: Generic Topology with overlay/underlay information The advantages of using the underlay/overlay network profiled YANG data model shown in Figure 3 as a core network topology model is to have a common solutions for navigating between overlay/underlay network topologies where: * both the underlay and overlay network topologies are TE networks; * both the underlay and overlay network topologies are non-TE networks; * the underlay and overlay network topologies are TE and non-TE networks; Busi, et al. Expires 23 April 2026 [Page 7] Internet-Draft TE Topology Profiles October 2025 * the underlay or the overlay network topology is a multi-layer network encompassing both TE and non-TE layers. 2.3.1. Supporting relationships in RFC8345 [RFC8345] defines the modeling constructs for supporting relations, including supporting network (i.e. topology), supporting node, supporting link, and supporting termination point. These relation constructs facilitate network mappings and transformations. One use case is to map a customized topology to a native topology. The customized topology uses different name spaces from the native topology when naming nodes, links, or termination points. There is a supporting relationship between a modeling construct in the customized topography to its counterpart in the native topology. In such a relationship, the modeling constructs at both ends represent the same type of network objects, which can be network (i.e. topology), node, link, or termination point. [RFC8795] defines the modeling constructs for network overlay and underlay relations. When the network overlay technology is used, some network objects (nodes or links) in the overlay network are built on top of network objects in the underlay network. As a result, the overlay-underlay relationship is created between network objects in the overlay networks and other network objects in the underlay network. Between the network object pairs in the overlay- underlay relationship, the types of the network objects are usually not the same. The network object can be a node in the overlay network, while the related underlay network object is a topology in the underlay network. A link in the overlay network can be related to a path that consists of a sequence of nodes and links in the underlay network. 2.4. Nodes with switching limitations It is worth noting that a node, as defined in [RFC8345], does not provide any information about the possible connectivity between its TPs. A node can have some switching limitations where connectivity is not possible between all its TP pairs, for example when: * the node represents a physical device with switching limitations; * the node represents an abstraction of a network topology. Busi, et al. Expires 23 April 2026 [Page 8] Internet-Draft TE Topology Profiles October 2025 The following profile of the Topology YANG data model, defined in [RFC8795], can be used for the management of nodes with switching limitations by defining the node connectivity matrix to represent feasible connections between termination points across the nodes: module: ietf-te-topology augment /nw:networks/nw:network/nw:network-types: +--rw te-topology! augment /nw:networks/nw:network/nw:node: +--rw te-node-id? te-types:te-node-id +--rw te! +--rw te-node-attributes +--rw connectivity-matrices +--rw number-of-entries? uint16 +--rw is-allowed? boolean +--rw connectivity-matrix* [id] +--rw id uint32 +--rw from | +--rw tp-ref? leafref +--rw to | +--rw tp-ref? leafref +--rw is-allowed? boolean Figure 4: Generic Topology with connectivity constraints 2.5. Multipoint links According to Section 4.4.4 of [RFC8345], multipoint links can be "represented through pseudonodes (similar to IS-IS, for example)". Each access point can have different directionality with respect to the multipoint link, as shown in Figure 5: - an access point of a multipoint link can be able to both transmit and receive traffic: this access point can be modelled as a TP (e.g., TP A in Figure 5) terminating two links, one incoming link (e.g., Link 1 in Figure 5) and one outgoing link (e.g., Link 2 in Figure 5); - an access point of a multipoint link can be able only to receive traffic: this access point can be modelled as a TP (e.g., TP B in Figure 5) with only one incoming link (e.g., Link 3 in Figure 5); - an access point of a multipoint link can be able only to transmit traffic: this access point can be modelled as a TP (e.g., TP C in Figure 5) with only one outgoing link (e.g., Link 4 in Figure 5). Busi, et al. Expires 23 April 2026 [Page 9] Internet-Draft TE Topology Profiles October 2025 | | Link3 | V +-+ / \ | B | \ / +--------+-+--------+ / \ / \ | | | | Link 1 | | +-+ | | +-+ ----->/ \| |/ \ | A | Psedonode | C |-----> <-----\ /| |\ / +-+ | | +-+ Link 4 Link 2 | | | | | | \ / \ / +-------------------+ Figure 5: Example of a pseudonode modelling a multipoint link The switching limitations of the pseudonode, as defined in Section 2.4, provides sufficient information to identify the type of multipoint link: - in case of multipoint links, the connectivity matrix of the pseudnode, reports that connectivity is enabled by default between all the TPs of the node; - in case of point-to- multipoint links, the connectivity matrix of the pseudnode, reports that connectivity is possible only between the root TP and the leaf TPs >> - if the point-to-multipoint link is bidirectional, the connectivity matrix of the pseudonodes reports that connectivity is possible from the root TP to the leaf TPs as well as from the leaf TPs to the root TP; >> - the connectivity matrix of the psuedonode can also describe point-to-multipoint links with more than one root (also known as rooted-multipoint links), indicating also whether connectivity between root TPs is allowed or not; - in case of hybrid multipoint links, as defined in [I-D.ietf-nmop-simap-concept], the connectivity matrix of the pseunode reports the list of TP pairs for which connectivity is allowed or not allowed. Busi, et al. Expires 23 April 2026 [Page 10] Internet-Draft TE Topology Profiles October 2025 It is worth noting that the directionality of the access point of a multipoint link overrides the switching limitations of the pseudonode. For example, even if the connectivity matrix of the psuedonode in Figure 5 indicates that connectivity is possible between TP A and TP B, the traffic entering the pseudonode from TP A cannot be transmitted by TP B since there is no outgoing link from TP B. Therefore, the connectivity matrix of a pseudonode modelling a point- to-multipoint unidirectional link, does not need to report that connectivity is only possible from the root TP to the leaf TPs but it can report that connectivity is possible by default between all the TPs of the node. The pseudonode represents a point-to-multipoint unidirectional link, as indicated by a single root TP that can only receive traffic and one or more leaf TPs that can only transmit traffic. | | Link1 | V +-+ / \ | A | \ / +--------+-+--------+ / \ / \ | | | | Link 2 | | Link 3 +-+ | | +-+ / \| |/ \ <----| B | Psedonode | C |-----> \ /| |\ / +-+ | | +-+ | | | | | | \ / \ / +-------------------+ Figure 6: Example of a pseudonode modelling an undirectional point-to- multipoint link Busi, et al. Expires 23 April 2026 [Page 11] Internet-Draft TE Topology Profiles October 2025 For example, Figure 6 shows an example of a pseudonode representing an unidirectional point-to-multipoint link where the TP A is the root TP and TPs B and C are the two leaf TPs. 3. Technology-specific augmentations There are two main options to define technology-specific Topology Models which can use the attributes defined in the Topology YANG data model, defined in [RFC8795]. Both options are applicable to any possible profile of the TE Topology Model, such as those defined in Section 2. The first option is to define a technology-specific TE Topology Model which augments the TE Topology Model, as shown in Figure 7: +-------------------+ | Network Topology | +-------------------+ ^ | | Augments | +-----------+-----------+ | TE Topology | | (profile) | +-----------------------+ ^ | | Augments | +----------+----------+ | Technology-Specific | | TE Topology | +---------------------+ Figure 7: Augmenting the TE Topology Model This approach is more suitable for cases when the technology-specific TE topology model provides augmentations to the TE Topology constructs, such as bandwidth information (e.g., link bandwidth), tunnel termination points (TTPs) or connectivity matrices. It also allows providing augmentations to the Network Topology constructs, such as nodes, links, and termination points (TPs). This is the approach currently used in [I-D.ietf-ccamp-eth-client-te-topo-yang] and [I-D.ietf-ccamp-otn-topo-yang]. Busi, et al. Expires 23 April 2026 [Page 12] Internet-Draft TE Topology Profiles October 2025 It is worth noting that a profile of the technology-specific TE Topology model not using any TE topology attribute or constructs can be used to address any use case that do not require these attributes. In this case, only the 'te-topology' presence container of the TE Topology Model needs to be implemented because it is the parent container for the 'network-type' representing the technology-specific topology model. Other data nodes defined in the TE Topology Model do not need to be implemented by this profile. The second option is to define a technology-specific Network Topology Model which augments the Network Topology Model and to rely on the multiple inheritance capability, which is implicit in the network- types definition of [RFC8345], to allow using also the generic attributes defined in the TE Topology model: +-----------------------+ | Network Topology | +-----------------------+ ^ ^ | | Augments +---+ +--+ Augments | | +---------+---+ +----------+----------+ | TE Topology | | Technology-specific | | (profile) | | Network Topology | +-------------+ +---------------------+ Figure 8: Augmenting the Network Topology Model with multi- inheritance This approach is more suitable in cases where the technology-specific Network Topology Model provides augmentation only to the constructs defined in the Network Topology Model, such as nodes, links, and termination points (TPs). Therefore, with this approach, only the generic attributes defined in the TE Topology Model could be used. It is also worth noting that in this case, technology-specific augmentations for the bandwidth information could not be defined. In principle, it would be also possible to define both a technology specific TE Topology Model which augments the TE Topology Model, and a technology-specific Network Topology Model which augments the Network Topology Model and to rely on the multiple inheritance capability, as shown in Figure 9: Busi, et al. Expires 23 April 2026 [Page 13] Internet-Draft TE Topology Profiles October 2025 +-----------------------+ | Network Topology | +-----------------------+ ^ ^ | | Augments +---+ +--+ Augments | | +---------+---+ +----------+----------+ | TE Topology | | Technology-specific | | (profile) | | Network Topology | +-------------+ +---------------------+ ^ ^ | | | Augments | References | | +----------+----------+ | | Technology-Specific +--------------+ | TE Topology | +---------------------+ Figure 9: Augmenting both the Network and TE Topology Models This option does not provide any technical advantage with respect to the first option, shown in Figure 7, but could be useful to add augmentations to the TE Topology constructs and to re-use an already existing technology-specific Network Topology Model. It is worth noting that the technology-specific TE Topology model can reference constructs defined by the technology-specific Network Topology model but it could not augment constructs defined by the technology-specific Network Topology model. 3.1. Multi-inheritance As described in section 4.1 of [RFC8345], the network types should be defined using presence containers to allow the representation of network subtypes. The hierarchy of network subtypes can be single hierarchy, as shown in Figure 7. In this case, each presence container contains at most one child presence container, as shows in the JSON code below: Busi, et al. Expires 23 April 2026 [Page 14] Internet-Draft TE Topology Profiles October 2025 { "ietf-network:ietf-network": { "ietf-te-topology:te-topology": { "example-te-topology": {} } } } The hierarchy of network subtypes can also be multi-hierarchy, as shown in Figure 8 and Figure 9. In this case, one presence container can contain more than one child presence containers, as show in the JSON codes below: { "ietf-network:ietf-network": { "ietf-te-topology:te-topology": {} "example-network-topology": {} } } { "ietf-network:ietf-network": { "ietf-te-topology:te-topology": { "example-te-topology": {} } "example-network-topology": {} } } Other examples of multi-hierarchy topologies are described in [I-D.ietf-teas-yang-sr-te-topo]. 3.2. Example (Link augmentation) This section provides an example on how technology-specific attributes can be added to the Link construct: Busi, et al. Expires 23 April 2026 [Page 15] Internet-Draft TE Topology Profiles October 2025 +--rw link* [link-id] +--rw link-id link-id +--rw source | +--rw source-node? -> ../../../nw:node/node-id | +--rw source-tp? leafref +--rw destination | +--rw dest-node? -> ../../../nw:node/node-id | +--rw dest-tp? leafref +--rw supporting-link* [network-ref link-ref] | +--rw network-ref | | -> ../../../nw:supporting-network/network-ref | +--rw link-ref leafref +--rw example-link-attributes | <...> +--rw te! +--rw te-link-attributes +--rw name? string +--rw example-te-link-attributes | <...> +--rw max-link-bandwidth +--rw te-bandwidth +--rw (technology)? +--:(generic) | +--rw generic? te-bandwidth +--:(example) +--rw example? example-bandwidth Figure 10: Augmenting the Link with technology-specific attributes The technology-specific attributes within the example-link-attributes container can be defined either in the technology-specific TE Topology Model (Option 1) or in the technology-specific Network Topology Model (Option 2 or Option 3). These attributes can only be non-TE and do not require the implementation of the te container. The technology-specific attributes within the example-te-link- attributes container as well as the example max-link-bandwidth can only be defined in the technology-specific TE Topology Model (Option 1 or Option 3). These attributes can be TE or non-TE and require the implementation of the te container. 4. Open Issues 4.1. Implemented profiles When a server implements a profile of the TE topology model, there is no standardized mechanism for the server to report to the client the subset of the model being implemented. Busi, et al. Expires 23 April 2026 [Page 16] Internet-Draft TE Topology Profiles October 2025 This might not be an issue in case the TE topology profile is read by the the client because the server reports in the operational datastore only the leaves which have been implemented, as described in section 5.3 of [RFC8342]. More investigation is instead required in case the TE topology profile is configured by the client, to avoid that the client tries to write an attribute not used in the TE Topology profile implemented by the server. It is also worth noting that the supported profile may also depend on other attributes (for example the network type), so the YANG deviation mechanism is not applicable to this scenario. Note: that this issue is also tracked in github as issue #161. 5. Security Considerations This document provides only information about how the Topology YANG data model, defined in [RFC8795], can be profiled to address some scenarios which are not considered as TE. As such, this document does not introduce any additional security considerations besides those already defined in [RFC8795]. 6. IANA Considerations This document requires no IANA actions. Acknowledgments The authors would like to thank Vishnu Pavan Beeram, Daniele Ceccarelli, Jonas Ahlberg and Scott Mansfield for providing useful suggestions for this draft. This document was prepared using kramdown. Initial versions of this document were prepared using 2-Word- v2.0.template.dot. References Normative References [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . Busi, et al. Expires 23 April 2026 [Page 17] Internet-Draft TE Topology Profiles October 2025 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 2018, . [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and O. Gonzalez de Dios, "YANG Data Model for Traffic Engineering (TE) Topologies", RFC 8795, DOI 10.17487/RFC8795, August 2020, . Informative References [I-D.ietf-ccamp-eth-client-te-topo-yang] Yu, C., Zheng, H., Guo, A., Busi, I., Xu, Y., Zhao, Y., and X. Liu, "A YANG Data Model for Ethernet TE Topology", Work in Progress, Internet-Draft, draft-ietf-ccamp-eth- client-te-topo-yang-10, 15 October 2025, . [I-D.ietf-ccamp-otn-topo-yang] Zheng, H., Busi, I., Liu, X., Belotti, S., and O. G. de Dios, "A YANG Data Model for Optical Transport Network Topology", Work in Progress, Internet-Draft, draft-ietf- ccamp-otn-topo-yang-20, 7 November 2024, . [I-D.ietf-ccamp-transport-nbi-app-statement] Busi, I., King, D., Zheng, H., and Y. Xu, "Transport Northbound Interface Applicability Statement", Work in Progress, Internet-Draft, draft-ietf-ccamp-transport-nbi- app-statement-17, 10 July 2023, . [I-D.ietf-nmop-simap-concept] Havel, O., Claise, B., de Dios, O. G., and T. Graf, "SIMAP: Concept, Requirements, and Use Cases", Work in Progress, Internet-Draft, draft-ietf-nmop-simap-concept- 07, 18 October 2025, . [I-D.ietf-teas-rfc3272bis] Farrel, A., "Overview and Principles of Internet Traffic Engineering", Work in Progress, Internet-Draft, draft- Busi, et al. Expires 23 April 2026 [Page 18] Internet-Draft TE Topology Profiles October 2025 ietf-teas-rfc3272bis-27, 12 August 2023, . [I-D.ietf-teas-yang-sr-te-topo] Liu, X., Bryskin, I., Beeram, V. P., Saad, T., Shah, H., and S. Litkowski, "YANG Data Model for SR and SR TE Topologies on MPLS Data Plane", Work in Progress, Internet-Draft, draft-ietf-teas-yang-sr-te-topo-19, 4 July 2024, . Contributors Aihua Guo Futurewei Inc. Email: aihuaguo.ietf@gmail.com Haomian Zheng Huawei Email: zhenghaomian@huawei.com Sergio Belotti Nokia Email: sergio.belotti@nokia.com Authors' Addresses Italo Busi Huawei Email: italo.busi@huawei.com Xufeng Liu Alef Edge Email: xufeng.liu.ietf@gmail.com Igor Bryskin Individual Email: i_bryskin@yahoo.com Tarek Saad Cisco Systems Inc Busi, et al. Expires 23 April 2026 [Page 19] Internet-Draft TE Topology Profiles October 2025 Email: tsaad.net@gmail.com Oscar Gonzalez de Dios Telefonica Email: oscar.gonzalezdedios@telefonica.com Busi, et al. Expires 23 April 2026 [Page 20]