RFC 9731
A YANG Data Model for Virtual Network (VN) Operations
1. Introduction ✨
okay so bestie, this is the title block, and it's giving very important doc energy 💅. The RFC is RFC 9731, called "A YANG Data Model for Virtual Network (VN) Operations" 🎀. It's a Standards Track document from the IETF, published March 2025 🌸. The editors are Y. Lee (Samsung Electronics), D. Dhody (Huawei), D. Ceccarelli (Cisco), I. Bryskin (Individual), and B. Yoon (ETRI) 🫶. It doesn't obsolete or update any other RFCs. Iconic, honestly 👑.
Okay so the Abstract says a Virtual Network (VN) is a network a service provider gives a customer, to use however they want, as if it were a physical network 🦋. This doc gives a YANG data model that works for basically any way of running VNs, and it includes VN operations from the ACTN framework [RFC8453] 💖.
Status of This Memo
This is an Internet Standards Track document 🔥.
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 7841 ✨. For the current status, errata, and feedback, check https://www.rfc-editor.org/info/rfc9731 🧚.
Copyright Notice
Copyright (c) 2025 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. Please review those carefully, because they spell out your rights and restrictions. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Revised BSD License 🙈.
Table of Contents
- 1. Introduction
- 1.1. Terminology and Conventions
- 1.2. Tree Diagram
- 1.3. Prefixes in Data Node Names
- 2. Use Case of VN YANG Data Model in the ACTN Context
- 2.1. Type 1 VN
- 2.2. Type 2 VN
- 3. High-Level Control Flows with Examples
- 3.1. Type 1 VN Illustration
- 3.2. Type 2 VN Illustration
- 3.2.1. VN and AP Usage
- 4. VN YANG Data Model Usage
- 4.1. Customer View of VN
- 4.2. Auto-creation of VN by MDSC
- 4.3. Innovative Services
- 4.3.1. VN Compute
- 4.3.2. Multiple Sources and Multiple Destinations
- 4.4. Others
- 4.5. Summary
- 5. VN YANG Data Model (Tree Structure)
- 6. VN YANG Data Model
- 7. Security Considerations
- 8. IANA Considerations
- 9. References
- 9.1. Normative References
- 9.2. Informative References
- Appendix A. Performance Constraints
- Appendix B. JSON Example
- B.1. VN JSON
- B.2. TE Topology JSON
- Acknowledgments
- Contributors
- Authors' Addresses
1.1. Terminology and Conventions
This doc borrows the following abbreviations from [RFC8453] and/or [RFC8795] 🌈:
- VN: Virtual Network
- AP: Access Point
- VNAP: VN Access Point
- ACTN: Abstraction and Control of TE Networks
- CNC: Customer Network Controller
- MDSC: Multi-Domain Service Coordinator
- CMI: CNC-MDSC Interface
- LTP: Link Termination Point
It also borrows the terminology in Section 1.1 of [RFC7926], the term "Service Model" from [RFC8309], and the term "Connectivity Matrix" from [RFC8795] 🧚.
Some examples have long lines that may get folded, as described in [RFC8792] 💅.
1.2. Tree Diagram
The simplified graphical representation of the data model shows up in Section 5 🦋. What the symbols mean is defined in [RFC8340] ✨.
1.3. Prefixes in Data Node Names
Data node names and other model objects get prefixed with the standard prefix for their YANG module, as listed in Table 1 🎀.
+==========+=======================+===========+
| Prefix | YANG Module | Reference |
+==========+=======================+===========+
| vn | ietf-vn | RFC 9731 |
+----------+-----------------------+-----------+
| yang | ietf-yang-types | [RFC6991] |
+----------+-----------------------+-----------+
| nw | ietf-network | [RFC8345] |
+----------+-----------------------+-----------+
| nt | ietf-network-topology | [RFC8345] |
+----------+-----------------------+-----------+
| te-types | ietf-te-types | [RFC8776] |
+----------+-----------------------+-----------+
| tet | ietf-te-topology | [RFC8795] |
+----------+-----------------------+-----------+Table 1: Prefixes and Corresponding YANG Modules
2. Use Case of VN YANG Data Model in the ACTN Context 🌸
Here ACTN is used to show how the VN YANG data model is generally used. The model in this section sits in the following ACTN context 💖.
+-------+
| CNC |
+-------+
|
| VN + TE Topology
|
+-----------------------+
| MDSC |
+-----------------------+
Figure 1: ACTN CMIAs Figure 1 shows, both the ACTN VN and TE Topology YANG data models run over the CMI to set up a VN over TE networks 🫶.
Part 1 of 10 done! Keep going, bestie 💜 — Part 2 is coming up next 🚀
2.1. Type 1 VN ✨
Okay bestie, so as [RFC8453] explains, a VN is basically the customer's view of the TE network 💖 Let's recap the VN types from [RFC8453] real quick. A Type 1 VN is a set of edge-to-edge abstract links, and each one is called a VN member. Every VN member is built as an end-to-end tunnel across the underlying networks 🦋 Those tunnels can be made through recursive slicing or abstraction of paths in the underlying networks, and they can cover the customer's edge points, access links, intra-domain paths, and inter-domain links. Iconic, right? 🌈
Picture a VN with four VN members, like this:
VN member 1 L1-L4
VN member 2 L1-L7
VN member 3 L2-L4
VN member 4 L3-L8Figure 2: VN Members (Type 1 VN)
In that setup, L1, L2, L3, L4, L7, and L8 each correspond to a Customer Endpoint (or AP) 🎀
Now the glow-up: this VN can be modeled as one abstract node, like in Figure 3 💅
+----------------------------------------------+
| |
L1----|..............................................|------L4
| . . |
| . AN1 . |
| . . |
| ..................................*.....|------L7
| . |
L2-----|....................................... |
| |
L3-----|..............................................|------L8
| |
+----------------------------------------------+Figure 3: Abstract Node (Type 1 Topology)
Honestly, modeling a VN as one abstract node is the easiest way for customers to express their end-to-end connectivity, as Figure 3 shows 🧚
2.2. Type 2 VN 🌸
Some VN members let customers pick the path they want, so it's giving control 👑 To make that happen, you need a single node abstract topology plus an underlay topology. The underlay could be a native TE topology or an abstract TE topology 💜 The intended path gets set using the nodes and links of that underlay. Here's the lore: a Type 1 VN is a higher-level abstraction of a Type 2 VN. A Type 2 VN is a single node abstract topology sitting on top of the underlay, plus a way to specify intended paths ✨ These topologies can be agreed on between the CNC and the MDSC before the VN is created, or they can be made during VN instantiation.
If a Type 2 VN is wanted for some or all of the VN members of a Type 1 VN (see the example in Section 2.1), the TE Topology model can provide these abstract topologies: a single node topology AN1, plus an underlay topology with nodes S1 to S11 and their links 🦋
+----------------------------------------------+
| S1 S2 |
| O...............O |
| ......... ....... . |
| . . . |
|S3 . . S4 . S5 |
L1----|.O......................O.........O...........|------L4
| . . . |
| . . . |
| . S6 . S7 . S8 |
| O ................O.........O.......|------L7
| . . . . ..... |
|S9 . . .S10 . . |
L2-----|...O.....O.....................O..............|------L8
| . S11 |
L3-----|.. |
| AN1 |
+----------------------------------------------+Figure 4: Type 2 Topology
As Figure 4 shows, the abstract node is AN1, and the underlay topology is drawn with its nodes and links (S1 to S11) 🫶
Here's an example: if VN member 1 (L1-L4) wants to set its own path over the Type 2 topology, it can pick, say, the explicit path {S3,S4,S5}, based on the underlay topology and its service requirement. This is enacted by the customer through TE-topology configuration 💅
3. High-Level Control Flows with Examples ✨
3.1. Type 1 VN Illustration 🎀
If this VN is Type 1, the diagram below shows the message flow between the CNC and the MDSC to instantiate the VN using the VN and TE Topology YANG data models 🌈
+--------+ +--------+
| CNC | | MDSC |
+--------+ +--------+
| |
| |
CNC POST TE Topo | POST /nw:networks/nw:network/ |
model (w/ Conn. | nw:node/te-node-id/ |
Matrix on one | tet:connectivity-matrices/ |
abstract node) | tet:connectivity-matrix |
|-------------------------------->|
| HTTP 200 |
|<--------------------------------|
| |
CNC POST the | POST /virtual-network |
VN identifying |-------------------------------->| If there is
AP, VNAP, and VN | | multi-src/dest,
members and maps | | then MDSC
to the TE Topo | HTTP 200 | selects an
model |<--------------------------------| src or dest
| | and updates
| | VN YANG
CNC GET the | GET /virtual-network |
VN YANG status |-------------------------------->|
| |
| HTTP 200 (VN with status: |
| selected VN members |
| in case of multi-s/d) |
|<--------------------------------|
| |Figure 5: Type 1 VN Illustration
3.2. Type 2 VN Illustration 💜
For some VN members, the customer may want to "configure" an explicit path that connects its two endpoints. Let's look at this example 🦋
VN member 1 L1-L4 (via S3, S4, and S5)
VN member 2 L1-L7 (via S3, S4, S7, and S8)
VN member 3 L2-L7 (via S9, S10, and S11)
VN member 4 L3-L8 (via S9, S10, and S11)Figure 6: VN Members (Type 2 VN)
There are two options, depending on whether the CNC or the MDSC creates the single abstract node topology 🍓
Case 1:
If the CNC creates the single abstract node topology, the message flow between the CNC and the MDSC to instantiate this VN using a VN and TE Topology YANG data model looks like the diagram below 🌸
+--------+ +--------+
| CNC | | MDSC |
+--------+ +--------+
| |
| |
CNC POST TE Topo | POST /nw:networks/nw:network/ |
model (w/ Conn. | nw:node/te-node-id/tet:connectivity- |
Matrix on one | matrices/tet:connectivity-matrix |
abstract node and|---------------------------------------->|
explicit paths in| |
the Conn. Matrix)| HTTP 200 |
|<----------------------------------------|
| |
CNC POST the | POST /virtual-network |
VN identifying |---------------------------------------->|
AP, VNAP, and VN | |
members and maps | |
to the TE Topo | HTTP 200 |
model |<----------------------------------------|
| |
| |
CNC GET the | GET /virtual-network |
VN YANG status |---------------------------------------->|
| |
| HTTP 200 (VN with status) |
|<----------------------------------------|
| |Figure 7: Type 2 VN Illustration: Case 1
Case 2:
On the other hand, if the MDSC creates the single abstract node topology based on the VN YANG posted by the CNC, the diagram below shows the message flow between the CNC and the MDSC to instantiate this VN using VN and TE Topology YANG data models 🙈
+--------+ +--------+
| CNC | | MDSC |
+--------+ +--------+
| |
| |
CNC POST VN | |
identifying AP, | |
VNAP and VN | POST /virtual-network | MDSC populates
members |-------------------------------->| a single abst.
| HTTP 200 | node topology
|<--------------------------------| by itself
| |
CNC GET VN & | GET /virtual-network & |
POST TE Topo | POST /nw:networks/nw:network/ |
models (w/ | nw:node/te-node-id/tet: |
Conn. Matrix | connectivity-matrices/ |
on the | tet:connectivity-matrix |
abstract node |-------------------------------->|
and explicit | |
paths in the | |
Conn. Matrix) | |
| HTTP 200 |
|<--------------------------------|
| |
| |
CNC GET the | GET /virtual-network |
VN YANG status |-------------------------------->|
| |
| HTTP 200 (VN with status) |
|<--------------------------------|
| |Figure 8: Type 2 VN Illustration: Case 2
Quick heads-up 🚨 The underlay topology (the one the single abstract node topology refers to) could be a Native/White topology, or a Grey topology ([RFC8453]) that's been further customized for the customer's requirements and configured at the MDSC 💖
Appendix B has JSON examples for both the VN model and the TE Topology Connectivity Matrix sub-model, showing how the CNC can create a VN using the VN model along with the TE Topology Connectivity Matrix module ✨
3.2.1. VN and AP Usage 🎀
Okay so the customer access info might already be known when the VN gets created 🌸 A shared logical AP identifier is used between the customer and the operator to identify the access link between Customer Edge (CE) and Provider Edge (PE). This is described in Section 6 of [RFC8453] ✨
But ngl, sometimes the customer access isn't known at the initial VN creation 😭 So the VN operation lets you create a VN with only a PE identifier, and the customer access info can get added later 🦋
To make that work, the 'ap' container has a leaf for the 'pe' node, so the AP can be created with PE information 💅 The VN member (and VN) could use APs that initially only have PE information. Literally so flexible 🫶
4. VN YANG Data Model Usage 💖
4.1. Customer View of VN 👑
The VN YANG data model lets you define a customer view, so the customer can communicate using the VN constructs as described in [RFC8454] 🧚 It groups edge-to-edge links (i.e., VN members) under one umbrella of VN. The customer can instantiate and view the VN as one entity, which makes life easier for some customers who don't want to deal with the details of the provider-based YANG data models 🌈
This is kinda like the benefits of a separate YANG data model for customer services described in [RFC8309]. That one states that service models don't make any assumptions about how a service is actually engineered and delivered for a customer. Main character energy 💜
4.2. Auto-creation of VN by MDSC 🦋
The VN could be configured at the MDSC explicitly by the CNC using the VN YANG data model. In other cases, the VN isn't explicitly configured and is instead created automatically by the MDSC based on the customer service model and local policy 🍓 Even then, the CNC can use the VN YANG data model to learn details of the underlying VN that was created to meet the requirements of the customer service model 🫶
4.3. Innovative Services ✨
4.3.1. VN Compute 🔥
The VN model supports VN compute (pre-instantiation mode), so you can view the full VN as a single entity before it's instantiated 👀 Doing this through path computation or "compute-only" tunnel setup ([YANG-TE]) does not give you the same functionality, sorry not sorry 💅
+--------+ +--------+
| CNC | | MDSC |
+--------+ +--------+
| |
| |
CNC POST TE Topo | POST /nw:networks/nw:network/ |
model (w/ Conn. | nw:node/te-node-id/tet:connectivity- |
Matrix on one | matrices/tet:connectivity-matrix |
abstract node and|---------------------------------------->|
constraints in | |
the conn. matrix)| HTTP 200 |
|<----------------------------------------|
| |
| |
CNC calls RPC to | RPC /vn compute |
compute the VN |---------------------------------------->|
as per the | |
referred TE-Topo | |
| |
| HTTP 200 (Computed VN) |
|<----------------------------------------|
| |Figure 9: VN Compute with Reference to TE Topology YANG Data Model
The VN compute RPC allows the optional inclusion of constraints and optimization criteria at the VN level as well as at the individual VN-member level 🎯 So the RPC can be used on its own to get the computed VN result, without creating an abstract topology first 🙌
+--------+ +--------+
| CNC | | MDSC |
+--------+ +--------+
| |
| |
CNC calls RPC to | RPC /vn compute |
compute the VN |---------------------------------------->|
as per the | |
constraints and | |
VN members | |
| HTTP 200 (Computed VN) |
|<----------------------------------------|
| |Figure 10: VN Compute
Whether or not the TE Topology model is referenced, the RPC output includes a reference to the single node abstract topology. Each VN member also includes a reference to the connectivity-matrix-id where the path properties can be found 🗺️
To make this happen, the VN compute RPC reuses these common groupings:
te-types:generic-path-constraints: is used optionally in the RPC input at the VN level and/or VN-member level. The VN-member level overrides the VN-level data, including any constraints in the referenced abstract node in the TE topology.te-types:generic-path-optimization: is used optionally in the RPC input at the VN level and/or VN-member level. The VN-member level overrides the VN-level data, including any optimization in the referenced abstract node in the TE topology.vn member: identifies the VN member in both RPC input and output.vn-policy: is used optionally in the RPC input to apply any VN-level policies.
When the MDSC receives this RPC, it computes the VN based on the input provided in the RPC. This computation doesn't create a VN or reserve any resources in the system. It just computes the resulting VN based on information at the MDSC or in coordination with the CNC 🥰 A single node abstract topology conveys the result of each VN member as a reference to the connectivity-matrix-id. If something goes wrong, the error information is included 🫶
rpcs:
+---x vn-compute
+---w input
| +---w te-topology-identifier
| | +---w provider-id? te-global-id
| | +---w client-id? te-global-id
| | +---w topology-id? te-topology-id
| +---w abstract-node?
| | -> /nw:networks/network/node/tet:te-node-id
| +---w path-constraints
| | +---w te-bandwidth
| | | +---w (technology)?
| | | ...
| | +---w link-protection? identityref
| | +---w setup-priority? uint8
| | +---w hold-priority? uint8
| | +---w signaling-type? identityref
| | +---w path-metric-bounds
| | | +---w path-metric-bound* [metric-type]
| | | ...
| | +---w path-affinities-values
| | | +---w path-affinities-value* [usage]
| | | ...
| | +---w path-affinity-names
| | | +---w path-affinity-name* [usage]
| | | ...
| | +---w path-srlgs-lists
| | | +---w path-srlgs-list* [usage]
| | | ...
| | +---w path-srlgs-names
| | | +---w path-srlgs-name* [usage]
| | | ...
| | +---w disjointness? te-path-disjointness
| +---w cos? te-types:te-ds-class
| +---w optimizations
| | +---w (algorithm)?
| | +--:(metric) {path-optimization-metric}?
| | | ...
| | +--:(objective-function)
| | {path-optimization-objective-function}?
| | ...
| +---w vn-member-list* [id]
| | +---w id vnm-id
| | +---w src
| | | +---w ap? -> /access-point/ap/id
| | | +---w vn-ap-id?
| | | | -> /access-point/ap[id=current()/../ap]/vn-ap/\
id
| | | +---w multi-src? boolean {multi-src-dest}?
| | +---w dest
| | | +---w ap? -> /access-point/ap/id
| | | +---w vn-ap-id?
| | | | -> /access-point/ap[id=current()/../ap]/vn-ap/\
id
| | | +---w multi-dest? boolean {multi-src-dest}?
| | +---w connectivity-matrix-id? leafref
| | +---w underlay
| | +---w path-constraints
| | | +---w te-bandwidth
| | | | ...
| | | +---w link-protection? identityref
| | | +---w setup-priority? uint8
| | | +---w hold-priority? uint8
| | | +---w signaling-type? identityref
| | | +---w path-metric-bounds
| | | | ...
| | | +---w path-affinities-values
| | | | ...
| | | +---w path-affinity-names
| | | | ...
| | | +---w path-srlgs-lists
| | | | ...
| | | +---w path-srlgs-names
| | | | ...
| | | +---w disjointness? te-path-disjointness
| | +---w cos? te-types:te-ds-class
| | +---w optimizations
| | +---w (algorithm)?
| | ...
| +---w vn-level-diversity? te-types:te-path-\
disjointness
+--ro output
+--ro te-topology-identifier
| +--ro provider-id? te-global-id
| +--ro client-id? te-global-id
| +--ro topology-id? te-topology-id
+--ro abstract-node?
| -> /nw:networks/network/node/tet:te-node-id
+--ro vn-member-list* [id]
+--ro id vnm-id
+--ro src
| +--ro ap? -> /access-point/ap/id
| +--ro vn-ap-id?
| | -> /access-point/ap[id=current()/../ap]/vn-ap/\
id
| +--ro multi-src? boolean {multi-src-dest}?
+--ro dest
| +--ro ap? -> /access-point/ap/id
| +--ro vn-ap-id?
| | -> /access-point/ap[id=current()/../ap]/vn-ap/\
id
| +--ro multi-dest? boolean {multi-src-dest}?
+--ro connectivity-matrix-id? leafref
+--ro underlay
+--ro if-selected? boolean {multi-src-dest}?
+--ro compute-status? vn-compute-status
+--ro error-info
+--ro error-description? string
+--ro error-timestamp? yang:date-and-time
+--ro error-reason? identityref4.3.2. Multiple Sources and Multiple Destinations ✨
Okay so, when you're setting up a VN, the customer might not have the full list of sources or destinations locked in yet 🫶. For one source there could be a whole list of possible destinations, and the best one gets picked based on what the network resources look like at that moment. It works the other way too: for one destination there could be several sources, and the optimal one gets chosen. Sometimes it's even a whole pool of sources and destinations, and the best source-destination pair comes out of that pool 💅. Here's the YANG tree showing how to model multiple sources and multiple destinations 🦋.
module: ietf-vn
+--rw virtual-network
+--rw vn* [id]
+--rw id vn-id
+--rw te-topology-identifier
| +--rw provider-id? te-global-id
| +--rw client-id? te-global-id
| +--rw topology-id? te-topology-id
+--rw abstract-node?
| -> /nw:networks/network/node/tet:te-node-id
+--rw vn-member* [id]
| +--rw id vnm-id
| +--rw src
| | +--rw ap? -> /access-point/ap/id
| | +--rw vn-ap-id?
| | | -> /access-point/ap[id=current()/../ap]/vn-ap/\
id
| | +--rw multi-src? boolean {multi-src-dest}?
| +--rw dest
| | +--rw ap? -> /access-point/ap/id
| | +--rw vn-ap-id?
| | | -> /access-point/ap[id=current()/../ap]/vn-ap/\
id
| | +--rw multi-dest? boolean {multi-src-dest}?
| +--rw connectivity-matrix-id? leafref
| +--rw underlay
| +--ro oper-status? te-types:te-oper-status
| +--ro if-selected? boolean {multi-src-dest}?
+--rw admin-status? te-types:te-admin-status
+--ro oper-status? te-types:te-oper-status
+--rw vn-level-diversity? te-types:te-path-disjointness4.4. Others 🌈
Bestie, the VN YANG data model can be augmented pretty easily to map VNs onto services like L3SM and L2SM, as described in [TE-SERVICE-MAPPING] 🎀. It can also be extended to support telemetry, performance monitoring, and network autonomics, as described in [TEAS-ACTN-PM] 📈.
Now, the VN YANG data model is tightly coupled with the TE Topology model [RFC8795] 🔗. So any underlay technology the TE Topology model in [RFC8795] doesn't support is also not supported by the VN model 🙈. Lowkey, though, the VN model does include an empty container called "underlay" that can be augmented. For example, Segment Routing (SR) Policy [RFC9256] information can be augmented for the SR underlay by a future model 🧚.
Apart from te-types:generic-path-constraints and te-types:generic-path-optimization, there's an extra leaf called cos for the class of service. It represents the Class-Type of traffic [RFC4124] and can be used as one of the path constraints 💜.
4.5. Summary 💖
Here's the recap of everything the VN YANG data model can do ✨.
- Maintenance of APs and VNAPs along with the VN
- VN construct to group of edge-to-edge links
- Ability to support various VN and VNS types
- VN Type 1: Customer configures the VN as a set of VN members. No other details need to be set by the customer, making for a simplified operation for the customer.
- VN Type 2: Along with VN members, the customer could also provide an abstract topology, and this topology is provided by the Abstract TE Topology YANG data model.
- Note that the VN type is not explicitly identified in the VN YANG data model, as the VN YANG data model is exactly the same for both VN Type 1 and VN Type 2. The VN type can be implicitly known based on the referenced TE topology and whether the connectivity matrix includes the underlay path (Type 2) or not (Type 1).
- VN Compute (pre-instantiate)
- Multi-Source / Multi-Destination
5. VN YANG Data Model (Tree Structure) 🌸
module: ietf-vn
+--rw access-point
| +--rw ap* [id]
| +--rw id ap-id
| +--rw pe?
| | -> /nw:networks/network/node/tet:te-node-id
| +--rw max-bandwidth? te-types:te-bandwidth
| +--rw avl-bandwidth? te-types:te-bandwidth
| +--rw vn-ap* [id]
| +--rw id ap-id
| +--rw vn? -> /virtual-network/vn/id
| +--rw abstract-node? -> /nw:networks/network/node/\
node-id
| +--rw ltp? leafref
| +--ro max-bandwidth? te-types:te-bandwidth
+--rw virtual-network
+--rw vn* [id]
+--rw id vn-id
+--rw te-topology-identifier
| +--rw provider-id? te-global-id
| +--rw client-id? te-global-id
| +--rw topology-id? te-topology-id
+--rw abstract-node?
| -> /nw:networks/network/node/tet:te-node-id
+--rw vn-member* [id]
| +--rw id vnm-id
| +--rw src
| | +--rw ap? -> /access-point/ap/id
| | +--rw vn-ap-id?
| | | -> /access-point/ap[id=current()/../ap]/\
vn-ap/id
| | +--rw multi-src? boolean {multi-src-dest}?
| +--rw dest
| | +--rw ap? -> /access-point/ap/id
| | +--rw vn-ap-id?
| | | -> /access-point/ap[id=current()/../ap]/\
vn-ap/id
| | +--rw multi-dest? boolean {multi-src-dest}?
| +--rw connectivity-matrix-id? leafref
| +--rw underlay
| +--ro oper-status? te-types:te-oper-status
| +--ro if-selected? boolean {multi-src-dest}?
+--rw admin-status? te-types:te-admin-status
+--ro oper-status? te-types:te-oper-status
+--rw vn-level-diversity? te-types:te-path-disjointness
rpcs:
+---x vn-compute
+---w input
| +---w te-topology-identifier
| | +---w provider-id? te-global-id
| | +---w client-id? te-global-id
| | +---w topology-id? te-topology-id
| +---w abstract-node?
| | -> /nw:networks/network/node/tet:te-node-id
| +---w path-constraints
| | +---w te-bandwidth
| | | +---w (technology)?
| | | ...
| | +---w link-protection? identityref
| | +---w setup-priority? uint8
| | +---w hold-priority? uint8
| | +---w signaling-type? identityref
| | +---w path-metric-bounds
| | | +---w path-metric-bound* [metric-type]
| | | ...
| | +---w path-affinities-values
| | | +---w path-affinities-value* [usage]
| | | ...
| | +---w path-affinity-names
| | | +---w path-affinity-name* [usage]
| | | ...
| | +---w path-srlgs-lists
| | | +---w path-srlgs-list* [usage]
| | | ...
| | +---w path-srlgs-names
| | | +---w path-srlgs-name* [usage]
| | | ...
| | +---w disjointness? te-path-disjointness
| +---w cos? te-types:te-ds-class
| +---w optimizations
| | +---w (algorithm)?
| | +--:(metric) {path-optimization-metric}?
| | | ...
| | +--:(objective-function)
| | {path-optimization-objective-function}?
| | ...
| +---w vn-member-list* [id]
| | +---w id vnm-id
| | +---w src
| | | +---w ap? -> /access-point/ap/id
| | | +---w vn-ap-id?
| | | | -> /access-point/ap[id=current()/../ap]/\
vn-ap/id
| | | +---w multi-src? boolean {multi-src-dest}?
| | +---w dest
| | | +---w ap? -> /access-point/ap/id
| | | +---w vn-ap-id?
| | | | -> /access-point/ap[id=current()/../ap]/\
vn-ap/id
| | | +---w multi-dest? boolean {multi-src-dest}?
| | +---w connectivity-matrix-id? leafref
| | +---w underlay
| | +---w path-constraints
| | | +---w te-bandwidth
| | | | ...
| | | +---w link-protection? identityref
| | | +---w setup-priority? uint8
| | | +---w hold-priority? uint8
| | | +---w signaling-type? identityref
| | | +---w path-metric-bounds
| | | | ...
| | | +---w path-affinities-values
| | | | ...
| | | +---w path-affinity-names
| | | | ...
| | | +---w path-srlgs-lists
| | | | ...
| | | +---w path-srlgs-names
| | | | ...
| | | +---w disjointness? te-path-disjointness
| | +---w cos? te-types:te-ds-class
| | +---w optimizations
| | +---w (algorithm)?
| | ...
| +---w vn-level-diversity? te-types:te-path-\
disjointness
+--ro output
+--ro te-topology-identifier
| +--ro provider-id? te-global-id
| +--ro client-id? te-global-id
| +--ro topology-id? te-topology-id
+--ro abstract-node?
| -> /nw:networks/network/node/tet:te-node-id
+--ro vn-member-list* [id]
+--ro id vnm-id
+--ro src
| +--ro ap? -> /access-point/ap/id
| +--ro vn-ap-id?
| | -> /access-point/ap[id=current()/../ap]/\
vn-ap/id
| +--ro multi-src? boolean {multi-src-dest}?
+--ro dest
| +--ro ap? -> /access-point/ap/id
| +--ro vn-ap-id?
| | -> /access-point/ap[id=current()/../ap]/\
vn-ap/id
| +--ro multi-dest? boolean {multi-src-dest}?
+--ro connectivity-matrix-id? leafref
+--ro underlay
+--ro if-selected? boolean {multi-src-\
dest}?
+--ro compute-status? vn-compute-status
+--ro error-info
+--ro error-description? string
+--ro error-timestamp? yang:date-and-time
+--ro error-reason? identityref6. VN YANG Data Model 🎀
Here's the actual YANG module, the whole thing 🧚.
<CODE BEGINS> file "ietf-vn@2025-03-27.yang"
module ietf-vn {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-vn";
prefix vn;
/* Import common YANG types */
import ietf-yang-types {
prefix yang;
reference
"RFC 6991: Common YANG Data Types";
}
/* Import network */
import ietf-network {
prefix nw;
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
/* Import network topology */
import ietf-network-topology {
prefix nt;
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
/* Import TE Common types */okay so the YANG module kicks off by pulling in the TE types and TE topology modules, bestie 🦋 these are the building blocks everything else leans on ✨
import ietf-te-types {
prefix te-types;
reference
"RFC 8776: Common YANG Data Types for Traffic Engineering";
}
/* Import TE Topology */
import ietf-te-topology {
prefix tet;
reference
"RFC 8795: YANG Data Model for Traffic Engineering (TE)
Topologies";
}
organization
"IETF Traffic Engineering Architecture and Signaling (TEAS)
Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/teas/>
WG List: <mailto:teas@ietf.org>
Editor: Young Lee <younglee.tx@gmail.com>
Editor: Dhruv Dhody <dhruv.ietf@gmail.com>";
description
"This YANG module for the Virtual Network (VN).
It describes a VN operation module that can take place
in the context of the Customer Network Controller (CNC) -
Multi-Domain Service Coordinator (MDSC) interface (CMI) of
the Abstraction and Control of TE Networks (ACTN)
architecture where the CNC is the actor of a VN
instantiation/modification/deletion as per RFC 8453.
Copyright (c) 2025 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 9731; see the
RFC itself for full legal notices.";
revision 2025-03-27 {
description
"The initial version.";
reference
"RFC 9731: A YANG Data Model for Virtual Network (VN)
Operations";
}
/* Features */
feature multi-src-dest {
description
"Support for selection of one source or destination
among multiple.";
reference
"RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN)";
}
/* Typedef */
typedef vn-id {
type string {
length "1..max";
}
description
"A type definition for a VN identifier.";
}
typedef ap-id {
type string {
length "1..max";
}
description
"A type definition for an Access Point (AP) identifier.";
}
typedef vnm-id {
type string {
length "1..max";
}
description
"A type definition for a VN-member identifier.";
}
typedef vn-compute-status {
type te-types:te-common-status;
description
"A type definition for representing the VN compute status.
Note that all statuses apart from up and down are considered
to be unknown.";
}
/* identities */
identity vn-computation-error-reason {
description
"Base identity for VN computation error reasons.";
}
identity vn-computation-error-not-ready {
base vn-computation-error-reason;
description
"VN computation has failed because the MDSC is not
ready.";
}
identity vn-computation-error-no-cnc {
base vn-computation-error-reason;
description
"VN computation has failed because one or more dependent
CNCs are unavailable.";
}
identity vn-computation-error-no-resource {
base vn-computation-error-reason;
description
"VN computation has failed because there is no
available resource in one or more domains.";
}
identity vn-computation-error-path-not-found {
base vn-computation-error-reason;
description
"VN computation failed as no path found.";
}
identity vn-computation-ap-unknown {
base vn-computation-error-reason;
description
"VN computation failed as the source or destination Access
Point (AP) not known.";
}
/* Groupings */
grouping vn-member {
description
"The vn-member is described by this grouping.";
leaf id {
type vnm-id;
description
"A vn-member identifier.";
}
container src {
description
"The source of VN member.";
leaf ap {
type leafref {
path "/access-point/ap/id";
}
description
"A reference to the source AP.";
}
leaf vn-ap-id {
type leafref {
path "/access-point/ap[id=current()/../ap]/vn-ap"
+ "/id";
}
description
"A reference to the source VNAP.";
}
leaf multi-src {
if-feature "multi-src-dest";
type boolean;
default "false";
description
"Is the source part of a multi-source, where
only one of the sources is enabled?";
}
}
container dest {
description
"The destination of the VN member.";
leaf ap {
type leafref {
path "/access-point/ap/id";
}
description
"A reference to the destination AP.";
}
leaf vn-ap-id {
type leafref {
path "/access-point/ap[id=current()/../ap]/"
+ "vn-ap/id";
}
description
"A reference to the destination VNAP.";
}
leaf multi-dest {
if-feature "multi-src-dest";
type boolean;
default "false";
description
"Is the destination part of a multi-destination,
where only one of the destinations is enabled.";
}
}
leaf connectivity-matrix-id {
type leafref {
path "/nw:networks/nw:network/nw:node/tet:te/"
+ "tet:te-node-attributes/"
+ "tet:connectivity-matrices/"
+ "tet:connectivity-matrix/tet:id";
}
description
"A reference to the connectivity-matrix.";
reference
"RFC 8795: YANG Data Model for Traffic Engineering (TE)
Topologies";
}
container underlay {
description
"An empty container that can be augmented with underlay
technology information not supported by RFC 8795 (for
example, Segment Routing (SR).";
}
reference
"RFC 8454: Information Model for Abstraction and Control of TE
Networks (ACTN)
RFC 8795: YANG Data Model for Traffic Engineering (TE)
Topologies";
}
grouping vn-policy {
description
"policy for VN-level diversity";
leaf vn-level-diversity {
type te-types:te-path-disjointness;
description
"The type of disjointness on the VN level (i.e., across all
VN members).";
}
}
/* Configuration data nodes */
container access-point {
description
"AP configurations.";
list ap {
key "id";
description
"The access-point identifier.";
leaf id {
type ap-id;
description
"An AP identifier unique within the scope of the entity
that controls the VN.";
}
leaf pe {
type leafref {
path "/nw:networks/nw:network/nw:node/tet:te-node-id";
}
description
"A reference to the PE node in the native TE Topology.";
}
leaf max-bandwidth {
type te-types:te-bandwidth;
description
"The max bandwidth of the AP.";
}
leaf avl-bandwidth {
type te-types:te-bandwidth;
description
"The available bandwidth of the AP.";
}
list vn-ap {
key "id";
leaf id {
type ap-id;
description
"A unique identifier for the VNAP.";
}
leaf vn {
type leafref {
path "/virtual-network/vn/id";
}
description
"A reference to the VN.";
}
leaf abstract-node {
type leafref {
path "/nw:networks/nw:network/nw:node/nw:node-id";
}
must '/nw:networks/nw:network/nw:node[nw:node-id='
+ 'current()/../abstract-node]/tet:te-node-id' {
description
"The associated network for the abstract-node
must be TE enabled.";
}
description
"A reference to the abstract node that represents
the VN.";
}
leaf ltp {
type leafref {
path "/nw:networks/nw:network/nw:node[nw:node-id="
+ "current()/../abstract-node]/nt:termination-point/"
+ "tet:te-tp-id";
}
description
"A reference to the Link Termination Point (LTP)
in the abstract-node, i.e., the LTP should be in
the abstract layer and not the underlying layer.";
reference
"RFC 8795: YANG Data Model for Traffic Engineering (TE)
Topologies";
}
leaf max-bandwidth {
type te-types:te-bandwidth;
config false;
description
"The max bandwidth of the VNAP.";
}
description
"List of VNAPs in this AP.";
}
}
reference
"RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN), Section 6";
}
container virtual-network {
description
"VN configurations.";
list vn {
key "id";
description
"A VN is identified by a vn-id.";
leaf id {
type vn-id;
description
"An identifier unique within the scope of the entity
that controls the VN.";
}
uses te-types:te-topology-identifier;
leaf abstract-node {
type leafref {
path "/nw:networks/nw:network/nw:node/tet:te-node-id";
}
description
"A reference to the abstract node in TE Topology.";
}
list vn-member {
key "id";
description
"List of vn-members in a VN.";
uses vn-member;
leaf oper-status {
type te-types:te-oper-status;
config false;
description
"The vn-member operational state.";
}
leaf if-selected {
if-feature "multi-src-dest";
type boolean;
default "false";
config false;
description
"Is the vn-member selected among the multi-source
or multi-destination options?";
}
}
leaf admin-status {
type te-types:te-admin-status;
default "up";
description
"VN administrative state.";
}
leaf oper-status {
type te-types:te-oper-status;
config false;
description
"VN operational state.";
}
uses vn-policy;
}
reference
"RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN)";
}
/* RPC */ rpc vn-compute {
description
"The VN computation without actual instantiation. This is
used by the CNC to get the VN results without actually
creating it in the network.
The input could include a reference to the single node
abstract topology. It could optionally also include
constraints and optimization criteria. The computation
is done based on the list of VN members.
The output includes a reference to the single node
abstract topology with each VN member including a
reference to the connectivity-matrix-id where the
path properties could be found. Error information is
also included.";
input {
uses te-types:te-topology-identifier;
leaf abstract-node {
type leafref {
path "/nw:networks/nw:network/nw:node/tet:te-node-id";
}
description
"A reference to the abstract node in TE Topology.";
}
uses te-types:generic-path-constraints;
leaf cos {
type te-types:te-ds-class;
description
"The class of service (COS).";
}
uses te-types:generic-path-optimization;
list vn-member-list {
key "id";
description
"List of VN members in a VN.";
uses vn-member;
uses te-types:generic-path-constraints;
leaf cos {
type te-types:te-ds-class;
description
"The class of service.";
reference
"RFC 4124: Protocol Extensions for Support of
Diffserv-aware MPLS Traffic Engineering,
Section 4.3.1";
}
uses te-types:generic-path-optimization;
}
uses vn-policy;
}
output {
uses te-types:te-topology-identifier;
leaf abstract-node {
type leafref {
path "/nw:networks/nw:network/nw:node/tet:te-node-id";
}
description
"A reference to the abstract node in TE Topology.";
}
list vn-member-list {
key "id";
description
"List of VN members in a VN.";
uses vn-member;
leaf if-selected {
if-feature "multi-src-dest";
type boolean;
default "false";
description
"Is the vn-member selected among the multi-source or
multi-destination options?";
reference
"RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN), Section 7";
}
leaf compute-status {
type vn-compute-status;
description
"The VN-member compute state.";
}
container error-info {
description
"Error information related to the VN member.";
leaf error-description {
type string {
length "1..max";
}
description
"Textual representation of the error that occurred
during VN compute.";
}
leaf error-timestamp {
type yang:date-and-time;
description
"Timestamp of the attempt.";
}
leaf error-reason {
type identityref {
base vn-computation-error-reason;
}
description
"Reason for the VN computation error.";
}
}
}
}
}
}
<CODE ENDS>7. Security Considerations 🔒💖
okay bestie, this is the part where we get VERY serious about keeping our YANG data safe 🫶 the module is built to be poked at by network management protocols like NETCONF [RFC6241] or RESTCONF [RFC8040]. the lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. the lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446].
the Network Configuration Access Control Model (NACM) [RFC8341] is giving bodyguard energy 💅 it lets you restrict particular NETCONF or RESTCONF users to a preconfigured subset of all the available protocol operations and content. ✨
this model sits in the interface between the CNC and MDSC, which is called the CNC-MDSC Interface (CMI). security risks are very real here, like malicious attacks and rogue elements trying to connect to the various ACTN components 😭. some ACTN components (e.g., MDSC) are a single point of failure and a threat vector, so be careful. there's also a need to manage policy conflicts and to stop eavesdropping on communication between different ACTN components. 🙈
there are a bunch of data nodes defined in this YANG module that are writable, creatable, and deletable (i.e., "config true", which is the default). these may be sensitive or vulnerable in some network environments. write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. here are the subtrees and data nodes, and how sensitive or vulnerable they are:
- ap: this list holds sensitive data that influences how the APs in the VN service are attached. if someone accesses these data nodes, they may be able to manipulate the VN. 💀
- id
- pe
- max-bandwidth
- avl-bandwidth
- vn-ap: this list holds sensitive data that influences how the VN service is delivered. if someone accesses these data nodes, they may be able to manipulate the VN. 😭
- id
- vn
- abstract-node
- ltp
- max-bandwidth
- vn: this list holds sensitive data that influences how the VN service is delivered. if someone accesses these data nodes, they may be able to manipulate the VN. 🍓
- id
- te-topology-identifier
- abstract-node
- vn-member: this list holds sensitive data that influences how the VN member in the VN service is delivered. if someone accesses these data nodes, they may be able to manipulate the VN member. 🦋
- id
- src/ap
- src/vn-ap-id
- dest/ap
- dest/vn-ap-id
- connectivity-matrix-id
some of the readable data nodes in this YANG module may be sensitive or vulnerable in some network environments too, so it's super important to control read access (e.g., via get, get-config, or notification) to them. here are the subtrees and data nodes and their sensitivity/vulnerability:
- oper-status: this leaf can reveal the current operational state of the VN. 👀
- if-selected: this leaf can reveal which vn-member is selected among the various multi-source / multi-destination options. 🧚
some of the RPC operations in this YANG module may be sensitive or vulnerable too, so it's important to control access to these operations. here they are and how sensitive or vulnerable they are:
- vn-compute: this RPC triggers the VN computation at the MDSC, which can reveal the VN information. 🌈
8. IANA Considerations 🌸
okay so IANA has made the following allocation for a URI in the "ns" registry within the "IETF XML Registry" registry group [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-vn
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.and IANA has also made the following allocation for the VN YANG data model (see Section 5 in the "YANG Module Names" registry [RFC6020]):
name: ietf-vn
namespace: urn:ietf:params:xml:ns:yang:ietf-vn
prefix: vn
reference: RFC 97319. References 📚
9.1. Normative References 💜
- [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.
- [RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, DOI 10.17487/RFC4124, June 2005, <https://www.rfc-editor.org/info/rfc4124>.
- [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.
- [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.
- [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>.
- [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.
- [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.
- [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.
- [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.
- [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>.
- [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, <https://www.rfc-editor.org/info/rfc8342>.
- [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/info/rfc8345>.
- [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
- [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, "Common YANG Data Types for Traffic Engineering", RFC 8776, DOI 10.17487/RFC8776, June 2020, <https://www.rfc-editor.org/info/rfc8776>.
- [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/info/rfc8795>.
9.2. Informative References 📚
okay so these are the informative refs, aka the extra reading list 🧚 nothing here is required to implement the thing, but they're the receipts behind the whole vibe.
- [L1CSM-YANG] Lee, Y., Lee, K., Zheng, H., Gonzalez de Dios, O., and D. Ceccarelli, "A YANG Data Model for L1 Connectivity Service Model (L1CSM)", Work in Progress, Internet-Draft, draft-ietf-ccamp-l1csm-yang-26, 11 April 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-l1csm-yang-26>. - [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., Ceccarelli, D., and X. Zhang, "Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks", BCP 206, RFC 7926, DOI 10.17487/RFC7926, July 2016,
<https://www.rfc-editor.org/info/rfc7926>. - [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data Model for L3VPN Service Delivery", RFC 8299, DOI 10.17487/RFC8299, January 2018,
<https://www.rfc-editor.org/info/rfc8299>. - [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
<https://www.rfc-editor.org/info/rfc8309>. - [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, August 2018,
<https://www.rfc-editor.org/info/rfc8453>. - [RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. Yoon, "Information Model for Abstraction and Control of TE Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454, September 2018,
<https://www.rfc-editor.org/info/rfc8454>. - [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2018,
<https://www.rfc-editor.org/info/rfc8466>. - [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, "Handling Long Lines in Content of Internet-Drafts and RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/info/rfc8792>. - [RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>. - [TE-SERVICE-MAPPING] Lee, Y., Dhody, D., Fioccola, G., Wu, Q., Ceccarelli, D., and J. Tantsura, "Traffic Engineering (TE) and Service Mapping YANG Data Model", Work in Progress, Internet-Draft, draft-ietf-teas-te-service-mapping-yang-17, 29 January 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-te-service-mapping-yang-17>. - [TEAS-ACTN-PM] Lee, Y., Dhody, D., Vilalta, R., King, D., and D. Ceccarelli, "YANG models for Virtual Network (VN)/TE Performance Monitoring Telemetry and Scaling Intent Autonomics", Work in Progress, Internet-Draft, draft-ietf-teas-actn-pm-telemetry-autonomics-14, 19 October 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-pm-telemetry-autonomics-14>. - [YANG-TE] Saad, T., Gandhi, R., Liu, X., Beeram, V. P., and I. Bryskin, "A YANG Data Model for Traffic Engineering Tunnels, Label Switched Paths and Interfaces", Work in Progress, Internet-Draft, draft-ietf-teas-yang-te-37, 9 October 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-te-37>.
Appendix A. Performance Constraints 💜
okay bestie, let's talk about the performance stuff 🫶 whenever a VN gets created, it's totally natural to attach the VN-level constraints and optimization criteria right then and there ✨ worth noting that the VN YANG data model in this document leans on the TE Topology model in [RFC8795]. It does this by pointing at an abstract node to hold those VN-level constraints and optimization criteria 🍓 Then the connectivity-matrix structure is what actually assigns the constraints and optimization criteria, things like delay, jitter, and so on. [RFC8776] already defines some of the metric-types, and future documents are meant to augment that list 🌸
Also, the VN compute lets you put the constraints and the optimization criteria straight into the RPC, so it can be used on its own, no extra setup needed 💅
Appendix B. JSON Example 🎀
B.1. VN JSON 💖
Okay so this bit is the good stuff! It shows how the VN YANG data model and the TE Topology YANG data model team up to actually instantiate a VN. Let's go 🦋
The example here includes these VNs:
- VN1 (Type 1) 🌸: This one maps to the single node topology abstract1. It has VN members 104 (L1 to L4), 107 (L1 to L7), 204 (L2 to L4), 308 (L3 to L8), and 108 (L1 to L8). Iconic.
- VN2 (Type 2) 🍓: This one maps to the single node topology abstract2, which has an underlay topology called underlay. VN2 has a single VN member, 105 (L1 to L5), and an underlay path (S4 and S7) is set in the connectivity matrix of the abstract2 topology. Underlay path, let's gooo 🛤️
- VN3 (Type 1) 👑: This VN has the multi-source and multi-destination feature turned on! VN members 106 (L1 to L6) and 107 (L1 to L7) show off the multi-dest side, and VN members 108 (L1 to L8) and 308 (L3 to L8) show off the multi-src side. Which member is selected is shown by the field "if-selected" and the matching connectivity-matrix-id. Main character energy 💅
Here's the diagram, bestie:
L1---104---L4 L1---105---L5 L1---106---L6(md)
L1---107---L7 Underlay Path: L1---107---L7(md)
L2---204---L4 (S4 and S7) L1---108---L8(ms)
L3---308---L8 L3---308---L8(ms)
L1---108---L8
--- --- ---
VN1 VN2 VN3
--- --- ---
Figure 11: ExampleAlso, ngl, the VN YANG data model includes the AP and VNAP too 🧚 They show how several VNs can share the same AP, which is so clever. Here's the JSON:
{
"ietf-vn:access-point": {
"ap": [
{
"id": "101",
"vn-ap": [
{
"id": "10101",
"vn": "1",
"abstract-node": "192.0.2.1",
"ltp": "203.0.113.11"
},
{
"id": "10102",
"vn": "2",
"abstract-node": "192.0.2.2",
"ltp": "203.0.113.12"
},
{
"id": "10103",
"vn": "3",
"abstract-node": "192.0.2.3",
"ltp": "203.0.113.13"
}
]
},
{
"id": "202",
"vn-ap": [
{
"id": "20201",
"vn": "1",
"abstract-node": "192.0.2.1",
"ltp": "203.0.113.21"
}
]
},
{
"id": "303",
"vn-ap": [
{
"id": "30301",
"vn": "1",
"abstract-node": "192.0.2.1",
"ltp": "203.0.113.31"
},
{
"id": "30303",
"vn": "3",
"abstract-node": "192.0.2.3",
"ltp": "203.0.113.33"
}
]
},
{
"id": "404",
"vn-ap": [
{
"id": "40401",
"vn": "1",
"abstract-node": "192.0.2.1",
"ltp": "203.0.113.41"
}
]
},
{
"id": "505",
"vn-ap": [
{
"id": "50502",
"vn": "2",
"abstract-node": "192.0.2.2",
"ltp": "203.0.113.52"
}
]
},
{
"id": "606",
"vn-ap": [
{
"id": "60603",
"vn": "3",
"abstract-node": "192.0.2.3",
"ltp": "203.0.113.63"
}
]
},
{
"id": "707",
"vn-ap": [
{
"id": "70701",
"vn": "1",
"abstract-node": "192.0.2.1",
"ltp": "203.0.113.71"
},
{
"id": "70703",
"vn": "3",
"abstract-node": "192.0.2.3",
"ltp": "203.0.113.73"
}
]
},
{
"id": "808",
"vn-ap": [
{
"id": "80801",
"vn": "1",
"abstract-node": "192.0.2.1",
"ltp": "203.0.113.81"
},
{
"id": "80803",
"vn": "3",
"abstract-node": "192.0.2.3",
"ltp": "203.0.113.83"
}
]
}
]
},
"ietf-vn:virtual-network": {
"vn": [
{
"id": "1",
"te-topology-identifier": {
"topology-id": "abstract1"
},
"abstract-node": "192.0.2.1",
"vn-member": [
{
"id": "104",
"src": {
"ap": "101",
"vn-ap-id": "10101"
},
"dest": {
"ap": "404",
"vn-ap-id": "40401"
},
"connectivity-matrix-id": 10104
},
{
"id": "107",
"src": {
"ap": "101",
"vn-ap-id": "10101"
},
"dest": {
"ap": "707",
"vn-ap-id": "70701"
},
"connectivity-matrix-id": 10107
},
{
"id": "204",
"src": {
"ap": "202",
"vn-ap-id": "20201"
},
"dest": {
"ap": "404",
"vn-ap-id": "40401"
},
"connectivity-matrix-id": 10204
},
{
"id": "308",
"src": {
"ap": "303",
"vn-ap-id": "30301"
},
"dest": {
"ap": "808",
"vn-ap-id": "80801"
},
"connectivity-matrix-id": 10308
},
{
"id": "108",
"src": {
"ap": "101",
"vn-ap-id": "10101"
},
"dest": {
"ap": "808",
"vn-ap-id": "80801"
},
"connectivity-matrix-id": 10108
}
]
},
{
"id": "2",
"te-topology-identifier": {
"topology-id": "abstract2"
},
"abstract-node": "192.0.2.2",
"vn-member": [
{
"id": "105",
"src": {
"ap": "101",
"vn-ap-id": "10102"
},
"dest": {
"ap": "505",
"vn-ap-id": "50502"
},
"connectivity-matrix-id": 20105
}
]
},
{
"id": "3",
"te-topology-identifier": {
"topology-id": "abstract3"
},
"abstract-node": "192.0.2.3",
"vn-member": [
{
"id": "106",
"src": {
"ap": "101",
"vn-ap-id": "10103"
},
"dest": {
"ap": "606",
"vn-ap-id": "60603",
"multi-dest": true
},
"connectivity-matrix-id": 30106,
"if-selected": false
},
{
"id": "107",
"src": {
"ap": "101",
"vn-ap-id": "10103"
},
"dest": {
"ap": "707",
"vn-ap-id": "70703",
"multi-dest": true
},
"connectivity-matrix-id": 30107,
"if-selected": true
},
{
"id": "108",
"src": {
"ap": "101",
"vn-ap-id": "10103",
"multi-src": true
},
"dest": {
"ap": "808",
"vn-ap-id": "80803",
},
"connectivity-matrix-id": 30108,
"if-selected": false
},
{
"id": "308",
"src": {
"ap": "303",
"vn-ap-id": "30303",
"multi-src": true
},
"dest": {
"ap": "808",
"vn-ap-id": "80803"
},
"connectivity-matrix-id": 30308,
"if-selected": true
}
]
}
]
}
}B.2. TE Topology JSON ✨
This section is all about the JSON for the different TE topology instances. Let's meet them 🌈
The example here includes these TE Topologies:
- abstract1 🌷: a single node TE topology that VN1 refers to. It also shows how disjointness (node, link, Shared Risk Link Group (SRLG)) is supported in the connectivity matrices. Super useful, fr fr.
- abstract2 🎀: a single node TE topology that VN2 refers to, with an underlay path.
- underlay 🧚: the topology with multiple nodes, which is the underlay path of abstract2. For brevity, the example only includes the node, so the other parameters aren't shown. Keeping it short, bestie 💜
- abstract3 🦋: a single node TE topology that VN3 refers to.
okay bestie, the TE topology JSON keeps going, and this is the part where the three networks really come together 🦋✨
{
"ietf-network:networks": {
"network": [
{
"network-types": {
"ietf-te-topology:te-topology": {}
},
"network-id": "example:abstract1",
"ietf-te-topology:te-topology-identifier": {
"provider-id": 0,
"client-id": 0,
"topology-id": "example:abstract1"
},
"node": [
{
"node-id": "example:192.0.2.1",
"ietf-network-topology:termination-point": [
{
"tp-id": "example:1-0-1",
"ietf-te-topology:te-tp-id": "203.0.113.11"
},
{
"tp-id": "example:1-0-2",
"ietf-te-topology:te-tp-id": "203.0.113.21"
},
{
"tp-id": "example:1-0-3",
"ietf-te-topology:te-tp-id": "203.0.113.31"
},
{
"tp-id": "example:1-0-4",
"ietf-te-topology:te-tp-id": "203.0.113.41"
},
{
"tp-id": "example:1-0-7",
"ietf-te-topology:te-tp-id": "203.0.113.71"
},
{
"tp-id": "example:1-0-8",
"ietf-te-topology:te-tp-id": "203.0.113.81"
}
],
"ietf-te-topology:te-node-id": "192.0.2.1",
"ietf-te-topology:te": {
"te-node-attributes": {
"domain-id": 1,
"is-abstract": [
null
],
"connectivity-matrices": {
"is-allowed": true,
"path-constraints": {
"te-bandwidth": {
"generic": "0x1p10"
},
"disjointness": "node link srlg"
},
"connectivity-matrix": [
{
"id": 10104,
"from": {
"tp-ref": "example:1-0-1"
},
"to": {
"tp-ref": "example:1-0-4"
}
},
{
"id": 10107,
"from": {
"tp-ref": "example:1-0-1"
},
"to": {
"tp-ref": "example:1-0-7"
}
},
{
"id": 10204,
"from": {
"tp-ref": "example:1-0-2"
},
"to": {
"tp-ref": "example:1-0-4"
}
},
{
"id": 10308,
"from": {
"tp-ref": "example:1-0-3"
},
"to": {
"tp-ref": "example:1-0-8"
}
},
{
"id": 10108,
"from": {
"tp-ref": "example:1-0-1"
},
"to": {
"tp-ref": "example:1-0-8"
}
}
]
}
}
}
}
]
},
{
"network-types": {
"ietf-te-topology:te-topology": {}
},
"network-id": "example:abstract2",
"ietf-te-topology:te-topology-identifier": {
"provider-id": 0,
"client-id": 0,
"topology-id": "example:abstract2"
},
"node": [
{
"node-id": "example:192.0.2.2",
"ietf-network-topology:termination-point": [
{
"tp-id": "example:2-0-1",
"ietf-te-topology:te-tp-id": "203.0.113.12"
},
{
"tp-id": "example:2-0-5",
"ietf-te-topology:te-tp-id": "203.0.113.52"
}
],
"ietf-te-topology:te-node-id": "192.0.2.2",
"ietf-te-topology:te": {
"te-node-attributes": {
"domain-id": 1,
"is-abstract": [
null
],
"connectivity-matrices": {
"is-allowed": true,
"underlay": {
"enabled": true
},
"path-constraints": {
"te-bandwidth": {
"generic": "0x1p10"
}
},
"optimizations": {
"objective-function": {
"objective-function-type":
"ietf-te-types:of-maximize-residual-bandwidth"
}
},
"ietf-te-topology:connectivity-matrix": [
{
"id": 20105,
"from": {
"tp-ref": "example:2-0-1"
},
"to": {
"tp-ref": "example:2-0-5"
},
"underlay": {
"enabled": true,
"primary-path": {
"network-ref": "example:underlay",
"path-element": [
{
"path-element-id": 1,
"numbered-node-hop": {
"node-id": "198.51.100.44",
"hop-type": "strict"
}
},
{
"path-element-id": 2,
"numbered-node-hop": {
"node-id": "198.51.100.77",
"hop-type": "strict"
}
}
]
}
}
}
]
}
}
}
}
]
},
{
"network-types": {
"ietf-te-topology:te-topology": {}
},
"network-id": "example:underlay",
"ietf-te-topology:te-topology-identifier": {
"provider-id": 0,
"client-id": 0,
"topology-id": "example:underlay"
},
"node": [
{
"node-id": "example:198.51.100.11",
"ietf-te-topology:te-node-id": "198.51.100.11"
},
{
"node-id": "example:198.51.100.22",
"ietf-te-topology:te-node-id": "198.51.100.22"
},
{
"node-id": "example:198.51.100.33",
"ietf-te-topology:te-node-id": "198.51.100.33"
},
{
"node-id": "example:198.51.100.44",
"ietf-te-topology:te-node-id": "198.51.100.44"
},
{
"node-id": "example:198.51.100.55",
"ietf-te-topology:te-node-id": "198.51.100.55"
},
{
"node-id": "example:198.51.100.66",
"ietf-te-topology:te-node-id": "198.51.100.66"
},
{
"node-id": "example:198.51.100.77",
"ietf-te-topology:te-node-id": "198.51.100.77"
},
{
"node-id": "example:198.51.100.88",
"ietf-te-topology:te-node-id": "198.51.100.88"
},
{
"node-id": "example:198.51.100.99",
"ietf-te-topology:te-node-id": "198.51.100.99"
}
]
},
{
"network-types": {
"ietf-te-topology:te-topology": {}
},
"network-id": "example:abstract3",
"ietf-te-topology:te-topology-identifier": {
"provider-id": 0,
"client-id": 0,
"topology-id": "example:abstract3"
},
"node": [
{
"node-id": "example:192.0.2.3",
"ietf-network-topology:termination-point": [
{
"tp-id": "example:3-0-1",
"ietf-te-topology:te-tp-id": "203.0.113.13"
},
{
"tp-id": "example:3-0-3",
"ietf-te-topology:te-tp-id": "203.0.113.33"
},
{
"tp-id": "example:3-0-6",
"ietf-te-topology:te-tp-id": "203.0.113.63"
},
{
"tp-id": "example:3-0-7",
"ietf-te-topology:te-tp-id": "203.0.113.73"
},
{
"tp-id": "example:3-0-8",
"ietf-te-topology:te-tp-id": "203.0.113.83"
}
],
"ietf-te-topology:te-node-id": "192.0.2.3",
"ietf-te-topology:te": {
"te-node-attributes": {
"domain-id": 3,
"is-abstract": [
null
],
"connectivity-matrices": {
"is-allowed": true,
"path-constraints": {
"te-bandwidth": {
"generic": "0x1p10"
}
},
"connectivity-matrix": [
{
"id": 30107,
"from": {
"tp-ref": "example:3-0-1"
},
"to": {
"tp-ref": "example:3-0-7"
}
},
{
"id": 30106,
"from": {
"tp-ref": "example:3-0-1"
},
"to": {
"tp-ref": "example:3-0-6"
}
},
{
"id": 30108,
"from": {
"tp-ref": "example:3-0-1"
},
"to": {
"tp-ref": "example:3-0-8"
}
},
{
"id": 30308,
"from": {
"tp-ref": "example:3-0-3"
},
"to": {
"tp-ref": "example:3-0-8"
}
}
]
}
}
}
}
]
}
]
}
}Acknowledgments 💖
okay bestie, the authors gotta thank the squad 🫶 huge thanks to Xufeng Liu, Adrian Farrel, Tom Petch, Mohamed Boucadair, Italo Busi, Bo Wu, and Daniel King for their helpful comments and valuable suggestions 🌸 they really made this doc better!!
Then there's a whole list of people who did reviews, and every single one of them ate 💅
- Andy Bierman for the YANGDIR review.
- Darren Dukes and Susan Hares for the RTGDIR review.
- Behcet Sarikaya for the GENART review.
- Bo Wu for the OPSDIR review.
- Shivan Sahib for the SECDIR review.
- Deb Cooley, Francesca Palombini, Gunter Van de Velde, and Mahesh Jethanandani for the IESG review.
Contributors 🎀
these are the people who helped write the actual text, so they get their own spotlight ✨ here they are, verbatim:
Qin Wu
Huawei Technologies
Email: bill.wu@huawei.com
Peter Park
KT
Email: peter.park@kt.com
Haomian Zheng
Huawei Technologies
Email: zhenghaomian@huawei.com
Xian Zhang
Huawei Technologies
Email: zhang.xian@huawei.com
Sergio Belotti
Nokia
Email: sergio.belotti@nokia.com
Takuya Miyasaka
KDDI
Email: ta-miyasaka@kddi.com
Kenichi Ogaki
KDDI
Email: ke-oogaki@kddi.comAuthors' Addresses 🦋
and last but definitely not least, the authors themselves 👑 Young Lee is the editor, Dhruv Dhody is also an editor, and then Daniele Ceccarelli, Igor Bryskin, and Bin Yeong Yoon round out the crew. Contact info is below, exactly as written:
Young Lee (editor)
Samsung Electronics
Email: younglee.tx@gmail.com
Dhruv Dhody (editor)
Huawei
India
Email: dhruv.ietf@gmail.com
Daniele Ceccarelli
Cisco
Email: daniele.ietf@gmail.com
Igor Bryskin
Individual
Email: i_bryskin@yahoo.com
Bin Yeong Yoon
ETRI
Email: byyun@etri.re.krthat's the whole doc, periodt 🌈💜
📦 where this page comes from
- ietf: rfc9731 2025-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms