Profiles for Traffic Engineering (TE) Topology Data Model and Applicability to non-TE-centric Use Cases
draft-ietf-teas-te-topology-profiles-06
| Document | Type | Active Internet-Draft (teas WG) | |
|---|---|---|---|
| Authors | Italo Busi , Xufeng Liu , Igor Bryskin , Tarek Saad , Oscar Gonzalez de Dios | ||
| Last updated | 2026-07-05 | ||
| Replaces | draft-busi-teas-te-topology-profiles | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-teas-te-topology-profiles-06
TEAS Working Group I. Busi
Internet-Draft Huawei
Intended status: Informational X. Liu
Expires: 6 January 2027 I. Bryskin
Individual
T. Saad
Cisco Systems Inc
O. Gonzalez de Dios
Telefonica
5 July 2026
Profiles for Traffic Engineering (TE) Topology Data Model and
Applicability to non-TE-centric Use Cases
draft-ietf-teas-te-topology-profiles-06
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 6 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Busi, et al. Expires 6 January 2027 [Page 1]
Internet-Draft TE Topology Profiles July 2026
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. Multi-domain Links Discovery . . . . . . . . . . . . . . 4
2.2. Administrative and Operational status management . . . . 6
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 . . . . . . . . . . . . . . . . . . . . 15
3.2. Example (Link augmentation) . . . . . . . . . . . . . . . 16
4. Implementation Status . . . . . . . . . . . . . . . . . . . . 17
4.1. ACTN multi-vendor interoperability tests . . . . . . . . 18
4.2. ETSI Plugtests . . . . . . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Normative References . . . . . . . . . . . . . . . . . . . . . 19
Informative References . . . . . . . . . . . . . . . . . . . . 20
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
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 [RFC9522] 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.
According to section 1.2 of [RFC9522]:
The key elements required in any TE solution are as follows:
Busi, et al. Expires 6 January 2027 [Page 2]
Internet-Draft TE Topology Profiles July 2026
1. Policy
2. Path steering
3. Resource management
Some TE solutions rely on these elements to a lesser or greater
extent. Debate remains about whether a solution can truly be
called "TE" if it does not include all of these elements. For the
sake of this document, we assert that all TE solutions must
include some aspects of all of these elements. Other solutions
can be classed as "partial TE" and also fall in scope of this
document.
As a consequence, the line between what is TE and what is not TE is
quite blurred.
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.
Busi, et al. Expires 6 January 2027 [Page 3]
Internet-Draft TE Topology Profiles July 2026
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.
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. Multi-domain Links Discovery
The following profile of the Topology YANG data model, defined in
[RFC8795], can be used to support the 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: Inter-domain Link Discovery
It is also worth noting that the inter-domain links can also be TE
(e.g. an OTN link) or non-TE (e.g., an Ethernet link) as well as
multi-function links, supporting both TE and non-TE technologies,
Busi, et al. Expires 6 January 2027 [Page 4]
Internet-Draft TE Topology Profiles July 2026
such as the links, described in Section 4.4 of
[I-D.ietf-ccamp-transport-nbi-app-statement], which can be configured
either OTN or Ethernet or SDH link.
The profiled YANG data model shown in Figure 1 can also be used with
technology-specific augmentations, as described in Section 3.
Technology-specific augmentations can for example describe the
capability of the TP to be support different types of services (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 link, together with the
Ethernet classification and VLAN operations supported by that TP.
The [I-D.ietf-ccamp-otn-topo-yang] provides another example, where:
* the client-svc container is defined to represent the capabilities
of the TP to be configured as an transparent client TP (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 link, together with the information
about OTN label and bandwidth availability at the OTN inter-domain
link.
The 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 any inter-domain 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 profiled YANG data model shown in
Figure 1 as a core network topology model is to have a common
solutions for:
* discovering inter-domain links, which is applicable to any
technology (TE or non TE) used at the inter-domain links or within
the network;
* modelling non TE inter-domain links, such as Ethernet, and TE
inter-domain links such as OTN, as well as inter-domain links
which can configured as TE or non-TE (e.g., being configured as
either Ethernet or OTN link).
Busi, et al. Expires 6 January 2027 [Page 5]
Internet-Draft TE Topology Profiles July 2026
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:
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 6 January 2027 [Page 6]
Internet-Draft TE Topology Profiles July 2026
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 6 January 2027 [Page 7]
Internet-Draft TE Topology Profiles July 2026
* 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 6 January 2027 [Page 8]
Internet-Draft TE Topology Profiles July 2026
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 6 January 2027 [Page 9]
Internet-Draft TE Topology Profiles July 2026
|
| Link3
|
V
+-+
/ \
| B |
\ /
+--------+-+--------+
/ \
+ +
| |
| |
Link 2 | | Link 4
+-+ | | +-+
/ \| |/ \
---->+ | | +
+ B | Psedonode | C +----->
<----+ | | +
\ /| |\ /
+-+ | | +-+
Link 1 | |
| |
| |
+ +
\ /
+-------------------+
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;
Busi, et al. Expires 6 January 2027 [Page 10]
Internet-Draft TE Topology Profiles July 2026
- 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.
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.
Busi, et al. Expires 6 January 2027 [Page 11]
Internet-Draft TE Topology Profiles July 2026
|
| Link1
|
V
+-+
/ \
| A |
\ /
+--------+-+--------+
/ \
+ +
| |
| |
Link 2 | | Link 3
+-+ | | +-+
/ \| |/ \
+ | | +
<----+ B | Psedonode | C +----->
+ | | +
\ /| |\ /
+-+ | | +-+
| |
| |
| |
+ +
\ /
+-------------------+
Figure 6: Example of a pseudonode modelling an undirectional
point-to-multipoint link
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:
Busi, et al. Expires 6 January 2027 [Page 12]
Internet-Draft TE Topology Profiles July 2026
+-------------------+
| 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].
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:
Busi, et al. Expires 6 January 2027 [Page 13]
Internet-Draft TE Topology Profiles July 2026
+-----------------------+
| 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 6 January 2027 [Page 14]
Internet-Draft TE Topology Profiles July 2026
+-----------------------+
| 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 6 January 2027 [Page 15]
Internet-Draft TE Topology Profiles July 2026
{
"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 6 January 2027 [Page 16]
Internet-Draft TE Topology Profiles July 2026
+--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. Implementation Status
Different profiles of the TE topology model, defined in [RFC8795],
has been implemented and pubicly demonstrated.
Busi, et al. Expires 6 January 2027 [Page 17]
Internet-Draft TE Topology Profiles July 2026
4.1. ACTN multi-vendor interoperability tests
A profile has been implmented and publicly demonstrated in the first
multi-vendor interoperability test of the IETF-defined ACTN framework
and YANG model standards perfmed in 2017 and involving Huawei and
Nokia Shanghai Bell, organized by and conducted in the lab facility
of China Mobile.
This interoperability test covered also multi-layer, multi-domain
topology auto-discovery, based on a work-in-progress version of the
Internet-Draft which was then finalized and published as [RFC8795].
The results of the results obtained in extensive ACTN
interoperability tests are reported in [ACTN-TEST].
4.2. ETSI Plugtests
ETSI has held two millimetre Wave Transmission (mWT) SDN to test the
northbound interface exposed by microwave (MW) network controllers:
1. The first Plugtest has been held in Sophia Antipolis, France on
21 - 24 January 2019
2. The second and third Plugtest have been merged and held in Sophia
Antipolis, France on November 2020
Both plugtests covered multi-layer and multi-domain topology
discovery scenarios, based on a work-in-progress version of the
Internet-Draft which was then finalized and published as [RFC8795].
Both plugtests have been attended by the majority of the MW vendors
and proved a good level of multi-vendor support.
The results of these ETSI plugtests are reported in [ETSI_MW-TEST-1]
and [ETSI_MW-TEST-2], which also describe the different profiles of
the TE topology model used for the MW topology model and for the
Ethernet topology model.
Based on the success of the plugtests, an ETSI Group Specification
(GS) [ETSI_MW-PROFILE] has been published to document a common
profile to be implemented at the northbound of MW network
controllers.
The use of the TE topology profile as the basis for MW technology-
specific augmentations have been specified also in the MW topology
model defined in [RFC9656].
Busi, et al. Expires 6 January 2027 [Page 18]
Internet-Draft TE Topology Profiles July 2026
It is worth noting that MW radio link technology is not a TE-centric
technology and not even a switching technology: in MW networks,
switching is performed at higher layers (e.g., Ethernet or IP) and
modelled as overlay topologies on top of the MW radio link topology.
The approach of profiling [RFC8795] worked well to model the
bandwdith of microwave links as well as the overlay/underlay
relationship between the overlay Ethernet topology and the supporting
underlay MW topology.
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.
The authors would like to thank Leonica Macciotta for his support on
the the section describing the ETSI MW plugtests.
This document was prepared using kramdown.
Initial versions of this document were prepared using 2-Word-
v2.0.template.dot.
References
Normative References
[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, <https://www.rfc-editor.org/rfc/rfc8345>.
Busi, et al. Expires 6 January 2027 [Page 19]
Internet-Draft TE Topology Profiles July 2026
[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,
<https://www.rfc-editor.org/rfc/rfc8795>.
Informative References
[ACTN-TEST]
Wang, L., Zhao, Y., Guo, A., Bryskin, I., Janz, C., Yaoi,
Y., Busi, I., Lee, Y., and S. Belotti, "ACTN Transport
Multi-Vendor Interoperability Testing", IEEE
Communications Standards Magazine, vol. 2, no. 1, pp.
82-89 DOI 10.1109/MCOMSTD.2018.1700085 , March 2018,
<https://ieeexplore.ieee.org/document/8334928>.
[ETSI_MW-PROFILE]
European Telecommunications Standards Institute,
"millimetre Wave Transmission (mWT); Definition of a
Wireless Transport Profile for Standard SDN Northbound
Interfaces", ETSI GS mWT 024 V1.1.1 (2022-03) , March
2022, <https://www.etsi.org/deliver/etsi_gs/
mWT/001_099/024/01.01.01_60/gs_mWT024v010101p.pdf>.
[ETSI_MW-TEST-1]
European Telecommunications Standards Institute, "1st mWT
SDN Plugtests Event", ETSI Plugtests Test Plan V1.0
(2019-01) , January 2019,
<https://portal.etsi.org/Portals/0/TBpages/CTI/Docs/
mWT_Plugtest1_TestPlan_v1.0.pdf>.
[ETSI_MW-TEST-2]
European Telecommunications Standards Institute, "2nd and
3rd mWT SDN Plugtests Event", ETSI Plugtests Test Plan
V1.0 (2020-11) , November 2020,
<https://portal.etsi.org/Portals/0/TBpages/CTI/Docs/
mWT_Plugtests2-3_TestPlan_v1_0.pdf>.
[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-11, 13 April 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-
eth-client-te-topo-yang-11>.
Busi, et al. Expires 6 January 2027 [Page 20]
Internet-Draft TE Topology Profiles July 2026
[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-21, 16 June 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-
otn-topo-yang-21>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-
transport-nbi-app-statement-17>.
[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-
12, 19 June 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-nmop-simap-concept-12>.
[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, <https://datatracker.ietf.org/doc/html/draft-ietf-
teas-yang-sr-te-topo-19>.
[RFC9522] Farrel, A., Ed., "Overview and Principles of Internet
Traffic Engineering", RFC 9522, DOI 10.17487/RFC9522,
January 2024, <https://www.rfc-editor.org/rfc/rfc9522>.
[RFC9656] Mansfield, S., Ed., Ahlberg, J., Ye, M., Li, X., and D.
Spreafico, "A YANG Data Model for Microwave Topology",
RFC 9656, DOI 10.17487/RFC9656, September 2024,
<https://www.rfc-editor.org/rfc/rfc9656>.
Contributors
Aihua Guo
Futurewei Inc.
Email: aihuaguo.ietf@gmail.com
Busi, et al. Expires 6 January 2027 [Page 21]
Internet-Draft TE Topology Profiles July 2026
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
Individual
Email: xufeng.liu.ietf@gmail.com
Igor Bryskin
Individual
Email: i_bryskin@yahoo.com
Tarek Saad
Cisco Systems Inc
Email: tsaad.net@gmail.com
Oscar Gonzalez de Dios
Telefonica
Email: oscar.gonzalezdedios@telefonica.com
Busi, et al. Expires 6 January 2027 [Page 22]