Traffic Engineering (TE) and Service Mapping YANG Data Model

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 15 March 2024.¶

Copyright Notice

Copyright (c) 2023 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

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 data models have been produced to allow configuration or modeling of a variety of network devices, protocol instances, and network services. YANG data models have been classified in [RFC8199] and [RFC8309].¶

Framework for Abstraction and Control of Traffic Engineered Networks (ACTN) [RFC8453] introduces an architecture to support virtual network services and connectivity services. [I-D.ietf-teas-actn-vn-yang] defines a YANG data 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 data 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 data 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 data 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.¶

[I-D.ietf-ccamp-l1csm-yang] provides a L1 connectivity service delivery YANG data 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]:¶

• Customer mapping/translation function: This function is to map customer requests/commands into network provisioning requests that can be sent to the PNC according to the business policies that have been provisioned statically or dynamically. Specifically, it provides mapping and translation of a customer's service request into a set of parameters that are specific to a network type and technology such that the network configuration process is made possible.¶
• Virtual service coordination function: This function translates customer service-related information into virtual network service operations in order to seamlessly operate virtual networks while meeting a customer's service requirements. In the context of ACTN, service/virtual service coordination includes a number of service orchestration functions such as multi-destination load balancing, guarantees of service quality, bandwidth and throughput. It also includes notifications for service fault and performance degradation and so forth.¶

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

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 data models defined in this document.¶

3. YANG Data 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

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 mapping could be made to any underlying TE resources such as VN, TE topology abstract node (and its connectivity matrix), set of TE tunnels etc. This flexibility from the modeling point of view allows for various use cases at both service and network model.¶

The role of the augmented LxSM 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. Note that this should be done only if the operator understands the VN/Tunnel resources and the the MDSC is willing to share that information. 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. 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 data models defined in this document conforms to the Network Management Datastore Architecture (NMDA) [RFC8342].¶

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

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 |  | |    |
               | |  +-----------+--------------+  | |    |
               | |              |                 | |    |
               | +-------+------|-----------------+ |    |
               |         |      |                   |    |
               |         |      |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    \
                            +-------------------------+

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

• 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.¶
• MDSC: This entity is responsible for coordinating a L3VPN service request (expressed via the Augmented L3SM) with the IP/MPLS PNC and the Transport PNC. For TE services, one of the key responsibilities of the MDSC is to coordinate with both the IP PNC and the Transport PNC for the mapping of the Augmented L3VPN Service Model to the ACTN VN model. In the VN/TE-tunnel binding case, the MDSC will need to coordinate with the Transport PNC to dynamically create the TE-tunnels in the transport network as needed. These tunnels are added as links in the IP/MPLS Layer topology. The MDSC coordinates with IP/MPLS PNC to create the TE- tunnels in the IP/MPLS layer, as part of the ACTN VN creation.¶

• PNC: The Provisioning Network Controller is responsible for configuring and operating the network devices. Figure 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.¶

• CMI: The CNC-MDSC Interface is used to communicate service requests from the customer to the operator. The requests may be expressed as Augmented VPN service requests (L2SM, L3SM), as connectivity requests (L1CSM), or as virtual network requests (ACTN VN).¶
• MPI: The MDSC-PNC Interface is used by the MDSC to orchestrate networks under the control of PNCs. The requests on this interface may use TE tunnel models, TE topology models, VPN network configuration models or layer one connectivity models.¶
• SBI: The Southbound Interface is used by the PNC to control network devices and is out of scope for this document.¶

The TE Service Mapping Model as described in this document can be used to see the mapping between service models and VN models and TE Tunnel/Topology models. That mapping may occur in the CNC if a service request is mapped to a VN request. Or it may occur in the MDSC where a service request is mapped to a TE tunnel, TE topology, or VPN network configuration model. The TE Service Mapping Model may be read from the CNC or MDSC to understand how the mapping has been made and to see the purpose for which network resources are used.¶

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

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

   1. The Transport PNC creates the corresponding TE tunnel matching with the access point and egress point.¶
   2. 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.¶

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

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 type                identityref
        +--rw path-constraints
        |  +--rw te-bandwidth
        |  |  +--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

module: ietf-l3sm-te-service-mapping

  augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services
            /l3vpn-svc:vpn-service:
    +--rw te-service-mapping!
       +--rw type?                           identityref
       +--rw te-policy
       |  +--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 protection-type?          identityref
       |  +--rw availability-type?        identityref
       +--rw (te)?
       |  +--:(vn)
       |  |  +--rw vn*
       |  |          -> /vn:virtual-network/vn/vn-id
       |  +--:(te-topo)
       |  |  +--rw te-topology-identifier
       |  |  |  +--rw provider-id?   te-global-id
       |  |  |  +--rw client-id?     te-global-id
       |  |  |  +--rw topology-id?   te-topology-id
       |  |  +--rw abstract-node?
       |  |          -> /nw:networks/network/node/node-id
       |  +--:(te-tunnel)
       |     +--rw te-tunnel*                te:tunnel-ref
       |     +--rw sr-policy* [headend color-ref endpoint-ref]
       |             {sr-policy}?
       |        +--rw headend         inet:ip-address-no-zone
       |        +--rw color-ref       leafref
       |        +--rw endpoint-ref    leafref
       +--rw 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:access-point/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:access-point/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: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:access-point/ap/vn-ap/vn-ap-id
       +--:(te)
          +--rw ltp*     te-types:te-tp-id

module: ietf-l2sm-te-service-mapping

  augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services
            /l2vpn-svc:vpn-service:
    +--rw te-service-mapping!
       +--rw type?                           identityref
       +--rw te-policy
       |  +--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 protection-type?          identityref
       |  +--rw availability-type?        identityref
       +--rw (te)?
       |  +--:(vn)
       |  |  +--rw vn*
       |  |          -> /vn:virtual-network/vn/vn-id
       |  +--:(te-topo)
       |  |  +--rw te-topology-identifier
       |  |  |  +--rw provider-id?   te-global-id
       |  |  |  +--rw client-id?     te-global-id
       |  |  |  +--rw topology-id?   te-topology-id
       |  |  +--rw abstract-node?
       |  |          -> /nw:networks/network/node/node-id
       |  +--:(te-tunnel)
       |     +--rw te-tunnel*                te:tunnel-ref
       |     +--rw sr-policy* [headend color-ref endpoint-ref]
       |             {sr-policy}?
       |        +--rw headend         inet:ip-address-no-zone
       |        +--rw color-ref       leafref
       |        +--rw endpoint-ref    leafref
       +--rw 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:access-point/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: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:access-point/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:access-point/ap/vn-ap/vn-ap-id
       +--:(te)
          +--rw ltp*     te-types:te-tp-id

module: ietf-l1csm-te-service-mapping

  augment /l1csm:l1-connectivity/l1csm:services/l1csm:service:
    +--rw te-service-mapping!
       +--rw type?                           identityref
       +--rw te-policy
       |  +--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 protection-type?          identityref
       |  +--rw availability-type?        identityref
       +--rw (te)?
       |  +--:(vn)
       |  |  +--rw vn*
       |  |          -> /vn:virtual-network/vn/vn-id
       |  +--:(te-topo)
       |  |  +--rw te-topology-identifier
       |  |  |  +--rw provider-id?   te-global-id
       |  |  |  +--rw client-id?     te-global-id
       |  |  |  +--rw topology-id?   te-topology-id
       |  |  +--rw abstract-node?
       |  |          -> /nw:networks/network/node/node-id
       |  +--:(te-tunnel)
       |     +--rw te-tunnel*                te:tunnel-ref
       |     +--rw sr-policy* [headend color-ref endpoint-ref]
       |             {sr-policy}?
       |        +--rw headend         inet:ip-address-no-zone
       |        +--rw color-ref       leafref
       |        +--rw endpoint-ref    leafref
       +--rw 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:access-point/ap/vn-ap/vn-ap-id
       +--:(te)
          +--rw ltp*     te-types:te-tp-id

module: ietf-l3nm-te-service-mapping

  augment /l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services
            /l3vpn-ntw:vpn-service:
    +--rw te-service-mapping!
       +--rw type?                           identityref
       +--rw te-policy
       |  +--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 protection-type?          identityref
       |  +--rw availability-type?        identityref
       +--rw (te)?
       |  +--:(vn)
       |  |  +--rw vn*
       |  |          -> /vn:virtual-network/vn/vn-id
       |  +--:(te-topo)
       |  |  +--rw te-topology-identifier
       |  |  |  +--rw provider-id?   te-global-id
       |  |  |  +--rw client-id?     te-global-id
       |  |  |  +--rw topology-id?   te-topology-id
       |  |  +--rw abstract-node?
       |  |          -> /nw:networks/network/node/node-id
       |  +--:(te-tunnel)
       |     +--rw te-tunnel*                te:tunnel-ref
       |     +--rw sr-policy* [headend color-ref endpoint-ref]
       |             {sr-policy}?
       |        +--rw headend         inet:ip-address-no-zone
       |        +--rw color-ref       leafref
       |        +--rw endpoint-ref    leafref
       +--rw 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:access-point/ap/vn-ap/vn-ap-id
       +--:(te)
          +--rw ltp*     te-types:te-tp-id

module: ietf-l2nm-te-service-mapping

  augment /l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services
            /l2vpn-ntw:vpn-service:
    +--rw te-service-mapping!
       +--rw type?                           identityref
       +--rw te-policy
       |  +--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 protection-type?          identityref
       |  +--rw availability-type?        identityref
       +--rw (te)?
       |  +--:(vn)
       |  |  +--rw vn*
       |  |          -> /vn:virtual-network/vn/vn-id
       |  +--:(te-topo)
       |  |  +--rw te-topology-identifier
       |  |  |  +--rw provider-id?   te-global-id
       |  |  |  +--rw client-id?     te-global-id
       |  |  |  +--rw topology-id?   te-topology-id
       |  |  +--rw abstract-node?
       |  |          -> /nw:networks/network/node/node-id
       |  +--:(te-tunnel)
       |     +--rw te-tunnel*                te:tunnel-ref
       |     +--rw sr-policy* [headend color-ref endpoint-ref]
       |             {sr-policy}?
       |        +--rw headend         inet:ip-address-no-zone
       |        +--rw color-ref       leafref
       |        +--rw endpoint-ref    leafref
       +--rw 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:access-point/ap/vn-ap/vn-ap-id
       +--:(te)
          +--rw ltp*     te-types:te-tp-id

7. YANG Data Models

The YANG modules are as follows:¶

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

module ietf-te-service-mapping-types {
  yang-version 1.1;
  namespace
    "urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types";
  prefix tsmt;

  /* Import inet-types */

  import ietf-inet-types {
    prefix inet;
    reference
      "RFC 6991: Common YANG Data Types";
  }

  /* Import te-types */

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

  /* Import network module */

  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
      "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:   <https://datatracker.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) 2023 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 Revised 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.";

  revision 2023-09-12 {
    description
      "Initial revision.";
    reference
      "RFC XXXX:  Traffic Engineering and Service Mapping Yang Data
       Model";
  }

  /*
   * 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 traffic-isolation {
    base new;
    description
      "Traffic isolation: a customer expects that the service
       traffic cannot be received by other customers in the
       same network.";
  }

  identity interference-isolation {
    base new;
    description
      "Interference isolation: a customer expects that the
       service traffic is not impacted by the existence of
       other customers or services in the same network.";
  }

  identity traffic-interference-isolation {
    base new;
    description
      "Both Traffic and Interference isolation is enabled.";
  }

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

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

  identity 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;
    description
      "level 4: 99.9%";
  }

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

  identity level-unspecified {
    base availability-type;
    description
      "level unspecified";
  }

  /*
   * 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
        "The service (e.g. VPN) can be mapped to a VN, TE-Topology,
         Tunnel, SR Policy etc.";
      case vn {
        leaf-list vn {
          type leafref {
            path "/vn:virtual-network/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 {
        /*An identifier to the TE Topology Model where the abstract
          nodes and links of the Topology can be found for Type 2
          VNs as defined in RFC 8453*/
        uses te-types:te-topology-identifier;
        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";
          /*Ideally Headend should be part of SR-Policy (but is
            missing) - This is retained to keep track of this*/
          key "headend color-ref endpoint-ref";
          description
            "SR Policy";
          leaf headend {
            type inet:ip-address-no-zone;
            description
              "The headend node for the SR Policy";
          }
          leaf 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 endpoint-ref {
            type leafref {
              path
                "/rt:routing/sr-policy:segment-routing"
              + "/sr-policy:traffic-engineering/sr-policy:policies"
              + "/sr-policy:policy/sr-policy:endpoint";
            }
            description
              "Reference to sr-policy endpoint";
          }
        }
      }
    }
    leaf 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 te-endpoint-ref {
    description
      "The reference to TE endpoints.";
    choice te {
      description
        "TE endpoint is refrenced by VN Access Point (VNAP) or TE
         Link Termination Point (LTP)";
      case vn {
        leaf-list vn-ap {
          type leafref {
            path "/vn:access-point/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-list 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";
        }
      }
    }
  }

  grouping te-policy {
    description
      "Various underlying TE policy requirements";
    uses te-types:generic-path-affinities;
    leaf protection-type {
      type identityref {
        base te-types:lsp-protection-type;
      }
      default "te-types:lsp-protection-unprotected";
      description
        "Desired protection level for the underlying
         TE resources";
    }
    leaf availability-type {
      type identityref {
        base availability-type;
      }
      default "level-unspecified";
      description
        "Availability Requirement for the Service";
    }
  }

  grouping te-mapping {
    description
      "Mapping between Services and TE";
    leaf type {
      type identityref {
        base map-type;
      }
      default "none";
      description
        "Isolation Requirements, Tunnel Bind or
         Tunnel Selection";
    }
    container te-policy {
      uses te-policy;
      description
        "Desired Underlying TE Policy";
    }
    uses te-ref;
  }

  /*
   * containers
   */

  container te-mapping-templates {
    description
      "The templates include 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 type {
        type identityref {
          base map-type;
        }
        must "0 = derived-from-or-self(.,'none')" {
          error-message "The map-type must be other than "
                      + "none";
        }
        mandatory true;
        description
          "Map type for the VN/Tunnel creation/
           selection.";
      }
      uses te-types:generic-path-constraints;
      uses te-types:generic-path-optimization;
      description
        "Template - only id and type are mandatory,
         if no other parameters are present, it
         indicates that no contraints and optimization
         criteria has been specified";
    }
  }
}

<CODE ENDS>

<CODE BEGINS> file "ietf-l3sm-te-service-mapping@2023-09-12.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:   <https://datatracker.ietf.org/wg/teas/about/>
     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) 2023 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 Revised 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.";

  revision 2023-09-12 {
    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"
  + "/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>

<CODE BEGINS> file "ietf-l2sm-te-service-mapping@2023-09-12.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 Data
       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:   <https://datatracker.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
     Virtual Private Network (L2VPN) Service Delivery to the TE and
     Virtual Network (VN).

     Copyright (c) 2023 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 Revised 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.";

  revision 2023-09-12 {
    description
      "Initial revision.";
    reference
      "RFC XXXX:  Traffic Engineering and Service Mapping Yang Data
       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 is relying on underlying TE";
      description
        "Container to augment L2SM to TE parameters and mapping
         If no other parameters exist, it indicates that the
         underlying TE resouces have not been mapped yet.";
      uses tsmt:te-mapping;
    }
  }

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

  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>

<CODE BEGINS> file "ietf-l1csm-te-service-mapping@2023-09-12.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 Data
       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:   <https://datatracker.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
     Virtual Network (VN).

     Copyright (c) 2023 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 Revised 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.";

  revision 2023-09-12 {
    description
      "Initial revision.";
    reference
      "RFC XXXX:  Traffic Engineering and Service Mapping Yang Data
       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 is relying on underlying TE";
      description
        "Container to augment L1CSM to TE parameters and mapping.
         If no other parameters exist, it indicates that the
         underlying TE resouces have not been mapped yet.";
      uses tsmt:te-mapping;
    }
  }

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

<CODE ENDS>

<CODE BEGINS> file "ietf-l3nm-te-service-mapping@2023-09-12.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 Data
       Model";
  }
  import ietf-l3vpn-ntw {
    prefix l3vpn-ntw;
    reference
      "RFC 9182: A YANG Network Data Model for Layer 3 VPNs";
  }

  organization
    "IETF Traffic Engineering Architecture and Signaling (TEAS)
     Working Group";
  contact
    "WG Web:   <https://datatracker.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
     VPNs network model to the TE and Virtual Network (VN).

     Copyright (c) 2023 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 Revised 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.";

  revision 2023-09-12 {
    description
      "Initial revision.";
    reference
      "RFC XXXX:  Traffic Engineering and Service Mapping Yang Data
       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 is relying on underlying TE";
      description
        "Container to augment l3nm to TE parameters and mapping.
         If no other parameters exist, it indicates that the
         underlying TE resouces have not been mapped yet.";
      uses tsmt:te-mapping;
    }
  }

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

<CODE ENDS>

<CODE BEGINS> file "ietf-l2nm-te-service-mapping@2023-09-12.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 Data
       Model";
  }
  import ietf-l2vpn-ntw {
    prefix l2vpn-ntw;
    reference
      "RFC 9291: A Layer 2 VPN Network YANG Model";
  }

  organization
    "IETF Traffic Engineering Architecture and Signaling (TEAS)
     Working Group";
  contact
    "WG Web:   <https://datatracker.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 Virtual Network (VN).

     Copyright (c) 2023 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 Revised 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.";
  revision 2023-09-12 {
    description
      "Initial revision.";
    reference
      "RFC XXXX:  Traffic Engineering and Service Mapping Yang Data
       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 is relying on underlying TE";
      description
        "Container to augment l2nm to TE parameters and mapping.
         If no other parameters exist, it indicates that the
         underlying TE resouces have not been mapped yet.";
      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>

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

• /l3vpn-svc/vpn-services/vpn-service/te-service-mapping/te-mapping/ - can configure TE Service mapping.¶
• /l3vpn-svc/sites/site/site-network-accesses/site-network-access/te/ - can configure TE Endpoint mapping.¶
• /l2vpn-svc/vpn-services/vpn-service/te-service-mapping/te-mapping/ - can configure TE Service mapping.¶
• /l2vpn-svc/sites/site/site-network-accesses/site-network-access/te/ - can configure TE Endpoint mapping.¶
• /l1-connectivity/services/service/te-service-mapping/te-mapping/ - can configure TE Service mapping.¶
• /l1-connectivity/access/unis/uni/te/ - can configure TE Endpoint mapping.¶
• /l3vpn-ntw/vpn-services/vpn-service/te-service-mapping/te-mapping/ - can configure TE Network mapping.¶
• /l3vpn-ntw/vpn-services/vpn-service/vpn-nodes/vpn-node/vpn-network-accesses/vpn-network-access/te/ - can configure TE Endpoint mapping.¶
• /l2vpn-ntw/vpn-services/vpn-service/te-service-mapping/te-mapping/ - can configure TE Network mapping.¶
• /l2vpn-ntw/vpn-services/vpn-service/vpn-nodes/vpn-node/vpn-network-accesses/vpn-network-access/te/ - can 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 data 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 -¶

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

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

Thanks to Xufeng Liu for YANGDOCTOR review.¶

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

{
  "ietf-te-service-mapping-types:te-mapping-templates": {
    "te-mapping-template": [
      {
        "id": "delay",
        "description": "delay based template",
        "type": "select",
        "optimizations": {
          "optimization-metric": [
            {
              "metric-type": "ietf-te-types: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.¶

   {
     "ietf-te-service-mapping-types:te-mapping-templates": {
       "te-mapping-template": [
         {
           "id": "bw-hop",
           "description": "Bandwidth and hop limit",
           "type": "new",
           "path-constraints": {
             "te-bandwidth": {
               "generic": "0x1p10"
             },
             "path-metric-bounds": {
               "path-metric-bound": [
                 {
                   "metric-type": "ietf-te-types: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.¶

{
  "ietf-vn:virtual-network": {
    "vn": [
      {
        "vn-id": "VN1"
      }
    ]
  }
}
{
 "ietf-l2vpn-svc:vpn-services": {
  "vpn-service":[
   {
        "vpn-id": "VPN1",
        "ietf-l2sm-te-service-mapping:te-service-mapping":{
          "te-mapping":"select",
          "te":{
            "vn":"VN1"
          }
        }
   }
  ]
 }
}

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

Appendix B. Out of Scope

Scheduling is currently out of scope, although an operator could use their own scheduling mechanism on top of this YANG data model. In future augmentations to this model might also be designed to integrate scheduling and calendering.¶

Note that the mechanism to map traffic (for example the enterprise customer can tell, the traffic from source X on port Y should go on a path with delay less than Z) can be via local configuration or through a YANG data model developed in the future (See one such attempt at [I-D.dhody-teas-te-traffic-yang]).¶

Appendix C. Contributor Addresses

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