< draft-ietf-teas-te-service-mapping-yang-05.txt   draft-ietf-teas-te-service-mapping-yang-06.txt >
TEAS Working Group Y. Lee, Ed. TEAS Working Group Y. Lee, Ed.
Internet-Draft Samsung Electronics Internet-Draft Samsung Electronics
Intended status: Standards Track D. Dhody, Ed. Intended status: Standards Track D. Dhody, Ed.
Expires: May 6, 2021 G. Fioccola Expires: August 24, 2021 G. Fioccola
Q. Wu, Ed. Q. Wu, Ed.
Huawei Technologies Huawei Technologies
D. Ceccarelli D. Ceccarelli
Ericsson Ericsson
J. Tantsura J. Tantsura
Apstra Apstra
November 2, 2020 February 20, 2021
Traffic Engineering (TE) and Service Mapping Yang Model Traffic Engineering (TE) and Service Mapping Yang Model
draft-ietf-teas-te-service-mapping-yang-05 draft-ietf-teas-te-service-mapping-yang-06
Abstract Abstract
This document provides a YANG data model to map customer service This document provides a YANG data model to map customer service
models (e.g., the L3VPN Service Model (L3SM)) to Traffic Engineering models (e.g., the L3VPN Service Model (L3SM)) to Traffic Engineering
(TE) models (e.g., the TE Tunnel or the Virtual Network (VN) model). (TE) models (e.g., the TE Tunnel or the Virtual Network (VN) model).
This model is referred to as TE Service Mapping Model and is This model is referred to as TE Service Mapping Model and is
applicable generically to the operator's need for seamless control applicable generically to the operator's need for seamless control
and management of their VPN services with TE tunnel support. and management of their VPN services with TE tunnel support.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 6, 2021. This Internet-Draft will expire on August 24, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1. Requirements Language . . . . . . . . . . . . . . . . 5 1.1.1. Requirements Language . . . . . . . . . . . . . . . . 5
1.2. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 5 1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 5
2. TE and Service Related Parameters . . . . . . . . . . . . . . 6 2. TE and Service Related Parameters . . . . . . . . . . . . . . 6
2.1. VN/Tunnel Selection Requirements . . . . . . . . . . . . 7 2.1. VN/Tunnel Selection Requirements . . . . . . . . . . . . 7
2.2. Availability Requirement . . . . . . . . . . . . . . . . 8 2.2. TE Policy . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. Availability Requirement . . . . . . . . . . . . . . 8
3. YANG Modeling Approach . . . . . . . . . . . . . . . . . . . 8 3. YANG Modeling Approach . . . . . . . . . . . . . . . . . . . 8
3.1. Forward Compatibility . . . . . . . . . . . . . . . . . . 9 3.1. Forward Compatibility . . . . . . . . . . . . . . . . . . 9
3.2. TE and Network Models . . . . . . . . . . . . . . . . . . 9 3.2. TE and Network Models . . . . . . . . . . . . . . . . . . 9
4. L3VPN Architecture in the ACTN Context . . . . . . . . . . . 10 4. L3VPN Architecture in the ACTN Context . . . . . . . . . . . 10
4.1. Service Mapping . . . . . . . . . . . . . . . . . . . . . 13 4.1. Service Mapping . . . . . . . . . . . . . . . . . . . . . 13
4.2. Site Mapping . . . . . . . . . . . . . . . . . . . . . . 13 4.2. Site Mapping . . . . . . . . . . . . . . . . . . . . . . 13
5. Applicability of TE-Service Mapping in Generic context . . . 14 5. Applicability of TE-Service Mapping in Generic context . . . 14
6. YANG Data Trees . . . . . . . . . . . . . . . . . . . . . . . 14 6. YANG Data Trees . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Service Mapping Types . . . . . . . . . . . . . . . . . . 14 6.1. Service Mapping Types . . . . . . . . . . . . . . . . . . 14
6.2. Service Models . . . . . . . . . . . . . . . . . . . . . 16 6.2. Service Models . . . . . . . . . . . . . . . . . . . . . 16
6.2.1. L3SM . . . . . . . . . . . . . . . . . . . . . . . . 16 6.2.1. L3SM . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2.2. L2SM . . . . . . . . . . . . . . . . . . . . . . . . 17 6.2.2. L2SM . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2.3. L1CSM . . . . . . . . . . . . . . . . . . . . . . . . 17 6.2.3. L1CSM . . . . . . . . . . . . . . . . . . . . . . . . 17
6.3. Network Models . . . . . . . . . . . . . . . . . . . . . 18 6.3. Network Models . . . . . . . . . . . . . . . . . . . . . 18
6.3.1. L3NM . . . . . . . . . . . . . . . . . . . . . . . . 18 6.3.1. L3NM . . . . . . . . . . . . . . . . . . . . . . . . 18
6.3.2. L2NM . . . . . . . . . . . . . . . . . . . . . . . . 19 6.3.2. L2NM . . . . . . . . . . . . . . . . . . . . . . . . 19
7. YANG Data Models . . . . . . . . . . . . . . . . . . . . . . 20 7. YANG Data Models . . . . . . . . . . . . . . . . . . . . . . 20
7.1. ietf-te-service-mapping-types . . . . . . . . . . . . . . 20 7.1. ietf-te-service-mapping-types . . . . . . . . . . . . . . 20
7.2. Service Models . . . . . . . . . . . . . . . . . . . . . 29 7.2. Service Models . . . . . . . . . . . . . . . . . . . . . 30
7.2.1. ietf-l3sm-te-service-mapping . . . . . . . . . . . . 29 7.2.1. ietf-l3sm-te-service-mapping . . . . . . . . . . . . 30
7.2.2. ietf-l2sm-te-service-mapping . . . . . . . . . . . . 31 7.2.2. ietf-l2sm-te-service-mapping . . . . . . . . . . . . 32
7.2.3. ietf-l1csm-te-service-mapping . . . . . . . . . . . . 33 7.2.3. ietf-l1csm-te-service-mapping . . . . . . . . . . . . 34
7.3. Network Models . . . . . . . . . . . . . . . . . . . . . 35
7.3.1. ietf-l3nm-te-service-mapping . . . . . . . . . . . . 35 7.3. Network Models . . . . . . . . . . . . . . . . . . . . . 36
7.3.2. ietf-l2nm-te-service-mapping . . . . . . . . . . . . 37 7.3.1. ietf-l3nm-te-service-mapping . . . . . . . . . . . . 36
8. Security Considerations . . . . . . . . . . . . . . . . . . . 39 7.3.2. ietf-l2nm-te-service-mapping . . . . . . . . . . . . 38
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 8. Security Considerations . . . . . . . . . . . . . . . . . . . 40
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43
11.1. Normative References . . . . . . . . . . . . . . . . . . 42 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
11.2. Informative References . . . . . . . . . . . . . . . . . 45 11.1. Normative References . . . . . . . . . . . . . . . . . . 43
Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 46 11.2. Informative References . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 47
Appendix B. Discussion . . . . . . . . . . . . . . . . . . . . . 49
Appendix C. Contributor Addresses . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
1. Introduction 1. Introduction
Data models are a representation of objects that can be configured or Data models are a representation of objects that can be configured or
monitored within a system. Within the IETF, YANG [RFC7950] is the monitored within a system. Within the IETF, YANG [RFC7950] is the
language of choice for documenting data models, and YANG models have language of choice for documenting data models, and YANG models have
been produced to allow configuration or modelling of a variety of been produced to allow configuration or modelling of a variety of
network devices, protocol instances, and network services. YANG data network devices, protocol instances, and network services. YANG data
models have been classified in [RFC8199] and [RFC8309]. models have been classified in [RFC8199] and [RFC8309].
skipping to change at page 6, line 8 skipping to change at page 6, line 8
1.3. Prefixes in Data Node Names 1.3. Prefixes in Data Node Names
In this document, names of data nodes and other data model objects In this document, names of data nodes and other data model objects
are prefixed using the standard prefix associated with the are prefixed using the standard prefix associated with the
corresponding YANG imported modules, as shown in Table 1. corresponding YANG imported modules, as shown in Table 1.
+---------+---------------------------+-----------------------------+ +---------+---------------------------+-----------------------------+
| Prefix | YANG module | Reference | | Prefix | YANG module | Reference |
+---------+---------------------------+-----------------------------+ +---------+---------------------------+-----------------------------+
| inet | ietf-inet-types | [RFC6991] | | tsmt | ietf-te-service-mapping- | [RFCXXXX] |
| tsm- | ietf-te-service-mapping- | [RFCXXXX] | | | types | |
| types | types | |
| l1csm | ietf-l1csm | [I-D.ietf-ccamp-l1csm-yang] | | l1csm | ietf-l1csm | [I-D.ietf-ccamp-l1csm-yang] |
| l2vpn- | ietf-l2vpn-svc | [RFC8466] | | l2vpn- | ietf-l2vpn-svc | [RFC8466] |
| svc | | | | svc | | |
| l3vpn- | ietf-l3vpn-svc | [RFC8299] | | l3vpn- | ietf-l3vpn-svc | [RFC8299] |
| svc | | | | svc | | |
| l1-tsm | ietf-l1csm-te-service- | [RFCXXXX] | | l1-tsm | ietf-l1csm-te-service- | [RFCXXXX] |
| | mapping | | | | mapping | |
| l2-tsm | ietf-l2sm-te-service- | [RFCXXXX] | | l2-tsm | ietf-l2sm-te-service- | [RFCXXXX] |
| | mapping | | | | mapping | |
| l3-tsm | ietf-l3sm-te-service- | [RFCXXXX] | | l3-tsm | ietf-l3sm-te-service- | [RFCXXXX] |
skipping to change at page 8, line 5 skipping to change at page 8, line 5
new tunnels (or a VN) do not need to be created for each VPN and 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 can be shared across multiple VPNs. Further, the mapping YANG
model described in Section 5 of this document can be used to model described in Section 5 of this document can be used to
describe the mapping between the VPN service and the tunnels in describe the mapping between the VPN service and the tunnels in
use. No modification of the properties of a tunnel (or VN) is use. No modification of the properties of a tunnel (or VN) is
allowed in this mode: an existing tunnel can only be selected. allowed in this mode: an existing tunnel can only be selected.
o VN/Tunnel Modify - This mode allows the modification of the o VN/Tunnel Modify - This mode allows the modification of the
properties of the existing VN/tunnel (e.g., bandwidth). properties of the existing VN/tunnel (e.g., bandwidth).
o TE Mapping Template - This mode allows a VPN service to be bound o TE Mapping Template - This mode allows a VPN service to use a
to a mapping template containing constraints and optimization mapping template containing constraints and optimization criteria.
criteria. This allows mapping with the underlay TE This allows mapping with the underlay TE characteristics without
characteristics without first creating a VN or tunnels to map. first creating a VN or tunnels to map. The VPN service could be
The VPN service could be mapped to a template first. Once the VN/ mapped to a template first. Once the VN/Tunnels are actually
Tunnels are actually created/selected for the VPN service, this created/selected for the VPN service, the mapping based on the
mode is no longer used and replaced with the above modes. actual TE resources is created.
2.2. Availability Requirement 2.2. TE Policy
The service models could be associated with various policies related
to mapping the underlying TE resources. A color could be used to map
to the underlying colored TE resources. The desired protection and
availability requirements could be specified.
2.2.1. Availability Requirement
Availability is another service requirement or intent that may Availability is another service requirement or intent that may
influence the selection or provisioning of TE tunnels or a VN to influence the selection or provisioning of TE tunnels or a VN to
support the requested service. Availability is a probabilistic support the requested service. Availability is a probabilistic
measure of the length of time that a VPN/VN instance functions measure of the length of time that a VPN/VN instance functions
without a network failure. without a network failure.
The availability level will need to be translated into network The availability level will need to be translated into network
specific policies such as the protection/reroute policy associated specific policies such as the protection/reroute policy associated
with a VN or Tunnel. The means by which this is achieved is not in with a VN or Tunnel. The means by which this is achieved is not in
skipping to change at page 9, line 9 skipping to change at page 9, line 17
(defined in Section 2) grouping information from TE and Service (defined in Section 2) grouping information from TE and Service
Mapping Types. The TE and Service Mapping Types (ietf-te-service- Mapping Types. The TE and Service Mapping Types (ietf-te-service-
mapping-types) module is the repository of all common groupings mapping-types) module is the repository of all common groupings
imported by each augmented LxSM model. Any future service models imported by each augmented LxSM model. Any future service models
would import this mapping-type common model. would import this mapping-type common model.
The role of the augmented LxSm service model is to expose the mapping The role of the augmented LxSm service model is to expose the mapping
relationship between service models and TE models so that VN/VPN relationship between service models and TE models so that VN/VPN
service instantiations provided by the underlying TE networks can be service instantiations provided by the underlying TE networks can be
viewed outside of the MDSC, for example by an operator who is viewed outside of the MDSC, for example by an operator who is
diagnosing the behaviour of the network. It also allows for the diagnosing the behavior of the network. It also allows for the
customers to access operational state information about how their customers to access operational state information about how their
services are instantiated with the underlying VN, TE topology or TE services are instantiated with the underlying VN, TE topology or TE
tunnels provided that the MDSC operator is willing to share that tunnels provided that the MDSC operator is willing to share that
information. This mapping will facilitate a seamless service information. This mapping will facilitate a seamless service
management operation with underlay-TE network visibility. management operation with underlay-TE network visibility.
As seen in Figure 1, the augmented LxSM service model records a As seen in Figure 1, the augmented LxSM service model records a
mapping between the customer service models and the ACTN VN YANG mapping between the customer service models and the ACTN VN YANG
model. Thus, when the MDSC receives a service request it creates a model. Thus, when the MDSC receives a service request it creates a
VN that meets the customer's service objectives with various VN that meets the customer's service objectives with various
skipping to change at page 9, line 41 skipping to change at page 9, line 49
Mapping Types. Mapping Types.
It is possible that new service models will be defined at some future It is possible that new service models will be defined at some future
time and that it will be desirable to map them to underlying TE time and that it will be desirable to map them to underlying TE
constructs in the same way as the three existing models are constructs in the same way as the three existing models are
augmented. augmented.
3.2. TE and Network Models 3.2. TE and Network Models
The L2/L3 network models (L2NM, L3NM) are intended to describe a VPN The L2/L3 network models (L2NM, L3NM) are intended to describe a VPN
Service in the Service Provider Network. It containts information of Service in the Service Provider Network. It contains information of
the Service Provider network and might include allocated resources. the Service Provider network and might include allocated resources.
It can be used by network controllers to manage and control the VPN It can be used by network controllers to manage and control the VPN
Service configuration in the Service Provider network. Service configuration in the Service Provider network.
Similar to service model, the existing network models (i.e., Similar to service model, the existing network models (i.e.,
[I-D.ietf-opsawg-l3sm-l3nm], and [I-D.ietf-opsawg-l2nm]) are [I-D.ietf-opsawg-l3sm-l3nm], and [I-D.ietf-opsawg-l2nm]) are
augmented to include the TE and Service mapping parameters. Figure 2 augmented to include the TE and Service mapping parameters. Figure 2
shows the scope of the Augmented LxNM Model. shows the scope of the Augmented LxNM Model.
+--------------+ +----------------------+ +----------+ +--------------+ +----------------------+ +----------+
skipping to change at page 12, line 6 skipping to change at page 12, line 8
responsibilities of the MDSC is to coordinate with both the IP PNC responsibilities of the MDSC is to coordinate with both the IP PNC
and the Transport PNC for the mapping of the Augmented L3VPN and the Transport PNC for the mapping of the Augmented L3VPN
Service Model to the ACTN VN model. In the VN/TE-tunnel binding 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 case, the MDSC will need to coordinate with the Transport PNC to
dynamically create the TE-tunnels in the transport network as dynamically create the TE-tunnels in the transport network as
needed. These tunnels are added as links in the IP/MPLS Layer needed. These tunnels are added as links in the IP/MPLS Layer
topology. The MDSC coordinates with IP/MPLS PNC to create the TE- 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. tunnels in the IP/MPLS layer, as part of the ACTN VN creation.
o PNC: The Provisioning Network Controller is responsible for o PNC: The Provisioning Network Controller is responsible for
configuring and operating the network devices. Figure 2 shows two configuring and operating the network devices. Figure 3 shows two
distinct PNCs. distinct PNCs.
* IP/MPLS PNC (PNC1): This entity is responsible for device * IP/MPLS PNC (PNC1): This entity is responsible for device
configuration to create PE-PE L3VPN tunnels for the VPN configuration to create PE-PE L3VPN tunnels for the VPN
customer and for the configuration of the L3VPN VRF on the PE customer and for the configuration of the L3VPN VRF on the PE
nodes. Each network element would select a tunnel based on the nodes. Each network element would select a tunnel based on the
configuration. configuration.
* Transport PNC (PNC2): This entity is responsible for device * Transport PNC (PNC2): This entity is responsible for device
configuration for TE tunnels in the transport networks. configuration for TE tunnels in the transport networks.
There are four main interfaces shown in Figure 2. The three main interfaces are shown in Figure 3 and listed below.
o CMI: The CNC-MDSC Interface is used to communicate service o CMI: The CNC-MDSC Interface is used to communicate service
requests from the customer to the operator. The requests may be requests from the customer to the operator. The requests may be
expressed as Augmented VPN service requests (L2SM, L3SM), as expressed as Augmented VPN service requests (L2SM, L3SM), as
connectivity requests (L1CSM), or as virtual network requests connectivity requests (L1CSM), or as virtual network requests
(ACTN VN). (ACTN VN).
o MPI: The MDSC-PNC Interface is used by the MDSC to orchestrate o MPI: The MDSC-PNC Interface is used by the MDSC to orchestrate
networks under the control of PNCs. The requests on this networks under the control of PNCs. The requests on this
interface may use TE tunnel models, TE topology models, VPN interface may use TE tunnel models, TE topology models, VPN
skipping to change at page 12, line 43 skipping to change at page 12, line 45
The TE Service Mapping Model as described in this document can be 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 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 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 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, MDSC where a service request is mapped to a TE tunnel, TE topology,
or VPN network configuration model. The TE Service Mapping Model may 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 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. made and to see the purpose for which network resources are used.
As shown in Figure 2, the MDSC may be used recursively. For example, 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 the CNC might map a L3SM request to a VN request that it sends to a
recursive MDSC. recursive MDSC.
The high-level control flows for one example are as follows: The high-level control flows for one example are as follows:
1. A customer asks for an L3VPN between CE1 and CE2 using the 1. A customer asks for an L3VPN between CE1 and CE2 using the
Augmented L3SM model. Augmented L3SM model.
2. The MDSC considers the service request and local policy to 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 determine if it needs to create a new VN or any TE Topology, and
skipping to change at page 16, line 14 skipping to change at page 16, line 14
6.2. Service Models 6.2. Service Models
6.2.1. L3SM 6.2.1. L3SM
module: ietf-l3sm-te-service-mapping module: ietf-l3sm-te-service-mapping
augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services
/l3vpn-svc:vpn-service: /l3vpn-svc:vpn-service:
+--rw te-service-mapping! +--rw te-service-mapping!
+--rw te-mapping +--rw te-mapping
+--rw map-type? identityref +--rw map-type? identityref
+--rw availability-type? identityref +--rw te-policy
| +--rw color? uint32
| +--rw protection-type? identityref
| +--rw availability-type? identityref
+--rw (te)? +--rw (te)?
+--:(vn) | +--:(vn)
| +--rw vn-list* | | +--rw vn* -> /vn:vn/vn/vn-id
| -> /vn:vn/vn-list/vn-id | +--:(te-topo)
+--:(te-topo) | | +--rw vn-topology-id? te-types:te-topology-id
| +--rw vn-topology-id? | | +--rw abstract-node?
| | te-types:te-topology-id | | -> /nw:networks/network/node/node-id
| +--rw abstract-node? | +--:(te-tunnel)
| -> /nw:networks/network/node/node-id | +--rw te-tunnel* te:tunnel-ref
+--:(te-tunnel) | +--rw sr-policy*
| +--rw te-tunnel-list* te:tunnel-ref | [policy-color-ref policy-endpoint-ref]
| +--rw sr-policy* | {sr-policy}?
| [policy-color-ref policy-endpoint-ref] | +--rw policy-color-ref leafref
| {sr-policy}? | +--rw policy-endpoint-ref leafref
| +--rw policy-color-ref leafref +--rw te-mapping-template-ref?
| +--rw policy-endpoint-ref leafref -> /te-mapping-templates/te-mapping-template/id
+--:(te-mapping-template) {template}? {template}?
+--rw te-mapping-template-ref? leafref
augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site
/l3vpn-svc:site-network-accesses /l3vpn-svc:site-network-accesses
/l3vpn-svc:site-network-access: /l3vpn-svc:site-network-access:
+--rw (te)? +--rw (te)?
+--:(vn) +--:(vn)
| +--rw ap-list* | +--rw ap* -> /vn:ap/ap/ap-id
| -> /vn:ap/access-point-list/access-point-id
+--:(te) +--:(te)
+--rw ltp? te-types:te-tp-id +--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 vnap? -> /vn:ap/ap/vn-ap/vn-ap-id
6.2.2. L2SM 6.2.2. L2SM
module: ietf-l2sm-te-service-mapping module: ietf-l2sm-te-service-mapping
augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services
/l2vpn-svc:vpn-service: /l2vpn-svc:vpn-service:
+--rw te-service-mapping! +--rw te-service-mapping!
+--rw te-mapping +--rw te-mapping
+--rw map-type? identityref +--rw map-type? identityref
+--rw availability-type? identityref +--rw te-policy
| +--rw color? uint32
| +--rw protection-type? identityref
| +--rw availability-type? identityref
+--rw (te)? +--rw (te)?
+--:(vn) | +--:(vn)
| +--rw vn-list* | | +--rw vn* -> /vn:vn/vn/vn-id
| -> /vn:vn/vn-list/vn-id | +--:(te-topo)
+--:(te-topo) | | +--rw vn-topology-id? te-types:te-topology-id
| +--rw vn-topology-id? | | +--rw abstract-node?
| | te-types:te-topology-id | | -> /nw:networks/network/node/node-id
| +--rw abstract-node? | +--:(te-tunnel)
| -> /nw:networks/network/node/node-id | +--rw te-tunnel* te:tunnel-ref
+--:(te-tunnel) | +--rw sr-policy*
| +--rw te-tunnel-list* te:tunnel-ref | [policy-color-ref policy-endpoint-ref]
| +--rw sr-policy* | {sr-policy}?
| [policy-color-ref policy-endpoint-ref] | +--rw policy-color-ref leafref
| {sr-policy}? | +--rw policy-endpoint-ref leafref
| +--rw policy-color-ref leafref +--rw te-mapping-template-ref?
| +--rw policy-endpoint-ref leafref -> /te-mapping-templates/te-mapping-template/id
+--:(te-mapping-template) {template}? {template}?
+--rw te-mapping-template-ref? leafref
augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site
/l2vpn-svc:site-network-accesses /l2vpn-svc:site-network-accesses
/l2vpn-svc:site-network-access: /l2vpn-svc:site-network-access:
+--rw (te)? +--rw (te)?
+--:(vn) +--:(vn)
| +--rw ap-list* | +--rw ap* -> /vn:ap/ap/ap-id
| -> /vn:ap/access-point-list/access-point-id
+--:(te) +--:(te)
+--rw ltp? te-types:te-tp-id +--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 vnap? -> /vn:ap/ap/vn-ap/vn-ap-id
6.2.3. L1CSM 6.2.3. L1CSM
module: ietf-l1csm-te-service-mapping module: ietf-l1csm-te-service-mapping
augment /l1csm:l1-connectivity/l1csm:services/l1csm:service: augment /l1csm:l1-connectivity/l1csm:services/l1csm:service:
+--rw te-service-mapping! +--rw te-service-mapping!
+--rw te-mapping +--rw te-mapping
+--rw map-type? identityref +--rw map-type? identityref
+--rw availability-type? identityref +--rw te-policy
| +--rw color? uint32
| +--rw protection-type? identityref
| +--rw availability-type? identityref
+--rw (te)? +--rw (te)?
+--:(vn) | +--:(vn)
| +--rw vn-list* | | +--rw vn* -> /vn:vn/vn/vn-id
| -> /vn:vn/vn-list/vn-id | +--:(te-topo)
+--:(te-topo) | | +--rw vn-topology-id? te-types:te-topology-id
| +--rw vn-topology-id? | | +--rw abstract-node?
| | te-types:te-topology-id | | -> /nw:networks/network/node/node-id
| +--rw abstract-node? | +--:(te-tunnel)
| -> /nw:networks/network/node/node-id | +--rw te-tunnel* te:tunnel-ref
+--:(te-tunnel) | +--rw sr-policy*
| +--rw te-tunnel-list* te:tunnel-ref | [policy-color-ref policy-endpoint-ref]
| +--rw sr-policy* | {sr-policy}?
| [policy-color-ref policy-endpoint-ref] | +--rw policy-color-ref leafref
| {sr-policy}? | +--rw policy-endpoint-ref leafref
| +--rw policy-color-ref leafref +--rw te-mapping-template-ref?
| +--rw policy-endpoint-ref leafref -> /te-mapping-templates/te-mapping-template/id
+--:(te-mapping-template) {template}? {template}?
+--rw te-mapping-template-ref? leafref
augment /l1csm:l1-connectivity/l1csm:access/l1csm:unis/l1csm:uni: augment /l1csm:l1-connectivity/l1csm:access/l1csm:unis/l1csm:uni:
+--rw (te)? +--rw (te)?
+--:(vn) +--:(vn)
| +--rw ap-list* | +--rw ap* -> /vn:ap/ap/ap-id
| -> /vn:ap/access-point-list/access-point-id
+--:(te) +--:(te)
+--rw ltp? te-types:te-tp-id +--rw ltp? te-types:te-tp-id
6.3. Network Models 6.3. Network Models
6.3.1. L3NM 6.3.1. L3NM
module: ietf-l3nm-te-service-mapping module: ietf-l3nm-te-service-mapping
augment /l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services augment /l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services
/l3vpn-ntw:vpn-service: /l3vpn-ntw:vpn-service:
+--rw te-service-mapping! +--rw te-service-mapping!
+--rw te-mapping +--rw te-mapping
+--rw map-type? identityref +--rw map-type? identityref
+--rw availability-type? identityref +--rw te-policy
| +--rw color? uint32
| +--rw protection-type? identityref
| +--rw availability-type? identityref
+--rw (te)? +--rw (te)?
+--:(vn) | +--:(vn)
| +--rw vn-list* | | +--rw vn* -> /vn:vn/vn/vn-id
| -> /vn:vn/vn-list/vn-id | +--:(te-topo)
+--:(te-topo) | | +--rw vn-topology-id? te-types:te-topology-id
| +--rw vn-topology-id? | | +--rw abstract-node?
| | te-types:te-topology-id | | -> /nw:networks/network/node/node-id
| +--rw abstract-node? | +--:(te-tunnel)
| -> /nw:networks/network/node/node-id | +--rw te-tunnel* te:tunnel-ref
+--:(te-tunnel) | +--rw sr-policy*
| +--rw te-tunnel-list* te:tunnel-ref | [policy-color-ref policy-endpoint-ref]
| +--rw sr-policy* | {sr-policy}?
| [policy-color-ref policy-endpoint-ref] | +--rw policy-color-ref leafref
| {sr-policy}? | +--rw policy-endpoint-ref leafref
| +--rw policy-color-ref leafref +--rw te-mapping-template-ref?
| +--rw policy-endpoint-ref leafref -> /te-mapping-templates/te-mapping-template/id
+--:(te-mapping-template) {template}? {template}?
+--rw te-mapping-template-ref? leafref
augment /l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services augment /l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services
/l3vpn-ntw:vpn-service/l3vpn-ntw:vpn-nodes /l3vpn-ntw:vpn-service/l3vpn-ntw:vpn-nodes
/l3vpn-ntw:vpn-node/l3vpn-ntw:vpn-network-accesses /l3vpn-ntw:vpn-node/l3vpn-ntw:vpn-network-accesses
/l3vpn-ntw:vpn-network-access: /l3vpn-ntw:vpn-network-access:
+--rw (te)? +--rw (te)?
+--:(vn) +--:(vn)
| +--rw ap-list* | +--rw ap* -> /vn:ap/ap/ap-id
| -> /vn:ap/access-point-list/access-point-id
+--:(te) +--:(te)
+--rw ltp? te-types:te-tp-id +--rw ltp? te-types:te-tp-id
6.3.2. L2NM 6.3.2. L2NM
module: ietf-l2nm-te-service-mapping module: ietf-l2nm-te-service-mapping
augment /l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services augment /l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services
/l2vpn-ntw:vpn-service: /l2vpn-ntw:vpn-service:
+--rw te-service-mapping! +--rw te-service-mapping!
+--rw te-mapping +--rw te-mapping
+--rw map-type? identityref +--rw map-type? identityref
+--rw availability-type? identityref +--rw te-policy
| +--rw color? uint32
| +--rw protection-type? identityref
| +--rw availability-type? identityref
+--rw (te)? +--rw (te)?
+--:(vn) | +--:(vn)
| +--rw vn-list* | | +--rw vn* -> /vn:vn/vn/vn-id
| -> /vn:vn/vn-list/vn-id | +--:(te-topo)
+--:(te-topo) | | +--rw vn-topology-id? te-types:te-topology-id
| +--rw vn-topology-id? | | +--rw abstract-node?
| | te-types:te-topology-id | | -> /nw:networks/network/node/node-id
| +--rw abstract-node? | +--:(te-tunnel)
| -> /nw:networks/network/node/node-id | +--rw te-tunnel* te:tunnel-ref
+--:(te-tunnel) | +--rw sr-policy*
| +--rw te-tunnel-list* te:tunnel-ref | [policy-color-ref policy-endpoint-ref]
| +--rw sr-policy* | {sr-policy}?
| [policy-color-ref policy-endpoint-ref] | +--rw policy-color-ref leafref
| {sr-policy}? | +--rw policy-endpoint-ref leafref
| +--rw policy-color-ref leafref +--rw te-mapping-template-ref?
| +--rw policy-endpoint-ref leafref -> /te-mapping-templates/te-mapping-template/id
+--:(te-mapping-template) {template}? {template}?
+--rw te-mapping-template-ref? leafref
augment /l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services augment /l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services
/l2vpn-ntw:vpn-service/l2vpn-ntw:vpn-nodes /l2vpn-ntw:vpn-service/l2vpn-ntw:vpn-nodes
/l2vpn-ntw:vpn-node/l2vpn-ntw:vpn-network-accesses /l2vpn-ntw:vpn-node/l2vpn-ntw:vpn-network-accesses
/l2vpn-ntw:vpn-network-access: /l2vpn-ntw:vpn-network-access:
+--rw (te)? +--rw (te)?
+--:(vn) +--:(vn)
| +--rw ap-list* | +--rw ap* -> /vn:ap/ap/ap-id
| -> /vn:ap/access-point-list/access-point-id
+--:(te) +--:(te)
+--rw ltp? te-types:te-tp-id +--rw ltp? te-types:te-tp-id
7. YANG Data Models 7. YANG Data Models
The YANG codes are as follows: The YANG codes are as follows:
7.1. ietf-te-service-mapping-types 7.1. ietf-te-service-mapping-types
<CODE BEGINS> file "ietf-te-service-mapping-types@2020-11-02.yang" <CODE BEGINS> file "ietf-te-service-mapping-types@2021-02-20.yang"
module ietf-te-service-mapping-types { module ietf-te-service-mapping-types {
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types"; "urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types";
prefix tsm-types;
/* Import inet-types */
import ietf-inet-types { prefix tsmt;
prefix inet;
reference
"RFC 6991: Common YANG Data Types";
}
/* Import inet-types */ /* Import te-types */
import ietf-te-types { import ietf-te-types {
prefix te-types; prefix te-types;
reference reference
"RFC 8776: Common YANG Data Types for Traffic Engineering"; "RFC 8776: Common YANG Data Types for Traffic Engineering";
} }
/* Import network model */ /* Import network model */
import ietf-network { import ietf-network {
skipping to change at page 22, line 35 skipping to change at page 22, line 26
<mailto:younglee.tx@gmail.com> <mailto:younglee.tx@gmail.com>
Editor: Dhruv Dhody Editor: Dhruv Dhody
<mailto:dhruv.ietf@gmail.com> <mailto:dhruv.ietf@gmail.com>
Editor: Qin Wu Editor: Qin Wu
<mailto:bill.wu@huawei.com>"; <mailto:bill.wu@huawei.com>";
description description
"This module contains a YANG module for TE & Service mapping "This module contains a YANG module for TE & Service mapping
parameters and policies as a common grouping applicable to parameters and policies as a common grouping applicable to
variuous service models (e.g., L1CSM, L2SM, L3SM, etc.) variuous service models (e.g., L1CSM, L2SM, L3SM, etc.)
Copyright (c) 2020 IETF Trust and the persons identified as Copyright (c) 2021 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the This version of this YANG module is part of RFC XXXX; see the
RFC itself for full legal notices. RFC itself for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as 'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here."; they appear in all capitals, as shown here.";
revision 2020-11-02 { revision 2021-02-20 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; "RFC XXXX: Traffic Engineering and Service Mapping Yang Model";
} }
/* /*
* Features * Features
*/ */
feature template { feature template {
description description
"Support TE mapping templates."; "Support TE mapping templates.";
} }
feature sr-policy { feature sr-policy {
skipping to change at page 24, line 27 skipping to change at page 24, line 17
modification."; modification.";
} }
identity modify { identity modify {
base map-type; base map-type;
description description
"The VPN service selects an existing tunnel and allows to modify "The VPN service selects an existing tunnel and allows to modify
the properties of the tunnel (e.g., b/w)"; the properties of the tunnel (e.g., b/w)";
} }
identity template { identity none {
base map-type; base map-type;
description description
"The VPN service selects an TE mapping template with path "The VPN service is not mapped to any underlying TE";
constraints and optimization criteria";
} }
/* /*
* Identity for availability-type * Identity for availability-type
*/ */
identity availability-type { identity availability-type {
description description
"Base identity from which specific map types are derived."; "Base identity from which specific map types are derived.";
} }
skipping to change at page 25, line 30 skipping to change at page 25, line 19
base availability-type; base availability-type;
description description
"level 5: 99%"; "level 5: 99%";
} }
/* /*
* Typedef * Typedef
*/ */
typedef te-mapping-template-id { typedef te-mapping-template-id {
type inet:uri; type string;
description description
"Identifier for a TE mapping template. The precise "Identifier for a TE mapping template.";
structure of the te-mapping-template-id will be up
to the implementation. The identifier SHOULD be
chosen such that the same template will always be
identified through the same identifier, even if the
data model is instantiated in separate datastores.";
} }
/* /*
* Groupings * Groupings
*/ */
grouping te-ref { grouping te-ref {
description description
"The reference to TE."; "The reference to TE.";
choice te { choice te {
description description
"The TE"; "How the VPN is mapped to a VN, Topology, Tunnel, SR Policy
etc.";
case vn { case vn {
leaf-list vn-list { leaf-list vn {
type leafref { type leafref {
path "/vn:vn/vn:vn-list/vn:vn-id"; path "/vn:vn/vn:vn/vn:vn-id";
} }
description description
"The reference to VN"; "The reference to VN";
reference reference
"RFC 8453: Framework for Abstraction and Control of TE "RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN)"; Networks (ACTN)";
} }
} }
case te-topo { case te-topo {
leaf vn-topology-id { leaf vn-topology-id {
type te-types:te-topology-id; type te-types:te-topology-id;
description description
"An identifier to the TE Topology Model where the abstract "An identifier to the TE Topology Model where the abstract
nodes and links of the Topology can be found for Type 2 nodes and links of the Topology can be found for Type 2
VNS"; VNs as defined in RFC 8453";
reference reference
"RFC 8795: YANG Data Model for Traffic Engineering (TE) "RFC 8795: YANG Data Model for Traffic Engineering (TE)
Topologies"; Topologies
RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN)";
} }
leaf abstract-node { leaf abstract-node {
type leafref { type leafref {
path "/nw:networks/nw:network/nw:node/nw:node-id"; path "/nw:networks/nw:network/nw:node/nw:node-id";
} }
description description
"A reference to the abstract node in TE Topology"; "A reference to the abstract node in TE Topology";
reference reference
"RFC 8795: YANG Data Model for Traffic Engineering (TE) "RFC 8795: YANG Data Model for Traffic Engineering (TE)
Topologies"; Topologies";
} }
} }
case te-tunnel { case te-tunnel {
leaf-list te-tunnel-list { leaf-list te-tunnel {
type te:tunnel-ref; type te:tunnel-ref;
description description
"Reference to TE Tunnels"; "Reference to TE Tunnels";
reference reference
"I-D.ietf-teas-yang-te: A YANG Data Model for Traffic "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic
Engineering Tunnels and Interfaces"; Engineering Tunnels and Interfaces";
} }
list sr-policy { list sr-policy {
if-feature "sr-policy"; if-feature "sr-policy";
key "policy-color-ref policy-endpoint-ref"; key "policy-color-ref policy-endpoint-ref";
skipping to change at page 27, line 23 skipping to change at page 27, line 11
path path
"/rt:routing/sr-policy:segment-routing" "/rt:routing/sr-policy:segment-routing"
+ "/sr-policy:traffic-engineering/sr-policy:policies" + "/sr-policy:traffic-engineering/sr-policy:policies"
+ "/sr-policy:policy/sr-policy:endpoint"; + "/sr-policy:policy/sr-policy:endpoint";
} }
description description
"Reference to sr-policy endpoint"; "Reference to sr-policy endpoint";
} }
} }
} }
case te-mapping-template { }
if-feature "template"; leaf te-mapping-template-ref {
leaf te-mapping-template-ref { if-feature "template";
type leafref { type leafref {
path "/tsm-types:te-mapping-templates/" path "/tsmt:te-mapping-templates/"
+ "tsm-types:te-mapping-template/tsm-types:id"; + "tsmt:te-mapping-template/tsmt:id";
}
description
"An identifier to the TE Mapping Template where the TE
constraints and optimization criteria are specified.";
}
} }
description
"An identifier to the TE Mapping Template where the TE
constraints and optimization criteria are specified.";
} }
} }
//grouping //grouping
grouping te-endpoint-ref { grouping te-endpoint-ref {
description description
"The reference to TE endpoints."; "The reference to TE endpoints.";
choice te { choice te {
description description
"The TE"; "How the TE endpoint is defined by VN's AP or TE's LTP";
case vn { case vn {
leaf-list ap-list { leaf-list ap {
type leafref { type leafref {
path "/vn:ap/vn:access-point-list/vn:access-point-id"; path "/vn:ap/vn:ap/vn:ap-id";
} }
description description
"The reference to VN AP"; "The reference to VN's AP";
reference reference
"RFC 8453: Framework for Abstraction and Control of TE "RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN)"; Networks (ACTN)";
} }
} }
case te { case te {
leaf ltp { leaf ltp {
type te-types:te-tp-id; type te-types:te-tp-id;
description description
"Reference LTP in the TE-topology"; "Reference LTP in the TE-topology";
skipping to change at page 28, line 18 skipping to change at page 28, line 4
} }
} }
case te { case te {
leaf ltp { leaf ltp {
type te-types:te-tp-id; type te-types:te-tp-id;
description description
"Reference LTP in the TE-topology"; "Reference LTP in the TE-topology";
reference reference
"RFC 8795: YANG Data Model for Traffic Engineering (TE) "RFC 8795: YANG Data Model for Traffic Engineering (TE)
Topologies"; Topologies";
} }
} }
} }
} }
//grouping //grouping
grouping vnap-ref {
description
"The reference to VNAP.";
leaf vnap {
type leafref {
path "/vn:ap/vn:ap/vn:vn-ap/vn:vn-ap-id";
}
description
"The reference to VNAP";
reference
"RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN)";
}
}
//grouping
grouping te-policy {
description
"Various underlying TE policy requirements";
leaf color {
type uint32;
description
"Maps to the underlying colored TE resources";
}
leaf protection-type {
type identityref {
base te-types:lsp-protection-type;
}
description
"Desired protection level for the underlying
TE resources";
}
leaf availability-type {
type identityref {
base availability-type;
}
description
"Availability Requirement for the Service";
}
}
//grouping
grouping te-mapping { grouping te-mapping {
description description
"Mapping between Services and TE"; "Mapping between Services and TE";
container te-mapping { container te-mapping {
description description
"Mapping between Services and TE"; "Mapping between Services and TE";
leaf map-type { leaf map-type {
type identityref { type identityref {
base map-type; base map-type;
} }
description description
"Isolation Requirements, Tunnel Bind or "Isolation Requirements, Tunnel Bind or
Tunnel Selection"; Tunnel Selection";
} }
leaf availability-type { container te-policy {
type identityref { uses te-policy;
base availability-type;
}
description description
"Availability Requirement for the Service"; "Desired Underlying TE Policy";
} }
uses te-ref; uses te-ref;
} }
} }
//grouping //grouping
container te-mapping-templates { container te-mapping-templates {
description description
"The TE constraints and optimization criteria"; "The TE constraints and optimization criteria";
list te-mapping-template { list te-mapping-template {
key "id"; key "id";
leaf id { leaf id {
type te-mapping-template-id; type te-mapping-template-id;
description description
"Identification of the Template to be used."; "Identification of the Template to be used.";
} }
leaf description { leaf description {
type string; type string;
description description
"Description of the template."; "Description of the template.";
} }
leaf map-type { leaf map-type {
type identityref { type identityref {
base map-type; base map-type;
} }
must "0 = derived-from-or-self(.,'template')" { must "0 = derived-from-or-self(.,'none')" {
error-message "The map-type must be other than " error-message "The map-type must be other than "
+ "TE mapping template"; + "none";
} }
description description
"Map type for the VN/Tunnel creation/ "Map type for the VN/Tunnel creation/
selection."; selection.";
} }
uses te-types:generic-path-constraints; uses te-types:generic-path-constraints;
uses te-types:generic-path-optimization; uses te-types:generic-path-optimization;
description description
"List for templates."; "List for templates.";
} }
skipping to change at page 29, line 38 skipping to change at page 30, line 17
"Map type for the VN/Tunnel creation/ "Map type for the VN/Tunnel creation/
selection."; selection.";
} }
uses te-types:generic-path-constraints; uses te-types:generic-path-constraints;
uses te-types:generic-path-optimization; uses te-types:generic-path-optimization;
description description
"List for templates."; "List for templates.";
} }
} }
} }
<CODE ENDS> <CODE ENDS>
7.2. Service Models 7.2. Service Models
7.2.1. ietf-l3sm-te-service-mapping 7.2.1. ietf-l3sm-te-service-mapping
<CODE BEGINS> file "ietf-l3sm-te-service-mapping@2020-11-02.yang" <CODE BEGINS> file "ietf-l3sm-te-service-mapping@2021-02-20.yang"
module ietf-l3sm-te-service-mapping { module ietf-l3sm-te-service-mapping {
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping"; "urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping";
prefix l3-tsm; prefix l3-tsm;
import ietf-te-service-mapping-types { import ietf-te-service-mapping-types {
prefix tsm-types; prefix tsmt;
reference reference
"RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; "RFC XXXX: Traffic Engineering and Service Mapping Yang Model";
} }
import ietf-l3vpn-svc { import ietf-l3vpn-svc {
prefix l3vpn-svc; prefix l3vpn-svc;
reference reference
"RFC 8299: YANG Data Model for L3VPN Service Delivery"; "RFC 8299: YANG Data Model for L3VPN Service Delivery";
} }
organization organization
skipping to change at page 30, line 51 skipping to change at page 31, line 30
This version of this YANG module is part of RFC XXXX; see the This version of this YANG module is part of RFC XXXX; see the
RFC itself for full legal notices. RFC itself for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as 'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here."; they appear in all capitals, as shown here.";
revision 2020-11-02 { revision 2021-02-20 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; "RFC XXXX: Traffic Engineering and Service Mapping Yang Model";
} }
/* /*
* Augmentation to L3SM * Augmentation to L3SM
*/ */
augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services" augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services"
+ "/l3vpn-svc:vpn-service" { + "/l3vpn-svc:vpn-service" {
description description
"L3SM augmented to include TE parameters and mapping"; "L3SM augmented to include TE parameters and mapping";
container te-service-mapping { container te-service-mapping {
presence "Indicates L3 service to TE mapping"; presence "Indicates L3 service to TE mapping";
description description
"Container to augment l3sm to TE parameters and mapping"; "Container to augment l3sm to TE parameters and mapping";
uses tsm-types:te-mapping; uses tsmt:te-mapping;
} }
} }
//augment //augment
augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site" augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site"
+ "/l3vpn-svc:site-network-accesses" + "/l3vpn-svc:site-network-accesses"
+ "/l3vpn-svc:site-network-access" { + "/l3vpn-svc:site-network-access" {
description description
"This augment is only valid for TE mapping of L3SM network-access "This augment is only valid for TE mapping of L3SM network-access
to TE endpoints"; to TE endpoints";
uses tsm-types:te-endpoint-ref; uses tsmt:te-endpoint-ref;
} }
//augment //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" {
when './l3vpn-svc:bandwidth/l3vpn-svc:end-to-end' {
description
"applicable only with end-to-end";
}
description
"This augment is only valid for the custom qos-profile with
end-to-end set";
uses tsmt:vnap-ref;
}
}
<CODE ENDS> <CODE ENDS>
7.2.2. ietf-l2sm-te-service-mapping 7.2.2. ietf-l2sm-te-service-mapping
<CODE BEGINS> file "ietf-l2sm-te-service-mapping@2020-11-02.yang" <CODE BEGINS> file "ietf-l2sm-te-service-mapping@2021-02-20.yang"
module ietf-l2sm-te-service-mapping { module ietf-l2sm-te-service-mapping {
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping"; "urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping";
prefix l2-tsm; prefix l2-tsm;
import ietf-te-service-mapping-types { import ietf-te-service-mapping-types {
prefix tsm-types; prefix tsmt;
reference reference
"RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; "RFC XXXX: Traffic Engineering and Service Mapping Yang Model";
} }
import ietf-l2vpn-svc { import ietf-l2vpn-svc {
prefix l2vpn-svc; prefix l2vpn-svc;
reference reference
"RFC 8466: A YANG Data Model for Layer 2 Virtual Private Network "RFC 8466: A YANG Data Model for Layer 2 Virtual Private Network
(L2VPN) Service Delivery"; (L2VPN) Service Delivery";
}
organization }
"IETF Traffic Engineering Architecture and Signaling (TEAS)
Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/teas/>
WG List: <mailto:teas@ietf.org>
Editor: Young Lee organization
<mailto:younglee.tx@gmail.com> "IETF Traffic Engineering Architecture and Signaling (TEAS)
Editor: Dhruv Dhody Working Group";
<mailto:dhruv.ietf@gmail.com> contact
Editor: Qin Wu "WG Web: <http://tools.ietf.org/wg/teas/>
<mailto:bill.wu@huawei.com>"; WG List: <mailto:teas@ietf.org>
description
"This module contains a YANG module for the mapping of Layer 2
Service Model (L2SM) to the TE and VN.
Copyright (c) 2020 IETF Trust and the persons identified as Editor: Young Lee
authors of the code. All rights reserved. <mailto:younglee.tx@gmail.com>
Editor: Dhruv Dhody
<mailto:dhruv.ietf@gmail.com>
Editor: Qin Wu
<mailto:bill.wu@huawei.com>";
description
"This module contains a YANG module for the mapping of Layer 2
Service Model (L2SM) to the TE and VN.
Redistribution and use in source and binary forms, with or Copyright (c) 2021 IETF Trust and the persons identified as
without modification, is permitted pursuant to, and subject to authors of the code. All rights reserved.
the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the Redistribution and use in source and binary forms, with or
RFC itself for full legal notices. without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL This version of this YANG module is part of RFC XXXX; see the
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', RFC itself for full legal notices.
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.";
revision 2020-11-02 { The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
description NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
"Initial revision."; 'MAY', and 'OPTIONAL' in this document are to be interpreted as
reference described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
"RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; they appear in all capitals, as shown here.";
}
/* revision 2021-02-20 {
* Augmentation to L2SM description
*/ "Initial revision.";
reference
"RFC XXXX: Traffic Engineering and Service Mapping Yang Model";
}
augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services/" /*
+ "l2vpn-svc:vpn-service" { * Augmentation to L2SM
description */
"L2SM augmented to include TE parameters and mapping";
container te-service-mapping {
presence "indicates L2 service to te mapping";
description
"Container to augment L2SM to TE parameters and mapping";
uses tsm-types:te-mapping;
}
}
//augment augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services/"
+ "l2vpn-svc:vpn-service" {
description
"L2SM augmented to include TE parameters and mapping";
container te-service-mapping {
presence "indicates L2 service to te mapping";
description
"Container to augment L2SM to TE parameters and mapping";
uses tsmt:te-mapping;
}
}
augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site" //augment
+ "/l2vpn-svc:site-network-accesses"
+ "/l2vpn-svc:site-network-access" {
description
"This augment is only valid for TE mapping of L2SM network-access
to TE endpoints";
uses tsm-types:te-endpoint-ref;
}
//augment augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site"
} + "/l2vpn-svc:site-network-accesses"
+ "/l2vpn-svc:site-network-access" {
description
"This augment the L2SM network-access with a reference
to TE endpoints when underlying TE is used";
uses tsmt:te-endpoint-ref;
}
<CODE ENDS> //augment
augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site"
+ "/l2vpn-svc:service/l2vpn-svc:qos/l2vpn-svc:qos-profile"
+ "/l2vpn-svc:qos-profile/l2vpn-svc:custom"
+ "/l2vpn-svc:classes/l2vpn-svc:class" {
when './l2vpn-svc:bandwidth/l2vpn-svc:end-to-end' {
description
"applicable only with end-to-end";
}
description
"This augment is only valid for the custom qos-profile with
end-to-end set";
uses tsmt:vnap-ref;
}
}
<CODE ENDS>
7.2.3. ietf-l1csm-te-service-mapping 7.2.3. ietf-l1csm-te-service-mapping
<CODE BEGINS> file "ietf-l1csm-te-service-mapping@2020-11-02.yang" <CODE BEGINS> file "ietf-l1csm-te-service-mapping@2021-02-20.yang"
module ietf-l1csm-te-service-mapping { module ietf-l1csm-te-service-mapping {
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping"; "urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping";
prefix l1-tsm; prefix l1-tsm;
import ietf-te-service-mapping-types { import ietf-te-service-mapping-types {
prefix tsm-types; prefix tsmt;
reference reference
"RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; "RFC XXXX: Traffic Engineering and Service Mapping Yang Model";
} }
import ietf-l1csm { import ietf-l1csm {
prefix l1csm; prefix l1csm;
reference reference
"I-D.ietf-ccamp-l1csm-yang: A YANG Data Model for L1 Connectivity "I-D.ietf-ccamp-l1csm-yang: A YANG Data Model for L1 Connectivity
Service Model (L1CSM)"; Service Model (L1CSM)";
} }
skipping to change at page 34, line 33 skipping to change at page 35, line 36
Editor: Young Lee Editor: Young Lee
<mailto:younglee.tx@gmail.com> <mailto:younglee.tx@gmail.com>
Editor: Dhruv Dhody Editor: Dhruv Dhody
<mailto:dhruv.ietf@gmail.com> <mailto:dhruv.ietf@gmail.com>
Editor: Qin Wu Editor: Qin Wu
<mailto:bill.wu@huawei.com>"; <mailto:bill.wu@huawei.com>";
description description
"This module contains a YANG module for the mapping of "This module contains a YANG module for the mapping of
Layer 1 Connectivity Service Module (L1CSM) to the TE and VN Layer 1 Connectivity Service Module (L1CSM) to the TE and VN
Copyright (c) 2020 IETF Trust and the persons identified as Copyright (c) 2021 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the This version of this YANG module is part of RFC XXXX; see the
RFC itself for full legal notices. RFC itself for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as 'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here."; they appear in all capitals, as shown here.";
revision 2020-11-02 { revision 2021-02-20 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; "RFC XXXX: Traffic Engineering and Service Mapping Yang Model";
} }
/* /*
* Augmentation to L1CSM * Augmentation to L1CSM
*/ */
augment "/l1csm:l1-connectivity/l1csm:services/l1csm:service" { augment "/l1csm:l1-connectivity/l1csm:services/l1csm:service" {
description description
"L1CSM augmented to include TE parameters and mapping"; "L1CSM augmented to include TE parameters and mapping";
container te-service-mapping { container te-service-mapping {
presence "Indicates L1 service to TE mapping"; presence "Indicates L1 service to TE mapping";
description description
"Container to augment L1CSM to TE parameters and mapping"; "Container to augment L1CSM to TE parameters and mapping";
uses tsm-types:te-mapping; uses tsmt:te-mapping;
} }
} }
//augment //augment
augment "/l1csm:l1-connectivity/l1csm:access/l1csm:unis/" augment "/l1csm:l1-connectivity/l1csm:access/l1csm:unis/"
+ "l1csm:uni" { + "l1csm:uni" {
description description
"This augment is only valid for TE mapping of L1CSM UNI to TE "This augment the L1CSM UNI with a reference
endpoints"; to TE endpoints";
uses tsm-types:te-endpoint-ref; uses tsmt:te-endpoint-ref;
} }
//augment //augment
} }
<CODE ENDS> <CODE ENDS>
7.3. Network Models 7.3. Network Models
7.3.1. ietf-l3nm-te-service-mapping 7.3.1. ietf-l3nm-te-service-mapping
<CODE BEGINS> file "ietf-l3nm-te-service-mapping@2020-11-02.yang" <CODE BEGINS> file "ietf-l3nm-te-service-mapping@202-02-20.yang"
module ietf-l3nm-te-service-mapping { module ietf-l3nm-te-service-mapping {
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-l3nm-te-service-mapping"; "urn:ietf:params:xml:ns:yang:ietf-l3nm-te-service-mapping";
prefix l3nm-tsm;
import ietf-te-service-mapping-types {
prefix tsm-types;
reference
"RFC XXXX: Traffic Engineering and Service Mapping Yang Model";
}
import ietf-l3vpn-ntw {
prefix l3vpn-ntw;
reference
"I-D.ietf-opsawg-l3sm-l3nm: A Layer 3 VPN Network YANG Model";
}
organization prefix l3nm-tsm;
"IETF Traffic Engineering Architecture and Signaling (TEAS)
Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/teas/>
WG List: <mailto:teas@ietf.org>
Editor: Young Lee import ietf-te-service-mapping-types {
<mailto:younglee.tx@gmail.com> prefix tsmt;
Editor: Dhruv Dhody reference
<mailto:dhruv.ietf@gmail.com> "RFC XXXX: Traffic Engineering and Service Mapping Yang Model";
Editor: Qin Wu }
<mailto:bill.wu@huawei.com>"; import ietf-l3vpn-ntw {
description prefix l3vpn-ntw;
"This module contains a YANG module for the mapping of Layer 3 reference
Network Model (L3NM) to the TE and VN. "I-D.ietf-opsawg-l3sm-l3nm: A Layer 3 VPN Network YANG Model";
}
Copyright (c) 2020 IETF Trust and the persons identified as organization
authors of the code. All rights reserved. "IETF Traffic Engineering Architecture and Signaling (TEAS)
Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/teas/>
WG List: <mailto:teas@ietf.org>
Redistribution and use in source and binary forms, with or Editor: Young Lee
without modification, is permitted pursuant to, and subject to <mailto:younglee.tx@gmail.com>
the license terms contained in, the Simplified BSD License set Editor: Dhruv Dhody
forth in Section 4.c of the IETF Trust's Legal Provisions <mailto:dhruv.ietf@gmail.com>
Relating to IETF Documents Editor: Qin Wu
(https://trustee.ietf.org/license-info). <mailto:bill.wu@huawei.com>";
description
"This module contains a YANG module for the mapping of Layer 3
Network Model (L3NM) to the TE and VN.
This version of this YANG module is part of RFC XXXX; see the Copyright (c) 2021 IETF Trust and the persons identified as
RFC itself for full legal notices. authors of the code. All rights reserved.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL Redistribution and use in source and binary forms, with or
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', without modification, is permitted pursuant to, and subject to
'MAY', and 'OPTIONAL' in this document are to be interpreted as the license terms contained in, the Simplified BSD License set
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, forth in Section 4.c of the IETF Trust's Legal Provisions
they appear in all capitals, as shown here."; Relating to IETF Documents
(https://trustee.ietf.org/license-info).
revision 2020-11-02 { This version of this YANG module is part of RFC XXXX; see the
description RFC itself for full legal notices.
"Initial revision.";
reference
"RFC XXXX: Traffic Engineering and Service Mapping Yang Model";
}
/* The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
* Augmentation to L3NM NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
*/ 'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.";
augment "/l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services" revision 2021-02-20 {
+ "/l3vpn-ntw:vpn-service" { description
description "Initial revision.";
"L3SM augmented to include TE parameters and mapping"; reference
container te-service-mapping { "RFC XXXX: Traffic Engineering and Service Mapping Yang Model";
presence "Indicates L3 network to TE mapping"; }
description
"Container to augment l3nm to TE parameters and mapping";
uses tsm-types:te-mapping;
}
}
//augment /*
* Augmentation to L3NM
*/
augment "/l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services" augment "/l3vpn-ntw:l3vpn-ntw/l3vpn-ntw:vpn-services"
+ "/l3vpn-ntw:vpn-service" + "/l3vpn-ntw:vpn-service" {
+ "/l3vpn-ntw:vpn-nodes/l3vpn-ntw:vpn-node" description
+ "/l3vpn-ntw:vpn-network-accesses" "L3SM augmented to include TE parameters and mapping";
+ "/l3vpn-ntw:vpn-network-access" { container te-service-mapping {
description presence "Indicates L3 network to TE mapping";
"This augment is only valid for TE mapping of L3NM network-access description
to TE endpoints"; "Container to augment l3nm to TE parameters and mapping";
uses tsm-types:te-endpoint-ref; uses tsmt:te-mapping;
} }
}
//augment //augment
}
<CODE ENDS> 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;
}
7.3.2. ietf-l2nm-te-service-mapping //augment
}
<CODE ENDS>
<CODE BEGINS> file "ietf-l2nm-te-service-mapping@2020-11-02.yang" 7.3.2. ietf-l2nm-te-service-mapping
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 tsm-types;
reference
"RFC XXXX: Traffic Engineering and Service Mapping Yang Model";
}
import ietf-l2vpn-ntw {
prefix l2vpn-ntw;
reference
"I-D.ietf-l2nm: A Layer 2 VPN Network YANG Model";
}
organization <CODE BEGINS> file "ietf-l2nm-te-service-mapping@2021-02-20.yang"
"IETF Traffic Engineering Architecture and Signaling (TEAS) module ietf-l2nm-te-service-mapping {
Working Group"; yang-version 1.1;
contact namespace
"WG Web: <http://tools.ietf.org/wg/teas/> "urn:ietf:params:xml:ns:yang:ietf-l2nm-te-service-mapping";
WG List: <mailto:teas@ietf.org> prefix l2nm-tsm;
import ietf-te-service-mapping-types {
prefix tsmt;
reference
"RFC XXXX: Traffic Engineering and Service Mapping Yang Model";
}
import ietf-l2vpn-ntw {
prefix l2vpn-ntw;
reference
"I-D.ietf-opsawg-l2nm: A Layer 2 VPN Network YANG Model";
}
Editor: Young Lee organization
<mailto:younglee.tx@gmail.com> "IETF Traffic Engineering Architecture and Signaling (TEAS)
Editor: Dhruv Dhody Working Group";
<mailto:dhruv.ietf@gmail.com> contact
Editor: Qin Wu "WG Web: <http://tools.ietf.org/wg/teas/>
<mailto:bill.wu@huawei.com>"; WG List: <mailto:teas@ietf.org>
description
"This module contains a YANG module for the mapping of Layer 2
Network Model (L2NM) to the TE and VN.
Copyright (c) 2020 IETF Trust and the persons identified as Editor: Young Lee
authors of the code. All rights reserved. <mailto:younglee.tx@gmail.com>
Editor: Dhruv Dhody
<mailto:dhruv.ietf@gmail.com>
Editor: Qin Wu
<mailto:bill.wu@huawei.com>";
description
"This module contains a YANG module for the mapping of Layer 2
Network Model (L2NM) to the TE and VN.
Redistribution and use in source and binary forms, with or Copyright (c) 2021 IETF Trust and the persons identified as
without modification, is permitted pursuant to, and subject to authors of the code. All rights reserved.
the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the Redistribution and use in source and binary forms, with or
RFC itself for full legal notices. without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL This version of this YANG module is part of RFC XXXX; see the
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', RFC itself for full legal notices.
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.";
revision 2020-11-02 { The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
description NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
"Initial revision."; 'MAY', and 'OPTIONAL' in this document are to be interpreted as
reference described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
"RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; they appear in all capitals, as shown here.";
}
/* revision 2021-02-20 {
* Augmentation to L2NM description
*/ "Initial revision.";
reference
"RFC XXXX: Traffic Engineering and Service Mapping Yang Model";
}
augment "/l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services" /*
+ "/l2vpn-ntw:vpn-service" { * Augmentation to L2NM
description */
"L2SM augmented to include TE parameters and mapping";
container te-service-mapping {
presence "Indicates L2 network to TE mapping";
description
"Container to augment l2nm to TE parameters and mapping";
uses tsm-types:te-mapping;
}
}
//augment augment "/l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services"
+ "/l2vpn-ntw:vpn-service" {
description
"L2SM augmented to include TE parameters and mapping";
container te-service-mapping {
presence "Indicates L2 network to TE mapping";
description
"Container to augment l2nm to TE parameters and mapping";
uses tsmt:te-mapping;
}
}
augment "/l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services" //augment
+ "/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 is only valid for TE mapping of L2NM network-access
to TE endpoints";
uses tsm-types:te-endpoint-ref;
}
//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;
}
<CODE ENDS> //augment
}
<CODE ENDS>
8. Security Considerations 8. Security Considerations
The YANG modules defined in this document is designed to be accessed The YANG modules defined in this document is designed to be accessed
via network management protocol such as NETCONF [RFC6241] or RESTCONF via network management protocol such as NETCONF [RFC6241] or RESTCONF
[RFC8040]. The lowest NETCONF layer is the secure transport layer [RFC8040]. The lowest NETCONF layer is the secure transport layer
and the mandatory-to-implement secure transport is SSH [RFC6242]. and the mandatory-to-implement secure transport is SSH [RFC6242].
The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement
secure transport is TLS [RFC8446] secure transport is TLS [RFC8446]
The NETCONF access control model [RFC8341] provides the means to The NETCONF access control model [RFC8341] provides the means to
skipping to change at page 41, line 10 skipping to change at page 42, line 10
mapping. mapping.
Unauthorized access to above list can adversely affect the VPN Unauthorized access to above list can adversely affect the VPN
service. service.
Some of the readable data nodes in the YANG module may be considered Some of the readable data nodes in the YANG module may be considered
sensitive or vulnerable in some network environments. It is thus sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or important to control read access (e.g., via get, get-config, or
notification) to these data nodes. The TE related parameters notification) to these data nodes. The TE related parameters
attached to the VPN service can leak sensitive information about the attached to the VPN service can leak sensitive information about the
network. This is apploicable to all elements in the yang models network. This is applicable to all elements in the yang models
defined in this document. defined in this document.
This document has no RPC defined. This document has no RPC defined.
9. IANA Considerations 9. IANA Considerations
This document request the IANA to register four URIs in the "IETF XML This document request the IANA to register six URIs in the "IETF XML
Registry" [RFC3688]. Following the format in RFC 3688, the following Registry" [RFC3688]. Following the format in RFC 3688, the following
registrations are requested - registrations are requested -
URI: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types URI: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping URI: urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
skipping to change at page 41, line 45 skipping to change at page 42, line 45
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-l3nm-te-service-mapping URI: urn:ietf:params:xml:ns:yang:ietf-l3nm-te-service-mapping
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-l2nm-te-service-mapping URI: urn:ietf:params:xml:ns:yang:ietf-l2nm-te-service-mapping
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
This document request the IANA to register four YANG modules in the This document request the IANA to register six YANG modules in the
"YANG Module Names" registry [RFC6020], as follows - "YANG Module Names" registry [RFC6020], as follows -
Name: ietf-te-service-mapping-types Name: ietf-te-service-mapping-types
Namespace: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types Namespace: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types
Prefix: tsm-types Prefix: tsmt
Reference: [This.I-D] Reference: [This.I-D]
Name: ietf-l3sm-te-service-mapping Name: ietf-l3sm-te-service-mapping
Namespace: urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping Namespace: urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping
Prefix: l3-tsm Prefix: l3-tsm
Reference: [This.I-D] Reference: [This.I-D]
Name: ietf-l2sm-te-service-mapping Name: ietf-l2sm-te-service-mapping
Namespace: urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping Namespace: urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping
Prefix: l2-tsm Prefix: l2-tsm
skipping to change at page 42, line 46 skipping to change at page 43, line 46
We thank Diego Caviglia, and Igor Bryskin for useful discussions and We thank Diego Caviglia, and Igor Bryskin for useful discussions and
motivation for this work. motivation for this work.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-ccamp-l1csm-yang] [I-D.ietf-ccamp-l1csm-yang]
Lee, Y., Lee, K., Zheng, H., Dios, O., and D. Ceccarelli, Lee, Y., Lee, K., Zheng, H., Dios, O., and D. Ceccarelli,
"A YANG Data Model for L1 Connectivity Service Model "A YANG Data Model for L1 Connectivity Service Model
(L1CSM)", draft-ietf-ccamp-l1csm-yang-12 (work in (L1CSM)", draft-ietf-ccamp-l1csm-yang-13 (work in
progress), September 2020. progress), November 2020.
[I-D.ietf-opsawg-l2nm] [I-D.ietf-opsawg-l2nm]
barguil, s., Dios, O., Boucadair, M., Munoz, L., Jalil, barguil, s., Dios, O., Boucadair, M., Munoz, L., Jalil,
L., and J. Ma, "A Layer 2 VPN Network YANG Model", draft- L., and J. Ma, "A Layer 2 VPN Network YANG Model", draft-
ietf-opsawg-l2nm-00 (work in progress), July 2020. ietf-opsawg-l2nm-01 (work in progress), November 2020.
[I-D.ietf-opsawg-l3sm-l3nm] [I-D.ietf-opsawg-l3sm-l3nm]
barguil, s., Dios, O., Boucadair, M., Munoz, L., and A. barguil, s., Dios, O., Boucadair, M., Munoz, L., and A.
Aguado, "A Layer 3 VPN Network YANG Model", draft-ietf- Aguado, "A Layer 3 VPN Network YANG Model", draft-ietf-
opsawg-l3sm-l3nm-05 (work in progress), October 2020. opsawg-l3sm-l3nm-05 (work in progress), October 2020.
[I-D.ietf-spring-sr-policy-yang] [I-D.ietf-spring-sr-policy-yang]
Raza, K., Sawaya, R., Shunwan, Z., Voyer, D., Durrani, M., Raza, K., Sawaya, R., Shunwan, Z., Voyer, D., Durrani, M.,
Matsushima, S., and V. Beeram, "YANG Data Model for Matsushima, S., and V. Beeram, "YANG Data Model for
Segment Routing Policy", draft-ietf-spring-sr-policy- Segment Routing Policy", draft-ietf-spring-sr-policy-
yang-00 (work in progress), September 2020. yang-00 (work in progress), September 2020.
[I-D.ietf-teas-actn-vn-yang] [I-D.ietf-teas-actn-vn-yang]
Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B. Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B.
Yoon, "A YANG Data Model for VN Operation", draft-ietf- Yoon, "A YANG Data Model for VN Operation", draft-ietf-
teas-actn-vn-yang-09 (work in progress), July 2020. teas-actn-vn-yang-10 (work in progress), November 2020.
[I-D.ietf-teas-yang-te] [I-D.ietf-teas-yang-te]
Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
"A YANG Data Model for Traffic Engineering Tunnels, Label "A YANG Data Model for Traffic Engineering Tunnels, Label
Switched Paths and Interfaces", draft-ietf-teas-yang-te-25 Switched Paths and Interfaces", draft-ietf-teas-yang-te-25
(work in progress), July 2020. (work in progress), July 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
skipping to change at page 43, line 50 skipping to change at page 45, line 5
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>. <https://www.rfc-editor.org/info/rfc6242>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>.
[RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G.,
Ceccarelli, D., and X. Zhang, "Problem Statement and Ceccarelli, D., and X. Zhang, "Problem Statement and
Architecture for Information Exchange between Architecture for Information Exchange between
Interconnected Traffic-Engineered Networks", BCP 206, Interconnected Traffic-Engineered Networks", BCP 206,
RFC 7926, DOI 10.17487/RFC7926, July 2016, RFC 7926, DOI 10.17487/RFC7926, July 2016,
<https://www.rfc-editor.org/info/rfc7926>. <https://www.rfc-editor.org/info/rfc7926>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
skipping to change at page 45, line 9 skipping to change at page 46, line 9
[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
Routing Management (NMDA Version)", RFC 8349, Routing Management (NMDA Version)", RFC 8349,
DOI 10.17487/RFC8349, March 2018, DOI 10.17487/RFC8349, March 2018,
<https://www.rfc-editor.org/info/rfc8349>. <https://www.rfc-editor.org/info/rfc8349>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Abstraction and Control of TE Networks (ACTN)", RFC 8453,
DOI 10.17487/RFC8453, August 2018,
<https://www.rfc-editor.org/info/rfc8453>.
[RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG
Data Model for Layer 2 Virtual Private Network (L2VPN) Data Model for Layer 2 Virtual Private Network (L2VPN)
Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October
2018, <https://www.rfc-editor.org/info/rfc8466>. 2018, <https://www.rfc-editor.org/info/rfc8466>.
[RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
"Common YANG Data Types for Traffic Engineering", "Common YANG Data Types for Traffic Engineering",
RFC 8776, DOI 10.17487/RFC8776, June 2020, RFC 8776, DOI 10.17487/RFC8776, June 2020,
<https://www.rfc-editor.org/info/rfc8776>. <https://www.rfc-editor.org/info/rfc8776>.
skipping to change at page 45, line 47 skipping to change at page 47, line 5
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module
Classification", RFC 8199, DOI 10.17487/RFC8199, July Classification", RFC 8199, DOI 10.17487/RFC8199, July
2017, <https://www.rfc-editor.org/info/rfc8199>. 2017, <https://www.rfc-editor.org/info/rfc8199>.
[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
<https://www.rfc-editor.org/info/rfc8309>. <https://www.rfc-editor.org/info/rfc8309>.
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Appendix A. Examples
Abstraction and Control of TE Networks (ACTN)", RFC 8453,
DOI 10.17487/RFC8453, August 2018,
<https://www.rfc-editor.org/info/rfc8453>.
Appendix A. Contributor Addresses This section details a few examples on how the TE-service mapping is
used in various scenarios.
Example 1: An L3VPN service with an optimization criteria for the
underlying TE as delay can be set in the mapping template and then
augmented to the L3SM service.
{
"te-mapping-template":[
{
"id": "delay",
"map-type": "select",
"optimizations":
{
"algorithm":{
"optimization-metric": [
{
"metric-type":"path-metric-delay-average"
}
]
}
}
}
]
}
The L3SM service can map it to the existing least delay TE resources
in form of a VN or TE-tunnels.
Example 2: An L2VPN service with a bandwidth constraint and a hop-
limit criteria for the underlying TE can be set in the mapping
template and then augmented to the L2SM service.
{
"te-mapping-template":[
{
"id": "bw-hop",
"map-type": "new",
"path-constraints":{
"te-bandwidth":{
"generic":10000
},
"path-metric-bounds":{
"path-metric-bound":[
{
"metric-type":"path-metric-hop",
"upper-bound":10
}
]
}
}
]
}
The L2SM service can map it to a new TE resources in form of a VN or
TE-tunnels.
Example 3: A VN (VN1) could be created before hand and then
explicitly mapped to the L2VPN service as shown below.
<?xml version="1.0"?>
<l2vpn-svc xmlns="urn:ietf:params:xml:ns:yang:ietf-l2vpn-svc">
<vpn-services>
<vpn-service>
<vpn-id>VPN1</vpn-id>
<te-service-mapping>
<te-mapping>
<map-type>select</map-type>
<te>
<vn>VN1</vn>
</te>
</te-mapping>
</te-service-mapping>
</vpn-service>
</vpn-services>
</l2vpn-svc>
Example 4: A VPN service may want different optimization criteria for
some of its sites. The template does not allow for such a case but
it can be achieved by creating the TE resources separately and then
mapping them to the service.
Appendix B. Discussion
o While the support to bind a tunnel to the VPN is supported. We do
not have a mechanism to map traffic to a path. The input can come
from the user. E.g. the enterprise customer can tell, the traffic
from source X on port Y should go with delay less than Z. Further
discussion is required on how and where to model these.
o Support for Calendaring and scheduling TE resources.
Appendix C. Contributor Addresses
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
EMail: adrian@olddog.co.uk EMail: adrian@olddog.co.uk
Italo Busi Italo Busi
Huawei Technologies Huawei Technologies
EMail: Italo.Busi@huawei.com EMail: Italo.Busi@huawei.com
 End of changes. 139 change blocks. 
471 lines changed or deleted 643 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/