A YANG Data Model for Virtual Network (VN) OperationsSamsung Electronicsyounglee.tx@gmail.comHuaweiIndiadhruv.ietf@gmail.comCiscodaniele.ietf@gmail.comIndividuali_bryskin@yahoo.comETRIbyyun@etri.re.kr
RTG
teas
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 were a
physical network. This document provides a YANG data model generally
applicable to any mode of VN operations. This includes VN operations as
per the Abstraction and Control of TE Networks (ACTN) framework (RFC 8453).Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
Table of Contents
. Introduction
. Terminology and Conventions
. Tree Diagram
. Prefixes in Data Node Names
. Use Case of VN YANG Data Model in the ACTN Context
. Type 1 VN
. Type 2 VN
. High-Level Control Flows with Examples
. Type 1 VN Illustration
. Type 2 VN Illustration
. VN and AP Usage
. VN YANG Data Model Usage
. Customer View of VN
. Auto-creation of VN by MDSC
. Innovative Services
. VN Compute
. Multiple Sources and Multiple Destinations
. Others
. Summary
. VN YANG Data Model (Tree Structure)
. VN YANG Data Model
. Security Considerations
. IANA Considerations
. References
. Normative References
. Informative References
. Performance Constraints
. JSON Example
. VN JSON
. TE Topology JSON
Acknowledgments
Contributors
Authors' Addresses
Introduction
Abstraction and Control of TE Networks (ACTN)
describes a set of management and control functions used to operate
one or more Traffic Engineered (TE) networks to construct a Virtual Network (VN). A VN
is represented to customers and is built from the abstractions of the
underlying TE networks . This document provides a YANG data model generally applicable to any
mode of VN operation. ACTN is the primary example of the usage of the VN YANG data model, but VN is not limited to it.
The VN model defined in this document is applicable in a generic sense
as an independent model in and of itself. It can also work together with other customer service models such as the L3VPN Service Model (L3SM) , the L2VPN Service Model (L2SM) , and the L1 Connectivity Service Model (L1CSM) to
provide complete life-cycle service management and operations.
The YANG data model discussed in this document basically provides the
following:
Characteristics of Access Points (APs) that describe customer's
endpoint characteristics;
Characteristics of Virtual Network Access Points (VNAPs) that
describe how an AP is partitioned for multiple VNs sharing the AP
and its reference to a Link Termination Point (LTP) of the
Provider Edge (PE) node;
Characteristics of VNs that describe the
customer's VN in terms of multiple VN members comprising a VN, multi-source and/or multi-destination characteristics of the VN member, the
VN's reference to TE-topology's abstract node.
An abstract TE topology is a topology that contains abstract topological elements (nodes, links) created and customized based on customer preference .
The actual VN instantiation and computation is performed with
connectivity matrices of the TE Topology model ,
which provides a TE network topology abstraction and management
operation. As per , a TE node connectivity matrix is the TE node's switching limitations in the form of valid switching combinations of the TE node's LTPs and potential TE paths. The VN representation relies on a single 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 is the VN member that is mapped to the connectivity matrix entry (). The VN can also be abstracted as a topology of virtual nodes
and virtual links (a Type 2 VN). Alongside the mapping of VN members to a connectivity matrix entry, an underlay path can also be specified ().
Once the TE Topology model is used in triggering VN
instantiation over the networks, the TE model will
inevitably interact with the TE Topology model when setting up actual
tunnels and Label Switched Paths (LSPs) under the tunnels.
Sections and provide a discussion of how the VN YANG data model is
applicable to the ACTN context where a Virtual Network Service (VNS)
operation is implemented for the interface of the Customer Network Controller (CNC) and the
Multi-Domain Service Coordinator (MDSC).
The YANG data model for the CNC-MDSC Interface (CMI) is also known as the "customer service model" in
. The YANG data model discussed in this document is used to
operate customer-driven VNs 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
configuration consistent with Network Management Datastore
Architecture (NMDA) .
Terminology and ConventionsThis document borrows the following abbreviations from and/or :
VN:
Virtual Network
AP:
Access Point
VNAP:
VN Access Point
ACTN:
Abstraction and Control of TE Networks
CNC:
Customer Network Controller
MDSC:
Multi-Domain Service Coordinator
CMI:
CNC-MDSC Interface
LTP:
Link Termination Point
This document borrows the terminology in , the term "Service Model" from , and the term "Connectivity Matrix" from .Various examples in this document contain long lines that may be folded, as described in .Tree Diagram
A simplified graphical representation of the data model is used in
of this document. The meaning of the symbols in
these diagrams is defined in .Prefixes in Data Node Names
In this document, the names of data nodes and other data model objects
are prefixed using the standard prefix associated with the
corresponding YANG imported modules as shown in .
Prefixes and Corresponding YANG Modules
Prefix
YANG Module
Reference
vn
ietf-vn
RFC 9731
yang
ietf-yang-types
nw
ietf-network
nt
ietf-network-topology
te-types
ietf-te-types
tet
ietf-te-topology
Use Case of VN YANG Data Model in the ACTN Context
In this section, ACTN is being used to illustrate the general usage
of the VN YANG data model. The model presented in this section has the
following ACTN context.ACTN CMI
+-------+
| CNC |
+-------+
|
| VN + TE Topology
|
+-----------------------+
| MDSC |
+-----------------------+
Both ACTN VN and TE Topology YANG data models are used over the CMI to
establish a VN over TE networks, as shown in .Type 1 VN
As defined in , a VN is a customer view of the
TE network. To recapitulate VN types from , a Type 1 VN is
defined as follows:
The VN can be seen as a set of edge-to-edge abstract links (a Type 1
VN). Each abstract link is referred to as a VN member and is formed
as an end-to-end tunnel across the underlying networks. Such tunnels
may be constructed by recursive slicing or abstraction of paths in
the underlying networks and can encompass edge points of the
customer's network, access links, intra-domain paths, and inter-domain links.If we were to create a VN where we have four VN members as follows:VN Members (Type 1 VN)
VN member 1 L1-L4
VN member 2 L1-L7
VN member 3 L2-L4
VN member 4 L3-L8
Where L1, L2, L3, L4, L7, and L8 correspond to a Customer
Endpoint (or AP).This VN can be modeled as one abstract node representation as
follows in :Abstract Node (Type 1 Topology)
+----------------------------------------------+
| |
L1----|..............................................|------L4
| . . |
| . AN1 . |
| . . |
| ..................................*.....|------L7
| . |
L2-----|....................................... |
| |
L3-----|..............................................|------L8
| |
+----------------------------------------------+
Modeling a VN as one abstract node is the easiest way for customers
to express their end-to-end connectivity as shown in .
Type 2 VN
For some VN members, the customers are allowed to configure
the intended path. To achieve this, alongside the single
node abstract topology, an underlay topology is also needed.
The underlay topology 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. A Type 1 VN
can be viewed as a higher-level abstraction of a Type 2 VN, which represents a single node abstract topology over the underlay topology and includes a mechanism to specify intended paths. These topologies
could be mutually agreed upon between the CNC and the MDSC
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 1
VN (see the example in ), the TE Topology model can provide the following abstract topologies (a single node topology AN1 and an underlay topology (with nodes S1 to S11 and corresponding links)).Type 2 Topology
+----------------------------------------------+
| S1 S2 |
| O...............O |
| ......... ....... . |
| . . . |
|S3 . . S4 . S5 |
L1----|.O......................O.........O...........|------L4
| . . . |
| . . . |
| . S6 . S7 . S8 |
| O ................O.........O.......|------L7
| . . . . ..... |
|S9 . . .S10 . . |
L2-----|...O.....O.....................O..............|------L8
| . S11 |
L3-----|.. |
| AN1 |
+----------------------------------------------+
As shown in , the abstract node is AN1 and an underlay 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
path over Type 2 topology, it can select, say, a path that consists
of the explicit path {S3,S4,S5} based on the underlay topology and its service
requirement. This capability is enacted via TE-topology
configuration by the customer.High-Level Control Flows with ExamplesType 1 VN Illustration
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
YANG data models.Type 1 VN Illustration
+--------+ +--------+
| CNC | | MDSC |
+--------+ +--------+
| |
| |
CNC POST TE Topo | POST /nw:networks/nw:network/ |
model (w/ Conn. | nw:node/te-node-id/ |
Matrix on one | tet:connectivity-matrices/ |
abstract node) | tet:connectivity-matrix |
|-------------------------------->|
| HTTP 200 |
|<--------------------------------|
| |
CNC POST the | POST /virtual-network |
VN identifying |-------------------------------->| If there is
AP, VNAP, and VN | | multi-src/dest,
members and maps | | then MDSC
to the TE Topo | HTTP 200 | selects an
model |<--------------------------------| src or dest
| | and updates
| | VN YANG
CNC GET the | GET /virtual-network |
VN YANG status |-------------------------------->|
| |
| HTTP 200 (VN with status: |
| selected VN members |
| in case of multi-s/d) |
|<--------------------------------|
| |Type 2 VN Illustration
For some VN members, the customer may want to "configure" an explicit
path that connects its two endpoints. Let us
consider the following example:VN Members (Type 2 VN)
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)There are two options depending on whether CNC or MDSC creates the
single abstract node topology.Case 1:
If the CNC creates the single abstract node topology, the message flow between the CNC and MDSC to instantiate
this VN using a VN and TE Topology YANG data model would be as shown in the following diagram:Type 2 VN Illustration: Case 1
+--------+ +--------+
| CNC | | MDSC |
+--------+ +--------+
| |
| |
CNC POST TE Topo | POST /nw:networks/nw:network/ |
model (w/ Conn. | nw:node/te-node-id/tet:connectivity- |
Matrix on one | matrices/tet:connectivity-matrix |
abstract node and|---------------------------------------->|
explicit paths in| |
the Conn. Matrix)| HTTP 200 |
|<----------------------------------------|
| |
CNC POST the | POST /virtual-network |
VN identifying |---------------------------------------->|
AP, VNAP, and VN | |
members and maps | |
to the TE Topo | HTTP 200 |
model |<----------------------------------------|
| |
| |
CNC GET the | GET /virtual-network |
VN YANG status |---------------------------------------->|
| |
| HTTP 200 (VN with status) |
|<----------------------------------------|
| |Case 2:
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
message flow between CNC and MDSC to instantiate this VN using VN
and TE Topology YANG data models.Type 2 VN Illustration: Case 2
+--------+ +--------+
| CNC | | MDSC |
+--------+ +--------+
| |
| |
CNC POST VN | |
identifying AP, | |
VNAP and VN | POST /virtual-network | MDSC populates
members |-------------------------------->| a single abst.
| HTTP 200 | node topology
|<--------------------------------| by itself
| |
CNC GET VN & | GET /virtual-network & |
POST TE Topo | POST /nw:networks/nw:network/ |
models (w/ | nw:node/te-node-id/tet: |
Conn. Matrix | connectivity-matrices/ |
on the | tet:connectivity-matrix |
abstract node |-------------------------------->|
and explicit | |
paths in the | |
Conn. Matrix) | |
| HTTP 200 |
|<--------------------------------|
| |
| |
CNC GET the | GET /virtual-network |
VN YANG status |-------------------------------->|
| |
| HTTP 200 (VN with status) |
|<--------------------------------|
| |Note that the underlay topology (which is referred to by the single abstract node topology) could be a Native/White topology or a Grey topology () that is further customized based on the requirements of the customer and configured at the MDSC. provides JSON examples for both the VN model and the TE Topology
Connectivity Matrix sub-model to illustrate how a VN can be created
by the CNC making use of the VN model as well as the TE Topology
Connectivity Matrix module.VN and AP UsageThe customer access information may be known at the time of VN creation. A shared logical AP identifier is used between the customer and the operator to identify the access link between Customer Edge (CE) and Provider Edge (PE). This is described in .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 with only a PE identifier. The customer access information could be added later.To achieve this, the 'ap' container has a leaf for the 'pe' node that allows the AP to be created with PE information. The VN member (and VN) could use APs that initially only have PE information.VN YANG Data Model UsageCustomer View of VN
The VN YANG data model allows the definition of a customer view and allows the
customer to communicate using the VN constructs as described in
. It allows the grouping of edge-to-edge links
(i.e., VN members) under a common umbrella of VN. This allows the
customer to instantiate and view the VN as one entity, making it
easier for some customers to work on VN without worrying about the
details of the provider-based YANG data models.
This is similar to the benefits offered by a separate YANG data model for
customer services described in , which states that
service models do not make any assumptions about how a service is
actually engineered and delivered for a customer.Auto-creation of VN by MDSC
The VN could be configured at the MDSC explicitly by the CNC using
the VN YANG data model. In some other cases, the VN is not explicitly
configured but is instead created automatically by the MDSC based on the
customer service model and local policy; even in these cases, the VN
YANG data model can be used by the CNC to learn details of the underlying
VN, created to meet the requirements of the customer service model.Innovative ServicesVN Compute
The VN model supports VN compute (pre-instantiation mode) to view the
full VN as a single entity before instantiation; achieving this via
path computation or "compute-only" tunnel setup () does not provide the
same functionality.VN Compute with Reference to TE Topology YANG Data Model
+--------+ +--------+
| CNC | | MDSC |
+--------+ +--------+
| |
| |
CNC POST TE Topo | POST /nw:networks/nw:network/ |
model (w/ Conn. | nw:node/te-node-id/tet:connectivity- |
Matrix on one | matrices/tet:connectivity-matrix |
abstract node and|---------------------------------------->|
constraints in | |
the conn. matrix)| HTTP 200 |
|<----------------------------------------|
| |
| |
CNC calls RPC to | RPC /vn compute |
compute the VN |---------------------------------------->|
as per the | |
referred TE-Topo | |
| |
| HTTP 200 (Computed VN) |
|<----------------------------------------|
| |The VN compute RPC allows the optional inclusion of the constraints 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 computed VN result
without creating an abstract topology first.VN Compute
+--------+ +--------+
| CNC | | MDSC |
+--------+ +--------+
| |
| |
CNC calls RPC to | RPC /vn compute |
compute the VN |---------------------------------------->|
as per the | |
constraints and | |
VN members | |
| HTTP 200 (Computed VN) |
|<----------------------------------------|
| |Regardless of whether the TE Topology model is referenced, the RPC output includes a reference to the single node
abstract topology with each VN member including a
reference to the connectivity-matrix-id where the
path properties could be found. To achieve this, the VN compute RPC reuses the following common groupings:
te-types:generic-path-constraints: is used optionally in the RPC input at the VN-level and/or VN-member level. The VN-member level overrides the VN-level data including any constraints in the referenced abstract node in the TE topology.
te-types:generic-path-optimization: is used optionally in the RPC input at the VN-level and/or VN-member level. The VN-member level overrides the VN-level data including any optimization in the referenced abstract node in the TE topology.
vn member: identifies the VN member in both RPC input and output.
vn-policy: is used optionally in the RPC input to apply any VN-level policies.
When MDSC receives this RPC, it computes the VN based on the input provided in the RPC. This computation does not create a VN or reserve any resources in the system, it simply computes the resulting 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 VN member as a reference to the connectivity-matrix-id. In case of an error, the error information is included.
rpcs:
+---x vn-compute
+---w input
| +---w te-topology-identifier
| | +---w provider-id? te-global-id
| | +---w client-id? te-global-id
| | +---w topology-id? te-topology-id
| +---w abstract-node?
| | -> /nw:networks/network/node/tet:te-node-id
| +---w path-constraints
| | +---w te-bandwidth
| | | +---w (technology)?
| | | ...
| | +---w link-protection? identityref
| | +---w setup-priority? uint8
| | +---w hold-priority? uint8
| | +---w signaling-type? identityref
| | +---w path-metric-bounds
| | | +---w path-metric-bound* [metric-type]
| | | ...
| | +---w path-affinities-values
| | | +---w path-affinities-value* [usage]
| | | ...
| | +---w path-affinity-names
| | | +---w path-affinity-name* [usage]
| | | ...
| | +---w path-srlgs-lists
| | | +---w path-srlgs-list* [usage]
| | | ...
| | +---w path-srlgs-names
| | | +---w path-srlgs-name* [usage]
| | | ...
| | +---w disjointness? te-path-disjointness
| +---w cos? te-types:te-ds-class
| +---w optimizations
| | +---w (algorithm)?
| | +--:(metric) {path-optimization-metric}?
| | | ...
| | +--:(objective-function)
| | {path-optimization-objective-function}?
| | ...
| +---w vn-member-list* [id]
| | +---w id vnm-id
| | +---w src
| | | +---w ap? -> /access-point/ap/id
| | | +---w vn-ap-id?
| | | | -> /access-point/ap[id=current()/../ap]/vn-ap/\
id
| | | +---w multi-src? boolean {multi-src-dest}?
| | +---w dest
| | | +---w ap? -> /access-point/ap/id
| | | +---w vn-ap-id?
| | | | -> /access-point/ap[id=current()/../ap]/vn-ap/\
id
| | | +---w multi-dest? boolean {multi-src-dest}?
| | +---w connectivity-matrix-id? leafref
| | +---w underlay
| | +---w path-constraints
| | | +---w te-bandwidth
| | | | ...
| | | +---w link-protection? identityref
| | | +---w setup-priority? uint8
| | | +---w hold-priority? uint8
| | | +---w signaling-type? identityref
| | | +---w path-metric-bounds
| | | | ...
| | | +---w path-affinities-values
| | | | ...
| | | +---w path-affinity-names
| | | | ...
| | | +---w path-srlgs-lists
| | | | ...
| | | +---w path-srlgs-names
| | | | ...
| | | +---w disjointness? te-path-disjointness
| | +---w cos? te-types:te-ds-class
| | +---w optimizations
| | +---w (algorithm)?
| | ...
| +---w vn-level-diversity? te-types:te-path-\
disjointness
+--ro output
+--ro te-topology-identifier
| +--ro provider-id? te-global-id
| +--ro client-id? te-global-id
| +--ro topology-id? te-topology-id
+--ro abstract-node?
| -> /nw:networks/network/node/tet:te-node-id
+--ro vn-member-list* [id]
+--ro id vnm-id
+--ro src
| +--ro ap? -> /access-point/ap/id
| +--ro vn-ap-id?
| | -> /access-point/ap[id=current()/../ap]/vn-ap/\
id
| +--ro multi-src? boolean {multi-src-dest}?
+--ro dest
| +--ro ap? -> /access-point/ap/id
| +--ro vn-ap-id?
| | -> /access-point/ap[id=current()/../ap]/vn-ap/\
id
| +--ro multi-dest? boolean {multi-src-dest}?
+--ro connectivity-matrix-id? leafref
+--ro underlay
+--ro if-selected? boolean {multi-src-dest}?
+--ro compute-status? vn-compute-status
+--ro error-info
+--ro error-description? string
+--ro error-timestamp? yang:date-and-time
+--ro error-reason? identityrefMultiple Sources and Multiple Destinations
In creating a VN, the list of sources or destinations
or both may not be predetermined by the customer. For instance, for
a given source, there may be a list of multiple destinations to
which the optimal destination may be chosen depending on the network
resource situations. Likewise, for a given destination, there may
also be multiple sources from which the optimal source may be
chosen. In some cases, there may be a pool of multiple sources and
destinations from which the optimal source-destination may be
chosen. The following YANG tree shows
how to model multiple sources and multiple destinations.
module: ietf-vn
+--rw virtual-network
+--rw vn* [id]
+--rw id vn-id
+--rw te-topology-identifier
| +--rw provider-id? te-global-id
| +--rw client-id? te-global-id
| +--rw topology-id? te-topology-id
+--rw abstract-node?
| -> /nw:networks/network/node/tet:te-node-id
+--rw vn-member* [id]
| +--rw id vnm-id
| +--rw src
| | +--rw ap? -> /access-point/ap/id
| | +--rw vn-ap-id?
| | | -> /access-point/ap[id=current()/../ap]/vn-ap/\
id
| | +--rw multi-src? boolean {multi-src-dest}?
| +--rw dest
| | +--rw ap? -> /access-point/ap/id
| | +--rw vn-ap-id?
| | | -> /access-point/ap[id=current()/../ap]/vn-ap/\
id
| | +--rw multi-dest? boolean {multi-src-dest}?
| +--rw connectivity-matrix-id? leafref
| +--rw underlay
| +--ro oper-status? te-types:te-oper-status
| +--ro if-selected? boolean {multi-src-dest}?
+--rw admin-status? te-types:te-admin-status
+--ro oper-status? te-types:te-oper-status
+--rw vn-level-diversity? te-types:te-path-disjointnessOthers
The VN YANG data model can easily be augmented to support the mapping of
VN to the services such as L3SM and L2SM as described in .
The VN YANG data model can be extended to support telemetry, performance
monitoring, and network autonomics as described in .Note that the VN YANG data model is tightly coupled with the TE Topology model . Any underlay technology not supported by the TE Topology model in is also not supported by the VN model. However, the VN model does include an empty container called "underlay" that can be augmented. For example, the Segment Routing (SR) Policy information can be augmented for the SR underlay by a future model.Apart from the te-types:generic-path-constraints and te-types:generic-path-optimization, an additional leaf called "cos" for the class of service is added to represent the Class-Type of traffic to be used as one of the path constraints.Summary
This section summarizes the features of the VN
YANG data model.
Maintenance of APs and VNAPs along with the VN
VN construct to group of edge-to-edge links
Ability to support various VN and VNS types
VN Type 1: Customer configures the VN as a set of VN
members. No other details need to be set by the customer,
making for a simplified operation for the customer.
VN Type 2: Along with VN members, the customer could
also provide an abstract topology, this topology is provided
by the Abstract TE Topology YANG data model.
Note that the VN type is not explicitly identified in
the VN YANG data model, as the VN YANG data model is exactly the same for
both VN Type 1 and VN Type 2. The VN type can be implicitly known
based on the referenced TE topology and whether the
connectivity matrix includes the underlay path (Type 2) or
not (Type 1).
VN Compute (pre-instantiate)
Multi-Source / Multi-Destination
VN YANG Data Model (Tree Structure)
module: ietf-vn
+--rw access-point
| +--rw ap* [id]
| +--rw id ap-id
| +--rw pe?
| | -> /nw:networks/network/node/tet:te-node-id
| +--rw max-bandwidth? te-types:te-bandwidth
| +--rw avl-bandwidth? te-types:te-bandwidth
| +--rw vn-ap* [id]
| +--rw id ap-id
| +--rw vn? -> /virtual-network/vn/id
| +--rw abstract-node? -> /nw:networks/network/node/\
node-id
| +--rw ltp? leafref
| +--ro max-bandwidth? te-types:te-bandwidth
+--rw virtual-network
+--rw vn* [id]
+--rw id vn-id
+--rw te-topology-identifier
| +--rw provider-id? te-global-id
| +--rw client-id? te-global-id
| +--rw topology-id? te-topology-id
+--rw abstract-node?
| -> /nw:networks/network/node/tet:te-node-id
+--rw vn-member* [id]
| +--rw id vnm-id
| +--rw src
| | +--rw ap? -> /access-point/ap/id
| | +--rw vn-ap-id?
| | | -> /access-point/ap[id=current()/../ap]/\
vn-ap/id
| | +--rw multi-src? boolean {multi-src-dest}?
| +--rw dest
| | +--rw ap? -> /access-point/ap/id
| | +--rw vn-ap-id?
| | | -> /access-point/ap[id=current()/../ap]/\
vn-ap/id
| | +--rw multi-dest? boolean {multi-src-dest}?
| +--rw connectivity-matrix-id? leafref
| +--rw underlay
| +--ro oper-status? te-types:te-oper-status
| +--ro if-selected? boolean {multi-src-dest}?
+--rw admin-status? te-types:te-admin-status
+--ro oper-status? te-types:te-oper-status
+--rw vn-level-diversity? te-types:te-path-disjointness
rpcs:
+---x vn-compute
+---w input
| +---w te-topology-identifier
| | +---w provider-id? te-global-id
| | +---w client-id? te-global-id
| | +---w topology-id? te-topology-id
| +---w abstract-node?
| | -> /nw:networks/network/node/tet:te-node-id
| +---w path-constraints
| | +---w te-bandwidth
| | | +---w (technology)?
| | | ...
| | +---w link-protection? identityref
| | +---w setup-priority? uint8
| | +---w hold-priority? uint8
| | +---w signaling-type? identityref
| | +---w path-metric-bounds
| | | +---w path-metric-bound* [metric-type]
| | | ...
| | +---w path-affinities-values
| | | +---w path-affinities-value* [usage]
| | | ...
| | +---w path-affinity-names
| | | +---w path-affinity-name* [usage]
| | | ...
| | +---w path-srlgs-lists
| | | +---w path-srlgs-list* [usage]
| | | ...
| | +---w path-srlgs-names
| | | +---w path-srlgs-name* [usage]
| | | ...
| | +---w disjointness? te-path-disjointness
| +---w cos? te-types:te-ds-class
| +---w optimizations
| | +---w (algorithm)?
| | +--:(metric) {path-optimization-metric}?
| | | ...
| | +--:(objective-function)
| | {path-optimization-objective-function}?
| | ...
| +---w vn-member-list* [id]
| | +---w id vnm-id
| | +---w src
| | | +---w ap? -> /access-point/ap/id
| | | +---w vn-ap-id?
| | | | -> /access-point/ap[id=current()/../ap]/\
vn-ap/id
| | | +---w multi-src? boolean {multi-src-dest}?
| | +---w dest
| | | +---w ap? -> /access-point/ap/id
| | | +---w vn-ap-id?
| | | | -> /access-point/ap[id=current()/../ap]/\
vn-ap/id
| | | +---w multi-dest? boolean {multi-src-dest}?
| | +---w connectivity-matrix-id? leafref
| | +---w underlay
| | +---w path-constraints
| | | +---w te-bandwidth
| | | | ...
| | | +---w link-protection? identityref
| | | +---w setup-priority? uint8
| | | +---w hold-priority? uint8
| | | +---w signaling-type? identityref
| | | +---w path-metric-bounds
| | | | ...
| | | +---w path-affinities-values
| | | | ...
| | | +---w path-affinity-names
| | | | ...
| | | +---w path-srlgs-lists
| | | | ...
| | | +---w path-srlgs-names
| | | | ...
| | | +---w disjointness? te-path-disjointness
| | +---w cos? te-types:te-ds-class
| | +---w optimizations
| | +---w (algorithm)?
| | ...
| +---w vn-level-diversity? te-types:te-path-\
disjointness
+--ro output
+--ro te-topology-identifier
| +--ro provider-id? te-global-id
| +--ro client-id? te-global-id
| +--ro topology-id? te-topology-id
+--ro abstract-node?
| -> /nw:networks/network/node/tet:te-node-id
+--ro vn-member-list* [id]
+--ro id vnm-id
+--ro src
| +--ro ap? -> /access-point/ap/id
| +--ro vn-ap-id?
| | -> /access-point/ap[id=current()/../ap]/\
vn-ap/id
| +--ro multi-src? boolean {multi-src-dest}?
+--ro dest
| +--ro ap? -> /access-point/ap/id
| +--ro vn-ap-id?
| | -> /access-point/ap[id=current()/../ap]/\
vn-ap/id
| +--ro multi-dest? boolean {multi-src-dest}?
+--ro connectivity-matrix-id? leafref
+--ro underlay
+--ro if-selected? boolean {multi-src-\
dest}?
+--ro compute-status? vn-compute-status
+--ro error-info
+--ro error-description? string
+--ro error-timestamp? yang:date-and-time
+--ro error-reason? identityrefVN YANG Data ModelThe VN YANG data model is as follows:
module ietf-vn {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-vn";
prefix vn;
/* Import common YANG types */
import ietf-yang-types {
prefix yang;
reference
"RFC 6991: Common YANG Data Types";
}
/* Import network */
import ietf-network {
prefix nw;
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
/* Import network topology */
import ietf-network-topology {
prefix nt;
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
/* Import TE Common types */
import ietf-te-types {
prefix te-types;
reference
"RFC 8776: Common YANG Data Types for Traffic Engineering";
}
/* Import TE Topology */
import ietf-te-topology {
prefix tet;
reference
"RFC 8795: YANG Data Model for Traffic Engineering (TE)
Topologies";
}
organization
"IETF Traffic Engineering Architecture and Signaling (TEAS)
Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/teas/>
WG List: <mailto:teas@ietf.org>
Editor: Young Lee <younglee.tx@gmail.com>
Editor: Dhruv Dhody <dhruv.ietf@gmail.com>";
description
"This YANG module for the Virtual Network (VN).
It describes a VN operation module that can take place
in the context of the Customer Network Controller (CNC) -
Multi-Domain Service Coordinator (MDSC) interface (CMI) of
the Abstraction and Control of TE Networks (ACTN)
architecture where the CNC is the actor of a VN
instantiation/modification/deletion as per RFC 8453.
Copyright (c) 2025 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 9731; see the
RFC itself for full legal notices.";
revision 2025-03-27 {
description
"The initial version.";
reference
"RFC 9731: A YANG Data Model for Virtual Network (VN)
Operations";
}
/* Features */
feature multi-src-dest {
description
"Support for selection of one source or destination
among multiple.";
reference
"RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN)";
}
/* Typedef */
typedef vn-id {
type string {
length "1..max";
}
description
"A type definition for a VN identifier.";
}
typedef ap-id {
type string {
length "1..max";
}
description
"A type definition for an Access Point (AP) identifier.";
}
typedef vnm-id {
type string {
length "1..max";
}
description
"A type definition for a VN-member identifier.";
}
typedef vn-compute-status {
type te-types:te-common-status;
description
"A type definition for representing the VN compute status.
Note that all statuses apart from up and down are considered
to be unknown.";
}
/* identities */
identity vn-computation-error-reason {
description
"Base identity for VN computation error reasons.";
}
identity vn-computation-error-not-ready {
base vn-computation-error-reason;
description
"VN computation has failed because the MDSC is not
ready.";
}
identity vn-computation-error-no-cnc {
base vn-computation-error-reason;
description
"VN computation has failed because one or more dependent
CNCs are unavailable.";
}
identity vn-computation-error-no-resource {
base vn-computation-error-reason;
description
"VN computation has failed because there is no
available resource in one or more domains.";
}
identity vn-computation-error-path-not-found {
base vn-computation-error-reason;
description
"VN computation failed as no path found.";
}
identity vn-computation-ap-unknown {
base vn-computation-error-reason;
description
"VN computation failed as the source or destination Access
Point (AP) not known.";
}
/* Groupings */
grouping vn-member {
description
"The vn-member is described by this grouping.";
leaf id {
type vnm-id;
description
"A vn-member identifier.";
}
container src {
description
"The source of VN member.";
leaf ap {
type leafref {
path "/access-point/ap/id";
}
description
"A reference to the source AP.";
}
leaf vn-ap-id {
type leafref {
path "/access-point/ap[id=current()/../ap]/vn-ap"
+ "/id";
}
description
"A reference to the source VNAP.";
}
leaf multi-src {
if-feature "multi-src-dest";
type boolean;
default "false";
description
"Is the source part of a multi-source, where
only one of the sources is enabled?";
}
}
container dest {
description
"The destination of the VN member.";
leaf ap {
type leafref {
path "/access-point/ap/id";
}
description
"A reference to the destination AP.";
}
leaf vn-ap-id {
type leafref {
path "/access-point/ap[id=current()/../ap]/"
+ "vn-ap/id";
}
description
"A reference to the destination VNAP.";
}
leaf multi-dest {
if-feature "multi-src-dest";
type boolean;
default "false";
description
"Is the destination part of a multi-destination,
where only one of the destinations is enabled.";
}
}
leaf connectivity-matrix-id {
type leafref {
path "/nw:networks/nw:network/nw:node/tet:te/"
+ "tet:te-node-attributes/"
+ "tet:connectivity-matrices/"
+ "tet:connectivity-matrix/tet:id";
}
description
"A reference to the connectivity-matrix.";
reference
"RFC 8795: YANG Data Model for Traffic Engineering (TE)
Topologies";
}
container underlay {
description
"An empty container that can be augmented with underlay
technology information not supported by RFC 8795 (for
example, Segment Routing (SR).";
}
reference
"RFC 8454: Information Model for Abstraction and Control of TE
Networks (ACTN)
RFC 8795: YANG Data Model for Traffic Engineering (TE)
Topologies";
}
grouping vn-policy {
description
"policy for VN-level diversity";
leaf vn-level-diversity {
type te-types:te-path-disjointness;
description
"The type of disjointness on the VN level (i.e., across all
VN members).";
}
}
/* Configuration data nodes */
container access-point {
description
"AP configurations.";
list ap {
key "id";
description
"The access-point identifier.";
leaf id {
type ap-id;
description
"An AP identifier unique within the scope of the entity
that controls the VN.";
}
leaf pe {
type leafref {
path "/nw:networks/nw:network/nw:node/tet:te-node-id";
}
description
"A reference to the PE node in the native TE Topology.";
}
leaf max-bandwidth {
type te-types:te-bandwidth;
description
"The max bandwidth of the AP.";
}
leaf avl-bandwidth {
type te-types:te-bandwidth;
description
"The available bandwidth of the AP.";
}
list vn-ap {
key "id";
leaf id {
type ap-id;
description
"A unique identifier for the VNAP.";
}
leaf vn {
type leafref {
path "/virtual-network/vn/id";
}
description
"A reference to the VN.";
}
leaf abstract-node {
type leafref {
path "/nw:networks/nw:network/nw:node/nw:node-id";
}
must '/nw:networks/nw:network/nw:node[nw:node-id='
+ 'current()/../abstract-node]/tet:te-node-id' {
description
"The associated network for the abstract-node
must be TE enabled.";
}
description
"A reference to the abstract node that represents
the VN.";
}
leaf ltp {
type leafref {
path "/nw:networks/nw:network/nw:node[nw:node-id="
+ "current()/../abstract-node]/nt:termination-point/"
+ "tet:te-tp-id";
}
description
"A reference to the Link Termination Point (LTP)
in the abstract-node, i.e., the LTP should be in
the abstract layer and not the underlying layer.";
reference
"RFC 8795: YANG Data Model for Traffic Engineering (TE)
Topologies";
}
leaf max-bandwidth {
type te-types:te-bandwidth;
config false;
description
"The max bandwidth of the VNAP.";
}
description
"List of VNAPs in this AP.";
}
}
reference
"RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN), Section 6";
}
container virtual-network {
description
"VN configurations.";
list vn {
key "id";
description
"A VN is identified by a vn-id.";
leaf id {
type vn-id;
description
"An identifier unique within the scope of the entity
that controls the VN.";
}
uses te-types:te-topology-identifier;
leaf abstract-node {
type leafref {
path "/nw:networks/nw:network/nw:node/tet:te-node-id";
}
description
"A reference to the abstract node in TE Topology.";
}
list vn-member {
key "id";
description
"List of vn-members in a VN.";
uses vn-member;
leaf oper-status {
type te-types:te-oper-status;
config false;
description
"The vn-member operational state.";
}
leaf if-selected {
if-feature "multi-src-dest";
type boolean;
default "false";
config false;
description
"Is the vn-member selected among the multi-source
or multi-destination options?";
}
}
leaf admin-status {
type te-types:te-admin-status;
default "up";
description
"VN administrative state.";
}
leaf oper-status {
type te-types:te-oper-status;
config false;
description
"VN operational state.";
}
uses vn-policy;
}
reference
"RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN)";
}
/* RPC */
rpc vn-compute {
description
"The VN computation without actual instantiation. This is
used by the CNC to get the VN results without actually
creating it in the network.
The input could include a reference to the single node
abstract topology. It could optionally also include
constraints and optimization criteria. The computation
is done based on the list of VN members.
The output includes a reference to the single node
abstract topology with each VN member including a
reference to the connectivity-matrix-id where the
path properties could be found. Error information is
also included.";
input {
uses te-types:te-topology-identifier;
leaf abstract-node {
type leafref {
path "/nw:networks/nw:network/nw:node/tet:te-node-id";
}
description
"A reference to the abstract node in TE Topology.";
}
uses te-types:generic-path-constraints;
leaf cos {
type te-types:te-ds-class;
description
"The class of service (COS).";
}
uses te-types:generic-path-optimization;
list vn-member-list {
key "id";
description
"List of VN members in a VN.";
uses vn-member;
uses te-types:generic-path-constraints;
leaf cos {
type te-types:te-ds-class;
description
"The class of service.";
reference
"RFC 4124: Protocol Extensions for Support of
Diffserv-aware MPLS Traffic Engineering,
Section 4.3.1";
}
uses te-types:generic-path-optimization;
}
uses vn-policy;
}
output {
uses te-types:te-topology-identifier;
leaf abstract-node {
type leafref {
path "/nw:networks/nw:network/nw:node/tet:te-node-id";
}
description
"A reference to the abstract node in TE Topology.";
}
list vn-member-list {
key "id";
description
"List of VN members in a VN.";
uses vn-member;
leaf if-selected {
if-feature "multi-src-dest";
type boolean;
default "false";
description
"Is the vn-member selected among the multi-source or
multi-destination options?";
reference
"RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN), Section 7";
}
leaf compute-status {
type vn-compute-status;
description
"The VN-member compute state.";
}
container error-info {
description
"Error information related to the VN member.";
leaf error-description {
type string {
length "1..max";
}
description
"Textual representation of the error that occurred
during VN compute.";
}
leaf error-timestamp {
type yang:date-and-time;
description
"Timestamp of the attempt.";
}
leaf error-reason {
type identityref {
base vn-computation-error-reason;
}
description
"Reason for the VN computation error.";
}
}
}
}
}
}
Security Considerations
The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such
as NETCONF or RESTCONF .
The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH)
. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS .
The Network Configuration Access Control Model (NACM) provides the means to
restrict access for particular NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.
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). Security risks, such as malicious
attack and rogue elements attempting to connect to the various ACTN
components, are possible. Furthermore, some ACTN components (e.g., MDSC)
represent a single point of failure and threat vector. Also, there is a need to
manage policy conflicts and eavesdropping on communication between
different ACTN components.
There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., "config true", which is the
default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability:
ap: This list includes a set of sensitive data that influences how the APs in the VN service are attached. By accessing the following data nodes, an attacker may be able to manipulate the VN.
id
pe
max-bandwidth
avl-bandwidth
vn-ap: This list includes a set of sensitive data that influences how the VN service is delivered. By accessing the following data nodes, an attacker may be able
to manipulate the VN.
id
vn
abstract-node
ltp
max-bandwidth
vn: This list includes a set of sensitive data that influences how the VN service is delivered. By accessing the following data nodes, an attacker may be able
to manipulate the VN.
id
te-topology-identifier
abstract-node
vn-member: This list includes a set of sensitive data that influences how the VN member in the VN service is delivered. By accessing the following data nodes, an attacker may be able to manipulate the VN member.
id
src/ap
src/vn-ap-id
dest/ap
dest/vn-ap-id
connectivity-matrix-id
Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or
notification) to these data nodes. These are the subtrees and data
nodes and their sensitivity/vulnerability:
oper-status: This leaf can reveal the current operational state of the VN.
if-selected: This leaf can reveal which vn-member is selected among the various multi-source / multi-destination options.
Some of the RPC operations in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control access to these operations. These are the
operations and their sensitivity/vulnerability:
vn-compute: This RPC triggers the VN computation at the MDSC, which can reveal the VN information.
IANA ConsiderationsIANA has made the following allocation for a URI in
the "ns" registry within the "IETF XML Registry" registry group :
URI:
urn:ietf:params:xml:ns:yang:ietf-vn
Registrant Contact:
The IESG.
XML:
N/A, the requested URI is an XML namespace.
IANA has made the following allocation for the VN YANG
data model (see in the "YANG Module Names" registry :
name:
ietf-vn
namespace:
urn:ietf:params:xml:ns:yang:ietf-vn
prefix:
vn
reference:
RFC 9731
ReferencesNormative ReferencesThe IETF XML RegistryThis document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.Protocol Extensions for Support of Diffserv-aware MPLS Traffic EngineeringThis document specifies the protocol extensions for support of Diffserv-aware MPLS Traffic Engineering (DS-TE). This includes generalization of the semantics of a number of Interior Gateway Protocol (IGP) extensions already defined for existing MPLS Traffic Engineering in RFC 3630, RFC 3784, and additional IGP extensions beyond those. This also includes extensions to RSVP-TE signaling beyond those already specified in RFC 3209 for existing MPLS Traffic Engineering. These extensions address the requirements for DS-TE spelled out in RFC 3564. [STANDARDS-TRACK]YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]Network Configuration Protocol (NETCONF)The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]Using the NETCONF Protocol over Secure Shell (SSH)This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK]Common YANG Data TypesThis document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021.The YANG 1.1 Data Modeling LanguageYANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).RESTCONF ProtocolThis document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).YANG Tree DiagramsThis document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.Network Configuration Access Control ModelThe standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model.This document obsoletes RFC 6536.Network Management Datastore Architecture (NMDA)Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950.A YANG Data Model for Network TopologiesThis document defines an abstract (generic, or base) YANG data model for network/service topologies and inventories. The data model serves as a base model that is augmented with technology-specific details in other, more specific topology and inventory data models.The Transport Layer Security (TLS) Protocol Version 1.3This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.Common YANG Data Types for Traffic EngineeringThis document defines a collection of common data types and groupings in YANG data modeling language. These derived common types and groupings are intended to be imported by modules that model Traffic Engineering (TE) configuration and state capabilities.YANG Data Model for Traffic Engineering (TE) TopologiesThis document defines a YANG data model for representing, retrieving, and manipulating Traffic Engineering (TE) Topologies. The model serves as a base model that other technology-specific TE topology models can augment.Informative ReferencesA YANG Data Model for L1 Connectivity Service Model (L1CSM)SamsungKorea TelecomHuawei TechnologiesTelefonicaCiscoWork in ProgressProblem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered NetworksIn Traffic-Engineered (TE) systems, it is sometimes desirable to establish an end-to-end TE path with a set of constraints (such as bandwidth) across one or more networks from a source to a destination. TE information is the data relating to nodes and TE links that is used in the process of selecting a TE path. TE information is usually only available within a network. We call such a zone of visibility of TE information a domain. An example of a domain may be an IGP area or an Autonomous System.In order to determine the potential to establish a TE path through a series of connected networks, it is necessary to have available a certain amount of TE information about each network. This need not be the full set of TE information available within each network but does need to express the potential of providing TE connectivity. This subset of TE information is called TE reachability information.This document sets out the problem statement for the exchange of TE information between interconnected TE networks in support of end-to-end TE path establishment and describes the best current practice architecture to meet this problem statement. For reasons that are explained in this document, this work is limited to simple TE constraints and information that determine TE reachability.YANG Data Model for L3VPN Service DeliveryThis document defines a YANG data model that can be used for communication between customers and network operators and to deliver a Layer 3 provider-provisioned VPN service. This document is limited to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364. This model is intended to be instantiated at the management system to deliver the overall service. It is not a configuration model to be used directly on network elements. This model provides an abstracted view of the Layer 3 IP VPN service configuration components. It will be up to the management system to take this model as input and use specific configuration models to configure the different network elements to deliver the service. How the configuration of network elements is done is out of scope for this document.This document obsoletes RFC 8049; it replaces the unimplementable module in that RFC with a new module with the same name that is not backward compatible. The changes are a series of small fixes to the YANG module and some clarifications to the text.Service Models ExplainedThe IETF has produced many modules in the YANG modeling language. The majority of these modules are used to construct data models to model devices or monolithic functions.A small number of YANG modules have been defined to model services (for example, the Layer 3 Virtual Private Network Service Model (L3SM) produced by the L3SM working group and documented in RFC 8049).This document describes service models as used within the IETF and also shows where a service model might fit into a software-defined networking architecture. Note that service models do not make any assumption of how a service is actually engineered and delivered for a customer; details of how network protocols and devices are engineered to deliver a service are captured in other modules that are not exposed through the interface between the customer and the provider.Framework for Abstraction and Control of TE Networks (ACTN)Traffic Engineered (TE) networks have a variety of mechanisms to facilitate the separation of the data plane and control plane. They also have a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. The term "Traffic Engineered network" refers to a network that uses any connection-oriented technology under the control of a distributed or centralized control plane to support dynamic provisioning of end-to- end connectivity.Abstraction of network resources is a technique that can be applied to a single network domain or across multiple domains to create a single virtualized network that is under the control of a network operator or the customer of the operator that actually owns the network resources.This document provides a framework for Abstraction and Control of TE Networks (ACTN) to support virtual network services and connectivity services.Information Model for Abstraction and Control of TE Networks (ACTN)This document provides an information model for Abstraction and Control of TE Networks (ACTN).A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service DeliveryThis document defines a YANG data model that can be used to configure a Layer 2 provider-provisioned VPN service. It is up to a management system to take this as an input and generate specific configuration models to configure the different network elements to deliver the service. How this configuration of network elements is done is out of scope for this document.The YANG data model defined in this document includes support for point-to-point Virtual Private Wire Services (VPWSs) and multipoint Virtual Private LAN Services (VPLSs) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFCs 4761 and 6624.The YANG data model defined in this document conforms to the Network Management Datastore Architecture defined in RFC 8342.Handling Long Lines in Content of Internet-Drafts and RFCsThis document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content.Segment Routing Policy ArchitectureSegment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy.This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy.Traffic Engineering (TE) and Service Mapping YANG Data ModelSamsung ElectronicsHuaweiHuaweiHuaweiCiscoNvidia This document provides a YANG data model to map customer service
models (e.g., L3VPN Service Delivery model) to Traffic Engineering
(TE) models (e.g., the TE Tunnel or the Virtual Network (VN) model).
These models are referred to as the TE Service Mapping Model and are
applicable generically to the operator's need for seamless control
and management of their VPN services with underlying TE support.
The models are principally used for monitoring and diagnostics of the
management systems to show how the service requests are mapped onto
underlying network resources and TE models.
Work in ProgressYANG models for Virtual Network (VN)/TE Performance Monitoring Telemetry and Scaling Intent AutonomicsSamsung ElectronicsHuaweiCTTCLancaster UniversityCisco This document provides YANG data models that describe the performance
monitoring parameters and scaling intent mechanisms for TE-tunnels
and Virtual Networks (VNs). Their performance monitoring parameters
are exposed as the key telemetry data for tunnels and VN.
The models presented in this document allow customers to subscribe to
and monitor the key performance data of the TE-tunnel or the VN. The
models also provide customers with the ability to program autonomic
scaling intent mechanisms on the level of TE-tunnel as well as VN.
Work in ProgressA YANG Data Model for Traffic Engineering Tunnels, Label Switched Paths and InterfacesCisco Systems IncCisco Systems IncAlef EdgeJuniper NetworksIndividual This document defines a YANG data model for the provisioning and
management of Traffic Engineering (TE) tunnels, Label Switched Paths
(LSPs), and interfaces. The model covers data that is independent of
any technology or dataplane encapsulation and is divided into two
YANG modules that cover device-specific, and device independent data.
This model covers data for configuration, operational state, remote
procedural calls, and event notifications.
Work in ProgressPerformance ConstraintsAt the creation of a VN, it is natural to provide VN-level constraints and optimization criteria. It should be noted that the VN YANG data model described in this document relies on the TE Topology model in by using a reference to an abstract node to provide VN-level constraints and optimization criteria. Further, the connectivity-matrix structure is used to assign the constraints and optimization criteria including delay, jitter, etc. defines some of the metric-types; future documents are meant to augment it.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 independently.JSON ExampleVN JSON
This section provides JSON examples of how the VN YANG
data model and TE Topology YANG data model are used together to instantiate a VN.
The example in this section includes the following VNs:
VN1 (Type 1): This VN maps to the single node topology abstract1
and consists of VN members 104 (L1 to L4), 107 (L1 to
L7), 204 (L2 to L4), 308 (L3 to L8), and 108 (L1 to L8).
VN2 (Type 2): This VN maps to the single node topology abstract2;
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 S7) has been set in the
connectivity matrix of the abstract2 topology;
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)
showcase multi-dest and VN member 108 (L1 to L8) and 308 (L3 to L8) showcase the multi-src feature. The selected VN member is known via the field "if-selected" and the corresponding connectivity-matrix-id.
abstract1: a single node TE topology referenced by VN1. We also
show how disjointness (node, link, Shared Risk Link Group (SRLG)) is supported in the example on the connectivity matrices.
abstract2: a single node TE topology referenced by VN2 with an underlay path.
underlay: the topology with multiple nodes (in the underlay path of abstract2). For brevity, the example includes only the node: other parameters are not included.
abstract3: a single node TE topology referenced by VN3.