draft-ietf-teas-te-service-mapping-yang-03.txt   draft-ietf-teas-te-service-mapping-yang-04.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: September 9, 2020 G. Fioccola Expires: January 14, 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
March 8, 2020 July 13, 2020
Traffic Engineering (TE) and Service Mapping Yang Model Traffic Engineering (TE) and Service Mapping Yang Model
draft-ietf-teas-te-service-mapping-yang-03 draft-ietf-teas-te-service-mapping-yang-04
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 September 9, 2020. This Internet-Draft will expire on January 14, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
described in the Simplified BSD License. described in the Simplified BSD License.
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.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 . . . . . . . . . . . . 6 2.1. VN/Tunnel Selection Requirements . . . . . . . . . . . . 7
2.2. Availability Requirement . . . . . . . . . . . . . . . . 7 2.2. Availability Requirement . . . . . . . . . . . . . . . . 8
3. YANG Modeling Approach . . . . . . . . . . . . . . . . . . . 7 3. YANG Modeling Approach . . . . . . . . . . . . . . . . . . . 8
3.1. Forward Compatibility . . . . . . . . . . . . . . . . . . 8 3.1. Forward Compatibility . . . . . . . . . . . . . . . . . . 9
3.2. TE and Network Models . . . . . . . . . . . . . . . . . . 8 3.2. TE and Network Models . . . . . . . . . . . . . . . . . . 9
4. L3VPN Architecture in the ACTN Context . . . . . . . . . . . 9 4. L3VPN Architecture in the ACTN Context . . . . . . . . . . . 10
4.1. Service Mapping . . . . . . . . . . . . . . . . . . . . . 12 4.1. Service Mapping . . . . . . . . . . . . . . . . . . . . . 13
4.2. Site Mapping . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Site Mapping . . . . . . . . . . . . . . . . . . . . . . 13
5. Applicability of TE-Service Mapping in Generic context . . . 13 5. Applicability of TE-Service Mapping in Generic context . . . 14
6. YANG Data Trees . . . . . . . . . . . . . . . . . . . . . . . 13 6. YANG Data Trees . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Service Models . . . . . . . . . . . . . . . . . . . . . 13 6.1. Service Mapping Types . . . . . . . . . . . . . . . . . . 14
6.1.1. L3SM . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Service Models . . . . . . . . . . . . . . . . . . . . . 16
6.1.2. L2SM . . . . . . . . . . . . . . . . . . . . . . . . 14 6.2.1. L3SM . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1.3. L1CSM . . . . . . . . . . . . . . . . . . . . . . . . 15 6.2.2. L2SM . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Network Models . . . . . . . . . . . . . . . . . . . . . 16 6.2.3. L1CSM . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2.1. L3NM . . . . . . . . . . . . . . . . . . . . . . . . 16 6.3. Network Models . . . . . . . . . . . . . . . . . . . . . 18
6.2.2. L2NM . . . . . . . . . . . . . . . . . . . . . . . . 17 6.3.1. L3NM . . . . . . . . . . . . . . . . . . . . . . . . 18
7. YANG Data Models . . . . . . . . . . . . . . . . . . . . . . 18 6.3.2. L2NM . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. ietf-te-service-mapping-types . . . . . . . . . . . . . . 18 7. YANG Data Models . . . . . . . . . . . . . . . . . . . . . . 20
7.2. Service Models . . . . . . . . . . . . . . . . . . . . . 24 7.1. ietf-te-service-mapping-types . . . . . . . . . . . . . . 20
7.2.1. ietf-l3sm-te-service-mapping . . . . . . . . . . . . 24 7.2. Service Models . . . . . . . . . . . . . . . . . . . . . 29
7.2.2. ietf-l2sm-te-service-mapping . . . . . . . . . . . . 26 7.2.1. ietf-l3sm-te-service-mapping . . . . . . . . . . . . 29
7.2.3. ietf-l1csm-te-service-mapping . . . . . . . . . . . . 28 7.2.2. ietf-l2sm-te-service-mapping . . . . . . . . . . . . 31
7.3. Network Models . . . . . . . . . . . . . . . . . . . . . 30 7.2.3. ietf-l1csm-te-service-mapping . . . . . . . . . . . . 33
7.3.1. ietf-l3nm-te-service-mapping . . . . . . . . . . . . 30 7.3. Network Models . . . . . . . . . . . . . . . . . . . . . 35
7.3.2. ietf-l2nm-te-service-mapping . . . . . . . . . . . . 32 7.3.1. ietf-l3nm-te-service-mapping . . . . . . . . . . . . 35
7.3.2. ietf-l2nm-te-service-mapping . . . . . . . . . . . . 37
8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 8. Security Considerations . . . . . . . . . . . . . . . . . . . 39
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
11.1. Normative References . . . . . . . . . . . . . . . . . . 37 11.1. Normative References . . . . . . . . . . . . . . . . . . 42
11.2. Informative References . . . . . . . . . . . . . . . . . 39 11.2. Informative References . . . . . . . . . . . . . . . . . 45
Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 40 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
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 4, line 39 skipping to change at page 4, line 41
performance degradation and so forth. performance degradation and so forth.
Section 2 describes a set of TE and service related parameters that Section 2 describes a set of TE and service related parameters that
this document addresses as "new and advanced parameters" that are not this document addresses as "new and advanced parameters" that are not
included in generic service models. Section 3 discusses YANG included in generic service models. Section 3 discusses YANG
modelling approach. modelling approach.
Apart from the service model, the TE mapping is equally applicable to Apart from the service model, the TE mapping is equally applicable to
the Network Models (L3 VPN Service Network Model (L3NM) the Network Models (L3 VPN Service Network Model (L3NM)
[I-D.ietf-opsawg-l3sm-l3nm], L2 VPN Service Network Model (L2NM) [I-D.ietf-opsawg-l3sm-l3nm], L2 VPN Service Network Model (L2NM)
[I-D.barguil-opsawg-l2sm-l2nm] etc.). See Section 3.2 for details. [I-D.ietf-opsawg-l2nm] etc.). See Section 3.2 for details.
1.1. Terminology 1.1. Terminology
Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used
in this document. in this document.
The terminology for describing YANG data models is found in The terminology for describing YANG data models is found in
[RFC7950]. [RFC7950].
1.1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.2. Tree diagram 1.2. Tree diagram
A simplified graphical representation of the data model is used in A simplified graphical representation of the data model is used in
Section 5 of this this document. The meaning of the symbols in these Section 5 of this this document. The meaning of the symbols in these
diagrams is defined in [RFC8340]. diagrams is defined in [RFC8340].
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 |
+---------+----------------------------+----------------------------+ +---------+---------------------------+-----------------------------+
| tsm- | ietf-te-service-mapping- | [RFCXXXX] | | inet | ietf-inet-types | [RFC6991] |
| types | types | | | tsm- | ietf-te-service-mapping- | [RFCXXXX] |
| l1csm | ietf-l1csm | [I-D.ietf-ccamp-l1csm-yang | | types | types | |
| | | ] | | 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] |
| | mapping | | | | mapping | |
| vn | ietf-vn | [I-D.ietf-teas-actn-vn-yan | | vn | ietf-vn | [I-D.ietf-teas-actn-vn-yang |
| | | g] | | | | ] |
| nw | ietf-network | [RFC8345] | | nw | ietf-network | [RFC8345] |
| te- | ietf-te-types | [I-D.ietf-teas-yang-te-typ | | te- | ietf-te-types | [RFC8776] |
| types | | es] | | types | | |
| te | ietf-te | [I-D.ietf-teas-yang-te] | | te | ietf-te | [I-D.ietf-teas-yang-te] |
| l1csm | ietf-l1csm | [I-D.ietf-ccamp-l1csm-yang | | l2vpn- | ietf-l2vpn-ntw | [I-D.ietf-opsawg-l2nm] |
| | | ] | | ntw | | |
| l2vpn- | ietf-l2vpn-ntw | [I-D.barguil-opsawg-l2sm-l | | l3vpn- | ietf-l3vpn-ntw | [I-D.ietf-opsawg-l3sm-l3nm] |
| ntw | | 2nm] | | ntw | | |
| l3vpn- | ietf-l3vpn-ntw | [I-D.ietf-opsawg-l3sm-l3nm | | rt | ietf-routing | [RFC8349] |
| ntw | | ] | | sr- | ietf-sr-policy | [I-D.raza-spring-sr-policy- |
+---------+----------------------------+----------------------------+ | policy | | yang] |
+---------+---------------------------+-----------------------------+
Table 1: Prefixes and corresponding YANG modules Table 1: Prefixes and corresponding YANG modules
Note: The RFC Editor should replace XXXX with the number assigned to Note: The RFC Editor should replace XXXX with the number assigned to
the RFC once this draft becomes an RFC. the RFC once this draft becomes an RFC.
2. TE and Service Related Parameters 2. TE and Service Related Parameters
While L1/L2/L3 service models (L1CSM, L2SM, L3SM) are intended to While L1/L2/L3 service models (L1CSM, L2SM, L3SM) are intended to
provide service-specific parameters for VPN service instances, there provide service-specific parameters for VPN service instances, there
skipping to change at page 7, line 16 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
to 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, this
mode is no longer used and replaced with the above modes.
2.2. Availability Requirement 2.2. 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
skipping to change at page 8, line 51 skipping to change at page 9, line 48
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 containts 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.barguil-opsawg-l2sm-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.
+--------------+ +----------------------+ +----------+ +--------------+ +----------------------+ +----------+
| LxNM |o-------| | . . . . | ACTN VN | | LxNM |o-------| | . . . . | ACTN VN |
+--------------+ augment| | +----------+ +--------------+ augment| | +----------+
| | +----------+ | | +----------+
+--------------+ | Augmented LxNM Model | . . . . | TE-topo | +--------------+ | Augmented LxNM Model | . . . . | TE-topo |
| TE & Service |------->| | +----------+ | TE & Service |------->| | +----------+
| Mapping Types| import | | +----------+ | Mapping Types| import | | +----------+
skipping to change at page 13, line 40 skipping to change at page 14, line 40
As discussed in the Introduction Section, the models presented in As discussed in the Introduction Section, the models presented in
this document are also applicable generically outside of the ACTN this document are also applicable generically outside of the ACTN
architecture. [RFC8309] defines Customer Service Model between architecture. [RFC8309] defines Customer Service Model between
Customer and Service Orchestrator and Service Delivery Model between Customer and Service Orchestrator and Service Delivery Model between
Service Orchestrator and Network Orchestrator(s). TE-Service mapping Service Orchestrator and Network Orchestrator(s). TE-Service mapping
models defined in this document can be regarded primarily as Customer models defined in this document can be regarded primarily as Customer
Service Model and secondarily as Service Deliver Model. Service Model and secondarily as Service Deliver Model.
6. YANG Data Trees 6. YANG Data Trees
6.1. Service Models 6.1. Service Mapping Types
module: ietf-te-service-mapping-types
+--rw te-mapping-templates
+--rw te-mapping-template* [id]
+--rw id te-mapping-template-id
+--rw description? string
+--rw map-type? identityref
+--rw path-constraints
| +--rw te-bandwidth
| | +--rw (technology)?
| | +--:(generic)
| | +--rw generic? te-bandwidth
| +--rw link-protection? identityref
| +--rw setup-priority? uint8
| +--rw hold-priority? uint8
| +--rw signaling-type? identityref
| +--rw path-metric-bounds
| | +--rw path-metric-bound* [metric-type]
| | +--rw metric-type identityref
| | +--rw upper-bound? uint64
| +--rw path-affinities-values
| | +--rw path-affinities-value* [usage]
| | +--rw usage identityref
| | +--rw value? admin-groups
| +--rw path-affinity-names
| | +--rw path-affinity-name* [usage]
| | +--rw usage identityref
| | +--rw affinity-name* [name]
| | +--rw name string
| +--rw path-srlgs-lists
| | +--rw path-srlgs-list* [usage]
| | +--rw usage identityref
| | +--rw values* srlg
| +--rw path-srlgs-names
| | +--rw path-srlgs-name* [usage]
| | +--rw usage identityref
| | +--rw names* string
| +--rw disjointness? te-path-disjointness
+--rw optimizations
+--rw (algorithm)?
+--:(metric) {path-optimization-metric}?
| +--rw optimization-metric* [metric-type]
| | +--rw metric-type
| | | identityref
| | +--rw weight? uint8
| | +--rw explicit-route-exclude-objects
| | | +--rw route-object-exclude-object* [index]
| | | ...
| | +--rw explicit-route-include-objects
| | +--rw route-object-include-object* [index]
| | ...
| +--rw tiebreakers
| +--rw tiebreaker* [tiebreaker-type]
| +--rw tiebreaker-type identityref
+--:(objective-function)
{path-optimization-objective-function}?
+--rw objective-function
+--rw objective-function-type? identityref
6.2. Service Models
6.2.1. L3SM
6.1.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 availability-type? identityref
+--rw (te)? +--rw (te)?
+--:(vn) +--:(vn)
| +--rw vn-ref? -> /vn:vn/vn-list/vn-id | +--rw vn-ref?
| -> /vn:vn/vn-list/vn-id
+--:(te-topo) +--:(te-topo)
| +--rw vn-topology-id? te-types:te-topology-id | +--rw vn-topology-id?
| | te-types:te-topology-id
| +--rw abstract-node? | +--rw abstract-node?
| -> /nw:networks/network/node/node-id | -> /nw:networks/network/node/node-id
+--:(te-tunnel) +--:(te-tunnel)
+--rw te-tunnel-list* te:tunnel-ref | +--rw te-tunnel-list* te:tunnel-ref
| +--rw sr-policy*
| [policy-color-ref policy-endpoint-ref]
| {sr-policy}?
| +--rw policy-color-ref leafref
| +--rw policy-endpoint-ref leafref
+--:(te-mapping-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 vn-ref? | +--rw vn-ref?
| -> /vn:ap/access-point-list/access-point-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.1.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 availability-type? identityref
+--rw (te)? +--rw (te)?
+--:(vn) +--:(vn)
| +--rw vn-ref? -> /vn:vn/vn-list/vn-id | +--rw vn-ref?
| -> /vn:vn/vn-list/vn-id
+--:(te-topo) +--:(te-topo)
| +--rw vn-topology-id? te-types:te-topology-id | +--rw vn-topology-id?
| | te-types:te-topology-id
| +--rw abstract-node? | +--rw abstract-node?
| -> /nw:networks/network/node/node-id | -> /nw:networks/network/node/node-id
+--:(te-tunnel) +--:(te-tunnel)
+--rw te-tunnel-list* te:tunnel-ref | +--rw te-tunnel-list* te:tunnel-ref
| +--rw sr-policy*
| [policy-color-ref policy-endpoint-ref]
| {sr-policy}?
| +--rw policy-color-ref leafref
| +--rw policy-endpoint-ref leafref
+--:(te-mapping-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 vn-ref? | +--rw vn-ref?
| -> /vn:ap/access-point-list/access-point-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.1.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 availability-type? identityref
+--rw (te)? +--rw (te)?
+--:(vn) +--:(vn)
| +--rw vn-ref? -> /vn:vn/vn-list/vn-id | +--rw vn-ref?
| -> /vn:vn/vn-list/vn-id
+--:(te-topo) +--:(te-topo)
| +--rw vn-topology-id? te-types:te-topology-id | +--rw vn-topology-id?
| | te-types:te-topology-id
| +--rw abstract-node? | +--rw abstract-node?
| -> /nw:networks/network/node/node-id | -> /nw:networks/network/node/node-id
+--:(te-tunnel) +--:(te-tunnel)
+--rw te-tunnel-list* te:tunnel-ref | +--rw te-tunnel-list* te:tunnel-ref
| +--rw sr-policy*
| [policy-color-ref policy-endpoint-ref]
| {sr-policy}?
| +--rw policy-color-ref leafref
| +--rw policy-endpoint-ref leafref
+--:(te-mapping-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 vn-ref? | +--rw vn-ref?
| -> /vn:ap/access-point-list/access-point-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.2. Network Models 6.3. Network Models
6.2.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 availability-type? identityref
+--rw (te)? +--rw (te)?
+--:(vn) +--:(vn)
| +--rw vn-ref? -> /vn:vn/vn-list/vn-id | +--rw vn-ref?
| -> /vn:vn/vn-list/vn-id
+--:(te-topo) +--:(te-topo)
| +--rw vn-topology-id? te-types:te-topology-id | +--rw vn-topology-id?
| | te-types:te-topology-id
| +--rw abstract-node? | +--rw abstract-node?
| -> /nw:networks/network/node/node-id | -> /nw:networks/network/node/node-id
+--:(te-tunnel) +--:(te-tunnel)
+--rw te-tunnel-list* te:tunnel-ref | +--rw te-tunnel-list* te:tunnel-ref
| +--rw sr-policy*
| [policy-color-ref policy-endpoint-ref]
| {sr-policy}?
| +--rw policy-color-ref leafref
| +--rw policy-endpoint-ref leafref
+--:(te-mapping-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 vn-ref? | +--rw vn-ref?
| -> /vn:ap/access-point-list/access-point-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.2.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-svc: /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 availability-type? identityref
+--rw (te)? +--rw (te)?
+--:(vn) +--:(vn)
| +--rw vn-ref? -> /vn:vn/vn-list/vn-id | +--rw vn-ref?
| -> /vn:vn/vn-list/vn-id
+--:(te-topo) +--:(te-topo)
| +--rw vn-topology-id? te-types:te-topology-id | +--rw vn-topology-id?
| | te-types:te-topology-id
| +--rw abstract-node? | +--rw abstract-node?
| -> /nw:networks/network/node/node-id | -> /nw:networks/network/node/node-id
+--:(te-tunnel) +--:(te-tunnel)
+--rw te-tunnel-list* te:tunnel-ref | +--rw te-tunnel-list* te:tunnel-ref
| +--rw sr-policy*
| [policy-color-ref policy-endpoint-ref]
| {sr-policy}?
| +--rw policy-color-ref leafref
| +--rw policy-endpoint-ref leafref
+--:(te-mapping-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-svc/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 vn-ref? | +--rw vn-ref?
| -> /vn:ap/access-point-list/access-point-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-03-08.yang" <CODE BEGINS> file "ietf-te-service-mapping-types@2020-07-13.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;
prefix tsm-types;
/* Import inet-types */
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types";
}
/* Import inet-types */
import ietf-te-types { import ietf-te-types {
prefix te-types; prefix te-types;
reference reference
"I-D.ietf-teas-yang-te-types: Traffic Engineering Common YANG "RFC 8776: Common YANG Data Types for Traffic Engineering";
Types";
} }
/* Import network model */
import ietf-network { import ietf-network {
prefix nw; prefix nw;
reference reference
"RFC 8345: A YANG Data Model for Network Topologies"; "RFC 8345: A YANG Data Model for Network Topologies";
} }
/* Import TE model */
import ietf-te { import ietf-te {
prefix te; prefix te;
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";
} }
/* Import VN model */
import ietf-vn { import ietf-vn {
prefix vn; prefix vn;
reference reference
"I-D.ietf-teas-actn-vn-yang: A Yang Data Model for VN Operation"; "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.raza-spring-sr-policy-yang: YANG Data Model for Segment
Routing Policy";
}
organization organization
"IETF Traffic Engineering Architecture and Signaling (TEAS) "IETF Traffic Engineering Architecture and Signaling (TEAS)
Working Group"; Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/teas/> "WG Web: <http://tools.ietf.org/wg/teas/>
WG List: <mailto:teas@ietf.org> WG List: <mailto:teas@ietf.org>
Editor: Young Lee Editor: Young Lee
<mailto:younglee.tx@gmail.com> <mailto:younglee.tx@gmail.com>
Editor: Dhruv Dhody Editor: Dhruv Dhody
skipping to change at page 20, line 11 skipping to change at page 23, line 5
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-03-08 { revision 2020-07-13 {
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
*/
feature template {
description
"Support TE mapping templates.";
}
feature sr-policy {
description
"Support SR Policy.";
}
/*
* Identity for map-type * Identity for map-type
*/ */
identity map-type { identity map-type {
description description
"Base identity from which specific map types are derived."; "Base identity from which specific map types are derived.";
} }
identity new { identity new {
base map-type; base map-type;
skipping to change at page 21, line 16 skipping to change at page 24, line 24
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 {
base map-type;
description
"The VPN service selects an TE mapping template with path
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.";
} }
identity level-1 { identity level-1 {
skipping to change at page 22, line 8 skipping to change at page 25, line 23
"level 4: 99.9%"; "level 4: 99.9%";
} }
identity level-5 { identity level-5 {
base availability-type; base availability-type;
description description
"level 5: 99%"; "level 5: 99%";
} }
/* /*
* Typedef
*/
typedef te-mapping-template-id {
type inet:uri;
description
"Identifier for a TE mapping template. The precise
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"; "The TE";
case vn { case vn {
skipping to change at page 23, line 12 skipping to change at page 26, line 42
} }
case te-tunnel { case te-tunnel {
leaf-list te-tunnel-list { leaf-list te-tunnel-list {
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 {
if-feature "sr-policy";
key "policy-color-ref policy-endpoint-ref";
description
"SR Policy";
leaf policy-color-ref {
type leafref {
path
"/rt:routing/sr-policy:segment-routing"
+ "/sr-policy:traffic-engineering/sr-policy:policies"
+ "/sr-policy:policy/sr-policy:color";
}
description
"Reference to sr-policy color";
}
leaf policy-endpoint-ref {
type leafref {
path
"/rt:routing/sr-policy:segment-routing"
+ "/sr-policy:traffic-engineering/sr-policy:policies"
+ "/sr-policy:policy/sr-policy:endpoint";
}
description
"Reference to sr-policy endpoint";
}
}
}
case te-mapping-template {
if-feature "template";
leaf te-mapping-template-ref {
type leafref {
path "/te-mapping-templates/te-mapping-template/id";
}
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 {
skipping to change at page 24, line 29 skipping to change at page 28, line 48
base availability-type; base availability-type;
} }
description description
"Availability Requirement for the Service"; "Availability Requirement for the Service";
} }
uses te-ref; uses te-ref;
} }
} }
//grouping //grouping
container te-mapping-templates {
description
"The TE constraints and optimization criteria";
list te-mapping-template {
key "id";
leaf id {
type te-mapping-template-id;
description
"Identification of the Template to be used.";
}
leaf description {
type string;
description
"Description of the template.";
}
leaf map-type {
type identityref {
base map-type;
}
must '(. != "template")' {
error-message "The map-type must be other than "
+ "TE mapping template";
}
description
"Map type for the VN/Tunnel creation/
selection.";
}
uses te-types:generic-path-constraints;
uses te-types:generic-path-optimization;
description
"List for templates.";
}
}
} }
<CODE ENDS> <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-03-08.yang" <CODE BEGINS> file "ietf-l3sm-te-service-mapping@2020-07-13.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 tsm-types;
reference reference
"RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; "RFC XXXX: Traffic Engineering and Service Mapping Yang Model";
skipping to change at page 26, line 36 skipping to change at page 31, line 43
uses tsm-types:te-endpoint-ref; uses tsm-types:te-endpoint-ref;
} }
//augment //augment
} }
<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-03-08.yang" <CODE BEGINS> file "ietf-l2sm-te-service-mapping@2020-07-13.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 tsm-types;
reference reference
"RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; "RFC XXXX: Traffic Engineering and Service Mapping Yang Model";
skipping to change at page 27, line 43 skipping to change at page 32, line 49
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-03-08 { revision 2020-07-13 {
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 L2SM
*/ */
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" {
description description
"L2SM augmented to include TE parameters and mapping"; "L2SM augmented to include TE parameters and mapping";
container te-service-mapping { container te-service-mapping {
presence "indicates L2 service to te mapping"; presence "indicates L2 service to te mapping";
description description
"Container to augment L2SM to TE parameters and mapping"; "Container to augment L2SM to TE parameters and mapping";
skipping to change at page 28, line 36 skipping to change at page 33, line 43
uses tsm-types:te-endpoint-ref; uses tsm-types:te-endpoint-ref;
} }
//augment //augment
} }
<CODE ENDS> <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-03-08.yang" <CODE BEGINS> file "ietf-l1csm-te-service-mapping@2020-07-13.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 tsm-types;
reference reference
"RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; "RFC XXXX: Traffic Engineering and Service Mapping Yang Model";
skipping to change at page 29, line 43 skipping to change at page 34, line 49
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-03-08 { revision 2020-07-13 {
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
skipping to change at page 30, line 36 skipping to change at page 35, line 43
//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-03-08.yang" <CODE BEGINS> file "ietf-l3nm-te-service-mapping@2020-07-13.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; prefix l3nm-tsm;
import ietf-te-service-mapping-types { import ietf-te-service-mapping-types {
prefix tsm-types; prefix tsm-types;
reference reference
"RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; "RFC XXXX: Traffic Engineering and Service Mapping Yang Model";
skipping to change at page 31, line 43 skipping to change at page 36, line 48
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-03-08 { revision 2020-07-13 {
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 L3NM * Augmentation to L3NM
*/ */
skipping to change at page 32, line 37 skipping to change at page 37, line 43
uses tsm-types:te-endpoint-ref; uses tsm-types:te-endpoint-ref;
} }
//augment //augment
} }
<CODE ENDS> <CODE ENDS>
7.3.2. ietf-l2nm-te-service-mapping 7.3.2. ietf-l2nm-te-service-mapping
<CODE BEGINS> file "ietf-l2nm-te-service-mapping@2020-03-08.yang" <CODE BEGINS> file "ietf-l2nm-te-service-mapping@2020-07-13.yang"
module ietf-l2nm-te-service-mapping { module ietf-l2nm-te-service-mapping {
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-l2nm-te-service-mapping"; "urn:ietf:params:xml:ns:yang:ietf-l2nm-te-service-mapping";
prefix l2nm-tsm; prefix l2nm-tsm;
import ietf-te-service-mapping-types { import ietf-te-service-mapping-types {
prefix tsm-types; prefix tsm-types;
reference reference
"RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; "RFC XXXX: Traffic Engineering and Service Mapping Yang Model";
} }
import ietf-l2vpn-ntw { import ietf-l2vpn-ntw {
prefix l2vpn-ntw; prefix l2vpn-ntw;
reference reference
"I-D.-barguil-opsawg-l2sm-l2nm: A Layer 2 VPN Network YANG Model"; "I-D.ietf-l2nm: A Layer 2 VPN Network YANG Model";
}
} organization
"IETF Traffic Engineering Architecture and Signaling (TEAS)
Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/teas/>
WG List: <mailto:teas@ietf.org>
organization Editor: Young Lee
"IETF Traffic Engineering Architecture and Signaling (TEAS) <mailto:younglee.tx@gmail.com>
Working Group"; Editor: Dhruv Dhody
contact <mailto:dhruv.ietf@gmail.com>
"WG Web: <http://tools.ietf.org/wg/teas/> Editor: Qin Wu
WG List: <mailto:teas@ietf.org> <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.
Editor: Young Lee Copyright (c) 2020 IETF Trust and the persons identified as
<mailto:younglee.tx@gmail.com> authors of the code. All rights reserved.
Editor: Dhruv Dhody
<mailto:dhruv.ietf@gmail.com>
Editor: Qin Wu
<mailto:bill.wu@huawei.com>";
description
"This module contains a YANG module for the mapping of Layer 2
Network Model (L2NM) to the TE and VN.
Copyright (c) 2020 IETF Trust and the persons identified as Redistribution and use in source and binary forms, with or
authors of the code. All rights reserved. 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).
Redistribution and use in source and binary forms, with or This version of this YANG module is part of RFC XXXX; see the
without modification, is permitted pursuant to, and subject to RFC itself for full legal notices.
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 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
RFC itself for full legal notices. 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.";
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL revision 2020-07-13 {
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', description
'MAY', and 'OPTIONAL' in this document are to be interpreted as "Initial revision.";
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.";
revision 2020-03-08 { reference
description "RFC XXXX: Traffic Engineering and Service Mapping Yang Model";
"Initial revision."; }
reference
"RFC XXXX: Traffic Engineering and Service Mapping Yang Model";
}
/* /*
* Augmentation to L2NM * Augmentation to L2NM
*/ */
augment "/l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services" augment "/l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services"
+ "/l2vpn-ntw:vpn-svc" { + "/l2vpn-ntw:vpn-service" {
description description
"L2SM augmented to include TE parameters and mapping"; "L2SM augmented to include TE parameters and mapping";
container te-service-mapping { container te-service-mapping {
presence "Indicates L2 network to TE mapping"; presence "Indicates L2 network to TE mapping";
description description
"Container to augment l2nm to TE parameters and mapping"; "Container to augment l2nm to TE parameters and mapping";
uses tsm-types:te-mapping; uses tsm-types:te-mapping;
} }
} }
//augment //augment
augment "/l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services" augment "/l2vpn-ntw:l2vpn-ntw/l2vpn-ntw:vpn-services"
+ "/l2vpn-ntw:vpn-svc" + "/l2vpn-ntw:vpn-service"
+ "/l2vpn-ntw:vpn-nodes/l2vpn-ntw:vpn-node" + "/l2vpn-ntw:vpn-nodes/l2vpn-ntw:vpn-node"
+ "/l2vpn-ntw:vpn-network-accesses" + "/l2vpn-ntw:vpn-network-accesses"
+ "/l2vpn-ntw:vpn-network-access" { + "/l2vpn-ntw:vpn-network-access" {
description description
"This augment is only valid for TE mapping of L2NM network-access "This augment is only valid for TE mapping of L2NM network-access
to TE endpoints"; to TE endpoints";
uses tsm-types:te-endpoint-ref; uses tsm-types:te-endpoint-ref;
} }
//augment //augment
} }
<CODE ENDS> <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
restrict access for particular NETCONF or RESTCONF users to a pre- restrict access for particular NETCONF or RESTCONF users to a pre-
configured subset of all available NETCONF or RESTCONF protocol configured subset of all available NETCONF or RESTCONF protocol
operations and content. operations and content.
There are a number of data nodes defined in the YANG moduleS which There are a number of data nodes defined in the YANG moduleS which
are writable/creatable/deletable (i.e., config true, which is the are writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., <edit-config>) in some network environments. Write operations (e.g., <edit-config>)
to these data nodes without proper protection can have a negative to these data nodes without proper protection can have a negative
skipping to change at page 37, line 6 skipping to change at page 42, line 6
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 four 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 Prefix: tsm-types
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 37, line 36 skipping to change at page 42, line 36
Prefix: l3nm-tsm Prefix: l3nm-tsm
Reference: [This.I-D] Reference: [This.I-D]
Name: ietf-l2nm-te-service-mapping Name: ietf-l2nm-te-service-mapping
Namespace: urn:ietf:params:xml:ns:yang:ietf-l2nm-te-service-mapping Namespace: urn:ietf:params:xml:ns:yang:ietf-l2nm-te-service-mapping
Prefix: l2nm-tsm Prefix: l2nm-tsm
Reference: [This.I-D] Reference: [This.I-D]
10. Acknowledgements 10. Acknowledgements
We thank Diego Caviglia, Igor Bryskin, Oscar Gonzalez de Dios, and We thank Diego Caviglia, and Igor Bryskin for useful discussions and
Samier Barguil Giraldo for useful discussions and motivation for this motivation for this work.
work.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-ccamp-l1csm-yang]
Lee, Y., Lee, K., Zheng, H., Dhody, D., Dios, O., and D.
Ceccarelli, "A YANG Data Model for L1 Connectivity Service
Model (L1CSM)", draft-ietf-ccamp-l1csm-yang-11 (work in
progress), March 2020.
[I-D.ietf-opsawg-l2nm]
Barguil, S., Dios, O., Boucadair, M., Munoz, L., Jalil,
L., and J. Ma, "A Layer 2 VPN Network YANG Model", draft-
ietf-opsawg-l2nm-00 (work in progress), July 2020.
[I-D.ietf-opsawg-l3sm-l3nm]
Barguil, S., Dios, O., Boucadair, M., Munoz, L., and A.
Aguado, "A Layer 3 VPN Network YANG Model", draft-ietf-
opsawg-l3sm-l3nm-03 (work in progress), April 2020.
[I-D.ietf-teas-actn-vn-yang]
Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B.
Yoon, "A Yang Data Model for VN Operation", draft-ietf-
teas-actn-vn-yang-08 (work in progress), March 2020.
[I-D.ietf-teas-yang-te]
Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
"A YANG Data Model for Traffic Engineering Tunnels and
Interfaces", draft-ietf-teas-yang-te-23 (work in
progress), March 2020.
[I-D.ietf-teas-yang-te-topo]
Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
O. Dios, "YANG Data Model for Traffic Engineering (TE)
Topologies", draft-ietf-teas-yang-te-topo-22 (work in
progress), June 2019.
[I-D.raza-spring-sr-policy-yang]
Raza, K., Sawaya, R., Shunwan, Z., Voyer, D., Durrani, M.,
Matsushima, S., and V. Beeram, "YANG Data Model for
Segment Routing Policy", draft-raza-spring-sr-policy-
yang-02 (work in progress), November 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <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 [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>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki,
"YANG Data Model for L3VPN Service Delivery", RFC 8299, "YANG Data Model for L3VPN Service Delivery", RFC 8299,
DOI 10.17487/RFC8299, January 2018, DOI 10.17487/RFC8299, January 2018,
<https://www.rfc-editor.org/info/rfc8299>. <https://www.rfc-editor.org/info/rfc8299>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341, Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018, DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>. <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., [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
2018, <https://www.rfc-editor.org/info/rfc8345>. 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 [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>.
[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>.
[I-D.ietf-ccamp-l1csm-yang] [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
Lee, Y., Lee, K., Zheng, H., Dhody, D., Dios, O., and D. "Common YANG Data Types for Traffic Engineering",
Ceccarelli, "A YANG Data Model for L1 Connectivity Service RFC 8776, DOI 10.17487/RFC8776, June 2020,
Model (L1CSM)", draft-ietf-ccamp-l1csm-yang-10 (work in <https://www.rfc-editor.org/info/rfc8776>.
progress), September 2019.
[I-D.ietf-teas-actn-vn-yang]
Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B.
Yoon, "A Yang Data Model for VN Operation", draft-ietf-
teas-actn-vn-yang-07 (work in progress), October 2019.
[I-D.ietf-teas-yang-te]
Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
"A YANG Data Model for Traffic Engineering Tunnels and
Interfaces", draft-ietf-teas-yang-te-22 (work in
progress), November 2019.
[I-D.ietf-teas-yang-te-types]
Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
"Traffic Engineering Common YANG Types", draft-ietf-teas-
yang-te-types-13 (work in progress), November 2019.
[I-D.ietf-opsawg-l3sm-l3nm]
Aguado, A., Dios, O., Lopezalvarez, V., Voyer, D., and L.
Munoz, "A Layer 3 VPN Network YANG Model", draft-ietf-
opsawg-l3sm-l3nm-01 (work in progress), November 2019.
[I-D.barguil-opsawg-l2sm-l2nm]
Barguil, S., Dios, O., Lopezalvarez, V., Munoz, L., and L.
Jalil, "A Layer 2 VPN Network Yang Model", draft-barguil-
opsawg-l2sm-l2nm-00 (work in progress), December 2019.
11.2. Informative References 11.2. Informative References
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [I-D.ietf-teas-actn-yang]
the Network Configuration Protocol (NETCONF)", RFC 6020, Lee, Y., Zheng, H., Ceccarelli, D., Yoon, B., Dios, O.,
DOI 10.17487/RFC6020, October 2010, Shin, J., and S. Belotti, "Applicability of YANG models
<https://www.rfc-editor.org/info/rfc6020>. for Abstraction and Control of Traffic Engineered
Networks", draft-ietf-teas-actn-yang-05 (work in
progress), February 2020.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<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>.
[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>.
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Abstraction and Control of TE Networks (ACTN)", RFC 8453, Abstraction and Control of TE Networks (ACTN)", RFC 8453,
DOI 10.17487/RFC8453, August 2018, DOI 10.17487/RFC8453, August 2018,
<https://www.rfc-editor.org/info/rfc8453>. <https://www.rfc-editor.org/info/rfc8453>.
[I-D.ietf-teas-yang-te-topo]
Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
O. Dios, "YANG Data Model for Traffic Engineering (TE)
Topologies", draft-ietf-teas-yang-te-topo-22 (work in
progress), June 2019.
[I-D.ietf-teas-actn-yang]
Lee, Y., Zheng, H., Ceccarelli, D., Yoon, B., Dios, O.,
Shin, J., and S. Belotti, "Applicability of YANG models
for Abstraction and Control of Traffic Engineered
Networks", draft-ietf-teas-actn-yang-05 (work in
progress), February 2020.
Appendix A. Contributor Addresses Appendix A. 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
Haomian Zheng Haomian Zheng
Huawei Technologies Huawei Technologies
EMail: zhenghaomian@huawei.com 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
Authors' Addresses Authors' Addresses
Young Lee (editor) Young Lee (editor)
Samsung Electronics Samsung Electronics
Email: younglee.tx@gmail.com Email: younglee.tx@gmail.com
Dhruv Dhody (editor) Dhruv Dhody (editor)
Huawei Technologies Huawei Technologies
Email: dhruv.ietf@gmail.com Email: dhruv.ietf@gmail.com
skipping to change at page 41, line 29 skipping to change at page 47, line 29
Daniele Ceccarelli Daniele Ceccarelli
Ericsson Ericsson
Torshamnsgatan,48 Torshamnsgatan,48
Stockholm, Sweden Stockholm, Sweden
Email: daniele.ceccarelli@ericsson.com Email: daniele.ceccarelli@ericsson.com
Jeff Tantsura Jeff Tantsura
Apstra Apstra
Email: jefftant@gmail.com Email: jefftant.ietf@gmail.com
 End of changes. 94 change blocks. 
256 lines changed or deleted 568 lines changed or added

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