Skip to content

Text preparation for IETF 125 #352

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
italobusi wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Text preparation for IETF 125 #352

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
6fcbf72
Added information about implementations and clean-up
italobusi Feb 27, 2026
dafdb60
Added clarification about MW not being TE-centric
italobusi Feb 27, 2026
90974a0
Few additional updates
italobusi Mar 2, 2026
9ba4dc3
Fixed idnits
italobusi Mar 2, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
118 changes: 110 additions & 8 deletions drafts/te-topo-profile/draft-ietf-teas-te-topology-profiles.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -52,6 +52,55 @@ contributor:
org: Nokia
email: sergio.belotti@nokia.com

informative:
ACTN-TEST:
title: "ACTN Transport Multi-Vendor Interoperability Testing"
author:
-
name: Lei Wang
-
name: Yang Zhao
-
name: Aihua Guo
-
name: Igor Bryskin
-
name: Chris Janz
-
name: Yingxi Yaoi
-
name: Italo Busi
-
name: Young Lee
-
name: Sergio Belotti
date: March 2018
seriesinfo:
IEEE Communications Standards Magazine, vol. 2, no. 1, pp. 82-89
DOI 10.1109/MCOMSTD.2018.1700085
target: https://ieeexplore.ieee.org/document/8334928
ETSI_MW-TEST-1:
title: "1st mWT SDN Plugtests Event"
author:
org: European Telecommunications Standards Institute
date: January 2019
seriesinfo: ETSI Plugtests Test Plan V1.0 (2019-01)
target: https://portal.etsi.org/Portals/0/TBpages/CTI/Docs/mWT_Plugtest1_TestPlan_v1.0.pdf
ETSI_MW-TEST-2:
title: "2nd and 3rd mWT SDN Plugtests Event"
author:
org: European Telecommunications Standards Institute
date: November 2020
seriesinfo: ETSI Plugtests Test Plan V1.0 (2020-11)
target: https://portal.etsi.org/Portals/0/TBpages/CTI/Docs/mWT_Plugtests2-3_TestPlan_v1_0.pdf
ETSI_MW-PROFILE:
title: "millimetre Wave Transmission (mWT); Definition of a Wireless Transport Profile for Standard SDN Northbound Interfaces"
author:
org: European Telecommunications Standards Institute
date: March 2022
seriesinfo: ETSI GS mWT 024 V1.1.1 (2022-03)
target: https://www.etsi.org/deliver/etsi_gs/mWT/001_099/024/01.01.01_60/gs_mWT024v010101p.pdf

--- abstract

This document describes how profiles of the
Expand All @@ -65,13 +114,25 @@ irrespective of whether they are TE-centric or not.

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
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:
>
> 1. Policy
> 1. Path steering
> 1. 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.
Expand All @@ -97,7 +158,7 @@ However, the 'te' container in the context of {{!RFC8795}}, should be understood

# Examples of generic profiles {#examples}

## UNI Topology Discovery {#uni-discovery}
## Multi-domain Links Discovery {#uni-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:

Expand Down Expand Up @@ -288,7 +349,7 @@ Each access point can have different directionality with respect to the multipoi
- 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 {{mp-link-example}}) with only one incoming link (e.g., Link 3 in {{mp-link-example}});
- 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 {{mp-link-example}}) with only one outgoing link (e.g., Link 4 in {{mp-link-example}}).

~~~~ ascii-art
~~~~ aasvg
{::include ./figures/mp-link-example.txt}
~~~~
{:#mp-link-example title="Example of a pseudonode modelling a multipoint link"}
Expand All @@ -307,7 +368,7 @@ It is worth noting that the directionality of the access point of a multipoint l
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.

~~~~ ascii-art
~~~~ aasvg
{::include ./figures/p2mp-link-example.txt}
~~~~
{:#p2mp-link-example title="Example of a pseudonode modelling an undirectional point-to-multipoint link"}
Expand All @@ -326,7 +387,7 @@ For example, {{p2mp-link-example}} shows an example of a pseudonode representing
The first option is to define a technology-specific TE Topology Model
which augments the TE Topology Model, as shown in {{te-augment-fig}}:

~~~~
~~~~ aasvg
+-------------------+
| Network Topology |
+-------------------+
Expand Down Expand Up @@ -373,7 +434,7 @@ 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:

~~~~
~~~~ aasvg
+-----------------------+
| Network Topology |
+-----------------------+
Expand Down Expand Up @@ -403,7 +464,7 @@ a technology-specific Network Topology Model which augments the
Network Topology Model and to rely on the multiple inheritance
capability, as shown in {{double-augment-fig}}:

~~~~
~~~~ aasvg
+-----------------------+
| Network Topology |
+-----------------------+
Expand Down Expand Up @@ -528,9 +589,40 @@ 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.

# Implementation Status {#implementations}

Different profiles of the TE topology model, defined in {{!RFC8795}}, has been implemented and pubicly demonstrated.

## 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}}.

## 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
1. 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}}.

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.

# Open Issues {#open-issues}

## Implemented profiles {#implement}
## 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.

Expand All @@ -542,6 +634,14 @@ More investigation is instead required in case the TE topology profile is config
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.

It is worth noting that existing implementations of {{!RFC8795}}, including those reported in {{implementations}}, have described the implemented profiled by manually pruning the YANG tree generated fom the YANG module defined in {{!RFC8795}}.

The pruned/profiled YANG trees were sufficient to the implementers to generate proper APIs.

However, it is possible to use the YANG deviation statements to programmatically generate a pruned/profiled YANG tree.

> Some investigations are on-going to see whether it is sufficient to define YANG deviations to document the pruned/profiled YANG trees to be implemented for a specific application or whether other existing tools can be leveraged to generate proper APIs.

Note: that this issue is also tracked in github as issue #161.

# Security Considerations {#security}
Expand All @@ -564,6 +664,8 @@ This document requires no IANA actions.
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.
Loading