TEAS WG                                                       Young Lee
                                                             Xian Zhang
Internet Draft                                                   Huawei
Intended status: Informational
                                                    Daniele Ceccarrelli
Expires: February 2017                                         Ericsson

                                                         Bin Yeong Yoon

                                                 Oscar Gonzalez de Dios

                                                     September 27, 2016

  Applicability of YANG models for Abstraction and Control of Traffic
                          Engineered Networks


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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 27, 2017.

Zhang, et al.          Expires January 27, 2017                [Page 1]

Internet-Draft                ACTN YANG                  September 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.


   Abstraction and Control of TE Networks (ACTN) refers to the set of
   virtual network operations needed to orchestrate, control and manage
   large-scale multi-domain TE networks, so as to facilitate network
   programmability, automation, efficient resource sharing, and end-to-
   end virtual service aware connectivity and network function
   virtualization services.

   This document explains how the different types of YANG models
   defined in the Operations and Management Area and in the Routing
   Area are applicable to the ACTN framework.

Table of Contents

   1. Introduction...................................................3
   2. Abstraction and Control of TE Networks (ACTN) Architecture.....3
   3. Service Models.................................................5
   4. Service Model Mapping to ACTN..................................6
      4.1. Customer Service Models in the ACTN Architecture (CMI)....8
      4.2. Service Delivery Model in ACTN Architecture...............9
      4.3. Network Configuration Model in ACTN Architecture (MPI)....9
      4.4. Device Model in ACTN Architecture (SBI)..................10
      4.5. Advanced Models..........................................10
   5. Examples of Using Different Types of YANG Models..............11
      5.1. Simple Connectivity Examples.............................11

Zhang, et al.          Expires January 27, 2017                [Page 2]

Internet-Draft                ACTN YANG                  September 2016

      5.2. VN service example.......................................11
      5.3. Data Center-Interconnection Example......................12
         5.3.1. CMI (CNC-MDSC Interface)............................14
         5.3.2. MPI (MDSC-PNC Interface)............................14
         5.3.3. PDI (PNC-Device interface)..........................14
   6. Security......................................................15
   7. Acknowledgements..............................................15
   8. References....................................................15
      8.1. Informative References...................................15
   9. Contributors..................................................16
   Authors' Addresses...............................................17

1. Introduction

   Abstraction and Control of TE Networks (ACTN) describes a method for
   operating a Traffic Engineered (TE) network (such as an MPLS-TE
   network or a layer 1 transport network) to provide connectivity and
   virtual network services for customers of the TE network. The
   services provided can be tuned to meet the requirements (such as
   traffic patterns, quality, and reliability) of the applications
   hosted by the customers. More details about ACTN can be found in
   Section 2.

   Data models are a representation of objects that can be configured
   or monitored within a system. Within the IETF, YANG [RFC6020] is the
   language of choice for documenting data models, and YANG models have
   been produced to allow configuration or modelling of a variety of
   network devices, protocol instances, and network services. YANG data
   models have been classified in [Netmod-Yang-Model-Classification]
   and [Service-YANG].

   This document shows how the ACTN architecture can be satisfied using
   classes of data model that have already been defined, and discusses
   the applicability of specific data models that are under
   development. It also highlights where new data models may need to be

2. Abstraction and Control of TE Networks (ACTN) Architecture

   [ACTN-Requirements] describes the high-level ACTN requirements.
   [ACTN-Frame] describes the architecture model for ACTN including the
   entities (Customer Network Controller (CNC), Multi-domain Service
   Coordinator (MDSC), and Physical Network Controller (PNC)) and their

   Figure 1 depicts a high-level control and interface architecture for
   ACTN and is a reproduction of Figure 7 from [ACTN-Frame]. A number

Zhang, et al.          Expires January 27, 2017                [Page 3]

Internet-Draft                ACTN YANG                  September 2016

   of key ACTN interfaces exist for deployment and operation of ACTN-
   based networks. These are highlighted in Figure 1 (ACTN Interfaces)

               -------------   |
              | Application |--
                     | I/F A                 --------
                     v                      (        )
                --------------             -          -
               | Customer     |           (  Customer  )
               |  Network     |--------->(    Network   )
               |   Controller |           (            )
                --------------             -          -
                     ^                      (        )
                     | I/F B                 --------
               | MultiDomain  |
               |  Service     |
               |   Coordinator|            --------
                --------------            (        )
                     ^                   -          -
                     | I/F C            (  Physical  )
                     v                 (    Network   )
                  ---------------       (            )     --------
                 |               |<----> -          -     (        )
                --------------   |        (        )     -         -
               | Physical     |--          --------     (  Physical  )
               |  Network     |<---------------------->(    Network   )
               |   Controller |         I/F D           (            )
                --------------                           -         -
                                                          (        )

                        Figure 1 : ACTN Interfaces

   The interfaces and functions are described below (without modifying
   the definitions) in [ACTN-Frame]:

     . Interface A: This is out of scope of this draft.

     . Interface B: The CNC-MDSC Interface (CMI) is an interface
        between a Customer Network Controller and a Multi Domain

Zhang, et al.          Expires January 27, 2017                [Page 4]

Internet-Draft                ACTN YANG                  September 2016

        Service Controller. The interface will communicate the service
        request or application demand. A request will include specific
        service properties, including: services, bandwidth and
        constraint information. The CNC can also request the creation
        of the virtual network resources and virtual topology based on
        underlying physical resources to provide network services for
        the applications. The CNC can provide the end-point
        information/characteristics, traffic demand, a connectivity
        matrix, and a virtual network. The MDSC may also report
        potential network topology availability if queried for current
        capability from the Customer Network Controller.

     . Interface C: The MDSC-PNC Interface (MPI) is an interface
        between a Multi Domain Service Coordinator and a Physical
        Network Controller. It allows the MDSC to communicate requests
        to create connectivity or to modify bandwidth reservations in
        the physical network. In multi-domain environments, each PNC is
        responsible for a separate domain and so the MDSC needs to
        establish multiple MPIs, one for each PNC and perform
        coordination between them.

     . Interface D: The provisioning interface for creating forwarding
        state in the physical network, requested via the Physical
        Network Controller.

3. Service Models

   [Service-YANG] introduces a reference architecture to explain the
   nature and usage of service YANG models in the context of service
   orchestration. Figure 2 below depicts this relationship and is a
   reproduction of Figure 2 from [Service-YANG]. Four models depicted
   in Figure 2 are defined as follows:

     . Customer Service Model:  A customer service model is used to
        describe a service as offer or delivered to a customer by a
        network operator.
     . Service Delivery Model:  A service delivery model is used by a
        network operator to define and configure how a service is
        provided by the network.
     . Network Configuration Model: A network configuration model is
        used by a network orchestrator to provide network-level
        configuration model to a controller.
     . Device Configuration Model: A device configuration model is
        used by a controller to configure physical network elements.

Zhang, et al.          Expires January 27, 2017                [Page 5]

Internet-Draft                ACTN YANG                  September 2016

                            ------------------   Service  ----------
                           |                  |  Model   |          |
                           |     Service      |<-------->| Customer |
                           |   Orchestrator   |          |          |
                           |                  |           ----------
                               .          .
                              .            .              -----------
                             .              .      ......|Application|
                            .                .     :     |  BSS/OSS  |
                           .                  .    :      -----------
                          .  Service Delivery  .   :
                          .       Model        .   :
                 ------------------    ------------------
                |                  |  |                  |
                |     Network      |  |     Network      |
                |   Orchestrator   |  |   Orchestrator   |
                |                  |  |                  |
                .------------------    ------------------.
               .         :                       :        .
              .          : Network Configuration :         .
              .          :        Model          :         .
      ------------     ------------     ------------    ------------
     |            |   |            |   |            |  |            |
     | Controller |   | Controller |   | Controller |  | Controller |
     |            |   |            |   |            |  |            |
      ------------     ------------     ------------    ------------
         :              .       .                 :            :
         :             .         .      Device    :            :
         :            .           . Configuration :            :
         :            .           .     Model     :            :
     ---------     ---------   ---------     ---------      ---------
    | Network |   | Network | | Network |   | Network |    | Network |
    | Element |   | Element | | Element |   | Element |    | Element |
     ---------     ---------   ---------     ---------      ---------

         Figure 2: An SDN Architecture with a Service Orchestrator
4. Service Model Mapping to ACTN

   YANG models coupled with the RESTCONF/NETCONF protocol
   [Netconf][Restconf] is a solution for the ACTN framework. This
   section explains which types of YANG models apply to each of the
   ACTN interfaces.

Zhang, et al.          Expires January 27, 2017                [Page 6]

Internet-Draft                ACTN YANG                  September 2016

   |                                                             |
   |   +-----------+                                 +-------+   |
   |   | Customer  |                                 |  CNC  |   |
   |   +-----------+                                 +-------+   |
   |        /|\                                         /|\      |
             |  Customer Service Model                   | CMI
             |                                           |
   +------ --|-------------------------------------------|--------+
   |        \|/                                          |        |
   |   +------------+                                    |        |
   |   |   Service  |                                   \|/       |
   |   |Orchestrator|                              +----------+   |
   |   +------------+                              |          |   |
   |        /|\                                    |   MDSC   |   |
   |         |  Service Delivery Model             |          |   |
   |        \|/                                    |          |   |
   |   +------------+                              +----------+   |
   |   |  Network   |                                   /|\       |
   |   |Orchestrator|                                    |        |
   |   +------------+                                    |        |
   |        /|\                                          |        |
   |         |                                           |        |
             |                                           | MPI
             | Network Configuration Model               |
   |        \|/                                         \|/       |
   |    +----------+                               +-----------+  |
   |    |  Domain  |                               |    PNC    |  |
   |    |Controller|                               +-----------+  |
   |    +----------+                                 /|\   /|\    |
   |     /|\   /|\                                    |     |     |
   |      |     |                                     |     |     |
          |     |  Device Configuration Model         |     | SBI
         \|/   \|/                                   \|/   \|/
         ---   ---                                   ---   ---
        /   \ /   \                                 /   \ /   \
        \   / \   /                                 \   / \   /
         ---   ---                                   ---   ---

      Figure 3 : Mapping between Service Model and ACTN Architecture

Zhang, et al.          Expires January 27, 2017                [Page 7]

Internet-Draft                ACTN YANG                  September 2016

   As shown in Figure 3, the architecture described in [Service-YANG]
   can be mapped to the ACTN architecture well. A point worth noting is
   that here the functions of the MDSC can include:

       1. Customer mapping/translation

   This function is to map customer intent-like commands into network
   provisioning requests to the Physical Network Controller (PNC)
   according to business OSS/NMS provisioned static or dynamic policy.
   . Moreover, it provides mapping and translation of customer network
   slices into physical network resources.

       2. Service/Virtual service coordination

   This function translates customer service-related information into
   the virtual network operations in order to seamlessly operate
   virtual networks while meeting customer's service requirements.

       3. Multi domain coordination

   This function oversees the specific aspects of the different domains
   and to build a single abstracted end-to-end network topology in
   order to coordinate end-to-end path computation and path/service
   provisioning. Domain sequence path calculation/determination is also
   a part of this function.

       4. Virtualization/Abstraction

   This function provides an abstracted view of the underlying network
   resources towards customer, being it the client or a higher level
   controller entity. It includes computation of customer resource
   requests into network paths based on the global network-wide
   abstracted topology and the creation of an abstracted view of
   network slices allocated to each customer, according to customer-
   specific network objective functions, and to the customer traffic

   The first two of these functions (1 and 2) are related to service
   orchestration while function 3 is related to network orchestration
   and function 4 is related to both service and network orchestration.

4.1. Customer Service Models in the ACTN Architecture (CMI)

   Customer Service Models, which are used between a customer and a
   service orchestrator as in [Service-YANG], should be used between

Zhang, et al.          Expires January 27, 2017                [Page 8]

Internet-Draft                ACTN YANG                  September 2016

   the CNC and MDSC (e.g., CMI) serving as providing a simple intent-
   like model/interface.

   Among the key functions of Customer Service Models on the CMI is the
   service request. A request will include specific service properties,
   including: service type and its characteristics, bandwidth,
   constraint information, and end-point characteristics.

   Examples of service models applicable to ACTN are [Transport-
   Service-Model] and [ACTN-VN-YANG].

4.2. Service Delivery Model in ACTN Architecture

   The Service Delivery Models (as shown in Figure 3) where the service
   orchestration and the network orchestration could be implemented as
   separate components as seen in [Service-YANG]. This is also known as
   Network Service Models. On the other hand, from an ACTN architecture
   point of view, the service delivery model between the service
   orchestrator and the network orchestrator is an internal interface
   between sub-components of the MDSC.

4.3. Network Configuration Model in ACTN Architecture (MPI)

   The Network Configuration Models is used between the network
   orchestrator (MSDC) and the controller (PNC) in [Service-YANG]. In
   ACTN, this model is used either between hierarchical MDSCs (see
   Section 4.5) or between a MDSC and a PNC.

   The Network Configuration Model captures the parameters which are
   network wide information. Examples of Network configuration models
   are [TE-Tunnel] and [TE-Topology].

   The following table provides key functions of the MPI mapped with
   Network Configuration Yang Models. Note that there are various Yang
   models are work in progress.

         Function                      Yang Models
         Configuration Scheduling      [Schedule]
         Path computation              TDB
         Path Provisioning             [TE-Tunnel]*
         Topology Abstraction          [TE-topology]
         Telemetry                     TDB

   *Note that path provisioning function is provided by ietf-te module
   in [TE-Tunnel].

Zhang, et al.          Expires January 27, 2017                [Page 9]

Internet-Draft                ACTN YANG                  September 2016

4.4. Device Models in ACTN Architecture (SBI)

   For the device YANG models are used for per-device configuration
   purpose, they can be used between the PNC and the physical
   network/devices. An example of Device Models is ietf-te-device yang
   module defined in [TE-tunnel]. Note that SBI is not in the scope of
   ACTN. This section is provided to give some examples of YANG-based
   Device Models.

4.5. Advanced Models

   There may be some variation of interface C whereby there may be
   MDSC-MDSC interface (MMI) in case where there may be a recursive
   hierarchy among the MDSCs. This is a variation of ACTN architecture.
   See Figure 4 for this.

   +-------+                 +-------+                 +-------+
   | CNC-A |                 | CNC-B |                 | CNC-C |
   +-------+                 +-------+                 +-------+
         \                       |                        /
          ----------             |             ----------
                     \           |            /
                      |         MDSC          |
                      /          |            \
            ----------           |             -----------
           /                     |                        \
   +----------+              +----------+             +--------+
   |   MDSC   |              |   MDSC   |             |  MDSC  |
   +----------+              +----------+             +--------+
        |                    /     |                     /    \
        |                   /      |                    /      \
     +-----+           +-----+  +-----+            +-----+  +-----+
     | PNC |           | PNC |  | PNC |            | PNC |  | PNC |
     +-----+           +-----+  +-----+            +-----+  +-----+

                    Figure 4: MDSC Controller Hierarchy

   The MDSC-MDSC interface can be viewed as a recursive network
   configuration model which is similar to the MDSC-PNC interface.

Zhang, et al.          Expires January 27, 2017               [Page 10]

Internet-Draft                ACTN YANG                  September 2016

5. Examples of Using Different Types of YANG Models

5.1. Simple Connectivity Examples

   The data model in [Transport-Service-Model] provides an intent-like
   connectivity service model which can be used in connection-oriented
   transport networks.

   It would be used as follows in the ACTN architecture:

     . A CNC uses this service model to specify the two client nodes
        that are to be connected, and also indicates the amount of
        traffic (i.e., the bandwidth required) and payload type. What
        may additionally is the SLA that describes the required quality
        and resilience of the service.

     . The MDSC uses the information in the request to pick the right
        network (domain) and also to select the provider edge nodes
        corresponding to the customer edge nodes.

        If there are multiple domains, then the MDSC needs to
        coordinate across domains to set up network tunnels to deliver
        a service. Thus coordination includes, but is not limited to,
        picking the right domain sequence to deliver a service. Before
        it can perform such functions, it needs to get the topology
        information from each PNC, be it abstract or not, using
        topology YANG models such as [te-topology].

        Additionally, a MDSC can initiate the creation of a tunnel (or
        tunnel segment) in order to fulfill the service request from
        CNC based on path computation upon the overall topology
        information it synthesized from different PNCs. The based model
        that can cater this purpose is the te-tunnel model specified in

     . Then, the PNC needs to decide the explicit route of such a
        tunnel or tunnel segment (in case of multiple domains), and
        create such a tunnel using protocols such as PCEP and RSVP-TE
        or using per-hop configuration.

5.2. VN service example

   The service model defined in [ACTN-VN-YANG] describes a virtual
   network (VN) as a service which is a set of multiple connectivity

Zhang, et al.          Expires January 27, 2017               [Page 11]

Internet-Draft                ACTN YANG                  September 2016

     . A CNC will specify to the MDSC a list of VN members. Each VN
        member specifies either a single connectivity service, or a
        source with multiple potential destination points in the case
        that the precise destination sites are to be determined by

          o In the first case, the procedure is the same as the
             connectivity service, except that in this case, there is a
             list of connections requested.

          o In the second case, where the CNC requests the MDSC to
             select the right destination out of a list of candidates,
             the MDSC needs to choose the best candidate and reply with
             the chosen destination for a given VN member.  After this
             is selected, the connectivity request setup procedure is
             the same as in the connectivity-as-a-service example.

5.3. Data Center-Interconnection Example

   This section describes more concretely how existing YANG models
   described in Section 4 map to an ACTN data center interconnection
   use case. Figure 5 shows a use-case which shows service policy-
   driven Data Center selection and is a reproduction of Figure A.1
   from [ACTN-Info].

Zhang, et al.          Expires January 27, 2017               [Page 12]

Internet-Draft                ACTN YANG                  September 2016

                             |       CNC      |
                             |   (Global DC   |
                             |   Operation    |
                             |    Control)    |
                                      | |   VN Requirement/Policy:
                    CMI:              | |  - Endpoint/DC location info
                 Service model        | |  - Endpoint/DC dynamic
                                      | |    selection policy
                                      | |    (for VM migration, DR, LB)
                                      | v
                            |  Multi-domain     | Service policy-driven
                            |Service Coordinator| dynamic DC selection
              MPI:          +-----+---+---+-----+
    Network Configuration         |   |   |
    Model                         |   |   |
                 +----------------+   |   +---------------+
                 |                    |                   |
           +-----+-----+       +------+-----+      +------+-----+
           |  PNC for  |       |  PNC for   |      |  PNC for   |
           | Transport |       | Transport  |      | Transport  |
           | Network A |       | Network B  |      | network C  |
           +-----------+       +------------+      +------------+
   Device        |                    |                   |
   Model         |                    |                   |
                 |                    |                   |
+---+      ------               ------              ------       +---+
|DC1|--////      \\\\       ////      \\\\      ////      \\\\---+DC5|
+---+ |              |     |              |    |              |  +---+
      |     TN A     +-----+     TN B     +----+      TN C    |
      /              |     |              |    |              |
     / \\\\      ////     / \\\\      ////      \\\\      ////
   +---+   ------        /      ------    \         ------ \
   |DC2|                /                  \                \+---+
   +---+               /                    \                |DC6|
                     +---+                   \ +---+         +---+
                     |DC3|                    \|DC4|
                     +---+                     +---+

                                                DR: Disaster Recovery
                                                LB: Load Balancing

             Figure 5: Service Policy-driven Data Center Selection

Zhang, et al.          Expires January 27, 2017               [Page 13]

Internet-Draft                ACTN YANG                  September 2016

   Figure 5 shows how VN policies from the CNC (Global Data Center
   Operation) are incorporated by the MDSC to support multi-destination
   applications. Multi-destination applications refer to applications
   in which the selection of the destination of a network path for a
   given source needs to be decided dynamically to support such

   Data Center selection problems arise for VM mobility, disaster
   recovery and load balancing cases. VN's policy plays an important
   role for virtual network operation. Policy can be static or dynamic.
   Dynamic policy for data center selection may be placed as a result
   of utilization of data center resources supporting VMs. The MDSC
   would then incorporate this information to meet the objective of
   this application.

        5.3.1. CMI (CNC-MDSC Interface)

   The VN Service Model [ACTN-VN-YANG] is used to express the
   definition of a VN, its VN creation request, the service objectives
   (metrics, QoS parameters, etc.), dynamic service policy when VM
   needs to be moved from one Data Center to another Data Center, etc.
   This service model is used between the CNC and the MDSC (CMI). The
   CNC in this use-case is an external entity that wants to create a VN
   and operates on the VN.

        5.3.2. MPI (MDSC-PNC Interface)

   The Network Configuration Model is used between the MDSC and the
   PNCs. Based on the Customer Service Model's request, the MDSC will
   need to translate the service model into the network configuration
   model to instantiate a set of multi-domain connections between the
   prescribed sources and the destinations. The MDSC will also need to
   dynamically interact with the CNC for dynamic policy changes
   initiated by the CNC. Upon the determination of the multi-domain
   connections, the MDSC will need to use the network configuration
   model such as [TE-Tunnel] to interact with each PNC involved on the
   path. [TE-Topology] is used to for the purpose of underlying domain
   network abstraction from the PNC to the MDSC.

        5.3.3. PDI (PNC-Device interface)

   The Device Model can be used between the PNC and its underlying
   devices that are controlled by the PNC. The PNC will need to trigger
   signaling using any mechanisms it employees (e.g. [RSVP-TE-YANG]) to
   provision its domain path segment. There can be a plethora of
   choices how to control/manage its domain network. The PNC is
   responsible to abstract its domain network resources and update it

Zhang, et al.          Expires January 27, 2017               [Page 14]

Internet-Draft                ACTN YANG                  September 2016

   to the MDSC. Note that this interface is not in the scope of ACTN.
   This section is provided just for an illustration purpose.

6. Security

   This document is an informational draft. When the models mentioned
   in this draft are implemented, detailed security consideration will
   be given in such work.

   How security fits into the whole architecture has the following

   - the use of Restconf security between components

   - the use of authentication and policy to govern which services can
   be requested by different parties.

   - how security may be requested as an element of a service and
   mapped down to protocol security mechanisms as well as separation
   (slicing) of physical resources)

7. Acknowledgements

   We thank Adrian Farrel for providing useful comments and suggestions
   for this draft.

8. References

8.1. Informative References

   [Service-YANG] Q. Wu, W. Liu and A. Farrel, "Service Models
             Explained", draft-wu-opsawg-service-model-explained, work
             in progress.

   [Netmod-Yang-Model-Classification] D. Bogdanovic, B. Claise, and C.
             Moberg, "YANG Module Classification", draft-ietf-netmod-
             yang-model-classification, work in progress.

   [Netconf] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,

             and A. Bierman, Ed., "Network Configuration Protocol

             (NETCONF)", RFC 6241.

   [Restconf] A. Bierman, M. Bjorklund, and K. Watsen, "RESTCONF
             Protocol", draft-ietf-netconf-restconf, work in progress.

Zhang, et al.          Expires January 27, 2017               [Page 15]

Internet-Draft                ACTN YANG                  September 2016

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

   [ACTN-Frame] D. Cecarelli and Y. Lee, "Framework for Abstraction and
             Control of Traffic Engineered Networks", draft-ietf-teas-
             actn-framework, work in progress.

   [TE-Topology] X. Liu, et. al., "YANG Data Model for TE Topologies",
             draft-ietf-teas-yang-te-topo, work in progress.

   [TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic
             Engineering Tunnels and Interfaces", draft-ietf-teas-yang-
             te, work in progress.

   [ACTN-VN-YANG] Y. Lee (Editor), "A Yang Data Model for ACTN VN
             Operation", draft-lee-teas-actn-vn-yang, work in progress.

   [ACTN-Info] Y. Lee & S. Belotti, "Information Model for Abstraction
             and Control of TE Networks (ACTN)", draft-leebelotti-teas-
             actn-info, work in progress.

   [Transport-Service-Model] X. Zhang (Editor), "A Service YANG Model
             for Connection-oriented Transport Networks", draft-zhang-
             teas-transport-service-model, work in progress.

   [RSVP-TE-YANG] T. Saad (Editor), "A YANG Data Model for Resource
             Reservation Protocol (RSVP)", draft-ietf-teas-yang-rsvp,
             work in progress.

   [Schedule] X. Liu, et. al., "A YANG Data Model for Configuration
             Scheduling", draft-liu-netmod-yang-schedule, work in

9. Contributors

Contributor's Addresses

   Dhruv Dhoddy
   Huawei Technologies

   Email: dhruv.ietf@gmail.com

Zhang, et al.          Expires January 27, 2017               [Page 16]

Internet-Draft                ACTN YANG                  September 2016

   Haomian Zheng
   Huawei Technologies

   Email: zhenghaomian@huawei.com

   Sergio Belotti

   Email: sergio.belotti@nokia.com

Authors' Addresses

   Young Lee
   Huawei Technologies
   5340 Legacy Drive
   Plano, TX 75023, USA
   Phone: (469)277-5838

   Email: leeyoung@huawei.com

   Xian Zhang
   Huawei Technologies

   Email: zhang.xian@huawei.com

   Daniele Ceccarelli
   Stockholm, Sweden

   Email: daniele.ceccarelli@ericsson.com

   Bin Yeong Yoon

   Email: byyun@etri.re.kr

   Oscar Gonzalez de Dios

   Email: oscar.gonzalezdedios@telefonica.com

Zhang, et al.          Expires January 27, 2017               [Page 17]