| TEAS Working Group | Y. Lee, Ed. |
| Internet-Draft | Samsung Electronics |
| Intended status: Standards Track | D. Dhody, Ed. |
| Expires: January 14, 2021 | Huawei Technologies |
| D. Ceccarelli | |
| Ericsson | |
| I. Bryskin | |
| Individual | |
| B. Yoon | |
| ETRI | |
| July 13, 2020 |
A YANG Data Model for VN Operation
draft-ietf-teas-actn-vn-yang-09
This document provides a YANG data model generally applicable to any mode of Virtual Network (VN) operation.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 14, 2021.
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document provides a YANG [RFC7950] data model generally applicable to any mode of Virtual Network (VN) operation.
The VN model defined in this document is applicable in generic sense as an independent model in and of itself. The VN model defined in this document can also work together with other customer service models such as L3SM [RFC8299], L2SM [RFC8466] and L1CSM [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 following:
The actual VN instantiation and computation is performed with Connectivity Matrices sub-module of TE-Topology Model [I-D.ietf-teas-yang-te-topo] which provides TE network topology abstraction and management operation. Once TE-topology Model is used in triggering VN instantiation over the networks, TE-tunnel [I-D.ietf-teas-yang-te] Model will inevitably interact with TE-Topology model for setting up actual tunnels and LSPs under the tunnels.
Abstraction and Control of Traffic Engineered Networks (ACTN) describes a set of management and control functions used to operate one or more TE networks to construct virtual networks that can be represented to customers and that are built from abstractions of the underlying TE networks [RFC8453]. ACTN is the primary example of the usage of the VN YANG model.
Sections 2 and 3 provide the discussion of how the VN YANG model is applicable to the ACTN context where Virtual Network Service (VNS) operation is implemented for the Customer Network Controller (CNC)- Multi-Domain Service Coordinator (MSDC) interface (CMI).
The YANG model on the CMI is also known as customer service model in [RFC8309]. The YANG model discussed in this document is used to operate customer-driven VNs during the VN instantiation, VN computation, and 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) [RFC8342]. The origin of the data is indicated as per the origin metadata annotation.
Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used in this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
A simplified graphical representation of the data model is used in Section 5 of this this document. The meaning of the symbols in these diagrams is defined in [RFC8340].
In this document, 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 Table 1.
| Prefix | YANG module | Reference |
|---|---|---|
| vn | ietf-vn | [RFCXXXX] |
| inet | ietf-inet-types | [RFC6991] |
| nw | ietf-network | [RFC8345] |
| nt | ietf-network-topology | [RFC8345] |
| te-types | ietf-te-types | [RFC8776] |
| te-topo | ietf-te-topology | [I-D.ietf-teas-yang-te-topo] |
Note: The RFC Editor will replace XXXX with the number assigned to the RFC once this draft becomes an RFC.
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 following ACTN context.
+-------+
| CNC |
+-------+
|
| VN YANG + TE-topology YANG
|
+-----------------------+
| MDSC |
+-----------------------+
Figure 1: ACTN CMI
Both ACTN VN YANG and TE-topology models are used over the CMI to establish a VN over TE networks.
As defined in [RFC8453], a Virtual Network is a customer view of the TE network. To recapitulate VN types from [RFC8453], 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.
VN-Member 1 L1-L4
VN-Member 2 L1-L7
VN-Member 3 L2-L4
VN-Member 4 L3-L8
This VN can be modeled as one abstract node representation as follows in Figure 2:
+---------------+
L1 ------| |------ L4
L2 ------| AN 1 |------ L7
L3 ------| |------ L8
+---------------+
Figure 2: Abstract Node (One node topology)
Modeling a VN as one abstract node is the easiest way for customers to express their end-to-end connectivity; however, customers are not limited to express their VN only with one abstract node.
For some VN members of a VN, the customers are allowed to configure the actual path (i.e., detailed virtual nodes and virtual links) over the VN/abstract topology agreed mutually between CNC and MDSC prior to or a topology created by the MDSC as part of VN instantiation. Type 1 VN is a higher abstraction of a Type 2 VN.
If a Type 2 VN is desired for some or all of VN members of a type 1 VN (see the example in Section 2.1), the TE-topology model can provide the following abstract topology (that consists of virtual nodes and virtual links) which is built under the Type 1 VN.
+----------------------------------------------+
| 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-----|-- |
| |
+----------------------------------------------+
Figure 3: Type 2 topology
As you see from Figure 3, the Type 1 abstract node is depicted as a Type 1 abstract topology comprising of detailed virtual nodes and virtual links.
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 ERO {S3,S4,S5} based on the topology and its service requirement. This capability is enacted via TE-topology configuration by the customer.
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 Access Points.
This VN can be modeled as one abstract node representation as follows:
+---------------+
L1 ------| |------ L4
L2 ------| AN 1 |------ L7
L3 ------| |------ L8
+---------------+
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 Models.
+--------+ +--------+
| CNC | | MDSC |
+--------+ +--------+
| |
| |
CNC POST TE-topo | POST /nw:networks/nw:network/ |
model(with Conn. | nw:node/te-node-id/ |
Matrix on one | tet:connectivity-matrices/ |
Abstract node | tet:connectivity-matrix |
|-------------------------------->|
| HTTP 200 |
|<--------------------------------|
| |
CNC POST the | POST /VN |
VN identifying |-------------------------------->| If there is
AP, VNAP and VN- | | multi-src/dest
Members and maps | | then MDSC
to the TE-topo | HTTP 200 | selects a
|<--------------------------------| src or dest
| | and update
| | VN YANG
CNC GET the | GET /VN |
VN YANG status |-------------------------------->|
| |
| HTTP 200 (VN with status: |
| selected VN-members |
| in case of multi s-d) |
|<--------------------------------|
| |
For some VN members, the customer may want to "configure" explicit routes over the path that connects its two end-points. Let us consider the following example.
Where the following topology is the underlay for Abstraction Node 1 (AN1).
AN1
............................................
. S1 S2 .
. O---------------O .
. ________/ \______ \ .
. / \ \ .
. S3/ \ S4 \ S5 .
L1----.-O----------------------O---------O-------.----------L4
. \ \ \ .
. \ \ \ .
. \ S6 \ S7 \ S8 .
. O ----------------O---------O---.----------L5
. / \ / \ ____/ \__.__________L6
.S9 / \ /S10 \ / .
L2-----.---O-----O---------------------O----------.----------L7
. / S11\_________.__________L8
L3-----.-- .
............................................
There are two options depending on whether CNC or MDSC creates the single abstract node topology.
Case 1:
If CNC creates the single abstract node topology, the following diagram shows the message flow between CNC and MDSC to instantiate this VN using VN and TE-Topology Model.
+--------+ +--------+
| CNC | | MDSC |
+--------+ +--------+
| |
| |
CNC POST TE-topo | POST /nw:networks/nw:network/ |
model(with 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 /VN |
VN identifying |---------------------------------------->|
AP, VNAP and VN- | |
Members and maps | |
to the TE-topo | HTTP 200 |
|<----------------------------------------|
| |
| |
CNC GET the | GET /VN |
VN YANG status |---------------------------------------->|
| |
| HTTP 200 (VN with status) |
|<----------------------------------------|
| |
Case 2:
On the other hand, if MDSC create the single abstract node topology based 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 Models.
+--------+ +--------+
| CNC | | MDSC |
+--------+ +--------+
| |
| |
CNC POST VN | |
Identifying AP, | |
VNAP and VN- | POST /VN | MDSC populates
Members |-------------------------------->| a single Abst.
| HTTP 200 | node topology
|<--------------------------------| by itself
| |
CNC GET VN & | GET /VN & |
POST TE-Topo | POST /nw:networks/nw:network/ |
Models (with | nw:node/te-node-id/tet: |
Conn. Matrix on | connectivity-matrices/ |
| tet:connectivity-matrix |
the Abstract Node|-------------------------------->|
and explicit | |
paths in the | |
Conn. Matrix | |
| HTTP 200 |
|<--------------------------------|
| |
| |
CNC GET the | GET /VN |
VN YANG status |-------------------------------->|
| |
| HTTP 200 (VN with status) |
|<--------------------------------|
| |
Section 7 provides JSON examples for both VN model and TE-topology Connectivity Matrix sub-model to illustrate how a VN can be created by the CNC making use of the VN module as well as the TE-topology Connectivity Matrix module.
The 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 Section 6 of [RFC8453].
In some VN operations, the customer access may not be known at the initial VN creation. The VN operation allow a creation of VN with only PE identifier as well. The customer access information could be added later.
To achieve this the 'ap' container has a leaf for 'pe' node that allows AP to be created with PE information. The vn-member (and vn) could use APs that only have PE information initially.
The VN-YANG model allows to define a customer view, and allows the customer to communicate using the VN constructs as described in the [RFC8454]. It also allows to group the set 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 models.
This is similar to the benefits of having a separate YANG model for the customer services as described in [RFC8309], which states that service models do not make any assumption of how a service is actually engineered and delivered for a customer.
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 configured, but created automatically by the MDSC based on the customer service model and local policy, even in these case the VN YANG model can be used by the CNC to learn details of the underlying VN created to meet the requirements of customer service model.
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.
In creating a virtual network, the list of sources or destinations or both may not be pre-determined 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 module is shown for describing source container and destination container. The following YANG tree shows how to model multi-sources and multi-destinations.
+--rw vn
+--rw vn-list* [vn-id]
+--rw vn-id vn-id
+--rw vn-topology-id? te-types:te-topology-id
+--rw abstract-node?
| -> /nw:networks/network/node/tet:te-node-id
+--rw vn-member-list* [vn-member-id]
| +--rw vn-member-id vn-member-id
| +--rw src
| | +--rw src?
| | | -> /ap/access-point-list/access-point-id
| | +--rw src-vn-ap-id?
| | | -> /ap/access-point-list/vn-ap/vn-ap-id
| | +--rw multi-src? boolean {multi-src-dest}?
| +--rw dest
| | +--rw dest?
| | | -> /ap/access-point-list/access-point-id
| | +--rw dest-vn-ap-id?
| | | -> /ap/access-point-list/vn-ap/vn-ap-id
| | +--rw multi-dest? boolean {multi-src-dest}?
| +--rw connectivity-matrix-id? leafref
| +--ro oper-status? identityref
+--ro if-selected? boolean {multi-src-dest}?
+--rw admin-status? identityref
+--ro oper-status? identityref
+--rw vn-level-diversity? te-types:te-path-disjointness
The VN YANG model can be easily augmented to support the mapping of VN to the Services such as L3SM and L2SM as described in [I-D.ietf-teas-te-service-mapping-yang].
The VN YANG model can be extended to support telemetry, performance monitoring and network autonomics as described in [I-D.ietf-teas-actn-pm-telemetry-autonomics].
This section summarizes the innovative service features of the VN YANG.
module: ietf-vn
+--rw ap
| +--rw access-point-list* [access-point-id]
| +--rw access-point-id access-point-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* [vn-ap-id]
| +--rw vn-ap-id access-point-id
| +--rw vn? -> /vn/vn-list/vn-id
| +--rw abstract-node?
| | -> /nw:networks/network/node/tet:te-node-id
| +--rw ltp? leafref
| +--ro max-bandwidth? te-types:te-bandwidth
+--rw vn
+--rw vn-list* [vn-id]
+--rw vn-id vn-id
+--rw vn-topology-id? te-types:te-topology-id
+--rw abstract-node?
| -> /nw:networks/network/node/tet:te-node-id
+--rw vn-member-list* [vn-member-id]
| +--rw vn-member-id vn-member-id
| +--rw src
| | +--rw src?
| | | -> /ap/access-point-list/access-point-id
| | +--rw src-vn-ap-id?
| | | -> /ap/access-point-list/vn-ap/vn-ap-id
| | +--rw multi-src? boolean {multi-src-dest}?
| +--rw dest
| | +--rw dest?
| | | -> /ap/access-point-list/access-point-id
| | +--rw dest-vn-ap-id?
| | | -> /ap/access-point-list/vn-ap/vn-ap-id
| | +--rw multi-dest? boolean {multi-src-dest}?
| +--rw connectivity-matrix-id? leafref
| +--ro oper-status? identityref
+--ro if-selected? boolean {multi-src-dest}?
+--rw admin-status? identityref
+--ro oper-status? identityref
+--rw vn-level-diversity? te-types:te-path-disjointness
rpcs:
+---x vn-compute
+---w input
| +---w abstract-node?
| | -> /nw:networks/network/node/tet:te-node-id
| +---w vn-member-list* [vn-member-id]
| | +---w vn-member-id vn-member-id
| | +---w src
| | | +---w src?
| | | | -> /ap/access-point-list/access-point-id
| | | +---w src-vn-ap-id?
| | | | -> /ap/access-point-list/vn-ap/vn-ap-id
| | | +---w multi-src? boolean {multi-src-dest}?
| | +---w dest
| | | +---w dest?
| | | | -> /ap/access-point-list/access-point-id
| | | +---w dest-vn-ap-id?
| | | | -> /ap/access-point-list/vn-ap/vn-ap-id
| | | +---w multi-dest? boolean {multi-src-dest}?
| | +---w connectivity-matrix-id? leafref
| +---w vn-level-diversity? te-types:te-path-disjointness
+--ro output
+--ro vn-member-list* [vn-member-id]
+--ro vn-member-id vn-member-id
+--ro src
| +--ro src?
| | -> /ap/access-point-list/access-point-id
| +--ro src-vn-ap-id?
| | -> /ap/access-point-list/vn-ap/vn-ap-id
| +--ro multi-src? boolean {multi-src-dest}?
+--ro dest
| +--ro dest?
| | -> /ap/access-point-list/access-point-id
| +--ro dest-vn-ap-id?
| | -> /ap/access-point-list/vn-ap/vn-ap-id
| +--ro multi-dest? boolean {multi-src-dest}?
+--ro connectivity-matrix-id? leafref
+--ro if-selected? boolean
| {multi-src-dest}?
+--ro compute-status? identityref
The YANG model is as follows:
<CODE BEGINS> file "ietf-vn@2020-07-13.yang"
module ietf-vn {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-vn";
prefix vn;
/* Import inet-types */
import ietf-inet-types {
prefix inet;
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
"I-D.ietf-teas-yang-te-topo: YANG Data Model for Traffic
Engineering (TE) Topologies";
}
organization
"IETF Traffic Engineering Architecture and Signaling (TEAS)
Working Group";
contact
"WG Web: <https://tools.ietf.org/wg/teas/>
WG List: <mailto:teas@ietf.org>
Editor: Young Lee <younglee.tx@gmail.com>
: Dhruv Dhody <dhruv.ietf@gmail.com>";
description
"This module contains a YANG module for the VN. It describes a
VN operation module that takes place in the context of the
CNC-MDSC Interface (CMI) of the ACTN architecture where the
CNC is the actor of a VN Instantiation/modification/deletion
as per RFC 8453.
Copyright (c) 2020 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 Simplified 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 XXXX; see the
RFC itself for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.";
revision 2020-07-13 {
description
"initial version.";
reference
"RFC XXXX: A YANG Data Model for VN Operation";
}
/* Features */
feature multi-src-dest {
description
"Support for selection of one src or destination
among multiple.";
reference
"RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN)";
}
/* Identity VN State*/
identity vn-state-type {
description
"Base identity for VN state";
}
identity vn-state-up {
base vn-state-type;
description
"VN state up";
}
identity vn-state-down {
base vn-state-type;
description
"VN state down";
}
/* Identity VN Admin State*/
identity vn-admin-state-type {
description
"Base identity for VN admin states";
}
identity vn-admin-state-up {
base vn-admin-state-type;
description
"VN administratively state up";
}
identity vn-admin-state-down {
base vn-admin-state-type;
description
"VN administratively state down";
}
/* Identity VN Compute State*/
identity vn-compute-state-type {
description
"Base identity for compute states";
}
identity vn-compute-state-computing {
base vn-compute-state-type;
description
"State path compute in progress";
}
identity vn-compute-state-computation-ok {
base vn-compute-state-type;
description
"State path compute successful";
}
identity vn-compute-state-computation-failed {
base vn-compute-state-type;
description
"State path compute failed";
}
/* Typedef */
typedef vn-id {
type inet:uri;
description
"Identifier for a VN. The precise structure of the
vn-id will be up to the implementation. The
identifier SHOULD be chosen such that the same VN
will always be identified through the same
identifier, even if the data model is instantiated
in separate datastores.";
}
typedef access-point-id {
type inet:uri;
description
"Identifier for an AP. The precise structure of the
access-point-id will be up to the implementation.
The identifier SHOULD be chosen such that the same AP
will always be identified through the same
identifier, even if the data model is instantiated
in separate datastores. This type is used for both AP
and VNAP";
}
typedef vn-member-id {
type inet:uri;
description
"Identifier for a VN member. The precise structure of
the vn-member-id will be up to the implementation.
The identifier SHOULD be chosen such that the same VN
member will always be identified through the same
identifier, even if the data model is instantiated
in separate datastores. ";
}
/* Groupings */
grouping vn-ap {
description
"VNAP related information";
leaf vn-ap-id {
type access-point-id;
description
"A unique identifier for the referred VNAP";
}
leaf vn {
type leafref {
path "/vn/vn-list/vn-id";
}
description
"A reference to the VN";
}
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 that
represent the VN";
}
leaf ltp {
type leafref {
path "/nw:networks/nw:network/nw:node/"
+ "nt:termination-point/tet:te-tp-id";
}
description
"A reference LTP in the TE-topology";
reference
"I-D.ietf-teas-yang-te-topo: 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";
}
reference
"RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN)";
} //vn-ap
grouping access-point {
description
"AP related information";
leaf access-point-id {
type access-point-id;
description
"A unique identifier for the referred access point";
}
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";
}
/*add details and any other properties of AP,
not associated by a VN
CE port, PE port etc.
*/
list vn-ap {
key "vn-ap-id";
uses vn-ap;
description
"List of VNAP in this AP";
}
reference
"RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN)";
} //access-point
grouping vn-member {
description
"The vn-member is described by this grouping";
leaf vn-member-id {
type vn-member-id;
description
"A vn-member identifier";
}
container src {
description
"The source of VN Member";
leaf src {
type leafref {
path "/ap/access-point-list/access-point-id";
}
description
"A reference to source AP";
}
leaf src-vn-ap-id {
type leafref {
path "/ap/access-point-list/vn-ap/vn-ap-id";
}
description
"A reference to source VNAP";
}
leaf multi-src {
if-feature "multi-src-dest";
type boolean;
description
"Is the source part of multi-source, where
only one of the source is enabled";
}
}
container dest {
description
"the destination of VN Member";
leaf dest {
type leafref {
path "/ap/access-point-list/access-point-id";
}
description
"A reference to destination AP";
}
leaf dest-vn-ap-id {
type leafref {
path "/ap/access-point-list/vn-ap/vn-ap-id";
}
description
"A reference to dest VNAP";
}
leaf multi-dest {
if-feature "multi-src-dest";
type boolean;
description
"Is destination part of multi-destination, where only one
of the destination 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 connectivity-matrix";
reference
"I-D.ietf-teas-yang-te-topo: YANG Data Model for Traffic
Engineering (TE) Topologies";
}
reference
"RFC 8454: Information Model for Abstraction and Control of TE
Networks (ACTN)";
} //vn-member
grouping vn-policy {
description
"policy for VN-level diverisity";
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 ap {
description
"AP configurations";
list access-point-list {
key "access-point-id";
description
"access-point identifier";
uses access-point {
description
"The access-point information";
}
}
reference
"RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN)";
}
container vn {
description
"VN configurations";
list vn-list {
key "vn-id";
description
"A virtual network is identified by a vn-id";
leaf vn-id {
type vn-id;
description
"A unique VN identifier";
}
leaf vn-topology-id {
type te-types:te-topology-id;
description
"An optional identifier to the TE Topology Model where the
abstract nodes and links of the Topology can be found for
Type 2 VNS";
}
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 "vn-member-id";
description
"List of vn-members in a VN";
uses vn-member;
leaf oper-status {
type identityref {
base vn-state-type;
}
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 is selected among the multi-src/dest
options";
}
leaf admin-status {
type identityref {
base vn-admin-state-type;
}
default "vn-admin-state-up";
description
"VN administrative state.";
}
leaf oper-status {
type identityref {
base vn-state-type;
}
config false;
description
"VN operational state.";
}
uses vn-policy;
} //vn-list
reference
"RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN)";
} //vn
/* RPC */
rpc vn-compute {
description
"The VN computation without actual instantiation";
input {
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 "vn-member-id";
description
"List of VN-members in a VN";
uses vn-member;
}
uses vn-policy;
}
output {
list vn-member-list {
key "vn-member-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 is selected among the multi-src/dest
options";
}
leaf compute-status {
type identityref {
base vn-compute-state-type;
}
description
"The VN-member compute state.";
}
}
}
} //vn-compute
}
<CODE ENDS>
This section provides json implementation examples as to how VN YANG model and TE topology model are used together to instantiate virtual networks.
The example in this section includes following VN
Note that the VN YANG model also include the AP and VNAP which shows various VN using the same AP.
{
"ap":{
"access-point-list": [
{
"access-point-id": 101,
"access-point-name": "101",
"vn-ap": [
{
"vn-ap-id": 10101,
"vn": 1,
"abstract-node": "D1",
"ltp": "1-0-1"
},
{
"vn-ap-id": 10102,
"vn": 2,
"abstract-node": "D2",
"ltp": "1-0-1"
},
{
"vn-ap-id": 10103,
"vn": 3,
"abstract-node": "D3",
"ltp": "1-0-1"
},
]
},
{
"access-point-id": 202,
"access-point-name": "202",
"vn-ap": [
{
"vn-ap-id": 20201,
"vn": 1,
"abstract-node": "D1",
"ltp": "2-0-2"
}
]
},
{
"access-point-id": 303,
"access-point-name": "303",
"vn-ap": [
{
"vn-ap-id": 30301,
"vn": 1,
"abstract-node": "D1",
"ltp": "3-0-3"
},
{
"vn-ap-id": 30303,
"vn": 3,
"abstract-node": "D3",
"ltp": "3-0-3"
}
]
},
{
"access-point-id": 440,
"access-point-name": "440",
"vn-ap": [
{
"vn-ap-id": 44001,
"vn": 1,
"abstract-node": "D1",
"ltp": "4-4-0"
}
]
},
{
"access-point-id": 550,
"access-point-name": "550",
"vn-ap": [
{
"vn-ap-id": 55002,
"vn": 2,
"abstract-node": "D2",
"ltp": "5-5-0"
}
]
},
{
"access-point-id": 770,
"access-point-name": "770",
"vn-ap": [
{
"vn-ap-id": 77001,
"vn": 1,
"abstract-node": "D1",
"ltp": "7-7-0"
},
{
"vn-ap-id": 77003,
"vn": 3,
"abstract-node": "D3",
"ltp": "7-7-0"
}
]
},
{
"access-point-id": 880,
"access-point-name": "880",
"vn-ap": [
{
"vn-ap-id": 88001,
"vn": 1,
"abstract-node": "D1",
"ltp": "8-8-0"
},
{
"vn-ap-id": 88003,
"vn": 3,
"abstract-node": "D3",
"ltp": "8-8-0"
}
]
}
]
},
"vn":{
"vn-list": [
{
"vn-id": 1,
"vn-name": "vn1",
"vn-topology-id": "te-topology:abstract1",
"abstract-node": "D1",
"vn-member-list": [
{
"vn-member-id": 104,
"src": {
"src": 101,
"src-vn-ap-id": 10101,
},
"dest": {
"dest": 440,
"dest-vn-ap-id": 44001,
},
"connectivity-matrix-id": 104
},
{
"vn-member-id": 107,
"src": {
"src": 101,
"src-vn-ap-id": 10101,
},
"dest": {
"dest": 770,
"dest-vn-ap-id": 77001,
},
"connectivity-matrix-id": 107
},
{
"vn-member-id": 204,
"src": {
"src": 202,
"dest-vn-ap-id": 20401,
},
"dest": {
"dest": 440,
"dest-vn-ap-id": 44001,
},
"connectivity-matrix-id": 204
},
{
"vn-member-id": 308,
"src": {
"src": 303,
"src-vn-ap-id": 30301,
},
"dest": {
"dest": 880,
"src-vn-ap-id": 88001,
},
"connectivity-matrix-id": 308
},
{
"vn-member-id": 108,
"src": {
"src": 101,
"src-vn-ap-id": 10101,
},
"dest": {
"dest": 880,
"dest-vn-ap-id": 88001,
},
"connectivity-matrix-id": 108
}
]
},
{
"vn-id": 2,
"vn-name": "vn2",
"vn-topology-id": "te-topology:abstract2",
"abstract-node": "D2",
"vn-member-list": [
{
"vn-member-id": 105,
"src": {
"src": 101,
"src-vn-ap-id": 10102,
},
"dest": {
"dest": 550,
"dest-vn-ap-id": 55002,
},
"connectivity-matrix-id": 105
}
]
},
{
"vn-id": 3,
"vn-name": "vn3",
"vn-topology-id": "te-topology:abstract3",
"abstract-node": "D3",
"vn-member-list": [
{
"vn-member-id": 104,
"src": {
"src": 101,
},
"dest": {
"dest": 440,
"multi-dest": true
}
},
{
"vn-member-id": 107,
"src": {
"src": 101,
"src-vn-ap-id": 10103,
},
"dest": {
"dest": 770,
"dest-vn-ap-id": 77003,
"multi-dest": true
},
"connectivity-matrix-id": 107,
"if-selected":true,
},
{
"vn-member-id": 204,
"src": {
"src": 202,
"multi-src": true,
},
"dest": {
"dest": 440,
},
},
{
"vn-member-id": 304,
"src": {
"src": 303,
"src-vn-ap-id": 30303,
"multi-src": true,
},
"dest": {
"dest": 440,
"src-vn-ap-id": 44003,
},
"connectivity-matrix-id": 304,
"if-selected":true,
},
]
},
]
}
}
}
{
"networks": {
"network": [
{
"network-types": {
"te-topology": {}
},
"network-id": "abstract1",
"provider-id": 201,
"client-id": 600,
"te-topology-id": "te-topology:abstract1",
"node": [
{
"node-id": "D1",
"te-node-id": "2.0.1.1",
"te": {
"te-node-attributes": {
"domain-id" : 1,
"is-abstract": [null],
"connectivity-matrices": {
"is-allowed": true,
"path-constraints": {
"bandwidth-generic": {
"te-bandwidth": {
"generic": [
{
"generic": "0x1p10",
}
]
}
}
"disjointness": "node link srlg",
},
"connectivity-matrix": [
{
"id": 104,
"from": "1-0-1",
"to": "4-4-0"
},
{
"id": 107,
"from": "1-0-1",
"to": "7-7-0"
},
{
"id": 204,
"from": "2-0-2",
"to": "4-4-0"
},
{
"id": 308,
"from": "3-0-3",
"to": "8-8-0"
},
{
"id": 108,
"from": "1-0-1",
"to": "8-8-0"
},
]
}
}
},
"termination-point": [
{
"tp-id": "1-0-1",
"te-tp-id": 10001,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "1-1-0",
"te-tp-id": 10100,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "2-0-2",
"te-tp-id": 20002,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "2-2-0",
"te-tp-id": 20200,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "3-0-3",
"te-tp-id": 30003,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "3-3-0",
"te-tp-id": 30300,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "4-0-4",
"te-tp-id": 40004,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "4-4-0",
"te-tp-id": 40400,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "5-0-5",
"te-tp-id": 50005,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "5-5-0",
"te-tp-id": 50500,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "6-0-6",
"te-tp-id": 60006,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "6-6-0",
"te-tp-id": 60600,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "7-0-7",
"te-tp-id": 70007,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "7-7-0",
"te-tp-id": 70700,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "8-0-8",
"te-tp-id": 80008,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "8-8-0",
"te-tp-id": 80800,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
}
]
}
]
},
{
"network-types": {
"te-topology": {}
},
"network-id": "abstract2",
"provider-id": 201,
"client-id": 600,
"te-topology-id": "te-topology:abstract2",
"node": [
{
"node-id": "D2",
"te-node-id": "2.0.1.2",
"te": {
"te-node-attributes": {
"domain-id" : 1,
"is-abstract": [null],
"connectivity-matrices": {
"is-allowed": true,
"underlay": {
"enabled": true
},
"path-constraints": {
"bandwidth-generic": {
"te-bandwidth": {
"generic": [
{
"generic": "0x1p10"
}
]
}
}
},
"optimizations": {
"objective-function": {
"objective-function-type":
"of-maximize-residual-bandwidth"
}
},
"connectivity-matrix": [
{
"id": 105,
"from": "1-0-1",
"to": "5-5-0",
"underlay": {
"enabled": true,
"primary-path": {
"network-ref": "absolute",
"path-element": [
{
"path-element-id": 1,
"index": 1,
"numbered-hop": {
"address": "4.4.4.4",
"hop-type": "STRICT"
}
},
{
"path-element-id": 2,
"index": 2,
"numbered-hop": {
"address": "7.7.7.7",
"hop-type": "STRICT"
}
}
]
}
}
}
]
}
}
},
"termination-point": [
{
"tp-id": "1-0-1",
"te-tp-id": 10001,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "1-1-0",
"te-tp-id": 10100,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "2-0-2",
"te-tp-id": 20002,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "2-2-0",
"te-tp-id": 20200,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "3-0-3",
"te-tp-id": 30003,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "3-3-0",
"te-tp-id": 30300,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "4-0-4",
"te-tp-id": 40004,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "4-4-0",
"te-tp-id": 40400,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "5-0-5",
"te-tp-id": 50005,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "5-5-0",
"te-tp-id": 50500,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "6-0-6",
"te-tp-id": 60006,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "6-6-0",
"te-tp-id": 60600,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "7-0-7",
"te-tp-id": 70007,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "7-7-0",
"te-tp-id": 70700,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "8-0-8",
"te-tp-id": 80008,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "8-8-0",
"te-tp-id": 80800,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
}
]
}
]
},
{
"network-types": {
"te-topology": {}
},
"network-id": "abstract3",
"provider-id": 201,
"client-id": 600,
"te-topology-id": "te-topology:abstract3",
"node": [
{
"node-id": "D3",
"te-node-id": "3.0.1.1",
"te": {
"te-node-attributes": {
"domain-id" : 3,
"is-abstract": [null],
"connectivity-matrices": {
"is-allowed": true,
"path-constraints": {
"bandwidth-generic": {
"te-bandwidth": {
"generic": [
{
"generic": "0x1p10",
}
]
}
}
},
"connectivity-matrix": [
{
"id": 107,
"from": "1-0-1",
"to": "7-7-0"
},
{
"id": 308,
"from": "3-0-3",
"to": "8-8-0"
},
]
}
}
},
"termination-point": [
{
"tp-id": "1-0-1",
"te-tp-id": 10001,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "1-1-0",
"te-tp-id": 10100,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "2-0-2",
"te-tp-id": 20002,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "2-2-0",
"te-tp-id": 20200,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "3-0-3",
"te-tp-id": 30003,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "3-3-0",
"te-tp-id": 30300,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "4-0-4",
"te-tp-id": 40004,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "4-4-0",
"te-tp-id": 40400,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "5-0-5",
"te-tp-id": 50005,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "5-5-0",
"te-tp-id": 50500,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "6-0-6",
"te-tp-id": 60006,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "6-6-0",
"te-tp-id": 60600,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "7-0-7",
"te-tp-id": 70007,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "7-7-0",
"te-tp-id": 70700,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "8-0-8",
"te-tp-id": 80008,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
},
{
"tp-id": "8-8-0",
"te-tp-id": 80800,
"te": {
"interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
}
]
}
}
]
}
]
},
]
}
}
The configuration, state, and action data defined in this document are designed to be accessed via a management protocol with a secure transport layer, such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory- to-implement secure transport is TLS [RFC8446].
The NETCONF access control model [RFC8341] provides the means to restrict access for particular NETCONF users to a preconfigured subset of all available NETCONF protocol operations and content.
The model presented in this document is used in the interface between the Customer Network Controller (CNC) and Multi-Domain Service Coordinator (MDSC), which is referred to as CNC-MDSC Interface (CMI). Therefore, many security risks such as malicious attack and rogue elements attempting to connect to various ACTN components. Furthermore, some ACTN components (e.g., MSDC) represent a single point of failure and threat vector and must also manage policy conflicts and eavesdropping of communication between different ACTN components.
A number of configuration data nodes defined in this document are writable/deletable (i.e., "config true") These data nodes may be considered sensitive or vulnerable in some network environments.
These are the subtrees and data nodes and their sensitivity/vulnerability:
This document registers the following namespace URIs in the IETF XML registry [RFC3688]:
-------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:ietf-vn Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. --------------------------------------------------------------------
This document registers the following YANG modules in the YANG Module Names registry [RFC6020]:
-------------------------------------------------------------------- name: ietf-vn namespace: urn:ietf:params:xml:ns:yang:ietf-vn prefix: vn reference: RFC XXXX (TDB) --------------------------------------------------------------------
The authors would like to thank Xufeng Liu, Adrian Farrel, Tom Petch, and Kenichi Ogaki for their helpful comments and valuable suggestions.
At the time of creation of VN, it is natural to provide VN level constraints and optimization criteria. It should be noted that this YANG model rely on the TE-Topology Model [I-D.ietf-teas-yang-te-topo] by using a reference to an abstract node to achieve this. Further, connectivity-matrix structure is used to assign the constraints and optimization criteria include delay, jitter etc. [RFC8776] define some of the metric-types already and future documents are meant to augment it.
Qin Wu Huawei Technologies Email: bill.wu@huawei.com Peter Park KT Email: peter.park@kt.com Haomian Zheng Huawei Technologies Email: zhenghaomian@huawei.com Xian Zhang Huawei Technologies Email: zhang.xian@huawei.com Sergio Belotti Nokia Email: sergio.belotti@nokia.com Takuya Miyasaka KDDI Email: ta-miyasaka@kddi.com