--- 1/draft-ietf-teas-actn-vn-yang-03.txt 2019-02-04 11:13:14.209370685 -0800 +++ 2/draft-ietf-teas-actn-vn-yang-04.txt 2019-02-04 11:13:14.321373422 -0800 @@ -1,35 +1,34 @@ TEAS Working Group Y. Lee (Editor) Internet Draft Dhruv Dhody (Editor) Intended Status: Standard Track Huawei -Expires: June 30, 2019 D. Ceccarelli +Expires: August 3, 2019 D. Ceccarelli Ericsson Igor Bryskin Huawei Bin Yeong Yoon ETRI Qin Wu Huawei Peter Park 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 - This document provides a YANG data model for the Abstraction and - Control of Traffic Engineered (TE) networks (ACTN) Virtual Network - Service (VNS) operation. + This document provides a YANG data model generally applicable to any + mode of Virtual Network (VN) operation. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -37,96 +36,83 @@ 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 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 (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction...................................................3 + Introduction.....................................................3 + 1.................................................................3 1.1. Terminology...............................................4 1.2. Tree diagram..............................................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.2. Type 2 VN.................................................6 3. High-Level Control Flows with Examples.........................7 3.1. Type 1 VN Illustration....................................7 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.2. Auto-creation of VN by MDSC..............................11 4.3. Innovative Services......................................11 4.3.1. VN Compute..........................................11 4.3.2. Multi-sources and Multi-destinations................12 4.3.3. Others..............................................12 4.3.4. Summary.............................................13 - 5. ACTN VN YANG Model (Tree Structure)...........................13 - 6. ACTN-VN YANG Code.............................................15 + 5. VN YANG Model (Tree Structure)................................13 + 6. VN YANG Code..................................................15 7. JSON Example..................................................27 - 7.1. ACTN VN JSON.............................................28 + 7.1. VN JSON..................................................28 7.2. TE-topology JSON.........................................33 8. Security Considerations.......................................49 9. IANA Considerations...........................................51 10. Acknowledgments..............................................51 11. References...................................................52 11.1. Normative References....................................52 11.2. Informative References..................................52 12. Contributors.................................................53 Authors' Addresses...............................................53 1. Introduction - 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]. - - 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. + This document provides a YANG data model generally applicable to any + mode of Virtual Network (VN) operation. The VN model defined in this document is applicable in generic sense - outside of the ACTN context as an independent model in and of - itself. The VN model defined in this document can also work together - with other customer service models such as L3SM [RFC8299], L2SM - [L2SM] and L1CSM [L1CSM] to provide a complete life-cycle service - management and operations. + as an independent model in and of itself. The VN model defined in + this document can also work together with other customer service + models such as L3SM [RFC8299], L2SM [L2SM] and L1CSM [L1CSM] to + provide a complete life-cycle service management and operations. The YANG model discussed in this document basically provides the following: o Characteristics of Access Points (APs) that describe customer's end point characteristics; o Characteristics of Virtual Network Access Points (VNAP) that describe How an AP is partitioned for multiple VNs sharing the AP and its reference to a Link Termination Point (LTP) of the @@ -138,21 +124,38 @@ VN's reference to TE-topology's Abstract Node; The actual VN instantiation and computation is performed with Connectivity Matrices sub-module of TE-Topology Model [TE-Topo] which provides TE network topology abstraction and management operation. Once TE-topology Model is used in triggering VN instantiation over the networks, TE-tunnel [TE-tunnel] Model will inevitably interact with TE-Topology model for setting up actual 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 Architecture (NMDA) [RFC8342]. The origin of the data is indicated as per the origin metadata annotation. 1.1. Terminology Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used in this document. 1.2. Tree diagram @@ -174,23 +177,25 @@ | nw | ietf-network | [RFC8345] | | te-types| ietf-te-types | [TE-Tunnel] | | te-topo | ietf-te-topology | [TE-TOPO] | +---------+------------------------------+-----------------+ Table 1: Prefixes and corresponding YANG modules Note: The RFC Editor will replace XXXX with the number assigned to 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 | +-------+ | | VN YANG + TE-topology YANG | +-----------------------+ | MDSC | +-----------------------+ @@ -302,47 +307,47 @@ This VN can be modeled as one abstract node representation as follows: +---------------+ L1 ------| |------ L4 L2 ------| AN 1 |------ L7 L3 ------| |------ L8 +---------------+ If this VN is Type 1, the following diagram shows the message flow - between CNC and MDSC to instantiate this VN using ACTN VN and TE- - Topology Model. + between CNC and MDSC to instantiate this VN using VN and TE-Topology + Models. +--------+ +--------+ | CNC | | MDSC | +--------+ +--------+ | | | | CNC POST TE-topo | POST /nw:networks/nw:network/ | model(with Conn. | nw:node/te-node-id/tet:connectivity- | Matrix on one | matrices/tet:connectivity-matrix | Abstract node |---------------------------------------->| | HTTP 200 | |<----------------------------------------| | | - CNC POST the ACTN| POST /ACTN VN | + CNC POST the | POST /VN | VN identifying |---------------------------------------->| If there is AP, VNAP and VN- | | multi-dest'n Members and maps | | module, then to the TE-topo | HTTP 200 | MDSC selects a |<----------------------------------------| src or dest'n | | and update - | | ACTN VN YANG - CNC GET the ACTN | GET /ACTN VN | + | | VN YANG + CNC GET the | GET /VN | VN YANG status |---------------------------------------->| | | - | HTTP 200 (ACTN VN with status: selected| + | HTTP 200 (VN with status: selected | | VN-members in case of multi s-d | |<----------------------------------------| | | 3.2. Type 2 VN Illustration For some VN members, the customer may want to "configure" explicit routes over the path that connects its two end-points. Let us consider the following example. @@ -367,268 +373,264 @@ \ S6 \ S7 \ S8 O ----------------O---------O--------------L5 / \ / \ ____/ \_____________L6 S9 / \ /S10 \ / L2---------O-----O---------------------O---------------------L7 / S11\____________________L8 L3-------- If CNC creates the single abstract topology, the following diagram 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 POST TE-topo | POST /nw:networks/nw:network/ | model(with Conn. | nw:node/te-node-id/tet:connectivity- | Matrix on one | matrices/tet:connectivity-matrix | Abstract node and|---------------------------------------->| Explicit paths in| | The conn. Matrix | HTTP 200 | |<----------------------------------------| | | - CNC POST the ACTN| POST /ACTN VN | + CNC POST the | POST /VN | VN identifying |---------------------------------------->| AP, VNAP and VN- | | Members and maps | | to the TE-topo | HTTP 200 | |<----------------------------------------| | | | | - CNC GET the ACTN | GET /ACTN VN | + CNC GET the | GET /VN | 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 - YANG posted by the CNC, the following diagram shows the message flow - between CNC and MDSC to instantiate this VN using ACTN VN and TE- - Topology Model. + On the other hand, if MDSC create single node topology based VN YANG + posted by the CNC, the following diagram shows the message flow + between CNC and MDSC to instantiate this VN using VN and TE-Topology + Models. +--------+ +--------+ | CNC | | MDSC | +--------+ +--------+ | | | | - CNC POST ACTN VN | | + CNC POST VN | | Identifying AP, | | - VNAP and VN- | POST /ACTN VN | MDSC populates + VNAP and VN- | POST /VN | MDSC populates Members |---------------------------------------->| a single Abst. | HTTP 200 | node topology |<----------------------------------------| by itself | | - CNC POST the ACTN| POST /ACTN VN | + CNC POST the | POST /VN | VN identifying |---------------------------------------->| AP, VNAP and VN- | | Members and maps | | to the TE-topo | HTTP 200 | |<----------------------------------------| | | | | - - CNC GET the ACTN | GET /ACTN VN | + CNC GET the | GET /VN | 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 The VN-Yang model allows to define a customer view, and allows 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 (i.e., VN members) under a common umbrella of VN. This allows the customer to instantiate and view the VN as one entity, making it easier for some customers to work on VN without worrying about the details of the provider based YANG models. This is similar to the benefits of having a separate YANG model for the customer services as described in [RFC8309], which states that service models do not make any assumption of how a service is actually engineered and delivered for a customer. 4.2. Auto-creation of VN by MDSC 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 - explicitly configured, but created automatically by the MDSC based - on the customer service model and local policy, even in these case - the ACTN VN yang model can be used by the CNC to learn details of - the underlying VN created to meet the requirements of customer - service model. + the VN yang model. In some other cases, the VN is not explicitly + configured, but created automatically by the MDSC based on the + customer service model and local policy, even in these case the VN + yang model can be used by the CNC to learn details of the underlying + VN created to meet the requirements of customer service model. 4.3. Innovative Services 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 path computation or "compute only" tunnel setup does not provide the same functionality. 4.3.2. Multi-sources and Multi-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 a given source, there may be a list of multiple-destinations to which the optimal destination may be chosen depending on the network resource situations. Likewise, for a given destination, there may also be multiple-sources from which the optimal source may be chosen. In some cases, there may be a pool of multiple sources and destinations from which the optimal source-destination may be chosen. The following YANG module is shown for describing source container and destination container. The following YANG tree shows how to model multi-sources and multi-destinations. -+--rw actn - . . . +--rw vn +--rw vn-list* [vn-id] +--rw vn-id uint32 +--rw vn-name? string +--rw vn-topology-id? te-types:te-topology-id +--rw abstract-node? -> /nw:networks/network/node/tet:te-node-id +--rw vn-member-list* [vn-member-id] | +--rw vn-member-id uint32 | +--rw src - | | +--rw src? -> /actn/ap/access-point-list/access-point-id - | | +--rw src-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id + | | +--rw src? -> /ap/access-point-list/access-point-id + | | +--rw src-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id | | +--rw multi-src? boolean {multi-src-dest}? | +--rw dest - | | +--rw dest? -> /actn/ap/access-point-list/access-point- -id - | | +--rw dest-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id + | | +--rw dest? -> /ap/access-point-list/access-point-id + | | +--rw dest-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id | | +--rw multi-dest? boolean {multi-src-dest}? | +--rw connetivity-matrix-id? -> /nw:networks/network/node/tet:te/te- node-attributes/connectivity-matrices/connectivity-matrix/id | +--ro oper-status? identityref +--ro if-selected? boolean {multi-src-dest}? +--rw admin-status? identityref +--ro oper-status? identityref 4.3.3. Others 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]. The VN Yang model can be extended to support telemetry, performance monitoring and network autonomics as described in [ACTN-PM]. 4.3.4. Summary - This section summarizes the innovative service features of the ACTN - VN Yang. + This section summarizes the innovative service features of the VN + Yang. o Maintenance of AP and VNAP along with VN. o VN construct to group of edge-to-edge links o VN Compute (pre-instantiate) o Multi-Source / Multi-Destination o Ability to support various VN and VNS Types * VN Type 1: Customer configures the VN as a set of VN Members. No other details need to be set by customer, making for a simplified operations for the customer. * VN Type 2: Along with VN Members, the customer could also provide an abstract topology, this topology is provided by the Abstract TE Topology Yang Model. -5. ACTN VN YANG Model (Tree Structure) +5. VN YANG Model (Tree Structure) module: ietf-vn - +--rw actn +--rw ap | +--rw access-point-list* [access-point-id] | +--rw access-point-id uint32 | +--rw access-point-name? string | +--rw max-bandwidth? te-types:te-bandwidth | +--rw avl-bandwidth? te-types:te-bandwidth | +--rw vn-ap* [vn-ap-id] | +--rw vn-ap-id uint32 - | +--rw vn? -> /actn/vn/vn-list/vn-id + | +--rw vn? -> /vn/vn-list/vn-id | +--rw abstract-node? -> /nw:networks/network/node/tet:te-node-id | +--rw ltp? te-types:te-tp-id +--rw vn +--rw vn-list* [vn-id] +--rw vn-id uint32 +--rw vn-name? string +--rw vn-topology-id? te-types:te-topology-id +--rw abstract-node? -> /nw:networks/network/node/tet:te-node-id +--rw vn-member-list* [vn-member-id] | +--rw vn-member-id uint32 | +--rw src - | | +--rw src? -> /actn/ap/access-point-list/access-point-id - | | +--rw src-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id + | | +--rw src? -> /ap/access-point-list/access-point-id + | | +--rw src-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id | | +--rw multi-src? boolean {multi-src-dest}? | +--rw dest - | | +--rw dest? -> /actn/ap/access-point-list/access-point-id - | | +--rw dest-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id + | | +--rw dest? -> /ap/access-point-list/access-point-id + | | +--rw dest-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id | | +--rw multi-dest? boolean {multi-src-dest}? - | +--rw connetivity-matrix-id? -> /nw:networks/network/node/tet:te/te-node- - attributes/connectivity-matrices/connectivity-matrix/id + | +--rw connetivity-matrix-id? -> /nw:networks/network/node/tet:te/te- + node-attributes/connectivity-matrices/connectivity-matrix/id | +--ro oper-status? identityref +--ro if-selected? boolean {multi-src-dest}? +--rw admin-status? identityref +--ro oper-status? identityref +--rw vn-level-diversity? vn-disjointness rpcs: +---x vn-compute +---w input | +---w abstract-node? -> /nw:networks/network/node/tet:te-node-id | +---w vn-member-list* [vn-member-id] | | +---w vn-member-id uint32 | | +---w src - | | | +---w src? -> /actn/ap/access-point-list/access-point-id - | | | +---w src-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id + | | | +---w src? -> /ap/access-point-list/access-point-id + | | | +---w src-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id | | | +---w multi-src? boolean {multi-src-dest}? | | +---w dest - | | | +---w dest? -> /actn/ap/access-point-list/access-point-id - | | | +---w dest-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id + | | | +---w dest? -> /ap/access-point-list/access-point-id + | | | +---w dest-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id | | | +---w multi-dest? boolean {multi-src-dest}? - | | +---w connetivity-matrix-id? -> /nw:networks/network/node/tet:te/te-node- - attributes/connectivity-matrices/connectivity-matrix/id + | | +---w connetivity-matrix-id? -> + /nw:networks/network/node/tet:te/te-node-attributes/connectivity- + matrices/connectivity-matrix/id | +---w vn-level-diversity? vn-disjointness +--ro output +--ro vn-member-list* [vn-member-id] +--ro vn-member-id uint32 +--ro src - | +--ro src? -> /actn/ap/access-point-list/access-point-id - | +--ro src-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id + | +--ro src? -> /ap/access-point-list/access-point-id + | +--ro src-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id | +--ro multi-src? boolean {multi-src-dest}? +--ro dest - | +--ro dest? -> /actn/ap/access-point-list/access-point-id - | +--ro dest-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id + | +--ro dest? -> /ap/access-point-list/access-point-id + | +--ro dest-vn-ap-id? -> /ap/access-point-list/vn-ap/vn-ap-id | +--ro multi-dest? boolean {multi-src-dest}? - +--ro connetivity-matrix-id? -> /nw:networks/network/node/tet:te/te-node- - attributes/connectivity-matrices/connectivity-matrix/id + +--ro connetivity-matrix-id? -> + /nw:networks/network/node/tet:te/te-node-attributes/connectivity- + matrices/connectivity-matrix/id +--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: - file "ietf-vn@2018-12-30.yang" + 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"; } @@ -642,26 +644,26 @@ prefix "tet"; } organization "IETF Traffic Engineering Architecture and Signaling (TEAS) Working Group"; contact "Editor: Young Lee : Dhruv Dhody "; description - "This module contains a YANG module for the ACTN VN. It + "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 2018-12-30 { + revision 2019-02-04 { description "initial version."; reference "TBD"; } /* * Features */ feature multi-src-dest { description @@ -757,21 +759,21 @@ 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"; + 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 @@ -827,55 +829,54 @@ type uint32; description "vn-member identifier"; } container src { description "the source of VN Member"; leaf src { type leafref { - path "/actn/ap/access-point-list/access-point-id"; + path "/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"; + 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 "/actn/ap/access-point-list/access-point-id"; + path "/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"; + 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"; @@ -984,23 +985,21 @@ 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"; @@ -1058,31 +1058,30 @@ } 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 "/actn/vn/vn-list/vn-member-list" + 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;*/ @@ -1096,21 +1095,21 @@ leaf oper-status { type identityref { base vn-state-type; } config false; description "VN operational state."; } uses vn-policy; }//vn-list }//vn - }//actn + /* * Notifications - TBD */ /* * RPC */ rpc vn-compute{ description "The VN computation without actual instantiation"; @@ -1170,23 +1169,23 @@ } }*/ } } } 7. JSON Example - This section provides json implementation examples as to how ACTN VN - YANG model and TE topology model are used together to instantiate - virtual networks. + This section provides json implementation examples as to how VN YANG + model and TE topology model are used together to instantiate virtual + networks. The example in this section includes following VN 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 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 example on the global level (i.e., connectivity matrices level). o VN2 (Type 2): Which maps to the single node topology abstract2 @@ -1199,21 +1198,20 @@ 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- dest] usecase. The selected VN-member is known via the field "if- selected" and the corresponding connectivity-matrix-id. Note that the VN YANG model also include the AP and VNAP which shows various VN using the same AP. 7.1. VN JSON { - "actn":{ "ap":{ "access-point-list": [ { "access-point-id": 101, "access-point-name": "101", "vn-ap": [ { "vn-ap-id": 10101, "vn": 1, "abstract-node": "D1",