draft-ietf-teas-actn-vn-yang-06.txt   draft-ietf-teas-actn-vn-yang-07.txt 
TEAS Working Group Y. Lee (Editor)
Internet Draft Futurewei
Intended Status: Standard Track
Expires: January 5, 2020 D. Dhody (Editor)
Huawei
D. Ceccarelli
Ericsson
I. Bryskin
Futurewei
B. Yoon
ETRI
July 5, 2019
A Yang Data Model for VN Operation TEAS Working Group Y. Lee, Ed.
Internet-Draft SKKU
Intended status: Standards Track D. Dhody, Ed.
Expires: May 3, 2020 Huawei Technologies
D. Ceccarelli
Ericsson
I. Bryskin
Futurewei
B. Yoon
ETRI
October 31, 2019
draft-ietf-teas-actn-vn-yang-06 A Yang Data Model for VN Operation
draft-ietf-teas-actn-vn-yang-07
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 to IETF in full conformance with This Internet-Draft is submitted in full conformance with the
the provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Internet-Drafts are draft documents valid for a maximum of six months
http://www.ietf.org/shadow.html 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 5, 2020. This Internet-Draft will expire on May 3, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(http://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 carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described in include Simplified BSD License text as described in Section 4.e of
Section 4.e of the Trust Legal Provisions and are provided without the Trust Legal Provisions and are provided without warranty as
warranty as described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
Introduction.....................................................3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.................................................................3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology...............................................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....................................9 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 Code . . . . . . . . . . . . . . . . . . . . . . . . 16
7. JSON Example..................................................29 7. JSON Example . . . . . . . . . . . . . . . . . . . . . . . . 25
7.1. VN JSON..................................................30 7.1. VN JSON . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.2. TE-topology JSON.........................................35 7.2. TE-topology JSON . . . . . . . . . . . . . . . . . . . . 32
8. Security Considerations.......................................51 8. Security Considerations . . . . . . . . . . . . . . . . . . . 48
9. IANA Considerations...........................................52 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
10. Acknowledgments..............................................53 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50
11. References...................................................54 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 50
11.1. Normative References....................................54 11.1. Normative References . . . . . . . . . . . . . . . . . . 50
11.2. Informative References..................................54 11.2. Informative References . . . . . . . . . . . . . . . . . 51
12. Contributors.................................................55 Appendix A. Contributors Addresses . . . . . . . . . . . . . . . 52
Authors' Addresses...............................................55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53
1. Introduction 1. Introduction
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.
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 [L2SM] and L1CSM [L1CSM] to models such as L3SM [RFC8299], L2SM [RFC8466] and L1CSM
provide a complete life-cycle service management and operations. [I-D.ietf-ccamp-l1csm-yang] to provide a complete life-cycle service
management and operations.
The YANG model discussed in this document basically provides the The YANG 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 VNs in terms of VN Members comprising a VN, multi-
source and/or multi-destination characteristics of VN Member, the source and/or multi-destination characteristics of VN Member, the
VN's reference to TE-topology's Abstract Node; 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 [TE-Topo] Connectivity Matrices sub-module of TE-Topology Model
which provides TE network topology abstraction and management [I-D.ietf-teas-yang-te-topo] which provides TE network topology
operation. Once TE-topology Model is used in triggering VN abstraction and management operation. Once TE-topology Model is used
instantiation over the networks, TE-tunnel [TE-tunnel] Model will in triggering VN instantiation over the networks, TE-tunnel
inevitably interact with TE-Topology model for setting up actual [I-D.ietf-teas-yang-te] Model will inevitably interact with TE-
tunnels and LSPs under the tunnels. Topology model for setting up actual tunnels and LSPs under the
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.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 Section 5 of this this document. The meaning of the symbols in these
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] |
| nw | ietf-network | [RFC8345] | | nw | ietf-network | [RFC8345] |
| te-types| ietf-te-types | [TE-Tunnel] | | nt | ietf-network-topology | [RFC8345] |
| te-topo | ietf-te-topology | [TE-TOPO] | | te-types | ietf-te-types | [I-D.ietf-teas-yang-te] |
+---------+------------------------------+-----------------+ | 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 In the context of 5G transport application, 5G Traffic Provisioning
Manager (TPM) that provides slicing requirements to the transport Manager (TPM) that provides slicing requirements to the transport
networks (i.e., MDSC) can be considered as a type of CNC. The ACTN networks (i.e., MDSC) can be considered as a type of CNC. The ACTN
CMI provides the necessary interface functions between 5G and CMI provides the necessary interface functions between 5G and
transport networks in order to facilitate dynamic VN creation and transport networks in order to facilitate dynamic VN creation and its
its lifecycle management with proper feedback loop for monitoring. 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
the underlying networks and can encompass edge points of the the underlying networks and can encompass edge points of the
customer's network, access links, intra-domain paths, and inter- customer's network, access links, intra-domain paths, and inter-
domain links. domain links.
If we were to create a VN where we have four VN-members as follows: If we were to create a VN where we have four VN-members as follows:
VN-Member 1 L1-L4 VN-Member 1 L1-L4
VN-Member 2 L1-L7 VN-Member 2 L1-L7
VN-Member 3 L2-L4 VN-Member 3 L2-L4
VN-Member 4 L3-L8 VN-Member 4 L3-L8
Where L1, L2, L3, L4, L7 and L8 correspond to a Customer Where L1, L2, L3, L4, L7 and L8 correspond to a Customer End-
End-Point, respectively. Point, respectively.
This VN can be modeled as one abstract node representation as This VN can be modeled as one abstract node representation as follows
follows in Figure 2: in Figure 2:
+---------------+ +---------------+
L1 ------| |------ L4 L1 ------| |------ L4
L2 ------| AN 1 |------ L7 L2 ------| AN 1 |------ L7
L3 ------| |------ L8 L3 ------| |------ L8
+---------------+ +---------------+
Figure 2. Abstract Node (One node topology) Figure 2: Abstract Node (One node topology)
Modeling a VN as one abstract node is the easiest way for customers Modeling a VN as one abstract node is the easiest way for customers
to express their end-to-end connectivity; however, customers are not to express their end-to-end connectivity; however, customers are not
limited to express their VN only with one abstract node. In some limited to express their VN only with one abstract node.
cases, more than one abstract nodes can be employed to express their
VN.
2.2. Type 2 VN 2.2. Type 2 VN
For some VN members of a VN, the customers are allowed to configure For some VN members of a VN, the customers are allowed to configure
the actual path (i.e., detailed virtual nodes and virtual links) the actual path (i.e., detailed virtual nodes and virtual links) over
over the VN/abstract topology agreed mutually between CNC and MDSC the VN/abstract topology agreed mutually between CNC and MDSC prior
prior to or a topology created by the MDSC as part of VN to or a topology created by the MDSC as part of VN instantiation.
instantiation. Type 2 VN is always built on top of a Type 1 VN. 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 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 VN (see the example in Section 2.1), the TE-topology model can
provide the following abstract topology (that consists of virtual provide the following abstract topology (that consists of virtual
nodes and virtual links) which is built on top of the Type 1 VN. nodes and virtual links) which is built under the Type 1 VN.
+----------------------------------------------+ +----------------------------------------------+
| S1 S2 | | S1 S2 |
| O---------------O | | O---------------O |
| ________/ \______ \ | | ________/ \______ \ |
| / \ \ | | / \ \ |
|S3 / \ S4 \ S5 | |S3 / \ S4 \ S5 |
L1----|-O----------------------O---------O-----------|------L4 L1----|-O----------------------O---------O-----------|------L4
| \ \ \ | | \ \ \ |
| \ \ \ | | \ \ \ |
| \ S6 \ S7 \ S8 | | \ S6 \ S7 \ S8 |
| O ----------------O---------O-------|------L7 | O ----------------O---------O-------|------L7
| / \ / \ ____/ | | / \ / \ ____/ |
|S9 / \ /S10 \ / | |S9 / \ /S10 \ / |
L2-----|---O-----O---------------------O--------------|------L8 L2-----|---O-----O---------------------O--------------|------L8
| / S11 | | / S11 |
L3-----|-- | L3-----|-- |
| | | |
+----------------------------------------------+ +----------------------------------------------+
Figure 3. Type 2 topology Figure 3: Type 2 topology
As you see from Figure 3, the Type 1 abstract node is depicted as a 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 Type 1 abstract topology comprising of detailed virtual nodes and
virtual links. virtual links.
As an example, if VN-member 1 (L1-L4) is chosen to configure its own As an example, if VN-member 1 (L1-L4) is chosen to configure its own
path over Type 2 topology, it can select, say, a path that consists path over Type 2 topology, it can select, say, a path that consists
of the ERO {S3,S4,S5} based on the topology and its service of the ERO {S3,S4,S5} based on the topology and its service
requirement. This capability is enacted via TE-topology requirement. This capability is enacted via TE-topology
configuration by the customer. configuration by the customer.
3. High-Level Control Flows with Examples 3. High-Level Control Flows with Examples
3.1. Type 1 VN Illustration 3.1. Type 1 VN Illustration
If we were to create a VN where we have four VN-members as follows: If we were to create a VN where we have four VN-members as follows:
VN-Member 1 L1-L4 VN-Member 1 L1-L4
VN-Member 2 L1-L7 VN-Member 2 L1-L7
VN-Member 3 L2-L4 VN-Member 3 L2-L4
VN-Member 4 L3-L8 VN-Member 4 L3-L8
Where L1, L2, L3, L4, L7 and L8 correspond to Customer End-Point, Where L1, L2, L3, L4, L7 and L8 correspond to Access Points.
respectively.
This VN can be modeled as one abstract node representation as This VN can be modeled as one abstract node representation as
follows: follows:
+---------------+ +---------------+
L1 ------| |------ L4 L1 ------| |------ L4
L2 ------| AN 1 |------ L7 L2 ------| AN 1 |------ L7
L3 ------| |------ L8 L3 ------| |------ L8
+---------------+ +---------------+
skipping to change at page 8, line 28 skipping to change at page 8, line 12
between CNC and MDSC to instantiate this VN using VN and TE-Topology between CNC and MDSC to instantiate this VN using VN and TE-Topology
Models. Models.
+--------+ +--------+ +--------+ +--------+
| CNC | | MDSC | | CNC | | MDSC |
+--------+ +--------+ +--------+ +--------+
| | | |
| | | |
CNC POST TE-topo | POST /nw:networks/nw:network/ | CNC POST TE-topo | POST /nw:networks/nw:network/ |
model(with Conn. | nw:node/te-node-id/ | model(with Conn. | nw:node/te-node-id/ |
| tet:connectivity-matrices/ | Matrix on one | tet:connectivity-matrices/ |
Matrix on one | tet:connectivity-matrix | Abstract node | tet:connectivity-matrix |
Abstract node |-------------------------------->| |-------------------------------->|
| HTTP 200 | | HTTP 200 |
|<--------------------------------| |<--------------------------------|
| | | |
CNC POST the | POST /VN | CNC POST the | POST /VN |
VN identifying |-------------------------------->| If there is VN identifying |-------------------------------->| If there is
AP, VNAP and VN- | | multi-dest'n AP, VNAP and VN- | | multi-src/dest
Members and maps | | module, then Members and maps | | then MDSC
to the TE-topo | HTTP 200 | MDSC selects a to the TE-topo | HTTP 200 | selects a
|<--------------------------------| src or dest'n |<--------------------------------| src or dest
| | and update | | and update
| | VN YANG | | VN YANG
CNC GET the | GET /VN | CNC GET the | GET /VN |
VN YANG status |-------------------------------->| VN YANG status |-------------------------------->|
| | | |
| HTTP 200 (VN with status: | | HTTP 200 (VN with status: |
| selected VN-members | | selected VN-members |
| in case of multi s-d) | | in case of multi s-d) |
|<--------------------------------| |<--------------------------------|
| | | |
3.2. Type 2 VN Illustration 3.2. Type 2 VN Illustration
For some VN members, the customer may want to "configure" explicit For some VN members, the customer may want to "configure" explicit
routes over the path that connects its two end-points. Let us routes over the path that connects its two end-points. Let us
consider the following example. consider the following example.
VN-Member 1 L1-L4 (via S3, S4, and S5) VN-Member 1 L1-L4 (via S3, S4, and S5)
VN-Member 2 L1-L7 (via S3, S4, S7 and S8) VN-Member 2 L1-L7 (via S3, S4, S7 and S8)
VN-Member 3 L2-L7 (via S9, S10, and S11) VN-Member 3 L2-L7 (via S9, S10, and S11)
VN-Member 4 L3-L8 (via S9, S10 and S11) VN-Member 4 L3-L8 (via S9, S10 and S11)
Where the following topology is the underlay for Abstraction Node 1 Where the following topology is the underlay for Abstraction Node 1
(AN1). (AN1).
AN1 AN1
............................................ ............................................
. S1 S2 . . S1 S2 .
. O---------------O . . O---------------O .
. ________/ \______ \ . . ________/ \______ \ .
. / \ \ . . / \ \ .
skipping to change at page 11, line 4 skipping to change at page 10, line 37
VN YANG status |---------------------------------------->| VN YANG status |---------------------------------------->|
| | | |
| HTTP 200 (VN with status) | | HTTP 200 (VN with status) |
|<----------------------------------------| |<----------------------------------------|
| | | |
Case 2: Case 2:
On the other hand, if MDSC create the single abstract node topology On the other hand, if MDSC create the single abstract node topology
based VN YANG posted by the CNC, the following diagram shows the based VN YANG posted by the CNC, the following diagram shows the
message flow between CNC and MDSC to instantiate this VN using VN message flow between CNC and MDSC to instantiate this VN using VN and
and TE-Topology Models. TE-Topology Models.
+--------+ +--------+ +--------+ +--------+
| CNC | | MDSC | | CNC | | MDSC |
+--------+ +--------+ +--------+ +--------+
| | | |
| | | |
CNC POST VN | | CNC POST VN | |
Identifying AP, | | Identifying AP, | |
VNAP and VN- | POST /VN | MDSC populates VNAP and VN- | POST /VN | MDSC populates
Members |-------------------------------->| a single Abst. Members |-------------------------------->| a single Abst.
skipping to change at page 12, line 5 skipping to change at page 11, line 42
| | | |
| HTTP 200 (VN with status) | | HTTP 200 (VN with status) |
|<--------------------------------| |<--------------------------------|
| | | |
Section 7 provides JSON examples for both VN model and TE-topology Section 7 provides JSON examples for both VN model and TE-topology
Connectivity Matrix sub-model to illustrate how a VN can be created 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 by the CNC making use of the VN module as well as the TE-topology
Connectivity Matrix module. Connectivity Matrix module.
4. VN Model Usage 3.2.1. VN and AP Usage
4.1. Customer view of VN 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.
4. VN Model Usage
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
[ACTN-INFO]. 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.
4.3.2. Multi-sources and Multi-destinations 4.3.2. Multi-sources and Multi-destinations
In creating a virtual network, the list of sources or destinations In creating a virtual network, the list of sources or destinations or
or both may not be pre-determined by the customer. For instance, for both may not be pre-determined by the customer. For instance, for a
a given source, there may be a list of multiple-destinations to given source, there may be a list of multiple-destinations to which
which the optimal destination may be chosen depending on the network the optimal destination may be chosen depending on the network
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 also be multiple-sources from which the optimal source may be chosen.
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 destinations from which the optimal source-destination may be chosen.
chosen. The following YANG module is shown for describing source The following YANG module is shown for describing source container
container and destination container. The following YANG tree shows and destination container. The following YANG tree shows how to
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 uint32
+--rw vn-name? string +--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 uint32
| +--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 connetivity-matrix-id? | +--rw connectivity-matrix-id? leafref
-> /nw:networks/network/node/tet:te/te-node-attributes/connectivity- | +--ro oper-status? identityref
matrices/connectivity-matrix/id +--ro if-selected? boolean {multi-src-dest}?
| +--ro oper-status? identityref +--rw admin-status? identityref
+--ro if-selected? boolean {multi-src-dest}? +--ro oper-status? identityref
+--rw admin-status? identityref +--rw vn-level-diversity? vn-disjointness
+--ro oper-status? identityref
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 [TE-MAP]. 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 The VN Yang model can be extended to support telemetry, performance
monitoring and network autonomics as described in [ACTN-PM]. monitoring and network autonomics as described in
[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 * VN Type 1: Customer configures the VN as a set of VN Members.
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 provide an abstract topology, this topology is provided by the
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 uint32
| +-rw access-point-name? string | +--rw access-point-name? string
| +-rw max-bandwidth? te-types:te-bandwidth | +--rw pe?
| +-rw avl-bandwidth? te-types:te-bandwidth | | -> /nw:networks/network/node/tet:te-node-id
| +-rw vn-ap* [vn-ap-id] | +--rw max-bandwidth? te-types:te-bandwidth
| +-rw vn-ap-id uint32 | +--rw avl-bandwidth? te-types:te-bandwidth
| +-rw vn? | +--rw vn-ap* [vn-ap-id]
-> /vn/vn-list/vn-id | +--rw vn-ap-id uint32
| +-rw abstract-node? | +--rw vn? -> /vn/vn-list/vn-id
-> /nw:networks/network/node/tet:te-node-id | +--rw abstract-node?
| +-rw ltp? | | -> /nw:networks/network/node/tet:te-node-id
-> /nw:networks/network/node/nt:termination-point/tet:te-tp-id | +--rw ltp? leafref
+-rw vn +--rw vn
+-rw vn-list* [vn-id] +--rw vn-list* [vn-id]
+-rw vn-id uint32 +--rw vn-id uint32
+-rw vn-name? string +--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 uint32
| +-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? | +--rw connectivity-matrix-id? leafref
-> /nw:networks/network/node/tet:te/te-node-attribute | +--ro oper-status? identityref
/connectivity-matrices/connectivity-matrix/id +--ro if-selected? boolean {multi-src-dest}?
| +-ro oper-status? identityref +--rw admin-status? identityref
+-ro if-selected? boolean {multi-src-dest}? +--ro oper-status? identityref
+-rw admin-status? identityref +--rw vn-level-diversity? vn-disjointness
+-ro oper-status? identityref
+-rw vn-level-diversity? vn-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 uint32
| | +--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? | | +---w connectivity-matrix-id? leafref
-> /nw:networks/network/node/tet:te/te-node-attributes | +---w vn-level-diversity? vn-disjointness
/connectivity-matrices/connectivity-matrix/id +--ro output
| +--w vn-level-diversity? vn-disjointness +--ro vn-member-list* [vn-member-id]
+-ro output +--ro vn-member-id uint32
+-ro vn-member-list* [vn-member-id] +--ro src
+-ro vn-member-id uint32 | +--ro src?
+-ro src | | -> /ap/access-point-list/access-point-id
| +-ro src? -> | +--ro src-vn-ap-id?
/ap/access-point-list/access-point-id | | -> /ap/access-point-list/vn-ap/vn-ap-id
| +-ro src-vn-ap-id? -> | +--ro multi-src? boolean {multi-src-dest}?
/ap/access-point-list/vn-ap/vn-ap-id +--ro dest
| +-ro multi-src? boolean {multi-src-dest}? | +--ro dest?
+-ro dest | | -> /ap/access-point-list/access-point-id
| +-ro dest? -> | +--ro dest-vn-ap-id?
/ap/access-point-list/access-point-id | | -> /ap/access-point-list/vn-ap/vn-ap-id
| +-ro dest-vn-ap-id? -> | +--ro multi-dest? boolean {multi-src-dest}?
/ap/access-point-list/vn-ap/vn-ap-id +--ro connectivity-matrix-id? leafref
| +-ro multi-dest? boolean {multi-src-dest}? +--ro if-selected? boolean
+-ro connectivity-matrix-id? | {multi-src-dest}?
-> /nw:networks/network/node/tet:te/te-node-attributes +--ro compute-status? identityref
/connectivity-matrices/connectivity-matrix/id
+-ro if-selected? boolean {multi-src-dest}?
+-ro compute-status? identityref
6. VN YANG Code 6. VN YANG Code
The YANG code is as follows: The YANG code is as follows:
<CODE BEGINS> file "ietf-vn@2019-06-20.yang" <CODE BEGINS> file "ietf-vn@2019-10-31.yang"
module ietf-vn {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-vn";
prefix vn;
module ietf-vn { /* Import network */
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-vn";
prefix "vn";
/* 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 ietf-network-topology {
prefix "nt";
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
/* Import TE generic types */ /* Import network topology */
import ietf-te-types {
prefix "te-types";
reference
"I-D.ietf-teas-yang-te-types: Traffic Engineering
Common YANG Types";
}
/* Import Abstract TE Topology */ import ietf-network-topology {
import ietf-te-topology { prefix nt;
prefix "tet"; reference
reference "RFC 8345: A YANG Data Model for Network Topologies";
"I-D.ietf-teas-yang-te-topo: YANG Data Model for }
Traffic Engineering (TE) Topologies";
}
organization /* Import TE Common types */
"IETF Traffic Engineering Architecture and Signaling (TEAS)
Working Group"; import ietf-te-types {
contact prefix te-types;
"Editor: Young Lee <younglee.tx@gmail.com> reference
: Dhruv Dhody <dhruv.ietf@gmail.com>"; "I-D.ietf-teas-yang-te-types: Traffic Engineering Common
YANG Types";
}
/* 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.";
revision 2019-10-31 {
description description
"This module contains a YANG module for the VN. It "initial version.";
describes a VN operation module that takes place in the reference
context of the CNC-MDSC Interface (CMI) of the ACTN "RFC XXXX: A Yang Data Model for VN Operation";
architecture where the CNC is the actor of a VN }
Instantiation/modification /deletion.";
revision 2019-06-20 { /* Features */
feature multi-src-dest {
description
"Support for selection of one src or destination
among multiple.";
}
/* 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-computatione-failed {
base vn-compute-state-type;
description
"State path compute failed";
}
/* typedef */
typedef vn-disjointness {
type bits {
bit node {
position 0;
description description
"initial version."; "node disjoint";
reference }
"TBD"; bit link {
} position 1;
/*
* Features
*/
feature multi-src-dest {
description description
"Support for selection of one src or destination "link disjoint";
among multiple."; }
bit srlg {
position 2;
description
"srlg disjoint";
}
} }
description
"type of the resource disjointness for VN level applied
across all VN members in a VN";
}
/*identity path-metric-delay { /* Groupings */
base te-types:path-metric-type;
description
"delay path metric";
}
identity path-metric-delay-variation {
base te-types:path-metric-type;
description
"delay-variation path metric";
}
identity path-metric-loss {
base te-types:path-metric-type;
description
"loss path metric";
}*/
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-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-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-computatione-failed {
base vn-compute-state-type;
description
"State path compute failed";
}
/*
* Groupings
*/
typedef vn-disjointness { grouping vn-ap {
type bits { description
bit node { "VNAP related information";
position 0; leaf vn-ap-id {
description "node disjoint"; type uint32;
} description
bit link { "unique identifier for the referred VNAP";
position 1; }
description "link disjoint"; leaf vn {
} type leafref {
bit srlg { path "/vn/vn-list/vn-id";
position 2;
description "srlg disjoint";
}
} }
description description
"type of the resource disjointness for "reference to the VN";
VN level applied across all VN members }
in a 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
"Reference LTP in the TE-topology";
}
}//vn-ap
grouping vn-ap { grouping access-point {
description description
"VNAP related information"; "AP related information";
leaf vn-ap-id { leaf access-point-id {
type uint32; type uint32;
description description
"unique identifier for the referred "unique identifier for the referred access point";
VNAP";
}
leaf vn {
type leafref {
path "/vn/vn-list/vn-id";
}
description
"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";
}
leaf ltp {
type leafref {
path "/nw:networks/nw:network/nw:node/"
+"nt:termination-point/tet:te-tp-id";
}
description
"Reference LTP in the TE-topology";
}
} }
grouping access-point{ leaf access-point-name {
description type string;
"AP related information"; description
leaf access-point-id { "ap name";
type uint32; }
description leaf pe {
"unique identifier for the referred type leafref {
access point"; path "/nw:networks/nw:network/nw:node/tet:te-node-id";
} }
leaf access-point-name { description
type string; "a reference to the PE node in the native TE Topology";
description }
"ap name"; leaf max-bandwidth {
} type te-types:te-bandwidth;
description
"max bandwidth of the AP";
}
leaf avl-bandwidth {
type te-types:te-bandwidth;
description
"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";
}
}//access-point
leaf max-bandwidth { grouping vn-member {
type te-types:te-bandwidth; description
description "vn-member is described by this container";
"max bandwidth of the AP"; leaf vn-member-id {
} type uint32;
leaf avl-bandwidth { description
type te-types:te-bandwidth; "vn-member identifier";
description }
"available bandwidth of the AP"; container src {
} description
/*add details and any other properties of AP, "the source of VN Member";
not associated by a VN leaf src {
CE port, PE port etc. type leafref {
*/ path "/ap/access-point-list/access-point-id";
list vn-ap {
key vn-ap-id;
uses vn-ap;
description
"list of VNAP in this AP";
} }
}//access-point
grouping vn-member {
description description
"vn-member is described by this container"; "reference to source AP";
leaf vn-member-id { }
type uint32; leaf src-vn-ap-id {
description type leafref {
"vn-member identifier"; path "/ap/access-point-list/vn-ap/vn-ap-id";
} }
container src description
{ "reference to source VNAP";
description }
"the source of VN Member"; leaf multi-src {
leaf src { if-feature "multi-src-dest";
type leafref { type boolean;
path "/ap/access-point-list/access-point-id"; description
} "Is source part of multi-source, where
description only one of the source is enabled";
"reference to source AP"; }
} }
leaf src-vn-ap-id{ container dest {
type leafref { description
path "/ap/access-point-list/vn-ap/vn-ap-id"; "the destination of VN Member";
} leaf dest {
description type leafref {
"reference to source VNAP"; path "/ap/access-point-list/access-point-id";
}
leaf multi-src {
if-feature multi-src-dest;
type boolean;
description
"Is source part of multi-source, where
only one of the source is enabled";
}
} }
container dest description
{ "reference to destination AP";
description }
"the destination of VN Member"; leaf dest-vn-ap-id {
leaf dest { type leafref {
type leafref { path "/ap/access-point-list/vn-ap/vn-ap-id";
path "/ap/access-point-list/access-point-id";
}
description
"reference to destination AP";
}
leaf dest-vn-ap-id{
type leafref {
path "/ap/access-point-list/vn-ap/vn-ap-id";
}
description
"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{ description
type leafref { "reference to dest VNAP";
path "/nw:networks/nw:network/nw:node/tet:te/" }
+ "tet:te-node-attributes/" leaf multi-dest {
+ "tet:connectivity-matrices/" if-feature "multi-src-dest";
+ "tet:connectivity-matrix/tet:id"; 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
"reference to connectivity-matrix";
}
}//vn-member
} grouping vn-policy {
description description
"reference to connectivity-matrix"; "policy for VN-level diverisity";
} leaf vn-level-diversity {
}//vn-member type vn-disjointness;
/* description
grouping policy { "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 description
"policy related to vn-member-id"; "access-point information";
leaf local-reroute { }
type boolean;
description
"Policy to state if reroute
can be done locally";
}
leaf push-allowed {
type boolean;
description
"Policy to state if changes
can be pushed to the customer";
}
leaf incremental-update {
type boolean;
description
"Policy to allow only the
changes to be reported";
}
}//policy
*/
grouping vn-policy {
description
"policy for VN-level diverisity";
leaf vn-level-diversity {
type vn-disjointness;
description
"the type of disjointness on the VN level
(i.e., across all VN members)";
}
} }
/* }
grouping metrics-op { 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 uint32;
description description
"metric related information"; "a unique vn identifier";
list metric{ }
key "metric-type"; leaf vn-name {
config false; type string;
description description
"The list of metrics for VN"; "vn name";
leaf metric-type { }
type identityref { leaf vn-topology-id {
base te-types:path-metric-type; type te-types:te-topology-id;
} description
description "An optional identifier to the TE Topology Model where the
"The VN metric type."; abstract nodes and links of the Topology can be found for
} Type 2 VNS";
leaf value{ }
type uint32; leaf abstract-node {
description type leafref {
"The limit value"; path "/nw:networks/nw:network/nw:node/tet:te-node-id";
}
} }
}
*/
/*
grouping metrics {
description description
"metric related information"; "a reference to the abstract node in TE Topology";
list metric{ }
key "metric-type"; list vn-member-list {
description key "vn-member-id";
"The list of metrics for VN"; description
uses te:path-metrics-bounds_config; "List of VN-members in a VN";
container optimize{ uses vn-member;
description leaf oper-status {
"optimizing constraints"; type identityref {
leaf enabled{ base vn-state-type;
type boolean; }
description config false;
"Metric to optimize"; description
} "VN-member operational state.";
leaf value{
type uint32;
description
"The computed value";
}
}
} }
} }
*/ leaf if-selected {
/* if-feature "multi-src-dest";
grouping service-metric { type boolean;
default "false";
config false;
description description
"service-metric"; "Is the vn-member is selected among the multi-src/dest
uses te:path-objective-function_config; options";
uses metrics; }
uses te-types:common-constraints_config; leaf admin-status {
uses te:protection-restoration-params_config; type identityref {
uses policy; base vn-admin-state-type;
}//service-metric
*/
/*
* Configuration data nodes
*/
container ap {
description
"AP configurations";
list access-point-list {
key "access-point-id";
description
"access-point identifier";
uses access-point {
description
"access-point information";
}
}
} }
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
}//vn
container vn { /* RPC */
description
"VN configurations";
list vn-list {
key "vn-id";
description
"a virtual network is identified by a vn-id";
leaf vn-id {
type uint32;
description
"a unique vn identifier";
}
leaf vn-name {
type string;
description "vn name";
}
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;
/*uses metrics-op;*/
leaf oper-status {
type identityref {
base vn-state-type;
}
config false;
description
"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";
}
/*
container multi-src-dest{
if-feature multi-src-dest;
config false;
description
"The selected VN Member when multi-src
and/or mult-destination is enabled.";
leaf selected-vn-member{
type leafref {
path "/vn/vn-list/vn-member-list"
+ "/vn-member-id";
}
description
"The selected VN Member along the set
of source and destination configured
with multi-source and/or multi-destination";
}
}
*/
/*uses service-metric;*/
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
}//vn
/* rpc vn-compute {
* Notifications - TBD description
*/ "The VN computation without actual instantiation";
/* input {
* RPC leaf abstract-node {
*/ type leafref {
rpc vn-compute{ path "/nw:networks/nw:network/nw:node/tet:te-node-id";
}
description description
"The VN computation without actual "a reference to the abstract node in TE Topology";
instantiation"; }
input { list vn-member-list {
leaf abstract-node { key "vn-member-id";
type leafref { description
path "/nw:networks/nw:network/nw:node/" "List of VN-members in a VN";
+ "tet:te-node-id"; uses vn-member;
} }
description uses vn-policy;
"a reference to the abstract node in TE }
Topology"; output {
} 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 if-selected {
} if-feature "multi-src-dest";
uses vn-policy; type boolean;
/*uses service-metric;*/ default "false";
description
"Is the vn-member is selected among the multi-src/dest
options";
} }
output { leaf compute-status {
list vn-member-list{ type identityref {
key "vn-member-id"; base vn-compute-state-type;
description }
"List of VN-members in a VN"; description
uses vn-member; "VN-member compute state.";
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";
}
/*uses metrics-op;*/
leaf compute-status {
type identityref {
base vn-compute-state-type;
}
description
"VN-member compute state.";
}
}
/*
container multi-src-dest{
if-feature multi-src-dest;
description
"The selected VN Member when multi-src
and/or mult-destination is enabled.";
leaf selected-vn-member-id{
type uint32;
description
"The selected VN Member-id from the
input";
}
}*/
} }
}
} }
}//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
o VN1 (Type 1): Which maps to the single node topology abstract1 o VN1 (Type 1): Which maps to the single node topology abstract1
(node D1) and consist of VN Members 104 (L1 to L4), 107 (L1 to (node D1) and consist of VN Members 104 (L1 to L4), 107 (L1 to
L7), 204 (L2 to L4), 308 (L3 to L8) and 108 (L1 to L8). We also L7), 204 (L2 to L4), 308 (L3 to L8) and 108 (L1 to L8). We also
show how disjointness (node, link, srlg) is supported in the show how disjointness (node, link, srlg) is supported in the
example on the global level (i.e., connectivity matrices level). example on the global level (i.e., connectivity matrices level).
o VN2 (Type 2): Which maps to the single node topology abstract2 o VN2 (Type 2): Which maps to the single node topology abstract2
(node D2), this topology has an underlay topology (absolute) (see (node D2), this topology has an underlay topology (absolute) (see
figure in section 3.2). This VN has a single VN member 105 (L1 to figure in section 3.2). This VN has a single VN member 105 (L1 to
L5) and an underlay path (S4 and S7) has been set in the L5) and an underlay path (S4 and S7) has been set in the
connectivity matrix of abstract2 topology; connectivity matrix of abstract2 topology;
o VN3 (Type 1): This VN has a multi-source, multi-destination o VN3 (Type 1): This VN has a multi-source, multi-destination
feature enable for VN Member 104 (L1 to L4)/107 (L1 to L7) feature enable for VN Member 104 (L1 to L4)/107 (L1 to L7) {multi-
[multi-src] and VN Member 204 (L2 to L4)/304 (L3 to L4) [multi- src} and VN Member 204 (L2 to L4)/304 (L3 to L4) {multi-dest}
dest] usecase. The selected VN-member is known via the field "if- usecase. The selected VN-member is known via the field "if-
selected" and the corresponding connectivity-matrix-id. selected" and the corresponding connectivity-matrix-id.
Note that the VN YANG model also include the AP and VNAP which shows Note that the VN YANG model also include the AP and VNAP which shows
various VN using the same AP. various VN using the same AP.
7.1. VN JSON
{
"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,
},
]
},
] 7.1. VN JSON
}
}
}
7.2. TE-topology JSON {
"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,
{ },
"networks": { "connectivity-matrix-id": 308
"network": [ },
{ {
"network-types": { "vn-member-id": 108,
"te-topology": {} "src": {
}, "src": 101,
"network-id": "abstract1", "src-vn-ap-id": 10101,
"provider-id": 201, },
"client-id": 600, "dest": {
"te-topology-id": "te-topology:abstract1", "dest": 880,
"node": [ "dest-vn-ap-id": 88001,
{ },
"node-id": "D1", "connectivity-matrix-id": 108
"te-node-id": "2.0.1.1", }
"te": { ]
"te-node-attributes": { },
"domain-id" : 1, {
"is-abstract": [null], "vn-id": 2,
"connectivity-matrices": { "vn-name": "vn2",
"is-allowed": true, "vn-topology-id": "te-topology:abstract2",
"path-constraints": { "abstract-node": "D2",
"bandwidth-generic": { "vn-member-list": [
"te-bandwidth": { {
"generic": [ "vn-member-id": 105,
{ "src": {
"generic": "0x1p10", "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
} }
"disjointness": "node link srlg", },
{
}, "vn-member-id": 107,
"connectivity-matrix": [ "src": {
{ "src": 101,
"id": 104, "src-vn-ap-id": 10103,
"from": "1-0-1",
"to": "4-4-0"
}, },
{ "dest": {
"id": 107, "dest": 770,
"from": "1-0-1", "dest-vn-ap-id": 77003,
"to": "7-7-0" "multi-dest": true
}, },
{ "connectivity-matrix-id": 107,
"id": 204, "if-selected":true,
"from": "2-0-2", },
"to": "4-4-0" {
"vn-member-id": 204,
"src": {
"src": 202,
"multi-src": true,
}, },
{ "dest": {
"id": 308, "dest": 440,
"from": "3-0-3",
"to": "8-8-0"
}, },
{ },
"id": 108, {
"from": "1-0-1", "vn-member-id": 304,
"to": "8-8-0" "src": {
"src": 303,
"src-vn-ap-id": 30303,
"multi-src": true,
}, },
] "dest": {
} "dest": 440,
} "src-vn-ap-id": 44003,
}, },
"termination-point": [ "connectivity-matrix-id": 304,
{ "if-selected":true,
"tp-id": "1-0-1", },
"te-tp-id": 10001, ]
"te": { },
"interface-switching-capability": [
{ ]
"switching-capability": "switching-otn", }
"encoding": "lsp-encoding-oduk"
}
}
7.2. TE-topology JSON
{
"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-1-0",
"te-tp-id": 10100, {
"te": { "tp-id": "1-0-1",
"interface-switching-capability": [ "te-tp-id": 10001,
{ "te": {
"switching-capability": "switching-otn", "interface-switching-capability": [
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk" "encoding": "lsp-encoding-oduk"
} }
] ]
} }
}, },
{ {
"tp-id": "2-0-2", "tp-id": "1-1-0",
"te-tp-id": 20002, "te-tp-id": 10100,
"te": { "te": {
"interface-switching-capability": [ "interface-switching-capability": [
{ {
"switching-capability": "switching-otn", "switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk" "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" "tp-id": "2-0-2",
} "te-tp-id": 20002,
}, "te": {
"connectivity-matrix": [ "interface-switching-capability": [
{ {
"id": 105, "switching-capability": "switching-otn",
"from": "1-0-1", "encoding": "lsp-encoding-oduk"
"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"
}
}
]
}
} }
} ]
] }
} },
} {
}, "tp-id": "2-2-0",
"termination-point": [ "te-tp-id": 20200,
{ "te": {
"tp-id": "1-0-1", "interface-switching-capability": [
"te-tp-id": 10001, {
"te": { "switching-capability": "switching-otn",
"interface-switching-capability": [ "encoding": "lsp-encoding-oduk"
{
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk"
} }
] ]
} }
}, },
{ {
"tp-id": "1-1-0",
"te-tp-id": 10100, "tp-id": "3-0-3",
"te": { "te-tp-id": 30003,
"interface-switching-capability": [ "te": {
{ "interface-switching-capability": [
"switching-capability": "switching-otn", {
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk" "encoding": "lsp-encoding-oduk"
} }
] ]
} }
}, },
{ {
"tp-id": "2-0-2", "tp-id": "3-3-0",
"te-tp-id": 20002, "te-tp-id": 30300,
"te": { "te": {
"interface-switching-capability": [ "interface-switching-capability": [
{ {
"switching-capability": "switching-otn", "switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk" "encoding": "lsp-encoding-oduk"
} }
] ]
}
}, }
{ },
"tp-id": "2-2-0", {
"te-tp-id": 20200, "tp-id": "4-0-4",
"te": { "te-tp-id": 40004,
"interface-switching-capability": [ "te": {
{ "interface-switching-capability": [
"switching-capability": "switching-otn", {
"encoding": "lsp-encoding-oduk" "switching-capability": "switching-otn",
} "encoding": "lsp-encoding-oduk"
] }
} ]
}, }
{ },
"tp-id": "3-0-3", {
"te-tp-id": 30003, "tp-id": "4-4-0",
"te": { "te-tp-id": 40400,
"interface-switching-capability": [ "te": {
{ "interface-switching-capability": [
"switching-capability": "switching-otn", {
"encoding": "lsp-encoding-oduk" "switching-capability": "switching-otn",
} "encoding": "lsp-encoding-oduk"
] }
} ]
}, }
{ },
"tp-id": "3-3-0", {
"te-tp-id": 30300, "tp-id": "5-0-5",
"te": { "te-tp-id": 50005,
"interface-switching-capability": [ "te": {
{ "interface-switching-capability": [
"switching-capability": "switching-otn", {
"encoding": "lsp-encoding-oduk" "switching-capability": "switching-otn",
} "encoding": "lsp-encoding-oduk"
] }
} ]
}, }
{ },
"tp-id": "4-0-4", {
"te-tp-id": 40004, "tp-id": "5-5-0",
"te": { "te-tp-id": 50500,
"interface-switching-capability": [ "te": {
{ "interface-switching-capability": [
"switching-capability": "switching-otn", {
"encoding": "lsp-encoding-oduk" "switching-capability": "switching-otn",
} "encoding": "lsp-encoding-oduk"
] }
} ]
},
{ }
"tp-id": "4-4-0", },
"te-tp-id": 40400, {
"te": { "tp-id": "6-0-6",
"interface-switching-capability": [ "te-tp-id": 60006,
{ "te": {
"switching-capability": "switching-otn", "interface-switching-capability": [
"encoding": "lsp-encoding-oduk" {
} "switching-capability": "switching-otn",
] "encoding": "lsp-encoding-oduk"
} }
}, ]
{ }
"tp-id": "5-0-5", },
"te-tp-id": 50005, {
"te": { "tp-id": "6-6-0",
"interface-switching-capability": [ "te-tp-id": 60600,
{ "te": {
"switching-capability": "switching-otn", "interface-switching-capability": [
"encoding": "lsp-encoding-oduk" {
} "switching-capability": "switching-otn",
] "encoding": "lsp-encoding-oduk"
} }
}, ]
{ }
"tp-id": "5-5-0", },
"te-tp-id": 50500, {
"te": { "tp-id": "7-0-7",
"interface-switching-capability": [ "te-tp-id": 70007,
{ "te": {
"switching-capability": "switching-otn", "interface-switching-capability": [
"encoding": "lsp-encoding-oduk" {
} "switching-capability": "switching-otn",
] "encoding": "lsp-encoding-oduk"
} }
}, ]
{ }
"tp-id": "6-0-6", },
"te-tp-id": 60006, {
"te": { "tp-id": "7-7-0",
"interface-switching-capability": [ "te-tp-id": 70700,
{ "te": {
"switching-capability": "switching-otn", "interface-switching-capability": [
"encoding": "lsp-encoding-oduk" {
} "switching-capability": "switching-otn",
] "encoding": "lsp-encoding-oduk"
} }
}, ]
{
"tp-id": "6-6-0", }
"te-tp-id": 60600, },
"te": { {
"interface-switching-capability": [ "tp-id": "8-0-8",
{ "te-tp-id": 80008,
"switching-capability": "switching-otn", "te": {
"encoding": "lsp-encoding-oduk" "interface-switching-capability": [
} {
] "switching-capability": "switching-otn",
} "encoding": "lsp-encoding-oduk"
}, }
{ ]
"tp-id": "7-0-7", }
"te-tp-id": 70007, },
"te": { {
"interface-switching-capability": [ "tp-id": "8-8-0",
{ "te-tp-id": 80800,
"switching-capability": "switching-otn", "te": {
"encoding": "lsp-encoding-oduk" "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, "network-types": {
"client-id": 600, "te-topology": {}
"te-topology-id": "te-topology:abstract3", },
"node": [ "network-id": "abstract2",
{ "provider-id": 201,
"node-id": "D3", "client-id": 600,
"te-node-id": "3.0.1.1", "te-topology-id": "te-topology:abstract2",
"te": { "node": [
"te-node-attributes": { {
"domain-id" : 3, "node-id": "D2",
"is-abstract": [null], "te-node-id": "2.0.1.2",
"connectivity-matrices": { "te": {
"is-allowed": true, "te-node-attributes": {
"path-constraints": { "domain-id" : 1,
"bandwidth-generic": { "is-abstract": [null],
"te-bandwidth": { "connectivity-matrices": {
"generic": [ "is-allowed": true,
{ "underlay": {
"generic": "0x1p10", "enabled": true
} },
"path-constraints": {
] "bandwidth-generic": {
"te-bandwidth": {
"generic": [
{
"generic": "0x1p10"
}
]
}
} }
}
},
"connectivity-matrix": [
{
"id": 107,
"from": "1-0-1",
"to": "7-7-0"
}, },
{ "optimizations": {
"id": 308, "objective-function": {
"from": "3-0-3", "objective-function-type":
"to": "8-8-0" "of-maximize-residual-bandwidth"
}
}, },
] "connectivity-matrix": [
} {
} "id": 105,
}, "from": "1-0-1",
"termination-point": [ "to": "5-5-0",
{ "underlay": {
"tp-id": "1-0-1", "enabled": true,
"te-tp-id": 10001, "primary-path": {
"te": { "network-ref": "absolute",
"interface-switching-capability": [ "path-element": [
{ {
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk" "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-1-0", {
"te-tp-id": 10100, "tp-id": "1-0-1",
"te": { "te-tp-id": 10001,
"interface-switching-capability": [ "te": {
{ "interface-switching-capability": [
"switching-capability": "switching-otn", {
"switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk" "encoding": "lsp-encoding-oduk"
} }
] ]
} }
}, },
{ {
"tp-id": "2-0-2", "tp-id": "1-1-0",
"te-tp-id": 20002, "te-tp-id": 10100,
"te": { "te": {
"interface-switching-capability": [ "interface-switching-capability": [
{ {
"switching-capability": "switching-otn", "switching-capability": "switching-otn",
"encoding": "lsp-encoding-oduk" "encoding": "lsp-encoding-oduk"
} }
] ]
} }
}, },
{ {
"tp-id": "2-2-0",
"te-tp-id": 20200, "tp-id": "2-0-2",
"te": { "te-tp-id": 20002,
"interface-switching-capability": [ "te": {
{ "interface-switching-capability": [
"switching-capability": "switching-otn", {
"encoding": "lsp-encoding-oduk" "switching-capability": "switching-otn",
} "encoding": "lsp-encoding-oduk"
] }
} ]
}, }
{ },
"tp-id": "3-0-3", {
"te-tp-id": 30003, "tp-id": "2-2-0",
"te": { "te-tp-id": 20200,
"interface-switching-capability": [ "te": {
{ "interface-switching-capability": [
"switching-capability": "switching-otn", {
"encoding": "lsp-encoding-oduk" "switching-capability": "switching-otn",
} "encoding": "lsp-encoding-oduk"
] }
} ]
}, }
{ },
"tp-id": "3-3-0", {
"te-tp-id": 30300, "tp-id": "3-0-3",
"te": { "te-tp-id": 30003,
"interface-switching-capability": [ "te": {
{ "interface-switching-capability": [
"switching-capability": "switching-otn", {
"encoding": "lsp-encoding-oduk" "switching-capability": "switching-otn",
} "encoding": "lsp-encoding-oduk"
] }
} ]
}, }
{ },
"tp-id": "4-0-4", {
"te-tp-id": 40004, "tp-id": "3-3-0",
"te": { "te-tp-id": 30300,
"interface-switching-capability": [ "te": {
{ "interface-switching-capability": [
"switching-capability": "switching-otn", {
"encoding": "lsp-encoding-oduk" "switching-capability": "switching-otn",
} "encoding": "lsp-encoding-oduk"
] }
} ]
}, }
{ },
"tp-id": "4-4-0", {
"te-tp-id": 40400, "tp-id": "4-0-4",
"te": { "te-tp-id": 40004,
"interface-switching-capability": [ "te": {
{ "interface-switching-capability": [
"switching-capability": "switching-otn", {
"encoding": "lsp-encoding-oduk" "switching-capability": "switching-otn",
} "encoding": "lsp-encoding-oduk"
] }
} ]
}, }
{ },
"tp-id": "5-0-5", {
"te-tp-id": 50005, "tp-id": "4-4-0",
"te": { "te-tp-id": 40400,
"interface-switching-capability": [ "te": {
{ "interface-switching-capability": [
"switching-capability": "switching-otn", {
"encoding": "lsp-encoding-oduk" "switching-capability": "switching-otn",
} "encoding": "lsp-encoding-oduk"
] }
} ]
}, }
{ },
"tp-id": "5-5-0", {
"te-tp-id": 50500, "tp-id": "5-0-5",
"te": { "te-tp-id": 50005,
"interface-switching-capability": [ "te": {
{ "interface-switching-capability": [
"switching-capability": "switching-otn", {
"encoding": "lsp-encoding-oduk" "switching-capability": "switching-otn",
} "encoding": "lsp-encoding-oduk"
] }
} ]
}, }
{ },
"tp-id": "6-0-6", {
"te-tp-id": 60006, "tp-id": "5-5-0",
"te": { "te-tp-id": 50500,
"interface-switching-capability": [ "te": {
{ "interface-switching-capability": [
"switching-capability": "switching-otn", {
"encoding": "lsp-encoding-oduk" "switching-capability": "switching-otn",
} "encoding": "lsp-encoding-oduk"
] }
} ]
}, }
{ },
"tp-id": "6-6-0", {
"te-tp-id": 60600, "tp-id": "6-0-6",
"te": { "te-tp-id": 60006,
"interface-switching-capability": [ "te": {
{ "interface-switching-capability": [
"switching-capability": "switching-otn", {
"encoding": "lsp-encoding-oduk" "switching-capability": "switching-otn",
} "encoding": "lsp-encoding-oduk"
] }
} ]
}, }
{ },
"tp-id": "7-0-7", {
"te-tp-id": 70007, "tp-id": "6-6-0",
"te": { "te-tp-id": 60600,
"interface-switching-capability": [ "te": {
{ "interface-switching-capability": [
"switching-capability": "switching-otn", {
"encoding": "lsp-encoding-oduk" "switching-capability": "switching-otn",
} "encoding": "lsp-encoding-oduk"
] }
} ]
}, }
{ },
"tp-id": "7-7-0", {
"te-tp-id": 70700, "tp-id": "7-0-7",
"te": { "te-tp-id": 70007,
"interface-switching-capability": [ "te": {
{ "interface-switching-capability": [
"switching-capability": "switching-otn", {
"encoding": "lsp-encoding-oduk" "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"
}
]
}
} }
}, ]
{ }
"tp-id": "8-0-8", ]
"te-tp-id": 80008, },
"te": { {
"interface-switching-capability": [ "network-types": {
{ "te-topology": {}
"switching-capability": "switching-otn", },
"encoding": "lsp-encoding-oduk" "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": "8-8-0", {
"te-tp-id": 80800, "tp-id": "1-0-1",
"te": { "te-tp-id": 10001,
"interface-switching-capability": [ "te": {
{ "interface-switching-capability": [
"switching-capability": "switching-otn", {
"encoding": "lsp-encoding-oduk" "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"
}
]
}
} }
} ]
] }
} ]
] },
}, ]
] }
} }
}
8. Security Considerations 8. Security Considerations
The configuration, state, and action data defined in this document The configuration, state, and action data defined in this document
are designed to be accessed via a management protocol with a secure are designed to be accessed via a management protocol with a secure
transport layer, such as NETCONF [RFC6241] or RESTCONF [RFC8040]. transport layer, such as NETCONF [RFC6241] or RESTCONF [RFC8040].
The lowest NETCONF layer is the secure transport layer, and the The lowest NETCONF layer is the secure transport layer, and the
mandatory-to-implement secure transport is Secure Shell (SSH) mandatory-to-implement secure transport is Secure Shell (SSH)
[RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory- [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-
to-implement secure transport is TLS [RFC8446]. to-implement secure transport is TLS [RFC8446].
The NETCONF access control model [RFC8341] provides the means to The NETCONF access control model [RFC8341] provides the means to
restrict access for particular NETCONF users to a preconfigured restrict access for particular NETCONF users to a preconfigured
subset of all available NETCONF protocol operations and content. subset of all available NETCONF protocol operations and content.
The model presented in this document is used in the interface The model presented in this document is used in the interface between
between the Customer Network Controller (CNC) and Multi-Domain the Customer Network Controller (CNC) and Multi-Domain Service
Service Coordinator (MDSC), which is referred to as CNC-MDSC Coordinator (MDSC), which is referred to as CNC-MDSC Interface (CMI).
Interface (CMI). Therefore, many security risks such as malicious Therefore, many security risks such as malicious attack and rogue
attack and rogue elements attempting to connect to various ACTN elements attempting to connect to various ACTN components.
components. Furthermore, some ACTN components (e.g., MSDC) Furthermore, some ACTN components (e.g., MSDC) represent a single
represent a single point of failure and threat vector and must also point of failure and threat vector and must also manage policy
manage policy conflicts and eavesdropping of communication between conflicts and eavesdropping of communication between different ACTN
different ACTN components. components.
A number of configuration data nodes defined in this document are A number of configuration data nodes defined in this document are
writable/deletable (i.e., "config true") These data nodes may be writable/deletable (i.e., "config true") These data nodes may be
considered sensitive or vulnerable in some network environments. considered sensitive or vulnerable in some network environments.
These are the subtrees and data nodes and their These are the subtrees and data nodes and their sensitivity/
sensitivity/vulnerability: vulnerability:
- access-point-list: o access-point-list:
o access-point-id
o max-bandwidth
o avl-bandwidth
- vn-ap: * access-point-id
o vn-ap-id
o vn
o abstract-node
o ltp
- vn-list * max-bandwidth
o vn-id
o vn-topology-id
o abstract-node
- vn-member-id * avl-bandwidth
o src
o src-vn-ap-id
o dest
o dest-vn-ap-id
o connectivity-matrix-id
9. IANA Considerations o vn-ap:
* vn-ap-id
* vn
* abstract-node
* ltp
o vn-list
* vn-id
* vn-topology-id
* abstract-node
o vn-member-id
* src
* src-vn-ap-id
* dest
* dest-vn-ap-id
* connectivity-matrix-id
9. IANA Considerations
This document registers the following namespace URIs in the IETF XML This document registers the following namespace URIs in the IETF XML
registry [RFC3688]: registry [RFC3688]:
-------------------------------------------------------------------- --------------------------------------------------------------------
URI: urn:ietf:params:xml:ns:yang:ietf-vn URI: urn:ietf:params:xml:ns:yang:ietf-vn
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
-------------------------------------------------------------------- --------------------------------------------------------------------
This document registers the following YANG modules in the YANG This document registers the following YANG modules in the YANG Module
Module
Names registry [RFC6020]: Names registry [RFC6020]:
-------------------------------------------------------------------- --------------------------------------------------------------------
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
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 and Adrian Farrel for
their helpful comments and valuable suggestions. their helpful comments and valuable suggestions.
11. References 11. References
11.1. Normative References 11.1. Normative References
[TE-TOPO] X. Liu, et al., "YANG Data Model for TE Topologies", work [I-D.ietf-teas-yang-te]
in progress: draft-ietf-teas-yang-te-topo. Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
"A YANG Data Model for Traffic Engineering Tunnels and
Interfaces", draft-ietf-teas-yang-te-21 (work in
progress), April 2019.
[TE-tunnel] T. Saad, et al., "A YANG Data Model for Traffic [I-D.ietf-teas-yang-te-topo]
Engineering Tunnels and Interfaces", work in progress: Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
draft-ietf-teas-yang-te. O. Dios, "YANG Data Model for Traffic Engineering (TE)
Topologies", draft-ietf-teas-yang-te-topo-22 (work in
progress), June 2019.
11.2. Informative References [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC7926] A. Farrel (Ed.), "Problem Statement and Architecture for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
Information Exchange between Interconnected Traffic- the Network Configuration Protocol (NETCONF)", RFC 6020,
Engineered Networks", RFC 7926, July 2016. DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[RFC8453] D. Ceccarelli and Y. Lee (Editors), "Framework for [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
Abstraction and Control of Traffic Engineered Networks", and A. Bierman, Ed., "Network Configuration Protocol
RFC 8453, August 2018. (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[TE-MAP] Y. Lee, D. Dhody, and D. Ceccarelli, "Traffic Engineering [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
and Service Mapping Yang Model", draft-lee-teas-te- Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
service-mapping-yang, work in progress. <https://www.rfc-editor.org/info/rfc6242>.
[ACTN-PM] Y. Lee, et al., "YANG models for ACTN TE Performance [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Monitoring Telemetry and Network Autonomics", draft-lee- Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
teas-actn-pm-telemetry-autonomics, work in progress. <https://www.rfc-editor.org/info/rfc8040>.
[L1CSM] G. Fioccola, Ed. & Y. Lee, Ed., "A Yang Data Model for L1 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Connectivity Service Model (L1CSM)", draft-ietf-ccamp- Access Control Model", STD 91, RFC 8341,
l1csm-yang, work in progress. DOI 10.17487/RFC8341, March 2018,
[L2SM] G. Fioccola, Ed., "A YANG Data Model for L2VPN Service <https://www.rfc-editor.org/info/rfc8341>.
Delivery", draft-ietf-l2sm-l2vpn-service-model, work in
progress.
[RFC8299] Q. Wu, Ed., S. Litkowski, L. Tomotaki, and K. Ogaki, "YANG [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Data Model for L3VPN Service Delivery", RFC 8299, January Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
2018. Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
2018, <https://www.rfc-editor.org/info/rfc8345>.
[RFC8309] Q. Wu, W. Cheng, and A. Farrel. "Service Models [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Explained", RFC 8309, January 2018. Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8340] M. Bjorklund and L. Berger (Editors), "YANG Tree 11.2. Informative References
Diagrams", RFC 8340, March 2018.
[RFC8345] A. Clemm, et al, "A YANG Data Model for Network [I-D.ietf-ccamp-l1csm-yang]
Topologies", RFC 8345, March 2018. Lee, Y., Lee, K., Zheng, H., Dhody, D., Dios, O., and D.
Ceccarelli, "A YANG Data Model for L1 Connectivity Service
Model (L1CSM)", draft-ietf-ccamp-l1csm-yang-10 (work in
progress), September 2019.
[I-D.ietf-teas-actn-pm-telemetry-autonomics]
Lee, Y., Dhody, D., Karunanithi, S., Vilata, R., King, D.,
and D. Ceccarelli, "YANG models for VN/TE Performance
Monitoring Telemetry and Scaling Intent Autonomics",
draft-ietf-teas-actn-pm-telemetry-autonomics-01 (work in
progress), October 2019.
[I-D.ietf-teas-te-service-mapping-yang]
Lee, Y., Dhody, D., Fioccola, G., WU, Q., Ceccarelli, D.,
and J. Tantsura, "Traffic Engineering (TE) and Service
Mapping Yang Model", draft-ietf-teas-te-service-mapping-
yang-02 (work in progress), September 2019.
[RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G.,
Ceccarelli, D., and X. Zhang, "Problem Statement and
Architecture for Information Exchange between
Interconnected Traffic-Engineered Networks", BCP 206,
RFC 7926, DOI 10.17487/RFC7926, July 2016,
<https://www.rfc-editor.org/info/rfc7926>.
[RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki,
"YANG Data Model for L3VPN Service Delivery", RFC 8299,
DOI 10.17487/RFC8299, January 2018,
<https://www.rfc-editor.org/info/rfc8299>.
[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
<https://www.rfc-editor.org/info/rfc8309>.
[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., [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, March 2018. (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>.
12. Contributors [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Abstraction and Control of TE Networks (ACTN)", RFC 8453,
DOI 10.17487/RFC8453, August 2018,
<https://www.rfc-editor.org/info/rfc8453>.
Contributor's Addresses [RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B.
Yoon, "Information Model for Abstraction and Control of TE
Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454,
September 2018, <https://www.rfc-editor.org/info/rfc8454>.
[RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG
Data Model for Layer 2 Virtual Private Network (L2VPN)
Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October
2018, <https://www.rfc-editor.org/info/rfc8466>.
Appendix A. Contributors Addresses
Qin Wu
Huawei Technologies
Email: bill.wu@huawei.com
Peter Park
KT
Email: peter.park@kt.com
Haomian Zheng Haomian Zheng
Huawei Technologies Huawei Technologies
Email: zhenghaomian@huawei.com Email: zhenghaomian@huawei.com
Xian Zhang Xian Zhang
Huawei Technologies Huawei Technologies
Email: zhang.xian@huawei.com Email: zhang.xian@huawei.com
Sergio Belotti Sergio Belotti
Nokia Nokia
Email: sergio.belotti@nokia.com Email: sergio.belotti@nokia.com
Takuya Miyasaka Takuya Miyasaka
KDDI KDDI
Email: ta-miyasaka@kddi.com Email: ta-miyasaka@kddi.com
Authors' Addresses Authors' Addresses
Young Lee (ed.) Young Lee (editor)
Futurewei Technologies SKKU
Email: younglee.tx@gmail.com Email: younglee.tx@gmail.com
Dhruv Dhody (ed.) Dhruv Dhody (editor)
Huawei Technologies Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
Email: dhruv.ietf@gmail.com Email: dhruv.ietf@gmail.com
Daniele Ceccarelli Daniele Ceccarelli
Ericsson Ericsson
Torshamnsgatan,48 Torshamnsgatan,48
Stockholm, Sweden Stockholm, Sweden
Email: daniele.ceccarelli@ericsson.com
Email: daniele.ceccarelli@ericsson.com
Igor Bryskin Igor Bryskin
Huawei Futurewei
Email: ibryskin@futurewei.com
Email: i_bryskin@yahoo.com
Bin Yeong Yoon Bin Yeong Yoon
ETRI ETRI
Email: byyun@etri.re.kr
Qin Wu Email: byyun@etri.re.kr
Huawei Technologies
Email: bill.wu@huawei.com
Peter Park
KT
Email: peter.park@kt.com
 End of changes. 183 change blocks. 
1934 lines changed or deleted 1918 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/