draft-ietf-teas-actn-vn-yang-08.txt   draft-ietf-teas-actn-vn-yang-09.txt 
TEAS Working Group Y. Lee, Ed. TEAS Working Group Y. Lee, Ed.
Internet-Draft Samsung Electronics Internet-Draft Samsung Electronics
Intended status: Standards Track D. Dhody, Ed. Intended status: Standards Track D. Dhody, Ed.
Expires: September 9, 2020 Huawei Technologies Expires: January 14, 2021 Huawei Technologies
D. Ceccarelli D. Ceccarelli
Ericsson Ericsson
I. Bryskin I. Bryskin
Individual Individual
B. Yoon B. Yoon
ETRI ETRI
March 8, 2020 July 13, 2020
A Yang Data Model for VN Operation A YANG Data Model for VN Operation
draft-ietf-teas-actn-vn-yang-08 draft-ietf-teas-actn-vn-yang-09
Abstract Abstract
This document provides a YANG data model generally applicable to any This document provides a YANG data model generally applicable to any
mode of Virtual Network (VN) operation. mode of Virtual Network (VN) operation.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 9, 2020. This Internet-Draft will expire on January 14, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1. Requirements Language . . . . . . . . . . . . . . . . 4
1.2. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 4 1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 4
2. Use-case of VN Yang Model in the ACTN context . . . . . . . . 4 2. Use-case of VN YANG Model in the ACTN context . . . . . . . . 5
2.1. Type 1 VN . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Type 1 VN . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Type 2 VN . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Type 2 VN . . . . . . . . . . . . . . . . . . . . . . . . 6
3. High-Level Control Flows with Examples . . . . . . . . . . . 7 3. High-Level Control Flows with Examples . . . . . . . . . . . 7
3.1. Type 1 VN Illustration . . . . . . . . . . . . . . . . . 7 3.1. Type 1 VN Illustration . . . . . . . . . . . . . . . . . 7
3.2. Type 2 VN Illustration . . . . . . . . . . . . . . . . . 8 3.2. Type 2 VN Illustration . . . . . . . . . . . . . . . . . 8
3.2.1. VN and AP Usage . . . . . . . . . . . . . . . . . . . 11 3.2.1. VN and AP Usage . . . . . . . . . . . . . . . . . . . 11
4. VN Model Usage . . . . . . . . . . . . . . . . . . . . . . . 12 4. VN Model Usage . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Customer view of VN . . . . . . . . . . . . . . . . . . . 12 4.1. Customer view of VN . . . . . . . . . . . . . . . . . . . 12
4.2. Auto-creation of VN by MDSC . . . . . . . . . . . . . . . 12 4.2. Auto-creation of VN by MDSC . . . . . . . . . . . . . . . 12
4.3. Innovative Services . . . . . . . . . . . . . . . . . . . 12 4.3. Innovative Services . . . . . . . . . . . . . . . . . . . 12
4.3.1. VN Compute . . . . . . . . . . . . . . . . . . . . . 12 4.3.1. VN Compute . . . . . . . . . . . . . . . . . . . . . 12
4.3.2. Multi-sources and Multi-destinations . . . . . . . . 12 4.3.2. Multi-sources and Multi-destinations . . . . . . . . 12
4.3.3. Others . . . . . . . . . . . . . . . . . . . . . . . 13 4.3.3. Others . . . . . . . . . . . . . . . . . . . . . . . 13
4.3.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 14 4.3.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 14
5. VN YANG Model (Tree Structure) . . . . . . . . . . . . . . . 14 5. VN YANG Model (Tree Structure) . . . . . . . . . . . . . . . 14
6. VN YANG Code . . . . . . . . . . . . . . . . . . . . . . . . 16 6. VN YANG Model . . . . . . . . . . . . . . . . . . . . . . . . 16
7. JSON Example . . . . . . . . . . . . . . . . . . . . . . . . 26 7. JSON Example . . . . . . . . . . . . . . . . . . . . . . . . 27
7.1. VN JSON . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.1. VN JSON . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.2. TE-topology JSON . . . . . . . . . . . . . . . . . . . . 32 7.2. TE-topology JSON . . . . . . . . . . . . . . . . . . . . 33
8. Security Considerations . . . . . . . . . . . . . . . . . . . 48 8. Security Considerations . . . . . . . . . . . . . . . . . . . 49
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 51
11.1. Normative References . . . . . . . . . . . . . . . . . . 51 11.1. Normative References . . . . . . . . . . . . . . . . . . 51
11.2. Informative References . . . . . . . . . . . . . . . . . 52 11.2. Informative References . . . . . . . . . . . . . . . . . 53
Appendix A. Contributors Addresses . . . . . . . . . . . . . . . 53 Appendix A. Performance Constraints . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 Appendix B. Contributors Addresses . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction 1. Introduction
This document provides a YANG data model generally applicable to any This document provides a YANG [RFC7950] data model generally
mode of Virtual Network (VN) operation. applicable to any mode of Virtual Network (VN) operation.
The VN model defined in this document is applicable in generic sense 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 as an independent model in and of itself. The VN model defined in
this document can also work together with other customer service this document can also work together with other customer service
models such as L3SM [RFC8299], L2SM [RFC8466] and L1CSM models such as L3SM [RFC8299], L2SM [RFC8466] and L1CSM
[I-D.ietf-ccamp-l1csm-yang] to provide a complete life-cycle service [I-D.ietf-ccamp-l1csm-yang] to provide a complete life-cycle service
management and operations. management and operations.
The YANG model discussed in this document basically provides the The YANG model discussed in this document basically provides the
following: following:
o Characteristics of Access Points (APs) that describe customer's o Characteristics of Access Points (APs) that describe customer's
end point characteristics; end point characteristics;
o Characteristics of Virtual Network Access Points (VNAP) that o Characteristics of Virtual Network Access Points (VNAP) that
describe How an AP is partitioned for multiple VNs sharing the AP describe how an AP is partitioned for multiple VNs sharing the AP
and its reference to a Link Termination Point (LTP) of the and its reference to a Link Termination Point (LTP) of the
Provider Edge (PE) Node; Provider Edge (PE) Node;
o Characteristics of Virtual Networks (VNs) that describe the o Characteristics of Virtual Networks (VNs) that describe the
customer's VNs in terms of VN Members comprising a VN, multi- customer's VN in terms of multiple VN Members comprising a VN,
source and/or multi-destination characteristics of VN Member, the multi- source and/or multi-destination characteristics of the VN
VN's reference to TE-topology's Abstract Node; Member, the VN's reference to TE-topology's Abstract Node;
The actual VN instantiation and computation is performed with The actual VN instantiation and computation is performed with
Connectivity Matrices sub-module of TE-Topology Model Connectivity Matrices sub-module of TE-Topology Model
[I-D.ietf-teas-yang-te-topo] which provides TE network topology [I-D.ietf-teas-yang-te-topo] which provides TE network topology
abstraction and management operation. Once TE-topology Model is used abstraction and management operation. Once TE-topology Model is used
in triggering VN instantiation over the networks, TE-tunnel in triggering VN instantiation over the networks, TE-tunnel
[I-D.ietf-teas-yang-te] Model will inevitably interact with TE- [I-D.ietf-teas-yang-te] Model will inevitably interact with TE-
Topology model for setting up actual tunnels and LSPs under the Topology model for setting up actual tunnels and LSPs under the
tunnels. tunnels.
Abstraction and Control of Traffic Engineered Networks (ACTN) Abstraction and Control of Traffic Engineered Networks (ACTN)
describes a set of management and control functions used to operate describes a set of management and control functions used to operate
one or more TE networks to construct virtual networks that can be one or more TE networks to construct virtual networks that can be
represented to customers and that are built from abstractions of the represented to customers and that are built from abstractions of the
underlying TE networks [RFC8453]. ACTN is the primary example of the underlying TE networks [RFC8453]. ACTN is the primary example of the
usage of the VN Yang model. usage of the VN YANG model.
Sections 2 and 3 provide the discussion of how the VN Yang model is Sections 2 and 3 provide the discussion of how the VN YANG model is
applicable to the ACTN context where Virtual Network Service (VNS) applicable to the ACTN context where Virtual Network Service (VNS)
operation is implemented for the Customer Network Controller (CNC)- operation is implemented for the Customer Network Controller (CNC)-
Multi-Domain Service Coordinator (MSDC) interface (CMI). Multi-Domain Service Coordinator (MSDC) interface (CMI).
The YANG model on the CMI is also known as customer service model in 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 [RFC8309]. The YANG model discussed in this document is used to
operate customer-driven VNs during the VN instantiation, VN operate customer-driven VNs during the VN instantiation, VN
computation, and its life-cycle service management and operations. computation, and its life-cycle service management and operations.
The VN operational state is included in the same tree as the The VN operational state is included in the same tree as the
configuration consistent with Network Management Datastore configuration consistent with Network Management Datastore
Architecture (NMDA) [RFC8342]. The origin of the data is indicated Architecture (NMDA) [RFC8342]. The origin of the data is indicated
as per the origin metadata annotation. as per the origin metadata annotation.
1.1. Terminology 1.1. Terminology
Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used
in this document. in this document.
1.1.1. Requirements Language
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.
1.2. Tree diagram 1.2. Tree diagram
A simplified graphical representation of the data model is used in A simplified graphical representation of the data model is used in
Section 5 of this this document. The meaning of the symbols in these Section 5 of this this document. The meaning of the symbols in these
diagrams is defined in [RFC8340]. diagrams is defined in [RFC8340].
1.3. Prefixes in Data Node Names 1.3. Prefixes in Data Node Names
In this document, names of data nodes and other data model objects In this document, names of data nodes and other data model objects
are prefixed using the standard prefix associated with the are prefixed using the standard prefix associated with the
corresponding YANG imported modules, as shown in Table 1. corresponding YANG imported modules, as shown in Table 1.
+----------+-----------------------+------------------------------+ +----------+-----------------------+------------------------------+
| Prefix | YANG module | Reference | | Prefix | YANG module | Reference |
+----------+-----------------------+------------------------------+ +----------+-----------------------+------------------------------+
| vn | ietf-vn | [RFCXXXX] | | vn | ietf-vn | [RFCXXXX] |
| inet | ietf-inet-types | [RFC6991] |
| nw | ietf-network | [RFC8345] | | nw | ietf-network | [RFC8345] |
| nt | ietf-network-topology | [RFC8345] | | nt | ietf-network-topology | [RFC8345] |
| te-types | ietf-te-types | [I-D.ietf-teas-yang-te] | | te-types | ietf-te-types | [RFC8776] |
| te-topo | ietf-te-topology | [I-D.ietf-teas-yang-te-topo] | | te-topo | ietf-te-topology | [I-D.ietf-teas-yang-te-topo] |
+----------+-----------------------+------------------------------+ +----------+-----------------------+------------------------------+
Table 1: Prefixes and corresponding YANG modules Table 1: Prefixes and corresponding YANG modules
Note: The RFC Editor will replace XXXX with the number assigned to Note: The RFC Editor will replace XXXX with the number assigned to
the RFC once this draft becomes an RFC. the RFC once this draft becomes an RFC.
2. Use-case of VN Yang Model in the ACTN context 2. Use-case of VN YANG Model in the ACTN context
In this section, ACTN is being used to illustrate the general usage In this section, ACTN is being used to illustrate the general usage
of the VN yang model. The model presented in this section has the of the VN YANG model. The model presented in this section has the
following ACTN context. following ACTN context.
+-------+ +-------+
| CNC | | CNC |
+-------+ +-------+
| |
| VN YANG + TE-topology YANG | VN YANG + TE-topology YANG
| |
+-----------------------+ +-----------------------+
| MDSC | | MDSC |
+-----------------------+ +-----------------------+
Figure 1: ACTN CMI Figure 1: ACTN CMI
Both ACTN VN YANG and TE-topology models are used over the CMI to Both ACTN VN YANG and TE-topology models are used over the CMI to
establish a VN over TE networks. establish a VN over TE networks.
In the context of 5G transport application, 5G Traffic Provisioning
Manager (TPM) that provides slicing requirements to the transport
networks (i.e., MDSC) can be considered as a type of CNC. The ACTN
CMI provides the necessary interface functions between 5G and
transport networks in order to facilitate dynamic VN creation and its
lifecycle management with proper feedback loop for monitoring.
2.1. Type 1 VN 2.1. Type 1 VN
As defined in [RFC8453], a Virtual Network is a customer view of the As defined in [RFC8453], a Virtual Network is a customer view of the
TE network. To recapitulate VN types from [RFC8453], Type 1 VN is TE network. To recapitulate VN types from [RFC8453], Type 1 VN is
defined as follows: defined as follows:
The VN can be seen as a set of edge-to-edge abstract links (a Type 1 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 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 as an end-to-end tunnel across the underlying networks. Such tunnels
may be constructed by recursive slicing or abstraction of paths in may be constructed by recursive slicing or abstraction of paths in
skipping to change at page 12, line 15 skipping to change at page 12, line 15
added later. added later.
To achieve this the 'ap' container has a leaf for 'pe' node that To achieve this the 'ap' container has a leaf for 'pe' node that
allows AP to be created with PE information. The vn-member (and vn) allows AP to be created with PE information. The vn-member (and vn)
could use APs that only have PE information initially. could use APs that only have PE information initially.
4. VN Model Usage 4. VN Model Usage
4.1. Customer view of VN 4.1. Customer view of VN
The VN-Yang model allows to define a customer view, and allows the The VN-YANG model allows to define a customer view, and allows the
customer to communicate using the VN constructs as described in 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 [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 (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 customer to instantiate and view the VN as one entity, making it
easier for some customers to work on VN without worrying about the easier for some customers to work on VN without worrying about the
details of the provider based YANG models. details of the provider based YANG models.
This is similar to the benefits of having a separate YANG model for This is similar to the benefits of having a separate YANG model for
the customer services as described in [RFC8309], which states that the customer services as described in [RFC8309], which states that
service models do not make any assumption of how a service is service models do not make any assumption of how a service is
actually engineered and delivered for a customer. actually engineered and delivered for a customer.
4.2. Auto-creation of VN by MDSC 4.2. Auto-creation of VN by MDSC
The VN could be configured at the MDSC explicitly by the CNC using The VN could be configured at the MDSC explicitly by the CNC using
the VN yang model. In some other cases, the VN is not explicitly the VN YANG model. In some other cases, the VN is not explicitly
configured, but created automatically by the MDSC based on the configured, but created automatically by the MDSC based on the
customer service model and local policy, even in these case the VN 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 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 created to meet the requirements of customer service model.
4.3. Innovative Services 4.3. Innovative Services
4.3.1. VN Compute 4.3.1. VN Compute
VN Model supports VN compute (pre-instantiation mode) to view the VN Model supports VN compute (pre-instantiation mode) to view the
full VN as a single entity before instantiation. Achieving this via full VN as a single entity before instantiation. Achieving this via
path computation or "compute only" tunnel setup does not provide the path computation or "compute only" tunnel setup does not provide the
same functionality. same functionality.
skipping to change at page 13, line 14 skipping to change at page 13, line 14
resource situations. Likewise, for a given destination, there may resource situations. Likewise, for a given destination, there may
also be multiple-sources from which the optimal source may be chosen. also be multiple-sources from which the optimal source may be chosen.
In some cases, there may be a pool of multiple sources and In some cases, there may be a pool of multiple sources and
destinations from which the optimal source-destination may be chosen. destinations from which the optimal source-destination may be chosen.
The following YANG module is shown for describing source container The following YANG module is shown for describing source container
and destination container. The following YANG tree shows how to and destination container. The following YANG tree shows how to
model multi-sources and multi-destinations. model multi-sources and multi-destinations.
+--rw vn +--rw vn
+--rw vn-list* [vn-id] +--rw vn-list* [vn-id]
+--rw vn-id uint32 +--rw vn-id vn-id
+--rw vn-name? string
+--rw vn-topology-id? te-types:te-topology-id +--rw vn-topology-id? te-types:te-topology-id
+--rw abstract-node? +--rw abstract-node?
| -> /nw:networks/network/node/tet:te-node-id | -> /nw:networks/network/node/tet:te-node-id
+--rw vn-member-list* [vn-member-id] +--rw vn-member-list* [vn-member-id]
| +--rw vn-member-id uint32 | +--rw vn-member-id vn-member-id
| +--rw src | +--rw src
| | +--rw src? | | +--rw src?
| | | -> /ap/access-point-list/access-point-id | | | -> /ap/access-point-list/access-point-id
| | +--rw src-vn-ap-id? | | +--rw src-vn-ap-id?
| | | -> /ap/access-point-list/vn-ap/vn-ap-id | | | -> /ap/access-point-list/vn-ap/vn-ap-id
| | +--rw multi-src? boolean {multi-src-dest}? | | +--rw multi-src? boolean {multi-src-dest}?
| +--rw dest | +--rw dest
| | +--rw dest? | | +--rw dest?
| | | -> /ap/access-point-list/access-point-id | | | -> /ap/access-point-list/access-point-id
| | +--rw dest-vn-ap-id? | | +--rw dest-vn-ap-id?
| | | -> /ap/access-point-list/vn-ap/vn-ap-id | | | -> /ap/access-point-list/vn-ap/vn-ap-id
| | +--rw multi-dest? boolean {multi-src-dest}? | | +--rw multi-dest? boolean {multi-src-dest}?
| +--rw connectivity-matrix-id? leafref | +--rw connectivity-matrix-id? leafref
| +--ro oper-status? identityref | +--ro oper-status? identityref
+--ro if-selected? boolean {multi-src-dest}? +--ro if-selected? boolean {multi-src-dest}?
+--rw admin-status? identityref +--rw admin-status? identityref
+--ro oper-status? identityref +--ro oper-status? identityref
+--rw vn-level-diversity? vn-disjointness +--rw vn-level-diversity? te-types:te-path-disjointness
4.3.3. Others 4.3.3. Others
The VN Yang model can be easily augmented to support the mapping of 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 VN to the Services such as L3SM and L2SM as described in
[I-D.ietf-teas-te-service-mapping-yang]. [I-D.ietf-teas-te-service-mapping-yang].
The VN Yang model can be extended to support telemetry, performance The VN YANG model can be extended to support telemetry, performance
monitoring and network autonomics as described in monitoring and network autonomics as described in
[I-D.ietf-teas-actn-pm-telemetry-autonomics]. [I-D.ietf-teas-actn-pm-telemetry-autonomics].
4.3.4. Summary 4.3.4. Summary
This section summarizes the innovative service features of the VN This section summarizes the innovative service features of the VN
Yang. YANG.
o Maintenance of AP and VNAP along with VN o Maintenance of AP and VNAP along with VN
o VN construct to group of edge-to-edge links o VN construct to group of edge-to-edge links
o VN Compute (pre-instantiate) o VN Compute (pre-instantiate)
o Multi-Source / Multi-Destination o Multi-Source / Multi-Destination
o Ability to support various VN and VNS Types o Ability to support various VN and VNS Types
* VN Type 1: Customer configures the VN as a set of VN Members. * VN Type 1: Customer configures the VN as a set of VN Members.
No other details need to be set by customer, making for a No other details need to be set by customer, making for a
simplified operations for the customer. simplified operations for the customer.
* VN Type 2: Along with VN Members, the customer could also * VN Type 2: Along with VN Members, the customer could also
provide an abstract topology, this topology is provided by the provide an abstract topology, this topology is provided by the
Abstract TE Topology Yang Model. Abstract TE Topology YANG Model.
5. VN YANG Model (Tree Structure) 5. VN YANG Model (Tree Structure)
module: ietf-vn module: ietf-vn
+--rw ap +--rw ap
| +--rw access-point-list* [access-point-id] | +--rw access-point-list* [access-point-id]
| +--rw access-point-id uint32 | +--rw access-point-id access-point-id
| +--rw access-point-name? string
| +--rw pe? | +--rw pe?
| | -> /nw:networks/network/node/tet:te-node-id | | -> /nw:networks/network/node/tet:te-node-id
| +--rw max-bandwidth? te-types:te-bandwidth | +--rw max-bandwidth? te-types:te-bandwidth
| +--rw avl-bandwidth? te-types:te-bandwidth | +--rw avl-bandwidth? te-types:te-bandwidth
| +--rw vn-ap* [vn-ap-id] | +--rw vn-ap* [vn-ap-id]
| +--rw vn-ap-id uint32 | +--rw vn-ap-id access-point-id
| +--rw vn? -> /vn/vn-list/vn-id | +--rw vn? -> /vn/vn-list/vn-id
| +--rw abstract-node? | +--rw abstract-node?
| | -> /nw:networks/network/node/tet:te-node-id | | -> /nw:networks/network/node/tet:te-node-id
| +--rw ltp? leafref | +--rw ltp? leafref
| +--ro max-bandwidth? te-types:te-bandwidth
+--rw vn +--rw vn
+--rw vn-list* [vn-id] +--rw vn-list* [vn-id]
+--rw vn-id uint32 +--rw vn-id vn-id
+--rw vn-name? string
+--rw vn-topology-id? te-types:te-topology-id +--rw vn-topology-id? te-types:te-topology-id
+--rw abstract-node? +--rw abstract-node?
| -> /nw:networks/network/node/tet:te-node-id | -> /nw:networks/network/node/tet:te-node-id
+--rw vn-member-list* [vn-member-id] +--rw vn-member-list* [vn-member-id]
| +--rw vn-member-id uint32 | +--rw vn-member-id vn-member-id
| +--rw src | +--rw src
| | +--rw src? | | +--rw src?
| | | -> /ap/access-point-list/access-point-id | | | -> /ap/access-point-list/access-point-id
| | +--rw src-vn-ap-id? | | +--rw src-vn-ap-id?
| | | -> /ap/access-point-list/vn-ap/vn-ap-id | | | -> /ap/access-point-list/vn-ap/vn-ap-id
| | +--rw multi-src? boolean {multi-src-dest}? | | +--rw multi-src? boolean {multi-src-dest}?
| +--rw dest | +--rw dest
| | +--rw dest? | | +--rw dest?
| | | -> /ap/access-point-list/access-point-id | | | -> /ap/access-point-list/access-point-id
| | +--rw dest-vn-ap-id? | | +--rw dest-vn-ap-id?
| | | -> /ap/access-point-list/vn-ap/vn-ap-id | | | -> /ap/access-point-list/vn-ap/vn-ap-id
| | +--rw multi-dest? boolean {multi-src-dest}? | | +--rw multi-dest? boolean {multi-src-dest}?
| +--rw connectivity-matrix-id? leafref | +--rw connectivity-matrix-id? leafref
| +--ro oper-status? identityref | +--ro oper-status? identityref
+--ro if-selected? boolean {multi-src-dest}? +--ro if-selected? boolean {multi-src-dest}?
+--rw admin-status? identityref +--rw admin-status? identityref
+--ro oper-status? identityref +--ro oper-status? identityref
+--rw vn-level-diversity? vn-disjointness +--rw vn-level-diversity? te-types:te-path-disjointness
rpcs: rpcs:
+---x vn-compute +---x vn-compute
+---w input +---w input
| +---w abstract-node? | +---w abstract-node?
| | -> /nw:networks/network/node/tet:te-node-id | | -> /nw:networks/network/node/tet:te-node-id
| +---w vn-member-list* [vn-member-id] | +---w vn-member-list* [vn-member-id]
| | +---w vn-member-id uint32 | | +---w vn-member-id vn-member-id
| | +---w src | | +---w src
| | | +---w src? | | | +---w src?
| | | | -> /ap/access-point-list/access-point-id | | | | -> /ap/access-point-list/access-point-id
| | | +---w src-vn-ap-id? | | | +---w src-vn-ap-id?
| | | | -> /ap/access-point-list/vn-ap/vn-ap-id | | | | -> /ap/access-point-list/vn-ap/vn-ap-id
| | | +---w multi-src? boolean {multi-src-dest}? | | | +---w multi-src? boolean {multi-src-dest}?
| | +---w dest | | +---w dest
| | | +---w dest? | | | +---w dest?
| | | | -> /ap/access-point-list/access-point-id | | | | -> /ap/access-point-list/access-point-id
| | | +---w dest-vn-ap-id? | | | +---w dest-vn-ap-id?
| | | | -> /ap/access-point-list/vn-ap/vn-ap-id | | | | -> /ap/access-point-list/vn-ap/vn-ap-id
| | | +---w multi-dest? boolean {multi-src-dest}? | | | +---w multi-dest? boolean {multi-src-dest}?
| | +---w connectivity-matrix-id? leafref | | +---w connectivity-matrix-id? leafref
| +---w vn-level-diversity? vn-disjointness | +---w vn-level-diversity? te-types:te-path-disjointness
+--ro output +--ro output
+--ro vn-member-list* [vn-member-id] +--ro vn-member-list* [vn-member-id]
+--ro vn-member-id uint32 +--ro vn-member-id vn-member-id
+--ro src +--ro src
| +--ro src? | +--ro src?
| | -> /ap/access-point-list/access-point-id | | -> /ap/access-point-list/access-point-id
| +--ro src-vn-ap-id? | +--ro src-vn-ap-id?
| | -> /ap/access-point-list/vn-ap/vn-ap-id | | -> /ap/access-point-list/vn-ap/vn-ap-id
| +--ro multi-src? boolean {multi-src-dest}? | +--ro multi-src? boolean {multi-src-dest}?
+--ro dest +--ro dest
| +--ro dest? | +--ro dest?
| | -> /ap/access-point-list/access-point-id | | -> /ap/access-point-list/access-point-id
| +--ro dest-vn-ap-id? | +--ro dest-vn-ap-id?
| | -> /ap/access-point-list/vn-ap/vn-ap-id | | -> /ap/access-point-list/vn-ap/vn-ap-id
| +--ro multi-dest? boolean {multi-src-dest}? | +--ro multi-dest? boolean {multi-src-dest}?
+--ro connectivity-matrix-id? leafref +--ro connectivity-matrix-id? leafref
+--ro if-selected? boolean +--ro if-selected? boolean
| {multi-src-dest}? | {multi-src-dest}?
+--ro compute-status? identityref +--ro compute-status? identityref
6. VN YANG Code 6. VN YANG Model
The YANG code is as follows: The YANG model is as follows:
<CODE BEGINS> file "ietf-vn@2020-03-08.yang" <CODE BEGINS> file "ietf-vn@2020-07-13.yang"
module ietf-vn { module ietf-vn {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-vn"; namespace "urn:ietf:params:xml:ns:yang:ietf-vn";
prefix vn; prefix vn;
/* Import inet-types */
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types";
}
/* Import network */ /* Import network */
import ietf-network { import ietf-network {
prefix nw; prefix nw;
reference reference
"RFC 8345: A YANG Data Model for Network Topologies"; "RFC 8345: A YANG Data Model for Network Topologies";
} }
/* Import network topology */ /* Import network topology */
skipping to change at page 16, line 44 skipping to change at page 17, line 4
/* Import network topology */ /* Import network topology */
import ietf-network-topology { import ietf-network-topology {
prefix nt; prefix nt;
reference reference
"RFC 8345: A YANG Data Model for Network Topologies"; "RFC 8345: A YANG Data Model for Network Topologies";
} }
/* Import TE Common types */ /* Import TE Common types */
import ietf-te-types { import ietf-te-types {
prefix te-types; prefix te-types;
reference reference
"I-D.ietf-teas-yang-te-types: Traffic Engineering Common "RFC 8776: Common YANG Data Types for Traffic Engineering";
YANG Types";
} }
/* Import TE Topology */ /* Import TE Topology */
import ietf-te-topology { import ietf-te-topology {
prefix tet; prefix tet;
reference reference
"I-D.ietf-teas-yang-te-topo: YANG Data Model for Traffic "I-D.ietf-teas-yang-te-topo: YANG Data Model for Traffic
Engineering (TE) Topologies"; Engineering (TE) Topologies";
} }
organization organization
skipping to change at page 17, line 25 skipping to change at page 17, line 31
Working Group"; Working Group";
contact contact
"WG Web: <https://tools.ietf.org/wg/teas/> "WG Web: <https://tools.ietf.org/wg/teas/>
WG List: <mailto:teas@ietf.org> WG List: <mailto:teas@ietf.org>
Editor: Young Lee <younglee.tx@gmail.com> Editor: Young Lee <younglee.tx@gmail.com>
: Dhruv Dhody <dhruv.ietf@gmail.com>"; : Dhruv Dhody <dhruv.ietf@gmail.com>";
description description
"This module contains a YANG module for the VN. It describes a "This module contains a YANG module for the VN. It describes a
VN operation module that takes place in the context of the VN operation module that takes place in the context of the
CNC-MDSC Interface (CMI) of the ACTN architecture where the CNC-MDSC Interface (CMI) of the ACTN architecture where the
CNC is the actor of a VN Instantiation/modification/deletion. CNC is the actor of a VN Instantiation/modification/deletion
as per RFC 8453.
Copyright (c) 2020 IETF Trust and the persons identified as Copyright (c) 2020 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the This version of this YANG module is part of RFC XXXX; see the
RFC itself for full legal notices. RFC itself for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as 'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here."; they appear in all capitals, as shown here.";
revision 2020-03-08 { revision 2020-07-13 {
description description
"initial version."; "initial version.";
reference reference
"RFC XXXX: A Yang Data Model for VN Operation"; "RFC XXXX: A YANG Data Model for VN Operation";
} }
/* Features */ /* Features */
feature multi-src-dest { feature multi-src-dest {
description description
"Support for selection of one src or destination "Support for selection of one src or destination
among multiple."; among multiple.";
reference
"RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN)";
} }
/* Identity VN State*/ /* Identity VN State*/
identity vn-state-type { identity vn-state-type {
description description
"Base identity for VN state"; "Base identity for VN state";
} }
identity vn-state-up { identity vn-state-up {
skipping to change at page 19, line 21 skipping to change at page 19, line 32
description description
"State path compute in progress"; "State path compute in progress";
} }
identity vn-compute-state-computation-ok { identity vn-compute-state-computation-ok {
base vn-compute-state-type; base vn-compute-state-type;
description description
"State path compute successful"; "State path compute successful";
} }
identity vn-compute-state-computatione-failed { identity vn-compute-state-computation-failed {
base vn-compute-state-type; base vn-compute-state-type;
description description
"State path compute failed"; "State path compute failed";
} }
/* typedef */ /* Typedef */
typedef vn-disjointness { typedef vn-id {
type bits { type inet:uri;
bit node {
position 0;
description
"node disjoint";
}
bit link {
position 1;
description
"link disjoint";
}
bit srlg {
position 2;
description
"srlg disjoint";
}
}
description description
"type of the resource disjointness for VN level applied "Identifier for a VN. The precise structure of the
across all VN members in a VN"; 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 */ /* Groupings */
grouping vn-ap { grouping vn-ap {
description description
"VNAP related information"; "VNAP related information";
leaf vn-ap-id { leaf vn-ap-id {
type uint32; type access-point-id;
description description
"unique identifier for the referred VNAP"; "A unique identifier for the referred VNAP";
} }
leaf vn { leaf vn {
type leafref { type leafref {
path "/vn/vn-list/vn-id"; path "/vn/vn-list/vn-id";
} }
description description
"reference to the VN"; "A reference to the VN";
} }
leaf abstract-node { leaf abstract-node {
type leafref { type leafref {
path "/nw:networks/nw:network/nw:node/tet:te-node-id"; path "/nw:networks/nw:network/nw:node/tet:te-node-id";
} }
description description
"a reference to the abstract node in TE Topology that "A reference to the abstract node in TE Topology that
represent the VN"; represent the VN";
} }
leaf ltp { leaf ltp {
type leafref { type leafref {
path "/nw:networks/nw:network/nw:node/" path "/nw:networks/nw:network/nw:node/"
+ "nt:termination-point/tet:te-tp-id"; + "nt:termination-point/tet:te-tp-id";
} }
description description
"Reference LTP in the TE-topology"; "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 } //vn-ap
grouping access-point { grouping access-point {
description description
"AP related information"; "AP related information";
leaf access-point-id { leaf access-point-id {
type uint32; type access-point-id;
description
"unique identifier for the referred access point";
}
leaf access-point-name {
type string;
description description
"ap name"; "A unique identifier for the referred access point";
} }
leaf pe { leaf pe {
type leafref { type leafref {
path "/nw:networks/nw:network/nw:node/tet:te-node-id"; path "/nw:networks/nw:network/nw:node/tet:te-node-id";
} }
description description
"a reference to the PE node in the native TE Topology"; "A reference to the PE node in the native TE Topology";
} }
leaf max-bandwidth { leaf max-bandwidth {
type te-types:te-bandwidth; type te-types:te-bandwidth;
description description
"max bandwidth of the AP"; "The max bandwidth of the AP";
} }
leaf avl-bandwidth { leaf avl-bandwidth {
type te-types:te-bandwidth; type te-types:te-bandwidth;
description description
"available bandwidth of the AP"; "The available bandwidth of the AP";
} }
/*add details and any other properties of AP, /*add details and any other properties of AP,
not associated by a VN not associated by a VN
CE port, PE port etc. CE port, PE port etc.
*/ */
list vn-ap { list vn-ap {
key "vn-ap-id"; key "vn-ap-id";
uses vn-ap; uses vn-ap;
description description
"list of VNAP in this AP"; "List of VNAP in this AP";
} }
reference
"RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN)";
} //access-point } //access-point
grouping vn-member { grouping vn-member {
description description
"vn-member is described by this container"; "The vn-member is described by this grouping";
leaf vn-member-id { leaf vn-member-id {
type uint32; type vn-member-id;
description description
"vn-member identifier"; "A vn-member identifier";
} }
container src { container src {
description description
"the source of VN Member"; "The source of VN Member";
leaf src { leaf src {
type leafref { type leafref {
path "/ap/access-point-list/access-point-id"; path "/ap/access-point-list/access-point-id";
} }
description description
"reference to source AP"; "A reference to source AP";
} }
leaf src-vn-ap-id { leaf src-vn-ap-id {
type leafref { type leafref {
path "/ap/access-point-list/vn-ap/vn-ap-id"; path "/ap/access-point-list/vn-ap/vn-ap-id";
} }
description description
"reference to source VNAP"; "A reference to source VNAP";
} }
leaf multi-src { leaf multi-src {
if-feature "multi-src-dest"; if-feature "multi-src-dest";
type boolean; type boolean;
description description
"Is source part of multi-source, where "Is the source part of multi-source, where
only one of the source is enabled"; only one of the source is enabled";
} }
} }
container dest { container dest {
description description
"the destination of VN Member"; "the destination of VN Member";
leaf dest { leaf dest {
type leafref { type leafref {
path "/ap/access-point-list/access-point-id"; path "/ap/access-point-list/access-point-id";
} }
description description
"reference to destination AP"; "A reference to destination AP";
} }
leaf dest-vn-ap-id { leaf dest-vn-ap-id {
type leafref { type leafref {
path "/ap/access-point-list/vn-ap/vn-ap-id"; path "/ap/access-point-list/vn-ap/vn-ap-id";
} }
description description
"reference to dest VNAP"; "A reference to dest VNAP";
} }
leaf multi-dest { leaf multi-dest {
if-feature "multi-src-dest"; if-feature "multi-src-dest";
type boolean; type boolean;
description description
"Is destination part of multi-destination, where only one "Is destination part of multi-destination, where only one
of the destination is enabled"; of the destination is enabled";
} }
} }
leaf connectivity-matrix-id { leaf connectivity-matrix-id {
type leafref { type leafref {
path "/nw:networks/nw:network/nw:node/tet:te/" path "/nw:networks/nw:network/nw:node/tet:te/"
+ "tet:te-node-attributes/" + "tet:te-node-attributes/"
+ "tet:connectivity-matrices/" + "tet:connectivity-matrices/"
+ "tet:connectivity-matrix/tet:id"; + "tet:connectivity-matrix/tet:id";
} }
description description
"reference to connectivity-matrix"; "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 } //vn-member
grouping vn-policy { grouping vn-policy {
description description
"policy for VN-level diverisity"; "policy for VN-level diverisity";
leaf vn-level-diversity { leaf vn-level-diversity {
type vn-disjointness; type te-types:te-path-disjointness;
description description
"the type of disjointness on the VN level (i.e., across all "The type of disjointness on the VN level (i.e., across all
VN members)"; VN members)";
} }
} }
/* Configuration data nodes */ /* Configuration data nodes */
container ap { container ap {
description description
"AP configurations"; "AP configurations";
list access-point-list { list access-point-list {
key "access-point-id"; key "access-point-id";
skipping to change at page 23, line 30 skipping to change at page 24, line 19
container ap { container ap {
description description
"AP configurations"; "AP configurations";
list access-point-list { list access-point-list {
key "access-point-id"; key "access-point-id";
description description
"access-point identifier"; "access-point identifier";
uses access-point { uses access-point {
description description
"access-point information"; "The access-point information";
} }
} }
reference
"RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN)";
} }
container vn { container vn {
description description
"VN configurations"; "VN configurations";
list vn-list { list vn-list {
key "vn-id"; key "vn-id";
description description
"a virtual network is identified by a vn-id"; "A virtual network is identified by a vn-id";
leaf vn-id { leaf vn-id {
type uint32; type vn-id;
description
"a unique vn identifier";
}
leaf vn-name {
type string;
description description
"vn name"; "A unique VN identifier";
} }
leaf vn-topology-id { leaf vn-topology-id {
type te-types:te-topology-id; type te-types:te-topology-id;
description description
"An optional identifier to the TE Topology Model where the "An optional identifier to the TE Topology Model where the
abstract nodes and links of the Topology can be found for abstract nodes and links of the Topology can be found for
Type 2 VNS"; Type 2 VNS";
} }
leaf abstract-node { leaf abstract-node {
type leafref { type leafref {
path "/nw:networks/nw:network/nw:node/tet:te-node-id"; path "/nw:networks/nw:network/nw:node/tet:te-node-id";
} }
description description
"a reference to the abstract node in TE Topology"; "A reference to the abstract node in TE Topology";
} }
list vn-member-list { list vn-member-list {
key "vn-member-id"; key "vn-member-id";
description description
"List of VN-members in a VN"; "List of vn-members in a VN";
uses vn-member; uses vn-member;
leaf oper-status { leaf oper-status {
type identityref { type identityref {
base vn-state-type; base vn-state-type;
} }
config false; config false;
description description
"VN-member operational state."; "The vn-member operational state.";
} }
} }
leaf if-selected { leaf if-selected {
if-feature "multi-src-dest"; if-feature "multi-src-dest";
type boolean; type boolean;
default "false"; default "false";
config false; config false;
description description
"Is the vn-member is selected among the multi-src/dest "Is the vn-member is selected among the multi-src/dest
options"; options";
skipping to change at page 25, line 9 skipping to change at page 25, line 44
leaf oper-status { leaf oper-status {
type identityref { type identityref {
base vn-state-type; base vn-state-type;
} }
config false; config false;
description description
"VN operational state."; "VN operational state.";
} }
uses vn-policy; uses vn-policy;
} //vn-list } //vn-list
reference
"RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN)";
} //vn } //vn
/* RPC */ /* RPC */
rpc vn-compute { rpc vn-compute {
description description
"The VN computation without actual instantiation"; "The VN computation without actual instantiation";
input { input {
leaf abstract-node { leaf abstract-node {
type leafref { type leafref {
path "/nw:networks/nw:network/nw:node/tet:te-node-id"; path "/nw:networks/nw:network/nw:node/tet:te-node-id";
} }
description description
"a reference to the abstract node in TE Topology"; "A reference to the abstract node in TE Topology";
} }
list vn-member-list { list vn-member-list {
key "vn-member-id"; key "vn-member-id";
description description
"List of VN-members in a VN"; "List of VN-members in a VN";
uses vn-member; uses vn-member;
} }
uses vn-policy; uses vn-policy;
} }
output { output {
skipping to change at page 25, line 51 skipping to change at page 26, line 41
default "false"; default "false";
description description
"Is the vn-member is selected among the multi-src/dest "Is the vn-member is selected among the multi-src/dest
options"; options";
} }
leaf compute-status { leaf compute-status {
type identityref { type identityref {
base vn-compute-state-type; base vn-compute-state-type;
} }
description description
"VN-member compute state."; "The VN-member compute state.";
} }
} }
} }
} //vn-compute } //vn-compute
} }
<CODE ENDS> <CODE ENDS>
7. JSON Example 7. JSON Example
This section provides json implementation examples as to how VN YANG This section provides json implementation examples as to how VN YANG
model and TE topology model are used together to instantiate virtual model and TE topology model are used together to instantiate virtual
networks. networks.
The example in this section includes following VN The example in this section includes following VN
skipping to change at page 50, line 41 skipping to change at page 51, line 33
-------------------------------------------------------------------- --------------------------------------------------------------------
name: ietf-vn name: ietf-vn
namespace: urn:ietf:params:xml:ns:yang:ietf-vn namespace: urn:ietf:params:xml:ns:yang:ietf-vn
prefix: vn prefix: vn
reference: RFC XXXX (TDB) reference: RFC XXXX (TDB)
-------------------------------------------------------------------- --------------------------------------------------------------------
10. Acknowledgments 10. Acknowledgments
The authors would like to thank Xufeng Liu and Adrian Farrel for The authors would like to thank Xufeng Liu, Adrian Farrel, Tom Petch,
their helpful comments and valuable suggestions. and Kenichi Ogaki for their helpful comments and valuable
suggestions.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-teas-yang-te] [I-D.ietf-teas-yang-te]
Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
"A YANG Data Model for Traffic Engineering Tunnels and "A YANG Data Model for Traffic Engineering Tunnels and
Interfaces", draft-ietf-teas-yang-te-22 (work in Interfaces", draft-ietf-teas-yang-te-23 (work in
progress), November 2019. progress), March 2020.
[I-D.ietf-teas-yang-te-topo] [I-D.ietf-teas-yang-te-topo]
Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
O. Dios, "YANG Data Model for Traffic Engineering (TE) O. Dios, "YANG Data Model for Traffic Engineering (TE)
Topologies", draft-ietf-teas-yang-te-topo-22 (work in Topologies", draft-ietf-teas-yang-te-topo-22 (work in
progress), June 2019. progress), June 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>. <https://www.rfc-editor.org/info/rfc6242>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341, Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018, DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>. <https://www.rfc-editor.org/info/rfc8341>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>.
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
2018, <https://www.rfc-editor.org/info/rfc8345>. 2018, <https://www.rfc-editor.org/info/rfc8345>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
"Common YANG Data Types for Traffic Engineering",
RFC 8776, DOI 10.17487/RFC8776, June 2020,
<https://www.rfc-editor.org/info/rfc8776>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-ccamp-l1csm-yang] [I-D.ietf-ccamp-l1csm-yang]
Lee, Y., Lee, K., Zheng, H., Dhody, D., Dios, O., and D. Lee, Y., Lee, K., Zheng, H., Dhody, D., Dios, O., and D.
Ceccarelli, "A YANG Data Model for L1 Connectivity Service Ceccarelli, "A YANG Data Model for L1 Connectivity Service
Model (L1CSM)", draft-ietf-ccamp-l1csm-yang-10 (work in Model (L1CSM)", draft-ietf-ccamp-l1csm-yang-11 (work in
progress), September 2019. progress), March 2020.
[I-D.ietf-teas-actn-pm-telemetry-autonomics] [I-D.ietf-teas-actn-pm-telemetry-autonomics]
Lee, Y., Dhody, D., Karunanithi, S., Vilata, R., King, D., Lee, Y., Dhody, D., Karunanithi, S., Vilata, R., King, D.,
and D. Ceccarelli, "YANG models for VN/TE Performance and D. Ceccarelli, "YANG models for VN/TE Performance
Monitoring Telemetry and Scaling Intent Autonomics", Monitoring Telemetry and Scaling Intent Autonomics",
draft-ietf-teas-actn-pm-telemetry-autonomics-01 (work in draft-ietf-teas-actn-pm-telemetry-autonomics-02 (work in
progress), October 2019. progress), March 2020.
[I-D.ietf-teas-te-service-mapping-yang] [I-D.ietf-teas-te-service-mapping-yang]
Lee, Y., Dhody, D., Fioccola, G., WU, Q., Ceccarelli, D., Lee, Y., Dhody, D., Fioccola, G., WU, Q., Ceccarelli, D.,
and J. Tantsura, "Traffic Engineering (TE) and Service and J. Tantsura, "Traffic Engineering (TE) and Service
Mapping Yang Model", draft-ietf-teas-te-service-mapping- Mapping Yang Model", draft-ietf-teas-te-service-mapping-
yang-02 (work in progress), September 2019. yang-03 (work in progress), March 2020.
[RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G.,
Ceccarelli, D., and X. Zhang, "Problem Statement and Ceccarelli, D., and X. Zhang, "Problem Statement and
Architecture for Information Exchange between Architecture for Information Exchange between
Interconnected Traffic-Engineered Networks", BCP 206, Interconnected Traffic-Engineered Networks", BCP 206,
RFC 7926, DOI 10.17487/RFC7926, July 2016, RFC 7926, DOI 10.17487/RFC7926, July 2016,
<https://www.rfc-editor.org/info/rfc7926>. <https://www.rfc-editor.org/info/rfc7926>.
[RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki,
"YANG Data Model for L3VPN Service Delivery", RFC 8299, "YANG Data Model for L3VPN Service Delivery", RFC 8299,
DOI 10.17487/RFC8299, January 2018, DOI 10.17487/RFC8299, January 2018,
<https://www.rfc-editor.org/info/rfc8299>. <https://www.rfc-editor.org/info/rfc8299>.
[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
<https://www.rfc-editor.org/info/rfc8309>. <https://www.rfc-editor.org/info/rfc8309>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>.
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Abstraction and Control of TE Networks (ACTN)", RFC 8453, Abstraction and Control of TE Networks (ACTN)", RFC 8453,
DOI 10.17487/RFC8453, August 2018, DOI 10.17487/RFC8453, August 2018,
<https://www.rfc-editor.org/info/rfc8453>. <https://www.rfc-editor.org/info/rfc8453>.
[RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. [RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B.
Yoon, "Information Model for Abstraction and Control of TE Yoon, "Information Model for Abstraction and Control of TE
Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454, Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454,
September 2018, <https://www.rfc-editor.org/info/rfc8454>. September 2018, <https://www.rfc-editor.org/info/rfc8454>.
[RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG
Data Model for Layer 2 Virtual Private Network (L2VPN) Data Model for Layer 2 Virtual Private Network (L2VPN)
Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October
2018, <https://www.rfc-editor.org/info/rfc8466>. 2018, <https://www.rfc-editor.org/info/rfc8466>.
Appendix A. Contributors Addresses Appendix A. Performance Constraints
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.
Appendix B. Contributors Addresses
Qin Wu Qin Wu
Huawei Technologies Huawei Technologies
Email: bill.wu@huawei.com Email: bill.wu@huawei.com
Peter Park Peter Park
KT KT
Email: peter.park@kt.com Email: peter.park@kt.com
Haomian Zheng Haomian Zheng
Huawei Technologies Huawei Technologies
 End of changes. 111 change blocks. 
152 lines changed or deleted 231 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/