< draft-ietf-teas-actn-vn-yang-03.txt   draft-ietf-teas-actn-vn-yang-04.txt >
TEAS Working Group Y. Lee (Editor) TEAS Working Group Y. Lee (Editor)
Internet Draft Dhruv Dhody (Editor) Internet Draft Dhruv Dhody (Editor)
Intended Status: Standard Track Huawei Intended Status: Standard Track Huawei
Expires: June 30, 2019 D. Ceccarelli Expires: August 3, 2019 D. Ceccarelli
Ericsson Ericsson
Igor Bryskin Igor Bryskin
Huawei Huawei
Bin Yeong Yoon Bin Yeong Yoon
ETRI ETRI
Qin Wu Qin Wu
Huawei Huawei
Peter Park Peter Park
KT KT
December 30, 2018 February 4, 2019
A Yang Data Model for ACTN VN Operation A Yang Data Model for VN Operation
draft-ietf-teas-actn-vn-yang-03 draft-ietf-teas-actn-vn-yang-04
Abstract Abstract
This document provides a YANG data model for the Abstraction and This document provides a YANG data model generally applicable to any
Control of Traffic Engineered (TE) networks (ACTN) Virtual Network mode of Virtual Network (VN) operation.
Service (VNS) 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 to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the 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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 4 skipping to change at page 1, line 47
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on June 30, 2019.
This Internet-Draft will expire on August 3, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 (http://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 to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction...................................................3 Introduction.....................................................3
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. ACTN CMI context...............................................5 2. Use-case of VN Yang Model in the ACTN context..................5
2.1. Type 1 VN.................................................5 2.1. Type 1 VN.................................................5
2.2. Type 2 VN.................................................6 2.2. Type 2 VN.................................................6
3. High-Level Control Flows with Examples.........................7 3. High-Level Control Flows with Examples.........................7
3.1. Type 1 VN Illustration....................................7 3.1. Type 1 VN Illustration....................................7
3.2. Type 2 VN Illustration....................................8 3.2. Type 2 VN Illustration....................................8
4. ACTN VN Model Usage...........................................11 4. VN Model Usage................................................11
4.1. Customer view of VN......................................11 4.1. Customer view of VN......................................11
4.2. Auto-creation of VN by MDSC..............................11 4.2. Auto-creation of VN by MDSC..............................11
4.3. Innovative Services......................................11 4.3. Innovative Services......................................11
4.3.1. VN Compute..........................................11 4.3.1. VN Compute..........................................11
4.3.2. Multi-sources and Multi-destinations................12 4.3.2. Multi-sources and Multi-destinations................12
4.3.3. Others..............................................12 4.3.3. Others..............................................12
4.3.4. Summary.............................................13 4.3.4. Summary.............................................13
5. ACTN VN YANG Model (Tree Structure)...........................13 5. VN YANG Model (Tree Structure)................................13
6. ACTN-VN YANG Code.............................................15 6. VN YANG Code..................................................15
7. JSON Example..................................................27 7. JSON Example..................................................27
7.1. ACTN VN JSON.............................................28 7.1. VN JSON..................................................28
7.2. TE-topology JSON.........................................33 7.2. TE-topology JSON.........................................33
8. Security Considerations.......................................49 8. Security Considerations.......................................49
9. IANA Considerations...........................................51 9. IANA Considerations...........................................51
10. Acknowledgments..............................................51 10. Acknowledgments..............................................51
11. References...................................................52 11. References...................................................52
11.1. Normative References....................................52 11.1. Normative References....................................52
11.2. Informative References..................................52 11.2. Informative References..................................52
12. Contributors.................................................53 12. Contributors.................................................53
Authors' Addresses...............................................53 Authors' Addresses...............................................53
1. Introduction 1. Introduction
Abstraction and Control of Traffic Engineered Networks (ACTN) This document provides a YANG data model generally applicable to any
describes a set of management and control functions used to operate mode of Virtual Network (VN) operation.
one or more TE networks to construct virtual networks that can be
represented to customers and that are built from abstractions of the
underlying TE networks [RFC8453].
This document provides a YANG data model for the Abstraction and
Control of Traffic Engineered (TE) networks (ACTN) Virtual Network
Service (VNS) operation that is going to be implemented for the
Customer Network Controller (CNC)- Multi-Domain Service Coordinator
(MSDC) interface (CMI).
The YANG model on the CMI is also known as customer service model in
[RFC8309]. The YANG model discussed in this document is used to
operate customer-driven VNs during the VN instantiation, VN
computation, and its life-cycle service management and operations.
The VN model defined in this document is applicable in generic sense The VN model defined in this document is applicable in generic sense
outside of the ACTN context as an independent model in and of as an independent model in and of itself. The VN model defined in
itself. The VN model defined in this document can also work together this document can also work together with other customer service
with other customer service models such as L3SM [RFC8299], L2SM models such as L3SM [RFC8299], L2SM [L2SM] and L1CSM [L1CSM] to
[L2SM] and L1CSM [L1CSM] to provide a complete life-cycle service provide a complete life-cycle service management and operations.
management and operations.
The YANG model discussed in this document basically provides the The YANG model discussed in this document basically provides the
following: following:
o Characteristics of Access Points (APs) that describe customer's o Characteristics of Access Points (APs) that describe customer's
end point characteristics; end point characteristics;
o Characteristics of Virtual Network Access Points (VNAP) that o Characteristics of Virtual Network Access Points (VNAP) that
describe How an AP is partitioned for multiple VNs sharing the AP describe How an AP is partitioned for multiple VNs sharing the AP
and its reference to a Link Termination Point (LTP) of the and its reference to a Link Termination Point (LTP) of the
skipping to change at page 4, line 13 skipping to change at page 3, line 43
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 [TE-Topo]
which provides TE network topology abstraction and management which provides TE network topology abstraction and management
operation. Once TE-topology Model is used in triggering VN operation. Once TE-topology Model is used in triggering VN
instantiation over the networks, TE-tunnel [TE-tunnel] Model will instantiation over the networks, TE-tunnel [TE-tunnel] Model will
inevitably interact with TE-Topology model for setting up actual inevitably interact with TE-Topology model for setting up actual
tunnels and LSPs under the tunnels. tunnels and LSPs under the tunnels.
The ACTN VN operational state is included in the same tree as the Abstraction and Control of Traffic Engineered Networks (ACTN)
describes a set of management and control functions used to operate
one or more TE networks to construct virtual networks that can be
represented to customers and that are built from abstractions of the
underlying TE networks [RFC8453]. ACTN is the primary example of the
usage of the VN Yang model.
Sections 2 and 3 provide the discussion of how the VN Yang model is
applicable to the ACTN context where Virtual Network Service (VNS)
operation is implemented for the Customer Network Controller (CNC)-
Multi-Domain Service Coordinator (MSDC) interface (CMI).
The YANG model on the CMI is also known as customer service model in
[RFC8309]. The YANG model discussed in this document is used to
operate customer-driven VNs during the VN instantiation, VN
computation, and its life-cycle service management and operations.
The VN operational state is included in the same tree as the
configuration consistent with Network Management Datastore 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
skipping to change at page 5, line 5 skipping to change at page 5, line 5
| nw | ietf-network | [RFC8345] | | nw | ietf-network | [RFC8345] |
| te-types| ietf-te-types | [TE-Tunnel] | | te-types| ietf-te-types | [TE-Tunnel] |
| te-topo | ietf-te-topology | [TE-TOPO] | | te-topo | ietf-te-topology | [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. ACTN CMI context 2. Use-case of VN Yang Model in the ACTN context
The model presented in this document has the following ACTN context. In this section, ACTN is being used to illustrate the general usage
of the VN yang model. The model presented in this section has the
following ACTN context.
+-------+ +-------+
| CNC | | CNC |
+-------+ +-------+
| |
| VN YANG + TE-topology YANG | VN YANG + TE-topology YANG
| |
+-----------------------+ +-----------------------+
| MDSC | | MDSC |
+-----------------------+ +-----------------------+
skipping to change at page 8, line 9 skipping to change at page 8, line 12
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
+---------------+ +---------------+
If this VN is Type 1, the following diagram shows the message flow If this VN is Type 1, the following diagram shows the message flow
between CNC and MDSC to instantiate this VN using ACTN VN and TE- between CNC and MDSC to instantiate this VN using VN and TE-Topology
Topology Model. 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/tet:connectivity- | model(with Conn. | nw:node/te-node-id/tet:connectivity- |
Matrix on one | matrices/tet:connectivity-matrix | Matrix on one | matrices/tet:connectivity-matrix |
Abstract node |---------------------------------------->| Abstract node |---------------------------------------->|
| HTTP 200 | | HTTP 200 |
|<----------------------------------------| |<----------------------------------------|
| | | |
CNC POST the ACTN| POST /ACTN 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-dest'n
Members and maps | | module, then Members and maps | | module, then
to the TE-topo | HTTP 200 | MDSC selects a to the TE-topo | HTTP 200 | MDSC selects a
|<----------------------------------------| src or dest'n |<----------------------------------------| src or dest'n
| | and update | | and update
| | ACTN VN YANG | | VN YANG
CNC GET the ACTN | GET /ACTN VN | CNC GET the | GET /VN |
VN YANG status |---------------------------------------->| VN YANG status |---------------------------------------->|
| | | |
| HTTP 200 (ACTN VN with status: selected| | HTTP 200 (VN with status: selected |
| VN-members in case of multi s-d | | VN-members 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.
skipping to change at page 9, line 31 skipping to change at page 9, line 34
\ S6 \ S7 \ S8 \ S6 \ S7 \ S8
O ----------------O---------O--------------L5 O ----------------O---------O--------------L5
/ \ / \ ____/ \_____________L6 / \ / \ ____/ \_____________L6
S9 / \ /S10 \ / S9 / \ /S10 \ /
L2---------O-----O---------------------O---------------------L7 L2---------O-----O---------------------O---------------------L7
/ S11\____________________L8 / S11\____________________L8
L3-------- L3--------
If CNC creates the single abstract topology, the following diagram If CNC creates the single abstract topology, the following diagram
shows the message flow between CNC and MDSC to instantiate this VN shows the message flow between CNC and MDSC to instantiate this VN
using ACTN VN and TE-Topology Model. using VN and TE-Topology Model.
+--------+ +--------+ +--------+ +--------+
| CNC | | MDSC | | CNC | | MDSC |
+--------+ +--------+ +--------+ +--------+
| | | |
| | | |
CNC POST TE-topo | POST /nw:networks/nw:network/ | CNC POST TE-topo | POST /nw:networks/nw:network/ |
model(with Conn. | nw:node/te-node-id/tet:connectivity- | model(with Conn. | nw:node/te-node-id/tet:connectivity- |
Matrix on one | matrices/tet:connectivity-matrix | Matrix on one | matrices/tet:connectivity-matrix |
Abstract node and|---------------------------------------->| Abstract node and|---------------------------------------->|
Explicit paths in| | Explicit paths in| |
The conn. Matrix | HTTP 200 | The conn. Matrix | HTTP 200 |
|<----------------------------------------| |<----------------------------------------|
| | | |
CNC POST the ACTN| POST /ACTN VN | CNC POST the | POST /VN |
VN identifying |---------------------------------------->| VN identifying |---------------------------------------->|
AP, VNAP and VN- | | AP, VNAP and VN- | |
Members and maps | | Members and maps | |
to the TE-topo | HTTP 200 | to the TE-topo | HTTP 200 |
|<----------------------------------------| |<----------------------------------------|
| | | |
| | | |
CNC GET the ACTN | GET /ACTN VN | CNC GET the | GET /VN |
VN YANG status |---------------------------------------->| VN YANG status |---------------------------------------->|
| | | |
| HTTP 200 (ACTN VN with status) | | HTTP 200 (VN with status) |
|<----------------------------------------| |<----------------------------------------|
| | | |
On the other hand, if MDSC create single node topology based ACTN VN On the other hand, if MDSC create single node topology based VN YANG
YANG posted by the CNC, the following diagram shows the message flow posted by the CNC, the following diagram shows the message flow
between CNC and MDSC to instantiate this VN using ACTN VN and TE- between CNC and MDSC to instantiate this VN using VN and TE-Topology
Topology Model. Models.
+--------+ +--------+ +--------+ +--------+
| CNC | | MDSC | | CNC | | MDSC |
+--------+ +--------+ +--------+ +--------+
| | | |
| | | |
CNC POST ACTN VN | | CNC POST VN | |
Identifying AP, | | Identifying AP, | |
VNAP and VN- | POST /ACTN VN | MDSC populates VNAP and VN- | POST /VN | MDSC populates
Members |---------------------------------------->| a single Abst. Members |---------------------------------------->| a single Abst.
| HTTP 200 | node topology | HTTP 200 | node topology
|<----------------------------------------| by itself |<----------------------------------------| by itself
| | | |
CNC POST the ACTN| POST /ACTN VN | CNC POST the | POST /VN |
VN identifying |---------------------------------------->| VN identifying |---------------------------------------->|
AP, VNAP and VN- | | AP, VNAP and VN- | |
Members and maps | | Members and maps | |
to the TE-topo | HTTP 200 | to the TE-topo | HTTP 200 |
|<----------------------------------------| |<----------------------------------------|
| | | |
| | | |
CNC GET the | GET /VN |
CNC GET the ACTN | GET /ACTN VN |
VN YANG status |---------------------------------------->| VN YANG status |---------------------------------------->|
| | | |
| HTTP 200 (ACTN VN with status) | | HTTP 200 (VN with status) |
|<----------------------------------------| |<----------------------------------------|
| | | |
4. ACTN VN Model Usage 4. VN Model Usage
4.1. Customer view of VN 4.1. Customer view of VN
The VN-Yang model allows to define a customer view, and allows the The VN-Yang model allows to define a customer view, and allows the
customer to communicate using the VN constructs as described in the customer to communicate using the VN constructs as described in the
[ACTN-INFO]. It also allows to group the set of edge-to-edge links [ACTN-INFO]. 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 ACTN VN yang model. In some other cases, the VN is not the VN yang model. In some other cases, the VN is not explicitly
explicitly configured, but created automatically by the MDSC based configured, but created automatically by the MDSC based on the
on the customer service model and local policy, even in these case customer service model and local policy, even in these case the VN
the ACTN VN yang model can be used by the CNC to learn details of yang model can be used by the CNC to learn details of the underlying
the underlying VN created to meet the requirements of customer VN created to meet the requirements of customer service model.
service model.
4.3. Innovative Services 4.3. Innovative Services
4.3.1. VN Compute 4.3.1. VN Compute
ACTN VN 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 both may not be pre-determined by the customer. For instance, for or both may not be pre-determined by the customer. For instance, for
a given source, there may be a list of multiple-destinations to a given source, there may be a list of multiple-destinations to
which the optimal destination may be chosen depending on the network which 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. In some cases, there may be a pool of multiple sources and chosen. 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. The following YANG module is shown for describing source chosen. The following YANG module is shown for describing source
container and destination container. The following YANG tree shows container and destination container. The following YANG tree shows
how to model multi-sources and multi-destinations. how to model multi-sources and multi-destinations.
+--rw actn
. . .
+--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? -> /nw:networks/network/node/tet:te-node-id +--rw abstract-node? -> /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? -> /actn/ap/access-point-list/access-point-id | | +--rw src? -> /ap/access-point-list/access-point-id
| | +--rw src-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id | | +--rw src-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? -> /actn/ap/access-point-list/access-point- | | +--rw dest? -> /ap/access-point-list/access-point-id
id | | +--rw dest-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id
| | +--rw dest-vn-ap-id? -> /actn/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? -> /nw:networks/network/node/tet:te/te- | +--rw connetivity-matrix-id? -> /nw:networks/network/node/tet:te/te-
node-attributes/connectivity-matrices/connectivity-matrix/id node-attributes/connectivity-matrices/connectivity-matrix/id
| +--ro oper-status? identityref | +--ro oper-status? identityref
+--ro if-selected? boolean {multi-src-dest}? +--ro if-selected? boolean {multi-src-dest}?
+--rw admin-status? identityref +--rw admin-status? identityref
+--ro oper-status? identityref +--ro oper-status? identityref
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 [TE-MAP].
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 [ACTN-PM].
4.3.4. Summary 4.3.4. Summary
This section summarizes the innovative service features of the ACTN This section summarizes the innovative service features of the VN
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 Abstract TE Topology Yang Model. the Abstract TE Topology Yang Model.
5. ACTN VN YANG Model (Tree Structure) 5. VN YANG Model (Tree Structure)
module: ietf-vn module: ietf-vn
+--rw actn +--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 max-bandwidth? te-types:te-bandwidth | +--rw avl-bandwidth? te-types:te-bandwidth
| +--rw avl-bandwidth? te-types:te-bandwidth | +--rw vn-ap* [vn-ap-id]
| +--rw vn-ap* [vn-ap-id] | +--rw vn-ap-id uint32
| +--rw vn-ap-id uint32 | +--rw vn? -> /vn/vn-list/vn-id
| +--rw vn? -> /actn/vn/vn-list/vn-id | +--rw abstract-node? -> /nw:networks/network/node/tet:te-node-id
| +--rw abstract-node? -> /nw:networks/network/node/tet:te-node-id | +--rw ltp? te-types:te-tp-id
| +--rw ltp? te-types:te-tp-id +--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? -> /nw:networks/network/node/tet:te-node-id
+--rw abstract-node? -> /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? -> /ap/access-point-list/access-point-id
| | +--rw src? -> /actn/ap/access-point-list/access-point-id | | +--rw src-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id
| | +--rw src-vn-ap-id? -> /actn/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? -> /ap/access-point-list/access-point-id
| | +--rw dest? -> /actn/ap/access-point-list/access-point-id | | +--rw dest-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id
| | +--rw dest-vn-ap-id? -> /actn/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? -> /nw:networks/network/node/tet:te/te-
| +--rw connetivity-matrix-id? -> /nw:networks/network/node/tet:te/te-node- node-attributes/connectivity-matrices/connectivity-matrix/id
attributes/connectivity-matrices/connectivity-matrix/id | +--ro oper-status? identityref
| +--ro oper-status? identityref +--ro if-selected? boolean {multi-src-dest}?
+--ro if-selected? boolean {multi-src-dest}? +--rw admin-status? identityref
+--rw admin-status? identityref +--ro oper-status? identityref
+--ro oper-status? identityref +--rw vn-level-diversity? vn-disjointness
+--rw vn-level-diversity? vn-disjointness
rpcs: rpcs:
+---x vn-compute +---x vn-compute
+---w input +---w input
| +---w abstract-node? -> /nw:networks/network/node/tet:te-node-id | +---w abstract-node? -> /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? -> /actn/ap/access-point-list/access-point-id | | | +---w src? -> /ap/access-point-list/access-point-id
| | | +---w src-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id | | | +---w src-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? -> /actn/ap/access-point-list/access-point-id | | | +---w dest? -> /ap/access-point-list/access-point-id
| | | +---w dest-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id | | | +---w dest-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 connetivity-matrix-id? -> /nw:networks/network/node/tet:te/te-node- | | +---w connetivity-matrix-id? ->
attributes/connectivity-matrices/connectivity-matrix/id /nw:networks/network/node/tet:te/te-node-attributes/connectivity-
matrices/connectivity-matrix/id
| +---w vn-level-diversity? vn-disjointness | +---w vn-level-diversity? vn-disjointness
+--ro output +--ro output
+--ro vn-member-list* [vn-member-id] +--ro vn-member-list* [vn-member-id]
+--ro vn-member-id uint32 +--ro vn-member-id uint32
+--ro src +--ro src
| +--ro src? -> /actn/ap/access-point-list/access-point-id | +--ro src? -> /ap/access-point-list/access-point-id
| +--ro src-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id | +--ro src-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id
| +--ro multi-src? boolean {multi-src-dest}? | +--ro multi-src? boolean {multi-src-dest}?
+--ro dest +--ro dest
| +--ro dest? -> /actn/ap/access-point-list/access-point-id | +--ro dest? -> /ap/access-point-list/access-point-id
| +--ro dest-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id | +--ro dest-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id
| +--ro multi-dest? boolean {multi-src-dest}? | +--ro multi-dest? boolean {multi-src-dest}?
+--ro connetivity-matrix-id? -> /nw:networks/network/node/tet:te/te-node- +--ro connetivity-matrix-id? ->
attributes/connectivity-matrices/connectivity-matrix/id /nw:networks/network/node/tet:te/te-node-attributes/connectivity-
matrices/connectivity-matrix/id
+--ro if-selected? boolean {multi-src-dest}? +--ro if-selected? boolean {multi-src-dest}?
+--ro compute-status? identityref +--ro compute-status? Identityref
6. ACTN-VN YANG Code 6. VN YANG Code
The YANG code is as follows: The YANG code is as follows:
<CODE BEGINS> file "ietf-vn@2018-12-30.yang" <CODE BEGINS> file "ietf-vn@2019-02-04.yang"
module ietf-vn {
namespace "urn:ietf:params:xml:ns:yang:ietf-vn";
prefix "vn";
/* Import network */
import ietf-network {
prefix "nw";
}
/* Import TE generic types */ module ietf-vn {
import ietf-te-types { namespace "urn:ietf:params:xml:ns:yang:ietf-vn";
prefix "te-types"; prefix "vn";
}
/* Import Abstract TE Topology */ /* Import network */
import ietf-te-topology { import ietf-network {
prefix "tet"; prefix "nw";
} }
organization /* Import TE generic types */
"IETF Traffic Engineering Architecture and Signaling (TEAS) import ietf-te-types {
Working Group"; prefix "te-types";
contact }
"Editor: Young Lee <leeyoung@huawei.com>
: Dhruv Dhody <dhruv.ietf@gmail.com>";
description
"This module contains a YANG module for the ACTN 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 2018-12-30 {
description
"initial version.";
reference
"TBD";
}
/*
* Features
*/
feature multi-src-dest {
description
"Support for selection of one src or destination
among multiple.";
}
/*identity path-metric-delay { /* Import Abstract TE Topology */
base te-types:path-metric-type; import ietf-te-topology {
description prefix "tet";
"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 { organization
"IETF Traffic Engineering Architecture and Signaling (TEAS)
Working Group";
contact
"Editor: Young Lee <leeyoung@huawei.com>
: Dhruv Dhody <dhruv.ietf@gmail.com>";
description description
"Base identity for VN state"; "This module contains a YANG module for the VN. It
} describes a VN operation module that takes place in the
identity vn-state-up { context of the CNC-MDSC Interface (CMI) of the ACTN
base vn-state-type; architecture where the CNC is the actor of a VN
description "VN state up"; Instantiation/modification /deletion.";
} revision 2019-02-04 {
identity vn-state-down { description
base vn-state-type; "initial version.";
description "VN state down"; reference
} "TBD";
identity vn-admin-state-type { }
description /*
"Base identity for VN admin states"; * Features
} */
identity vn-admin-state-up { feature multi-src-dest {
base vn-admin-state-type; description
description "VN administratively state up"; "Support for selection of one src or destination
} among multiple.";
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 { /*identity path-metric-delay {
type bits { base te-types:path-metric-type;
bit node {
position 0;
description "node disjoint";
}
bit link {
position 1;
description "link disjoint";
}
bit srlg {
position 2;
description "srlg disjoint";
}
}
description description
"type of the resource disjointness for "delay path metric";
VN level applied across all VN members
in a VN";
}
grouping vn-ap {
description
"VNAP related information";
leaf vn-ap-id {
type uint32;
description
"unique identifier for the referred
VNAP";
}
leaf vn {
type leafref {
path "/actn/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 te-types:te-tp-id;
description
"Reference LTP in the TE-topology";
}
}
grouping access-point{
description
"AP related information";
leaf access-point-id {
type uint32;
description
"unique identifier for the referred
access point";
} }
leaf access-point-name { identity path-metric-delay-variation {
type string; base te-types:path-metric-type;
description description
"ap name"; "delay-variation path metric";
} }
identity path-metric-loss {
base te-types:path-metric-type;
description
"loss path metric";
}*/
leaf max-bandwidth { identity vn-state-type {
type te-types:te-bandwidth; description
description "Base identity for VN state";
"max bandwidth of the AP";
} }
leaf avl-bandwidth { identity vn-state-up {
type te-types:te-bandwidth; base vn-state-type;
description description "VN state up";
"available bandwidth of the AP";
} }
/*add details and any other properties of AP, identity vn-state-down {
not associated by a VN base vn-state-type;
CE port, PE port etc. description "VN state down";
*/
list vn-ap {
key vn-ap-id;
uses vn-ap;
description
"list of VNAP in this AP";
} }
}//access-point identity vn-admin-state-type {
grouping vn-member {
description
"vn-member is described by this container";
leaf vn-member-id {
type uint32;
description description
"vn-member identifier"; "Base identity for VN admin states";
} }
container src identity vn-admin-state-up {
{ base vn-admin-state-type;
description description "VN administratively state up";
"the source of VN Member";
leaf src {
type leafref {
path "/actn/ap/access-point-list/access-point-id";
}
description
"reference to source AP";
}
leaf src-vn-ap-id{
type leafref {
path "/actn/ap/access-point-list/vn-ap/vn-ap-id";
}
description
"reference to source VNAP";
}
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 identity vn-admin-state-down {
{ base vn-admin-state-type;
description description "VN administratively state down";
"the destination of VN Member";
leaf dest {
type leafref {
path "/actn/ap/access-point-list/access-point-id";
}
description
"reference to destination AP";
}
leaf dest-vn-ap-id{
type leafref {
path "/actn/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 connetivity-matrix-id{ identity vn-compute-state-type {
type leafref {
path "/nw:networks/nw:network/nw:node/tet:te/"
+ "tet:te-node-attributes/"
+ "tet:connectivity-matrices/"
+ "tet:connectivity-matrix/tet:id";
}
description description
"reference to connetivity-matrix"; "Base identity for compute states";
} }
}//vn-member identity vn-compute-state-computing {
/* base vn-compute-state-type;
grouping policy {
description
"policy related to vn-member-id";
leaf local-reroute {
type boolean;
description description
"Policy to state if reroute "State path compute in progress";
can be done locally";
} }
leaf push-allowed { identity vn-compute-state-computation-ok {
type boolean; base vn-compute-state-type;
description description
"Policy to state if changes "State path compute successful";
can be pushed to the customer";
} }
leaf incremental-update { identity vn-compute-state-computatione-failed {
type boolean; base vn-compute-state-type;
description description
"Policy to allow only the "State path compute failed";
changes to be reported";
} }
}//policy /*
*/ * Groupings
grouping vn-policy { */
description
"policy for VN-level diverisity"; typedef vn-disjointness {
leaf vn-level-diversity { type bits {
type vn-disjointness; bit node {
description position 0;
"the type of disjointness on the VN level description "node disjoint";
(i.e., across all VN members)"; }
} bit link {
} position 1;
/* description "link disjoint";
grouping metrics-op {
description
"metric related information";
list metric{
key "metric-type";
config false;
description
"The list of metrics for VN";
leaf metric-type {
type identityref {
base te-types:path-metric-type;
}
description
"The VN metric type.";
}
leaf value{
type uint32;
description
"The limit value";
} }
} bit srlg {
} position 2;
*/ description "srlg disjoint";
/*
grouping metrics {
description
"metric related information";
list metric{
key "metric-type";
description
"The list of metrics for VN";
uses te:path-metrics-bounds_config;
container optimize{
description
"optimizing constraints";
leaf enabled{
type boolean;
description
"Metric to optimize";
}
leaf value{
type uint32;
description
"The computed value";
}
} }
}
}
*/
/*
grouping service-metric {
description
"service-metric";
uses te:path-objective-function_config;
uses metrics;
uses te-types:common-constraints_config;
uses te:protection-restoration-params_config;
uses policy;
}//service-metric
*/
/*
* Configuration data nodes
*/
container actn {
description
"actn is described by this container";
container ap {
description
"AP configurations";
list access-point-list {
key "access-point-id";
description
"access-point identifier";
uses access-point{
description
"access-point information";
}
} }
} description
container vn { "type of the resource disjointness for
description VN level applied across all VN members
"VN configurations"; in a VN";
list vn-list { }
key "vn-id";
description grouping vn-ap {
"a virtual network is identified by a vn-id"; description
leaf vn-id { "VNAP related information";
type uint32; leaf vn-ap-id {
description type uint32;
"a unique vn identifier"; description
} "unique identifier for the referred
leaf vn-name { VNAP";
type string; }
description "vn name"; leaf vn {
} type leafref {
leaf vn-topology-id{ path "/vn/vn-list/vn-id";
type te-types:te-topology-id; }
description description
"An optional identifier to the TE Topology "reference to the VN";
Model where the abstract nodes and links }
of the Topology can be found for Type 2 leaf abstract-node {
VNS"; type leafref {
}
leaf abstract-node {
type leafref {
path "/nw:networks/nw:network/nw:node/" path "/nw:networks/nw:network/nw:node/"
+ "tet:te-node-id"; + "tet:te-node-id";
} }
description description
"a reference to the abstract node in TE "a reference to the abstract node in TE
Topology"; Topology";
} }
list vn-member-list{ leaf ltp {
key "vn-member-id"; type te-types:te-tp-id;
description description
"List of VN-members in a VN"; "Reference LTP in the TE-topology";
uses vn-member; }
/*uses metrics-op;*/ }
leaf oper-status { grouping access-point{
type identityref { description
base vn-state-type; "AP related information";
} leaf access-point-id {
config false; type uint32;
description description
"VN-member operational state."; "unique identifier for the referred
access point";
}
leaf access-point-name {
type string;
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
grouping vn-member {
description
"vn-member is described by this container";
leaf vn-member-id {
type uint32;
description
"vn-member identifier";
}
container src
{
description
"the source of VN Member";
leaf src {
type leafref {
path "/ap/access-point-list/access-point-id";
}
description
"reference to source AP";
}
leaf src-vn-ap-id{
type leafref {
path "/ap/access-point-list/vn-ap/vn-ap-id";
}
description
"reference to source VNAP";
}
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
"the destination of VN Member";
leaf dest {
type leafref {
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 connetivity-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 connetivity-matrix";
}
}//vn-member
/*
grouping policy {
description
"policy related to vn-member-id";
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 {
description
"metric related information";
list metric{
key "metric-type";
config false;
description
"The list of metrics for VN";
leaf metric-type {
type identityref {
base te-types:path-metric-type;
}
description
"The VN metric type.";
}
leaf value{
type uint32;
description
"The limit value";
}
}
}
*/
/*
grouping metrics {
description
"metric related information";
list metric{
key "metric-type";
description
"The list of metrics for VN";
uses te:path-metrics-bounds_config;
container optimize{
description
"optimizing constraints";
leaf enabled{
type boolean;
description
"Metric to optimize";
} }
leaf value{
type uint32;
description
"The computed value";
}
}
}
}
*/
/*
grouping service-metric {
description
"service-metric";
uses te:path-objective-function_config;
uses metrics;
uses te-types:common-constraints_config;
uses te:protection-restoration-params_config;
uses policy;
}//service-metric
*/
/*
* Configuration data nodes
*/
} container ap {
leaf if-selected{ description
if-feature multi-src-dest; "AP configurations";
type boolean; list access-point-list {
default false; key "access-point-id";
config false; description
description "access-point identifier";
"Is the vn-member is selected among the uses access-point {
multi-src/dest options"; description
} "access-point information";
}
}
}
/* container vn {
container multi-src-dest{ description
if-feature multi-src-dest; "VN configurations";
config false; list vn-list {
description key "vn-id";
"The selected VN Member when multi-src description
and/or mult-destination is enabled."; "a virtual network is identified by a vn-id";
leaf selected-vn-member{ 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 { type leafref {
path "/actn/vn/vn-list/vn-member-list" path "/nw:networks/nw:network/nw:node/"
+ "/vn-member-id"; + "tet:te-node-id";
} }
description description
"The selected VN Member along the set "a reference to the abstract node in TE
of source and destination configured Topology";
with multi-source and/or multi-destination"; }
} list vn-member-list{
} key "vn-member-id";
*/ description
/*uses service-metric;*/ "List of VN-members in a VN";
leaf admin-status { uses vn-member;
type identityref { /*uses metrics-op;*/
base vn-admin-state-type; leaf oper-status {
} type identityref {
default vn-admin-state-up; base vn-state-type;
description "VN administrative state."; }
} config false;
leaf oper-status { description
type identityref { "VN-member operational state.";
base vn-state-type; }
}
config false; }
description "VN operational state."; leaf if-selected{
} if-feature multi-src-dest;
uses vn-policy; type boolean;
}//vn-list default false;
}//vn config false;
}//actn description
/* "Is the vn-member is selected among the
* Notifications - TBD multi-src/dest options";
*/ }
/* /*
* RPC container multi-src-dest{
*/ if-feature multi-src-dest;
rpc vn-compute{ config false;
description description
"The VN computation without actual "The selected VN Member when multi-src
instantiation"; and/or mult-destination is enabled.";
input { leaf selected-vn-member{
leaf abstract-node { type leafref {
type leafref { path "/vn/vn-list/vn-member-list"
path "/nw:networks/nw:network/nw:node/" + "/vn-member-id";
+ "tet:te-node-id"; }
} description
description "The selected VN Member along the set
"a reference to the abstract node in TE of source and destination configured
Topology"; with multi-source and/or multi-destination";
} }
list vn-member-list{ }
key "vn-member-id"; */
description /*uses service-metric;*/
"List of VN-members in a VN"; leaf admin-status {
uses vn-member; 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; uses vn-policy;
/*uses service-metric;*/ }//vn-list
} }//vn
output {
list vn-member-list{ /*
key "vn-member-id"; * Notifications - TBD
description */
"List of VN-members in a VN"; /*
uses vn-member; * RPC
leaf if-selected{ */
if-feature multi-src-dest; rpc vn-compute{
type boolean; description
default false; "The VN computation without actual
description instantiation";
"Is the vn-member is selected among input {
the multi-src/dest options"; leaf abstract-node {
} type leafref {
/*uses metrics-op;*/ path "/nw:networks/nw:network/nw:node/"
leaf compute-status { + "tet:te-node-id";
type identityref { }
base vn-compute-state-type; description
} "a reference to the abstract node in TE
description Topology";
"VN-member compute state."; }
} list vn-member-list{
} key "vn-member-id";
/* description
container multi-src-dest{ "List of VN-members in a VN";
if-feature multi-src-dest; uses vn-member;
description }
"The selected VN Member when multi-src uses vn-policy;
and/or mult-destination is enabled."; /*uses service-metric;*/
leaf selected-vn-member-id{ }
type uint32; output {
description list vn-member-list{
"The selected VN Member-id from the key "vn-member-id";
input"; description
} "List of VN-members in a VN";
}*/ uses vn-member;
} leaf if-selected{
} if-feature multi-src-dest;
} type boolean;
default false;
description
"Is the vn-member is selected among
the multi-src/dest options";
}
/*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";
}
}*/
}
}
}
<CODE ENDS> <CODE ENDS>
7. JSON Example 7. JSON Example
This section provides json implementation examples as to how ACTN VN This section provides json implementation examples as to how VN YANG
YANG model and TE topology model are used together to instantiate model and TE topology model are used together to instantiate virtual
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
skipping to change at page 28, line 16 skipping to change at page 28, line 22
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-src] and VN Member 204 (L2 to L4)/304 (L3 to L4) [multi- [multi-src] and VN Member 204 (L2 to L4)/304 (L3 to L4) [multi-
dest] usecase. The selected VN-member is known via the field "if- dest] 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 7.1. VN JSON
{ {
"actn":{
"ap":{ "ap":{
"access-point-list": [ "access-point-list": [
{ {
"access-point-id": 101, "access-point-id": 101,
"access-point-name": "101", "access-point-name": "101",
"vn-ap": [ "vn-ap": [
{ {
"vn-ap-id": 10101, "vn-ap-id": 10101,
"vn": 1, "vn": 1,
"abstract-node": "D1", "abstract-node": "D1",
 End of changes. 87 change blocks. 
642 lines changed or deleted 639 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/