Traffic Engineering (TE) and Service Mapping YANG Data Model
draft-ietf-teas-te-service-mapping-yang-17
draft-ietf-teas-te-service-mapping-yang-17
TEAS Working Group Y. Lee, Ed.
Internet-Draft Samsung Electronics
Intended status: Standards Track D. Dhody, Ed.
Expires: 2 August 2025 G. Fioccola
Q. Wu, Ed.
Huawei
D. Ceccarelli
Cisco
J. Tantsura
Nvidia
29 January 2025
Traffic Engineering (TE) and Service Mapping YANG Data Model
draft-ietf-teas-te-service-mapping-yang-17
Abstract
This document provides a YANG data model to map customer service
models (e.g., L3VPN Service Delivery model) to Traffic Engineering
(TE) models (e.g., the TE Tunnel or the Virtual Network (VN) model).
These models are referred to as the TE Service Mapping Model and are
applicable generically to the operator's need for seamless control
and management of their VPN services with underlying TE support.
The models are principally used for monitoring and diagnostics of the
management systems to show how the service requests are mapped onto
underlying network resources 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 2 August 2025.
Lee, et al. Expires 2 August 2025 [Page 1]
Internet-Draft TE Service Mapping January 2025
Copyright Notice
Copyright (c) 2025 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Purpose of TE Service Mapping for Service Model . . . . . 4
1.2. Purpose of TE Service Mapping for Network Model . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 6
1.5. Prefixes in Data Node Names . . . . . . . . . . . . . . . 6
1.6. Refrences . . . . . . . . . . . . . . . . . . . . . . . . 8
2. TE and Service Related Parameters . . . . . . . . . . . . . . 8
2.1. VN/Tunnel Selection Requirements . . . . . . . . . . . . 8
2.2. TE Policy . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1. Availability Requirement . . . . . . . . . . . . . . 9
3. YANG Data Modeling Approach . . . . . . . . . . . . . . . . . 10
3.1. Forward Compatibility . . . . . . . . . . . . . . . . . . 11
3.2. TE and Network Models . . . . . . . . . . . . . . . . . . 11
4. L3VPN Architecture in the ACTN Context . . . . . . . . . . . 12
4.1. Service Mapping . . . . . . . . . . . . . . . . . . . . . 16
4.2. Site Mapping . . . . . . . . . . . . . . . . . . . . . . 16
5. Applicability of TE-Service Mapping in Generic Context . . . 17
6. YANG Data Trees . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Service Mapping Types . . . . . . . . . . . . . . . . . . 17
6.2. Service Models . . . . . . . . . . . . . . . . . . . . . 18
6.2.1. L3SM . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2.2. L2SM . . . . . . . . . . . . . . . . . . . . . . . . 20
6.2.3. L1CSM . . . . . . . . . . . . . . . . . . . . . . . . 21
6.3. Network Models . . . . . . . . . . . . . . . . . . . . . 23
6.3.1. L3NM . . . . . . . . . . . . . . . . . . . . . . . . 23
6.3.2. L2NM . . . . . . . . . . . . . . . . . . . . . . . . 24
7. YANG Data Models . . . . . . . . . . . . . . . . . . . . . . 25
7.1. ietf-te-service-mapping-types . . . . . . . . . . . . . . 25
7.2. Service Models . . . . . . . . . . . . . . . . . . . . . 34
7.2.1. ietf-l3sm-te-service-mapping . . . . . . . . . . . . 34
7.2.2. ietf-l2sm-te-service-mapping . . . . . . . . . . . . 36
Lee, et al. Expires 2 August 2025 [Page 2]
Internet-Draft TE Service Mapping January 2025
7.2.3. ietf-l1csm-te-service-mapping . . . . . . . . . . . . 39
7.3. Network Models . . . . . . . . . . . . . . . . . . . . . 41
7.3.1. ietf-l3nm-te-service-mapping . . . . . . . . . . . . 41
7.3.2. ietf-l2nm-te-service-mapping . . . . . . . . . . . . 43
8. Security Considerations . . . . . . . . . . . . . . . . . . . 45
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 48
11.1. Normative References . . . . . . . . . . . . . . . . . . 48
11.2. Informative References . . . . . . . . . . . . . . . . . 51
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 52
Appendix B. Out of Scope . . . . . . . . . . . . . . . . . . . . 54
Appendix C. Contributor Addresses . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55
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 the 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 a customer 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 to generic
context [RFC8309] as part of Customer Service Model used between
Service Orchestrator and Customer.
[RFC8299] provides an L3VPN service delivery YANG data model for PE-
based VPNs. The scope of that draft is limited to a set of domains
under the control of the same network operator to deliver services
requiring TE tunnels.
[RFC8466] provides an L2VPN service delivery YANG data model for PE-
based VPNs. The scope of that draft is limited to a set of domains
under the control of the same network operator to deliver services
requiring TE tunnels.
Lee, et al. Expires 2 August 2025 [Page 3]
Internet-Draft TE Service Mapping January 2025
[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 the 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 a 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 faults and
performance degradation and so forth.
Section 2 describes a set of TE and service-related parameters that
this document addresses "new and advanced parameters" that are not
included in the service models. Section 3 discusses the YANG
modeling approach.
1.1. Purpose of TE Service Mapping for Service Model
The TE service mapping for the LxSM supports:
Lee, et al. Expires 2 August 2025 [Page 4]
Internet-Draft TE Service Mapping January 2025
* A mapping of the LxSM with the underlying TE resources. The TE
resources could be in the form of VN, set of TE tunnels, TE
abstract topology etc. This mapping can be populated by the
network at the time of realization of the service. It is also
possible to configure the mapping provided one is aware of VN/
tunnels. This mapping model is used only when there is an
awareness of VN or TE by the consumer of the model. Otherwise,
this mapping information is internal and used for monitoring and
diagnostics purposes such as telemetry, auto-scaling, and closed-
loop automation.
* Possibility to request the creation of a new VN/Tunnel to be bound
to LxSM .
* Indication to share the VN/Tunnel sharing (with or without
modification) for the LxSM.
* Support for configuration of underlying TE properties (as opposed
to existing VN or tunnels).
* Provide some additional service characteristics for the LxSM
models.
1.2. Purpose of TE Service Mapping for Network Model
Apart from the service model, the TE mapping is equally applicable to
the Network Models (L3 VPN Service Network Model (L3NM) [RFC9182], L2
VPN Service Network Model (L2NM) [RFC9291] etc.). See Section 3.2
for details.
The TE service mapping for the LxNM supports:
* A mapping of the LxNM with the underlying TE resources. The TE
resources could be in the form of VN, set of TE tunnels, TE
abstract topology etc. This mapping can be populated by the
network or configured. This mapping is useful to understand the
TE realization of the LxVPN as well for monitoring/diagnostic
purposes.
* Possibility to request the creation of a new VN/Tunnel to be bound
to LxNM .
* Indication to share the VN/Tunnel sharing (with or without
modification) for the LxNM.
* Support for configuration of underlying TE properties (as opposed
to existing VN or tunnels).
Lee, et al. Expires 2 August 2025 [Page 5]
Internet-Draft TE Service Mapping January 2025
* Provide some additional service characteristics for the LxNM
models
1.3. 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].
This document uses the term L3SM to refer to the L3VPN Service
Delivery model specified in [RFC8299] and the term L2SM for Layer 2
Virtual Private Network (L2VPN) Service Delivery model specified in
[RFC8466]. The term L3NM refers to the L3VPN network model specified
in [RFC9182] and L2NM for the L2VPN network model specified in
[RFC9291].
1.4. Tree diagram
A simplified graphical representation of the data model is used in
Section 6 of this this document. The meaning of the symbols in these
diagrams is defined in [RFC8340].
1.5. Prefixes in Data Node Names
In this document, the 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 2 August 2025 [Page 6]
Internet-Draft TE Service Mapping January 2025
+========+==================+==================================+
| Prefix | YANG module | Reference |
+========+==================+==================================+
| tsmt | ietf-te-service- | [RFCXXXX] |
| | mapping-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- | [RFCXXXX] |
| | service-mapping | |
+--------+------------------+----------------------------------+
| l2-tsm | ietf-l2sm-te- | [RFCXXXX] |
| | service-mapping | |
+--------+------------------+----------------------------------+
| l3-tsm | ietf-l3sm-te- | [RFCXXXX] |
| | service-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 | [RFC9291] |
| ntw | | |
+--------+------------------+----------------------------------+
| l3vpn- | ietf-l3vpn-ntw | [RFC9182] |
| ntw | | |
+--------+------------------+----------------------------------+
| rt | ietf-routing | [RFC8349] |
+--------+------------------+----------------------------------+
| sr- | ietf-sr-policy | [I-D.ietf-spring-sr-policy-yang] |
| policy | | |
+--------+------------------+----------------------------------+
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.
Lee, et al. Expires 2 August 2025 [Page 7]
Internet-Draft TE Service Mapping January 2025
1.6. Refrences
In the YANG modules specified in this document, the following
additional documents are referenced -
* [RFC8453]: Framework for Abstraction and Control of TE Networks
(ACTN)
* [RFC8795]: YANG Data Model for Traffic Engineering (TE) Topologies
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.
2.1. VN/Tunnel Selection Requirements
In some cases, the service requirements may need additional VN/TE
tunnels to be established. This may occur when there are no suitable
existing VN/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.
* 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 the VPN isolation
requirements. Further, the YANG data model described in Section 4
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. Traffic Isolation: A customer expects that the service traffic
cannot be received by other customers in the same network.
Lee, et al. Expires 2 August 2025 [Page 8]
Internet-Draft TE Service Mapping January 2025
2. Interference Isolation: A customer expects that the service
traffic is not impacted by the existence of other customers or
services in the same network.
3. A combination of both.
* 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
data 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.
* VN/Tunnel Modify - This mode allows the modification of the
properties of the existing VN/tunnel (e.g., bandwidth).
* 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. The path-affinities 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 the 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.
Lee, et al. Expires 2 August 2025 [Page 9]
Internet-Draft TE Service Mapping January 2025
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
Figure 1: Augmented LxSM Model
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 in both service and network models.
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
behaviour of the network. Note that this should be done only if the
operator understands the VN/Tunnel resources and 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.
Lee, et al. Expires 2 August 2025 [Page 10]
Internet-Draft TE Service Mapping January 2025
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 the 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 conform 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 the underlying TE
constructs in the same way as the three existing models are
augmented.
Appendix B highlights some features that are deemed out of the scope
of this document.
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.
Similar to the service model, the existing network models (i.e.,
[RFC9182], and [RFC9291]) are augmented to include the TE and Service
mapping parameters. Figure 2 shows the scope of the Augmented LxNM
Model.
Lee, et al. Expires 2 August 2025 [Page 11]
Internet-Draft TE Service Mapping January 2025
<artwork name="" type="" align="left" alt=""><![CDATA[
+--------------+ +----------------------+ +----------+
| 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 | | | |
| | v | | |
| | .-------------------------. | | |
| | | Service Mapping Function | | | |
| | '-------------------------' | | |
| | | | |
| +-------+------+-----------------+ | |
| | | | |
| | |CMI(VN) | |
| | | | |
Lee, et al. Expires 2 August 2025 [Page 12]
Internet-Draft TE Service Mapping January 2025
| | +--+-------------------+--+ |
| | | v MDSC v | |
| | | .-------------------. | |
| | | | Service Mapping | | |
| | | '-------------------' | |
| | +--+----------+-----------+ |
+---------+------+----------+-------------+
| | |
| +----+--------+ |
| | | |
MPI(VPN/TE models)| | | |MPI(TE/L1 models)
| | | |
+-----+-+---+ +-----+-+----+
| v v | | v v |
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 as 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.
Lee, et al. Expires 2 August 2025 [Page 13]
Internet-Draft TE Service Mapping January 2025
* 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 the 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 the scope of this document.
Lee, et al. Expires 2 August 2025 [Page 14]
Internet-Draft TE Service Mapping January 2025
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 to see the purpose for which the network resources are used.
As shown in Figure 3, the MDSC may be used recursively. For example,
the CNC might map an 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 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.
Lee, et al. Expires 2 August 2025 [Page 15]
Internet-Draft TE Service Mapping January 2025
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
parameters and constraints and network attachment point location.
Suppose multiple attachment points are matched, the management system
can use constraints or other local policies 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, | (Constraint-Type, | |
| | Access | Postal Code, | Group-id,Target Group- | |
| | | State, City, | id) | |
| | | Country 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
Lee, et al. Expires 2 August 2025 [Page 16]
Internet-Draft TE Service Mapping January 2025
As per [RFC8299], a VPN has a particular service topology and as a
consequence, each site belonging to a VPN is assigned a particular
role in this topology. At the time of mapping, the site to the TE
endpoints, the role of the site in a particular VPN topology is also
mapped.
5. Applicability of TE-Service Mapping in Generic Context
As discussed in the Introduction Section, the models presented in
this document is 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 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
Lee, et al. Expires 2 August 2025 [Page 17]
Internet-Draft TE Service Mapping January 2025
| +--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
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 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
Lee, et al. Expires 2 August 2025 [Page 18]
Internet-Draft TE Service Mapping January 2025
| +--rw protection-type? identityref
| +--rw availability-type? identityref
+--rw (te)?
| +--:(vn)
| | +--rw vn*
| | -> /vn:virtual-network/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/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/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)
Lee, et al. Expires 2 August 2025 [Page 19]
Internet-Draft TE Service Mapping January 2025
| +--rw vn-ap* -> /vn:access-point/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 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/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:
Lee, et al. Expires 2 August 2025 [Page 20]
Internet-Draft TE Service Mapping January 2025
+--rw (te)?
+--:(vn)
| +--rw vn-ap* -> /vn:access-point/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/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/id
+--:(te)
+--rw ltp* te-types:te-tp-id
6.2.3. L1CSM
Lee, et al. Expires 2 August 2025 [Page 21]
Internet-Draft TE Service Mapping January 2025
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/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/id
+--:(te)
+--rw ltp* te-types:te-tp-id
Lee, et al. Expires 2 August 2025 [Page 22]
Internet-Draft TE Service Mapping January 2025
6.3. Network Models
6.3.1. L3NM
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/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)?
Lee, et al. Expires 2 August 2025 [Page 23]
Internet-Draft TE Service Mapping January 2025
+--:(vn)
| +--rw vn-ap* -> /vn:access-point/ap/vn-ap/id
+--:(te)
+--rw ltp* te-types:te-tp-id
6.3.2. L2NM
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/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
Lee, et al. Expires 2 August 2025 [Page 24]
Internet-Draft TE Service Mapping January 2025
/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/id
+--:(te)
+--rw ltp* te-types:te-tp-id
7. YANG Data Models
The YANG modules are as follows:
7.1. ietf-te-service-mapping-types
<CODE BEGINS> file "ietf-te-service-mapping-types@2025-01-29.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 {
Lee, et al. Expires 2 August 2025 [Page 25]
Internet-Draft TE Service Mapping January 2025
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.)
Lee, et al. Expires 2 August 2025 [Page 26]
Internet-Draft TE Service Mapping January 2025
Copyright (c) 2025 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 2025-01-29 {
description
"Initial revision.";
reference
"RFC XXXX: Traffic Engineering (TE) 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 bound to the service.";
Lee, et al. Expires 2 August 2025 [Page 27]
Internet-Draft TE Service Mapping January 2025
}
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 are 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
*/
Lee, et al. Expires 2 August 2025 [Page 28]
Internet-Draft TE Service Mapping January 2025
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
Lee, et al. Expires 2 August 2025 [Page 29]
Internet-Draft TE Service Mapping January 2025
"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: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
Lee, et al. Expires 2 August 2025 [Page 30]
Internet-Draft TE Service Mapping January 2025
"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.";
}
Lee, et al. Expires 2 August 2025 [Page 31]
Internet-Draft TE Service Mapping January 2025
}
grouping te-endpoint-ref {
description
"The reference to TE endpoints.";
choice te {
description
"TE endpoint is referenced 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: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 {
Lee, et al. Expires 2 August 2025 [Page 32]
Internet-Draft TE Service Mapping January 2025
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.";
Lee, et al. Expires 2 August 2025 [Page 33]
Internet-Draft TE Service Mapping January 2025
}
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 constraints and optimization
criteria has been specified";
}
}
}
<CODE ENDS>
7.2. Service Models
7.2.1. ietf-l3sm-te-service-mapping
<CODE BEGINS> file "ietf-l3sm-te-service-mapping@2025-01-29.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";
}
Lee, et al. Expires 2 August 2025 [Page 34]
Internet-Draft TE Service Mapping January 2025
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) 2025 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 2025-01-29 {
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
Lee, et al. Expires 2 August 2025 [Page 35]
Internet-Draft TE Service Mapping January 2025
"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>
7.2.2. ietf-l2sm-te-service-mapping
Lee, et al. Expires 2 August 2025 [Page 36]
Internet-Draft TE Service Mapping January 2025
<CODE BEGINS> file "ietf-l2sm-te-service-mapping@2025-01-29.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) 2025 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).
Lee, et al. Expires 2 August 2025 [Page 37]
Internet-Draft TE Service Mapping January 2025
This version of this YANG module is part of RFC XXXX; see the
RFC itself for full legal notices.";
revision 2025-01-29 {
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 resources 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 augments 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";
Lee, et al. Expires 2 August 2025 [Page 38]
Internet-Draft TE Service Mapping January 2025
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>
7.2.3. ietf-l1csm-te-service-mapping
<CODE BEGINS> file "ietf-l1csm-te-service-mapping@2025-01-29.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
Lee, et al. Expires 2 August 2025 [Page 39]
Internet-Draft TE Service Mapping January 2025
<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) 2025 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 2025-01-29 {
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 resources have not been mapped yet.";
uses tsmt:te-mapping;
}
}
augment "/l1csm:l1-connectivity/l1csm:access/l1csm:unis/"
+ "l1csm:uni" {
Lee, et al. Expires 2 August 2025 [Page 40]
Internet-Draft TE Service Mapping January 2025
description
"This augments the L1CSM UNI with a reference
to TE endpoints";
uses tsmt:te-endpoint-ref;
}
}
<CODE ENDS>
7.3. Network Models
7.3.1. ietf-l3nm-te-service-mapping
<CODE BEGINS> file "ietf-l3nm-te-service-mapping@2025-01-29.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).
Lee, et al. Expires 2 August 2025 [Page 41]
Internet-Draft TE Service Mapping January 2025
Copyright (c) 2025 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 2025-01-29 {
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 resources 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 augments the L3NM network-access with a reference
to TE endpoints when underlying TE is used";
uses tsmt:te-endpoint-ref;
Lee, et al. Expires 2 August 2025 [Page 42]
Internet-Draft TE Service Mapping January 2025
}
}
<CODE ENDS>
7.3.2. ietf-l2nm-te-service-mapping
<CODE BEGINS> file "ietf-l2nm-te-service-mapping@2025-01-29.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) 2025 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
Lee, et al. Expires 2 August 2025 [Page 43]
Internet-Draft TE Service Mapping January 2025
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 2025-01-29 {
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 resources 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 augments the L2NM network-access with a reference
to TE endpoints when underlying TE is used";
uses tsmt:te-endpoint-ref;
}
//augment
}
Lee, et al. Expires 2 August 2025 [Page 44]
Internet-Draft TE Service Mapping January 2025
<CODE ENDS>
8. Security Considerations
The YANG modules defined in this document are designed to be accessed
via network management protocols 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 that 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.
Lee, et al. Expires 2 August 2025 [Page 45]
Internet-Draft TE Service Mapping January 2025
* /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 the 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 requests 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 2 August 2025 [Page 46]
Internet-Draft TE Service Mapping January 2025
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 2 August 2025 [Page 47]
Internet-Draft TE Service Mapping January 2025
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 the YANGDOCTOR review.
11. References
11.1. Normative References
Lee, et al. Expires 2 August 2025 [Page 48]
Internet-Draft TE Service Mapping January 2025
[I-D.ietf-ccamp-l1csm-yang]
Lee, Y., Lee, K., Zheng, H., de Dios, O. G., and D.
Ceccarelli, "A YANG Data Model for L1 Connectivity Service
Model (L1CSM)", Work in Progress, Internet-Draft, draft-
ietf-ccamp-l1csm-yang-26, 11 April 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-
l1csm-yang-26>.
[I-D.ietf-spring-sr-policy-yang]
Raza, S. K., Saleh, T., Shunwan, Z., Voyer, D., Durrani,
M., Matsushima, S., and V. P. Beeram, "YANG Data Model for
Segment Routing Policy", Work in Progress, Internet-Draft,
draft-ietf-spring-sr-policy-yang-04, 22 November 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
sr-policy-yang-04>.
[I-D.ietf-teas-actn-vn-yang]
Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. Y.
Yoon, "A YANG Data Model for Virtual Network (VN)
Operations", Work in Progress, Internet-Draft, draft-ietf-
teas-actn-vn-yang-29, 22 June 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
actn-vn-yang-29>.
[I-D.ietf-teas-yang-te]
Saad, T., Gandhi, R., Liu, X., Beeram, V. P., and I.
Bryskin, "A YANG Data Model for Traffic Engineering
Tunnels, Label Switched Paths and Interfaces", Work in
Progress, Internet-Draft, draft-ietf-teas-yang-te-37, 9
October 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-teas-yang-te-37>.
[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>.
[RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G.,
Ceccarelli, D., and X. Zhang, "Problem Statement and
Architecture for Information Exchange between
Lee, et al. Expires 2 August 2025 [Page 49]
Internet-Draft TE Service Mapping January 2025
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>.
[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>.
[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>.
Lee, et al. Expires 2 August 2025 [Page 50]
Internet-Draft TE Service Mapping January 2025
[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>.
[RFC9182] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M.,
Ed., Munoz, L., and A. Aguado, "A YANG Network Data Model
for Layer 3 VPNs", RFC 9182, DOI 10.17487/RFC9182,
February 2022, <https://www.rfc-editor.org/info/rfc9182>.
[RFC9291] Boucadair, M., Ed., Gonzalez de Dios, O., Ed., Barguil,
S., and L. Munoz, "A YANG Network Data Model for Layer 2
VPNs", RFC 9291, DOI 10.17487/RFC9291, September 2022,
<https://www.rfc-editor.org/info/rfc9291>.
11.2. Informative References
[I-D.dhody-teas-te-traffic-yang]
Dhody, D., "Traffic Mapping YANG model for Traffic
Engineering (TE)", Work in Progress, Internet-Draft,
draft-dhody-teas-te-traffic-yang-05, 20 October 2024,
<https://datatracker.ietf.org/doc/html/draft-dhody-teas-
te-traffic-yang-05>.
[I-D.ietf-teas-actn-yang]
Lee, Y., Zheng, H., Ceccarelli, D., Yoon, B. Y., and S.
Belotti, "Applicability of YANG models for Abstraction and
Control of Traffic Engineered Networks", Work in Progress,
Internet-Draft, draft-ietf-teas-actn-yang-11, 7 March
2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
teas-actn-yang-11>.
[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>.
Lee, et al. Expires 2 August 2025 [Page 51]
Internet-Draft TE Service Mapping January 2025
[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>.
[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>.
Appendix A. Examples
This section details a few examples of how the TE-service mapping is
used in various scenarios.
Example 1: An L3VPN service with 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 the form of 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 2 August 2025 [Page 52]
Internet-Draft TE Service Mapping January 2025
{
"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 resource in the form of a VN
or TE-tunnels.
Example 3: A VN (VN1) could be created beforehand and then explicitly
mapped to the L2VPN service as shown below.
Lee, et al. Expires 2 August 2025 [Page 53]
Internet-Draft TE Service Mapping January 2025
{
"ietf-vn:virtual-network": {
"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 calendaring.
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 a 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
Lee, et al. Expires 2 August 2025 [Page 54]
Internet-Draft TE Service Mapping January 2025
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 2 August 2025 [Page 55]
Internet-Draft TE Service Mapping January 2025
Dhruv Dhody (editor)
Huawei
India
Email: dhruv.ietf@gmail.com
Giuseppe Fioccola
Huawei
Email: giuseppe.fioccola@huawei.com
Qin Wu (editor)
Huawei
Email: bill.wu@huawei.com
Daniele Ceccarelli
Cisco
Email: daniele.ietf@gmail.com
Jeff Tantsura
Nvidia
Email: jefftant.ietf@gmail.com
Lee, et al. Expires 2 August 2025 [Page 56]