[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12

TEAS WG                                                       Young Lee
Internet Draft                                              Dhruv Dhody
Intended status: standard track                                  Huawei
Expires: October 5, 2018
                                                     Daniele Ceccarelli
                                                               Ericsson

                                                          Jeff Tantsura
                                                                  Nuage

                                                      Giuseppe Fioccola
                                                         Telecom Italia

                                                          April 5, 2018


           Traffic Engineering and Service Mapping Yang Model


                 draft-lee-teas-te-service-mapping-yang-07

Abstract

   This document provides a YANG data model to map service model (e.g.,
   L3SM) and Traffic Engineering model (e.g., TE Tunnel or ACTN VN
   model). This model is referred to as TE service Mapping Model. This
   model is applicable to the operation's need for a seamless control
   and management of their VPN services with TE tunnel support.





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





Lee, et al.              Expires October 2018                  [Page 1]


Internet-Draft             TE & Service Mapping              April 2018


   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 October 5, 2018.

Copyright Notice

   Copyright (c) 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.


Table of Contents


   1. Introduction...................................................2
   2. L3VPN Architecture in ACTN context.............................5
   3. TE-Service Mapping Model.......................................7
   4. YANG Data Tree.................................................7
   5. Yang Data Model................................................8
   6. Security......................................................16
   7. IANA Considerations...........................................16
   8. Acknowledgements..............................................17
   9. References....................................................17
      9.1. Informative References...................................17
   10. Contributors.................................................18
   Authors' Addresses...............................................18

1. Introduction

   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 modeling of a variety of



Lee, et al.              Expires October 2018                  [Page 2]


Internet-Draft             TE & Service Mapping              April 2018


   network devices, protocol instances, and network services. YANG data
   models have been classified in [Netmod-Yang-Model-Classification]
   and [Service-YANG].

   [RFC4110] provides a framework for Layer 3 Provider-Provisioned
   Virtual Private Networks (PPVPNs). [L3SM-YANG] provides a L3VPN
   service delivery YANG model for PE-based VPNs. The scope of this
   draft is limited to a set of domain under the same network operators
   to deliver services requiring TE tunnels.

   [ACTN-VN-YANG] describes how customers or end to end orchestrators
   can request and/or instantiate a generic virtual network service.
   [ACTN-Applicability] describes a connection between IETF YANG model
   classifications to ACTN interfaces. In particular, it describes the
   customer service model can be mapped into the CMI (CNC-MDSC
   Interface) of the ACTN architecture.

   The YANG model on the ACTN CMI is known as customer service model in
   [Service-YANG]. The YANG model developed in this document describes
   how operator's end to end orchestrator interacts with the MDSC so
   that the MDSC then can coordinate the control and management of
   L3VPN MPLS TE tunnels that traverse both IP/MPLS and Transport
   networks. In addition, the YANG model described in this document
   also supports the mapping with TE tunnels for other VPN models such
   as L1VPN and L2VPN, etc.

   While IP/MPLS PNC is responsible for provisioning the VPN service on
   the PE nodes, the MDSC can coordinate how to map the VPN services
   with TE tunnels. This is consistent with the two of the core
   functions of the MDSC specified in [ACTN-Frame]:

     . Customer mapping/translation function: This function is to map
        customer requests/commands into network provisioning requests
        that can be sent to the Physical Network Controller (PNC)
        according to business policies provisioned statically or
        dynamically. Specifically, it provides mapping and translation
        of a customer's service request into a set of parameters that
        are specific to a network type and technology such that network
        configuration process is made possible.

     . Virtual service coordination function: This function translates
        customer service-related information into virtual network
        service operations in order to seamlessly operate virtual
        networks while meeting a customer's service requirements. In
        the context of ACTN, service/virtual service coordination
        includes a number of service orchestration functions such as
        multi-destination load balancing, guarantees of service


Lee, et al.              Expires October 2018                  [Page 3]


Internet-Draft             TE & Service Mapping              April 2018


        quality, bandwidth and throughput. It also includes
        notifications for service fault and performance degradation and
        so forth.


   In some cases, under the confines of service policy, dynamic TE
   tunnel creation may need to be supported for the VPN service. This
   may occur when there are no suitable existing TE tunnels that can
   support VPN service requirements. Or the operator would like to
   dynamically create and bind tunnels to the VPN, which could not be
   shared for network slicing.

   To summarize there are three mode of operations, but not limited to:

        o New VN/Tunnel Binding - Customer could request an L3VPN
          service [L3SM-YANG] with a new VN/Tunnel not shared with
          other existing services. This is to meet VPN isolation
          requirement. Further the mapping yang model described in
          Section 5 of this document is used to set this mapping
          between the L3VPN service and the ACTN VN. Note that this
          could be done dynamically. The VN (and TE tunnels) could be
          bound to the L3VPN and not used for any other VPN.

        o VN/Tunnel Selection - Customer could request an L3VPN service
          [L3SM-Yang], and with this model as input, the PNC configures
          the different network elements to deliver the service. Each
          network element would select a tunnel based on the
          configuration. With this mode, new tunnels (or VN) are not
          created for each VPN. Thus, the tunnels can be shared across
          multiple VPN. Further the mapping yang model described in
          Section 5 of this document is used to get the mapping between
          the L3VPN and the tunnels in use. No modification is allowed
          when an existing tunnel is selected.

        o VN/Tunnel Modify - This mode allows the modification of the
          properties of the existing VN/tunnel (e.g., bandwidth) when
          VN/Tunnel Selection Mode is applied.

   Other mode of operations could be easily added to the current model
   in the future.

   [Editor's note - A future version of the document can be updated to
   add more modes or policy.]

   The YANG model described in this document provides an ACTN TE-
   service mapping model that enables a seamless service mapping across
   L1/2/3 VPN, ACTN VN and TE-tunnel models at the controllers.


Lee, et al.              Expires October 2018                  [Page 4]


Internet-Draft             TE & Service Mapping              April 2018



2. L3VPN Architecture in ACTN context

   Figure 1 shows the architectural context of this document.



                                        | L3SM + TE-Svc + VN
                                        V
                                     +------+
                                     | MDSC |
                                     +------+
                                        |
                            +-------------------------------+
                            |               |               |
                            V               V               V
                         +--------+     +--------+    +--------+
                         |IP/MPLS |     | Transp.|    |IP/MPLS |
                         |  PNC 1 |     |   PNC  |    |  PNC 2 |
                         +--------+     +--------+    +--------+

                   CE                                                   CE
                    \     AS 100                          AS 200       /
                     \                                               /
                      A----B----C----ASBR1------ASBR2----D----E----F
                     /:   /    /:      /:         /:    /:   /:   /:
                    / :  /    / :     / :        / :   / :  / :  / :
             CE----G--:-H----I--:-ASBR3-:----ASBR4-:--J--:-K--:-L--:---CE
                   :  : :    :  :   :   :      :   :     : :  : :  :
                   :  : :    :  :   :   :      :   :     : :  : :  :
                   :  : :    :  :   :   :      :   :     : :  : :  :
                   :  M-:----:--P---:---S------:---U-----V-:--X-:--Y
                   : /  :    : /    :  /       :  /        : /  : /
                   :/   :    :/     : /        : /         :/   :/
                   N----O----Q-------R----------T----------W----Z
                                    Transport Network


     Figure 1: L3VPN Architecture from the IP+Optical Network Perspective



   There are three main entities in the architecture.

  . MDSC: This entity is responsible for coordinating a L3VPN service
     request (expressed in L3SM) with the IP PNC and the Transport PNC.



Lee, et al.              Expires October 2018                  [Page 5]


Internet-Draft             TE & Service Mapping              April 2018


     One of the key responsibilities of the MDSC for TE services is to
     coordinate with both the IP PNC and the Transport PNC for the
     mapping of L3VPN Service Model and ACTN VN model. With the VN/TE-
     tunnel binding case, the MDSC will need to coordinate with the
     Transport PNC to dynamically create the TE-tunnel(s) in the
     Transport network as needed. These tunnels are added as links in
     the IP Layer topology. The MDSC coordinates with IP PNC to create
     the TE-tunnel(s) in the IP layer, as part of the ACTN VN creation.

  . IP/MPLS PNC: This entity is responsible for device configuration
     to create PE-PE L3VPN tunnels for the VPN customer and for the
     configuration of the L3VPN VRF on the PE nodes. Each network
     element would select a tunnel based on the configuration.

  . Transport PNC: This entity is responsible for device configuration
     for TE tunnels in the transport networks.

   High-Level Control Flows

     1. Customer asks for a L3VPN between CE1 and CE2 with TE
        constraints using L3SM model. The customer can provide tunnel
        creation policy where it allows dynamic VN/TE tunnel creation
        or not. Under this policy, dynamic VN/TE tunnels can be created
        when there are no proper VN/TE-tunnels that can support L3VPN
        tunnels or when there is a strict isolation requirement for the
        VPN service, e.g., no sharing with other tunnels is allowed.

     2. The MDSC determines if it needs to create a new VN, and if that
        is the case, ACTN VN YANG [ACTN-VN-YANG] is used to configure a
        new VN based on this VPN and map the VPN service to ACTN VN. In
        case an existing tunnel is to be used, each device will select
        which tunnel to use and populates this mapping information.

     3. The MDSC interacts with both the IP/MPLS PNC and the Transport
        PNC to create a PE-PE tunnel in the IP network mapped to a TE
        tunnel in the transport network by providing the inter-layer
        access points and tunnel requirements. The specific service
        information are passed to the IP/MPLS PNC for the actual VPN
        configuration and activation.

          a. The Transport PNC creates the corresponding TE tunnel
             matching with the access point and egress point.
          b. The IP/MPLS PNC maps the VPN ID with the corresponding TE
             tunnel ID to bind these two IDs.

     4. The IP/MPLS PNC creates/updates a VRF instance for this VPN
        customer. This is not in the scope of this document..


Lee, et al.              Expires October 2018                  [Page 6]


Internet-Draft             TE & Service Mapping              April 2018



3. TE-Service Mapping Model

   The role of TE-service Mapping model is to create a binding
   relationship across L3SM, L2SM [L2SM-YANG] and L1CSM [L1CSM-YANG]
   and ACTN VN Model. The ACTN VN YANG model is a generic virtual
   network service model that allows customers (internal or external)
   to create a VN that meets the customer's service objective with
   various constraints via TE-topology model [TE-topo]. The TE-service
   mapping model is needed to bind LxVPN specific service model with
   TE-specific parameters. This binding will facilitate a seamless
   service operation with underlay-TE network visibility. The TE-
   service model developed in this document can also be extended to
   support other services beyond L3SM, L2SM and L1CSM.


         +---------+          +-------------+         +----------+
         |  L3SM   | <------> |             | <-----> | ACTN VN  |
         +---------+          |             |         |  Model   |
                              |             |         +----------+
                              |             |
         +---------+          | TE-Service  |         +----------+
         |  L2SM   | <------> |Mapping Model| <-----> | TE-Topo  |
         +---------+          |             |         |   Model  |
                              |             |         +----------+
                              |             |
         +---------+          |             |         +----------+
         |  L1CSM  | <------> |             | <-----> | TE-Tunnel|
         +---------+          |             |         |   Model  |
                              +-------------+         +----------+




            . . .



4. YANG Data Tree

module: ietf-te-service-mapping
    +--rw te-service-mapping
       +--rw service-mapping
       |  +--rw mapping-list* [map-id]
       |     +--rw map-id            uint32
       |     +--rw map-type?         map-type



Lee, et al.              Expires October 2018                  [Page 7]


Internet-Draft             TE & Service Mapping              April 2018


       |     +--rw (service)?
       |     |  +--:(l3vpn)
       |     |  |  +--rw l3vpn-ref?        -> /l3:l3vpn-svc/vpn-services/vpn-
service/vpn-id
       |     |  +--:(l2vpn)
       |     |  |  +--rw l2vpn-ref?        -> /l2:l2vpn-svc/vpn-services/vpn-
service/vpn-id
       |     |  +--:(l1vpn)
       |     |     +--rw l1vpn-ref?        -> /l1:l1cs/service/service-
list/subscriber-l1vc-id
       |     +--rw (te)?
       |        +--:(actn-vn)
       |        |  +--rw actn-vn-ref?      -> /vn:actn/vn/vn-list/vn-id
       |        +--:(te-topo)
       |        |  +--rw vn-topology-id?   te-types:te-topology-id
       |        |  +--rw abstract-node?    -> /nw:networks/network/node/node-
id
       |        +--:(te-tunnel)
       |           +--rw te-tunnel-list*   te:tunnel-ref
       +--rw site-mapping
          +--rw mapping-list* [map-id]
             +--rw map-id         uint32
             +--rw (service)?
             |  +--:(l3vpn)
             |  |  +--rw l3vpn-ref?     -> /l3:l3vpn-svc/sites/site/site-id
             |  +--:(l2vpn)
             |  |  +--rw l2vpn-ref?     -> /l2:l2vpn-svc/sites/site/site-id
             |  +--:(l1vpn)
             |     +--rw l1vpn-ref?     -> /l1:l1cs/access/uni-list/UNI-ID
             +--rw (te)?
                +--:(actn-vn)
                |  +--rw actn-vn-ref?   -> /vn:actn/ap/access-point-
list/access-point-id
                +--:(te)
                   +--rw ltp?           te-types:te-tp-id

5. Yang Data Model

   The YANG code is as follows:

   <CODE BEGINS> file "ietf-te-service-mapping@2018-04-05.yang"






Lee, et al.              Expires October 2018                  [Page 8]


Internet-Draft             TE & Service Mapping              April 2018



   module ietf-te-service-mapping {

       namespace "urn:ietf:params:xml:ns:yang:ietf-te-service-mapping";

       prefix "tm";

       import ietf-l3vpn-svc {
           prefix "l3";
       }

       import ietf-l2vpn-svc {
           prefix "l2";
       }

       import ietf-l1csm {
           prefix "l1";
       }

       import ietf-te-types {
           prefix "te-types";
       }

       import ietf-network {
           prefix "nw";
       }

       import ietf-te {
           prefix "te";
       }

       import ietf-actn-vn {
           prefix "vn";
       }

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

       contact
           "Editor: Young Lee <leeyoung@huawei.com>
                    Dhruv Dhody <dhruv.ietf@gmail.com>";
       description
           "This module contains a YANG module for the mapping of
           service (e.g. L3VPN) to the TE tunnels or ACTN VN.";


Lee, et al.              Expires October 2018                  [Page 9]


Internet-Draft             TE & Service Mapping              April 2018



       revision 2018-04-05 {
           description
               "initial version.";
           reference
               "TBD";
       }

       /*
        * Identities
        */
       identity service-type {
           description
               "Base identity from which specific service types are
               derived.";
       }

       identity l3vpn-service {
           base service-type;
           description
               "L3VPN service type.";
       }

       identity l2vpn-service {
           base service-type;
           description
               "L2VPN service type.";
       }

       identity l1vpn-service {
           base service-type;
           description
               "L1VPN connectivity service type.";
       }
       /*
        * Enum
        */
       typedef map-type {
           type enumeration {
               enum "new" {
                   description
                       "The new VN/tunnels are binded to the service";
               }
               enum "select" {
                   description


Lee, et al.              Expires October 2018                 [Page 10]


Internet-Draft             TE & Service Mapping              April 2018


                       "The VPN service selects an existing tunnel with no
modification";
               }
               enum "modify" {
                   description
                       "The VPN service selects an existing tunnel and allows
to modify the properties of the tunnel (e.g., b/w) ";
                  }
           }
           description
               "The map-type";
       }

       /*
        * Groupings
        */
       grouping service-ref{
           description
               "The reference to the service.";
            choice service {
               description
                   "The service";
               case l3vpn {
                   leaf l3vpn-ref {
                       type leafref {
                           path "/l3:l3vpn-svc/l3:vpn-services/"
                           + "l3:vpn-service/l3:vpn-id";
                       }
                       description
                           "The reference to L3VPN Service Yang Model";
                   }
               }
               case l2vpn {
                   leaf l2vpn-ref {
                       type leafref {
                           path "/l2:l2vpn-svc/l2:vpn-services/"
                           + "l2:vpn-service/l2:vpn-id";
                       }
                       description
                           "The reference to L2VPN Service Yang Model";
                   }

               }
               case l1vpn {
                   leaf l1vpn-ref {


Lee, et al.              Expires October 2018                 [Page 11]


Internet-Draft             TE & Service Mapping              April 2018


                       type leafref {
                           path "/l1:l1cs/l1:service/"
                           + "l1:service-list/l1:subscriber-l1vc-id";
                       }
                       description
                           "The reference to L1VPN Service Yang Model";
                   }

               }
            }
       }

       grouping site-ref {
           description
               "The reference to the site.";
            choice service {
               description
                   "The service choice";
               case l3vpn {
                   leaf l3vpn-ref{
                       type leafref {
                           path "/l3:l3vpn-svc/l3:sites/l3:site/"
                           + "l3:site-id";
                       }
                       description
                           "The reference to L3VPN Service Yang Model";
                   }
               }
               case l2vpn {
                   leaf l2vpn-ref{
                       type leafref {
                           path "/l2:l2vpn-svc/l2:sites/l2:site/"
                           + "l2:site-id";
                       }
                       description
                           "The reference to L2VPN Service Yang Model";
                   }

               }
               case l1vpn {
                   leaf l1vpn-ref{
                       type leafref {
                           path "/l1:l1cs/l1:access/l1:uni-list/"
                           + "l1:UNI-ID";
                       }


Lee, et al.              Expires October 2018                 [Page 12]


Internet-Draft             TE & Service Mapping              April 2018


                       description
                           "The reference to L1VPN Connectivity Service Yang
Model";
                   }

               }

            }
       }

       grouping te-ref {
           description
               "The reference to TE.";
           choice te {
               description
                   "The TE";
               case actn-vn {
                   leaf actn-vn-ref {
                       type leafref {
                           path "/vn:actn/vn:vn/vn:vn-list/vn:vn-id";
                       }
                       description
                           "The reference to ACTN VN";
                   }
               }
               case te-topo {
                  leaf vn-topology-id{
                      type te-types:te-topology-id;
                      description
                          "An identifier to the TE Topology Model
                           where the abstract nodes and links of
                           the Topology can be found for Type 2
                           VNS";
                  }
                  leaf abstract-node {
                    type leafref {
                      path "/nw:networks/nw:network/nw:node/"
                      + "nw:node-id";
                    }
                    description
                      "a reference to the abstract node in TE
                      Topology";
                  }
               }
               case te-tunnel {


Lee, et al.              Expires October 2018                 [Page 13]


Internet-Draft             TE & Service Mapping              April 2018


                   leaf-list te-tunnel-list {
                       type te:tunnel-ref;
                       description
                           "Reference to TE Tunnels";
                   }

               }

           }

       }

       grouping te-endpoint-ref {
           description
               "The reference to TE endpoints.";
           choice te {
               description
                   "The TE";
               case actn-vn {
                   leaf actn-vn-ref {
                       type leafref {
                           path "/vn:actn/vn:ap/vn:access-point-list"
                           + "/vn:access-point-id";
                       }
                       description
                           "The reference to ACTN VN";
                   }
               }
               case te {
                  leaf ltp {
                      type te-types:te-tp-id;
                      description
                          "Reference LTP in the TE-topology";
                  }
               }
           }

       }

       grouping service-mapping {
           description
               "Mapping between Services and TE";
           container service-mapping {
               description
                   "Mapping between Services and TE";


Lee, et al.              Expires October 2018                 [Page 14]


Internet-Draft             TE & Service Mapping              April 2018



               list mapping-list {
                   key "map-id";
                   description
                       "Mapping identified via a map-id";
                   leaf map-id {
                       type uint32;
                       description
                           "a unique mapping identifier";
                   }
                   leaf map-type {
                       type map-type;
                       description
                           "Tunnel Bind or Tunnel Selection";
                   }
                   uses service-ref;

                   uses te-ref;
               }
           }
       }
       grouping site-mapping {
           description
               "Mapping between VPN access site and TE
               endpoints or AP";
           container site-mapping {
               description
                   "Mapping between VPN access site and TE
                   endpoints or AP";
               list mapping-list {
                   key "map-id";
                   description
                       "Mapping identified via a map-id";
                   leaf map-id {
                       type uint32;
                       description
                           "a unique mapping identifier";
                   }
                   uses site-ref;

                   uses te-endpoint-ref;
               }

           }
       }


Lee, et al.              Expires October 2018                 [Page 15]


Internet-Draft             TE & Service Mapping              April 2018



       /*
        * Configuration data nodes
        */
       container te-service-mapping {
           description
               "Mapping between Services and TE";

           uses service-mapping;

           uses site-mapping;
       }


   }





   <CODE ENDS>


6. Security

   The configuration, state, and action data defined in this document
   are designed to be accessed via a management protocol with a secure
   transport layer, such as NETCONF [RFC6241].  The NETCONF access
   control model [RFC6536] provides the means to restrict access for
   particular NETCONF users to a preconfigured subset of all available
   NETCONF protocol operations and content.

   A number of configuration data nodes defined in this document are
   writable/deletable (i.e., "config true") These data nodes may be
   considered sensitive or vulnerable in some network environments.


7. IANA Considerations


   This document registers the following namespace URIs in the IETF XML
   registry [RFC3688]:

   --------------------------------------------------------------------


Lee, et al.              Expires October 2018                 [Page 16]


Internet-Draft             TE & Service Mapping              April 2018


   URI: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping
   Registrant Contact: The IESG.
   XML: N/A, the requested URI is an XML namespace.
   --------------------------------------------------------------------

   This document registers the following YANG modules in the YANG
   Module

   Names registry [RFC7950]:

   --------------------------------------------------------------------
   name:         ietf-te-service-mapping
   namespace:    urn:ietf:params:xml:ns:yang:ietf-te-service-mapping
   reference:    RFC XXXX (TDB)
   --------------------------------------------------------------------


8. Acknowledgements

   We thank Diego Caviglia and Igor Bryskin for useful discussions and
   motivation for this work.

9. References

9.1. Informative References

   [RFC4110] R. Callon and M. Suzuki, "A Framework for Layer 3
             Provider-Provisioned Virtual Private Networks (PPVPNs)",
             RFC 4110, July 2005.

   [RFC6020] M. Bjorklund, Ed., "YANG - A Data Modeling Language for
             the Network Configuration Protocol (NETCONF)", RFC 6020,
             October 2010.

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


Lee, et al.              Expires October 2018                 [Page 17]


Internet-Draft             TE & Service Mapping              April 2018



   [Restconf] A. Bierman, M. Bjorklund, and K. Watsen, "RESTCONF
             Protocol", draft-ietf-netconf-restconf, 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.

   [L3SM-YANG] S. Litkowski, L.Tomotaki, and K. Ogaki, "YANG Data Model
             for L3VPN service delivery", draft-ietf-l3sm-l3vpn-
             service-model, work in progress.

   [L2SM-YANG] B. Wen, et al, "A YANG Data Model for L2VPN Service
             Delivery", draft-ietf-l2sm-l2vpn-service-model, work in
             progress.

   [L1CSM-YANG] G. Fioccola, et al, "A Yang Data Model for L1
             Connectivity Service Model (L1CSM)", draft-fioccola-ccamp-
             l1csm-yang, work in progress.



10. Contributors


Authors' Addresses

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

   Email: leeyoung@huawei.com

   Dhruv Dhody


Lee, et al.              Expires October 2018                 [Page 18]


Internet-Draft             TE & Service Mapping              April 2018


   Huawei Technologies

   Email: dhruv.ietf@gmail.com

   Daniele Ceccarelli
   Ericsson
   Torshamnsgatan,48
   Stockholm, Sweden

   Email: daniele.ceccarelli@ericsson.com

   Jeff Tantsura
   Nuage

   EMail: jefftant@gmail.com

   Giuseppe Fioccola
   Telecom Italia
   Email: giuseppe.fioccola@telecomitalia.it





























Lee, et al.              Expires October 2018                 [Page 19]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/