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

The information below is for an old version of the document
Document Type Active Internet-Draft (individual)
Authors Young Lee  , Daniele Ceccarelli  , Takuya Miyasaka  , Peter Park  , Bin-Yeong Yoon 
Last updated 2016-07-20
Replaced by draft-ietf-teas-actn-vn-yang
Stream (None)
Formats pdf htmlized (tools) htmlized bibtex
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                                                   Huawei
Intended Status: Standard Track                           D. Ceccarelli
                                                               Ericsson
                                                            Dhruv Doddy
                                                                 Huawei
                                                        Takuya Miyasaka
                                                                   KDDI
                                                             Peter Park
                                                                     KT
                                                         Bin Young Yoon
                                                                   ETRI

Expires: January 20, 2017                                 July 20, 2016

                  A Yang Data Model for ACTN VN Operation

                    draft-lee-teas-actn-vn-yang-01.txt

Abstract

   This document provides a YANG data model for the Abstraction and
   Control of Traffic Engineered (TE) networks (ACTN) 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.

   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 January 20, 2017.
Lee, et al.              Expires January 2017                  [Page 1]
Internet-Draft            ACTN VN YANG Model                  July 2016

Copyright Notice

   Copyright (c) 2016 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
      1.2. ACTN CMI context..........................................3
   2. ACTN VN YANG Model (Tree Structure)............................7
   3. ACTN-VN YANG Model.............................................8
   4. Security Considerations.......................................16
   5. IANA Considerations...........................................16
   6. Acknowledgments...............................................16
   7. References....................................................17
      7.1. Normative References.....................................17
      7.2. Informative References...................................17
   8. Contributors..................................................17
   Authors' Addresses...............................................18

1. Introduction

   This document provides a YANG data model for the Abstraction and
   Control of Traffic Engineered (TE) networks (ACTN) Virtual Network
   (VN) operation that is going to be implemented for the Customer
   Network Controller (CNC)- Multi-Domain Service Coordinator (MSDC)
   interface (CMI). The YANG model discussed in this document is used
   to operate customer-driven VNs during the VN instantiation and its
   life-cycle operations stages.

Lee, et al.              Expires January 2017                  [Page 2]
Internet-Draft            ACTN VN YANG Model                  July 2016

   This document is based on the requirements identified in [ACTN-REQ]
   and on the architecture framework defined in [ACTN-FWK]. As defined
   in [ACTN-FW], a Virtual Network (VN) is a customer view of the TE
   networks and may comprise a set of end-to-end tunnels connecting
   customer's end points. Therefore, it is important to associate a VN
   with its members (which are a number of end-to-end tunnels) that are
   going to be created in the provider network. Each end-to-end tunnel
   defined under a VN is referred to as a VN member.

   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.

1.1. Terminology

     - Abstract Topology: Every lower controller in the provider
        network, when is representing its network topology to a higher
        layer, it may want to hide details of the actual network
        topology. In such case, an abstract topology may be used for
        this purpose. Abstract topology enhances scalability for the
        MDSC to operate multi-domain networks. The abstraction of
        topology can be applied on both MPI and CMI, from PNC to MDSC
        and from MDSC to CNC respectively.

     - Access link: A link between a customer node and a provider
        node.

     - Access Point (AP): An access point is defined on an access
        link. It is used to keep confidentiality between the customer
        and the provider. It is an identifier shared between the
        customer and the provider, used to map the end points of the
        border node in the provider NW. The AP can be used by the
        customer when requesting connectivity service to the provider.
        A number of parameters, e.g. available bandwidth, need to be
        associated to the AP to qualify it.

     - VN Access Point (VNAP): A VNAP is defined within an AP as part
        of a given VN and is used to identify the portion of the AP,
        (and hence of the access link) dedicated to a given VN.

1.2. ACTN CMI context

   The model presented in this document has the following ACTN context.

Lee, et al.              Expires January 2017                  [Page 3]
Internet-Draft            ACTN VN YANG Model                  July 2016

                             +-------+
                             |  CNC  |
                             +-------+
                                 |
                                 |    <--- CMI (CNC-MDSC Interface)
                                 |
                      +-----------------------+
                      |         MDSC          |
                      +-----------------------+

                            Figure 1. ACTN CMI

   The CNC is the actor of the VN creation/modification/deletion (aka
   VN CRUD (Create, Read, Update and Delete) model).

   1. A VN may comprise a set of end-to-end tunnels from a customer
       point of view that connects customer endpoints (i.e., source CE
       and destination CE). See Figure 3 for this VN type.

   2. A VN may comprise of a number of virtual nodes and virtual links
       (more than a tunnel).

   For both cases, the CNC can dynamically add VN elements. For case 1,
   the VN element is an end-to-end tunnel and for case 2, the VN
   element can be virtual nodes or virtual links.

   In the subsequent discussion, the first form of VN will be
   discussed.

Lee, et al.              Expires January 2017                  [Page 4]
Internet-Draft            ACTN VN YANG Model                  July 2016

   The following figure describes a VN that comprises three VN members
   forming a full mesh for the VN as an illustration.

                                  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 end-to-end tunnel 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.

   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 end-to-end tunnel may be
   unidirectional or bidirectional which is also depending on its
   connectivity requirements. The following figure shows some examples
   of a VN that can represented in a different connectivity form
   depending on the customer's connectivity requirements.

Lee, et al.              Expires January 2017                  [Page 5]
Internet-Draft            ACTN VN YANG Model                  July 2016

       +---+         +---+        +---+         +---+         +---+         +---+
       |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
   end-to-end tunnels (i.e., VN members) with one unique identifier.
   From a customer standpoint, this simplifies its VN operation
   significantly.

   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 PNCs. The mapping and translation of a VN into network-centric
   models is out of the scope of this document.

Lee, et al.              Expires January 2017                  [Page 6]
Internet-Draft            ACTN VN YANG Model                  July 2016

   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.

2. 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 max-bandwidth?       decimal64
   |  |     +--rw avl-bandwidth?       decimal64
   |  +--rw vn
   |     +--rw vn-list* [vn-id]
   |        +--rw vn-id                 uint32
   |        +--rw vn-name?              string
   |        +--rw vn-member-list* [vn-member-id]
   |        |  +--rw vn-member-id     uint32
   |        |  +--rw src?             leafref
   |        |  +--rw src-vn-ap-id?    uint32
   |        |  +--rw dest?            leafref
   |        |  +--rw dest-vn-ap-id?   uint32
   |        +--rw delay?                uint32
   |        +--rw delay-variation?      uint32
   |        +--rw packet-loss?          decimal64
   |        +--rw bandwidth?            decimal64
   |        +--rw protection?           identityref
   |        +--rw local-reroute?        boolean
   |        +--rw push-allowed?         boolean
   |        +--rw incremental-update?   boolean
   |        +--rw admin-status?         identityref
   +--ro actn-state
      +--ro ap
      |  +--ro access-point-list* [access-point-id]
      |     +--ro access-point-id      uint32
      |     +--ro access-point-name?   string
      |     +--ro max-bandwidth?       decimal64

Lee, et al.              Expires January 2017                  [Page 7]
Internet-Draft            ACTN VN YANG Model                  July 2016

      |     +--ro avl-bandwidth?       decimal64
      +--ro vn
         +--ro vn-list* [vn-id]
            +--ro vn-id                 uint32
            +--ro vn-name?              string
            +--ro vn-member-list* [vn-member-id]
            |  +--ro vn-member-id       uint32
            |  +--ro src?               leafref
            |  +--ro src-vn-ap-id?      uint32
            |  +--ro dest?              leafref
            |  +--ro dest-vn-ap-id?     uint32
            |  +--ro delay?             uint32
            |  +--ro delay-variation?   uint32
            |  +--ro packet-loss?       decimal64
            |  +--ro oper-status?       identityref
            +--ro delay?                uint32
            +--ro delay-variation?      uint32
            +--ro packet-loss?          decimal64
            +--ro bandwidth?            decimal64
            +--ro protection?           identityref
            +--ro local-reroute?        boolean
            +--ro push-allowed?         boolean
            +--ro incremental-update?   boolean
            +--ro admin-status?         identityref
            +--ro oper-status?          Identityref

3. ACTN-VN YANG Code

   The YANG code is as follows:

   <CODE BEGINS> file ietf-actn-vn@2016-7-5.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";
       }

Lee, et al.              Expires January 2017                  [Page 8]
Internet-Draft            ACTN VN YANG Model                  July 2016

       organization
           "IETF Traffic Engineering Architecture and Signaling (TEAS)
           Working Group";

       contact
           "Editor: Young Lee <leeyoung@huawei.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 creation
           /modification /deletion.";

       revision 2016-07-05 {
           description
               "initial version.";
           reference
               "TBD";
       }

       /*
        * Groupings
        */

       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";
           }
           leaf max-bandwidth {
               type decimal64 {

Lee, et al.              Expires January 2017                  [Page 9]
Internet-Draft            ACTN VN YANG Model                  July 2016

                   fraction-digits 2;
                   range "0..max";
               }
               description
                   "max bandwidth of the AP";
           }
           leaf avl-bandwidth {
               type decimal64 {
                   fraction-digits 2;
                   range "0..max";
               }
               description
                   "available bandwidth of the AP";
           }
           /*add details and any other properties of AP,
           not associated by a VN
           CE port, PE port etc.

           This link may not be in the TE topology model(?)
           thus reference to that model would be incorrect
           */
       }//access-point

       grouping vn-member {
           description
               "vn-member is described by this container";
           leaf vn-member-id {
               type uint32;
               description
                   "vn-member identifier";
           }
           leaf src {
               type leafref {
                   path "/actn/ap/access-point-list/access-point-id";
               }
               description
                   "reference to source AP";
           }
           leaf src-vn-ap-id{
               type uint32;
               description

Lee, et al.              Expires January 2017                 [Page 10]
Internet-Draft            ACTN VN YANG Model                  July 2016

                   "vn-ap-id";
           }
           leaf dest {
               type leafref {
                   path "/actn/ap/access-point-list/access-point-id";
               }
               description
                   "reference to destination AP";
           }
           leaf dest-vn-ap-id{
               type uint32;
               description
                   "vn-ap-id";
           }

           /* can we add reference to itef-te model(?) here
           */

       }//vn-member

       grouping connectivity-metric {
           description
               "service aware metrics";
           leaf delay {
               type uint32 {
                   range "0..max";
               }
               description
                   "Path Delay or latency in micro seconds.";
           }
           leaf delay-variation {
               type uint32 {
                   range "0..max";
               }
               description
                   "Path Delay variation in micro seconds.";
           }
           leaf packet-loss {
               type decimal64 {
                   fraction-digits 6;
                   range "0 .. max";

Lee, et al.              Expires January 2017                 [Page 11]
Internet-Draft            ACTN VN YANG Model                  July 2016

               }
               description
                   "Path Packet Loss in percentage";
           }
           /*should we add other metrics
           like bandwidth utilization?*/

       }//connectivity-metric

       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 objective-function {
           description
               "objective-function";

           uses connectivity-metric;

           leaf bandwidth {
               type decimal64 {
                   fraction-digits 2;

Lee, et al.              Expires January 2017                 [Page 12]
Internet-Draft            ACTN VN YANG Model                  July 2016

                   range "0..max";
               }
               description
                   "bandwidth requested/required for
                   vn-member-id";
           }

           leaf protection {
               type identityref {
                   base te-types:lsp-prot-type;
               }
               description "protection type.";
           }

           uses policy;

       }//objective-function

       /*
        * 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";
                   }
            }
           }
           container vn {
               description
                   "VN configurations";

Lee, et al.              Expires January 2017                 [Page 13]
Internet-Draft            ACTN VN YANG Model                  July 2016

               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";
                   }
                   list vn-member-list{
                       key "vn-member-id";
                       description
                           "List of VN-members in a VN";
                       uses vn-member;
                   }
                   uses objective-function;

                   leaf admin-status {
                       type identityref {
                           base te-types:state-type;
                       }
                       default te-types:state-up;
                       description "VN administrative state.";
                   }
               }//vn-list
           }//vn
       }//actn

       /*
        * Operational data nodes
        */

       container actn-state{
           config false;

           description
               "actn is described by this container";

Lee, et al.              Expires January 2017                 [Page 14]
Internet-Draft            ACTN VN YANG Model                  July 2016

           container ap {
               description
                   "AP state";
               list access-point-list {
                   key "access-point-id";
                   description
                       "access-point identifier";
                   uses access-point{
                       description
                           "access-point information";
                   }
            }
           }
           container vn {
               description
                   "VN state";
               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";
                   }
                   list vn-member-list{
                       key "vn-member-id";
                       description
                           "List of VN-members in a VN";
                       uses vn-member;
                       uses connectivity-metric;
                       leaf oper-status {
                           type identityref {
                               base te-types:state-type;
                           }
                           description

Lee, et al.              Expires January 2017                 [Page 15]
Internet-Draft            ACTN VN YANG Model                  July 2016

                               "VN-member operational state.";
                       }
                   }

                   uses objective-function;

                   leaf admin-status {
                       type identityref {
                           base te-types:state-type;
                       }
                       description "VN administrative state.";
                   }
                   leaf oper-status {
                       type identityref {
                           base te-types:state-type;
                       }
                       description "VN operational state.";
                   }
               }//vn-list
           }//vn
       }//actn-state
   }

   <CODE ENDS>

4. Security Considerations

   TDB

5. IANA Considerations

   TDB

6. Acknowledgments

   This document was prepared using 2-Word-v2.0.template.dot.

Lee, et al.              Expires January 2017                 [Page 16]
Internet-Draft            ACTN VN YANG Model                  July 2016

7. References

   7.1. Normative References

   [ACTN-REQ] Lee, et al., "Requirements for Abstraction and Control of
             TE Networks", work in progress: draft-ietf-teas-actn-
             requirements.

   [ACTN-FWK] D. Ceccarelli, Y. Lee [Editors], "Framework for
             Abstraction and Control of Traffic Engineered Networks",
             work in progress: draft-ceccarelli-teas-actn-framework.

   [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.

   7.2. Informative References

8. 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

Lee, et al.              Expires January 2017                 [Page 17]
Internet-Draft            ACTN VN YANG Model                  July 2016

Authors' Addresses

   Young Lee (ed.)
   Huawei Technologies
   Email: leeyoung@huawei.com

   Daniele Ceccarelli
   Ericsson
   Torshamnsgatan,48
   Stockholm, Sweden
   Email: daniele.ceccarelli@ericsson.com

   Dhruv Dhoddy
   Huawei Technologies,
   Email: dhruv.ietf@gmail.com

   Takuya Miyasaka
   KDDI
   Email: ta-miyasaka@kddi.com

   Peter Park
   KT
   Email: peter.park@kt.com

   Bin Yeong Yoon
   ETRI
   Email: byyun@etri.re.kr

Lee, et al.              Expires January 2017                 [Page 18]