TEAS Working Group Y. Lee (Editor) Internet Draft Dhruv Dhody Intended Status: Standard Track Huawei Expires: April 23, 2018 D. Ceccarelli Ericsson Takuya Miyasaka KDDI Peter Park KT Bin Yeung Yoon ETRI October 23, 2017 A Yang Data Model for ACTN VN Operation draft-lee-teas-actn-vn-yang-07 Abstract This document provides a YANG data model for the Abstraction and Control of Traffic Engineered (TE) networks (ACTN) Virtual Network Service (VNS) 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. 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 April 23, 2018. Lee, et al. Expires April 23, 2018 [Page 1] Internet-Draft ACTN VN YANG Model October 2017 Copyright Notice Copyright (c) 2017 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...................................................2 1.1. Terminology...............................................3 2. ACTN CMI context...............................................4 2.1. Type 1 VNS................................................5 2.2. Type 2 VNS................................................8 2.3. Justification of the ACTN VN Model on the CMI............10 3. ACTN VN YANG Model (Tree Structure)...........................12 4. ACTN-VN YANG Code.............................................15 5. Security Considerations.......................................27 6. IANA Considerations...........................................27 7. Acknowledgments...............................................27 8. References....................................................28 8.1. Normative References.....................................28 8.2. Informative References...................................28 9. Contributors..................................................29 Authors' Addresses...............................................29 1. Introduction 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). Lee, et al. Expires April 23, 2018 [Page 2] Internet-Draft ACTN VN YANG Model October 2017 The YANG model on the CMI is also known as customer service model in [Service-YANG]. The YANG model discussed in this document is used to operate customer-driven VNs during the VN computation, VN instantiation and its life-cycle management and operations. Note that the YANG model presented in this draft has two aspects: - VN pre-instantiation mode of operation (also known as VN compute); - VN instantiation mode of operation. The VN pre-instantiation mode of operation is concerned about service inquiry before making a formal request for VN instantiation. This operation is important for a customer to make sure the network can provide VN services it desires. The VN instantiation mode of operation is concerned about instantiating VNs. In the VN instantiation mode, the CNC provides the VN service definition that includes VN members, VN service objective, VN service policy and preferences, etc. Upon receipt of a VN instantiation request, the MDSC (in coordination with PNCs) executes service request into network operation that include creating tunnels/paths and securing network resources/slices for VNs. The YANG model discussed in this document basically provides the characteristics of VNs such as VN level parameters (e.g., VN ID, VN member, VN objective function, VN service preference, etc.), customer's end point characteristics (e.g., Customer Interface Capability, Access Points Interface characteristics, etc.), and other relevant VN information that needs to be known to the MDSC to facilitate ACTN VN operation. This is as per the ACTN Information Model described in [ACTN-INFO]. The ACTN VN operational state is included in the same tree as the configuration consistent with Network Management Datastore Architecture (NMDA) [NMDA]. The origin of the data is indicated as per the origin metadata annotation. 1.1. Terminology Refer to [ACTN-Frame] and [RFC7926] for the key terms used in this document. Lee, et al. Expires April 23, 2018 [Page 3] Internet-Draft ACTN VN YANG Model October 2017 2. ACTN CMI context The model presented in this document has the following ACTN context. +-------+ | CNC | +-------+ | | <--- CMI (CNC-MDSC Interface) | +-----------------------+ | MDSC | +-----------------------+ Figure 1. ACTN CMI As defined in [ACTN-FW], a Virtual Network is a customer view of the TE network. To recapitulate VN types from [ACTN-FW], there are two views of a VN as follows: a) The VN can be seen as a set of edge-to-edge links (a Type 1 VN). Each link is referred as a VN member and is formed as an end-to-end tunnel across the underlying networks. Such tunnels may be constructed by recursive slicing or abstraction of paths in the underlying networks and can encompass edge points of the customer's network, access links, intra-domain paths, and inter-domain links. b) The VN can also be seen as a topology of virtual nodes and virtual links (a Type 2 VN). The provider needs to map the VN to actual resource assignment, which is known as virtual network embedding. The nodes in this case include physical end points, border nodes, and internal nodes as well as abstracted nodes. Similarly the links include physical access links, inter-domain links, and intra-domain links as well as abstract links. It [ACTN-FW] further defines a Virtual Network Service (VNS) as follows: Lee, et al. Expires April 23, 2018 [Page 4] Internet-Draft ACTN VN YANG Model October 2017 A Virtual Network Service (VNS) is the service agreement between a customer and provider to provide a VN. There are three types of VNS defined in this document. o Type 1 VNS refers to a VNS in which the customer is allowed to create and operate a Type 1 VN. o Type 2a and 2b VNS refer to VNSs in which the customer is allowed to create and operates a Type 2 VN. With a Type 2a VNS, the VN is statically created at service configuration time and the customer is not allowed to change the topology (e.g., by adding or deleting abstract nodes and links). A Type 2b VNS is the same as a Type 2a VNS except that the customer is allowed to make dynamic changes to the initial topology created at service configuration time. Note that the VNS definition and its types are based on and consistent with OIF Virtual Transport Network Service (VTNS) [OIF- VTNS]. VNS Type 1, 2a and 2b correspond to OIF VTNS Type A, B and C, respectively. 2.1. Type 1 VNS This section considers a Type 1 VNS, where the customer provides its VN requirements in terms of VN members and VNAP. Figure 2 describes a VN that comprises three VN members forming a full mesh for the VN as an illustration. Lee, et al. Expires April 23, 2018 [Page 5] Internet-Draft ACTN VN YANG Model October 2017 VN Member 1 |<-------------------------------------->| | | | ------------- | | ( ) | | - - | +---+ X ( Provider ) Z +---+ |CE1|---+----( )---+---|CE2| +---+ AP1 ( Network ) AP2 +---+ .- - - _ -. |\ ( ) /| \ ------------- / \ | / ---- + AP3 ---- VN Member 2 \ | / VN Member 3 \ Y | / \ +---+ / `----> |CE3|<----` +---+ Figure 2. Full Mesh Example for a VN In Figure 2, a VN has three members, namely, VN Member 1, VN member 2, and VN member 3. VN Member 1 is an edge-to-edge link identified by CE1-AP1 (source) and CE2-AP2 (destination). Similarly, VN Member 2 by CE1-AP1 and CE3-AP3 and VN Member 3 by CE3-AP3 and CE2-AP2. This particular VN shown in Figure 2 is a full mesh connectivity across these three customer end-points. [ACTN-FW] defines the Access Point (AP) is a logical identifier shared between the customer and the provider used to identify an access link. The AP is used by the customer when requesting a VNS, and VN Access Point (VNAP) is defined as a binding between an AP and a given VN. Lee, et al. Expires April 23, 2018 [Page 6] Internet-Draft ACTN VN YANG Model October 2017 The set of assumptions that applies to this document is the following: - CNC is responsible for providing necessary Customer End-Points information to the MDSC via the CMI. - The access links (between Customer Edge (CE) Devices and the Provider Edge (PE) Devices) are assumed to have been provisioned prior to the VN instantiation request. Access point identifiers have been configured and therefore are known in both the CNC and the MDSC. This YANG model maintains the list of AP and VNAP. It is also possible for the customer to create a VN which can be a hub and spoke or any other form of connectivity depending on its connectivity requirement. Each VN-member may be unidirectional or bidirectional which is also depending on its connectivity requirements. The following figure shows some examples of a VN that can be represented in a different connectivity form depending on the customer's connectivity requirements. +---+ +---+ +---+ +---+ +---+ +---+ |CE1|---------|CE2| |CE4|---------|CE5| |CE8|---------|CE9| +---+ +---+ +---+ +---+ +---+ +---+ \ / | \ | \ | \ / | \ | \ | \ / | \ | \ | \ / | \ | \ | \ / | \ | \ | \ / | \ | \ | +---+ +---+ +---+ +---+ +---+ |CE3| |CE6| |CE7| |CE6|---------|CE7| +---+ +---+ +---+ +---+ +---+ (a) Full Mesh (b) Hub and Spoke (c) partial Mesh Figure 3. Different Connectivity Forms of a VN It is important to note that a VN can associate a multiple number of edge-to-edge links (i.e., VN members) with one unique identifier under the VN umbrella. From a customer standpoint, this simplifies its VN operation significantly. Lee, et al. Expires April 23, 2018 [Page 7] Internet-Draft ACTN VN YANG Model October 2017 The MDSC interacts with the CNC for the VN operation. Once the customer VN is requested by the CNC to the MDSC, the MDSC shall be responsible for translating and mapping the VN request into specific network centric-models (e.g., TE-tunnels [TE-Tunnel], TE-topology [TE-TOPO], etc.) to coordinate the multi-domain network operations with Provisioning Network Controllers (PNCs). 2.2. Type 2 VNS A type 2 VNS would allow the customer to also configure and learn a VN abstract topology (Type 2 VN) via the TE topology yang model [TE- TOPO]. A reference to the abstract topology is maintain in the VN Yang model. Any change in topology (Type 2b VN) would be made via [TE-TOPO]. Further, the ACTN VN Yang model is used for Type 2 VNS in exactly the same way by configuring the VN members and corresponding VNAP as described in section 2.1. Using the path in VN-member in the ACTN VN yang model, CNC can also set a path based on the abstract topology in [TE-TOPO]. Figure 4 shows an example VN abstract topology with six virtual nodes and six virtual links configured and learned from via [TE-TOPO]. For each VN member, the customer configures the path over the VN abstract topology. For instance, for VN-member 1 (that connects CE1 to CE2), the customer may choose a path comprising VL12 or alternatively a path comprising of VL13-VL36-VL26 depending on the virtual link state of the topology. If VN-member 1 needs to configure a link- diversity path from VN-member 2 (CE1-CE3), then VN-member 1 should configure a path comprising VL12 while VN-member 2 should configure a path comprising VL13-VL34 to avoid the links that overlap. Lee, et al. Expires April 23, 2018 [Page 8] Internet-Draft ACTN VN YANG Model October 2017 |<----------------VN-member 1----------------->| +------+ VL12 +------+ --- CE1------|VNode1|----------------|VNode2|------CE2 --- /|\ +------+ +------+ /|\ | \ / | | VL13 \ / VL26 | | +------+ VL36 +------+ | VN-member 2 |VNode3|--------|VNode6| | | +------+ +------+ | | VL34 / \ VL56 | | / \ | \|/ +------+ +------+ . --- CE3------|VNode4|--------------|VNode5| / +------+ VL45 +------+ / / / |<------------------VN-member 3-----------------' Figure 4. Type 2 VNS with VN abstract topology The following YANG tree segment shows how YANG is modeled to support Type VNS where for each VN-member how a path can be configured. +--rw vn +--rw vn-list* [vn-id] +--rw vn-id uint32 +--rw vn-name? string +--rw vn-topology-id? te-types:te-topology-id | {type-2}? +--rw vn-member-list* [vn-member-id] | +--rw vn-member-id uint32 | +--rw src | | +--rw src? leafref | | +--rw src-vn-ap-id? leafref | | +--rw multi-src? boolean | | {multi-src-dest}? | +--rw dest | | +--rw dest? leafref | | +--rw dest-vn-ap-id? leafref | | +--rw multi-dest? boolean | | {multi-src-dest}? | +--rw path {type-2}? | | +--rw path-element* [path-element-id] | | +--rw path-element-id uint32 | | +--rw index? uint32 | | +--rw address? te-types:te-tp-id Lee, et al. Expires April 23, 2018 [Page 9] Internet-Draft ACTN VN YANG Model October 2017 | | +--rw hop-type? te-types:te-hop-type 2.3. Justification of the ACTN VN Model on the CMI. 2.3.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. Further, there are certain advantages to maintain a set of E2E Tunnels as one VN unit for applying policy, reroute, protection, restoration, etc., rather than treating each TE-tunnel as individual unit. This allows customer to set one VN to be disjoint to another as a whole, allows the optimization functions to be applied to the VN rather than to an individual tunnels. This is similar to the benefits of having a separate YANG model for the customer services as described in [SERVICE-YANG], which states that service models do not make any assumption of how a service is actually engineered and delivered for a customer; details of how network protocols and devices are engineered to deliver a service are captured in other models that are not exposed through the Customer-Provider Interface. Ability to hide the complexity of the TE topology and TE tunnel YANG from some customers would be beneficial. 2.3.2 Innovative Services 2.3.2.1 VN Compute ACTN VN 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. 2.3.2.2 Multi-sources and Multi-destinations Lee, et al. Expires April 23, 2018 [Page 10] Internet-Draft ACTN VN YANG Model October 2017 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 src | | | +--rw src? leafref | | | +--rw src-vn-ap-id? uint32 | | | +--rw multi-src? boolean | | +--rw dest | | +--rw dest? leafref | | +--rw dest-vn-ap-id? uint32 | | +--rw multi-dest? boolean 2.3.2.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]. 2.3.3 Summary This section summarizes the innovative service features of the ACTN VN Yang. o Maintenance of AP and VNAP along with VN. o VN construct to group of edge-to-edge links Lee, et al. Expires April 23, 2018 [Page 11] Internet-Draft ACTN VN YANG Model October 2017 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. 3. ACTN VN YANG Model (Tree Structure) module: ietf-actn-vn +--rw actn +--rw ap | +--rw access-point-list* [access-point-id] | +--rw access-point-id uint32 | +--rw access-point-name? string | +--rw src-tp-id? binary | +--rw dst-tp-id? binary | +--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 +--rw vn-list* [vn-id] +--rw vn-id uint32 +--rw vn-name? string +--rw vn-topology-id? te-types:te-topology-id Lee, et al. Expires April 23, 2018 [Page 12] Internet-Draft ACTN VN YANG Model October 2017 | {type-2}? +--rw vn-member-list* [vn-member-id] | +--rw vn-member-id uint32 | +--rw src | | +--rw src? leafref | | +--rw src-vn-ap-id? leafref | | +--rw multi-src? boolean | | {multi-src-dest}? | +--rw dest | | +--rw dest? leafref | | +--rw dest-vn-ap-id? leafref | | +--rw multi-dest? boolean | | {multi-src-dest}? | +--rw path {type-2}? | | +--rw path-element* [path-element-id] | | +--rw path-element-id uint32 | | +--rw index? uint32 | | +--rw address? te-types:te-tp-id | | +--rw hop-type? te-types:te-hop-type | +--ro metric* [metric-type] | | +--ro metric-type identityref | | +--ro value? uint32 | +--ro oper-status? identityref | +--ro tunnel-ref? te:tunnel-ref +--ro multi-src-dest {multi-src-dest}? | +--ro selected-vn-member? leafref +--rw objective-function? pcep:objective-function +--rw metric* [metric-type] | +--rw metric-type identityref | +--rw limit | | +--rw enabled? boolean | | +--rw value? uint32 | +--rw optimize | +--rw enabled? boolean | +--rw value? uint32 +--rw bandwidth? te-types:te-bandwidth +--rw protection? identityref +--rw local-reroute? boolean +--rw push-allowed? boolean +--rw incremental-update? boolean +--rw admin-status? identityref +--ro oper-status? identityref rpcs: +---x vn-compute +---w input | +---w vn-member-list* [vn-member-id] | | +---w vn-member-id uint32 | | +---w src Lee, et al. Expires April 23, 2018 [Page 13] Internet-Draft ACTN VN YANG Model October 2017 | | | +---w src? leafref | | | +---w src-vn-ap-id? leafref | | | +---w multi-src? boolean {multi-src-dest}? | | +---w dest | | | +---w dest? leafref | | | +---w dest-vn-ap-id? leafref | | | +---w multi-dest? boolean | | | {multi-src-dest}? | | +---w path {type-2}? | | +---w path-element* [path-element-id] | | +---w path-element-id uint32 | | +---w index? uint32 | | +---w address? te-types:te-tp-id | | +---w hop-type? te-types:te-hop-type | +---w objective-function? pcep:objective-function | +---w metric* [metric-type] | | +---w metric-type identityref | | +---w limit | | | +---w enabled? boolean | | | +---w value? uint32 | | +---w optimize | | +---w enabled? boolean | | +---w value? uint32 | +---w bandwidth? te-types:te-bandwidth | +---w protection? identityref | +---w local-reroute? boolean | +---w push-allowed? boolean | +---w incremental-update? boolean +--ro output +--ro vn-member-list* [vn-member-id] | +--ro vn-member-id uint32 | +--ro src | | +--ro src? leafref | | +--ro src-vn-ap-id? leafref | | +--ro multi-src? boolean {multi-src-dest}? | +--ro dest | | +--ro dest? leafref | | +--ro dest-vn-ap-id? leafref | | +--ro multi-dest? boolean | | {multi-src-dest}? | +--ro path {type-2}? | | +--ro path-element* [path-element-id] | | +--ro path-element-id uint32 | | +--ro index? uint32 | | +--ro address? te-types:te-tp-id | | +--ro hop-type? te-types:te-hop-type | +--ro metric* [metric-type] | | +--ro metric-type identityref | | +--ro value? uint32 Lee, et al. Expires April 23, 2018 [Page 14] Internet-Draft ACTN VN YANG Model October 2017 | +--ro compute-status? identityref +--ro multi-src-dest {multi-src-dest}? +--ro selected-vn-member-id? uint32 4. ACTN-VN YANG Code The YANG code is as follows: file "ietf-actn-vn@2017-10-23.yang" module ietf-actn-vn { namespace "urn:ietf:params:xml:ns:yang:ietf-actn-vn"; prefix "vn"; /* Import TE generic types */ import ietf-te-types { prefix "te-types"; } import ietf-te { prefix "te"; } import ietf-pcep { prefix "pcep"; } 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 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."; Lee, et al. Expires April 23, 2018 [Page 15] Internet-Draft ACTN VN YANG Model October 2017 revision 2017-10-23 { description "initial version."; reference "TBD"; } /* * Features */ feature multi-src-dest { description "Support for selection of one src or destination among multiple."; } feature type-2 { description "Support for Type 2 VNS based on the abstract VN Topology."; } identity path-metric-delay { 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"; Lee, et al. Expires April 23, 2018 [Page 16] Internet-Draft ACTN VN YANG Model October 2017 } 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 */ grouping vn-ap { Lee, et al. Expires April 23, 2018 [Page 17] Internet-Draft ACTN VN YANG Model October 2017 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"; } } 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 { type string; description "ap name"; } /*using direct tp-id for now as per ietf-te should check if reference is better*/ leaf src-tp-id { type binary; description "TE tunnel source termination point identifier."; } leaf dst-tp-id { type binary; description "TE tunnel destination termination point identifier."; } leaf max-bandwidth { type te-types:te-bandwidth; description "max bandwidth of the AP"; } leaf avl-bandwidth { Lee, et al. Expires April 23, 2018 [Page 18] Internet-Draft ACTN VN YANG Model October 2017 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 "/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 Lee, et al. Expires April 23, 2018 [Page 19] Internet-Draft ACTN VN YANG Model October 2017 "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"; } 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"; } } container path { if-feature type-2; description "the path if set by the customer"; list path-element { key "path-element-id"; description "A list of path elements describing the service path."; leaf path-element-id { type uint32; description "To identify the element in a path."; } leaf index { type uint32; description "ERO subobject index"; } leaf address { type te-types:te-tp-id; Lee, et al. Expires April 23, 2018 [Page 20] Internet-Draft ACTN VN YANG Model October 2017 description "Numbered link TE termination point address. Should refer to the abstract TE topology of this VN"; } leaf hop-type { type te-types:te-hop-type; description "strict or loose hop"; } } } }//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 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; } Lee, et al. Expires April 23, 2018 [Page 21] Internet-Draft ACTN VN YANG Model October 2017 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"; leaf metric-type { type identityref { base te-types:path-metric-type; } description "The VN metric type."; } container limit { description "Limiting contraints"; leaf enabled{ type boolean; description "Limit contraint is enabled"; } leaf value{ type uint32; description "The limit value"; } } container optimize{ description "optimizing constraints"; leaf enabled{ type boolean; description "Metric to optimize"; } leaf value{ Lee, et al. Expires April 23, 2018 [Page 22] Internet-Draft ACTN VN YANG Model October 2017 type uint32; description "The computed value"; } } } } grouping service-metric { description "service-metric"; leaf objective-function { type pcep:objective-function; description "operational state of the objective function"; } uses metrics; leaf bandwidth { type te-types:te-bandwidth; description "bandwidth requested/required for vn-member-id"; } leaf protection { type identityref { base te-types:lsp-prot-type; } description "protection type."; } 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"; Lee, et al. Expires April 23, 2018 [Page 23] Internet-Draft ACTN VN YANG Model October 2017 description "access-point identifier"; uses access-point{ description "access-point information"; } } } 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 "a unique vn identifier"; } leaf vn-name { type string; description "vn name"; } leaf vn-topology-id{ if-feature type-2; 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"; } 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."; Lee, et al. Expires April 23, 2018 [Page 24] Internet-Draft ACTN VN YANG Model October 2017 } leaf tunnel-ref { type te:tunnel-ref; config false; description "A reference to the TE tunnel in the TE model"; } } 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/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."; } }//vn-list }//vn }//actn /* Lee, et al. Expires April 23, 2018 [Page 25] Internet-Draft ACTN VN YANG Model October 2017 * Notifications - TBD */ /* * RPC */ rpc vn-compute{ description "The VN computation without actual instantiation"; input { list vn-member-list{ key "vn-member-id"; description "List of VN-members in a VN"; uses vn-member; } uses service-metric; } output { list vn-member-list{ key "vn-member-id"; description "List of VN-members in a VN"; uses vn-member; 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"; } } } } } Lee, et al. Expires April 23, 2018 [Page 26] Internet-Draft ACTN VN YANG Model October 2017 5. Security Considerations TDB 6. IANA Considerations TDB 7. Acknowledgments The authors would like to thank Igor Bryskin and Xufeng Liu for their helpful comments and valuable contributions. Lee, et al. Expires April 23, 2018 [Page 27] Internet-Draft ACTN VN YANG Model October 2017 8. References 8.1. Normative References [TE-TOPO] X. Liu, et al., "YANG Data Model for TE Topologies", work in progress: draft-ietf-teas-yang-te-topo. [TE-tunnel] T. Saad, et al., "A YANG Data Model for Traffic Engineering Tunnels and Interfaces", work in progress: draft-ietf-teas-yang-te. 8.2. Informative References [RFC7926] A. Farrel (Ed.), "Problem Statement and Architecture for Information Exchange between Interconnected Traffic- Engineered Networks", RFC 7926, July 2016. [ACTN-REQ] Lee, et al., "Requirements for Abstraction and Control of TE Networks", draft-ietf-teas-actn-requirements, work in progress. [ACTN-FWK] D. Ceccarelli, Y. Lee [Editors], "Framework for Abstraction and Control of Traffic Engineered Networks", draft-ceccarelli-teas-actn-framework, work in progress. [TE-MAP] Y. Lee, D. Dhody, and D. Ceccarelli, "Traffic Engineering and Service Mapping Yang Model", draft-lee-teas-te- service-mapping-yang, work in progress. [SERVICE-YANG] Q. Wu, W. Liu and A. Farrel, "Service Models Explained", draft-wu-opsawg-service-model-explained, work in progress. [ACTN-PM] Y. Lee, et al., "YANG models for ACTN TE Performance Monitoring Telemetry and Network Autonomics", draft-lee- teas-actn-pm-telemetry-autonomics, work in progress. [OIF-VTNS] Virtual Transport Network Services 1.0 Specification, IA OIF-VTNS-1.0, April 2017. Lee, et al. Expires April 23, 2018 [Page 28] Internet-Draft ACTN VN YANG Model October 2017 9. Contributors Contributor's Addresses Haomian Zheng Huawei Technologies Email: zhenghaomian@huawei.com Xian Zhang Huawei Technologies Email: zhang.xian@huawei.com Sergio Belotti Nokia Email: sergio.belotti@nokia.com Authors' Addresses Young Lee (ed.) Huawei Technologies Email: leeyoung@huawei.com Dhruv Dhody Huawei Technologies Email: dhruv.ietf@gmail.com Daniele Ceccarelli Ericsson Torshamnsgatan,48 Stockholm, Sweden Email: daniele.ceccarelli@ericsson.com Takuya Miyasaka KDDI Email: ta-miyasaka@kddi.com Peter Park KT Email: peter.park@kt.com Lee, et al. Expires April 23, 2018 [Page 29] Internet-Draft ACTN VN YANG Model October 2017 Bin Yeong Yoon ETRI Email: byyun@etri.re.kr Lee, et al. Expires April 23, 2018 [Page 30]