draft-ietf-teas-te-service-mapping-yang-01.txt   draft-ietf-teas-te-service-mapping-yang-02.txt 
TEAS WG Young Lee
Internet Draft Dhruv Dhody
Intended status: standard track Huawei
Expires: September 5, 2019
Daniele Ceccarelli
Ericsson
Jeff Tantsura
Apstra
Giuseppe Fioccola
Huawei
Qin Wu TEAS Working Group Y. Lee, Ed.
Huawei Internet-Draft SKKU
Intended status: Standards Track D. Dhody, Ed.
March 5, 2019 Expires: March 12, 2020 G. Fioccola
Q. Wu, Ed.
Traffic Engineering and Service Mapping Yang Model Huawei Technologies
D. Ceccarelli
Ericsson
J. Tantsura
Apstra
September 9, 2019
draft-ietf-teas-te-service-mapping-yang-01 Traffic Engineering (TE) and Service Mapping Yang Model
draft-ietf-teas-te-service-mapping-yang-02
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 L3VPM Service Model) to Traffic Engineering (TE) models (e.g., the L3VPN Service Model (L3SM)) to Traffic Engineering
models (e.g., the TE Tunnel or the Abstraction and Control of (TE) models (e.g., the TE Tunnel or the Virtual Network (VN) model).
Traffic Engineered Networks Virtual Network model). This model is This model is referred to as TE Service Mapping Model and is
referred to as TE Service Mapping Model and is applicable applicable generically to the operator's need for seamless control
generically to the operator's need for seamless control and and management of their VPN services with TE tunnel support.
management of their VPN services with TE tunnel support.
The model is principally used to allow monitoring and diagnostics of The model is principally used to allow monitoring and diagnostics of
the management systems to show how the service requests are mapped the management systems to show how the service requests are mapped
onto underlying network resource and TE models. onto underlying network resource and TE models.
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted in full conformance with the
the provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Internet-Drafts are draft documents valid for a maximum of six months
http://www.ietf.org/shadow.html. and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 5, 2019. This Internet-Draft will expire on March 12, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(http://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 carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described in include Simplified BSD License text as described in Section 4.e of
Section 4.e of the Trust Legal Provisions and are provided without the Trust Legal Provisions and are provided without warranty as
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.2. Tree diagram..............................................4 1.2. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Prefixes in Data Node Names...............................4 1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 4
2. TE & Service Related Parameters................................5 2. TE and Service Related Parameters . . . . . . . . . . . . . . 5
2.1. VN/Tunnel Selection Requirements..........................5 2.1. VN/Tunnel Selection Requirements . . . . . . . . . . . . 5
2.2. Availability Requirement..................................7 2.2. Availability Requirement . . . . . . . . . . . . . . . . 6
3. YANG Modeling Approach.........................................7 3. YANG Modeling Approach . . . . . . . . . . . . . . . . . . . 7
3.1. Forward Compatibility.....................................8 3.1. Forward Compatibility . . . . . . . . . . . . . . . . . . 8
4. L3VPN Architecture in the ACTN Context.........................8 4. L3VPN Architecture in the ACTN Context . . . . . . . . . . . 8
4.1. Service Mapping..........................................11 4.1. Service Mapping . . . . . . . . . . . . . . . . . . . . . 11
4.2. Site Mapping.............................................12 4.2. Site Mapping . . . . . . . . . . . . . . . . . . . . . . 11
5. Applicability of TE-Service Mapping in Generic context........12 5. Applicability of TE-Service Mapping in Generic context . . . 12
6. YANG Data Trees...............................................13 6. YANG Data Trees . . . . . . . . . . . . . . . . . . . . . . . 12
7. YANG Data Models..............................................14 6.1. L3SM . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security......................................................24 6.2. L2SM . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations...........................................24 6.3. L1CSM . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements.............................................26 7. YANG Data Models . . . . . . . . . . . . . . . . . . . . . . 15
11. References...................................................26 7.1. ietf-te-service-mapping-types . . . . . . . . . . . . . . 15
11.1. Informative References..................................26 7.2. ietf-l3sm-te-service-mapping . . . . . . . . . . . . . . 21
12. Contributors.................................................27 7.3. ietf-l2sm-te-service-mapping . . . . . . . . . . . . . . 23
Authors' Addresses...............................................27 7.4. ietf-l1csm-te-service-mapping . . . . . . . . . . . . . . 25
8. Security Considerations . . . . . . . . . . . . . . . . . . . 27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
11.1. Normative References . . . . . . . . . . . . . . . . . . 29
11.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
Data models are a representation of objects that can be configured Data models are a representation of objects that can be configured or
or monitored within a system. Within the IETF, YANG [RFC6020] 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 modeling 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].
Framework for Abstraction and Control of Traffic Engineered Networks Framework for Abstraction and Control of Traffic Engineered Networks
(ACTN) [RFC8453] introduces an architecture to support virtual (ACTN) [RFC8453] introduces an architecture to support virtual
network services and connectivity services. [ACTN-VN-YANG] defines a network services and connectivity services.
YANG model and describes how customers or end-to-end orchestrators [I-D.ietf-teas-actn-vn-yang] defines a YANG model and describes how
can request and/or instantiate a generic virtual network service. customers or end-to-end orchestrator can request and/or instantiate a
[ACTN-Applicability] describes the way IETF YANG models of different generic virtual network service. [I-D.ietf-teas-actn-yang] describes
classifications can be applied to the ACTN interfaces. In the way IETF YANG models of different classifications can be applied
particular, it describes how customer service models can be mapped to the ACTN interfaces. In particular, it describes how customer
into the CNC-MDSC Interface (CMI) of the ACTN architecture. service models can be mapped into the CNC-MDSC Interface (CMI) of the
ACTN architecture.
The models presented in this document are also applicable in generic The models presented in this document are also applicable in generic
context [RFC8309] as part of Customer Service Model used between context [RFC8309] as part of Customer Service Model used between
Service Orchestrator and Customer. Service Orchestrator and Customer.
[RFC8299] provides a L3VPN service delivery YANG model for PE-based [RFC8299] provides a L3VPN service delivery YANG model for PE-based
VPNs. The scope of that draft is limited to a set of domains under VPNs. The scope of that draft is limited to a set of domains under
control of the same network operator to deliver services requiring control of the same network operator to deliver services requiring TE
TE tunnels. tunnels.
[L2SM] provides a L2VPN service delivery YANG model for PE-based [RFC8466] provides a L2VPN service delivery YANG model for PE-based
VPNs. The scope of that draft is limited to a set of domains under VPNs. The scope of that draft is limited to a set of domains under
control of the same network operator to deliver services requiring control of the same network operator to deliver services requiring TE
TE tunnels. tunnels.
[L1CSM] provides a L1 connectivity service delivery YANG model for [I-D.ietf-ccamp-l1csm-yang] provides a L1 connectivity service
PE-based VPNs. The scope of that draft is limited to a set of delivery YANG model for PE-based VPNs. The scope of that draft is
domains under control of the same network operator to deliver limited to a set of domains under control of the same network
services requiring TE tunnels. operator to deliver services requiring TE tunnels.
While the IP/MPLS Provisioning Network Controller (PNC) is While the IP/MPLS Provisioning Network Controller (PNC) is
responsible for provisioning the VPN service on the Provider Edge responsible for provisioning the VPN service on the Provider Edge
(PE) nodes, the Multi-Domain Service Coordinator (MDSC) can (PE) nodes, the Multi-Domain Service Coordinator (MDSC) can
coordinate how to map the VPN services onto Traffic Engineering (TE) coordinate how to map the VPN services onto Traffic Engineering (TE)
tunnels. This is consistent with the two of the core functions of tunnels. This is consistent with the two of the core functions of
the MDSC specified in [RFC8453]: the MDSC specified in [RFC8453]:
. Customer mapping/translation function: This function is to map o Customer mapping/translation function: This function is to map
customer requests/commands into network provisioning requests customer requests/commands into network provisioning requests that
that can be sent to the PNC according to the business policies can be sent to the PNC according to the business policies that
that have been provisioned statically or dynamically. have been provisioned statically or dynamically. Specifically, it
Specifically, it provides mapping and translation of a provides mapping and translation of a customer's service request
customer's service request into a set of parameters that are into a set of parameters that are specific to a network type and
specific to a network type and technology such that the network technology such that the network configuration process is made
configuration process is made possible. possible.
. Virtual service coordination function: This function translates o Virtual service coordination function: This function translates
customer service-related information into virtual network customer service-related information into virtual network service
service operations in order to seamlessly operate virtual operations in order to seamlessly operate virtual networks while
networks while meeting a customer's service requirements. In meeting a customer's service requirements. In the context of
the context of ACTN, service/virtual service coordination ACTN, service/virtual service coordination includes a number of
includes a number of service orchestration functions such as service orchestration functions such as multi-destination load
multi-destination load balancing, guarantees of service balancing, guarantees of service quality, bandwidth and
quality, bandwidth and throughput. It also includes throughput. It also includes notifications for service fault and
notifications for service fault and performance degradation and performance degradation and so forth.
so forth.
Section 2 describes a set of TE & 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
modeling approach. modelling approach.
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.
1.2. Tree diagram The terminology for describing YANG data models is found in
[RFC7950].
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 Section 5 of this this document. The meaning of the symbols in these
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-types| ietf-te-service-mapping-types| [RFCXXXX} | | tsm- | ietf-te-service-mapping- | [RFCXXXX] |
|l1 | ietf-l1csm | [L1CSM] | | types | types | |
|l2vpn-svc| ietf-l2vpn-svc | [L2SM] | | l1csm | ietf-l1csm | [I-D.ietf-ccamp-l1csm-yang |
|l3vpn-svc| ietf-l3vpn-svc | [RFC8299] | | | | ] |
|l1-tsm | ietf-l1csm-te-service-mapping| [RFCXXXX] | | l2vpn- | ietf-l2vpn-svc | [RFC8466] |
|l2-tsm | ietf-l2sm-te-service-mapping | [RFCXXXX] | | svc | | |
|l3-tsm | ietf-l3sm-te-service-mapping | [RFCXXXX] | | l3vpn- | ietf-l3vpn-svc | [RFC8299] |
|vn | ietf-vn | [ACTN-VN] | | svc | | |
|nw | ietf-network | [RFC8345] | | l1-tsm | ietf-l1csm-te-service- | [RFCXXXX] |
|te-types | ietf-te-types | [TE-Types] | | | mapping | |
|te-topo | ietf-te-topology | [TE-Topo] | | l2-tsm | ietf-l2sm-te-service- | [RFCXXXX] |
|te | ietf-te | [TE-Tunnel] | | | mapping | |
+---------+------------------------------+-----------------+ | l3-tsm | ietf-l3sm-te-service- | [RFCXXXX] |
| | mapping | |
| vn | ietf-vn | [I-D.ietf-teas-actn-vn-yan |
| | | g] |
| nw | ietf-network | [RFC8345] |
| te- | ietf-te-types | [I-D.ietf-teas-yang-te-typ |
| types | | es] |
| te | ietf-te | [I-D.ietf-teas-yang-te] |
+---------+----------------------------+----------------------------+
Table 1: Prefixes and corresponding YANG modules Table 1: Prefixes and corresponding YANG modules
Note: The RFC Editor will 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 & Service Related Parameters 2. TE and Service Related Parameters
While L1/2/3 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
are a number of TE & Service related parameters that are not are a number of TE Service related parameters that are not included
included in the generic service models. in these service models.
Additional service parameters and policies that are not included in Additional 'service parameters and policies' that are not included in
the aforementioned service models are addressed in the YANG models the aforementioned service models are addressed in the YANG models
defined in this document. defined in this document.
2.1. VN/Tunnel Selection Requirements 2.1. VN/Tunnel Selection Requirements
In some cases, the service requirements may need addition TE tunnels In some cases, the service requirements may need addition TE tunnels
to be established. This may occur when there are no suitable to be established. This may occur when there are no suitable
existing TE tunnels that can support the service requirements, or existing TE tunnels that can support the service requirements, or
when the operator would like to dynamically create and bind tunnels when the operator would like to dynamically create and bind tunnels
to the VPN such that they are not shared by other VPNs, for example, to the VPN such that they are not shared by other VPNs, for example,
for network slicing. The establishment of TE tunnels is subject to for network slicing. The establishment of TE tunnels is subject to
the network operator's policies. the network operator's policies.
To summarize, there are three modes of VN/Tunnel selection To summarize, there are three modes of VN/Tunnel selection operations
operations to be supported as follows. Additional modes may be to be supported as follows. Additional modes may be defined in the
defined in the future. future.
o New VN/Tunnel Binding - A customer could request a VPN
service based on VN/Tunnels that are not shared with other
existing or future services. This might be to meet VPN
isolation requirements. Further, the YANG model described in
Section 5 of this document can be used to describe the
mapping between the VPN service and the ACTN VN. The VN (and
TE tunnels) could be bound to the VPN and not used for any
other VPN.
Under this mode, the following sub-categories can be o New VN/Tunnel Binding - A customer could request a VPN service
supported: based on VN/Tunnels that are not shared with other existing or
future services. This might be to meet VPN isolation
requirements. Further, the YANG model described in Section 5 of
this document can be used to describe the mapping between the VPN
service and the ACTN VN. The VN (and TE tunnels) could be bound
to the VPN and not used for any other VPN. Under this mode, the
following sub-categories can be supported:
1. Hard Isolation with deterministic characteristics: A 1. Hard Isolation with deterministic characteristics: A customer
customer could request a VPN service using a set of TE could request a VPN service using a set of TE Tunnels with
Tunnels with deterministic characteristics requirements deterministic characteristics requirements (e.g., no latency
(e.g., no latency variation) and where that set of TE variation) and where that set of TE Tunnels must not be shared
Tunnels must not be shared with other VPN services and with other VPN services and must not compete for bandwidth or
must not compete for bandwidth or other network resources other network resources with other TE Tunnels.
with other TE Tunnels.
2. Hard Isolation: This is similar to the above case but 2. Hard Isolation: This is similar to the above case but without
without the deterministic characteristics requirements. the deterministic characteristics requirements.
3. Soft Isolation: The customer requests a VPN service using 3. Soft Isolation: The customer requests a VPN service using a
a set of TE tunnels which can be shared with other VPN set of TE tunnels which can be shared with other VPN services.
services.
o VN/Tunnel Sharing - A customer could request a VPN service o VN/Tunnel Sharing - A customer could request a VPN service where
where new tunnels (or a VN) do not need to be created for new tunnels (or a VN) do not need to be created for each VPN and
each VPN and can be shared across multiple VPNs. Further, the can be shared across multiple VPNs. Further, the mapping YANG
mapping YANG model described in Section 5 of this document model described in Section 5 of this document can be used to
can be used to describe the mapping between the VPN service describe the mapping between the VPN service and the tunnels in
and the tunnels in use. No modification of the properties of use. No modification of the properties of a tunnel (or VN) is
a tunnel (or VN) is allowed in this mode: an existing tunnel allowed in this mode: an existing tunnel can only be selected.
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).
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
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
the scope of this draft. the scope of this document.
3. YANG Modeling Approach 3. YANG Modeling Approach
This section provides how the TE & Service mapping parameters are This section provides how the TE and Service mapping parameters are
supported using augmentation of the existing service models (i.e., supported using augmentation of the existing service models (i.e.,
[L1CSM], [L2SM], and [L3SM]). Figure 1 shows the scope of the [I-D.ietf-ccamp-l1csm-yang], [RFC8466], and [RFC8299]). Figure 1
Augmented LxSM Model. shows the scope of the Augmented LxSM Model.
+--------------+ +----------------------------+ +----------+ +--------------+ +----------------------+ +----------+
| LxSM |o-------| | . . . . . | ACTN VN | | LxSM |o-------| | . . . . | ACTN VN |
+--------------+ augment| | +----------+ +--------------+ augment| | +----------+
| | +----------+ | | +----------+
+--------------+ | Augmented LxSM Model | . . . . . | TE-topo | +--------------+ | Augmented LxSM Model | . . . . | TE-topo |
| TE & Service |------->| | +----------+ | TE & Service |------->| | +----------+
| Mapping Types| import | | +----------+ | Mapping Types| import | | +----------+
+--------------+ | | . . . . . | TE-tunnel| +--------------+ | | . . . . | TE-tunnel|
+----------------------------+ reference +----------+ +----------------------+ +----------+
reference
Figure 1. Augmented LxSM Model Figure 1: Augmented LxSM Model
The Augmented LxSM model (where x=1,2,3) augments the basic LxSM The Augmented LxSM model (where x=1,2,3) augments the basic LxSM
model while importing the common TE & Service related parameters model while importing the common TE and Service related parameters
(defined in Section 2) grouping information from TE & Service (defined in Section 2) grouping information from TE and Service
Mapping Types. The TE & 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 grouping file. would import this mapping-type common model.
The role of the augmented LxSm service model is to expose the The role of the augmented LxSm service model is to expose the mapping
mapping relationship between service models and TE models so that relationship between service models and TE models so that VN/VPN
VN/VPN service instantiations provided by the underlying TE networks service instantiations provided by the underlying TE networks can be
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 behavior of the network. It also allows for the diagnosing the behaviour 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
constraints via TE-topology model [TE-topo], and this relationship constraints via TE-topology model [I-D.ietf-teas-yang-te-topo], and
is recorded by the Augmented LxSM Model. The model also supports a this relationship is recorded by the Augmented LxSM Model. The model
mapping between a service model and TE-topology or a TE-tunnel. also supports a mapping between a service model and TE-topology or a
TE-tunnel.
3.1. Forward Compatibility The YANG models defined in this document conforms to the Network
Management Datastore Architecture (NMDA) [RFC8342].
3.1. Forward Compatibility
The YANG module defined in this document supports three existing The YANG module defined in this document supports three existing
service models via augmenting while sharing the common TE & Service service models via augmenting while sharing the common TE and Service
Mapping Types. Mapping Types.
It is possible that new service models will be defined at some It is possible that new service models will be defined at some future
future time and that it will be desirable to map them to underlying time and that it will be desirable to map them to underlying TE
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.
4. L3VPN Architecture in the ACTN Context 4. L3VPN Architecture in the ACTN Context
Figure 2 shows the architectural context of this document Figure 2 shows the architectural context of this document referencing
referencing the ACTN components and interfaces. the ACTN components and interfaces.
+----------------------------+ +----------------------------+
| Customer Service Manager | | Customer Service Manager |
| +-----------------------+ | | +-----------------------+ |
| | CNC + | | | CNC + |
| +-+-------------------+-+ | | +-+-------------------+-+ |
+----|-------------------|---+ +----|-------------------|---+
| | | |
|CMI(Augmented L3SM)|CMI(VN) |CMI(Augmented L3SM)|CMI(VN)
| | | |
skipping to change at page 9, line 45 skipping to change at page 9, line 33
V V
+---------------------+ +---------------------+
/ Optical Network \ / Optical Network \
+-------------------------+ +-------------------------+
Figure 2: L3VPN Architecture from the IP+Optical Network Perspective Figure 2: L3VPN Architecture from the IP+Optical Network Perspective
There are three main entities in the ACTN architecture and shown in There are three main entities in the ACTN architecture and shown in
Figure 2. Figure 2.
. CNC: The Customer Network Controller is responsible for generating o CNC: The Customer Network Controller is responsible for generating
service requests. In the context of an L3VPN, the CNC uses the service requests. In the context of an L3VPN, the CNC uses the
Augmented L3SM to express the service request and communicate it Augmented L3SM to express the service request and communicate it
to the network operator. to the network operator.
. MDSC: This entity is responsible for coordinating a L3VPN service o MDSC: This entity is responsible for coordinating a L3VPN service
request (expressed via the Augmented L3SM) with the IP/MPLS PNC request (expressed via the Augmented L3SM) with the IP/MPLS PNC
and the Transport PNC. For TE services, one of the key and the Transport PNC. For TE services, one of the key
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.
. PNC: The Provisioning Network Controller is responsible for
configuring and operating the network devices. Figure 2 shows two o PNC: The Provisioning Network Controller is responsible for
distinct PNCs. configuring and operating the network devices. Figure 2 shows two
o IP/MPLS PNC (PNC1): This entity is responsible for device distinct PNCs.
configuration to create PE-PE L3VPN tunnels for the VPN
customer and for the configuration of the L3VPN VRF on the PE * IP/MPLS PNC (PNC1): This entity is responsible for device
nodes. Each network element would select a tunnel based on configuration to create PE-PE L3VPN tunnels for the VPN
the configuration. customer and for the configuration of the L3VPN VRF on the PE
o Transport PNC (PNC2): This entity is responsible for device nodes. Each network element would select a tunnel based on the
configuration for TE tunnels in the transport networks. configuration.
* Transport PNC (PNC2): This entity is responsible for device
configuration for TE tunnels in the transport networks.
There are four main interfaces shown in Figure 2. There are four main interfaces shown in Figure 2.
. 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).
. MPI: The MDSC-PNC Interface is used by the MDSC to orchestrate
networks under the control of PNCs. The requests on this interface
may use TE tunnel models, TE topology models, VPN network
configuration models or layer one connectivity models.
. SBI: The Southbound Interface is used by the PNC to control
network devices and is out of scope for this document.
. The TE Service Mapping Model as described in this document can be
used to see the mapping between service models and VN models and
TE Tunnel/Topology models. That mapping may occur in the CNC if a
service request is mapped to a VN request. Or it may occur in the
MDSC where a service request is mapped to a TE tunnel, TE
topology, or VPN network configuration model. The TE Service
Mapping Model may be read from the CNC or MDSC to understand how
the mapping has been made and to see the purpose for which network
resources are used.
As shown in Figure 2, the MDSC may be used recursively. For example, o MPI: The MDSC-PNC Interface is used by the MDSC to orchestrate
networks under the control of PNCs. The requests on this
interface may use TE tunnel models, TE topology models, VPN
network configuration models or layer one connectivity models.
o SBI: The Southbound Interface is used by the PNC to control
network devices and is out of scope for this document.
The TE Service Mapping Model as described in this document can be
used to see the mapping between service models and VN models and TE
Tunnel/Topology models. That mapping may occur in the CNC if a
service request is mapped to a VN request. Or it may occur in the
MDSC where a service request is mapped to a TE tunnel, TE topology,
or VPN network configuration model. The TE Service Mapping Model may
be read from the CNC or MDSC to understand how the mapping has been
made and to see the purpose for which network resources are used.
As shown in Figure 2, 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
if that is the case, ACTN VN YANG [ACTN-VN-YANG] is used to if that is the case, ACTN VN YANG [I-D.ietf-teas-actn-vn-yang] is
configure a new VN based on this VPN and map the VPN service to used to configure a new VN based on this VPN and map the VPN
the ACTN VN. In case an existing tunnel is to be used, each device service to the ACTN VN. In case an existing tunnel is to be
will select which tunnel to use and populate this mapping used, each device will select which tunnel to use and populate
information. this mapping information.
3. The MDSC interacts with both the IP/MPLS PNC and the Transport PNC 3. The MDSC interacts with both the IP/MPLS PNC and the Transport
to create a PE-PE tunnel in the IP network mapped to a TE tunnel PNC to create a PE-PE tunnel in the IP network mapped to a TE
in the transport network by providing the inter-layer access tunnel in the transport network by providing the inter-layer
points and tunnel requirements. The specific service information access points and tunnel requirements. The specific service
is passed to the IP/MPLS PNC for the actual VPN configuration and information is passed to the IP/MPLS PNC for the actual VPN
activation. configuration and activation.
a. The Transport PNC creates the corresponding TE tunnel A. The Transport PNC creates the corresponding TE tunnel
matching with the access point and egress point. matching with the access point and egress point.
b. The IP/MPLS PNC maps the VPN ID with the corresponding TE B. The IP/MPLS PNC maps the VPN ID with the corresponding TE
tunnel ID to bind these two IDs. tunnel ID to bind these two IDs.
4. The IP/MPLS PNC creates/updates a VRF instance for this VPN 4. The IP/MPLS PNC creates/updates a VRF instance for this VPN
customer. This is not in the scope of this document. customer. This is not in the scope of this document.
4.1. Service Mapping 4.1. Service Mapping
Augmented L3SM and L2SM can be used to request VPN service creation Augmented L3SM and L2SM can be used to request VPN service creation
including the creation of sites and corresponding site network including the creation of sites and corresponding site network access
access connection between CE and PE. A VPN-ID is used to identify connection between CE and PE. A VPN-ID is used to identify each VPN
each VPN service ordered by the customer. The ACTN VN can be used service ordered by the customer. The ACTN VN can be used further to
further to establish PE-to-PE connectivity between VPN sites establish PE-to-PE connectivity between VPN sites belonging to the
belonging to the same VPN service. A VN-ID is used to identify each same VPN service. A VN-ID is used to identify each virtual network
virtual network established between VPN sites. established between VPN sites.
Once the ACTN VN has been established over the TE network (maybe a Once the ACTN VN has been established over the TE network (maybe a
new VN, maybe modification of an existing VN, or maybe the use of an new VN, maybe modification of an existing VN, or maybe the use of an
unmodified existing VN), the mapping between the VPN service and the unmodified existing VN), the mapping between the VPN service and the
ACTN VN service can be created. ACTN VN service can be created.
4.2. Site Mapping 4.2. Site Mapping
The elements in Augmented L3SM and L2SM define site location The elements in Augmented L3SM and L2SM define site location
parameters and constraints such as distance and access diversity parameters and constraints such as distance and access diversity that
that can influence the placement of network attachment points (i.e, can influence the placement of network attachment points (i.e,
virtual network access points (VNAP)). To achieve this, a central virtual network access points (VNAP)). To achieve this, a central
directory can be set up to establish the mapping between location directory can be set up to establish the mapping between location
parameters and constraints and network attachment point location. parameters and constraints and network attachment point location.
Suppose multiple attachment points are matched, the management Suppose multiple attachment points are matched, the management system
system can use constraints or other local policy to select the best can use constraints or other local policy to select the best
candidate network attachment points. candidate network attachment points.
After a network attachment point is selected, the mapping between After a network attachment point is selected, the mapping between VPN
VPN site and VNAP can be established as shown in Table 1. site and VNAP can be established as shown in Table 1.
+------+---------+------------------+----------------------+-------+ +-------+---------+------------------+------------------------+-----+
| | | Location | Access Diversity | PE | | Site | Site | Location | Access Diversity | PE |
| | Site | | | | | | Network | (Address, Postal | (Constraint-Type, | |
|Site | Network | (Address, Postal | (Constraint-Type, | | | | Access | Code, State, | Group-id,Target Group- | |
| | Access | Code, State, | Group-id,Target | | | | | City,Country | id) | |
| | | City,Country | Group-id) | | | | | Code) | | |
| | | Code) | | | +-------+---------+------------------+------------------------+-----+
+------+---------+------------------+----------------------+-------+ | SITE1 | ACCESS1 | (,,US,NewYork,) | (10,PE-Diverse,10) | PE1 |
| | | | | | +-------+---------+------------------+------------------------+-----+
|SITE1 | ACCESS1 | (,,US,NewYork,) |(10,PE-Diverse,10) | PE1 | | SITE2 | ACCESS2 | (,,CN,Beijing,) | (10,PE-Diverse,10) | PE2 |
+------+---------+------------------+----------------------+-------+ +-------+---------+------------------+------------------------+-----+
|SITE2 | ACCESS2 | (,,CN,Beijing,) |(10,PE-Diverse,10) | PE2 | | SITE3 | ACCESS3 | (,,UK,London, ) | (12,same-PE,12) | PE4 |
+------+---------+------------------+----------------------+-------+ +-------+---------+------------------+------------------------+-----+
|SITE3 | ACCESS3 | (,,UK,London, ) |(12,same-PE,12) | PE4 | | SITE4 | ACCESS4 | (,,FR,Paris,) | (20,Bearer-Diverse,20) | PE7 |
+------+---------+------------------+----------------------+-------+ +-------+---------+------------------+------------------------+-----+
|SITE4 | ACCESS4 | (,,FR,Paris,) |(20,Bearer-Diverse,20)| PE7 |
+------+---------+------------------+----------------------+-------+
Table 1 : Mapping Between VPN Site and VNAP Table 2: : Mapping Between VPN Site and VNAP
5. Applicability of TE-Service Mapping in Generic context 5. Applicability of TE-Service Mapping in Generic context
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 models defined in this document can be regarded primarily as Customer
Customer Service Model and secondarily as Service Deliver Model. Service Model and secondarily as Service Deliver Model.
6. YANG Data Trees
module: ietf-l1csm-te-service-mapping 6. YANG Data Trees
augment /l1:l1-connectivity/l1:services/l1:service:
+-rw te-service-mapping!
augment /l1:l1-connectivity/l1:services/l1:service:
+-rw te-mapping
+-rw map-type? identityref
+-rw availability-type? identityref
+-rw (te)?
+-:(actn-vn)
| +-rw actn-vn-ref? -> /vn:vn/vn-list/vn-id
+-:(te-topo)
| +-rw vn-topology-id? te-types:te-topology-id
| +-rw abstract-node? -> /nw:networks/network/node/node-id
+-:(te-tunnel)
+-rw te-tunnel-list* te:tunnel-ref
augment /l1:l1-connectivity/l1:services/l1:service/l1:endpoint-1:
+-rw (te)?
+-:(actn-vn)
| +-rw actn-vn-ref? -> /vn:ap/access-point-list/access-point-id
+-:(te)
+-rw ltp? te-types:te-tp-id
augment /l1:l1-connectivity/l1:services/l1:service/l1:endpoint-2:
+-rw (te)?
+-:(actn-vn)
| +-rw actn-vn-ref? -> /vn:ap/access-point-list/access-point-id
+-:(te)
+-rw ltp? te-types:te-tp-id
module: ietf-l2sm-te-service-mapping 6.1. L3SM
augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services/l2vpn-svc:vpn-service: module: ietf-l3sm-te-service-mapping
+-rw te-service-mapping! augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services
augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services/l2vpn-svc:vpn-service: /l3vpn-svc:vpn-service:
+-rw te-mapping +--rw te-service-mapping!
+-rw map-type? identityref +--rw te-mapping
+-rw availability-type? identityref +--rw map-type? identityref
+-rw (te)? +--rw availability-type? identityref
+-:(actn-vn) +--rw (te)?
| +-rw actn-vn-ref? -> /vn:vn/vn-list/vn-id +--:(vn)
+-:(te-topo) | +--rw vn-ref? -> /vn:vn/vn-list/vn-id
| +-rw vn-topology-id? te-types:te-topology-id +--:(te-topo)
| +-rw abstract-node? -> /nw:networks/network/node/node-id | +--rw vn-topology-id? te-types:te-topology-id
+-:(te-tunnel) | +--rw abstract-node?
+-rw te-tunnel-list* te:tunnel-ref | -> /nw:networks/network/node/node-id
augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site/l2vpn-svc:site-network- +--:(te-tunnel)
accesses/l2vpn-svc:site-network-access: +--rw te-tunnel-list* te:tunnel-ref
augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site
/l3vpn-svc:site-network-accesses
/l3vpn-svc:site-network-access:
+--rw (te)?
+--:(vn)
| +--rw vn-ref?
| -> /vn:ap/access-point-list/access-point-id
+--:(te)
+--rw ltp? te-types:te-tp-id
+-rw (te)? 6.2. L2SM
+-:(actn-vn) module: ietf-l2sm-te-service-mapping
| +-rw actn-vn-ref? -> /vn:ap/access-point-list/access-point-id augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services
+-:(te) /l2vpn-svc:vpn-service:
+-rw ltp? te-types:te-tp-id +--rw te-service-mapping!
+--rw te-mapping
+--rw map-type? identityref
+--rw availability-type? identityref
+--rw (te)?
+--:(vn)
| +--rw vn-ref? -> /vn:vn/vn-list/vn-id
+--:(te-topo)
| +--rw vn-topology-id? te-types:te-topology-id
| +--rw abstract-node?
| -> /nw:networks/network/node/node-id
+--:(te-tunnel)
+--rw te-tunnel-list* te:tunnel-ref
augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site
/l2vpn-svc:site-network-accesses
/l2vpn-svc:site-network-access:
+--rw (te)?
+--:(vn)
| +--rw vn-ref?
| -> /vn:ap/access-point-list/access-point-id
+--:(te)
+--rw ltp? te-types:te-tp-id
module: ietf-l3sm-te-service-mapping 6.3. L1CSM
augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services/l3vpn-svc:vpn-service: module: ietf-l1csm-te-service-mapping
+-rw te-service-mapping! augment /l1csm:l1-connectivity/l1csm:services/l1csm:service:
augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services/l3vpn-svc:vpn-service: +--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)?
+-:(actn-vn) +--:(vn)
| +-rw actn-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? -> /nw:networks/network/node/node-id | +--rw abstract-node?
+-:(te-tunnel) | -> /nw:networks/network/node/node-id
+-rw te-tunnel-list* te:tunnel-ref +--:(te-tunnel)
augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site/l3vpn-svc:site- +--rw te-tunnel-list* te:tunnel-ref
network-accesses/l3vpn-svc:site-network-access: augment /l1csm:l1-connectivity/l1csm:access/l1csm:unis/l1csm:uni:
+-rw (te)? +--rw (te)?
+-:(actn-vn) +--:(vn)
| +-rw actn-vn-ref? -> /vn:ap/access-point-list/access-point-id | +--rw vn-ref?
+-:(te) | -> /vn:ap/access-point-list/access-point-id
+-rw ltp? te-types:te-tp-id +--:(te)
+--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:
<CODE BEGINS> file "ietf-te-service-mapping-types@2019-03-05.yang" 7.1. ietf-te-service-mapping-types
module ietf-te-service-mapping-types { <CODE BEGINS> file "ietf-te-service-mapping-types@2019-09-09.yang"
namespace "urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types"; module ietf-te-service-mapping-types {
prefix "tsm"; yang-version 1.1;
import ietf-te-types { namespace "urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types";
prefix "te-types";
}
import ietf-network { prefix tsm;
prefix "nw";
}
import ietf-te {
prefix "te";
}
import ietf-vn { import ietf-te-types {
prefix "vn"; prefix te-types;
} reference
"I-D.ietf-teas-yang-te-types: Traffic Engineering Common YANG
Types";
}
organization import ietf-network {
"IETF Traffic Engineering Architecture and Signaling (TEAS) prefix nw;
Working Group"; reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
contact import ietf-te {
"Editor: Young Lee <leeyoung@huawei.com> prefix te;
Dhruv Dhody <dhruv.ietf@gmail.com> reference
Qin Wu <bill.wu@huawei.com>"; "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic
description Engineering Tunnels and Interfaces";
"This module contains a YANG module for TE & Service mapping }
parameters and policies as a common grouping applicable to
variuous service models (e.g., L1CSM, L2SM, L3SM, etc.)";
revision 2019-03-05 { import ietf-vn {
description prefix vn;
"initial version."; reference
reference "I-D.ietf-teas-actn-vn-yang: A Yang Data Model for VN Operation";
"TBD"; }
}
/* organization
* Identity for map-type "IETF Traffic Engineering Architecture and Signaling (TEAS)
*/ Working Group";
identity map-type {
description
"Base identity from which specific map types are
derived.";
}
identity new { contact
base map-type; "WG Web: <http://tools.ietf.org/wg/teas/>
description WG List: <mailto:teas@ietf.org>
"The new VN/tunnels are binded to the service.";
}
identity detnet-hard-isolation { Editor: Young Lee
base new; <mailto:younglee.tx@gmail.com>
description Editor: Dhruv Dhody
"Hard isolation with deterministic characteristics."; <mailto:dhruv.ietf@gmail.com>
Editor: Qin Wu
<mailto:bill.wu@huawei.com>";
} description
"This module contains a YANG module for TE & Service mapping
parameters and policies as a common grouping applicable to
variuous service models (e.g., L1CSM, L2SM, L3SM, etc.)
identity hard-isolation { Copyright (c) 2019 IETF Trust and the persons identified as
base new; authors of the code. All rights reserved.
description
"Hard isolation.";
}
identity soft-isolation { Redistribution and use in source and binary forms, with or
base new; without modification, is permitted pursuant to, and subject
description to the license terms contained in, the Simplified BSD License
"Soft-isolation."; set forth in Section 4.c of the IETF Trust's Legal Provisions
} Relating to IETF Documents
(https://trustee.ietf.org/license-info).
identity select { This version of this YANG module is part of RFC XXXX; see the
base map-type; RFC itself for full legal notices.";
description
"The VPN service selects an existing tunnel with no
modification.";
}
identity modify { revision 2019-09-09 {
base map-type; description
description "Initial revision.";
"The VPN service selects an existing tunnel and allows reference
to modify the properties of the tunnel (e.g., b/w)"; "RFC XXXX: Traffic Engineering and Service Mapping Yang Model";
} }
/* /*
* Identity for availability-type * Identity for map-type
*/ */
identity availability-type {
description
"Base identity from which specific map types are
derived.";
}
identity level-1 { identity map-type {
base availability-type; description
description "Base identity from which specific map types are derived.";
"level 1: 99.9999%"; }
}
identity level-2 { identity new {
base availability-type; base map-type;
description description
"level 2: 99.999%"; "The new VN/tunnels are binded to the service.";
} }
identity level-3 {
base availability-type;
description
"level 3: 99.99%";
}
identity level-4 { identity hard-isolation {
base availability-type; base new;
description description
"level 4: 99.9%"; "Hard isolation.";
} }
identity level-5 { identity detnet-hard-isolation {
base availability-type; base hard-isolation;
description description
"level 5: 99%"; "Hard isolation with deterministic characteristics.";
} }
/* identity soft-isolation {
* Groupings base new;
*/ description
"Soft-isolation.";
}
grouping te-ref { identity select {
description base map-type;
"The reference to TE."; description
choice te { "The VPN service selects an existing tunnel with no
description modification.";
"The TE"; }
case actn-vn { identity modify {
leaf actn-vn-ref { base map-type;
type leafref { description
path "/vn:vn/vn:vn-list/vn:vn-id"; "The VPN service selects an existing tunnel and allows to modify
} the properties of the tunnel (e.g., b/w)";
description }
"The reference to ACTN VN";
}
}
case te-topo {
leaf vn-topology-id{
type te-types:te-topology-id;
description
"An identifier to the TE Topology Model
where the abstract nodes and links of
the Topology can be found for Type 2
VNS";
}
leaf abstract-node {
type leafref {
path "/nw:networks/nw:network/nw:node/"
+ "nw:node-id";
}
description
"a reference to the abstract node in TE
Topology";
}
}
case te-tunnel {
leaf-list te-tunnel-list {
type te:tunnel-ref;
description
"Reference to TE Tunnels";
}
} /*
* Identity for availability-type
*/
} identity availability-type {
description
"Base identity from which specific map types are derived.";
}
} identity level-1 {
base availability-type;
description
"level 1: 99.9999%";
}
grouping te-endpoint-ref { identity level-2 {
description base availability-type;
"The reference to TE endpoints."; description
choice te { "level 2: 99.999%";
description }
"The TE";
case actn-vn { identity level-3 {
leaf actn-vn-ref { base availability-type;
type leafref { description
path "/vn:ap/vn:access-point-list" "level 3: 99.99%";
+ "/vn:access-point-id"; }
}
description identity level-4 {
"The reference to ACTN VN"; base availability-type;
} description
} "level 4: 99.9%";
case te { }
leaf ltp {
type te-types:te-tp-id;
description
"Reference LTP in the TE-topology";
}
}
}
identity level-5 {
base availability-type;
description
"level 5: 99%";
}
/*
* Groupings
*/
grouping te-ref {
description
"The reference to TE.";
choice te {
description
"The TE";
case vn {
leaf vn-ref {
type leafref {
path "/vn:vn/vn:vn-list/vn:vn-id";
} }
description
"The reference to VN";
reference
"RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN)";
}
}
case te-topo {
leaf vn-topology-id{
type te-types:te-topology-id;
description
"An identifier to the TE Topology Model where the abstract
nodes and links of the Topology can be found for Type 2
VNS";
reference
"I-D.ietf-teas-yang-te-topo: YANG Data Model for Traffic
Engineering (TE) Topologies";
}
leaf abstract-node {
type leafref {
path "/nw:networks/nw:network/nw:node/nw:node-id";
}
description
"A reference to the abstract node in TE Topology";
reference
"I-D.ietf-teas-yang-te-topo: YANG Data Model for Traffic
Engineering (TE) Topologies";
}
}
case te-tunnel {
leaf-list te-tunnel-list {
type te:tunnel-ref;
description
"Reference to TE Tunnels";
reference
"I-D.ietf-teas-yang-te: A YANG Data Model for Traffic
Engineering Tunnels and Interfaces";
}
}
}
}//grouping
grouping te-mapping { grouping te-endpoint-ref {
description description
"Mapping between Services and TE"; "The reference to TE endpoints.";
container te-mapping { choice te {
description description
"Mapping between Services and TE"; "The TE";
leaf map-type { case vn {
type identityref { leaf vn-ref {
base map-type; type leafref {
} path "/vn:ap/vn:access-point-list/vn:access-point-id";
description
"Isolation Requirements, Tunnel Bind or
Tunnel Selection";
}
leaf availability-type {
type identityref {
base availability-type;
}
description
"Availability Requirement for the Service";
}
uses te-ref;
}
} }
description
"The reference to VN AP";
reference
"RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN)";
}
}
case te {
leaf ltp {
type te-types:te-tp-id;
description
"Reference LTP in the TE-topology";
reference
"I-D.ietf-teas-yang-te-topo: YANG Data Model for Traffic
Engineering (TE) Topologies";
}
}
}
}//grouping
grouping te-mapping {
description
"Mapping between Services and TE";
container te-mapping {
description
"Mapping between Services and TE";
leaf map-type {
type identityref {
base map-type;
}
description
"Isolation Requirements, Tunnel Bind or
Tunnel Selection";
}
leaf availability-type {
type identityref {
base availability-type;
}
description
"Availability Requirement for the Service";
}
uses te-ref;
}
}//grouping
}//module
<CODE ENDS>
7.2. ietf-l3sm-te-service-mapping
<CODE BEGINS> file "ietf-l3sm-te-service-mapping@2019-09-09.yang"
module ietf-l3sm-te-service-mapping {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping";
prefix l3-tsm;
import ietf-te-service-mapping-types {
prefix tsm-types;
reference
"RFC XXXX: Traffic Engineering and Service Mapping Yang Model";
} }
<CODE ENDS>
<CODE BEGINS> file "ietf-l1csm-te-service-mapping@2019-03-05.yang" import ietf-l3vpn-svc {
prefix l3vpn-svc;
reference
"RFC 8299: YANG Data Model for L3VPN Service Delivery";
}
module ietf-l1csm-te-service-mapping { organization
"IETF Traffic Engineering Architecture and Signaling (TEAS)
Working Group";
namespace "urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping"; contact
"WG Web: <http://tools.ietf.org/wg/teas/>
WG List: <mailto:teas@ietf.org>
Editor: Young Lee
<mailto:younglee.tx@gmail.com>
Editor: Dhruv Dhody
<mailto:dhruv.ietf@gmail.com>
Editor: Qin Wu
<mailto:bill.wu@huawei.com>";
description
"This module contains a YANG module for the mapping of Layer 3
Service Model (L3SM) to the TE and VN.
prefix "tm"; Copyright (c) 2019 IETF Trust and the persons identified as
authors of the code. All rights reserved.
import ietf-te-service-mapping-types { Redistribution and use in source and binary forms, with or
prefix "tsm-types"; 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).
import ietf-l1csm { This version of this YANG module is part of RFC XXXX; see the
prefix "l1"; RFC itself for full legal notices.";
}
organization revision 2019-09-09 {
"IETF Traffic Engineering Architecture and Signaling (TEAS) description
Working Group"; "Initial revision.";
reference
"RFC XXXX: Traffic Engineering and Service Mapping Yang Model";
}
contact /*
"Editor: Young Lee <leeyoung@huawei.com> * Augmentation to L3SM
Dhruv Dhody <dhruv.ietf@gmail.com> */
Qin Wu <bill.wu@huawei.com>"; augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services"
description + "/l3vpn-svc:vpn-service" {
"This module contains a YANG module for the mapping of description
Layer 1 Connectivity Service Module (L1CSM) to the TE and VN "; "L3SM augmented to include TE parameters and mapping";
container te-service-mapping {
presence
"Indicates L3 service to TE mapping";
description
"Container to augment l3sm to TE parameters and mapping";
uses tsm-types:te-mapping;
}
}//augment
revision 2019-03-05 { augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site"
description + "/l3vpn-svc:site-network-accesses"
"initial version."; + "/l3vpn-svc:site-network-access" {
reference description
"TBD"; "This augment is only valid for TE mapping of L3SM network-access
} to TE endpoints";
uses tsm-types:te-endpoint-ref;
}//augment
}//module
/* <CODE ENDS>
* Configuration data nodes
*/
augment "/l1:l1-connectivity/l1:services/l1:service" {
description
"l1csm augmented to include TE parameters and mapping";
container te-service-mapping {
presence "indicates l1 service to te mapping";
description
"Container to augment l1csm to TE parameters and mapping";
}
}
augment "/l1:l1-connectivity/l1:services/l1:service" { 7.3. ietf-l2sm-te-service-mapping
description
"This augment is only valid for TE mapping --
te mapping is added";
uses tsm-types:te-mapping;
}
augment "/l1:l1-connectivity/l1:services/l1:service/l1:endpoint-1" { <CODE BEGINS> file "ietf-l2sm-te-service-mapping@2019-09-09.yang"
description module ietf-l2sm-te-service-mapping {
"This augment is only valid for TE mapping --
endpoint-1 te-reference is added";
uses tsm-types:te-endpoint-ref;
}
augment "/l1:l1-connectivity/l1:services/l1:service/l1:endpoint-2" { yang-version 1.1;
description
"This augment is only valid for TE mapping --
endpoint-2 te-reference is added";
uses tsm-types:te-endpoint-ref;
}
}
<CODE ENDS>; namespace "urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping";
<CODE BEGINS> file "ietf-l2sm-te-service-mapping@2019-03-05.yang" prefix l2-tsm;
module ietf-l2sm-te-service-mapping { import ietf-te-service-mapping-types {
prefix tsm-types;
reference
"RFC XXXX: Traffic Engineering and Service Mapping Yang Model";
}
namespace "urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping"; import ietf-l2vpn-svc {
prefix l2vpn-svc;
reference
"RFC 8466: A YANG Data Model for Layer 2 Virtual Private Network
(L2VPN) Service Delivery";
}
prefix "tm"; organization
"IETF Traffic Engineering Architecture and Signaling (TEAS)
Working Group";
import ietf-te-service-mapping-types { contact
prefix "tsm-types"; "WG Web: <http://tools.ietf.org/wg/teas/>
} WG List: <mailto:teas@ietf.org>
import ietf-l2vpn-svc { Editor: Young Lee
prefix "l2vpn-svc"; <mailto:younglee.tx@gmail.com>
} Editor: Dhruv Dhody
<mailto:dhruv.ietf@gmail.com>
Editor: Qin Wu
<mailto:bill.wu@huawei.com>";
organization description
"IETF Traffic Engineering Architecture and Signaling (TEAS) "This module contains a YANG module for the mapping of Layer 2
Working Group"; Service Model (L2SM) to the TE and VN.
contact Copyright (c) 2019 IETF Trust and the persons identified as
"Editor: Young Lee <leeyoung@huawei.com> authors of the code. All rights reserved.
Dhruv Dhody <dhruv.ietf@gmail.com>
Qin Wu <bill.wu@huawei.com>";
description
"This module contains a YANG module for the mapping of
Layer 2 Service Model (L1CSM) to the TE and VN ";
revision 2019-03-05 { Redistribution and use in source and binary forms, with or
description without modification, is permitted pursuant to, and subject
"initial version."; to the license terms contained in, the Simplified BSD License
reference set forth in Section 4.c of the IETF Trust's Legal Provisions
"TBD"; Relating to IETF Documents
} (https://trustee.ietf.org/license-info).
/* This version of this YANG module is part of RFC XXXX; see the
* Configuration data nodes RFC itself for full legal notices.";
*/
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";
}
}
augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services/l2vpn-svc:vpn-service" { revision 2019-09-09 {
description description
"This augment is only valid for TE mapping -- "Initial revision.";
te mapping is added"; reference
uses tsm-types:te-mapping; "RFC XXXX: Traffic Engineering and Service Mapping Yang Model";
} }
augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site" /*
+"/l2vpn-svc:site-network-accesses/l2vpn-svc:site-network-access" { * Augmentation to L3SM
description */
"This augment is only valid for TE mapping -- augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services/"
network-access te-reference is added"; + "l2vpn-svc:vpn-service" {
uses tsm-types:te-endpoint-ref; 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
<CODE ENDS> augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site"
+ "/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";
<CODE BEGINS> file "ietf-l3sm-te-service-mapping@2019-03-05.yang" uses tsm-types:te-endpoint-ref;
}//augment
}//module
<CODE ENDS>
module ietf-l3sm-te-service-mapping { 7.4. ietf-l1csm-te-service-mapping
namespace "urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping"; <CODE BEGINS> file "ietf-l1csm-te-service-mapping@2019-09-09.yang"
module ietf-l1csm-te-service-mapping {
prefix "tm"; yang-version 1.1;
import ietf-te-service-mapping-types { namespace "urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping";
prefix "tsm-types";
}
import ietf-l3vpn-svc { prefix l1-tsm;
prefix "l3vpn-svc";
}
organization
"IETF Traffic Engineering Architecture and Signaling (TEAS)
Working Group";
contact import ietf-te-service-mapping-types {
"Editor: Young Lee <leeyoung@huawei.com> prefix tsm-types;
Dhruv Dhody <dhruv.ietf@gmail.com> reference
Qin Wu <bill.wu@huawei.com>"; "RFC XXXX: Traffic Engineering and Service Mapping Yang Model";
description }
"This module contains a YANG module for the mapping of
Layer 3 Service Model (L3SM) to the TE and VN ";
revision 2019-03-05 { import ietf-l1csm {
description prefix l1csm;
"initial version."; reference
reference "I-D.ietf-ccamp-l1csm-yang: A YANG Data Model for L1 Connectivity
"TBD"; Service Model (L1CSM)";
} }
/* organization
* Configuration data nodes "IETF Traffic Engineering Architecture and Signaling (TEAS)
*/ Working Group";
augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services/l3vpn-svc:vpn-service" {
description
"l3sm augmented to include TE parameters and mapping";
container te-service-mapping {
presence "indicates l3 service to te mapping";
description
"Container to augment l3sm to TE parameters and mapping";
}
}
augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services/l3vpn-svc:vpn-service" { contact
description "WG Web: <http://tools.ietf.org/wg/teas/>
"This augment is only valid for TE mapping -- WG List: <mailto:teas@ietf.org>
te mapping is added";
uses tsm-types:te-mapping;
}
augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site" Editor: Young Lee
+"/l3vpn-svc:site-network-accesses/l3vpn-svc:site-network-access" { <mailto:younglee.tx@gmail.com>
description Editor: Dhruv Dhody
"This augment is only valid for TE mapping -- <mailto:dhruv.ietf@gmail.com>
network-access te-reference is added"; Editor: Qin Wu
uses tsm-types:te-endpoint-ref; <mailto:bill.wu@huawei.com>";
}
} description
"This module contains a YANG module for the mapping of
Layer 1 Connectivity Service Module (L1CSM) to the TE and VN
Copyright (c) 2019 IETF Trust and the persons identified as
authors of the code. All rights reserved.
<CODE ENDS> Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
8. Security This version of this YANG module is part of RFC XXXX; see the
RFC itself for full legal notices.";
The configuration, state, and action data defined in this document revision 2019-09-09 {
are designed to be accessed via a management protocol with a secure description
transport layer, such as NETCONF [RFC6241]. The NETCONF access "Initial revision.";
control model [RFC6536] provides the means to restrict access for reference
particular NETCONF users to a preconfigured subset of all available "RFC XXXX: Traffic Engineering and Service Mapping Yang Model";
NETCONF protocol operations and content. }
A number of configuration data nodes defined in this document are /*
writable/deletable (i.e., "config true") These data nodes may be * Augmentation to L1CSM
considered sensitive or vulnerable in some network environments. */
augment "/l1csm:l1-connectivity/l1csm:services/l1csm:service" {
description
"L1CSM augmented to include TE parameters and mapping";
container te-service-mapping {
presence
"Indicates L1 service to TE mapping";
description
"Container to augment L1CSM to TE parameters and mapping";
uses tsm-types:te-mapping;
}
}//augment
9. IANA Considerations augment "/l1csm:l1-connectivity/l1csm:access/l1csm:unis/"
+ "l1csm:uni" {
description
"This augment is only valid for TE mapping of L1CSM UNI to TE
endpoints";
uses tsm-types:te-endpoint-ref;
}//augment
}//module
This document registers the following namespace URIs in the IETF XML <CODE ENDS>
registry [RFC3688]: 8. Security Considerations
The YANG modules defined in this document is designed to be accessed
via network management protocol such as NETCONF [RFC6241] or RESTCONF
[RFC8040]. The lowest NETCONF layer is the secure transport layer
and the mandatory-to-implement secure transport is SSH [RFC6242].
The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement
secure transport is TLS [RFC8446]
The NETCONF access control model [RFC8341] provides the means to
restrict access for particular NETCONF or RESTCONF users to a pre-
configured subset of all available NETCONF or RESTCONF protocol
operations and content.
There are a number of data nodes defined in the YANG moduleS which
are writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., <edit-config>)
to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability:
o /l3vpn-svc/vpn-services/vpn-service/te-service-mapping/te-mapping/
- configure TE Service mapping.
o /l3vpn-svc/sites/site/site-network-accesses/site-network-access/
te/ - configure TE Endpoint mapping.
o /l2vpn-svc/vpn-services/vpn-service/te-service-mapping/te-mapping/
- configure TE Service mapping.
o /l2vpn-svc/sites/site/site-network-accesses/site-network-access/
te/ - configure TE Endpoint mapping.
o /l1-connectivity/services/service/te-service-mapping/te-mapping/ -
configure TE Service mapping.
o /l1-connectivity/access/unis/uni/te/ - configure TE Endpoint
mapping.
Unauthorized access to above list can adversely affect the VPN
service.
Some of the readable data nodes in the YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or
notification) to these data nodes. The TE related parameters
attached to the VPN service can leak sensitive information about the
network. This is apploicable to all elements in the yang models
defined in this document.
This document has no RPC defined.
9. IANA Considerations
This document request the IANA to register four URIs in the "IETF XML
Registry" [RFC3688]. Following the format in RFC 3688, the following
registrations are requested -
--------------------------------------------------------------------
URI: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types 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-l1csm-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-l2sm-te-service-mapping URI: urn:ietf:params:xml:ns:yang:ietf-l2sm-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-l1csm-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.
--------------------------------------------------------------------
This document registers the following YANG modules in the YANG This document request the IANA to register four YANG modules in the
Module. "YANG Module Names" registry [RFC6020], as follows -
Name: ietf-te-service-mapping-types
Names registry [RFC7950]: Namespace: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types
Prefix: tsm
-------------------------------------------------------------------- Reference: [This.I-D]
name: ietf-te-service-mapping-types
namespace: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-
types
reference: RFC XXXX (TDB)
--------------------------------------------------------------------
-------------------------------------------------------------------- Name: ietf-l3sm-te-service-mapping
name: ietf-l1csm-te-service-mapping Namespace: urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping
namespace: urn:ietf:params:xml:ns:yang:ietf-l1cms-te-service- Prefix: l3-tsm
mapping Reference: [This.I-D]
reference: RFC XXXX (TDB)
--------------------------------------------------------------------
-------------------------------------------------------------------- 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- Prefix: l2-tsm
mapping Reference: [This.I-D]
reference: RFC XXXX (TDB)
--------------------------------------------------------------------
-------------------------------------------------------------------- Name: ietf-l1csm-te-service-mapping
name: ietf-l3sm-te-service-mapping Namespace: urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping
namespace: urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service- Prefix: l1-tsm
mapping Reference: [This.I-D]
reference: RFC XXXX (TDB)
--------------------------------------------------------------------
10. Acknowledgements 10. Acknowledgements
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. Informative References 11.1. Normative References
[RFC4110] R. Callon and M. Suzuki, "A Framework for Layer 3 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
Provider-Provisioned Virtual Private Networks (PPVPNs)", DOI 10.17487/RFC3688, January 2004,
RFC 4110, July 2005. <https://www.rfc-editor.org/info/rfc3688>.
[RFC6020] M. Bjorklund, Ed., "YANG - A Data Modeling Language for [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
the Network Configuration Protocol (NETCONF)", RFC 6020, Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
October 2010. <https://www.rfc-editor.org/info/rfc6242>.
[RFC8309] Q. Wu, W. Liu and A. Farrel, "Service Models Explained", [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G.,
RFC 8309, January 2018. Ceccarelli, D., and X. Zhang, "Problem Statement and
Architecture for Information Exchange between
Interconnected Traffic-Engineered Networks", BCP 206,
RFC 7926, DOI 10.17487/RFC7926, July 2016,
<https://www.rfc-editor.org/info/rfc7926>.
[RFC8199] D. Bogdanovic, B. Claise, and C. Moberg, "YANG Module [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
Classification", RFC 8199, July 2017. RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
and A. Bierman, Ed., "Network Configuration Protocol Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
(NETCONF)", RFC 6241. <https://www.rfc-editor.org/info/rfc8040>.
[RFC8453] D. Cecarelli and Y. Lee, "Framework for Abstraction and [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki,
Control of Traffic Engineered Networks", RFC 8453, August "YANG Data Model for L3VPN Service Delivery", RFC 8299,
2018. DOI 10.17487/RFC8299, January 2018,
<https://www.rfc-editor.org/info/rfc8299>.
[TE-Topo] X. Liu, et. al., "YANG Data Model for TE Topologies", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
draft-ietf-teas-yang-te-topo, work in progress. BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Engineering Tunnels and Interfaces", draft-ietf-teas-yang- Access Control Model", STD 91, RFC 8341,
te, work in progress. DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[TE-Types] T. Saad (Editor), "Traffic Engineering Common YANG [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Types", draft-ietf-teas-yang-te-types, work in progress. Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
2018, <https://www.rfc-editor.org/info/rfc8345>.
[ACTN-VN-YANG] Y. Lee (Editor), "A Yang Data Model for ACTN VN [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Operation", draft-lee-teas-actn-vn-yang, work in progress. Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[ACTN-Applicability] Y. Lee, et al, "Applicability of YANG models [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG
for Abstraction and Control of Traffic Engineered Data Model for Layer 2 Virtual Private Network (L2VPN)
Networks, draft-ietf-teas-actn-yang, work in progress. Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October
2018, <https://www.rfc-editor.org/info/rfc8466>.
[RFC8299] Q. Wu, S. Litkowski, L.Tomotaki, and K. Ogaki, "YANG Data [I-D.ietf-ccamp-l1csm-yang]
Model for L3VPN service delivery", RFC 8299, January 2018. 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-10 (work in
progress), September 2019.
[L2SM] B. Wen, et al, "A YANG Data Model for L2VPN Service [I-D.ietf-teas-actn-vn-yang]
Delivery", draft-ietf-l2sm-l2vpn-service-model, work in Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., and B.
progress. Yoon, "A Yang Data Model for VN Operation", draft-ietf-
teas-actn-vn-yang-06 (work in progress), July 2019.
[L1CSM] G. Fioccola, et al, "A Yang Data Model for L1 Connectivity [I-D.ietf-teas-yang-te]
Service Model (L1CSM)", draft-ietf-ccamp-l1csm-yang, work Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
in progress. "A YANG Data Model for Traffic Engineering Tunnels and
Interfaces", draft-ietf-teas-yang-te-21 (work in
progress), April 2019.
12. Contributors [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-10 (work in progress), July 2019.
11.2. Informative References
[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>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module
Classification", RFC 8199, DOI 10.17487/RFC8199, July
2017, <https://www.rfc-editor.org/info/rfc8199>.
[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
<https://www.rfc-editor.org/info/rfc8309>.
[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
Abstraction and Control of TE Networks (ACTN)", RFC 8453,
DOI 10.17487/RFC8453, August 2018,
<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-04 (work in
progress), August 2019.
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
Huawei Technologies
EMail: zhenghaomian@huawei.com
Authors' Addresses Authors' Addresses
Young Lee Young Lee (editor)
Huawei Technologies SKKU
5340 Legacy Drive
Plano, TX 75023, USA
Phone: (469)277-5838
Email: leeyoung@huawei.com Email: younglee.tx@gmail.com
Dhruv Dhody Dhruv Dhody (editor)
Huawei Technologies Huawei Technologies
Email: dhruv.ietf@gmail.com Email: dhruv.ietf@gmail.com
Giuseppe Fioccola
Huawei Technologies
Email: giuseppe.fioccola@huawei.com
Qin Wu (editor)
Huawei Technologies
Email: bill.wu@huawei.com
Daniele Ceccarelli 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@gmail.com
Giuseppe Fioccola
Huawei
Email: giuseppe.fioccola@huawei.com
Qin Wu
Huawei
Email: bill.wu@huawei.com
 End of changes. 205 change blocks. 
868 lines changed or deleted 1085 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/