draft-ietf-teas-te-service-mapping-yang-07 - Traffic Engineering (TE) and Service Mapping Yang Model

Traffic Engineering (TE) and Service Mapping Yang Model
draft-ietf-teas-te-service-mapping-yang-07

Document
Type
Active Internet-Draft (teas WG)
Authors
Young Lee , Dhruv Dhody , Giuseppe Fioccola , Qin Wu , Daniele Ceccarelli , Jeff Tantsura
Last updated
2021-02-21
Replaces
draft-lee-teas-te-service-mapping-yang
Stream
Internet Engineering Task Force (IETF)
Intended RFC status
(None)
Formats
plain text xml pdf htmlized (tools) htmlized bibtex
Yang Validation
☯ 0 errors, 19 warnings.
Additional Resources
- Yang catalog entry for ietf-l1csm-te-service-mapping@2020-11-02.yang
- Yang catalog entry for ietf-l2nm-te-service-mapping@2020-11-02.yang
- Yang catalog entry for ietf-l2sm-te-service-mapping@2020-11-02.yang
- Yang catalog entry for ietf-l3nm-te-service-mapping@2020-11-02.yang
- Yang catalog entry for ietf-l3sm-te-service-mapping@2020-11-02.yang
- Yang catalog entry for ietf-te-service-mapping-types@2020-11-02.yang
- Yang impact analysis for draft-ietf-teas-te-service-mapping-yang
- Mailing list discussion
Stream
WG state
WG Document
Document shepherd
No shepherd assigned
IESG
IESG state
I-D Exists
Consensus Boilerplate
Unknown
Telechat date
Responsible AD
(None)
Send notices to
(None)
Email authors Email WG IPR References Referenced by Nits
TEAS Working Group                                           Y. Lee, Ed.
Internet-Draft                                       Samsung Electronics
Intended status: Standards Track                           D. Dhody, Ed.
Expires: August 25, 2021                                     G. Fioccola
                                                              Q. Wu, Ed.
                                                     Huawei Technologies
                                                           D. Ceccarelli
                                                                Ericsson
                                                             J. Tantsura
                                                                  Apstra
                                                       February 21, 2021

        Traffic Engineering (TE) and Service Mapping Yang Model
               draft-ietf-teas-te-service-mapping-yang-07

Abstract

   This document provides a YANG data model to map customer service
   models (e.g., the L3VPN Service Model (L3SM)) to Traffic Engineering
   (TE) models (e.g., the TE Tunnel or the Virtual Network (VN) 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 in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on August 25, 2021.

Lee, et al.              Expires August 25, 2021                [Page 1]
Internet-Draft             TE Service Mapping              February 2021

Copyright Notice

   Copyright (c) 2021 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
   (https://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.1.1.  Requirements Language . . . . . . . . . . . . . . . .   5
     1.2.  Tree diagram  . . . . . . . . . . . . . . . . . . . . . .   5
     1.3.  Prefixes in Data Node Names . . . . . . . . . . . . . . .   5
   2.  TE and Service Related Parameters . . . . . . . . . . . . . .   6
     2.1.  VN/Tunnel Selection Requirements  . . . . . . . . . . . .   7
     2.2.  TE Policy . . . . . . . . . . . . . . . . . . . . . . . .   8
       2.2.1.  Availability Requirement  . . . . . . . . . . . . . .   8
   3.  YANG Modeling Approach  . . . . . . . . . . . . . . . . . . .   8
     3.1.  Forward Compatibility . . . . . . . . . . . . . . . . . .   9
     3.2.  TE and Network Models . . . . . . . . . . . . . . . . . .   9
   4.  L3VPN Architecture in the ACTN Context  . . . . . . . . . . .  10
     4.1.  Service Mapping . . . . . . . . . . . . . . . . . . . . .  13
     4.2.  Site Mapping  . . . . . . . . . . . . . . . . . . . . . .  13
   5.  Applicability of TE-Service Mapping in Generic context  . . .  14
   6.  YANG Data Trees . . . . . . . . . . . . . . . . . . . . . . .  14
     6.1.  Service Mapping Types . . . . . . . . . . . . . . . . . .  14
     6.2.  Service Models  . . . . . . . . . . . . . . . . . . . . .  16
       6.2.1.  L3SM  . . . . . . . . . . . . . . . . . . . . . . . .  16
       6.2.2.  L2SM  . . . . . . . . . . . . . . . . . . . . . . . .  17
       6.2.3.  L1CSM . . . . . . . . . . . . . . . . . . . . . . . .  18
     6.3.  Network Models  . . . . . . . . . . . . . . . . . . . . .  19
       6.3.1.  L3NM  . . . . . . . . . . . . . . . . . . . . . . . .  19
       6.3.2.  L2NM  . . . . . . . . . . . . . . . . . . . . . . . .  20
   7.  YANG Data Models  . . . . . . . . . . . . . . . . . . . . . .  21
     7.1.  ietf-te-service-mapping-types . . . . . . . . . . . . . .  21
     7.2.  Service Models  . . . . . . . . . . . . . . . . . . . . .  31
       7.2.1.  ietf-l3sm-te-service-mapping  . . . . . . . . . . . .  31
       7.2.2.  ietf-l2sm-te-service-mapping  . . . . . . . . . . . .  33
       7.2.3.  ietf-l1csm-te-service-mapping . . . . . . . . . . . .  36

Lee, et al.              Expires August 25, 2021                [Page 2]
Internet-Draft             TE Service Mapping              February 2021

     7.3.  Network Models  . . . . . . . . . . . . . . . . . . . . .  38
       7.3.1.  ietf-l3nm-te-service-mapping  . . . . . . . . . . . .  38
       7.3.2.  ietf-l2nm-te-service-mapping  . . . . . . . . . . . .  40
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  42
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  43
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  45
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  45
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  45
     11.2.  Informative References . . . . . . . . . . . . . . . . .  48
   Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .  49
   Appendix B.  Discussion . . . . . . . . . . . . . . . . . . . . .  51
   Appendix C.  Contributor Addresses  . . . . . . . . . . . . . . .  51
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  52

1.  Introduction

   Data models are a representation of objects that can be configured or
   monitored within a system.  Within the IETF, YANG [RFC7950] 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 [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.
   [I-D.ietf-teas-actn-vn-yang] defines a YANG model and describes how
   customers or end-to-end orchestrator can request and/or instantiate a
   generic virtual network service.  [I-D.ietf-teas-actn-yang] 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.

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

Lee, et al.              Expires August 25, 2021                [Page 3]
Internet-Draft             TE Service Mapping              February 2021

   [I-D.ietf-ccamp-l1csm-yang] 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.

   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]:

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

   o  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 and service related parameters that
   this document addresses as "new and advanced parameters" that are not
   included in generic service models.  Section 3 discusses YANG
   modelling approach.

   Apart from the service model, the TE mapping is equally applicable to
   the Network Models (L3 VPN Service Network Model (L3NM)
   [I-D.ietf-opsawg-l3sm-l3nm], L2 VPN Service Network Model (L2NM)
   [I-D.ietf-opsawg-l2nm] etc.).  See Section 3.2 for details.

1.1.  Terminology

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

   The terminology for describing YANG data models is found in
   [RFC7950].

Lee, et al.              Expires August 25, 2021                [Page 4]
Internet-Draft             TE Service Mapping              February 2021

1.1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

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
   corresponding YANG imported modules, as shown in Table 1.

Lee, et al.              Expires August 25, 2021                [Page 5]
Internet-Draft             TE Service Mapping              February 2021

   +---------+---------------------------+-----------------------------+
   | Prefix  | YANG module               | Reference                   |
   +---------+---------------------------+-----------------------------+
   | tsmt    | ietf-te-service-mapping-  | [RFCXXXX]                   |
   |         | types                     |                             |
   | l1csm   | ietf-l1csm                | [I-D.ietf-ccamp-l1csm-yang] |
   | l2vpn-  | ietf-l2vpn-svc            | [RFC8466]                   |
   | svc     |                           |                             |
   | l3vpn-  | ietf-l3vpn-svc            | [RFC8299]                   |
   | svc     |                           |                             |
   | l1-tsm  | ietf-l1csm-te-service-    | [RFCXXXX]                   |
   |         | mapping                   |                             |
   | l2-tsm  | ietf-l2sm-te-service-     | [RFCXXXX]                   |
   |         | mapping                   |                             |
   | l3-tsm  | ietf-l3sm-te-service-     | [RFCXXXX]                   |
   |         | mapping                   |                             |
   | vn      | ietf-vn                   | [I-D.ietf-teas-actn-vn-yang |
   |         |                           | ]                           |
   | nw      | ietf-network              | [RFC8345]                   |
   | te-     | ietf-te-types             | [RFC8776]                   |
   | types   |                           |                             |
   | te      | ietf-te                   | [I-D.ietf-teas-yang-te]     |
   | l2vpn-  | ietf-l2vpn-ntw            | [I-D.ietf-opsawg-l2nm]      |
   | ntw     |                           |                             |
   | l3vpn-  | ietf-l3vpn-ntw            | [I-D.ietf-opsawg-l3sm-l3nm] |
   | ntw     |                           |                             |
   | rt      | ietf-routing              | [RFC8349]                   |
   | sr-     | ietf-sr-policy            | [I-D.ietf-spring-sr-policy- |
   | policy  |                           | yang]                       |
   +---------+---------------------------+-----------------------------+

             Table 1: Prefixes and corresponding YANG modules

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

2.  TE and Service Related Parameters

   While L1/L2/L3 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 these 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.

Lee, et al.              Expires August 25, 2021                [Page 6]
Internet-Draft             TE Service Mapping              February 2021

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.

   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 August 25, 2021                [Page 7]
Internet-Draft             TE Service Mapping              February 2021

   o  TE Mapping Template - This mode allows a VPN service to use a
      mapping template containing constraints and optimization criteria.
      This allows mapping with the underlay TE characteristics without
      first creating a VN or tunnels to map.  The VPN service could be
      mapped to a template first.  Once the VN/Tunnels are actually
      created/selected for the VPN service, the mapping based on the
      actual TE resources is created.

2.2.  TE Policy

   The service models could be associated with various policies related
   to mapping the underlying TE resources.  A color could be used to map
   to the underlying colored TE resources.  The desired protection and
   availability requirements could be specified.

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

3.  YANG Modeling Approach

   This section provides how the TE and Service mapping parameters are
   supported using augmentation of the existing service models (i.e.,
   [I-D.ietf-ccamp-l1csm-yang], [RFC8466], and [RFC8299]).  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

Lee, et al.              Expires August 25, 2021                [Page 8]
Internet-Draft             TE Service Mapping              February 2021

   The Augmented LxSM model (where x=1,2,3) augments the basic LxSM
   model while importing the common TE and Service related parameters
   (defined in Section 2) grouping information from TE and Service
   Mapping Types.  The TE and 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 mapping-type common model.

   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 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 [RFC8795], 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.

   The YANG models defined in this document conforms to the Network
   Management Datastore Architecture (NMDA) [RFC8342].

3.1.  Forward Compatibility

   The YANG module defined in this document supports three existing
   service models via augmenting while sharing the common TE and 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.

3.2.  TE and Network Models

   The L2/L3 network models (L2NM, L3NM) are intended to describe a VPN
   Service in the Service Provider Network.  It contains information of
   the Service Provider network and might include allocated resources.
   It can be used by network controllers to manage and control the VPN
   Service configuration in the Service Provider network.

Lee, et al.              Expires August 25, 2021                [Page 9]
Internet-Draft             TE Service Mapping              February 2021

   Similar to service model, the existing network models (i.e.,
   [I-D.ietf-opsawg-l3sm-l3nm], and [I-D.ietf-opsawg-l2nm]) are
   augmented to include the TE and Service mapping parameters.  Figure 2
   shows the scope of the Augmented LxNM Model.

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

                      Figure 2: Augmented LxNM Model

   The Augmented LxNM model (where x=2,3) augments the basic LxNM model
   while importing the common TE mapping related parameters (defined in
   Section 2) grouping information from TE and Service Mapping Types.
   The role of the augmented LxNM network model is to expose the mapping
   relationship between network models and TE models.

4.  L3VPN Architecture in the ACTN Context

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

                              +----------------------------+
                              |  Customer Service Manager  |
                              |  +-----------------------+ |
                              |  |           CNC         + |
                              |  +-+-------------------+-+ |
                              +----|-------------------|---+
                                   |                   |
                                   |CMI(Augmented L3SM)|CMI(VN)
                                   |                   |
                  +----------------|-------------------|----+
                  | +--------------|-----------------+ |    |
                  | | MDSC         |                 | |    |
                  | |              |                 | |    |
                  | |  +-----------+--------------+  | |    |
      TE-Svc-Map<------+ Service Mapping Function |  | |    |
                  | |  +-----------+--------------+  | |    |
                  | |              |                 | |    |
                  | +-------+------|-----------------+ |    |
                  |         |      |                   |    |

Lee, et al.              Expires August 25, 2021               [Page 10]
Internet-Draft             TE Service Mapping              February 2021

                  |         |      |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 3: L3VPN Architecture from the IP+Optical Network Perspective

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

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

   o  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

Lee, et al.              Expires August 25, 2021               [Page 11]
Internet-Draft             TE Service Mapping              February 2021

      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.

   o  PNC: The Provisioning Network Controller is responsible for
      configuring and operating the network devices.  Figure 3 shows two
      distinct PNCs.

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

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

   The three main interfaces are shown in Figure 3 and listed below.

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

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

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

   As shown in Figure 3, 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:

Lee, et al.              Expires August 25, 2021               [Page 12]
Internet-Draft             TE Service Mapping              February 2021

   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 [I-D.ietf-teas-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.

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

Lee, et al.              Expires August 25, 2021               [Page 13]
Internet-Draft             TE Service Mapping              February 2021

   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.

   +-------+---------+------------------+------------------------+-----+
   | Site  | Site    | Location         | Access Diversity       | PE  |
   |       | Network | (Address, Postal | (Constraint-Type,      |     |
   |       | Access  | Code, State,     | Group-id,Target Group- |     |
   |       |         | City,Country     | 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 2: : 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.

6.  YANG Data Trees

6.1.  Service Mapping Types

   module: ietf-te-service-mapping-types
     +--rw te-mapping-templates
        +--rw te-mapping-template* [id]
           +--rw id                  te-mapping-template-id
           +--rw description?        string
           +--rw map-type?           identityref
           +--rw path-constraints
           |  +--rw te-bandwidth

Lee, et al.              Expires August 25, 2021               [Page 14]
Internet-Draft             TE Service Mapping              February 2021

           |  |  +--rw (technology)?
           |  |     +--:(generic)
           |  |        +--rw generic?   te-bandwidth
           |  +--rw link-protection?          identityref
           |  +--rw setup-priority?           uint8
           |  +--rw hold-priority?            uint8
           |  +--rw signaling-type?           identityref
           |  +--rw path-metric-bounds
           |  |  +--rw path-metric-bound* [metric-type]
           |  |     +--rw metric-type    identityref
           |  |     +--rw upper-bound?   uint64
           |  +--rw path-affinities-values
           |  |  +--rw path-affinities-value* [usage]
           |  |     +--rw usage    identityref
           |  |     +--rw value?   admin-groups
           |  +--rw path-affinity-names
           |  |  +--rw path-affinity-name* [usage]
           |  |     +--rw usage            identityref
           |  |     +--rw affinity-name* [name]
           |  |        +--rw name    string
           |  +--rw path-srlgs-lists
           |  |  +--rw path-srlgs-list* [usage]
           |  |     +--rw usage     identityref
           |  |     +--rw values*   srlg
           |  +--rw path-srlgs-names
           |  |  +--rw path-srlgs-name* [usage]
           |  |     +--rw usage    identityref
           |  |     +--rw names*   string
           |  +--rw disjointness?             te-path-disjointness
           +--rw optimizations
              +--rw (algorithm)?
                 +--:(metric) {path-optimization-metric}?
                 |  +--rw optimization-metric* [metric-type]
                 |  |  +--rw metric-type
                 |  |  |       identityref
                 |  |  +--rw weight?                           uint8
                 |  |  +--rw explicit-route-exclude-objects
                 |  |  |     ...
                 |  |  +--rw explicit-route-include-objects
                 |  |        ...
                 |  +--rw tiebreakers
                 |     +--rw tiebreaker* [tiebreaker-type]
                 |           ...
                 +--:(objective-function)
                          {path-optimization-objective-function}?
                    +--rw objective-function
                       +--rw objective-function-type?   identityref

Lee, et al.              Expires August 25, 2021               [Page 15]
Internet-Draft             TE Service Mapping              February 2021

6.2.  Service Models

6.2.1.  L3SM

  module: ietf-l3sm-te-service-mapping
    augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services
              /l3vpn-svc:vpn-service:
      +--rw te-service-mapping!
         +--rw te-mapping
            +--rw map-type?                  identityref
            +--rw te-policy
            |  +--rw color?               uint32
            |  +--rw protection-type?     identityref
            |  +--rw availability-type?   identityref
            +--rw (te)?
            |  +--:(vn)
            |  |  +--rw vn*                  -> /vn:vn/vn/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*           te:tunnel-ref
            |     +--rw sr-policy*
            |             [policy-color-ref policy-endpoint-ref]
            |             {sr-policy}?
            |        +--rw policy-color-ref       leafref
            |        +--rw policy-endpoint-ref    leafref
            +--rw te-mapping-template-ref?
                    -> /tsmt:te-mapping-templates/te-mapping-template/id
                    {template}?
    augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site
              /l3vpn-svc:site-network-accesses
              /l3vpn-svc:site-network-access:
      +--rw (te)?
         +--:(vn)
         |  +--rw vn-ap*   -> /vn:ap/ap/vn-ap/vn-ap-id
         +--:(te)
            +--rw ltp?     te-types:te-tp-id
    augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site
              /l3vpn-svc:service/l3vpn-svc:qos/l3vpn-svc:qos-profile
              /l3vpn-svc:qos-profile/l3vpn-svc:custom/l3vpn-svc:classes
              /l3vpn-svc:class:
      +--rw (te)?
         +--:(vn)
         |  +--rw vn-ap*   -> /vn:ap/ap/vn-ap/vn-ap-id
         +--:(te)

Lee, et al.              Expires August 25, 2021               [Page 16]
Internet-Draft             TE Service Mapping              February 2021

            +--rw ltp?     te-types:te-tp-id
    augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site
              /l3vpn-svc:site-network-accesses
              /l3vpn-svc:site-network-access/l3vpn-svc:service
              /l3vpn-svc:qos/l3vpn-svc:qos-profile
              /l3vpn-svc:qos-profile/l3vpn-svc:custom/l3vpn-svc:classes
              /l3vpn-svc:class:
      +--rw (te)?
         +--:(vn)
         |  +--rw vn-ap*   -> /vn:ap/ap/vn-ap/vn-ap-id
         +--:(te)
            +--rw ltp?     te-types:te-tp-id

6.2.2.  L2SM

  module: ietf-l2sm-te-service-mapping
    augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services
              /l2vpn-svc:vpn-service:
      +--rw te-service-mapping!
         +--rw te-mapping
            +--rw map-type?                  identityref
            +--rw te-policy
            |  +--rw color?               uint32
            |  +--rw protection-type?     identityref
            |  +--rw availability-type?   identityref
            +--rw (te)?
            |  +--:(vn)
            |  |  +--rw vn*                  -> /vn:vn/vn/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*           te:tunnel-ref
            |     +--rw sr-policy*
            |             [policy-color-ref policy-endpoint-ref]
            |             {sr-policy}?
            |        +--rw policy-color-ref       leafref
            |        +--rw policy-endpoint-ref    leafref
            +--rw te-mapping-template-ref?
                    -> /tsmt:te-mapping-templates/te-mapping-template/id
                    {template}?
    augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site
              /l2vpn-svc:site-network-accesses
              /l2vpn-svc:site-network-access:
      +--rw (te)?
         +--:(vn)
         |  +--rw vn-ap*   -> /vn:ap/ap/vn-ap/vn-ap-id

Lee, et al.              Expires August 25, 2021               [Page 17]
Internet-Draft             TE Service Mapping              February 2021

         +--:(te)
            +--rw ltp?     te-types:te-tp-id
    augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site
              /l2vpn-svc:service/l2vpn-svc:qos/l2vpn-svc:qos-profile
              /l2vpn-svc:qos-profile/l2vpn-svc:custom/l2vpn-svc:classes
              /l2vpn-svc:class:
      +--rw (te)?
         +--:(vn)
         |  +--rw vn-ap*   -> /vn:ap/ap/vn-ap/vn-ap-id
         +--:(te)
            +--rw ltp?     te-types:te-tp-id
    augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site
              /l2vpn-svc:site-network-accesses
              /l2vpn-svc:site-network-access/l2vpn-svc:service
              /l2vpn-svc:qos/l2vpn-svc:qos-profile
              /l2vpn-svc:qos-profile/l2vpn-svc:custom/l2vpn-svc:classes
              /l2vpn-svc:class:
      +--rw (te)?
         +--:(vn)
         |  +--rw vn-ap*   -> /vn:ap/ap/vn-ap/vn-ap-id
         +--:(te)
            +--rw ltp?     te-types:te-tp-id

6.2.3.  L1CSM

Lee, et al.              Expires August 25, 2021               [Page 18]
Internet-Draft             TE Service Mapping              February 2021

  module: ietf-l1csm-te-service-mapping
    augment /l1csm:l1-connectivity/l1csm:services/l1csm:service:
      +--rw te-service-mapping!
         +--rw te-mapping
            +--rw map-type?                  identityref
            +--rw te-policy
            |  +--rw color?               uint32
            |  +--rw protection-type?     identityref
            |  +--rw availability-type?   identityref
            +--rw (te)?
            |  +--:(vn)
            |  |  +--rw vn*                  -> /vn:vn/vn/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*           te:tunnel-ref
            |     +--rw sr-policy*
            |             [policy-color-ref policy-endpoint-ref]
            |             {sr-policy}?
            |        +--rw policy-color-ref       leafref
            |        +--rw policy-endpoint-ref    leafref
            +--rw te-mapping-template-ref?
                    -> /tsmt:te-mapping-templates/te-mapping-template/id
                    {template}?
    augment /l1csm:l1-connectivity/l1csm:access/l1csm:unis/l1csm:uni:
      +--rw (te)?
         +--:(vn)
         |  +--rw vn-ap*   -> /vn:ap/ap/vn-ap/vn-ap-id
         +--:(te)
            +--rw ltp?     te-types:te-tp-id

6.3.  Network Models

6.3.1.  L3NM

Lee, et al.              Expires August 25, 2021               [Page 19]
Internet-Draft             TE Service Mapping              February 2021

  module: ietf-l3nm-te-service-mapping
    augment /l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services
              /l3vpn-ntw:vpn-service:
      +--rw te-service-mapping!
         +--rw te-mapping
            +--rw map-type?                  identityref
            +--rw te-policy
            |  +--rw color?               uint32
            |  +--rw protection-type?     identityref
            |  +--rw availability-type?   identityref
            +--rw (te)?
            |  +--:(vn)
            |  |  +--rw vn*                  -> /vn:vn/vn/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*           te:tunnel-ref
            |     +--rw sr-policy*
            |             [policy-color-ref policy-endpoint-ref]
            |             {sr-policy}?
            |        +--rw policy-color-ref       leafref
            |        +--rw policy-endpoint-ref    leafref
            +--rw te-mapping-template-ref?
                    -> /tsmt:te-mapping-templates/te-mapping-template/id
                    {template}?
    augment /l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services
              /l3vpn-ntw:vpn-service/l3vpn-ntw:vpn-nodes
              /l3vpn-ntw:vpn-node/l3vpn-ntw:vpn-network-accesses
              /l3vpn-ntw:vpn-network-access:
      +--rw (te)?
         +--:(vn)
         |  +--rw vn-ap*   -> /vn:ap/ap/vn-ap/vn-ap-id
         +--:(te)
            +--rw ltp?     te-types:te-tp-id

6.3.2.  L2NM

Lee, et al.              Expires August 25, 2021               [Page 20]
Internet-Draft             TE Service Mapping              February 2021

  module: ietf-l2nm-te-service-mapping
    augment /l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services
              /l2vpn-ntw:vpn-service:
      +--rw te-service-mapping!
         +--rw te-mapping
            +--rw map-type?                  identityref
            +--rw te-policy
            |  +--rw color?               uint32
            |  +--rw protection-type?     identityref
            |  +--rw availability-type?   identityref
            +--rw (te)?
            |  +--:(vn)
            |  |  +--rw vn*                  -> /vn:vn/vn/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*           te:tunnel-ref
            |     +--rw sr-policy*
            |             [policy-color-ref policy-endpoint-ref]
            |             {sr-policy}?
            |        +--rw policy-color-ref       leafref
            |        +--rw policy-endpoint-ref    leafref
            +--rw te-mapping-template-ref?
                    -> /tsmt:te-mapping-templates/te-mapping-template/id
                    {template}?
    augment /l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services
              /l2vpn-ntw:vpn-service/l2vpn-ntw:vpn-nodes
              /l2vpn-ntw:vpn-node/l2vpn-ntw:vpn-network-accesses
              /l2vpn-ntw:vpn-network-access:
      +--rw (te)?
         +--:(vn)
         |  +--rw vn-ap*   -> /vn:ap/ap/vn-ap/vn-ap-id
         +--:(te)
            +--rw ltp?     te-types:te-tp-id

7.  YANG Data Models

   The YANG codes are as follows:

7.1.  ietf-te-service-mapping-types

 <CODE BEGINS> file "ietf-te-service-mapping-types@2021-02-22.yang"
 module ietf-te-service-mapping-types {
   yang-version 1.1;
   namespace
     "urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types";

Lee, et al.              Expires August 25, 2021               [Page 21]
Internet-Draft             TE Service Mapping              February 2021

   prefix tsmt;

   /* Import te-types */

   import ietf-te-types {
     prefix te-types;
     reference
       "RFC 8776: Common YANG Data Types for Traffic Engineering";
   }

   /* Import network model */

   import ietf-network {
     prefix nw;
     reference
       "RFC 8345: A YANG Data Model for Network Topologies";
   }

   /* Import TE model */

   import ietf-te {
     prefix te;
     reference
       "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic
        Engineering Tunnels and Interfaces";
   }

   /* Import VN model */

   import ietf-vn {
     prefix vn;
     reference
       "I-D.ietf-teas-actn-vn-yang: A Yang Data Model for VN Operation";
   }

   /* Import Routing */

   import ietf-routing {
     prefix rt;
     reference
       "RFC 8349: A YANG Data Model for Routing Management";
   }

   /* Import SR Policy */

   import ietf-sr-policy {
     prefix sr-policy;
     reference

Lee, et al.              Expires August 25, 2021               [Page 22]
Internet-Draft             TE Service Mapping              February 2021

       "I-D.ietf-spring-sr-policy-yang: YANG Data Model for Segment
        Routing Policy";
   }

   organization
     "IETF Traffic Engineering Architecture and Signaling (TEAS)
      Working Group";
   contact
     "WG Web:   <http://tools.ietf.org/wg/teas/>
      WG List:  <mailto:teas@ietf.org>

      Editor:   Young Lee
                <mailto:younglee.tx@gmail.com>
      Editor:   Dhruv Dhody
                <mailto:dhruv.ietf@gmail.com>
      Editor:   Qin Wu
                <mailto: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.)

      Copyright (c) 2021 IETF Trust and the persons identified as
      authors of the code.  All rights reserved.

      Redistribution and use in source and binary forms, with or
      without modification, is permitted pursuant to, and subject to
      the license terms contained in, the Simplified BSD License set
      forth in Section 4.c of the IETF Trust's Legal Provisions
      Relating to IETF Documents
      (https://trustee.ietf.org/license-info).

      This version of this YANG module is part of RFC XXXX; see the
      RFC itself for full legal notices.

      The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
      NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
      'MAY', and 'OPTIONAL' in this document are to be interpreted as
      described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
      they appear in all capitals, as shown here.";

   revision 2021-02-22 {
     description
       "Initial revision.";
     reference
       "RFC XXXX:  Traffic Engineering and Service Mapping Yang Model";
   }

Lee, et al.              Expires August 25, 2021               [Page 23]
Internet-Draft             TE Service Mapping              February 2021

   /*
    * Features
    */

   feature template {
     description
       "Support TE mapping templates.";
   }

   feature sr-policy {
     description
       "Support SR Policy.";
   }

   /*
    * 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.";
   }

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

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

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

   identity select {

Lee, et al.              Expires August 25, 2021               [Page 24]
Internet-Draft             TE Service Mapping              February 2021

     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 none {
     base map-type;
     description
       "The VPN service is not mapped to any underlying TE";
   }

   /*
    * 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 {
     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;

Lee, et al.              Expires August 25, 2021               [Page 25]
Internet-Draft             TE Service Mapping              February 2021

     description
       "level 4: 99.9%";
   }

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

   /*
    * Typedef
    */

   typedef te-mapping-template-id {
     type string;
     description
       "Identifier for a TE mapping template.";
   }

   /*
    * Groupings
    */

   grouping te-ref {
     description
       "The reference to TE.";
     choice te {
       description
         "How the VPN is mapped to a VN, Topology, Tunnel, SR Policy
          etc.";
       case vn {
         leaf-list vn {
           type leafref {
             path "/vn:vn/vn:vn/vn:vn-id";
           }
           description
             "The reference to VN";
           reference
             "RFC 8453: Framework for Abstraction and Control of TE
              Networks (ACTN)";
         }
       }
       case te-topo {
         leaf vn-topology-id {
           type te-types:te-topology-id;
           description
             "An identifier to the TE Topology Model where the abstract

Lee, et al.              Expires August 25, 2021               [Page 26]
Internet-Draft             TE Service Mapping              February 2021

              nodes and links of the Topology can be found for Type 2
              VNs as defined in RFC 8453";
           reference
             "RFC 8795: YANG Data Model for Traffic Engineering (TE)
              Topologies
              RFC 8453: Framework for Abstraction and Control of TE
              Networks (ACTN)";
         }
         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";
           reference
             "RFC 8795: YANG Data Model for Traffic Engineering (TE)
              Topologies";
         }
       }
       case te-tunnel {
         leaf-list te-tunnel {
           type te:tunnel-ref;
           description
             "Reference to TE Tunnels";
           reference
             "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic
              Engineering Tunnels and Interfaces";
         }
         list sr-policy {
           if-feature "sr-policy";
           key "policy-color-ref policy-endpoint-ref";
           description
             "SR Policy";
           leaf policy-color-ref {
             type leafref {
               path
                 "/rt:routing/sr-policy:segment-routing"
               + "/sr-policy:traffic-engineering/sr-policy:policies"
               + "/sr-policy:policy/sr-policy:color";
             }
             description
               "Reference to sr-policy color";
           }
           leaf policy-endpoint-ref {
             type leafref {
               path
                 "/rt:routing/sr-policy:segment-routing"
               + "/sr-policy:traffic-engineering/sr-policy:policies"

Lee, et al.              Expires August 25, 2021               [Page 27]
Internet-Draft             TE Service Mapping              February 2021

               + "/sr-policy:policy/sr-policy:endpoint";
             }
             description
               "Reference to sr-policy endpoint";
           }
         }
       }
     }
     leaf te-mapping-template-ref {
       if-feature "template";
       type leafref {
         path "/tsmt:te-mapping-templates/"
            + "tsmt:te-mapping-template/tsmt:id";
       }
       description
         "An identifier to the TE Mapping Template where the TE
          constraints and optimization criteria are specified.";
     }
   }

   //grouping

   grouping te-endpoint-ref {
     description
       "The reference to TE endpoints.";
     choice te {
       description
         "How the TE endpoint is defined by VN's AP or TE's LTP";
       case vn {
         leaf-list vn-ap {
           type leafref {
             path "/vn:ap/vn:ap/vn:vn-ap/vn:vn-ap-id";
           }
           description
             "The reference to VNAP";
           reference
             "RFC 8453: Framework for Abstraction and Control of TE
              Networks (ACTN)";
         }
       }
       case te {
         leaf ltp {
           type te-types:te-tp-id;
           description
             "Reference LTP in the TE-topology";
           reference
             "RFC 8795: YANG Data Model for Traffic Engineering (TE)
              Topologies";

Lee, et al.              Expires August 25, 2021               [Page 28]
Internet-Draft             TE Service Mapping              February 2021

         }
       }
     }
   }

   //grouping

   grouping te-policy {
     description
       "Various underlying TE policy requirements";
     leaf color {
       type uint32;
       description
         "Maps to the underlying colored TE resources";
     }
     leaf protection-type {
       type identityref {
         base te-types:lsp-protection-type;
       }
       description
         "Desired protection level for the underlying
          TE resources";
     }
     leaf availability-type {
       type identityref {
         base availability-type;
       }
       description
         "Availability Requirement for the Service";
     }
   }

   //grouping

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

Lee, et al.              Expires August 25, 2021               [Page 29]
Internet-Draft             TE Service Mapping              February 2021

       container te-policy {
         uses te-policy;
         description
           "Desired Underlying TE Policy";
       }
       uses te-ref;
     }
   }

   //grouping

   container te-mapping-templates {
     description
       "The TE constraints and optimization criteria";
     list te-mapping-template {
       key "id";
       leaf id {
         type te-mapping-template-id;
         description
           "Identification of the Template to be used.";
       }
       leaf description {
         type string;
         description
           "Description of the template.";
       }
       leaf map-type {
         type identityref {
           base map-type;
         }
         must "0 = derived-from-or-self(.,'none')" {
           error-message "The map-type must be other than "
                       + "none";
         }
         description
           "Map type for the VN/Tunnel creation/
            selection.";
       }
       uses te-types:generic-path-constraints;
       uses te-types:generic-path-optimization;
       description
         "List for templates.";
     }
   }
 }
 <CODE ENDS>

Lee, et al.              Expires August 25, 2021               [Page 30]
Internet-Draft             TE Service Mapping              February 2021

7.2.  Service Models

7.2.1.  ietf-l3sm-te-service-mapping

 <CODE BEGINS> file "ietf-l3sm-te-service-mapping@2021-02-22.yang"
 module ietf-l3sm-te-service-mapping {
   yang-version 1.1;
   namespace
     "urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping";
   prefix l3-tsm;

   import ietf-te-service-mapping-types {
     prefix tsmt;
     reference
       "RFC XXXX:  Traffic Engineering and Service Mapping Yang Model";
   }
   import ietf-l3vpn-svc {
     prefix l3vpn-svc;
     reference
       "RFC 8299: YANG Data Model for L3VPN Service Delivery";
   }

   organization
     "IETF Traffic Engineering Architecture and Signaling (TEAS)
      Working Group";
   contact
     "WG Web:   <http://tools.ietf.org/wg/teas/>
      WG List:  <mailto:teas@ietf.org>

      Editor:   Young Lee
                <mailto:younglee.tx@gmail.com>
      Editor:   Dhruv Dhody
                <mailto:dhruv.ietf@gmail.com>
      Editor:   Qin Wu
                <mailto: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.

      Copyright (c) 2020 IETF Trust and the persons identified as
      authors of the code.  All rights reserved.

      Redistribution and use in source and binary forms, with or
      without modification, is permitted pursuant to, and subject to
      the license terms contained in, the Simplified BSD License set
      forth in Section 4.c of the IETF Trust's Legal Provisions
      Relating to IETF Documents
      (https://trustee.ietf.org/license-info).

Lee, et al.              Expires August 25, 2021               [Page 31]
Internet-Draft             TE Service Mapping              February 2021

      This version of this YANG module is part of RFC XXXX; see the
      RFC itself for full legal notices.

      The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
      NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
      'MAY', and 'OPTIONAL' in this document are to be interpreted as
      described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
      they appear in all capitals, as shown here.";

   revision 2021-02-22 {
     description
       "Initial revision.";
     reference
       "RFC XXXX:  Traffic Engineering and Service Mapping Yang Model";
   }

   /*
    * Augmentation to L3SM
    */

   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";
       uses tsmt:te-mapping;
     }
   }

   //augment

   augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site"
         + "/l3vpn-svc:site-network-accesses"
         + "/l3vpn-svc:site-network-access" {
     description
       "This augment is only valid for TE mapping of L3SM network-access
        to TE endpoints";
     uses tsmt:te-endpoint-ref;
   }

   //augment

   augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site"
         + "/l3vpn-svc:service/l3vpn-svc:qos/l3vpn-svc:qos-profile"
         + "/l3vpn-svc:qos-profile/l3vpn-svc:custom"

Lee, et al.              Expires August 25, 2021               [Page 32]
Internet-Draft             TE Service Mapping              February 2021

         + "/l3vpn-svc:classes/l3vpn-svc:class" {
     description
       "This augment is for per-class in site for custom QoS profile";
     uses tsmt:te-endpoint-ref;
   }

   augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site"
         + "/l3vpn-svc:site-network-accesses"
         + "/l3vpn-svc:site-network-access"
         + "/l3vpn-svc:service/l3vpn-svc:qos/l3vpn-svc:qos-profile"
         + "/l3vpn-svc:qos-profile/l3vpn-svc:custom"
         + "/l3vpn-svc:classes/l3vpn-svc:class" {
     description
       "This augment is for per-class in site-network-access for custom
        QoS profile";
     uses tsmt:te-endpoint-ref;
   }
 }
 <CODE ENDS>

7.2.2.  ietf-l2sm-te-service-mapping

  <CODE BEGINS> file "ietf-l2sm-te-service-mapping@2021-02-22.yang"
  module ietf-l2sm-te-service-mapping {
    yang-version 1.1;
    namespace
      "urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping";
    prefix l2-tsm;

    import ietf-te-service-mapping-types {
      prefix tsmt;
      reference
        "RFC XXXX:  Traffic Engineering and Service Mapping Yang Model";
    }
    import ietf-l2vpn-svc {
      prefix l2vpn-svc;
      reference
        "RFC 8466: A YANG Data Model for Layer 2 Virtual Private Network
         (L2VPN) Service Delivery";
    }

    organization
      "IETF Traffic Engineering Architecture and Signaling (TEAS)
       Working Group";
    contact
      "WG Web:   <http://tools.ietf.org/wg/teas/>
       WG List:  <mailto:teas@ietf.org>

Lee, et al.              Expires August 25, 2021               [Page 33]
Internet-Draft             TE Service Mapping              February 2021

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

       Copyright (c) 2021 IETF Trust and the persons identified as
       authors of the code.  All rights reserved.

       Redistribution and use in source and binary forms, with or
       without modification, is permitted pursuant to, and subject to
       the license terms contained in, the Simplified BSD License set
       forth in Section 4.c of the IETF Trust's Legal Provisions
       Relating to IETF Documents
       (https://trustee.ietf.org/license-info).

       This version of this YANG module is part of RFC XXXX; see the
       RFC itself for full legal notices.

       The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
       NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
       'MAY', and 'OPTIONAL' in this document are to be interpreted as
       described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
       they appear in all capitals, as shown here.";

    revision 2021-02-22 {
      description
        "Initial revision.";
      reference
        "RFC XXXX:  Traffic Engineering and Service Mapping Yang Model";
    }

    /*
     * Augmentation to L2SM
     */

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

Lee, et al.              Expires August 25, 2021               [Page 34]
Internet-Draft             TE Service Mapping              February 2021

        uses tsmt:te-mapping;
      }
    }

    //augment

    augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site"
          + "/l2vpn-svc:site-network-accesses"
          + "/l2vpn-svc:site-network-access" {
      description
        "This augment the L2SM network-access with a reference
         to TE endpoints when underlying TE is used";
      uses tsmt:te-endpoint-ref;
    }

    //augment

    augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site"
          + "/l2vpn-svc:service/l2vpn-svc:qos/l2vpn-svc:qos-profile"
          + "/l2vpn-svc:qos-profile/l2vpn-svc:custom"
          + "/l2vpn-svc:classes/l2vpn-svc:class" {
      when './l2vpn-svc:bandwidth/l2vpn-svc:end-to-end' {
        description
          "applicable only with end-to-end";
      }
      description
        "This augment is for per-class in site for custom QoS profile";
      uses tsmt:te-endpoint-ref;
    }

    augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site"
          + "/l2vpn-svc:site-network-accesses"
          + "/l2vpn-svc:site-network-access"
          + "/l2vpn-svc:service/l2vpn-svc:qos/l2vpn-svc:qos-profile"
          + "/l2vpn-svc:qos-profile/l2vpn-svc:custom"
          + "/l2vpn-svc:classes/l2vpn-svc:class" {
      description
        "This augment is for per-class in site-network-access for custom
         QoS profile";
      uses tsmt:te-endpoint-ref;
    }
  }
  <CODE ENDS>

Lee, et al.              Expires August 25, 2021               [Page 35]
Internet-Draft             TE Service Mapping              February 2021

7.2.3.  ietf-l1csm-te-service-mapping

 <CODE BEGINS> file "ietf-l1csm-te-service-mapping@2021-02-22.yang"
 module ietf-l1csm-te-service-mapping {
   yang-version 1.1;
   namespace
     "urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping";
   prefix l1-tsm;

   import ietf-te-service-mapping-types {
     prefix tsmt;
     reference
       "RFC XXXX:  Traffic Engineering and Service Mapping Yang Model";
   }
   import ietf-l1csm {
     prefix l1csm;
     reference
       "I-D.ietf-ccamp-l1csm-yang: A YANG Data Model for L1 Connectivity
        Service Model (L1CSM)";
   }

   organization
     "IETF Traffic Engineering Architecture and Signaling (TEAS)
      Working Group";
   contact
     "WG Web:   <http://tools.ietf.org/wg/teas/>
      WG List:  <mailto:teas@ietf.org>

      Editor:   Young Lee
                <mailto:younglee.tx@gmail.com>
      Editor:   Dhruv Dhody
                <mailto:dhruv.ietf@gmail.com>
      Editor:   Qin Wu
                <mailto: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

      Copyright (c) 2021 IETF Trust and the persons identified as
      authors of the code.  All rights reserved.

      Redistribution and use in source and binary forms, with or
      without modification, is permitted pursuant to, and subject to
      the license terms contained in, the Simplified BSD License set
      forth in Section 4.c of the IETF Trust's Legal Provisions
      Relating to IETF Documents
      (https://trustee.ietf.org/license-info).

Lee, et al.              Expires August 25, 2021               [Page 36]
Internet-Draft             TE Service Mapping              February 2021

      This version of this YANG module is part of RFC XXXX; see the
      RFC itself for full legal notices.

      The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
      NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
      'MAY', and 'OPTIONAL' in this document are to be interpreted as
      described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
      they appear in all capitals, as shown here.";

   revision 2021-02-22 {
     description
       "Initial revision.";
     reference
       "RFC XXXX:  Traffic Engineering and Service Mapping Yang Model";
   }

   /*
    * Augmentation to L1CSM
    */

   augment "/l1csm:l1-connectivity/l1csm:services/l1csm: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";
       uses tsmt:te-mapping;
     }
   }

   //augment

   augment "/l1csm:l1-connectivity/l1csm:access/l1csm:unis/"
         + "l1csm:uni" {
     description
       "This augment the L1CSM UNI with a reference
        to TE endpoints";
     uses tsmt:te-endpoint-ref;
   }

   //augment
 }
 <CODE ENDS>

Lee, et al.              Expires August 25, 2021               [Page 37]
Internet-Draft             TE Service Mapping              February 2021

7.3.  Network Models

7.3.1.  ietf-l3nm-te-service-mapping

  <CODE BEGINS> file "ietf-l3nm-te-service-mapping@202-02-22.yang"
  module ietf-l3nm-te-service-mapping {
    yang-version 1.1;
    namespace
      "urn:ietf:params:xml:ns:yang:ietf-l3nm-te-service-mapping";
    prefix l3nm-tsm;

    import ietf-te-service-mapping-types {
      prefix tsmt;
      reference
        "RFC XXXX:  Traffic Engineering and Service Mapping Yang Model";
    }
    import ietf-l3vpn-ntw {
      prefix l3vpn-ntw;
      reference
        "I-D.ietf-opsawg-l3sm-l3nm: A Layer 3 VPN Network YANG Model";
    }

    organization
      "IETF Traffic Engineering Architecture and Signaling (TEAS)
       Working Group";
    contact
      "WG Web:   <http://tools.ietf.org/wg/teas/>
       WG List:  <mailto:teas@ietf.org>

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

       Copyright (c) 2021 IETF Trust and the persons identified as
       authors of the code.  All rights reserved.

       Redistribution and use in source and binary forms, with or
       without modification, is permitted pursuant to, and subject to
       the license terms contained in, the Simplified BSD License set
       forth in Section 4.c of the IETF Trust's Legal Provisions
       Relating to IETF Documents
       (https://trustee.ietf.org/license-info).

Lee, et al.              Expires August 25, 2021               [Page 38]
Internet-Draft             TE Service Mapping              February 2021

       This version of this YANG module is part of RFC XXXX; see the
       RFC itself for full legal notices.

       The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
       NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
       'MAY', and 'OPTIONAL' in this document are to be interpreted as
       described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
       they appear in all capitals, as shown here.";

    revision 2021-02-22 {
      description
        "Initial revision.";
      reference
        "RFC XXXX:  Traffic Engineering and Service Mapping Yang Model";
    }

    /*
     * Augmentation to L3NM
     */

    augment "/l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services"
          + "/l3vpn-ntw:vpn-service" {
      description
        "L3SM augmented to include TE parameters and mapping";
      container te-service-mapping {
        presence "Indicates L3 network to TE mapping";
        description
          "Container to augment l3nm to TE parameters and mapping";
        uses tsmt:te-mapping;
      }
    }

    //augment

    augment "/l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services"
          + "/l3vpn-ntw:vpn-service"
          + "/l3vpn-ntw:vpn-nodes/l3vpn-ntw:vpn-node"
          + "/l3vpn-ntw:vpn-network-accesses"
          + "/l3vpn-ntw:vpn-network-access" {
      description
        "This augment the L3NM network-access with a reference
         to TE endpoints when underlying TE is used";
      uses tsmt:te-endpoint-ref;
    }

    //augment
  }
  <CODE ENDS>

Lee, et al.              Expires August 25, 2021               [Page 39]
Internet-Draft             TE Service Mapping              February 2021

7.3.2.  ietf-l2nm-te-service-mapping

  <CODE BEGINS> file "ietf-l2nm-te-service-mapping@2021-02-22.yang"
  module ietf-l2nm-te-service-mapping {
    yang-version 1.1;
    namespace
      "urn:ietf:params:xml:ns:yang:ietf-l2nm-te-service-mapping";
    prefix l2nm-tsm;

    import ietf-te-service-mapping-types {
      prefix tsmt;
      reference
        "RFC XXXX:  Traffic Engineering and Service Mapping Yang Model";
    }
    import ietf-l2vpn-ntw {
      prefix l2vpn-ntw;
      reference
        "I-D.ietf-opsawg-l2nm: A Layer 2 VPN Network YANG Model";
    }

    organization
      "IETF Traffic Engineering Architecture and Signaling (TEAS)
       Working Group";
    contact
      "WG Web:   <http://tools.ietf.org/wg/teas/>
       WG List:  <mailto:teas@ietf.org>

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

       Copyright (c) 2021 IETF Trust and the persons identified as
       authors of the code.  All rights reserved.

       Redistribution and use in source and binary forms, with or
       without modification, is permitted pursuant to, and subject to
       the license terms contained in, the Simplified BSD License set
       forth in Section 4.c of the IETF Trust's Legal Provisions
       Relating to IETF Documents
       (https://trustee.ietf.org/license-info).

       This version of this YANG module is part of RFC XXXX; see the

Lee, et al.              Expires August 25, 2021               [Page 40]
Internet-Draft             TE Service Mapping              February 2021

       RFC itself for full legal notices.

       The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
       NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
       'MAY', and 'OPTIONAL' in this document are to be interpreted as
       described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
       they appear in all capitals, as shown here.";

    revision 2021-02-22 {
      description
        "Initial revision.";
      reference
        "RFC XXXX:  Traffic Engineering and Service Mapping Yang Model";
    }

    /*
     * Augmentation to L2NM
     */

    augment "/l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services"
          + "/l2vpn-ntw:vpn-service" {
      description
        "L2SM augmented to include TE parameters and mapping";
      container te-service-mapping {
        presence "Indicates L2 network to TE mapping";
        description
          "Container to augment l2nm to TE parameters and mapping";
        uses tsmt:te-mapping;
      }
    }

    //augment

    augment "/l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services"
          + "/l2vpn-ntw:vpn-service"
          + "/l2vpn-ntw:vpn-nodes/l2vpn-ntw:vpn-node"
          + "/l2vpn-ntw:vpn-network-accesses"
          + "/l2vpn-ntw:vpn-network-access" {
      description
        "This augment the L2NM network-access with a reference
         to TE endpoints when underlying TE is used";
      uses tsmt:te-endpoint-ref;
    }

    //augment
  }
  <CODE ENDS>

Lee, et al.              Expires August 25, 2021               [Page 41]
Internet-Draft             TE Service Mapping              February 2021

8.  Security Considerations

   The YANG modules defined in this document is designed to be accessed
   via network management protocol such as NETCONF [RFC6241] or RESTCONF
   [RFC8040].  The lowest NETCONF layer is the secure transport layer
   and the mandatory-to-implement secure transport is SSH [RFC6242].
   The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement
   secure transport is TLS [RFC8446]

   The NETCONF access control model [RFC8341] provides the means to
   restrict access for particular NETCONF or RESTCONF users to a pre-
   configured subset of all available NETCONF or RESTCONF protocol
   operations and content.

   There are a number of data nodes defined in the YANG moduleS which
   are writable/creatable/deletable (i.e., config true, which is the
   default).  These data nodes may be considered sensitive or vulnerable
   in some network environments.  Write operations (e.g., <edit-config>)
   to these data nodes without proper protection can have a negative
   effect on network operations.  These are the subtrees and data nodes
   and their sensitivity/vulnerability:

   o  /l3vpn-svc/vpn-services/vpn-service/te-service-mapping/te-mapping/
      - configure TE Service mapping.

   o  /l3vpn-svc/sites/site/site-network-accesses/site-network-access/
      te/ - configure TE Endpoint mapping.

   o  /l2vpn-svc/vpn-services/vpn-service/te-service-mapping/te-mapping/
      - configure TE Service mapping.

   o  /l2vpn-svc/sites/site/site-network-accesses/site-network-access/
      te/ - configure TE Endpoint mapping.

   o  /l1-connectivity/services/service/te-service-mapping/te-mapping/ -
      configure TE Service mapping.

   o  /l1-connectivity/access/unis/uni/te/ - configure TE Endpoint
      mapping.

   o  /l3vpn-ntw/vpn-services/vpn-service/te-service-mapping/te-mapping/
      - configure TE Network mapping.

   o  /l3vpn-ntw/vpn-services/vpn-service/vpn-nodes/vpn-node/vpn-
      network-accesses/vpn-network-access/te/ - configure TE Endpoint
      mapping.

Lee, et al.              Expires August 25, 2021               [Page 42]
Internet-Draft             TE Service Mapping              February 2021

   o  /l2vpn-ntw/vpn-services/vpn-service/te-service-mapping/te-mapping/
      - configure TE Network mapping.

   o  /l2vpn-ntw/vpn-services/vpn-service/vpn-nodes/vpn-node/vpn-
      network-accesses/vpn-network-access/te/ - configure TE Endpoint
      mapping.

   Unauthorized access to above list can adversely affect the VPN
   service.

   Some of the readable data nodes in the YANG module may be considered
   sensitive or vulnerable in some network environments.  It is thus
   important to control read access (e.g., via get, get-config, or
   notification) to these data nodes.  The TE related parameters
   attached to the VPN service can leak sensitive information about the
   network.  This is applicable to all elements in the yang models
   defined in this document.

   This document has no RPC defined.

9.  IANA Considerations

   This document request the IANA to register six URIs in the "IETF XML
   Registry" [RFC3688].  Following the format in RFC 3688, the following
   registrations are requested -

Lee, et al.              Expires August 25, 2021               [Page 43]
Internet-Draft             TE Service Mapping              February 2021

   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-l3sm-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.
   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-l3nm-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-l2nm-te-service-mapping
   Registrant Contact: The IESG.
   XML: N/A, the requested URI is an XML namespace.

   This document request the IANA to register six YANG modules in the
   "YANG Module Names" registry [RFC6020], as follows -

Lee, et al.              Expires August 25, 2021               [Page 44]
Internet-Draft             TE Service Mapping              February 2021

   Name:      ietf-te-service-mapping-types
   Namespace: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types
   Prefix:    tsmt
   Reference: [This.I-D]

   Name:      ietf-l3sm-te-service-mapping
   Namespace: urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping
   Prefix:    l3-tsm
   Reference: [This.I-D]

   Name:      ietf-l2sm-te-service-mapping
   Namespace: urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping
   Prefix:    l2-tsm
   Reference: [This.I-D]

   Name:      ietf-l1csm-te-service-mapping
   Namespace: urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping
   Prefix:    l1-tsm
   Reference: [This.I-D]

   Name:      ietf-l3nm-te-service-mapping
   Namespace: urn:ietf:params:xml:ns:yang:ietf-l3nm-te-service-mapping
   Prefix:    l3nm-tsm
   Reference: [This.I-D]

   Name:      ietf-l2nm-te-service-mapping
   Namespace: urn:ietf:params:xml:ns:yang:ietf-l2nm-te-service-mapping
   Prefix:    l2nm-tsm
   Reference: [This.I-D]

10.  Acknowledgements

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

11.  References

11.1.  Normative References

   [I-D.ietf-ccamp-l1csm-yang]
              Lee, Y., Lee, K., Zheng, H., Dios, O., and D. Ceccarelli,
              "A YANG Data Model for L1 Connectivity Service Model
              (L1CSM)", draft-ietf-ccamp-l1csm-yang-13 (work in
              progress), November 2020.

Lee, et al.              Expires August 25, 2021               [Page 45]
Internet-Draft             TE Service Mapping              February 2021

   [I-D.ietf-opsawg-l2nm]
              barguil, s., Dios, O., Boucadair, M., Munoz, L., Jalil,
              L., and J. Ma, "A Layer 2 VPN Network YANG Model", draft-
              ietf-opsawg-l2nm-01 (work in progress), November 2020.

   [I-D.ietf-opsawg-l3sm-l3nm]
              barguil, s., Dios, O., Boucadair, M., Munoz, L., and A.
              Aguado, "A Layer 3 VPN Network YANG Model", draft-ietf-
              opsawg-l3sm-l3nm-05 (work in progress), October 2020.

   [I-D.ietf-spring-sr-policy-yang]
              Raza, K., Sawaya, R., Shunwan, Z., Voyer, D., Durrani, M.,
              Matsushima, S., and V. Beeram, "YANG Data Model for
              Segment Routing Policy", draft-ietf-spring-sr-policy-
              yang-00 (work in progress), September 2020.

   [I-D.ietf-teas-actn-vn-yang]
              Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B.
              Yoon, "A YANG Data Model for VN Operation", draft-ietf-
              teas-actn-vn-yang-10 (work in progress), November 2020.

   [I-D.ietf-teas-yang-te]
              Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
              "A YANG Data Model for Traffic Engineering Tunnels, Label
              Switched Paths and Interfaces", draft-ietf-teas-yang-te-25
              (work in progress), July 2020.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January 2004,
              <https://www.rfc-editor.org/info/rfc3688>.

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,
              <https://www.rfc-editor.org/info/rfc6020>.

   [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
              Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
              <https://www.rfc-editor.org/info/rfc6242>.

Lee, et al.              Expires August 25, 2021               [Page 46]
Internet-Draft             TE Service Mapping              February 2021

   [RFC7926]  Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G.,
              Ceccarelli, D., and X. Zhang, "Problem Statement and
              Architecture for Information Exchange between
              Interconnected Traffic-Engineered Networks", BCP 206,
              RFC 7926, DOI 10.17487/RFC7926, July 2016,
              <https://www.rfc-editor.org/info/rfc7926>.

   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
              RFC 7950, DOI 10.17487/RFC7950, August 2016,
              <https://www.rfc-editor.org/info/rfc7950>.

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/info/rfc8040>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8299]  Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki,
              "YANG Data Model for L3VPN Service Delivery", RFC 8299,
              DOI 10.17487/RFC8299, January 2018,
              <https://www.rfc-editor.org/info/rfc8299>.

   [RFC8340]  Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
              BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
              <https://www.rfc-editor.org/info/rfc8340>.

   [RFC8341]  Bierman, A. and M. Bjorklund, "Network Configuration
              Access Control Model", STD 91, RFC 8341,
              DOI 10.17487/RFC8341, March 2018,
              <https://www.rfc-editor.org/info/rfc8341>.

   [RFC8342]  Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
              and R. Wilton, "Network Management Datastore Architecture
              (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
              <https://www.rfc-editor.org/info/rfc8342>.

   [RFC8345]  Clemm, A., Medved, J., Varga, R., Bahadur, N.,
              Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
              Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
              2018, <https://www.rfc-editor.org/info/rfc8345>.

   [RFC8349]  Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
              Routing Management (NMDA Version)", RFC 8349,
              DOI 10.17487/RFC8349, March 2018,
              <https://www.rfc-editor.org/info/rfc8349>.

Lee, et al.              Expires August 25, 2021               [Page 47]
Internet-Draft             TE Service Mapping              February 2021

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC8453]  Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
              Abstraction and Control of TE Networks (ACTN)", RFC 8453,
              DOI 10.17487/RFC8453, August 2018,
              <https://www.rfc-editor.org/info/rfc8453>.

   [RFC8466]  Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG
              Data Model for Layer 2 Virtual Private Network (L2VPN)
              Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October
              2018, <https://www.rfc-editor.org/info/rfc8466>.

   [RFC8776]  Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
              "Common YANG Data Types for Traffic Engineering",
              RFC 8776, DOI 10.17487/RFC8776, June 2020,
              <https://www.rfc-editor.org/info/rfc8776>.

   [RFC8795]  Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
              O. Gonzalez de Dios, "YANG Data Model for Traffic
              Engineering (TE) Topologies", RFC 8795,
              DOI 10.17487/RFC8795, August 2020,
              <https://www.rfc-editor.org/info/rfc8795>.

11.2.  Informative References

   [I-D.ietf-teas-actn-yang]
              Lee, Y., Zheng, H., Ceccarelli, D., Yoon, B., Dios, O.,
              Shin, J., and S. Belotti, "Applicability of YANG models
              for Abstraction and Control of Traffic Engineered
              Networks", draft-ietf-teas-actn-yang-06 (work in
              progress), August 2020.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

   [RFC8199]  Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module
              Classification", RFC 8199, DOI 10.17487/RFC8199, July
              2017, <https://www.rfc-editor.org/info/rfc8199>.

   [RFC8309]  Wu, Q., Liu, W., and A. Farrel, "Service Models
              Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
              <https://www.rfc-editor.org/info/rfc8309>.

Lee, et al.              Expires August 25, 2021               [Page 48]
Internet-Draft             TE Service Mapping              February 2021

Appendix A.  Examples

   This section details a few examples on how the TE-service mapping is
   used in various scenarios.

   Example 1: An L3VPN service with an optimization criteria for the
   underlying TE as delay can be set in the mapping template and then
   augmented to the L3SM service.

   {
     "te-mapping-template":[
       {
         "id": "delay",
         "map-type": "select",
         "optimizations":
           {
             "algorithm":{
               "optimization-metric": [
                 {
                   "metric-type":"path-metric-delay-average"
                 }
               ]
             }
           }
       }
     ]
   }

   The L3SM service can map it to the existing least delay TE resources
   in form of a VN or TE-tunnels.

   Example 2: An L2VPN service with a bandwidth constraint and a hop-
   limit criteria for the underlying TE can be set in the mapping
   template and then augmented to the L2SM service.

Lee, et al.              Expires August 25, 2021               [Page 49]
Internet-Draft             TE Service Mapping              February 2021

   {
     "te-mapping-template":[
       {
         "id": "bw-hop",
         "map-type": "new",
         "path-constraints":{
           "te-bandwidth":{
             "generic":10000
           },
           "path-metric-bounds":{
             "path-metric-bound":[
               {
                 "metric-type":"path-metric-hop",
                 "upper-bound":10
               }
             ]
           }
         }
     ]
   }

   The L2SM service can map it to a new TE resources in form of a VN or
   TE-tunnels.

   Example 3: A VN (VN1) could be created before hand and then
   explicitly mapped to the L2VPN service as shown below.

   <?xml version="1.0"?>
   <l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
   <vpn-services>
        <vpn-service>
         <vpn-id>VPN1</vpn-id>
         <te-service-mapping>
           <te-mapping>
             <map-type>select</map-type>
             <te>
               <vn>VN1</vn>
             </te>
           </te-mapping>
         </te-service-mapping>
        </vpn-service>
   </vpn-services>
   </l2vpn-svc>

   Example 4: A VPN service may want different optimization criteria for
   some of its sites.  The template does not allow for such a case but
   it can be achieved by creating the TE resources separately and then
   mapping them to the service.

Lee, et al.              Expires August 25, 2021               [Page 50]
Internet-Draft             TE Service Mapping              February 2021

Appendix B.  Discussion

   o  While the support to bind a tunnel to the VPN is supported.  We do
      not have a mechanism to map traffic to a path.  The input can come
      from the user.  E.g. the enterprise customer can tell, the traffic
      from source X on port Y should go with delay less than Z.  Further
      discussion is required on how and where to model these.

   o  Support for Calendaring and scheduling TE resources.

Appendix C.  Contributor Addresses

Lee, et al.              Expires August 25, 2021               [Page 51]
Internet-Draft             TE Service Mapping              February 2021

   Adrian Farrel
   Old Dog Consulting

   EMail: adrian@olddog.co.uk

   Italo Busi
   Huawei Technologies

   EMail: Italo.Busi@huawei.com

   Haomian Zheng
   Huawei Technologies

   EMail: zhenghaomian@huawei.com

   Anton Snitser
   Sedonasys

   EMail: antons@sedonasys.com

   SAMIER BARGUIL GIRALDO
   Telefonica

   EMail: samier.barguilgiraldo.ext@telefonica.com

   Oscar Gonzalez de Dios
   Telefonica

   EMail: oscar.gonzalezdedios@telefonica.com

   Carlo Perocchio
   Ericsson

   EMail: carlo.perocchio@ericsson.com

   Kenichi Ogaki
   KDDI
   Email: ke-oogaki@kddi.com

Authors' Addresses

   Young Lee (editor)
   Samsung Electronics

   Email: younglee.tx@gmail.com

Lee, et al.              Expires August 25, 2021               [Page 52]
Internet-Draft             TE Service Mapping              February 2021

   Dhruv Dhody (editor)
   Huawei Technologies
   Divyashree Techno Park, Whitefield
   Bangalore, Karnataka  560066
   India

   Email: dhruv.ietf@gmail.com

   Giuseppe Fioccola
   Huawei Technologies

   Email: giuseppe.fioccola@huawei.com

   Qin Wu (editor)
   Huawei Technologies

   Email: bill.wu@huawei.com

   Daniele Ceccarelli
   Ericsson
   Torshamnsgatan,48
   Stockholm, Sweden

   Email: daniele.ceccarelli@ericsson.com

   Jeff Tantsura
   Apstra

   Email: jefftant.ietf@gmail.com

Lee, et al.              Expires August 25, 2021               [Page 53]
Traffic Engineering (TE) and Service Mapping Yang Modeldraft-ietf-teas-te-service-mapping-yang-07

Traffic Engineering (TE) and Service Mapping Yang Model
draft-ietf-teas-te-service-mapping-yang-07
