rfc9731.original   rfc9731.txt 
TEAS Working Group Y. Lee, Ed. Internet Engineering Task Force (IETF) Y. Lee, Ed.
Internet-Draft Samsung Electronics Request for Comments: 9731 Samsung Electronics
Intended status: Standards Track D. Dhody, Ed. Category: Standards Track D. Dhody, Ed.
Expires: 24 December 2024 Huawei ISSN: 2070-1721 Huawei
D. Ceccarelli D. Ceccarelli
Cisco Cisco
I. Bryskin I. Bryskin
Individual Individual
B. Yoon B. Yoon
ETRI ETRI
22 June 2024 March 2025
A YANG Data Model for Virtual Network (VN) Operations A YANG Data Model for Virtual Network (VN) Operations
draft-ietf-teas-actn-vn-yang-29
Abstract Abstract
A Virtual Network (VN) is a network provided by a service provider to A Virtual Network (VN) is a network provided by a service provider to
a customer for the customer to use in any way it wants as though it a customer for the customer to use in any way it wants as though it
was a physical network. This document provides a YANG data model were a physical network. This document provides a YANG data model
generally applicable to any mode of VN operations. This includes VN generally applicable to any mode of VN operations. This includes VN
operations as per the Abstraction and Control of TE Networks (ACTN) operations as per the Abstraction and Control of TE Networks (ACTN)
framework. framework (see RFC 8453).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 24 December 2024. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9731.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology and Conventions
1.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Tree Diagram
1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 5 1.3. Prefixes in Data Node Names
2. Use-case of VN YANG Model in the ACTN context . . . . . . . . 5 2. Use Case of VN YANG Data Model in the ACTN Context
2.1. Type 1 VN . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Type 1 VN
2.2. Type 2 VN . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Type 2 VN
3. High-Level Control Flows with Examples . . . . . . . . . . . 8 3. High-Level Control Flows with Examples
3.1. Type 1 VN Illustration . . . . . . . . . . . . . . . . . 8 3.1. Type 1 VN Illustration
3.2. Type 2 VN Illustration . . . . . . . . . . . . . . . . . 9 3.2. Type 2 VN Illustration
3.2.1. VN and AP Usage . . . . . . . . . . . . . . . . . . . 12 3.2.1. VN and AP Usage
4. VN Model Usage . . . . . . . . . . . . . . . . . . . . . . . 12 4. VN YANG Data Model Usage
4.1. Customer view of VN . . . . . . . . . . . . . . . . . . . 12 4.1. Customer View of VN
4.2. Auto-creation of VN by MDSC . . . . . . . . . . . . . . . 12 4.2. Auto-creation of VN by MDSC
4.3. Innovative Services . . . . . . . . . . . . . . . . . . . 12 4.3. Innovative Services
4.3.1. VN Compute . . . . . . . . . . . . . . . . . . . . . 13 4.3.1. VN Compute
4.3.2. Multi-sources and Multi-destinations . . . . . . . . 17 4.3.2. Multiple Sources and Multiple Destinations
4.4. Others . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.4. Others
4.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.5. Summary
5. VN YANG Model (Tree Structure) . . . . . . . . . . . . . . . 19 5. VN YANG Data Model (Tree Structure)
6. VN YANG Model . . . . . . . . . . . . . . . . . . . . . . . . 22 6. VN YANG Data Model
7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 7. Security Considerations
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 8. IANA Considerations
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 9. References
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 9.1. Normative References
10.1. Normative References . . . . . . . . . . . . . . . . . . 37 9.2. Informative References
10.2. Informative References . . . . . . . . . . . . . . . . . 38 Appendix A. Performance Constraints
Appendix A. Performance Constraints . . . . . . . . . . . . . . 40 Appendix B. JSON Example
Appendix B. JSON Example . . . . . . . . . . . . . . . . . . . . 40 B.1. VN JSON
B.1. VN JSON . . . . . . . . . . . . . . . . . . . . . . . . . 40 B.2. TE Topology JSON
B.2. TE-topology JSON . . . . . . . . . . . . . . . . . . . . 47 Acknowledgments
Appendix C. Contributors Addresses . . . . . . . . . . . . . . . 54 Contributors
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 Authors' Addresses
1. Introduction 1. Introduction
Abstraction and Control of Traffic Engineered (TE) Networks (ACTN) Abstraction and Control of TE Networks (ACTN) describes a set of
describes a set of management and control functions used to operate management and control functions used to operate one or more Traffic
one or more TE networks to construct a Virtual Network (VN). A VN is Engineered (TE) networks to construct a Virtual Network (VN). A VN
represented to customers and is built from the abstractions of the is represented to customers and is built from the abstractions of the
underlying TE networks [RFC8453]. This document provides a YANG underlying TE networks [RFC8453]. This document provides a YANG data
[RFC7950] data model generally applicable to any mode of VN model [RFC7950] generally applicable to any mode of VN operation.
operation. ACTN is the primary example of the usage of the VN YANG ACTN is the primary example of the usage of the VN YANG data model,
model but not limited to it. but VN is not limited to it.
The VN model defined in this document is applicable in a generic The VN model defined in this document is applicable in a generic
sense as an independent model in and of itself. The VN model defined sense as an independent model in and of itself. It can also work
in this document can also work together with other customer service together with other customer service models such as the L3VPN Service
models such as the Layer Three Virtual Private Network Service Model Model (L3SM) [RFC8299], the L2VPN Service Model (L2SM) [RFC8466], and
(L3SM) [RFC8299], the Layer Two Virtual Private Network Service Model the L1 Connectivity Service Model (L1CSM) [L1CSM-YANG] to provide
(L2SM) [RFC8466] and the Layer One Connectivity Service Model (L1CSM) complete life-cycle service management and operations.
[I-D.ietf-ccamp-l1csm-yang] to provide a complete life-cycle service
management and operations.
The YANG model discussed in this document basically provides the The YANG data model discussed in this document basically provides the
following: following:
* Characteristics of Access Points (APs) that describe customer's * Characteristics of Access Points (APs) that describe customer's
endpoint characteristics; endpoint characteristics;
* Characteristics of Virtual Network Access Points (VNAP) that * Characteristics of Virtual Network Access Points (VNAPs) that
describe how an AP is partitioned for multiple VNs sharing the AP describe how an AP is partitioned for multiple VNs sharing the AP
and its reference to a Link Termination Point (LTP) of the and its reference to a Link Termination Point (LTP) of the
Provider Edge (PE) Node; Provider Edge (PE) node;
* Characteristics of Virtual Networks (VNs) that describe the * Characteristics of VNs that describe the customer's VN in terms of
customer's VN in terms of multiple VN Members comprising a VN, multiple VN members comprising a VN, multi-source and/or multi-
multi-source and/or multi-destination characteristics of the VN destination characteristics of the VN member, the VN's reference
Member, the VN's reference to TE-topology's Abstract Node; to TE-topology's abstract node.
An abstract TE topology is a topology that contains abstract An abstract TE topology is a topology that contains abstract
topological elements (nodes, links) created and customised based on topological elements (nodes, links) created and customized based on
customer's preference [RFC8795]. The actual VN instantiation and customer preference [RFC8795]. The actual VN instantiation and
computation is performed with Connectivity Matrices of the TE- computation is performed with connectivity matrices of the TE
Topology Model [RFC8795] which provides a TE network topology Topology model [RFC8795], which provides a TE network topology
abstraction and management operation. As per [RFC8795], a TE node abstraction and management operation. As per [RFC8795], a TE node
connectivity matrix is the TE node's switching limitations in the connectivity matrix is the TE node's switching limitations in the
form of valid switching combinations of the TE node's LTPs and form of valid switching combinations of the TE node's LTPs and
potential TE paths. The VN representation relies on a single potential TE paths. The VN representation relies on a single
abstract TE node with a connectivity matrix. The VN can be abstract TE node with a connectivity matrix. The VN can be
abstracted as a set of edge-to-edge links (a Type 1 VN). Each link abstracted as a set of edge-to-edge links (a Type 1 VN). Each link
is the VN member that is mapped to the connectivity matrix entry is the VN member that is mapped to the connectivity matrix entry
(Section 2.1). The VN can also be abstracted as a topology of (Section 2.1). The VN can also be abstracted as a topology of
virtual nodes and virtual links (a Type 2 VN). Alongside the mapping virtual nodes and virtual links (a Type 2 VN). Alongside the mapping
of VN members to connectivity matrix entry, an underlay path can also of VN members to a connectivity matrix entry, an underlay path can
be specified (Section 2.2). also be specified (Section 2.2).
Once the TE-topology Model is used in triggering VN instantiation Once the TE Topology model is used in triggering VN instantiation
over the networks, the TE-tunnel [I-D.ietf-teas-yang-te] Model will over the networks, the TE model [YANG-TE] will inevitably interact
inevitably interact with the TE-Topology model for setting up actual with the TE Topology model when setting up actual tunnels and Label
tunnels and LSPs under the tunnels. Switched Paths (LSPs) under the tunnels.
Sections 2 and 3 provide a discussion of how the VN YANG model is Sections 2 and 3 provide a discussion of how the VN YANG data model
applicable to the ACTN context where Virtual Network Service (VNS) is applicable to the ACTN context where a Virtual Network Service
operation is implemented for the Customer Network Controller (CNC)- (VNS) operation is implemented for the interface of the Customer
Multi-Domain Service Coordinator (MDSC) interface (CMI). Network Controller (CNC) and the Multi-Domain Service Coordinator
(MDSC).
The YANG model on the CMI is also known as the customer service model The YANG data model for the CNC-MDSC Interface (CMI) is also known as
in [RFC8309]. The YANG model discussed in this document is used to the "customer service model" in [RFC8309]. The YANG data model
operate customer-driven VNs during the VN instantiation, VN discussed in this document is used to operate customer-driven VNs
computation, and its life-cycle service management and operations. during the VN instantiation and computation as well as its life-cycle
service management and operations.
The VN operational state is included in the same tree as the The VN operational state is included in the same tree as the
configuration consistent with Network Management Datastore configuration consistent with Network Management Datastore
Architecture (NMDA) [RFC8342]. Architecture (NMDA) [RFC8342].
1.1. Terminology 1.1. Terminology and Conventions
This document borrows the following terms from [RFC8453]:
* VN: Virtual Network This document borrows the following abbreviations from [RFC8453] and/
or [RFC8795]:
* AP: Access Point VN: Virtual Network
* VNAP: VN Access Point AP: Access Point
* ACTN: Abstraction and Control of TE Networks VNAP: VN Access Point
* CNC: Customer Network Controller ACTN: Abstraction and Control of TE Networks
* MDSC: Multi-Domain Service Coordinator CNC: Customer Network Controller
* CMI: CNC-MDSC Interface MDSC: Multi-Domain Service Coordinator
This document borrows the following terms from [RFC8795]: CMI: CNC-MDSC Interface
* LTP: Link Termination Point LTP: Link Termination Point
* Connectivity Matrix This document borrows the terminology in Section 1.1 of [RFC7926],
This document borrows the terminology in Section 1.1 of [RFC7926]. the term "Service Model" from [RFC8309], and the term "Connectivity
Matrix" from [RFC8795].
This document uses the term 'Service Model' as described in Various examples in this document contain long lines that may be
[RFC8309]. folded, as described in [RFC8792].
1.2. Tree Diagram 1.2. Tree Diagram
A simplified graphical representation of the data model is used in A simplified graphical representation of the data model is used in
Section 5 of this document. The meaning of the symbols in these Section 5 of this document. The meaning of the symbols in these
diagrams is defined in [RFC8340]. diagrams is defined in [RFC8340].
1.3. Prefixes in Data Node Names 1.3. Prefixes in Data Node Names
In this document, the names of data nodes and other data model In this document, the names of data nodes and other data model
objects are prefixed using the standard prefix associated with the objects are prefixed using the standard prefix associated with the
corresponding YANG imported modules, as shown in Table 1. corresponding YANG imported modules as shown in Table 1.
+==========+=======================+===========+ +==========+=======================+===========+
| Prefix | YANG module | Reference | | Prefix | YANG Module | Reference |
+==========+=======================+===========+ +==========+=======================+===========+
| vn | ietf-vn | [RFCXXXX] | | vn | ietf-vn | RFC 9731 |
+----------+-----------------------+-----------+ +----------+-----------------------+-----------+
| yang | ietf-yang-types | [RFC6991] | | yang | ietf-yang-types | [RFC6991] |
+----------+-----------------------+-----------+ +----------+-----------------------+-----------+
| nw | ietf-network | [RFC8345] | | nw | ietf-network | [RFC8345] |
+----------+-----------------------+-----------+ +----------+-----------------------+-----------+
| nt | ietf-network-topology | [RFC8345] | | nt | ietf-network-topology | [RFC8345] |
+----------+-----------------------+-----------+ +----------+-----------------------+-----------+
| te-types | ietf-te-types | [RFC8776] | | te-types | ietf-te-types | [RFC8776] |
+----------+-----------------------+-----------+ +----------+-----------------------+-----------+
| tet | ietf-te-topology | [RFC8795] | | tet | ietf-te-topology | [RFC8795] |
+----------+-----------------------+-----------+ +----------+-----------------------+-----------+
Table 1: Prefixes and corresponding YANG modules Table 1: Prefixes and Corresponding YANG Modules
Note: The RFC Editor will replace XXXX with the number assigned to
the RFC once this draft becomes an RFC.
2. Use-case of VN YANG Model in the ACTN context 2. Use Case of VN YANG Data Model in the ACTN Context
In this section, ACTN is being used to illustrate the general usage In this section, ACTN is being used to illustrate the general usage
of the VN YANG model. The model presented in this section has the of the VN YANG data model. The model presented in this section has
following ACTN context. the following ACTN context.
+-------+ +-------+
| CNC | | CNC |
+-------+ +-------+
| |
| VN YANG + TE-topology YANG | VN + TE Topology
| |
+-----------------------+ +-----------------------+
| MDSC | | MDSC |
+-----------------------+ +-----------------------+
Figure 1: ACTN CMI Figure 1: ACTN CMI
Both ACTN VN YANG and TE-topology models are used over the CMI to Both ACTN VN and TE Topology YANG data models are used over the CMI
establish a VN over TE networks as shown in Figure 1. to establish a VN over TE networks, as shown in Figure 1.
2.1. Type 1 VN 2.1. Type 1 VN
As defined in [RFC8453], a Virtual Network is a customer view of the As defined in [RFC8453], a VN is a customer view of the TE network.
TE network. To recapitulate VN types from [RFC8453], Type 1 VN is To recapitulate VN types from [RFC8453], a Type 1 VN is defined as
defined as follows: follows:
| The VN can be seen as a set of edge-to-edge abstract links (a Type The VN can be seen as a set of edge-to-edge abstract links (a Type 1
| 1 VN). Each abstract link is referred to as a VN member and is VN). Each abstract link is referred to as a VN member and is formed
| formed as an end-to-end tunnel across the underlying networks. as an end-to-end tunnel across the underlying networks. Such tunnels
| Such tunnels may be constructed by recursive slicing or may be constructed by recursive slicing or abstraction of paths in
| abstraction of paths in the underlying networks and can encompass the underlying networks and can encompass edge points of the
| edge points of the customer's network, access links, intra-domain customer's network, access links, intra-domain paths, and inter-
| paths, and inter-domain links. domain links.
If we were to create a VN where we have four VN-members as If we were to create a VN where we have four VN members as follows:
follows:
VN-member 1 L1-L4 VN member 1 L1-L4
VN-member 2 L1-L7 VN member 2 L1-L7
VN-member 3 L2-L4 VN member 3 L2-L4
VN-member 4 L3-L8 VN member 4 L3-L8
Where L1, L2, L3, L4, L7, and L8 correspond to a Customer End- Figure 2: VN Members (Type 1 VN)
Point (or AP).
This VN can be modelled as one abstract node representation as Where L1, L2, L3, L4, L7, and L8 correspond to a Customer Endpoint
follows in Figure 2: (or AP).
+----------------------------------------------+ This VN can be modeled as one abstract node representation as follows
| | in Figure 3:
L1----|..............................................|------L4
| . . |
| . AN1 . |
| . . |
| ..................................*.....|------L7
| . |
L2-----|....................................... |
| |
L3-----|..............................................|------L8
| |
+----------------------------------------------+
Figure 2: Abstract Node (One node topology) +----------------------------------------------+
| |
L1----|..............................................|------L4
| . . |
| . AN1 . |
| . . |
| ..................................*.....|------L7
| . |
L2-----|....................................... |
| |
L3-----|..............................................|------L8
| |
+----------------------------------------------+
Modelling a VN as one abstract node is the easiest way for customers Figure 3: Abstract Node (Type 1 Topology)
to express their end-to-end connectivity as shown in Figure 2.
Modeling a VN as one abstract node is the easiest way for customers
to express their end-to-end connectivity as shown in Figure 3.
2.2. Type 2 VN 2.2. Type 2 VN
For some VN members, the customers are allowed to configure the For some VN members, the customers are allowed to configure the
intended path. To achieve this, alongside the single node abstract intended path. To achieve this, alongside the single node abstract
topology, an underlay topology is also needed. The underlay topology topology, an underlay topology is also needed. The underlay topology
could be native TE topology or an abstract TE topology. The intended could be native TE topology or an abstract TE topology. The intended
path is set based on the nodes and links of the underlay topology. path is set based on the nodes and links of the underlay topology. A
Type 1 VN can be seen as a higher abstraction of a Type 2 VN (which Type 1 VN can be viewed as a higher-level abstraction of a Type 2 VN,
along with a single node abstract topology, an underlay topology and which represents a single node abstract topology over the underlay
the intended path is specified). These topologies could be mutually topology and includes a mechanism to specify intended paths. These
agreed between CNC and MDSC prior to VN creation or it could be topologies could be mutually agreed upon between the CNC and the MDSC
created as part of VN instantiation. prior to VN creation or they could be created as part of VN
instantiation.
If a Type 2 VN is desired for some or all of the VN members of a Type If a Type 2 VN is desired 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 1 VN (see the example in Section 2.1), the TE Topology model can
provide the following abstract topologies (a single node topology AN1 provide the following abstract topologies (a single node topology AN1
and an underlay topology (with nodes S1 to S11 and corresponding and an underlay topology (with nodes S1 to S11 and corresponding
links)). links)).
+----------------------------------------------+ +----------------------------------------------+
| S1 S2 | | S1 S2 |
| O...............O | | O...............O |
| ......... ....... . | | ......... ....... . |
| . . . | | . . . |
|S3 . . S4 . S5 | |S3 . . S4 . S5 |
L1----|.O......................O.........O...........|------L4 L1----|.O......................O.........O...........|------L4
| . . . | | . . . |
| . . . | | . . . |
| . S6 . S7 . S8 | | . S6 . S7 . S8 |
| O ................O.........O.......|------L7 | O ................O.........O.......|------L7
| . . . . ..... | | . . . . ..... |
|S9 . . .S10 . . | |S9 . . .S10 . . |
L2-----|...O.....O.....................O..............|------L8 L2-----|...O.....O.....................O..............|------L8
| . S11 | | . S11 |
L3-----|.. | L3-----|.. |
| AN1 | | AN1 |
+----------------------------------------------+ +----------------------------------------------+
Figure 3: Type 2 topology Figure 4: Type 2 Topology
As shown in Figure 3, the abstract node is AN1 and an underlay As shown in Figure 4, the abstract node is AN1 and an underlay
topology is depicted with nodes and links (S1 to S11). topology is depicted with nodes and links (S1 to S11).
As an example, if VN-member 1 (L1-L4) is chosen to configure its own As an example, if VN member 1 (L1-L4) is chosen to configure its own
path over Type 2 topology, it can select, say, a path that consists path over Type 2 topology, it can select, say, a path that consists
of the explicit abstract path {S3,S4,S5} based on the underlay of the explicit path {S3,S4,S5} based on the underlay topology and
topology and its service requirement. This capability is enacted via its service requirement. This capability is enacted via TE-topology
TE-topology configuration by the customer. configuration by the customer.
3. High-Level Control Flows with Examples 3. High-Level Control Flows with Examples
3.1. Type 1 VN Illustration 3.1. Type 1 VN Illustration
If this VN is Type 1, the following diagram shows the message flow If this VN is Type 1, the following diagram shows the message flow
between CNC and MDSC to instantiate this VN using VN and TE-Topology between CNC and MDSC to instantiate this VN using VN and TE Topology
Models. YANG data models.
+--------+ +--------+ +--------+ +--------+
| CNC | | MDSC | | CNC | | MDSC |
+--------+ +--------+ +--------+ +--------+
| | | |
| | | |
CNC POST TE-topo | POST /nw:networks/nw:network/ | CNC POST TE Topo | POST /nw:networks/nw:network/ |
model(with Conn. | nw:node/te-node-id/ | model (w/ Conn. | nw:node/te-node-id/ |
Matrix on one | tet:connectivity-matrices/ | Matrix on one | tet:connectivity-matrices/ |
Abstract node | tet:connectivity-matrix | abstract node) | tet:connectivity-matrix |
|-------------------------------->| |-------------------------------->|
| HTTP 200 | | HTTP 200 |
|<--------------------------------| |<--------------------------------|
| | | |
CNC POST the | POST /virtual-network | CNC POST the | POST /virtual-network |
VN identifying |-------------------------------->| If there is VN identifying |-------------------------------->| If there is
AP, VNAP and VN- | | multi-src/dest AP, VNAP, and VN | | multi-src/dest,
Members and maps | | then MDSC members and maps | | then MDSC
to the TE-topo | HTTP 200 | selects a to the TE Topo | HTTP 200 | selects an
|<--------------------------------| src or dest model |<--------------------------------| src or dest
| | and updates | | and updates
| | VN YANG | | VN YANG
CNC GET the | GET /virtual-network | CNC GET the | GET /virtual-network |
VN YANG status |-------------------------------->| VN YANG status |-------------------------------->|
| | | |
| HTTP 200 (VN with status: | | HTTP 200 (VN with status: |
| selected VN-members | | selected VN members |
| in case of multi-s-d) | | in case of multi-s/d) |
|<--------------------------------| |<--------------------------------|
| | | |
Figure 4: Type 1 VN Illustration Figure 5: Type 1 VN Illustration
3.2. Type 2 VN Illustration 3.2. Type 2 VN Illustration
For some VN members, the customer may want to "configure" explicit For some VN members, the customer may want to "configure" an explicit
path that connects its two end-points. Let us consider the following path that connects its two endpoints. Let us consider the following
example. 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 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)
VN-member 4 L3-L8 (via S9, S10 and S11) Figure 6: VN Members (Type 2 VN)
There are two options depending on whether CNC or MDSC creates the There are two options depending on whether CNC or MDSC creates the
single abstract node topology. single abstract node topology.
Case 1: Case 1:
If CNC creates the single-abstract-node topology, the following If the CNC creates the single abstract node topology, the message
diagram shows the message flow between CNC and MDSC to instantiate flow between the CNC and MDSC to instantiate this VN using a VN and
this VN using VN and TE-Topology Model. TE Topology YANG data model would be as shown in the following
diagram:
+--------+ +--------+ +--------+ +--------+
| CNC | | MDSC | | CNC | | MDSC |
+--------+ +--------+ +--------+ +--------+
| | | |
| | | |
CNC POST TE-topo | POST /nw:networks/nw:network/ | CNC POST TE Topo | POST /nw:networks/nw:network/ |
model(with Conn. | nw:node/te-node-id/tet:connectivity- | model (w/ Conn. | nw:node/te-node-id/tet:connectivity- |
Matrix on one | matrices/tet:connectivity-matrix | Matrix on one | matrices/tet:connectivity-matrix |
Abstract node and|---------------------------------------->| abstract node and|---------------------------------------->|
Explicit paths in| | explicit paths in| |
the conn. matrix)| HTTP 200 | the Conn. Matrix)| HTTP 200 |
|<----------------------------------------| |<----------------------------------------|
| | | |
CNC POST the | POST /virtual-network | CNC POST the | POST /virtual-network |
VN identifying |---------------------------------------->| VN identifying |---------------------------------------->|
AP, VNAP and VN- | | AP, VNAP, and VN | |
Members and maps | | members and maps | |
to the TE-topo | HTTP 200 | to the TE Topo | HTTP 200 |
|<----------------------------------------| model |<----------------------------------------|
| | | |
| | | |
CNC GET the | GET /virtual-network | CNC GET the | GET /virtual-network |
VN YANG status |---------------------------------------->| VN YANG status |---------------------------------------->|
| | | |
| HTTP 200 (VN with status) | | HTTP 200 (VN with status) |
|<----------------------------------------| |<----------------------------------------|
| | | |
Figure 5: Type 2 VN Illustration, Case 1 Figure 7: Type 2 VN Illustration: Case 1
Case 2: Case 2:
On the other hand, if MDSC create the single-abstract-node topology On the other hand, if MDSC create the single abstract node topology
based on VN YANG posted by the CNC, the following diagram shows the based on VN YANG posted by the CNC, the following diagram shows the
message flow between CNC and MDSC to instantiate this VN using VN and message flow between CNC and MDSC to instantiate this VN using VN and
TE-Topology Models. TE Topology YANG data models.
+--------+ +--------+ +--------+ +--------+
| CNC | | MDSC | | CNC | | MDSC |
+--------+ +--------+ +--------+ +--------+
| | | |
| | | |
CNC POST VN | | CNC POST VN | |
Identifying AP, | | identifying AP, | |
VNAP and VN- | POST /virtual-network | MDSC populates VNAP and VN | POST /virtual-network | MDSC populates
Members |-------------------------------->| a single Abst. members |-------------------------------->| a single abst.
| HTTP 200 | node topology | HTTP 200 | node topology
|<--------------------------------| by itself |<--------------------------------| by itself
| | | |
CNC GET VN & | GET /virtual-network & | CNC GET VN & | GET /virtual-network & |
POST TE-Topo | POST /nw:networks/nw:network/ | POST TE Topo | POST /nw:networks/nw:network/ |
Models (with | nw:node/te-node-id/tet: | models (w/ | nw:node/te-node-id/tet: |
Conn. Matrix | connectivity-matrices/ | Conn. Matrix | connectivity-matrices/ |
on the | tet:connectivity-matrix | on the | tet:connectivity-matrix |
Abstract Node |-------------------------------->| abstract node |-------------------------------->|
and explicit | | and explicit | |
paths in the | | paths in the | |
conn. matrix) | | Conn. Matrix) | |
| HTTP 200 | | HTTP 200 |
|<--------------------------------| |<--------------------------------|
| | | |
| | | |
CNC GET the | GET /virtual-network | CNC GET the | GET /virtual-network |
VN YANG status |-------------------------------->| VN YANG status |-------------------------------->|
| | | |
| HTTP 200 (VN with status) | | HTTP 200 (VN with status) |
|<--------------------------------| |<--------------------------------|
| | | |
Figure 6: Type 2 VN Illustration, Case 2 Figure 8: Type 2 VN Illustration: Case 2
Note that the underlay topology (which is referred to by the single- Note that the underlay topology (which is referred to by the single
abstract-node topology) could be a Native/White topology or a Grey abstract node topology) could be a Native/White topology or a Grey
topology ([RFC8453]) that is further customised based on the topology ([RFC8453]) that is further customized based on the
requirements of the customer and configured at MDSC. requirements of the customer and configured at the MDSC.
Appendix B provides JSON examples for both VN model and TE-topology Appendix B provides JSON examples for both the VN model and the TE
Connectivity Matrix sub-model to illustrate how a VN can be created Topology Connectivity Matrix sub-model to illustrate how a VN can be
by the CNC making use of the VN module as well as the TE-topology created by the CNC making use of the VN model as well as the TE
Connectivity Matrix module. Topology Connectivity Matrix module.
3.2.1. VN and AP Usage 3.2.1. VN and AP Usage
The customer access information may be known at the time of VN The customer access information may be known at the time of VN
creation. A shared logical AP identifier is used between the creation. A shared logical AP identifier is used between the
customer and the operator to identify the access link between customer and the operator to identify the access link between
Customer Edge (CE) and Provider Edge (PE). This is described in Customer Edge (CE) and Provider Edge (PE). This is described in
Section 6 of [RFC8453]. Section 6 of [RFC8453].
In some VN operations, the customer access may not be known at the In some VN operations, the customer access may not be known at the
initial VN creation. The VN operation allows the creation of a VN initial VN creation. The VN operation allows the creation of a VN
with only a PE identifier as well. The customer access information with only a PE identifier. The customer access information could be
could be added later. added later.
To achieve this, the 'ap' container has a leaf for 'pe' node that To achieve this, the 'ap' container has a leaf for the 'pe' node that
allows AP to be created with PE information. The vn-member (and vn) allows the AP to be created with PE information. The VN member (and
could use APs that only have PE information initially. VN) could use APs that initially only have PE information.
4. VN Model Usage 4. VN YANG Data Model Usage
4.1. Customer view of VN 4.1. Customer View of VN
The VN-YANG model allows to define a customer view, and allows the The VN YANG data model allows the definition of a customer view and
customer to communicate using the VN constructs as described in the allows the customer to communicate using the VN constructs as
[RFC8454]. It allows the grouping of edge-to-edge links (i.e., VN described in [RFC8454]. It allows the grouping of edge-to-edge links
members) under a common umbrella of VN. This allows the customer to (i.e., VN members) under a common umbrella of VN. This allows the
instantiate and view the VN as one entity, making it easier for some customer to instantiate and view the VN as one entity, making it
customers to work on VN without worrying about the details of the easier for some customers to work on VN without worrying about the
provider-based YANG models. details of the provider-based YANG data models.
This is similar to the benefits offered by a separate YANG model for This is similar to the benefits offered by a separate YANG data model
the customer services as described in [RFC8309], which states that for customer services described in [RFC8309], which states that
service models do not make any assumption about how a service is service models do not make any assumptions about how a service is
actually engineered and delivered for a customer. actually engineered and delivered for a customer.
4.2. Auto-creation of VN by MDSC 4.2. Auto-creation of VN by MDSC
The VN could be configured at the MDSC explicitly by the CNC using The VN could be configured at the MDSC explicitly by the CNC using
the VN YANG model. In some other cases, the VN is not explicitly the VN YANG data model. In some other cases, the VN is not
configured, but created automatically by the MDSC based on the explicitly configured but is instead created automatically by the
customer service model and local policy, even in these cases, the VN MDSC based on the customer service model and local policy; even in
YANG model can be used by the CNC to learn details of the underlying these cases, the VN YANG data model can be used by the CNC to learn
VN, created to meet the requirements of the customer service model. details of the underlying VN, created to meet the requirements of the
customer service model.
4.3. Innovative Services 4.3. Innovative Services
4.3.1. VN Compute 4.3.1. VN Compute
VN Model supports VN compute (pre-instantiation mode) to view the The VN model supports VN compute (pre-instantiation mode) to view the
full VN as a single entity before instantiation. Achieving this via full VN as a single entity before instantiation; achieving this via
path computation or "compute only" tunnel setup path computation or "compute-only" tunnel setup ([YANG-TE]) does not
([I-D.ietf-teas-yang-te]) does not provide the same functionality. provide the same functionality.
+--------+ +--------+ +--------+ +--------+
| CNC | | MDSC | | CNC | | MDSC |
+--------+ +--------+ +--------+ +--------+
| | | |
| | | |
CNC POST TE-topo | POST /nw:networks/nw:network/ | CNC POST TE Topo | POST /nw:networks/nw:network/ |
model(with Conn. | nw:node/te-node-id/tet:connectivity- | model (w/ Conn. | nw:node/te-node-id/tet:connectivity- |
Matrix on one | matrices/tet:connectivity-matrix | Matrix on one | matrices/tet:connectivity-matrix |
Abstract node and|---------------------------------------->| abstract node and|---------------------------------------->|
constraints in | | constraints in | |
the conn. matrix)| HTTP 200 | the conn. matrix)| HTTP 200 |
|<----------------------------------------| |<----------------------------------------|
| | | |
| | | |
CNC calls RPC to | RPC /vn-compute | CNC calls RPC to | RPC /vn compute |
compute the VN |---------------------------------------->| compute the VN |---------------------------------------->|
as per the | | as per the | |
refered TE-Topo | | referred TE-Topo | |
| | | |
| HTTP 200 (Computed VN) | | HTTP 200 (Computed VN) |
|<----------------------------------------| |<----------------------------------------|
| | | |
Figure 7: VN Compute Figure 9: VN Compute with Reference to TE Topology YANG Data Model
The VN compute RPC allows you to optionally include the constraints The VN compute RPC allows the optional inclusion of the constraints
and the optimization criteria at the VN as well as at the individual and the optimization criteria at the VN as well as at the individual
VN-member level. Thus, the RPC can be used independently to get the VN-member level. Thus, the RPC can be used independently to get the
computed VN result without creating an abstract topology first. computed VN result without creating an abstract topology first.
+--------+ +--------+ +--------+ +--------+
| CNC | | MDSC | | CNC | | MDSC |
+--------+ +--------+ +--------+ +--------+
| | | |
| | | |
CNC calls RPC to | RPC /vn-compute | CNC calls RPC to | RPC /vn compute |
compute the VN |---------------------------------------->| compute the VN |---------------------------------------->|
as per the | | as per the | |
constraints and | | constraints and | |
VN-members | | VN members | |
| HTTP 200 (Computed VN) | | HTTP 200 (Computed VN) |
|<----------------------------------------| |<----------------------------------------|
| | | |
Figure 8: VN Compute Figure 10: VN Compute
In either case the output includes a reference to the single node Regardless of whether the TE Topology model is referenced, the RPC
abstract topology with each VN-member including a reference to the output includes a reference to the single node abstract topology with
connectivity-matrix-id where the path properties could be found. each VN member including a reference to the connectivity-matrix-id
where the path properties could be found.
To achieve this the VN-compute RPC reuses the following common To achieve this, the VN compute RPC reuses the following common
groupings: groupings:
* te-types:generic-path-constraints: This is used optionally in the * te-types:generic-path-constraints: is used optionally in the RPC
RPC input at the VN and/or VN-member level. The VN-member level input at the VN-level and/or VN-member level. The VN-member level
overrides the VN-level data. This also overrides any constraints overrides the VN-level data including any constraints in the
in the referenced abstract node in the TE topology. referenced abstract node in the TE topology.
* te-types:generic-path-optimization: This is used optionally in the * te-types:generic-path-optimization: is used optionally in the RPC
RPC input at the VN and/or VN-member level. The VN-member level input at the VN-level and/or VN-member level. The VN-member level
overrides the VN-level data. This also overrides any optimization overrides the VN-level data including any optimization in the
in the referenced abstract node in the TE topology. referenced abstract node in the TE topology.
* vn-member: This identifies the VN member in both RPC input and * vn member: identifies the VN member in both RPC input and output.
output.
* vn-policy: This is used optionally in the RPC input to apply any * vn-policy: is used optionally in the RPC input to apply any VN-
VN level policies. level policies.
When MDSC receives this RPC it computes the VN based on the input When MDSC receives this RPC, it computes the VN based on the input
provided in the RPC call. This computation does not create a VN or provided in the RPC. This computation does not create a VN or
reserve any resources in the system, it simply computes the resulting reserve any resources in the system, it simply computes the resulting
VN based on information at the MDSC or in coordination with the CNC. VN based on information at the MDSC or in coordination with the CNC.
A single-node-abstract topology is used to convey the result of each A single node abstract topology is used to convey the result of each
VN member as a reference to the connectivity-matrix-id. In case of VN member as a reference to the connectivity-matrix-id. In case of
an error, the error information is included. an error, the error information is included.
rpcs: rpcs:
+---x vn-compute +---x vn-compute
+---w input +---w input
| +---w te-topology-identifier | +---w te-topology-identifier
| | +---w provider-id? te-global-id | | +---w provider-id? te-global-id
| | +---w client-id? te-global-id | | +---w client-id? te-global-id
| | +---w topology-id? te-topology-id | | +---w topology-id? te-topology-id
| +---w abstract-node? | +---w abstract-node?
| | -> /nw:networks/network/node/tet:te-node-id | | -> /nw:networks/network/node/tet:te-node-id
| +---w path-constraints | +---w path-constraints
| | +---w te-bandwidth | | +---w te-bandwidth
| | | +---w (technology)? | | | +---w (technology)?
| | | ... | | | ...
| | +---w link-protection? identityref | | +---w link-protection? identityref
| | +---w setup-priority? uint8 | | +---w setup-priority? uint8
| | +---w hold-priority? uint8 | | +---w hold-priority? uint8
| | +---w signaling-type? identityref | | +---w signaling-type? identityref
| | +---w path-metric-bounds | | +---w path-metric-bounds
| | | +---w path-metric-bound* [metric-type] | | | +---w path-metric-bound* [metric-type]
| | | ... | | | ...
| | +---w path-affinities-values | | +---w path-affinities-values
| | | +---w path-affinities-value* [usage] | | | +---w path-affinities-value* [usage]
| | | ... | | | ...
| | +---w path-affinity-names | | +---w path-affinity-names
| | | +---w path-affinity-name* [usage] | | | +---w path-affinity-name* [usage]
| | | ... | | | ...
| | +---w path-srlgs-lists | | +---w path-srlgs-lists
| | | +---w path-srlgs-list* [usage] | | | +---w path-srlgs-list* [usage]
| | | ... | | | ...
| | +---w path-srlgs-names | | +---w path-srlgs-names
| | | +---w path-srlgs-name* [usage] | | | +---w path-srlgs-name* [usage]
| | | ... | | | ...
| | +---w disjointness? te-path-disjointness | | +---w disjointness? te-path-disjointness
| +---w cos? te-types:te-ds-class | +---w cos? te-types:te-ds-class
| +---w optimizations | +---w optimizations
| | +---w (algorithm)? | | +---w (algorithm)?
| | +--:(metric) {path-optimization-metric}? | | +--:(metric) {path-optimization-metric}?
| | | ... | | | ...
| | +--:(objective-function) | | +--:(objective-function)
| | {path-optimization-objective-function}? | | {path-optimization-objective-function}?
| | ... | | ...
| +---w vn-member-list* [id] | +---w vn-member-list* [id]
| | +---w id vnm-id | | +---w id vnm-id
| | +---w src | | +---w src
| | | +---w ap? -> /access-point/ap/id | | | +---w ap? -> /access-point/ap/id
| | | +---w vn-ap-id? | | | +---w vn-ap-id?
| | | | -> /access-point/ap[id=current()/../ap]/vn-ap/id | | | | -> /access-point/ap[id=current()/../ap]/vn-ap/\
| | | +---w multi-src? boolean {multi-src-dest}? id
| | +---w dest | | | +---w multi-src? boolean {multi-src-dest}?
| | | +---w ap? -> /access-point/ap/id | | +---w dest
| | | +---w vn-ap-id? | | | +---w ap? -> /access-point/ap/id
| | | | -> /access-point/ap[id=current()/../ap]/vn-ap/id | | | +---w vn-ap-id?
| | | +---w multi-dest? boolean {multi-src-dest}? | | | | -> /access-point/ap[id=current()/../ap]/vn-ap/\
| | +---w connectivity-matrix-id? leafref id
| | +---w underlay | | | +---w multi-dest? boolean {multi-src-dest}?
| | +---w path-constraints | | +---w connectivity-matrix-id? leafref
| | | +---w te-bandwidth | | +---w underlay
| | | | ... | | +---w path-constraints
| | | +---w link-protection? identityref | | | +---w te-bandwidth
| | | +---w setup-priority? uint8 | | | | ...
| | | +---w hold-priority? uint8 | | | +---w link-protection? identityref
| | | +---w signaling-type? identityref | | | +---w setup-priority? uint8
| | | +---w path-metric-bounds | | | +---w hold-priority? uint8
| | | | ... | | | +---w signaling-type? identityref
| | | +---w path-affinities-values | | | +---w path-metric-bounds
| | | | ... | | | | ...
| | | +---w path-affinity-names | | | +---w path-affinities-values
| | | | ... | | | | ...
| | | +---w path-srlgs-lists | | | +---w path-affinity-names
| | | | ... | | | | ...
| | | +---w path-srlgs-names | | | +---w path-srlgs-lists
| | | | ... | | | | ...
| | | +---w disjointness? te-path-disjointness | | | +---w path-srlgs-names
| | +---w cos? te-types:te-ds-class | | | | ...
| | +---w optimizations | | | +---w disjointness? te-path-disjointness
| | +---w (algorithm)? | | +---w cos? te-types:te-ds-class
| | ... | | +---w optimizations
| +---w vn-level-diversity? te-types:te-path-disjointness | | +---w (algorithm)?
+--ro output | | ...
+--ro te-topology-identifier | +---w vn-level-diversity? te-types:te-path-\
| +--ro provider-id? te-global-id disjointness
| +--ro client-id? te-global-id +--ro output
| +--ro topology-id? te-topology-id +--ro te-topology-identifier
+--ro abstract-node? | +--ro provider-id? te-global-id
| -> /nw:networks/network/node/tet:te-node-id | +--ro client-id? te-global-id
+--ro vn-member-list* [id] | +--ro topology-id? te-topology-id
+--ro id vnm-id +--ro abstract-node?
+--ro src | -> /nw:networks/network/node/tet:te-node-id
| +--ro ap? -> /access-point/ap/id +--ro vn-member-list* [id]
| +--ro vn-ap-id? +--ro id vnm-id
| | -> /access-point/ap[id=current()/../ap]/vn-ap/id +--ro src
| +--ro multi-src? boolean {multi-src-dest}? | +--ro ap? -> /access-point/ap/id
+--ro dest | +--ro vn-ap-id?
| +--ro ap? -> /access-point/ap/id | | -> /access-point/ap[id=current()/../ap]/vn-ap/\
| +--ro vn-ap-id? id
| | -> /access-point/ap[id=current()/../ap]/vn-ap/id | +--ro multi-src? boolean {multi-src-dest}?
| +--ro multi-dest? boolean {multi-src-dest}? +--ro dest
+--ro connectivity-matrix-id? leafref | +--ro ap? -> /access-point/ap/id
+--ro underlay | +--ro vn-ap-id?
+--ro if-selected? boolean {multi-src-dest}? | | -> /access-point/ap[id=current()/../ap]/vn-ap/\
+--ro compute-status? vn-compute-status id
+--ro error-info | +--ro multi-dest? boolean {multi-src-dest}?
+--ro error-description? string +--ro connectivity-matrix-id? leafref
+--ro error-timestamp? yang:date-and-time +--ro underlay
+--ro error-reason? identityref +--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? identityref
4.3.2. Multi-sources and Multi-destinations 4.3.2. Multiple Sources and Multiple Destinations
In creating a virtual network, the list of sources or destinations or In creating a VN, the list of sources or destinations or both may not
both may not be pre-determined by the customer. For instance, for a be predetermined by the customer. For instance, for a given source,
given source, there may be a list of multiple-destinations to which there may be a list of multiple destinations to which the optimal
the optimal destination may be chosen depending on the network destination may be chosen depending on the network resource
resource situations. Likewise, for a given destination, there may situations. Likewise, for a given destination, there may also be
also be multiple-sources from which the optimal source may be chosen. multiple sources from which the optimal source may be chosen. In
In some cases, there may be a pool of multiple sources and some cases, there may be a pool of multiple sources and destinations
destinations from which the optimal source-destination may be chosen. from which the optimal source-destination may be chosen. The
The following YANG tree shows how to model multi-sources and multi- following YANG tree shows how to model multiple sources and multiple
destinations. destinations.
module: ietf-vn module: ietf-vn
+--rw virtual-network +--rw virtual-network
+--rw vn* [id] +--rw vn* [id]
+--rw id vn-id +--rw id vn-id
+--rw te-topology-identifier +--rw te-topology-identifier
| +--rw provider-id? te-global-id | +--rw provider-id? te-global-id
| +--rw client-id? te-global-id | +--rw client-id? te-global-id
| +--rw topology-id? te-topology-id | +--rw topology-id? te-topology-id
+--rw abstract-node? +--rw abstract-node?
| -> /nw:networks/network/node/tet:te-node-id | -> /nw:networks/network/node/tet:te-node-id
+--rw vn-member* [id] +--rw vn-member* [id]
| +--rw id vnm-id | +--rw id vnm-id
| +--rw src | +--rw src
| | +--rw ap? -> /access-point/ap/id | | +--rw ap? -> /access-point/ap/id
| | +--rw vn-ap-id? | | +--rw vn-ap-id?
| | | -> /access-point/ap[id=current()/../ap]/vn-ap/id | | | -> /access-point/ap[id=current()/../ap]/vn-ap/\
| | +--rw multi-src? boolean {multi-src-dest}? id
| +--rw dest | | +--rw multi-src? boolean {multi-src-dest}?
| | +--rw ap? -> /access-point/ap/id | +--rw dest
| | +--rw vn-ap-id? | | +--rw ap? -> /access-point/ap/id
| | | -> /access-point/ap[id=current()/../ap]/vn-ap/id | | +--rw vn-ap-id?
| | +--rw multi-dest? boolean {multi-src-dest}? | | | -> /access-point/ap[id=current()/../ap]/vn-ap/\
| +--rw connectivity-matrix-id? leafref id
| +--rw underlay | | +--rw multi-dest? boolean {multi-src-dest}?
| +--ro oper-status? te-types:te-oper-status | +--rw connectivity-matrix-id? leafref
| +--ro if-selected? boolean {multi-src-dest}? | +--rw underlay
+--rw admin-status? te-types:te-admin-status | +--ro oper-status? te-types:te-oper-status
+--ro oper-status? te-types:te-oper-status | +--ro if-selected? boolean {multi-src-dest}?
+--rw vn-level-diversity? te-types:te-path-disjointness +--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
4.4. Others 4.4. Others
The VN YANG model can be easily augmented to support the mapping of The VN YANG data model can easily be augmented to support the mapping
VN to the Services such as L3SM and L2SM as described in of VN to the services such as L3SM and L2SM as described in
[I-D.ietf-teas-te-service-mapping-yang]. [TE-SERVICE-MAPPING].
The VN YANG model can be extended to support telemetry, performance The VN YANG data model can be extended to support telemetry,
monitoring and network autonomics as described in performance monitoring, and network autonomics as described in
[I-D.ietf-teas-actn-pm-telemetry-autonomics]. [TEAS-ACTN-PM].
Note that the YANG model is tightly coupled with the TE Topology Note that the VN YANG data model is tightly coupled with the TE
model [RFC8795]. Any underlay technology not supported by [RFC8795] Topology model [RFC8795]. Any underlay technology not supported by
is also not supported by this model. The model does include an empty the TE Topology model in [RFC8795] is also not supported by the VN
container called "underlay" that can be augmented. For example the model. However, the VN model does include an empty container called
Segment Routing (SR) Policy [RFC9256] information can be augmented "underlay" that can be augmented. For example, the Segment Routing
for the SR underlay by a future model. (SR) Policy [RFC9256] information can be augmented for the SR
underlay by a future model.
Apart from the te-types:generic-path-constraints and te- Apart from the te-types:generic-path-constraints and te-
types:generic-path-optimization, an additional leaf cos for the class types:generic-path-optimization, an additional leaf called "cos" for
of service [RFC4124] is added to represent the Class-Type of traffic the class of service is added to represent the Class-Type of traffic
to be used as one of the path constraints. [RFC4124] to be used as one of the path constraints.
4.5. Summary 4.5. Summary
This section summarizes the features of the VN YANG. This section summarizes the features of the VN YANG data model.
* Maintenance of AP and VNAP along with VN * Maintenance of APs and VNAPs along with the VN
* VN construct to group of edge-to-edge links * VN construct to group of edge-to-edge links
* Ability to support various VN and VNS Types * Ability to support various VN and VNS types
- VN Type 1: Customer configures the VN as a set of VN Members. - 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 No other details need to be set by the customer, making for a
simplified operation for the customer. simplified operation for the customer.
- VN Type 2: Along with VN Members, the customer could also - VN Type 2: Along with VN members, the customer could also
provide an abstract topology, this topology is provided by the provide an abstract topology, this topology is provided by the
Abstract TE Topology YANG Model. Abstract TE Topology YANG data model.
- Note that the VN Type is not explicitly identified in the VN o Note that the VN type is not explicitly identified in the VN
Yang model, as the VN Model is exactly the same for both VN YANG data model, as the VN YANG data model is exactly the
Type 1 and 2. The VN type can be implicitly known based on the same for both VN Type 1 and VN Type 2. The VN type can be
referenced TE topology and whether the connectivity matrix implicitly known based on the referenced TE topology and
includes the underlay path (Type 2) or not (Type 1). whether the connectivity matrix includes the underlay path
(Type 2) or not (Type 1).
* VN Compute (pre-instantiate) * VN Compute (pre-instantiate)
* Multi-Source / Multi-Destination * Multi-Source / Multi-Destination
5. VN YANG Model (Tree Structure) 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: module: ietf-vn
+---x vn-compute +--rw access-point
+---w input | +--rw ap* [id]
| +---w te-topology-identifier | +--rw id ap-id
| | +---w provider-id? te-global-id | +--rw pe?
| | +---w client-id? te-global-id | | -> /nw:networks/network/node/tet:te-node-id
| | +---w topology-id? te-topology-id | +--rw max-bandwidth? te-types:te-bandwidth
| +---w abstract-node? | +--rw avl-bandwidth? te-types:te-bandwidth
| | -> /nw:networks/network/node/tet:te-node-id | +--rw vn-ap* [id]
| +---w path-constraints | +--rw id ap-id
| | +---w te-bandwidth | +--rw vn? -> /virtual-network/vn/id
| | | +---w (technology)? | +--rw abstract-node? -> /nw:networks/network/node/\
| | | ... node-id
| | +---w link-protection? identityref | +--rw ltp? leafref
| | +---w setup-priority? uint8 | +--ro max-bandwidth? te-types:te-bandwidth
| | +---w hold-priority? uint8 +--rw virtual-network
| | +---w signaling-type? identityref +--rw vn* [id]
| | +---w path-metric-bounds +--rw id vn-id
| | | +---w path-metric-bound* [metric-type] +--rw te-topology-identifier
| | | ... | +--rw provider-id? te-global-id
| | +---w path-affinities-values | +--rw client-id? te-global-id
| | | +---w path-affinities-value* [usage] | +--rw topology-id? te-topology-id
| | | ... +--rw abstract-node?
| | +---w path-affinity-names | -> /nw:networks/network/node/tet:te-node-id
| | | +---w path-affinity-name* [usage] +--rw vn-member* [id]
| | | ... | +--rw id vnm-id
| | +---w path-srlgs-lists | +--rw src
| | | +---w path-srlgs-list* [usage] | | +--rw ap? -> /access-point/ap/id
| | | ... | | +--rw vn-ap-id?
| | +---w path-srlgs-names | | | -> /access-point/ap[id=current()/../ap]/\
| | | +---w path-srlgs-name* [usage] vn-ap/id
| | | ... | | +--rw multi-src? boolean {multi-src-dest}?
| | +---w disjointness? te-path-disjointness | +--rw dest
| +---w cos? te-types:te-ds-class | | +--rw ap? -> /access-point/ap/id
| +---w optimizations | | +--rw vn-ap-id?
| | +---w (algorithm)? | | | -> /access-point/ap[id=current()/../ap]/\
| | +--:(metric) {path-optimization-metric}? vn-ap/id
| | | ... | | +--rw multi-dest? boolean {multi-src-dest}?
| | +--:(objective-function) | +--rw connectivity-matrix-id? leafref
| | {path-optimization-objective-function}? | +--rw underlay
| | ... | +--ro oper-status? te-types:te-oper-status
| +---w vn-member-list* [id] | +--ro if-selected? boolean {multi-src-dest}?
| | +---w id vnm-id +--rw admin-status? te-types:te-admin-status
| | +---w src +--ro oper-status? te-types:te-oper-status
| | | +---w ap? -> /access-point/ap/id +--rw vn-level-diversity? te-types:te-path-disjointness
| | | +---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 rpcs:
| | | | ... +---x vn-compute
| | | +---w path-srlgs-lists +---w input
| | | | ... | +---w te-topology-identifier
| | | +---w path-srlgs-names | | +---w provider-id? te-global-id
| | | | ... | | +---w client-id? te-global-id
| | | +---w disjointness? te-path-disjointness | | +---w topology-id? te-topology-id
| | +---w cos? te-types:te-ds-class | +---w abstract-node?
| | +---w optimizations | | -> /nw:networks/network/node/tet:te-node-id
| | +---w (algorithm)? | +---w path-constraints
| | ... | | +---w te-bandwidth
| +---w vn-level-diversity? te-types:te-path-disjointness | | | +---w (technology)?
+--ro output | | | ...
+--ro te-topology-identifier | | +---w link-protection? identityref
| +--ro provider-id? te-global-id | | +---w setup-priority? uint8
| +--ro client-id? te-global-id | | +---w hold-priority? uint8
| +--ro topology-id? te-topology-id | | +---w signaling-type? identityref
+--ro abstract-node? | | +---w path-metric-bounds
| -> /nw:networks/network/node/tet:te-node-id | | | +---w path-metric-bound* [metric-type]
+--ro vn-member-list* [id] | | | ...
+--ro id vnm-id | | +---w path-affinities-values
+--ro src | | | +---w path-affinities-value* [usage]
| +--ro ap? -> /access-point/ap/id | | | ...
| +--ro vn-ap-id? | | +---w path-affinity-names
| | -> /access-point/ap[id=current()/../ap]/vn-ap/id | | | +---w path-affinity-name* [usage]
| +--ro multi-src? boolean {multi-src-dest}? | | | ...
+--ro dest | | +---w path-srlgs-lists
| +--ro ap? -> /access-point/ap/id | | | +---w path-srlgs-list* [usage]
| +--ro vn-ap-id? | | | ...
| | -> /access-point/ap[id=current()/../ap]/vn-ap/id | | +---w path-srlgs-names
| +--ro multi-dest? boolean {multi-src-dest}? | | | +---w path-srlgs-name* [usage]
+--ro connectivity-matrix-id? leafref | | | ...
+--ro underlay | | +---w disjointness? te-path-disjointness
+--ro if-selected? boolean {multi-src-dest}? | +---w cos? te-types:te-ds-class
+--ro compute-status? vn-compute-status | +---w optimizations
+--ro error-info | | +---w (algorithm)?
+--ro error-description? string | | +--:(metric) {path-optimization-metric}?
+--ro error-timestamp? yang:date-and-time | | | ...
+--ro error-reason? identityref | | +--:(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? identityref
6. VN YANG Model 6. VN YANG Data Model
The YANG model is as follows: The VN YANG data model is as follows:
<CODE BEGINS> file "ietf-vn@2024-06-22.yang" <CODE BEGINS> file "ietf-vn@2025-02-18.yang"
module ietf-vn { module ietf-vn {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-vn"; namespace "urn:ietf:params:xml:ns:yang:ietf-vn";
prefix vn; prefix vn;
/* Import common YANG types */ /* Import common YANG types */
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
reference reference
skipping to change at page 23, line 49 skipping to change at line 1029
reference reference
"RFC 8776: Common YANG Data Types for Traffic Engineering"; "RFC 8776: Common YANG Data Types for Traffic Engineering";
} }
/* Import TE Topology */ /* Import TE Topology */
import ietf-te-topology { import ietf-te-topology {
prefix tet; prefix tet;
reference reference
"RFC 8795: YANG Data Model for Traffic Engineering (TE) "RFC 8795: YANG Data Model for Traffic Engineering (TE)
Topologies"; Topologies";
} }
organization organization
"IETF Traffic Engineering Architecture and Signaling (TEAS) "IETF Traffic Engineering Architecture and Signaling (TEAS)
Working Group"; Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/teas/> "WG Web: <https://datatracker.ietf.org/wg/teas/>
WG List: <mailto:teas@ietf.org> WG List: <mailto:teas@ietf.org>
Editor: Young Lee <younglee.tx@gmail.com>
: Dhruv Dhody <dhruv.ietf@gmail.com>"; Editor: Young Lee <younglee.tx@gmail.com>
Editor: Dhruv Dhody <dhruv.ietf@gmail.com>";
description description
"This module contains a YANG module for the Virtual Network "This YANG module for the Virtual Network (VN).
(VN). It describes a VN operation module that can take place It describes a VN operation module that can take place
in the context of the Customer Network Controller (CNC)- in the context of the Customer Network Controller (CNC) -
Multi-Domain Service Coordinator (MDSC) interface (CMI) of Multi-Domain Service Coordinator (MDSC) interface (CMI) of
the Abstraction and Control of Traffic Engineered (TE) the Abstraction and Control of TE Networks (ACTN)
Networks (ACTN) architecture where the CNC is the actor of architecture where the CNC is the actor of a VN
a VN Instantiation/modification/deletion as per RFC 8453. instantiation/modification/deletion as per RFC 8453.
This module uses following abbreviations:
- VN: Virtual Network
- AP: Access Point
- VNAP: Virtual Network Access Point
- LTP: Link Termination Point
- PE: Provider Edge
- COS: Class of Service
Further, 'src' and 'dest' is used for source and destination
respectively.
Copyright (c) 2024 IETF Trust and the persons identified as Copyright (c) 2025 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the This version of this YANG module is part of RFC 9731; see the
RFC itself for full legal notices."; RFC itself for full legal notices.";
revision 2024-06-22 { revision 2025-02-18 {
description description
"The initial version."; "The initial version.";
reference reference
"RFC XXXX: A YANG Data Model for Virtual Network (VN) "RFC 9731: A YANG Data Model for Virtual Network (VN)
Operations"; Operations";
} }
/* Features */ /* Features */
feature multi-src-dest { feature multi-src-dest {
description description
"Support for selection of one src or destination "Support for selection of one source or destination
among multiple."; among multiple.";
reference reference
"RFC 8453: Framework for Abstraction and Control of TE "RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN)"; Networks (ACTN)";
} }
/* Typedef */ /* Typedef */
typedef vn-id { typedef vn-id {
type string { type string {
length "1..max"; length "1..max";
} }
description description
"A type definition for Virtual Network (VN) "A type definition for a VN identifier.";
identifier.";
} }
typedef ap-id { typedef ap-id {
type string { type string {
length "1..max"; length "1..max";
} }
description description
"A type definition for Access Point (AP) identifier."; "A type definition for an Access Point (AP) identifier.";
} }
typedef vnm-id { typedef vnm-id {
type string { type string {
length "1..max"; length "1..max";
} }
description description
"A type definition for VN member identifier."; "A type definition for a VN-member identifier.";
} }
typedef vn-compute-status { typedef vn-compute-status {
type te-types:te-common-status; type te-types:te-common-status;
description description
"A type definition for representing the VN compute status. Note "A type definition for representing the VN compute status.
that all statuses apart from up and down are considered as Note that all statuses apart from up and down are considered
unknown."; to be unknown.";
} }
/* identities */ /* identities */
identity vn-computation-error-reason { identity vn-computation-error-reason {
description description
"Base identity for VN computation error reasons."; "Base identity for VN computation error reasons.";
} }
identity vn-computation-error-not-ready { identity vn-computation-error-not-ready {
base vn-computation-error-reason; base vn-computation-error-reason;
description description
"VN computation has failed because the MDSC is not "VN computation has failed because the MDSC is not
ready."; ready.";
} }
identity vn-computation-error-no-cnc { identity vn-computation-error-no-cnc {
base vn-computation-error-reason; base vn-computation-error-reason;
description description
"VN computation has failed because one or more dependent "VN computation has failed because one or more dependent
CNC are unavailable."; CNCs are unavailable.";
} }
identity vn-computation-error-no-resource { identity vn-computation-error-no-resource {
base vn-computation-error-reason; base vn-computation-error-reason;
description description
"VN computation has failed because there is no "VN computation has failed because there is no
available resource in one or more domains."; available resource in one or more domains.";
} }
identity vn-computation-error-path-not-found { identity vn-computation-error-path-not-found {
skipping to change at page 27, line 4 skipping to change at line 1166
/* Groupings */ /* Groupings */
grouping vn-member { grouping vn-member {
description description
"The vn-member is described by this grouping."; "The vn-member is described by this grouping.";
leaf id { leaf id {
type vnm-id; type vnm-id;
description description
"A vn-member identifier."; "A vn-member identifier.";
} }
container src { container src {
description description
"The source of VN Member."; "The source of VN member.";
leaf ap { leaf ap {
type leafref { type leafref {
path "/access-point/ap/id"; path "/access-point/ap/id";
} }
description description
"A reference to source AP."; "A reference to the source AP.";
} }
leaf vn-ap-id { leaf vn-ap-id {
type leafref { type leafref {
path "/access-point/ap[id=current()/../ap]/vn-ap" path "/access-point/ap[id=current()/../ap]/vn-ap"
+ "/id"; + "/id";
} }
description description
"A reference to source VNAP."; "A reference to the source VNAP.";
} }
leaf multi-src { leaf multi-src {
if-feature "multi-src-dest"; if-feature "multi-src-dest";
type boolean; type boolean;
default "false"; default "false";
description description
"Is the source part of multi-source, where "Is the source part of a multi-source, where
only one of the sources is enabled."; only one of the sources is enabled?";
} }
} }
container dest { container dest {
description description
"the destination of VN Member."; "The destination of the VN member.";
leaf ap { leaf ap {
type leafref { type leafref {
path "/access-point/ap/id"; path "/access-point/ap/id";
} }
description description
"A reference to destination AP."; "A reference to the destination AP.";
} }
leaf vn-ap-id { leaf vn-ap-id {
type leafref { type leafref {
path "/access-point/ap[id=current()/../ap]/" path "/access-point/ap[id=current()/../ap]/"
+ "vn-ap/id"; + "vn-ap/id";
} }
description description
"A reference to dest VNAP."; "A reference to the destination VNAP.";
} }
leaf multi-dest { leaf multi-dest {
if-feature "multi-src-dest"; if-feature "multi-src-dest";
type boolean; type boolean;
default "false"; default "false";
description description
"Is destination part of multi-destination, where only one "Is the destination part of a multi-destination,
of the destinations is enabled."; where only one of the destinations is enabled.";
} }
} }
leaf connectivity-matrix-id { leaf connectivity-matrix-id {
type leafref { type leafref {
path "/nw:networks/nw:network/nw:node/tet:te/" path "/nw:networks/nw:network/nw:node/tet:te/"
+ "tet:te-node-attributes/" + "tet:te-node-attributes/"
+ "tet:connectivity-matrices/" + "tet:connectivity-matrices/"
+ "tet:connectivity-matrix/tet:id"; + "tet:connectivity-matrix/tet:id";
} }
description description
"A reference to connectivity-matrix."; "A reference to the connectivity-matrix.";
reference reference
"RFC 8795: YANG Data Model for Traffic Engineering (TE) "RFC 8795: YANG Data Model for Traffic Engineering (TE)
Topologies"; Topologies";
} }
container underlay { container underlay {
description description
"An empty container that can be augmented with underlay "An empty container that can be augmented with underlay
technology information not supported by RFC 8795 (for technology information not supported by RFC 8795 (for
example - Segment Routing (SR)."; example, Segment Routing (SR).";
} }
reference reference
"RFC 8454: Information Model for Abstraction and Control of TE "RFC 8454: Information Model for Abstraction and Control of TE
Networks (ACTN)"; Networks (ACTN)
RFC 8795: YANG Data Model for Traffic Engineering (TE)
Topologies";
} }
grouping vn-policy { grouping vn-policy {
description description
"policy for VN-level diversity"; "policy for VN-level diversity";
leaf vn-level-diversity { leaf vn-level-diversity {
type te-types:te-path-disjointness; type te-types:te-path-disjointness;
description description
"The type of disjointness on the VN level (i.e., across all "The type of disjointness on the VN level (i.e., across all
VN members)."; VN members).";
} }
} }
/* Configuration data nodes */ /* Configuration data nodes */
container access-point { container access-point {
description description
"AP configurations"; "AP configurations.";
list ap { list ap {
key "id"; key "id";
description description
"access-point identifier."; "The access-point identifier.";
leaf id { leaf id {
type ap-id; type ap-id;
description description
"An AP identifier unique within the scope of the entity "An AP identifier unique within the scope of the entity
that controls the VN."; that controls the VN.";
} }
leaf pe { leaf pe {
type leafref { type leafref {
path "/nw:networks/nw:network/nw:node/tet:te-node-id"; path "/nw:networks/nw:network/nw:node/tet:te-node-id";
} }
skipping to change at page 30, line 7 skipping to change at line 1315
type leafref { type leafref {
path "/nw:networks/nw:network/nw:node/nw:node-id"; path "/nw:networks/nw:network/nw:node/nw:node-id";
} }
must '/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' { + 'current()/../abstract-node]/tet:te-node-id' {
description description
"The associated network for the abstract-node "The associated network for the abstract-node
must be TE enabled."; must be TE enabled.";
} }
description description
"A reference to the abstract node that represent "A reference to the abstract node that represents
the VN."; the VN.";
} }
leaf ltp { leaf ltp {
type leafref { type leafref {
path "/nw:networks/nw:network/nw:node[nw:node-id=" path "/nw:networks/nw:network/nw:node[nw:node-id="
+ "current()/../abstract-node]/nt:termination-point/" + "current()/../abstract-node]/nt:termination-point/"
+ "tet:te-tp-id"; + "tet:te-tp-id";
} }
description description
"A reference to Link Termination Point (LTP) in the "A reference to the Link Termination Point (LTP)
abstract-node i.e. the LTP should be in the abstract in the abstract-node, i.e., the LTP should be in
layer, and not the underlying layer."; the abstract layer and not the underlying layer.";
reference reference
"RFC 8795: YANG Data Model for Traffic Engineering (TE) "RFC 8795: YANG Data Model for Traffic Engineering (TE)
Topologies"; Topologies";
} }
leaf max-bandwidth { leaf max-bandwidth {
type te-types:te-bandwidth; type te-types:te-bandwidth;
config false; config false;
description description
"The max bandwidth of the VNAP."; "The max bandwidth of the VNAP.";
} }
description description
"List of VNAP in this AP."; "List of VNAPs in this AP.";
} }
} }
reference reference
"RFC 8453: Framework for Abstraction and Control of TE "RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN), Section 6"; Networks (ACTN), Section 6";
} }
container virtual-network { container virtual-network {
description description
"VN configurations."; "VN configurations.";
list vn { list vn {
key "id"; key "id";
description description
"A virtual network is identified by a vn-id."; "A VN is identified by a vn-id.";
leaf id { leaf id {
type vn-id; type vn-id;
description description
"An identifier unique within the scope of the entity "An identifier unique within the scope of the entity
that controls the VN."; that controls the VN.";
} }
uses te-types:te-topology-identifier; uses te-types:te-topology-identifier;
leaf abstract-node { leaf abstract-node {
type leafref { type leafref {
path "/nw:networks/nw:network/nw:node/tet:te-node-id"; path "/nw:networks/nw:network/nw:node/tet:te-node-id";
skipping to change at page 31, line 28 skipping to change at line 1384
config false; config false;
description description
"The vn-member operational state."; "The vn-member operational state.";
} }
leaf if-selected { leaf if-selected {
if-feature "multi-src-dest"; if-feature "multi-src-dest";
type boolean; type boolean;
default "false"; default "false";
config false; config false;
description description
"Is the vn-member selected among the multi-src/dest "Is the vn-member selected among the multi-source
options."; or multi-destination options?";
} }
} }
leaf admin-status { leaf admin-status {
type te-types:te-admin-status; type te-types:te-admin-status;
default "up"; default "up";
description description
"VN administrative state."; "VN administrative state.";
} }
leaf oper-status { leaf oper-status {
type te-types:te-oper-status; type te-types:te-oper-status;
skipping to change at page 32, line 4 skipping to change at line 1408
"VN operational state."; "VN operational state.";
} }
uses vn-policy; uses vn-policy;
} }
reference reference
"RFC 8453: Framework for Abstraction and Control of TE "RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN)"; Networks (ACTN)";
} }
/* RPC */ /* RPC */
rpc vn-compute { rpc vn-compute {
description description
"The VN computation without actual instantiation. This is "The VN computation without actual instantiation. This is
used by the CNC to get the VN results without actually used by the CNC to get the VN results without actually
creating it in the network. creating it in the network.
The input could include a reference to the single-node The input could include a reference to the single node
-abstract topology. It could optionally also include abstract topology. It could optionally also include
constraints and optimization criteria. The computation constraints and optimization criteria. The computation
is done based on the list of VN-members. is done based on the list of VN members.
The output includes a reference to the single-node The output includes a reference to the single node
-abstract topology with each VN-member including a abstract topology with each VN member including a
reference to the connectivity-matrix-id where the reference to the connectivity-matrix-id where the
path properties could be found. Error information is path properties could be found. Error information is
also included."; also included.";
input { input {
uses te-types:te-topology-identifier; uses te-types:te-topology-identifier;
leaf abstract-node { leaf abstract-node {
type leafref { type leafref {
path "/nw:networks/nw:network/nw:node/tet:te-node-id"; path "/nw:networks/nw:network/nw:node/tet:te-node-id";
} }
description description
"A reference to the abstract node in TE Topology."; "A reference to the abstract node in TE Topology.";
} }
uses te-types:generic-path-constraints; uses te-types:generic-path-constraints;
leaf cos { leaf cos {
type te-types:te-ds-class; type te-types:te-ds-class;
description description
"The class of service (COS)."; "The class of service (COS).";
} }
uses te-types:generic-path-optimization; uses te-types:generic-path-optimization;
list vn-member-list { list vn-member-list {
key "id"; key "id";
description description
"List of VN-members in a VN."; "List of VN members in a VN.";
uses vn-member; uses vn-member;
uses te-types:generic-path-constraints; uses te-types:generic-path-constraints;
leaf cos { leaf cos {
type te-types:te-ds-class; type te-types:te-ds-class;
description description
"The class of service."; "The class of service.";
reference reference
"RFC 4124: Protocol Extensions for Support of "RFC 4124: Protocol Extensions for Support of
Diffserv-aware MPLS Traffic Engineering, Diffserv-aware MPLS Traffic Engineering,
Section 4.3.1"; Section 4.3.1";
skipping to change at page 33, line 4 skipping to change at line 1457
leaf cos { leaf cos {
type te-types:te-ds-class; type te-types:te-ds-class;
description description
"The class of service."; "The class of service.";
reference reference
"RFC 4124: Protocol Extensions for Support of "RFC 4124: Protocol Extensions for Support of
Diffserv-aware MPLS Traffic Engineering, Diffserv-aware MPLS Traffic Engineering,
Section 4.3.1"; Section 4.3.1";
} }
uses te-types:generic-path-optimization; uses te-types:generic-path-optimization;
} }
uses vn-policy; uses vn-policy;
} }
output { output {
uses te-types:te-topology-identifier; uses te-types:te-topology-identifier;
leaf abstract-node { leaf abstract-node {
type leafref { type leafref {
path "/nw:networks/nw:network/nw:node/tet:te-node-id"; path "/nw:networks/nw:network/nw:node/tet:te-node-id";
} }
description description
"A reference to the abstract node in TE Topology."; "A reference to the abstract node in TE Topology.";
} }
list vn-member-list { list vn-member-list {
key "id"; key "id";
description description
"List of VN-members in a VN."; "List of VN members in a VN.";
uses vn-member; uses vn-member;
leaf if-selected { leaf if-selected {
if-feature "multi-src-dest"; if-feature "multi-src-dest";
type boolean; type boolean;
default "false"; default "false";
description description
"Is the vn-member selected among the multi-src/dest "Is the vn-member selected among the multi-source or
options."; multi-destination options?";
reference reference
"RFC 8453: Framework for Abstraction and Control of TE "RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN), Section 7"; Networks (ACTN), Section 7";
} }
leaf compute-status { leaf compute-status {
type vn-compute-status; type vn-compute-status;
description description
"The VN-member compute state."; "The VN-member compute state.";
} }
container error-info { container error-info {
description description
"Error information related to the VN member."; "Error information related to the VN member.";
leaf error-description { leaf error-description {
type string { type string {
length "1..max"; length "1..max";
} }
description description
"Textual representation of the error occurred during "Textual representation of the error that occurred
VN compute."; during VN compute.";
} }
leaf error-timestamp { leaf error-timestamp {
type yang:date-and-time; type yang:date-and-time;
description description
"Timestamp of the attempt."; "Timestamp of the attempt.";
} }
leaf error-reason { leaf error-reason {
type identityref { type identityref {
base vn-computation-error-reason; base vn-computation-error-reason;
} }
description description
"Reason for the VN computation error."; "Reason for the VN computation error.";
} }
} }
} }
skipping to change at page 34, line 30 skipping to change at line 1530
7. Security Considerations 7. Security Considerations
The YANG module specified in this document defines a schema for data The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC8446]. [RFC8446].
The NETCONF access control model [RFC8341] provides the means to The Network Configuration Access Control Model (NACM) [RFC8341]
restrict access for particular NETCONF or RESTCONF users to a provides the means to restrict access for particular NETCONF or
preconfigured subset of all available NETCONF or RESTCONF protocol RESTCONF users to a preconfigured subset of all available NETCONF or
operations and content. RESTCONF protocol operations and content.
The model presented in this document is used in the interface between The model presented in this document is used in the interface between
the CNC and MDSC, which is referred to as CNC-MDSC Interface (CMI). the CNC and MDSC, which is referred to as CNC-MDSC Interface (CMI).
Security risks such as malicious attack and rogue elements attempting Security risks, such as malicious attack and rogue elements
to connect to the various ACTN components are possible. Furthermore, attempting to connect to the various ACTN components, are possible.
some ACTN components (e.g., MDSC) represent a single point of failure Furthermore, some ACTN components (e.g., MDSC) represent a single
and threat vector. Also, there is a need to manage policy conflicts point of failure and threat vector. Also, there is a need to manage
and eavesdropping of communication between different ACTN components. policy conflicts and eavesdropping on communication between different
ACTN components.
There are a number of data nodes defined in this YANG module that are There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., "config true", which is the writable/creatable/deletable (i.e., "config true", which is the
default). These data nodes may be considered sensitive or vulnerable default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config) in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability: and their sensitivity/vulnerability:
* ap: This list includes a set of sensitive data that influences how * ap: This list includes a set of sensitive data that influences how
the access points in the VN service are attached. By accessing the APs in the VN service are attached. By accessing the
the following data nodes, an attacker may be able to manipulate following data nodes, an attacker may be able to manipulate the
the VN. VN.
- id - id
- pe - pe
- max-bandwidth - max-bandwidth
- avl-bandwidth - avl-bandwidth
* vn-ap: This list includes a set of sensitive data that influences * vn-ap: This list includes a set of sensitive data that influences
skipping to change at page 36, line 4 skipping to change at line 1599
* vn-member: This list includes a set of sensitive data that * vn-member: This list includes a set of sensitive data that
influences how the VN member in the VN service is delivered. By influences how the VN member in the VN service is delivered. By
accessing the following data nodes, an attacker may be able to accessing the following data nodes, an attacker may be able to
manipulate the VN member. manipulate the VN member.
- id - id
- src/ap - src/ap
- src/vn-ap-id - src/vn-ap-id
- dest/ap - dest/ap
- dest/vn-ap-id - dest/vn-ap-id
- connectivity-matrix-id - connectivity-matrix-id
Some of the readable data nodes in this YANG module may be considered Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or important to control read access (e.g., via get, get-config, or
notification) to these data nodes. These are the subtrees and data notification) to these data nodes. These are the subtrees and data
nodes and their sensitivity/vulnerability: nodes and their sensitivity/vulnerability:
* oper-status: This leaf can reveal the current operational state of * oper-status: This leaf can reveal the current operational state of
the VN. the VN.
* if-selected: This leaf can reveal which vn-member is selected * if-selected: This leaf can reveal which vn-member is selected
among the various multi-src/dest options. among the various multi-source / multi-destination options.
Some of the RPC operations in this YANG module may be considered Some of the RPC operations in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus sensitive or vulnerable in some network environments. It is thus
important to control access to these operations. These are the important to control access to these operations. These are the
operations and their sensitivity/vulnerability: operations and their sensitivity/vulnerability:
* vn-compute: This RPC triggers the VN computation at the MDSC which * vn-compute: This RPC triggers the VN computation at the MDSC,
can reveal the VN information. which can reveal the VN information.
8. IANA Considerations 8. IANA Considerations
IANA is requested to make the following allocation for the URIs in IANA has made the following allocation for a URI in the "ns" registry
the "ns" subregistry within the "IETF XML Registry" [RFC3688]: 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.
IANA is requested to make the following allocation for the YANG
module in the "YANG Module Names" registry [RFC6020]:
name: ietf-vn
namespace: urn:ietf:params:xml:ns:yang:ietf-vn
prefix: vn
reference: RFC XXXX
9. Acknowledgments
The authors would like to thank Xufeng Liu, Adrian Farrel, Tom Petch, URI: urn:ietf:params:xml:ns:yang:ietf-vn
Mohamed Boucadair, Italo Busi, Bo Wu and Daniel King for their Registrant Contact: The IESG.
helpful comments and valuable suggestions. XML: N/A, the requested URI is an XML namespace.
Thanks to Andy Bierman for YANGDIR review. Thanks to Darren Dukes IANA has made the following allocation for the VN YANG data model
for RTGDIR review. Thanks to Behcet Sarikaya for GENART review. (see Section 5 in the "YANG Module Names" registry [RFC6020]:
Thanks to Bo Wu for OPSDIR review. Thanks to Shivan Sahib for SECDIR
review. Thanks to Susan Hares for RTGDIR review.
Thanks to Deb Cooley, Francesca Palombini, Gunter Van de Velde, and name: ietf-vn
Mahesh Jethanandani for IESG review. namespace: urn:ietf:params:xml:ns:yang:ietf-vn
prefix: vn
reference: RFC 9731
10. References 9. References
10.1. Normative References 9.1. Normative References
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of [RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of
Diffserv-aware MPLS Traffic Engineering", RFC 4124, Diffserv-aware MPLS Traffic Engineering", RFC 4124,
DOI 10.17487/RFC4124, June 2005, DOI 10.17487/RFC4124, June 2005,
<https://www.rfc-editor.org/info/rfc4124>. <https://www.rfc-editor.org/info/rfc4124>.
skipping to change at page 38, line 39 skipping to change at line 1716
"Common YANG Data Types for Traffic Engineering", "Common YANG Data Types for Traffic Engineering",
RFC 8776, DOI 10.17487/RFC8776, June 2020, RFC 8776, DOI 10.17487/RFC8776, June 2020,
<https://www.rfc-editor.org/info/rfc8776>. <https://www.rfc-editor.org/info/rfc8776>.
[RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
O. Gonzalez de Dios, "YANG Data Model for Traffic O. Gonzalez de Dios, "YANG Data Model for Traffic
Engineering (TE) Topologies", RFC 8795, Engineering (TE) Topologies", RFC 8795,
DOI 10.17487/RFC8795, August 2020, DOI 10.17487/RFC8795, August 2020,
<https://www.rfc-editor.org/info/rfc8795>. <https://www.rfc-editor.org/info/rfc8795>.
10.2. Informative References 9.2. Informative References
[I-D.ietf-ccamp-l1csm-yang] [L1CSM-YANG]
Lee, Y., Lee, K., Zheng, H., de Dios, O. G., and D. Lee, Y., Lee, K., Zheng, H., Gonzalez de Dios, O., and D.
Ceccarelli, "A YANG Data Model for L1 Connectivity Service Ceccarelli, "A YANG Data Model for L1 Connectivity Service
Model (L1CSM)", Work in Progress, Internet-Draft, draft- Model (L1CSM)", Work in Progress, Internet-Draft, draft-
ietf-ccamp-l1csm-yang-26, 11 April 2024, ietf-ccamp-l1csm-yang-26, 11 April 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-ccamp- <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-
l1csm-yang-26>. l1csm-yang-26>.
[I-D.ietf-teas-actn-pm-telemetry-autonomics]
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-12, 16 March 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
actn-pm-telemetry-autonomics-12>.
[I-D.ietf-teas-te-service-mapping-yang]
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-15, 16
March 2024, <https://datatracker.ietf.org/doc/html/draft-
ietf-teas-te-service-mapping-yang-15>.
[I-D.ietf-teas-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-36, 2
February 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-teas-yang-te-36>.
[RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G.,
Ceccarelli, D., and X. Zhang, "Problem Statement and Ceccarelli, D., and X. Zhang, "Problem Statement and
Architecture for Information Exchange between Architecture for Information Exchange between
Interconnected Traffic-Engineered Networks", BCP 206, Interconnected Traffic-Engineered Networks", BCP 206,
RFC 7926, DOI 10.17487/RFC7926, July 2016, RFC 7926, DOI 10.17487/RFC7926, July 2016,
<https://www.rfc-editor.org/info/rfc7926>. <https://www.rfc-editor.org/info/rfc7926>.
[RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki,
"YANG Data Model for L3VPN Service Delivery", RFC 8299, "YANG Data Model for L3VPN Service Delivery", RFC 8299,
DOI 10.17487/RFC8299, January 2018, DOI 10.17487/RFC8299, January 2018,
skipping to change at page 40, line 10 skipping to change at line 1757
[RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. [RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B.
Yoon, "Information Model for Abstraction and Control of TE Yoon, "Information Model for Abstraction and Control of TE
Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454, Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454,
September 2018, <https://www.rfc-editor.org/info/rfc8454>. September 2018, <https://www.rfc-editor.org/info/rfc8454>.
[RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG
Data Model for Layer 2 Virtual Private Network (L2VPN) Data Model for Layer 2 Virtual Private Network (L2VPN)
Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October
2018, <https://www.rfc-editor.org/info/rfc8466>. 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, [RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture", A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022, RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>. <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 Appendix A. Performance Constraints
At the time of creation of VN, it is natural to provide VN level At the creation of a VN, it is natural to provide VN-level
constraints and optimization criteria. It should be noted that this constraints and optimization criteria. It should be noted that the
YANG module relies on the TE-Topology Model [RFC8795] by using a VN YANG data model described in this document relies on the TE
reference to an abstract node to achieve this. Further, the Topology model in [RFC8795] by using a reference to an abstract node
connectivity-matrix structure is used to assign the constraints and to provide VN-level constraints and optimization criteria. Further,
optimization criteria including delay, jitter etc. [RFC8776] defines the connectivity-matrix structure is used to assign the constraints
some of the metric-types already and future documents are meant to and optimization criteria including delay, jitter, etc. [RFC8776]
defines some of the metric-types; future documents are meant to
augment it. augment it.
Note that the VN compute allows the inclusion of the constraints and Note that the VN compute allows the inclusion of the constraints and
the optimization criteria directly in the RPC to allow it to be used the optimization criteria directly in the RPC to allow it to be used
independently. independently.
Appendix B. JSON Example Appendix B. JSON Example
B.1. VN JSON B.1. VN JSON
This section provides JSON examples of how VN YANG model and TE This section provides JSON examples of how the VN YANG data model and
topology model are used together to instantiate VN. TE Topology YANG data model are used together to instantiate a VN.
The example in this section includes the following VN The example in this section includes the following VNs:
* VN1 (Type 1): Which maps to the single node topology abstract1 and * VN1 (Type 1): This VN maps to the single node topology abstract1
consist of VN Members 104 (L1 to L4), 107 (L1 to L7), 204 (L2 to and consists of VN members 104 (L1 to L4), 107 (L1 to L7), 204 (L2
L4), 308 (L3 to L8) and 108 (L1 to L8). to L4), 308 (L3 to L8), and 108 (L1 to L8).
* VN2 (Type 2): Which maps to the single node topology abstract2, * VN2 (Type 2): This VN maps to the single node topology abstract2;
this topology has an underlay topology (called underlay). This VN this topology has an underlay topology (called underlay). This VN
has a single VN member 105 (L1 to L5) and an underlay path (S4 and has a single VN member 105 (L1 to L5) and an underlay path (S4 and
S7) has been set in the connectivity matrix of abstract2 topology; S7) has been set in the connectivity matrix of the abstract2
topology;
* VN3 (Type 1): This VN has a multi-source and multi-destination * VN3 (Type 1): This VN has a multi-source and multi-destination
feature enabled. VN Member 106 (L1 to L6) and 107 (L1 to L7) feature enabled. VN member 106 (L1 to L6) and 107 (L1 to L7)
showcase multi-dest and VN Member 108 (L1 to L8) and 308 (L3 to showcase multi-dest and VN member 108 (L1 to L8) and 308 (L3 to
L8) showcase multi-src feature. The selected VN-member is known L8) showcase the multi-src feature. The selected VN member is
via the field "if-selected" and the corresponding connectivity- known via the field "if-selected" and the corresponding
matrix-id. connectivity-matrix-id.
L1---104---L4 L1---105---L5 L1---106---L6(md) L1---104---L4 L1---105---L5 L1---106---L6(md)
L1---107---L7 Underlay Path: L1---107---L7(md) L1---107---L7 Underlay Path: L1---107---L7(md)
L2---204---L4 (S4 and S7) L1---108---L8(ms) L2---204---L4 (S4 and S7) L1---108---L8(ms)
L3---308---L8 L3---308---L8(ms) L3---308---L8 L3---308---L8(ms)
L1---108---L8 L1---108---L8
--- --- --- --- --- ---
VN1 VN2 VN3 VN1 VN2 VN3
--- --- --- --- --- ---
Note that the VN YANG model also includes the AP and VNAP which shows Figure 11: Example
various VN using the same AP.
Note that the VN YANG data model also includes the AP and VNAP, which
shows various VNs using the same AP.
{ {
"ietf-vn:access-point": { "ietf-vn:access-point": {
"ap": [ "ap": [
{ {
"id": "101", "id": "101",
"vn-ap": [ "vn-ap": [
{ {
"id": "10101", "id": "10101",
"vn": "1", "vn": "1",
skipping to change at page 47, line 20 skipping to change at line 2132
}, },
"connectivity-matrix-id": 30308, "connectivity-matrix-id": 30308,
"if-selected": true "if-selected": true
} }
] ]
} }
] ]
} }
} }
B.2. TE-topology JSON B.2. TE Topology JSON
This section provides JSON examples of the various TE topology This section provides JSON examples of the various TE topology
instances. instances.
The example in this section includes the following TE Topologies The example in this section includes the following TE Topologies:
* abstract1: a single node TE topology referenced by VN1. We also * abstract1: a single node TE topology referenced by VN1. We also
show how disjointness (node, link, Shared Risk Link Group (SRLG)) show how disjointness (node, link, Shared Risk Link Group (SRLG))
is supported in the example on the connectivity matrices. is supported in the example on the connectivity matrices.
* abstract2: a single node TE topology referenced by VN2 with * abstract2: a single node TE topology referenced by VN2 with an
underlay path. underlay path.
* underlay: the topology with multiple nodes (in the underlay path * underlay: the topology with multiple nodes (in the underlay path
of abstract2). For brevity, the example includes only the node of abstract2). For brevity, the example includes only the node:
and other parameters are not included. other parameters are not included.
* abstract3: a single node TE topology referenced by VN3. * abstract3: a single node TE topology referenced by VN3.
{ {
"ietf-network:networks": { "ietf-network:networks": {
"network": [ "network": [
{ {
"network-types": { "network-types": {
"ietf-te-topology:te-topology": {} "ietf-te-topology:te-topology": {}
}, },
skipping to change at page 54, line 45 skipping to change at line 2493
} }
} }
} }
} }
] ]
} }
] ]
} }
} }
Appendix C. Contributors Addresses Acknowledgments
The authors would like to thank Xufeng Liu, Adrian Farrel, Tom Petch,
Mohamed Boucadair, Italo Busi, Bo Wu, and Daniel King for their
helpful comments and valuable suggestions.
Thanks to:
* 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
Qin Wu Qin Wu
Huawei Technologies Huawei Technologies
Email: bill.wu@huawei.com Email: bill.wu@huawei.com
Peter Park Peter Park
KT KT
Email: peter.park@kt.com Email: peter.park@kt.com
Haomian Zheng Haomian Zheng
Huawei Technologies Huawei Technologies
 End of changes. 209 change blocks. 
811 lines changed or deleted 830 lines changed or added

This html diff was produced by rfcdiff 1.48.