A Yang Data Model for ACTN VN Operation
draft-lee-teas-actn-vn-yang-08

Document Type Active Internet-Draft (individual)
Last updated 2017-10-30
Stream (None)
Intended RFC status (None)
Formats plain text pdf html bibtex
Yang Validation 0 errors, 0 warnings.
Additional URLs
- Yang catalog entry for ietf-actn-vn@2017-10-23.yang
- Yang impact analysis for draft-lee-teas-actn-vn-yang
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
TEAS Working Group                                      Y. Lee (Editor)
Internet Draft                                              Dhruv Dhody
Intended Status: Standard Track                                  Huawei
Expires: April 30, 2018                                   D. Ceccarelli
                                                               Ericsson
                                                        Takuya Miyasaka
                                                                   KDDI
                                                             Peter Park
                                                                     KT
                                                         Bin Yeung Yoon
                                                                   ETRI

                                                       October 30, 2017

                  A Yang Data Model for ACTN VN Operation

                      draft-lee-teas-actn-vn-yang-08

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 30, 2018.

Lee, et al.             Expires April 30, 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 30, 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 30, 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 30, 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 30, 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 30, 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 30, 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 30, 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 30, 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 30, 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 30, 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 30, 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 30, 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 30, 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:

   <CODE BEGINS> 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 <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.";

Lee, et al.             Expires April 30, 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 30, 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 30, 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 30, 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 30, 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 30, 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 30, 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 30, 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-protection-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 30, 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 30, 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 30, 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 30, 2018                [Page 26]
Internet-Draft            ACTN VN YANG Model               October 2017

   <CODE ENDS>

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 30, 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 30, 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 30, 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 30, 2018                [Page 30]