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

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 draft-ietf-teas-te-service-mapping-yang

TEAS WG                                                       Young Lee
Internet Draft                                              Dhruv Dhody
Intended status: standard track                                  Huawei
Expires: June 30, 2019
                                                     Daniele Ceccarelli
                                                               Ericsson

                                                          Jeff Tantsura
                                                                 Apstra

                                                      Giuseppe Fioccola
                                                                 Huawei

                                                                 Qin Wu
                                                                 Huawei

                                                      December 30, 2018


           Traffic Engineering and Service Mapping Yang Model


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

Abstract

   This document provides a YANG data model to map customer service
   models (e.g., the L3VPM Service Model) to Traffic Engineering (TE)
   models (e.g., the TE Tunnel or the Abstraction and Control of
   Traffic Engineered Networks Virtual Network model). This model is
   referred to as TE Service Mapping Model and is applicable
   generically to the operator's need for seamless control and
   management of their VPN services with TE tunnel support.

   The model is principally used to allow monitoring and diagnostics of
   the management systems to show how the service requests are mapped
   onto underlying network resource and TE models.

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.






Lee, et al.               Expires June 2019                    [Page 1]


Internet-Draft             TE & Service Mapping           December 2018


   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on June 30, 2019.

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...................................................3
      1.1. Terminology...............................................4
      1.2. Tree diagram..............................................4
      1.3. Prefixes in Data Node Names...............................4
   2. TE & Service Related Parameters................................5
      2.1. VN/Tunnel Selection Requirements..........................5
      2.2. Availability Requirement..................................7
   3. YANG Modeling Approach.........................................7
      3.1. Forward Compatibility.....................................8
   4. L3VPN Architecture in the ACTN Context.........................8
      4.1. Service Mapping..........................................11
      4.2. Site Mapping.............................................12
   5. Applicability of TE-Service Mapping in Generic context........12
   6. YANG Data Trees...............................................13



Lee, et al.               Expires June 2019                   [Page 2]


Internet-Draft             TE & Service Mapping           December 2018


   7. YANG Data Models..............................................14
   8. Security......................................................24
   9. IANA Considerations...........................................24
   10. Acknowledgements.............................................26
   11. References...................................................26
      11.1. Informative References..................................26
   12. Contributors.................................................27
   Authors' Addresses...............................................27

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
   network devices, protocol instances, and network services. YANG data
   models have been classified in [RFC8199] and [RFC8309].

   Framework for Abstraction and Control of Traffic Engineered Networks
   (ACTN) [RFC8453] introduces an architecture to support virtual
   network services and connectivity services. [ACTN-VN-YANG] defines a
   YANG model and describes how customers or end-to-end orchestrators
   can request and/or instantiate a generic virtual network service.
   [ACTN-Applicability] describes the way IETF YANG models of different
   classifications can be applied to the ACTN interfaces. In
   particular, it describes how customer service models can be mapped
   into the CNC-MDSC Interface (CMI) of the ACTN architecture.

   The models presented in this document are also applicable in generic
   context [RFC8309] as part of Customer Service Model used between
   Service Orchestrator and Customer.

   [RFC8299] provides a L3VPN service delivery YANG model for PE-based
   VPNs. The scope of that draft is limited to a set of domains under
   control of the same network operator to deliver services requiring
   TE tunnels.

   [L2SM] provides a L2VPN service delivery YANG model for PE-based
   VPNs. The scope of that draft is limited to a set of domains under
   control of the same network operator to deliver services requiring
   TE tunnels.

   [L1CSM] provides a L1 connectivity service delivery YANG model for
   PE-based VPNs. The scope of that draft is limited to a set of
   domains under control of the same network operator to deliver
   services requiring TE tunnels.



Lee, et al.               Expires June 2019                   [Page 3]


Internet-Draft             TE & Service Mapping           December 2018


   While the IP/MPLS Provisioning Network Controller (PNC) is
   responsible for provisioning the VPN service on the Provider Edge
   (PE) nodes, the Multi-Domain Service Coordinator (MDSC) can
   coordinate how to map the VPN services onto Traffic Engineering (TE)
   tunnels. This is consistent with the two of the core functions of
   the MDSC specified in [RFC8453]:

     . Customer mapping/translation function: This function is to map
        customer requests/commands into network provisioning requests
        that can be sent to the PNC according to the business policies
        that have been 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 the 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
        quality, bandwidth and throughput. It also includes
        notifications for service fault and performance degradation and
        so forth.

   Section 2 describes a set of TE & service related parameters that
   this document addresses as new and advanced parameters that are not
   included in generic service models. Section 3 discusses YANG
   modeling approach.

1.1. Terminology

   Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used
   in this document.

1.2. Tree diagram

   A simplified graphical representation of the data model is used in
   Section 5 of this this document.  The meaning of the symbols in
   these diagrams is defined in [RFC8340].

1.3. Prefixes in Data Node Names

   In this document, names of data nodes and other data model objects
   are prefixed using the standard prefix associated with the


Lee, et al.               Expires June 2019                   [Page 4]


Internet-Draft             TE & Service Mapping           December 2018


   corresponding YANG imported modules, as shown in Table 1.

      +---------+------------------------------+-----------------+
      | Prefix  | YANG module                  | Reference       |
      +---------+------------------------------+-----------------+
      |tsm-types| ietf-te-service-mapping-types| [RFCXXXX}       |
      |l1       | ietf-l1csm                   | [L1CSM]         |
      |l2vpn-svc| ietf-l2vpn-svc               | [L2SM]          |
      |l3vpn-svc| ietf-l3vpn-svc               | [RFC8299]       |
      |l1-tsm   | ietf-l1csm-te-service-mapping| [RFCXXXX]       |
      |l2-tsm   | ietf-l2sm-te-service-mapping | [RFCXXXX]       |
      |l3-tsm   | ietf-l3sm-te-service-mapping | [RFCXXXX]       |
      |vn       | ietf-vn                      | [ACTN-VN]       |
      |nw       | ietf-network                 | [RFC8345]       |
      |te-types | ietf-te-types                | [TE-Types]      |
      |te-topo  | ietf-te-topology             | [TE-Topo]       |
      |te       | ietf-te                      | [TE-Tunnel]     |
      +---------+------------------------------+-----------------+

             Table 1: Prefixes and corresponding YANG modules

   Note: The RFC Editor will replace XXXX with the number assigned to
   the RFC once this draft becomes an RFC.



2. TE & Service Related Parameters

   While L1/2/3 service models [L1CSM, L2SM, L3SM] are intended to
   provide service-specific parameters for VPN service instances, there
   are a number of TE & Service related parameters that are not
   included in the generic service models.

   Additional service parameters and policies that are not included in
   the aforementioned service models are addressed in the YANG models
   defined in this document.

2.1. VN/Tunnel Selection Requirements

   In some cases, the service requirements may need addition TE tunnels
   to be established. This may occur when there are no suitable
   existing TE tunnels that can support the service requirements, or
   when the operator would like to dynamically create and bind tunnels
   to the VPN such that they are not shared by other VPNs, for example,
   for network slicing. The establishment of TE tunnels is subject to
   the network operator's policies.



Lee, et al.               Expires June 2019                   [Page 5]


Internet-Draft             TE & Service Mapping           December 2018


   To summarize, there are three modes of VN/Tunnel selection
   operations to be supported as follows. Additional modes may be
   defined in the future.

        o New VN/Tunnel Binding - A customer could request a VPN
          service based on VN/Tunnels that are not shared with other
          existing or future services. This might be to meet VPN
          isolation requirements. Further, the YANG model described in
          Section 5 of this document can be used to describe the
          mapping between the VPN service and the ACTN VN. The VN (and
          TE tunnels) could be bound to the VPN and not used for any
          other VPN.

          Under this mode, the following sub-categories can be
          supported:

          1. Hard Isolation with deterministic characteristics: A
             customer could request a VPN service using a set of TE
             Tunnels with deterministic characteristics requirements
             (e.g., no latency variation) and where that set of TE
             Tunnels must not be shared with other VPN services and
             must not compete for bandwidth or other network resources
             with other TE Tunnels.

          2. Hard Isolation: This is similar to the above case but
             without the deterministic characteristics requirements.

          3. Soft Isolation: The customer requests a VPN service using
             a set of TE tunnels which can be shared with other VPN
             services.

        o VN/Tunnel Sharing - A customer could request a VPN service
          where new tunnels (or a VN) do not need to be created for
          each VPN and can be shared across multiple VPNs. Further, the
          mapping YANG model described in Section 5 of this document
          can be used to describe the mapping between the VPN service
          and the tunnels in use. No modification of the properties of
          a tunnel (or VN) is allowed in this mode: an existing tunnel
          can only be selected.

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







Lee, et al.               Expires June 2019                   [Page 6]


Internet-Draft             TE & Service Mapping           December 2018


2.2. Availability Requirement

   Availability is another service requirement or intent that may
   influence the selection or provisioning of TE tunnels or a VN to
   support the requested service. Availability is a probabilistic
   measure of the length of time that a VPN/VN instance functions
   without a network failure.

   The availability level will need to be translated into network
   specific policies such as the protection/reroute policy associated
   with a VN or Tunnel. The means by which this is achieved is not in
   the scope of this draft.

3. YANG Modeling Approach

   This section provides how the TE & Service mapping parameters are
   supported using augmentation of the existing service models (i.e.,
   [L1CSM], [L2SM], and [L3SM]). Figure 1 shows the scope of the
   Augmented LxSM Model.



   +--------------+        +----------------------------+           +----------+
   |    LxSM      |o-------|                            | . . . . . | ACTN VN  |
   +--------------+ augment|                            |           +----------+
                           |                            |           +----------+
   +--------------+        |    Augmented LxSM Model    | . . . . . | TE-topo  |
   | TE & Service |------->|                            |           +----------+
   | Mapping Types| import |                            |           +----------+
   +--------------+        |                            | . . . . . | TE-tunnel|
                           +----------------------------+ reference +----------+



                      Figure 1. Augmented LxSM Model

   The Augmented LxSM model (where x=1,2,3) augments the basic LxSM
   model while importing the common TE & Service related parameters
   (defined in Section 2) grouping information from TE & Service
   Mapping Types. The TE & Service Mapping Types (ietf-te-service-
   mapping-types) module is the repository of all common groupings
   imported by each augmented LxSM model. Any future service models
   would import this grouping file.

   The role of the augmented LxSm service model is to expose the
   mapping relationship between service models and TE models so that
   VN/VPN service instantiations provided by the underlying TE networks


Lee, et al.               Expires June 2019                   [Page 7]


Internet-Draft             TE & Service Mapping           December 2018


   can be viewed outside of the MDSC, for example by an operator who is
   diagnosing the behavior of the network. It also allows for the
   customers to access operational state information about how their
   services are instantiated with the underlying VN, TE topology or TE
   tunnels provided that the MDSC operator is willing to share that
   information. This mapping will facilitate a seamless service
   management operation with underlay-TE network visibility.

   As seen in Figure 1, the augmented LxSM service model records a
   mapping between the customer service models and the ACTN VN YANG
   model. Thus, when the MDSC receives a service request it creates a
   VN that meets the customer's service objectives with various
   constraints via TE-topology model [TE-topo], and this relationship
   is recorded by the Augmented LxSM Model. The model also supports a
   mapping between a service model and TE-topology or a TE-tunnel.

3.1. Forward Compatibility

   The YANG module defined in this document supports three existing
   service models via augmenting while sharing the common TE & Service
   Mapping Types.

   It is possible that new service models will be defined at some
   future time and that it will be desirable to map them to underlying
   TE constructs in the same way as the three existing models are
   augmented.


4. L3VPN Architecture in the ACTN Context

   Figure 2 shows the architectural context of this document
   referencing the ACTN components and interfaces.



                              +----------------------------+
                              |  Customer Service Manager  |
                              |  +-----------------------+ |
                              |  |           CNC         + |
                              |  +-+-------------------+-+ |
                              +----|-------------------|---+
                                   |                   |
                                   |CMI(Augmented L3SM)|CMI(VN)
                                   |                   |
                  +----------------|-------------------|----+
                  | +--------------|-----------------+ |    |
                  | | MDSC         |                 | |    |


Lee, et al.               Expires June 2019                   [Page 8]


Internet-Draft             TE & Service Mapping           December 2018


                  | |              |                 | |    |
                  | |  +-----------+--------------+  | |    |
      TE-Svc-Map<------+ Service Mapping Function |  | |    |
                  | |  +-----------+--------------+  | |    |
                  | |              |                 | |    |
                  | +-------+------|-----------------+ |    |
                  |         |      |                   |    |
                  |         |      |CMI(VN)            |    |
                  |         |      |                   |    |
                  |         |   +--|-------------------|--+ |
                  |         |   |  |        MDSC       |  | |
                  |         |   | ++-------------------++ | |
                  |         |   | +   Service Mapping   +---->TE-Svc-Map
                  |         |   | ++----------+---------+ | |
                  |         |   +--|----------|-----------+ |
                  +---------|------|----------|-------------+
                            |      |          |
                            | +----+--------+ |
                            | |             | |
        MPI(VPN / TE models)| |             | |MPI(TE / L1 models)
                            | |             | |
                      +-----|-|---+   +-----|-|----+
           IP/MPLS    |  +--+-+-+ |   |  +--+-+-+  | Optical Domain
           Domain     |  | PNC1 | |   |  | PNC2 |  | Controller
           Controller |  +--+---+ |   |  +--+---+  |
                      +-----|-----+   +-----|------+
                            |               |
                            V               | SBI
                +---------------------+     |
               /    IP/MPLS Network    \    |
              +-------------------------+   |
                                            V
                                 +---------------------+
                                /    Optical Network    \
                               +-------------------------+

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

   There are three main entities in the ACTN architecture and shown in
   Figure 2.

  . CNC: The Customer Network Controller is responsible for generating
     service requests. In the context of an L3VPN, the CNC uses the
     Augmented L3SM to express the service request and communicate it
     to the network operator.




Lee, et al.               Expires June 2019                   [Page 9]


Internet-Draft             TE & Service Mapping           December 2018


  . MDSC: This entity is responsible for coordinating a L3VPN service
     request (expressed via the Augmented L3SM) with the IP/MPLS PNC
     and the Transport PNC. For TE services, one of the key
     responsibilities of the MDSC is to coordinate with both the IP PNC
     and the Transport PNC for the mapping of the Augmented L3VPN
     Service Model to the ACTN VN model. In the VN/TE-tunnel binding
     case, the MDSC will need to coordinate with the Transport PNC to
     dynamically create the TE-tunnels in the transport network as
     needed. These tunnels are added as links in the IP/MPLS Layer
     topology. The MDSC coordinates with IP/MPLS PNC to create the TE-
     tunnels in the IP/MPLS layer, as part of the ACTN VN creation.
  . PNC: The Provisioning Network Controller is responsible for
     configuring and operating the network devices. Figure 2 shows two
     distinct PNCs.
       o IP/MPLS PNC (PNC1): 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.
       o Transport PNC (PNC2): This entity is responsible for device
          configuration for TE tunnels in the transport networks.

   There are four main interfaces shown in Figure 2.

   . CMI: The CNC-MDSC Interface is used to communicate service
     requests from the customer to the operator. The requests may be
     expressed as Augmented VPN service requests (L2SM, L3SM), as
     connectivity requests (L1CSM), or as virtual network requests
     (ACTN VN).
   . MPI: The MDSC-PNC Interface is used by the MDSC to orchestrate
     networks under the control of PNCs. The requests on this interface
     may use TE tunnel models, TE topology models, VPN network
     configuration models or layer one connectivity models.
   . SBI: The Southbound Interface is used by the PNC to control
     network devices and is out of scope for this document.
   . The TE Service Mapping Model as described in this document can be
     used to see the mapping between service models and VN models and
     TE Tunnel/Topology models. That mapping may occur in the CNC if a
     service request is mapped to a VN request. Or it may occur in the
     MDSC where a service request is mapped to a TE tunnel, TE
     topology, or VPN network configuration model. The TE Service
     Mapping Model may be read from the CNC or MDSC to understand how
     the mapping has been made and to see the purpose for which network
     resources are used.





Lee, et al.               Expires June 2019                  [Page 10]


Internet-Draft             TE & Service Mapping           December 2018


   As shown in Figure 2, the MDSC may be used recursively. For example,
   the CNC might map a L3SM request to a VN request that it sends to a
   recursive MDSC.

   The high-level control flows for one example are as follows:

   1. A customer asks for an L3VPN between CE1 and CE2 using the
     Augmented L3SM model.

   2. The MDSC considers the service request and local policy to
     determine if it needs to create a new VN or any TE Topology, 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
     the ACTN VN. In case an existing tunnel is to be used, each device
     will select which tunnel to use and populate 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
     is 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.

4.1. Service Mapping

   Augmented L3SM and L2SM can be used to request VPN service creation
   including the creation of sites and corresponding site network
   access connection between CE and PE. A VPN-ID is used to identify
   each VPN service ordered by the customer. The ACTN VN can be used
   further to establish PE-to-PE connectivity between VPN sites
   belonging to the same VPN service. A VN-ID is used to identify each
   virtual network established between VPN sites.

   Once the ACTN VN has been established over the TE network (maybe a
   new VN, maybe modification of an existing VN, or maybe the use of an
   unmodified existing VN), the mapping between the VPN service and the
   ACTN VN service can be created.



Lee, et al.               Expires June 2019                  [Page 11]


Internet-Draft             TE & Service Mapping           December 2018


4.2. Site Mapping

   The elements in Augmented L3SM and L2SM define site location
   parameters and constraints such as distance and access diversity
   that can influence the placement of network attachment points (i.e,
   virtual network access points (VNAP)). To achieve this, a central
   directory can be set up to establish the mapping between location
   parameters and constraints and network attachment point location.
   Suppose multiple attachment points are matched, the management
   system can use constraints or other local policy to select the best
   candidate network attachment points.

   After a network attachment point is selected, the mapping between
   VPN site and VNAP can be established as shown in Table 1.

   +------+---------+------------------+----------------------+-------+
   |      |         |     Location     |  Access Diversity    |  PE   |
   |      |  Site   |                  |                      |       |
   |Site  | Network | (Address, Postal | (Constraint-Type,    |       |
   |      | Access  |  Code, State,    |  Group-id,Target     |       |
   |      |         |  City,Country    |  Group-id)           |       |
   |      |         |  Code)           |                      |       |
   +------+---------+------------------+----------------------+-------+
   |      |         |                  |                      |       |
   |SITE1 | ACCESS1 | (,,US,NewYork,)  |(10,PE-Diverse,10)    |  PE1  |
   +------+---------+------------------+----------------------+-------+
   |SITE2 | ACCESS2 | (,,CN,Beijing,)  |(10,PE-Diverse,10)    |  PE2  |
   +------+---------+------------------+----------------------+-------+
   |SITE3 | ACCESS3 | (,,UK,London, )  |(12,same-PE,12)       |  PE4  |
   +------+---------+------------------+----------------------+-------+
   |SITE4 | ACCESS4 | (,,FR,Paris,)    |(20,Bearer-Diverse,20)|  PE7  |
   +------+---------+------------------+----------------------+-------+

                Table 1 : Mapping Between VPN Site and VNAP


5. Applicability of TE-Service Mapping in Generic context


   As discussed in the Introduction Section, the models presented in
   this document are also applicable generically outside of the ACTN
   architecture. [RFC8309] defines Customer Service Model between
   Customer and Service Orchestrator and Service Delivery Model between
   Service Orchestrator and Network Orchestrator(s). TE-Service mapping
   models defined in this document can be regarded primarily as
   Customer Service Model and secondarily as Service Deliver Model.



Lee, et al.               Expires June 2019                  [Page 12]


Internet-Draft             TE & Service Mapping           December 2018


6. YANG Data Trees


module: ietf-l1csm-te-service-mapping
  augment /l1:l1-connectivity/l1:services/l1:service:
    +-rw te-service-mapping!
  augment /l1:l1-connectivity/l1:services/l1:service:
    +-rw te-mapping
       +-rw map-type?               identityref
       +-rw availability-type?      identityref
       +-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
  augment /l1:l1-connectivity/l1:services/l1:service/l1:endpoint-1:
    +-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
  augment /l1:l1-connectivity/l1:services/l1:service/l1:endpoint-2:
    +-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



module: ietf-l2sm-te-service-mapping
  augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services/l2vpn-svc:vpn-service:
    +-rw te-service-mapping!
  augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services/l2vpn-svc:vpn-service:
    +-rw te-mapping
       +-rw map-type?               identityref
       +-rw availability-type?      identityref
       +-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



Lee, et al.               Expires June 2019                  [Page 13]


Internet-Draft             TE & Service Mapping           December 2018


  augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site/l2vpn-svc:site-network-
accesses/l2vpn-svc:site-network-access:
    +-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



   module: ietf-l3sm-te-service-mapping
     augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services/l3vpn-svc:vpn-service:
       +-rw te-service-mapping!
     augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services/l3vpn-svc:vpn-service:
       +-rw te-mapping
          +-rw map-type?               identityref
          +-rw availability-type?      identityref
          +-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
     augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site/l3vpn-svc:site-
   network-accesses/l3vpn-svc:site-network-access:
       +-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



7. YANG Data Models

   The YANG codes are as follows:

   <CODE BEGINS> file "ietf-te-service-mapping-types@2018-12-30.yang"

   module ietf-te-service-mapping-types {

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

          prefix "tsm";

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


Lee, et al.               Expires June 2019                  [Page 14]


Internet-Draft             TE & Service Mapping           December 2018


          }

          import ietf-network {
              prefix "nw";
          }

          import ietf-te {
              prefix "te";
          }

          import ietf-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>
                      Qin Wu <bill.wu@huawei.com>";
          description
              "This module contains a YANG module for TE & Service mapping
            parameters and policies as a common grouping applicable to
            variuous service models (e.g., L1CSM, L2SM, L3SM, etc.)";

          revision 2018-12-30 {
              description
                  "initial version.";
              reference
                  "TBD";
          }


          /*
           * Identity for map-type
           */
         identity map-type {
            description
            "Base identity from which specific map types are
             derived.";
         }

         identity new {
            base map-type;
            description
              "The new VN/tunnels are binded to the service.";
         }



Lee, et al.               Expires June 2019                  [Page 15]


Internet-Draft             TE & Service Mapping           December 2018



         identity detnet-hard-isolation {
            base new;
            description
              "Hard isolation with deterministic characteristics.";
         }

         identity hard-isolation {
            base new;
            description
              "Hard isolation.";
         }

         identity soft-isolation {
            base new;
            description
              "Soft-isolation.";
         }

         identity select {
            base map-type;
            description
              "The VPN service selects an existing tunnel with no
               modification.";
         }

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

          /*
           * Identity for availability-type
           */
         identity availability-type {
            description
              "Base identity from which specific map types are
               derived.";
         }

         identity level-1 {
            base availability-type;
            description
              "level 1: 99.9999%";
         }

         identity level-2 {



Lee, et al.               Expires June 2019                  [Page 16]


Internet-Draft             TE & Service Mapping           December 2018


            base availability-type;
            description
              "level 2: 99.999%";
         }

         identity level-3 {
            base availability-type;
            description
              "level 3: 99.99%";
         }

         identity level-4 {
            base availability-type;
            description
              "level 4: 99.9%";
         }

         identity level-5 {
            base availability-type;
            description
              "level 5: 99%";
         }

          /*
           * Groupings
           */

         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



Lee, et al.               Expires June 2019                  [Page 17]


Internet-Draft             TE & Service Mapping           December 2018


                              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 {
                      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";
                    }
                 }
              }



Lee, et al.               Expires June 2019                  [Page 18]


Internet-Draft             TE & Service Mapping           December 2018



          }

          grouping te-mapping {
              description
                  "Mapping between Services and TE";
              container te-mapping {
                  description
                      "Mapping between Services and TE";
                  leaf map-type {
                     type identityref {
             base map-type;
                }
                     description
                       "Isolation Requirements, Tunnel Bind or
                        Tunnel Selection";
                  }
                  leaf availability-type {
                     type identityref {
                       base availability-type;
                     }
                     description
                       "Availability Requirement for the Service";
                  }
                  uses te-ref;
              }
          }

   }
   <CODE ENDS>


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



      module ietf-l1csm-te-service-mapping {

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

          prefix "tm";

          import ietf-te-service-mapping-types {
             prefix "tsm-types";
         }

         import ietf-l1csm {
              prefix "l1";
          }


Lee, et al.               Expires June 2019                  [Page 19]


Internet-Draft             TE & Service Mapping           December 2018



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

          contact
              "Editor: Young Lee <leeyoung@huawei.com>
                       Dhruv Dhody <dhruv.ietf@gmail.com>
             Qin Wu <bill.wu@huawei.com>";
          description
              "This module contains a YANG module for the mapping of
              Layer 1 Connectivity Service Module (L1CSM) to the TE and VN ";

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

          /*
           * Configuration data nodes
           */
          augment "/l1:l1-connectivity/l1:services/l1:service" {
            description
              "l1csm augmented to include TE parameters and mapping";
            container te-service-mapping {
               presence "indicates l1 service to te mapping";
               description
                 "Container to augment l1csm to TE parameters and mapping";
             }
          }

          augment "/l1:l1-connectivity/l1:services/l1:service" {
             description
               "This augment is only valid for TE mapping --
               te mapping is added";
             uses tsm-types:te-mapping;
          }

          augment "/l1:l1-connectivity/l1:services/l1:service/l1:endpoint-1" {
            description
               "This augment is only valid for TE mapping --
                endpoint-1 te-reference is added";
            uses tsm-types:te-endpoint-ref;
          }

          augment "/l1:l1-connectivity/l1:services/l1:service/l1:endpoint-2" {
            description



Lee, et al.               Expires June 2019                  [Page 20]


Internet-Draft             TE & Service Mapping           December 2018


              "This augment is only valid for TE mapping --
              endpoint-2 te-reference is added";
            uses tsm-types:te-endpoint-ref;
          }
      }


   <CODE ENDS>


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



      module ietf-l2sm-te-service-mapping {

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

          prefix "tm";

          import ietf-te-service-mapping-types {
            prefix "tsm-types";
          }

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

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

          contact
              "Editor: Young Lee <leeyoung@huawei.com>
                       Dhruv Dhody <dhruv.ietf@gmail.com>
                     Qin Wu <bill.wu@huawei.com>";
          description
              "This module contains a YANG module for the mapping of
              Layer 2 Service Model (L1CSM) to the TE and VN ";

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



Lee, et al.               Expires June 2019                  [Page 21]


Internet-Draft             TE & Service Mapping           December 2018


          /*
           * Configuration data nodes
           */
        augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services/l2vpn-svc:vpn-service" {
            description
              "l2sm augmented to include TE parameters and mapping";
            container te-service-mapping {
               presence "indicates l2 service to te mapping";
               description
                 "Container to augment l2sm to TE parameters and mapping";
             }
        }

        augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services/l2vpn-svc:vpn-service" {
            description
              "This augment is only valid for TE mapping --
               te mapping is added";
            uses tsm-types:te-mapping;
        }

        augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site"
            +"/l2vpn-svc:site-network-accesses/l2vpn-svc:site-network-access" {
              description
                 "This augment is only valid for TE mapping --
                  network-access te-reference is added";
              uses tsm-types:te-endpoint-ref;
          }
      }



   <CODE ENDS>


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




   module ietf-l3sm-te-service-mapping {

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

       prefix "tm";

       import ietf-te-service-mapping-types {
         prefix "tsm-types";


Lee, et al.               Expires June 2019                  [Page 22]


Internet-Draft             TE & Service Mapping           December 2018


       }

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

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

       contact
           "Editor: Young Lee <leeyoung@huawei.com>
                    Dhruv Dhody <dhruv.ietf@gmail.com>
                   Qin Wu <bill.wu@huawei.com>";
       description
           "This module contains a YANG module for the mapping of
           Layer 3 Service Model (L3SM) to the TE and VN ";

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

       /*
        * Configuration data nodes
        */
       augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services/l3vpn-svc:vpn-service" {
         description
            "l3sm augmented to include TE parameters and mapping";
         container te-service-mapping {
            presence "indicates l3 service to te mapping";
            description
              "Container to augment l3sm to TE parameters and mapping";
         }
       }

       augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services/l3vpn-svc:vpn-service" {
          description
            "This augment is only valid for TE mapping --
             te mapping is added";
          uses tsm-types:te-mapping;
       }

       augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site"
         +"/l3vpn-svc:site-network-accesses/l3vpn-svc:site-network-access" {


Lee, et al.               Expires June 2019                  [Page 23]


Internet-Draft             TE & Service Mapping           December 2018


         description
            "This augment is only valid for TE mapping --
             network-access te-reference is added";
         uses tsm-types:te-endpoint-ref;
       }
   }


   <CODE ENDS>

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

9. IANA Considerations

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

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

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

   --------------------------------------------------------------------
   URI: urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping
   Registrant Contact: The IESG.


Lee, et al.               Expires June 2019                  [Page 24]


Internet-Draft             TE & Service Mapping           December 2018


   XML: N/A, the requested URI is an XML namespace.
   --------------------------------------------------------------------

   --------------------------------------------------------------------
   URI: urn:ietf:params:xml:ns:yang:ietf-l3sm-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-types
   namespace:    urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-
   types
   reference:    RFC XXXX (TDB)
   --------------------------------------------------------------------

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

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

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


Lee, et al.               Expires June 2019                  [Page 25]


Internet-Draft             TE & Service Mapping           December 2018



10. Acknowledgements

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

11. References

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

   [RFC8309] Q. Wu, W. Liu and A. Farrel, "Service Models Explained",
             RFC 8309, January 2018.

   [RFC8199] D. Bogdanovic, B. Claise, and C. Moberg, "YANG Module
             Classification", RFC 8199, July 2017.

   [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
             and A. Bierman, Ed., "Network Configuration Protocol
             (NETCONF)", RFC 6241.

   [RFC8453] D. Cecarelli and Y. Lee, "Framework for Abstraction and
             Control of Traffic Engineered Networks", RFC 8453, August
             2018.

   [TE-Topo] 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.

   [TE-Types] T. Saad (Editor), "Traffic Engineering Common YANG
             Types", draft-ietf-teas-yang-te-types, 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.





Lee, et al.               Expires June 2019                  [Page 26]


Internet-Draft             TE & Service Mapping           December 2018


   [ACTN-Applicability] Y. Lee, et al, "Applicability of YANG models
             for Abstraction and Control of Traffic Engineered
             Networks, draft-ietf-teas-actn-yang, work in progress.

   [RFC8299] Q. Wu, S. Litkowski, L.Tomotaki, and K. Ogaki, "YANG Data
             Model for L3VPN service delivery", RFC 8299, January 2018.

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

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

12. Contributors

   Adrian Farrel
   Old Dog Consulting

   Email: adrian@olddog.co.uk

   Italo Busi
   Huawei Technologies

   Email: Italo.Busi@huawei.com

Authors' Addresses

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

   Email: leeyoung@huawei.com

   Dhruv Dhody
   Huawei Technologies

   Email: dhruv.ietf@gmail.com






Lee, et al.               Expires June 2019                  [Page 27]


Internet-Draft             TE & Service Mapping           December 2018



   Daniele Ceccarelli
   Ericsson
   Torshamnsgatan,48
   Stockholm, Sweden

   Email: daniele.ceccarelli@ericsson.com

   Jeff Tantsura
   Apstra

   EMail: jefftant@gmail.com

   Giuseppe Fioccola
   Huawei
   Email: giuseppe.fioccola@huawei.com

   Qin Wu
   Huawei
   Email: bill.wu@huawei.com




























Lee, et al.               Expires June 2019                  [Page 28]


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