TEAS WG                                                       Young Lee
                                                          Haomian Zheng
Internet Draft                                                   Huawei                                            Haomian Zheng
Intended status: Informational
                                                     Daniel Ceccarrelli                                   Huawei
Expires: May 12, August 28, 2018
                                                      Daniel Ceccarelli

                                                         Bin Yeong Yoon

                                                 Oscar Gonzalez de Dios

                                                         Jong Yoon Shin

                                                         Sergio Belotti

                                                      November 12, 2017

                                                      February 28, 2018

  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 May 12, 2017. August 28, 2018.

Copyright Notice

   Copyright (c) 2017 2018 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document.  Code Components extracted from this
   document must include Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.


   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. This document also 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 developed.

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)....7
      4.2. Service Delivery Models in ACTN Architecture..............8
      4.3. Network Configuration Models in ACTN Architecture (MPI)...8
      4.4. Device Models in ACTN Architecture (SBI)..................9
   5. Examples of Using Different Types of YANG Models..............10 Models...............9
      5.1. Simple Connectivity Examples.............................10 Topology Collection.......................................9
      5.2. Connectivity over Two Client Nodes.......................10
      5.3. VN service example.......................................10
      5.3. example.......................................11
      5.4. Data Center-Interconnection Example......................11
         5.4.1. CMI (CNC-MDSC Interface)............................13
         5.4.2. MPI (MDSC-PNC Interface)............................13
         5.3.3. PDI (PNC-Device interface)..........................13
   6. Security......................................................14
   7. Acknowledgements..............................................14
   8. References....................................................14
      8.1. Informative References...................................14
   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 3 from [ACTN-Frame]. A number
   of key ACTN interfaces exist for deployment and operation of ACTN-
   based networks. These are highlighted in Figure 1 (ACTN Interfaces)

                +--------------+        +---------------+        +--------------+
                |    CNC-A     |        |     CNC-B     |        |     CNC-C    |
                |(DC provider) |        |     (ISP)     |        |     (MVNO)   |
                +--------------+        +---------------+        +--------------+
                     \                          |                           /
      Business        \                         |                          /
      Boundary  =======\========================|=========================/=======
      Between           \                       | CMI                    /
      Customer &         -----------            |          --------------
      Network Provider              \           |         /
                                   |          MDSC         |
                                    /           |         \
                        ------------            |MPI       ----------------
                       /                        |                          \
                  +-------+                 +-------+                   +-------+
                  |  PNC  |                 |  PNC  |                   |  PNC  |
                  +-------+                 +-------+                   +-------+
                     | GMPLS               /      |                      /   \
                     | trigger            /       |SBI              SBI /     \
                  --------           -----        |                    /       \
                 (        )         (     )       |                   /         \
                -         -        ( Phys. )      |                  /       -----
                (  GMPLS   )        ( Net )       |                 /       (     )
               (  Physical  )         ----        |                /       ( Phys. )
                (  Network )                   -----        -----           ( Net )
                 -        -                   (     )      (     )           -----
                  (       )                  (  Phys. )   (  Phys. )
                  --------                    ( Net )      ( Net )
                                               -----        -----

                        Figure 1 : ACTN Interfaces

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

     . The CNC-MDSC Interface (CMI) is an interface between a Customer
        Network Controller and a Multi Domain Service Controller. The
        interface will communicate the service request or application
        demand. A request will include specific service properties, for
        example, services type, bandwidth and constraint information.
        These constraints SHOULD be measurable by MDSC and therefore
        visible to CNC via CMI. The CNC can also request the creation
        of the virtual network based on underlying physical resources
        to provide network services for the applications. The CNC can
        provide the end-point information/characteristics, traffic
        matrix specifying specific customer constraints.  The MDSC may
        also report potential network topology availability if queried
        for current capability from the Customer Network Controller.

     . 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/delete
        connectivity or to modify bandwidth reservations in the
        physical network. In multi-domain environments, each PNC is
        responsible for a separate domain. The MDSC needs to establish
        multiple MPIs, one for each PNC and perform coordination
        between them to provide cross-domain connectivity.

     . The South-Bound Interface (SBI) is the provisioning interface
        for creating forwarding state in the physical network,
        requested via the Physical Network Controller. The SBI is not
        in the scope of ACTN, however, it is included in this document
        so that it can be compared to models in [Service-Yang].

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.

                            ------------------   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] provides solutions for the ACTN framework. This
   section explains which types of YANG models apply to each of the
   ACTN interfaces.

   Refer to Figure 5 of [ACTN-Frame] for details of the mapping between
   ACTN functions and service models. In summary, the following
   mappings are held between and Service Yang Models and the ACTN

     o Customer Service Model <-> CMI
     o Network Configuration Model <-> MPI
     o Device Configuration Model <-> SBI

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

   The following table provides a list of functions needed to build the
   CMI. They are mapped with Customer Service Models.

      Function                            Yang Model
      Transport Service Request              [Transport-Service-Model]

      VN Service Request & Instantiation                     [ACTN-VN-YANG]
      VN Path Computation Request                 [ACTN-VN-YANG]*
      TE & Service Mapping                   [TE-Service-Mapping]**
      VN Performance Monitoring Telemetry    [ACTN-PM-Telemetry]**    [ACTN-PM-Telemetry]***
      Topology Abstraction                   [TE-topology]                   [TE-topology]****

   *VN Path computation request in the CMI context means network path
   computation request based on customer service connectivity request
   constraints prior to the instantiation of a VN creation.


   **[TE-Service-Mapping] provides a mapping and cross-references
   between service models (e.g., L3SM, L2SM, L1CSM) and TE model via
   [ACTN-VN-YANG] and [TE-topology].

   ***ietf-actn-te-kpi-telemetry model describes performance telemetry
   for ACTN VN model. This module also allows autonomic traffic
   engineering scaling intent configuration mechanism on the VN level.
   Scale in/out criteria might be used for network autonomics in order
   the controller to react to a certain set of variations in monitored
   parameters. Moreover, this module also provides mechanism to define
   aggregated telemetry parameters as a grouping of underlying VN level
   telemetry parameters.

   ****TE-Topology's Connectivity Matrices/Matrix construct can be used
   to instantiate VN Service via a suitable referencing and mapping
   with [ACTN-VN-YANG].

4.2. Service Delivery Models in ACTN Architecture

   The Service Delivery Models 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 in a single MDSC model.

   In the MDSC hierarchical model where there are multiple MDSCs, the
   interface between the top MDSC and the bottom MDSC can be mapped to
   service delivery models.

4.3. Network Configuration Models in ACTN Architecture (MPI)

   The Network Configuration Models is used between the network
   orchestrator and the controller in [Service-YANG]. In ACTN, this
   model is used primarily between a MDSC and a PNC. The Network
   Configuration Model can be also used for the foundation of more
   advanced models, like hierarchical MDSCs (see Section 4.5)

   The Network Configuration Model captures the parameters which are
   network wide information.

   The following table provides a list of functions needed to build the
   MPI. They are mapped with Network Configuration Yang Models. Note
   that various Yang models are work in progress.

         Function                         Yang Model
         Configuration Scheduling         [Schedule]
         Path computation                 [PATH_COMPUTATION-API]*
         Path                 [PATH_COMPUTATION-API]
         Tunnel/LSP Provisioning                [TE-Tunnel]**          [TE-Tunnel]
         Topology Abstraction             [TE-topology]
         Tunnel PM Telemetry              [ACTN-PM-Telemetry]***
         Client Signal Description        [Client-signal]
         Service Provisioning             TBD****              TBD*

         OTN Topology Abstraction         [OTN-YANG]
         WSON Topology Abstraction        [WSON-YANG]
         Flexi-grid Topology Abstraction  [Flexi-YANG]
         OTN Tunnel Model                 [ODU-Tunnel]                 [OTN-Tunnel]
         WSON TE Tunnel Model             [WSON-Tunnel]
         Flexi-grid Tunnel Model          [Flexigrid-Tunnel]

   * Related draft is presenting use cases for path computation API,
   and Yang related model is foreseen to be added.

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

   ** ietf-actn-te-kpi-telemetry model describes performance telemetry
   for TE-tunnel model. This module also allows autonomic traffic
   engineering scaling intent configuration mechanism on the TE-tunnel
   level. Various conditions can be set for auto-scaling based on the
   telemetry data.

   **** This function needs to be investigated further. This can be a part
   of [TE-Tunnel] which is to be determined. Service provisioning is an
   optional function that builds on top the path provisioning one.

   Path provisioning and Topology abstraction functions are mandatory
   in any case, while Path Computation may be mandatory or optional

   [T-NBI Applicability] provides a summary on the type of topology abstraction used. Details applicability of this
   topic are discussed
   existing YANG model usage in [ACTN-Abstraction].

   Telemetry may also be an optional function. the current network configuration,
   especially for transport network.

4.4. Device Models in ACTN Architecture (SBI)

   Note that SBI is not in the scope of ACTN, as there are already
   mature protocol solutions for various purpose on the device level of
   ACTN architecture, such as RSVP-TE, OSPF-TE and so on. The
   interworking of such protocols and ACTN controller hierarchies can
   be found in [gmpls-controller-inter-work].

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

5. Examples of Using Different Types of YANG Models

5.1. Simple Connectivity Examples

   The data model in [Transport-Service-Model]

   This section provides an intent-like
   connectivity service model which can be used in connection-oriented

   It would be used as follows some examples on the usage of IETF YANG models
   in the ACTN architecture: network operation. A few typical generic scenarios are
   involved. In [T-NBI Applicability], there are more transport-related
   scenarios and examples.

5.1. Topology Collection

   Before any connection is requested and delivered, the controller
   needs to understand the network topology. The topology information
   is exchanged among controllers with topology models, such as [te-
   topology]. Moreover, technology-specific topology reporting may use
   the model described in [OTN-YANG] [WSON-YANG], and [Flexi-YANG] for
   OTN, WSON and Flexi-grid, respectively. By collecting the network
   topology, each controller can therefore construct a local database,
   which can be used for the further service deployment.

   There can be different types of abstraction applied between each
   pair of controllers as discussed in in [ACTN-frame]. The technology-
   specific features may be hidden after abstraction to make the
   network operation easier.

   When there are topology changes in the physical network, the PNC
   should report the change to upper level of controllers via updating
   messages using topology models. Accordingly, such changes are
   propagated between different controllers for further

5.2. Connectivity over Two Client Nodes

   The service models, such as described in [RFC8049], [L2SM] and
   [L1CSM], provide a connectivity service model which can be used in
   connection-oriented networks.

   It would be used as follows in the ACTN architecture:

     . A CNC uses this the service model models 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 be additionally specified is the SLA SLA/Policy that describes
        the required quality and resilience of the service. service especially
        on TE binding with the service (e.g., soft isolation, hard
        isolation, etc.) as defined in [TE-Service-Mapping].

     . 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, using topology YANG models such as
        [te-topology]. The topology reported from PNC to MDSC can
        either be abstract or non-abstract.

        Additionally, an 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 TE tunnel model specified in

        [te-tunnel]. Technology-specific tunnel configuration may use
        the model described in [OTN-Tunnel] [WSON-Tunnel], and
        [Flexigrid-Tunnel] for OTN, WSON and Flexi-grid, respectively.

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


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

     . A CNC will request VN to the MDSC by specifying 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 MDSC.

          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 evaluate each candidate and then choose
             the best candidate one 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. connectivity
             example in section 5.2.

   After the VN is set up, a successful reply message is sent from MDSC
   to CNC, indicating the VN is ready. This message can also be
   achieved by using the model defined in [ACTN-VN-YANG].


5.4. 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 3 shows a use-case which shows service policy-
   driven Data Center selection and is a reproduction of Figure A.1
   from [ACTN-Info].

                             |       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 3: Service Policy-driven Data Center Selection

   Figure 3 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.4.1. CMI (CNC-MDSC Interface)

   [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.4.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 DC sources and the DC 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
   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.

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

   [PATH-COMPUTATION-API] I.Busi/S.Belotti et al. "Path Computation
             API", draft-busibel-ccamp-path-computation-api-00.txt,
             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

   [ACTN-Abstraction] Y. Lee, D. Dhody, and D. Ceccarelli, "ACTN
             Abstraction Methods", draft-lee-tease-actn-abstraction,
             work in progress.

   [OTN-YANG] X. Zhang, A. Sharma, and X. Liu, "A YANG Data Model for
             Optical Transport Network Topology", draft-zhang-ccamp-l1-
             topo-yang, work in progress.

   [WSON-YANG] Y. Lee, et. al., "A Yang Data Model for WSON Optical
             Networks", draft-ietf-ccamp-wson-yang, work in progress.

   [Flexi-YANG] J.E. Lopez de Vergara, et. al., "YANG data model for
             Flexi-Grid Optical Networks", draft-vergara-ccamp-flexigrid-
             yang, work in progress.[ODU-Tunnel]   Sharma, R. Rao, and
             X. Zhang, "OTN Service YANG Model", draft-sharma-ccamp-
             otn-service-model, work in progress.

   [ACTN-PM-Telemetry] Y. Lee, D. Dhody, S. Karunanithi, R. Vilalta, D.
             King, and D. Ceccarelli, "YANG models for ACTN TE
             Performance Monitoring Telemetry and Network Autonomics",
             draft-lee-teas-actn-pm-telemetry-autonomics, work in

   [WSON-Tunnel] Y. Lee, D. Dhody, V. Lopez, D. King, B. Yoon, and R.
             Vilalta, "A Yang Data Model for WSON Tunnel", draft-lee- draft-ietf-
             ccamp-wson-tunnel-model, work in progress.

   [Flexigrid-Tunnel] J. Vergara, D. Perdices, V. Lopez, O. Gonzalez de
             Dios, D. King, Y. Lee, and G. Galimberti, "YANG data model
             for Flexi-Grid media-channels", draft-vergara-ccamp- draft-ietf-ccamp-
             flexigrid-media-channel-yang, work in progress.

   [TE-Service-Mapping] Y. Lee, et al, "Traffic Engineering and Service
             Mapping Yang Model", draft-lee-teas-te-service-mapping-
             yang, work in progress.

   [Client-signal] H. Zheng, et al, "A YANG Data Model for Optical
             Transport Network Client Signals", draft-zheng-ccamp-otn-
             client-signal-yang, work in progress.

   [T-NBI Applicability] I. Busi, et al, "Transport Northbound
             Interface Applicability Statement and Use Cases", draft-
             ietf-ccamp-transport-nbi-app-statement, work in progress.

   [gmpls-controller-inter-work] H. Zheng, et al, "Interworking of
             GMPLS Control and Centralized Controller System", draft-
             zheng-ccamp-gmpls-controller-inter-work, work in progress.

9. Contributors

Contributor's Addresses
   Dhruv Dhody
   Huawei Technologies

   Email: dhruv.ietf@gmail.com

   Xian Zhang
   Huawei Technologies

   Email: zhang.xian@huawei.com

Authors' Addresses

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

   Email: leeyoung@huawei.com

   Haomian Zheng
   Huawei Technologies

   Email: zhenghaomian@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

   Jong Yoon Shin

   Email: jongyoon.shin@sk.com

   Sergio Belotti

   Email: sergio.belotti@nokia.com