--- 1/draft-ietf-teas-te-service-mapping-yang-01.txt 2019-09-09 04:14:33.728488693 -0700 +++ 2/draft-ietf-teas-te-service-mapping-yang-02.txt 2019-09-09 04:14:33.796490414 -0700 @@ -1,356 +1,361 @@ -TEAS WG Young Lee -Internet Draft Dhruv Dhody -Intended status: standard track Huawei -Expires: September 5, 2019 - Daniele Ceccarelli - Ericsson - Jeff Tantsura +TEAS Working Group Y. Lee, Ed. +Internet-Draft SKKU +Intended status: Standards Track D. Dhody, Ed. +Expires: March 12, 2020 G. Fioccola + Q. Wu, Ed. + Huawei Technologies + D. Ceccarelli + Ericsson + J. Tantsura Apstra + September 9, 2019 - Giuseppe Fioccola - Huawei - - Qin Wu - Huawei - - March 5, 2019 - - Traffic Engineering and Service Mapping Yang Model - - 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 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 TE Tunnel or the Abstraction and Control of - Traffic Engineered Networks Virtual Network model). This model is - referred to as TE Service Mapping Model and is applicable - generically to the operator's need for seamless control and - management of their VPN services with TE tunnel support. + models (e.g., the L3VPN Service Model (L3SM)) to Traffic Engineering + (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 + applicable generically to the operator's need for seamless control + and management of their VPN services with TE tunnel support. The model is principally used to allow monitoring and diagnostics of the management systems to show how the service requests are mapped 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 - the provisions of BCP 78 and BCP 79. + This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - 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 + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at https://datatracker.ietf.org/drafts/current/. - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 5, 2019. + This Internet-Draft will expire on March 12, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents - (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 - carefully, as they describe your rights and restrictions with - respect to this document. Code Components extracted from this - document must include Simplified BSD License text as described in - Section 4.e of the Trust Legal Provisions and are provided without - warranty as described in the Simplified BSD License. + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. Table of Contents - 1. Introduction...................................................3 - 1.1. Terminology...............................................4 - 1.2. Tree diagram..............................................4 - 1.3. Prefixes in Data Node Names...............................4 - 2. TE & Service Related Parameters................................5 - 2.1. VN/Tunnel Selection Requirements..........................5 - 2.2. Availability Requirement..................................7 - 3. YANG Modeling Approach.........................................7 - 3.1. Forward Compatibility.....................................8 - 4. L3VPN Architecture in the ACTN Context.........................8 - 4.1. Service Mapping..........................................11 - 4.2. Site Mapping.............................................12 - 5. Applicability of TE-Service Mapping in Generic context........12 - 6. YANG Data Trees...............................................13 - 7. YANG Data Models..............................................14 - 8. Security......................................................24 - 9. IANA Considerations...........................................24 - 10. Acknowledgements.............................................26 - 11. References...................................................26 - 11.1. Informative References..................................26 - 12. Contributors.................................................27 - Authors' Addresses...............................................27 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.2. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 4 + 2. TE and Service Related Parameters . . . . . . . . . . . . . . 5 + 2.1. VN/Tunnel Selection Requirements . . . . . . . . . . . . 5 + 2.2. Availability Requirement . . . . . . . . . . . . . . . . 6 + 3. YANG Modeling Approach . . . . . . . . . . . . . . . . . . . 7 + 3.1. Forward Compatibility . . . . . . . . . . . . . . . . . . 8 + 4. L3VPN Architecture in the ACTN Context . . . . . . . . . . . 8 + 4.1. Service Mapping . . . . . . . . . . . . . . . . . . . . . 11 + 4.2. Site Mapping . . . . . . . . . . . . . . . . . . . . . . 11 + 5. Applicability of TE-Service Mapping in Generic context . . . 12 + 6. YANG Data Trees . . . . . . . . . . . . . . . . . . . . . . . 12 + 6.1. L3SM . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 6.2. L2SM . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 6.3. L1CSM . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 7. YANG Data Models . . . . . . . . . . . . . . . . . . . . . . 15 + 7.1. ietf-te-service-mapping-types . . . . . . . . . . . . . . 15 + 7.2. ietf-l3sm-te-service-mapping . . . . . . . . . . . . . . 21 + 7.3. ietf-l2sm-te-service-mapping . . . . . . . . . . . . . . 23 + 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 - Data models are a representation of objects that can be configured - or monitored within a system. Within the IETF, YANG [RFC6020] is the + Data models are a representation of objects that can be configured or + monitored within a system. Within the IETF, YANG [RFC7950] is the language of choice for documenting data models, and YANG 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 models have been classified in [RFC8199] and [RFC8309]. Framework for Abstraction and Control of Traffic Engineered Networks (ACTN) [RFC8453] introduces an architecture to support virtual - network services and connectivity services. [ACTN-VN-YANG] defines a - YANG model and describes how customers or end-to-end orchestrators - can request and/or instantiate a generic virtual network service. - [ACTN-Applicability] describes the way IETF YANG models of different - classifications can be applied to the ACTN interfaces. In - particular, it describes how customer service models can be mapped - into the CNC-MDSC Interface (CMI) of the ACTN architecture. + network services and connectivity services. + [I-D.ietf-teas-actn-vn-yang] defines a YANG model and describes how + customers or end-to-end orchestrator can request and/or instantiate a + generic virtual network service. [I-D.ietf-teas-actn-yang] describes + the way IETF YANG models of different classifications can be applied + to the ACTN interfaces. In particular, it describes how customer + service models can be mapped into the CNC-MDSC Interface (CMI) of the + ACTN architecture. The models presented in this document are also applicable in generic context [RFC8309] as part of Customer Service Model used between Service Orchestrator and Customer. [RFC8299] provides a L3VPN service delivery YANG model for PE-based VPNs. The scope of that draft is limited to a set of domains under - control of the same network operator to deliver services requiring - TE tunnels. + control of the same network operator to deliver services requiring TE + 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 - control of the same network operator to deliver services requiring - TE tunnels. + control of the same network operator to deliver services requiring TE + tunnels. - [L1CSM] provides a L1 connectivity service delivery YANG model for - PE-based VPNs. The scope of that draft is limited to a set of - domains under control of the same network operator to deliver - services requiring TE tunnels. + [I-D.ietf-ccamp-l1csm-yang] provides a L1 connectivity service + delivery YANG model for PE-based VPNs. The scope of that draft is + limited to a set of domains under control of the same network + operator to deliver services requiring TE tunnels. While the IP/MPLS Provisioning Network Controller (PNC) is responsible for provisioning the VPN service on the Provider Edge (PE) nodes, the Multi-Domain Service Coordinator (MDSC) can coordinate how to map the VPN services onto Traffic Engineering (TE) tunnels. This is consistent with the two of the core functions of the MDSC specified in [RFC8453]: - . Customer mapping/translation function: This function is to map - customer requests/commands into network provisioning requests - that can be sent to the PNC according to the business policies - that have been provisioned statically or dynamically. - Specifically, it provides mapping and translation of a - customer's service request into a set of parameters that are - specific to a network type and technology such that the network - configuration process is made possible. + o Customer mapping/translation function: This function is to map + customer requests/commands into network provisioning requests that + can be sent to the PNC according to the business policies that + have been provisioned statically or dynamically. Specifically, it + provides mapping and translation of a customer's service request + into a set of parameters that are specific to a network type and + technology such that the network configuration process is made + possible. - . Virtual service coordination function: This function translates - customer service-related information into virtual network - service operations in order to seamlessly operate virtual - networks while meeting a customer's service requirements. In - the context of ACTN, service/virtual service coordination - includes a number of service orchestration functions such as - multi-destination load balancing, guarantees of service - quality, bandwidth and throughput. It also includes - notifications for service fault and performance degradation and - so forth. + o Virtual service coordination function: This function translates + customer service-related information into virtual network service + operations in order to seamlessly operate virtual networks while + meeting a customer's service requirements. In the context of + ACTN, service/virtual service coordination includes a number of + service orchestration functions such as multi-destination load + balancing, guarantees of service quality, bandwidth and + throughput. It also includes notifications for service fault and + performance degradation and so forth. - Section 2 describes a set of TE & service related parameters that - this document addresses as new and advanced parameters that are not + Section 2 describes a set of TE and service related parameters that + this document addresses as "new and advanced parameters" that are not included in generic service models. Section 3 discusses YANG - modeling approach. + modelling approach. 1.1. Terminology Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used in this document. + The terminology for describing YANG data models is found in + [RFC7950]. + 1.2. Tree diagram A simplified graphical representation of the data model is used in - Section 5 of this this document. The meaning of the symbols in - these diagrams is defined in [RFC8340]. + Section 5 of this this document. The meaning of the symbols in these + diagrams is defined in [RFC8340]. 1.3. Prefixes in Data Node Names In this document, names of data nodes and other data model objects are prefixed using the standard prefix associated with the corresponding YANG imported modules, as shown in Table 1. - +---------+------------------------------+-----------------+ + +---------+----------------------------+----------------------------+ | Prefix | YANG module | Reference | - +---------+------------------------------+-----------------+ - |tsm-types| ietf-te-service-mapping-types| [RFCXXXX} | - |l1 | ietf-l1csm | [L1CSM] | - |l2vpn-svc| ietf-l2vpn-svc | [L2SM] | - |l3vpn-svc| ietf-l3vpn-svc | [RFC8299] | - |l1-tsm | ietf-l1csm-te-service-mapping| [RFCXXXX] | - |l2-tsm | ietf-l2sm-te-service-mapping | [RFCXXXX] | - |l3-tsm | ietf-l3sm-te-service-mapping | [RFCXXXX] | - |vn | ietf-vn | [ACTN-VN] | + +---------+----------------------------+----------------------------+ + | tsm- | ietf-te-service-mapping- | [RFCXXXX] | + | types | types | | + | l1csm | ietf-l1csm | [I-D.ietf-ccamp-l1csm-yang | + | | | ] | + | l2vpn- | ietf-l2vpn-svc | [RFC8466] | + | svc | | | + | l3vpn- | ietf-l3vpn-svc | [RFC8299] | + | svc | | | + | l1-tsm | ietf-l1csm-te-service- | [RFCXXXX] | + | | mapping | | + | l2-tsm | ietf-l2sm-te-service- | [RFCXXXX] | + | | 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-types | ietf-te-types | [TE-Types] | - |te-topo | ietf-te-topology | [TE-Topo] | - |te | ietf-te | [TE-Tunnel] | - +---------+------------------------------+-----------------+ + | 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 - 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. -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 - are a number of TE & Service related parameters that are not - included in the generic service models. + are a number of TE Service related parameters that are not included + in these service models. - Additional service parameters and policies that are not included in + Additional 'service parameters and policies' that are not included in the aforementioned service models are addressed in the YANG models defined in this document. 2.1. VN/Tunnel Selection Requirements In some cases, the service requirements may need addition TE tunnels to be established. This may occur when there are no suitable existing TE tunnels that can support the service requirements, or when the operator would like to dynamically create and bind tunnels to the VPN such that they are not shared by other VPNs, for example, for network slicing. The establishment of TE tunnels is subject to the network operator's policies. - To summarize, there are three modes of VN/Tunnel selection - operations to be supported as follows. Additional modes may be - defined in the future. - - 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. + To summarize, there are three modes of VN/Tunnel selection operations + to be supported as follows. Additional modes may be defined in the + future. - Under this mode, the following sub-categories can be - supported: + 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 supported: - 1. Hard Isolation with deterministic characteristics: A - customer could request a VPN service using a set of TE - Tunnels with deterministic characteristics requirements - (e.g., no latency variation) and where that set of TE - Tunnels must not be shared with other VPN services and - must not compete for bandwidth or other network resources - with other TE Tunnels. + 1. Hard Isolation with deterministic characteristics: A customer + could request a VPN service using a set of TE Tunnels with + deterministic characteristics requirements (e.g., no latency + variation) and where that set of TE Tunnels must not be shared + with other VPN services and must not compete for bandwidth or + other network resources with other TE Tunnels. - 2. Hard Isolation: This is similar to the above case but - without the deterministic characteristics requirements. + 2. Hard Isolation: This is similar to the above case but without + the deterministic characteristics requirements. - 3. Soft Isolation: The customer requests a VPN service using - a set of TE tunnels which can be shared with other VPN - services. + 3. Soft Isolation: The customer requests a VPN service using a + set of TE tunnels which can be shared with other VPN services. - o VN/Tunnel Sharing - A customer could request a VPN service - where new tunnels (or a VN) do not need to be created for - each VPN and can be shared across multiple VPNs. Further, the - mapping YANG model described in Section 5 of this document - can be used to describe the mapping between the VPN service - and the tunnels in use. No modification of the properties of - a tunnel (or VN) is allowed in this mode: an existing tunnel - can only be selected. + o VN/Tunnel Sharing - A customer could request a VPN service where + new tunnels (or a VN) do not need to be created for each VPN and + can be shared across multiple VPNs. Further, the mapping YANG + model described in Section 5 of this document can be used to + describe the mapping between the VPN service and the tunnels in + use. No modification of the properties of a tunnel (or VN) is + allowed in this mode: an existing tunnel can only be selected. o VN/Tunnel Modify - This mode allows the modification of the properties of the existing VN/tunnel (e.g., bandwidth). 2.2. Availability Requirement Availability is another service requirement or intent that may influence the selection or provisioning of TE tunnels or a VN to support the requested service. Availability is a probabilistic measure of the length of time that a VPN/VN instance functions without a network failure. The availability level will need to be translated into network specific policies such as the protection/reroute policy associated with a VN or Tunnel. The means by which this is achieved is not in - the scope of this draft. + the scope of this document. 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., - [L1CSM], [L2SM], and [L3SM]). Figure 1 shows the scope of the - Augmented LxSM Model. + [I-D.ietf-ccamp-l1csm-yang], [RFC8466], and [RFC8299]). Figure 1 + shows the scope of the Augmented LxSM Model. - +--------------+ +----------------------------+ +----------+ - | LxSM |o-------| | . . . . . | ACTN VN | + +--------------+ +----------------------+ +----------+ + | LxSM |o-------| | . . . . | ACTN VN | +--------------+ augment| | +----------+ | | +----------+ - +--------------+ | Augmented LxSM Model | . . . . . | TE-topo | + +--------------+ | Augmented LxSM Model | . . . . | TE-topo | | TE & Service |------->| | +----------+ | Mapping Types| import | | +----------+ - +--------------+ | | . . . . . | TE-tunnel| - +----------------------------+ reference +----------+ + +--------------+ | | . . . . | TE-tunnel| + +----------------------+ +----------+ + reference - Figure 1. Augmented LxSM Model + Figure 1: Augmented LxSM Model The Augmented LxSM model (where x=1,2,3) augments the basic LxSM - model while importing the common TE & Service related parameters - (defined in Section 2) grouping information from TE & Service - Mapping Types. The TE & Service Mapping Types (ietf-te-service- + model while importing the common TE and Service related parameters + (defined in Section 2) grouping information from TE and Service + Mapping Types. The TE and Service Mapping Types (ietf-te-service- mapping-types) module is the repository of all common groupings imported by each augmented LxSM model. Any future service models - would import this grouping file. + would import this mapping-type common model. - The role of the augmented LxSm service model is to expose the - mapping relationship between service models and TE models so that - VN/VPN service instantiations provided by the underlying TE networks - can be viewed outside of the MDSC, for example by an operator who is - diagnosing the behavior of the network. It also allows for the + The role of the augmented LxSm service model is to expose the mapping + relationship between service models and TE models so that VN/VPN + service instantiations provided by the underlying TE networks can be + viewed outside of the MDSC, for example by an operator who is + diagnosing the behaviour of the network. It also allows for the customers to access operational state information about how their services are instantiated with the underlying VN, TE topology or TE tunnels provided that the MDSC operator is willing to share that information. This mapping will facilitate a seamless service management operation with underlay-TE network visibility. As seen in Figure 1, the augmented LxSM service model records a mapping between the customer service models and the ACTN VN YANG model. Thus, when the MDSC receives a service request it creates a VN that meets the customer's service objectives with various - constraints via TE-topology model [TE-topo], and this relationship - is recorded by the Augmented LxSM Model. The model also supports a - mapping between a service model and TE-topology or a TE-tunnel. + constraints via TE-topology model [I-D.ietf-teas-yang-te-topo], and + this relationship is recorded by the Augmented LxSM Model. The model + also supports a mapping between a service model and TE-topology or a + TE-tunnel. + + The YANG 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 - service models via augmenting while sharing the common TE & Service + service models via augmenting while sharing the common TE and Service Mapping Types. - It is possible that new service models will be defined at some - future time and that it will be desirable to map them to underlying - TE constructs in the same way as the three existing models are + It is possible that new service models will be defined at some future + time and that it will be desirable to map them to underlying TE + constructs in the same way as the three existing models are augmented. 4. L3VPN Architecture in the ACTN Context - Figure 2 shows the architectural context of this document - referencing the ACTN components and interfaces. + Figure 2 shows the architectural context of this document referencing + the ACTN components and interfaces. +----------------------------+ | Customer Service Manager | | +-----------------------+ | | | CNC + | | +-+-------------------+-+ | +----|-------------------|---+ | | |CMI(Augmented L3SM)|CMI(VN) | | @@ -391,312 +396,352 @@ V +---------------------+ / Optical Network \ +-------------------------+ Figure 2: L3VPN Architecture from the IP+Optical Network Perspective There are three main entities in the ACTN architecture and shown in 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 Augmented L3SM to express the service request and communicate it 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 and the Transport PNC. For TE services, one of the key responsibilities of the MDSC is to coordinate with both the IP PNC and the Transport PNC for the mapping of the Augmented L3VPN Service Model to the ACTN VN model. In the VN/TE-tunnel binding case, the MDSC will need to coordinate with the Transport PNC to dynamically create the TE-tunnels in the transport network as needed. These tunnels are added as links in the IP/MPLS Layer topology. The MDSC coordinates with IP/MPLS PNC to create the TE- tunnels in the IP/MPLS layer, as part of the ACTN VN creation. - . PNC: The Provisioning Network Controller is responsible for + + o PNC: The Provisioning Network Controller is responsible for configuring and operating the network devices. Figure 2 shows two distinct PNCs. - o IP/MPLS PNC (PNC1): This entity is responsible for device + + * IP/MPLS PNC (PNC1): This entity is responsible for device configuration to create PE-PE L3VPN tunnels for the VPN customer and for the configuration of the L3VPN VRF on the PE - nodes. Each network element would select a tunnel based on - the configuration. - o Transport PNC (PNC2): This entity is responsible for device + nodes. Each network element would select a tunnel based on the + configuration. + + * Transport PNC (PNC2): This entity is responsible for device configuration for TE tunnels in the transport networks. 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 expressed as Augmented VPN service requests (L2SM, L3SM), as connectivity requests (L1CSM), or as virtual network requests (ACTN VN). - . MPI: The MDSC-PNC Interface is used by the MDSC to orchestrate - networks under the control of PNCs. The requests on this interface - may use TE tunnel models, TE topology models, VPN network - configuration models or layer one connectivity models. - . SBI: The Southbound Interface is used by the PNC to control + + 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 + + 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. + 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 recursive MDSC. The high-level control flows for one example are as follows: 1. A customer asks for an L3VPN between CE1 and CE2 using the Augmented L3SM model. 2. The MDSC considers the service request and local policy to determine if it needs to create a new VN or any TE Topology, and - if that is the case, ACTN VN YANG [ACTN-VN-YANG] is used to - configure a new VN based on this VPN and map the VPN service to - the ACTN VN. In case an existing tunnel is to be used, each device - will select which tunnel to use and populate this mapping - information. + if that is the case, ACTN VN YANG [I-D.ietf-teas-actn-vn-yang] is + used to configure a new VN based on this VPN and map the VPN + service to the ACTN VN. In case an existing tunnel is to be + used, each device will select which tunnel to use and populate + this mapping information. - 3. The MDSC interacts with both the IP/MPLS PNC and the Transport PNC - to create a PE-PE tunnel in the IP network mapped to a TE tunnel - in the transport network by providing the inter-layer access - points and tunnel requirements. The specific service information - is passed to the IP/MPLS PNC for the actual VPN configuration and - activation. + 3. The MDSC interacts with both the IP/MPLS PNC and the Transport + PNC to create a PE-PE tunnel in the IP network mapped to a TE + tunnel in the transport network by providing the inter-layer + access points and tunnel requirements. The specific service + information is passed to the IP/MPLS PNC for the actual VPN + configuration and activation. - 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. - 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. 4. The IP/MPLS PNC creates/updates a VRF instance for this VPN customer. This is not in the scope of this document. 4.1. Service Mapping Augmented L3SM and L2SM can be used to request VPN service creation - including the creation of sites and corresponding site network - access connection between CE and PE. A VPN-ID is used to identify - each VPN service ordered by the customer. The ACTN VN can be used - further to establish PE-to-PE connectivity between VPN sites - belonging to the same VPN service. A VN-ID is used to identify each - virtual network established between VPN sites. + including the creation of sites and corresponding site network access + connection between CE and PE. A VPN-ID is used to identify each VPN + service ordered by the customer. The ACTN VN can be used further to + establish PE-to-PE connectivity between VPN sites belonging to the + same VPN service. A VN-ID is used to identify each virtual network + established between VPN sites. Once the ACTN VN has been established over the TE network (maybe a new VN, maybe modification of an existing VN, or maybe the use of an unmodified existing VN), the mapping between the VPN service and the ACTN VN service can be created. 4.2. Site Mapping The elements in Augmented L3SM and L2SM define site location - parameters and constraints such as distance and access diversity - that can influence the placement of network attachment points (i.e, + parameters and constraints such as distance and access diversity that + can influence the placement of network attachment points (i.e, virtual network access points (VNAP)). To achieve this, a central directory can be set up to establish the mapping between location parameters and constraints and network attachment point location. - Suppose multiple attachment points are matched, the management - system can use constraints or other local policy to select the best + Suppose multiple attachment points are matched, the management system + can use constraints or other local policy to select the best candidate network attachment points. - After a network attachment point is selected, the mapping between - VPN site and VNAP can be established as shown in Table 1. + After a network attachment point is selected, the mapping between VPN + site and VNAP can be established as shown in Table 1. - +------+---------+------------------+----------------------+-------+ - | | | Location | Access Diversity | PE | - | | Site | | | | - |Site | Network | (Address, Postal | (Constraint-Type, | | - | | Access | Code, State, | Group-id,Target | | - | | | City,Country | Group-id) | | + +-------+---------+------------------+------------------------+-----+ + | Site | Site | Location | Access Diversity | PE | + | | Network | (Address, Postal | (Constraint-Type, | | + | | Access | Code, State, | Group-id,Target Group- | | + | | | City,Country | id) | | | | | Code) | | | - +------+---------+------------------+----------------------+-------+ - | | | | | | + +-------+---------+------------------+------------------------+-----+ |SITE1 | ACCESS1 | (,,US,NewYork,) |(10,PE-Diverse,10) | PE1 | - +------+---------+------------------+----------------------+-------+ + +-------+---------+------------------+------------------------+-----+ |SITE2 | ACCESS2 | (,,CN,Beijing,) |(10,PE-Diverse,10) | PE2 | - +------+---------+------------------+----------------------+-------+ + +-------+---------+------------------+------------------------+-----+ |SITE3 | ACCESS3 | (,,UK,London, ) |(12,same-PE,12) | PE4 | - +------+---------+------------------+----------------------+-------+ + +-------+---------+------------------+------------------------+-----+ |SITE4 | ACCESS4 | (,,FR,Paris,) |(20,Bearer-Diverse,20)| PE7 | - +------+---------+------------------+----------------------+-------+ + +-------+---------+------------------+------------------------+-----+ - Table 1 : Mapping Between VPN Site and VNAP + Table 2: : Mapping Between VPN Site and VNAP 5. Applicability of TE-Service Mapping in Generic context As discussed in the Introduction Section, the models presented in this document are also applicable generically outside of the ACTN architecture. [RFC8309] defines Customer Service Model between Customer and Service Orchestrator and Service Delivery Model between Service Orchestrator and Network Orchestrator(s). TE-Service mapping - models defined in this document can be regarded primarily as - Customer Service Model and secondarily as Service Deliver Model. + models defined in this document can be regarded primarily as Customer + Service Model and secondarily as Service Deliver Model. 6. YANG Data Trees -module: ietf-l1csm-te-service-mapping - 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 +6.1. L3SM + module: ietf-l3sm-te-service-mapping + augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services + /l3vpn-svc:vpn-service: + +--rw te-service-mapping! + +--rw 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 /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 +6.2. L2SM module: ietf-l2sm-te-service-mapping - augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services/l2vpn-svc:vpn-service: - +-rw te-service-mapping! - augment /l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services/l2vpn-svc:vpn-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 /l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site/l2vpn-svc:site-network- -accesses/l2vpn-svc:site-network-access: - - +-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 /l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services + /l2vpn-svc:vpn-service: + +--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 - augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services/l3vpn-svc:vpn-service: - +-rw te-service-mapping! - augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services/l3vpn-svc:vpn-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 /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site/l3vpn-svc:site- - network-accesses/l3vpn-svc:site-network-access: - +-rw (te)? - +-:(actn-vn) - | +-rw actn-vn-ref? -> /vn:ap/access-point-list/access-point-id - +-:(te) - +-rw ltp? te-types:te-tp-id +6.3. L1CSM + module: ietf-l1csm-te-service-mapping + augment /l1csm:l1-connectivity/l1csm:services/l1csm:service: + +--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 /l1csm:l1-connectivity/l1csm:access/l1csm:unis/l1csm:uni: + +--rw (te)? + +--:(vn) + | +--rw vn-ref? + | -> /vn:ap/access-point-list/access-point-id + +--:(te) + +--rw ltp? te-types:te-tp-id 7. YANG Data Models The YANG codes are as follows: - file "ietf-te-service-mapping-types@2019-03-05.yang" +7.1. ietf-te-service-mapping-types + + file "ietf-te-service-mapping-types@2019-09-09.yang" module ietf-te-service-mapping-types { + yang-version 1.1; + namespace "urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types"; - prefix "tsm"; + prefix tsm; import ietf-te-types { - prefix "te-types"; + prefix te-types; + reference + "I-D.ietf-teas-yang-te-types: Traffic Engineering Common YANG + Types"; } import ietf-network { - prefix "nw"; + prefix nw; + reference + "RFC 8345: A YANG Data Model for Network Topologies"; } + import ietf-te { - prefix "te"; + prefix te; + reference + "I-D.ietf-teas-yang-te: A YANG Data Model for Traffic + Engineering Tunnels and Interfaces"; } import ietf-vn { - prefix "vn"; + prefix vn; + reference + "I-D.ietf-teas-actn-vn-yang: A Yang Data Model for VN Operation"; } organization "IETF Traffic Engineering Architecture and Signaling (TEAS) Working Group"; contact - "Editor: Young Lee - Dhruv Dhody - Qin Wu "; + "WG Web: + WG List: + + Editor: Young Lee + + Editor: Dhruv Dhody + + Editor: Qin Wu + "; + 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.)"; + variuous service models (e.g., L1CSM, L2SM, L3SM, etc.) - revision 2019-03-05 { + Copyright (c) 2019 IETF Trust and the persons identified as + authors of the code. All rights reserved. + + Redistribution and use in source and binary forms, with or + without modification, is permitted pursuant to, and subject + to the license terms contained in, the 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 + RFC itself for full legal notices."; + + revision 2019-09-09 { description - "initial version."; + "Initial revision."; reference - "TBD"; + "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; } /* * Identity for map-type */ + identity map-type { description - "Base identity from which specific map types are - derived."; + "Base identity from which specific map types are derived."; } identity new { base map-type; description "The new VN/tunnels are binded to the service."; } - identity detnet-hard-isolation { + identity hard-isolation { base new; description - "Hard isolation with deterministic characteristics."; - + "Hard isolation."; } - identity hard-isolation { - base new; + identity detnet-hard-isolation { + base hard-isolation; description - "Hard isolation."; + "Hard isolation with deterministic characteristics."; } identity soft-isolation { base new; description "Soft-isolation."; } identity select { base map-type; @@ -697,35 +742,34 @@ description "Soft-isolation."; } identity select { base map-type; description "The VPN service selects an existing tunnel with no modification."; } - identity modify { base map-type; description - "The VPN service selects an existing tunnel and allows - to modify the properties of the tunnel (e.g., b/w)"; + "The VPN service selects an existing tunnel and allows to modify + the properties of the tunnel (e.g., b/w)"; } /* * Identity for availability-type */ + identity availability-type { description - "Base identity from which specific map types are - derived."; + "Base identity from which specific map types are derived."; } identity level-1 { base availability-type; description "level 1: 99.9999%"; } identity level-2 { base availability-type; @@ -753,87 +798,97 @@ /* * Groupings */ grouping te-ref { description "The reference to TE."; choice te { description "The TE"; - case actn-vn { - leaf actn-vn-ref { + case vn { + leaf vn-ref { type leafref { path "/vn:vn/vn:vn-list/vn:vn-id"; } description - "The reference to ACTN VN"; + "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 + "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"; + path "/nw:networks/nw:network/nw:node/nw:node-id"; } description - "a reference to the abstract node in TE - Topology"; + "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-endpoint-ref { description "The reference to TE endpoints."; choice te { description "The TE"; - case actn-vn { - leaf actn-vn-ref { + case vn { + leaf vn-ref { type leafref { - path "/vn:ap/vn:access-point-list" - + "/vn:access-point-id"; + path "/vn:ap/vn:access-point-list/vn:access-point-id"; } description - "The reference to ACTN VN"; + "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; @@ -844,398 +899,552 @@ } leaf availability-type { type identityref { base availability-type; } description "Availability Requirement for the Service"; } uses te-ref; } - } + }//grouping +}//module - } - file "ietf-l1csm-te-service-mapping@2019-03-05.yang" +7.2. ietf-l3sm-te-service-mapping - module ietf-l1csm-te-service-mapping { + file "ietf-l3sm-te-service-mapping@2019-09-09.yang" + module ietf-l3sm-te-service-mapping { - namespace "urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping"; + yang-version 1.1; - prefix "tm"; + namespace "urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping"; + + prefix l3-tsm; import ietf-te-service-mapping-types { - prefix "tsm-types"; + prefix tsm-types; + reference + "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; } - import ietf-l1csm { - prefix "l1"; + import ietf-l3vpn-svc { + prefix l3vpn-svc; + reference + "RFC 8299: YANG Data Model for L3VPN Service Delivery"; } organization "IETF Traffic Engineering Architecture and Signaling (TEAS) Working Group"; contact - "Editor: Young Lee - Dhruv Dhody - Qin Wu "; + "WG Web: + WG List: + Editor: Young Lee + + Editor: Dhruv Dhody + + Editor: Qin Wu + "; description - "This module contains a YANG module for the mapping of - Layer 1 Connectivity Service Module (L1CSM) to the TE and VN "; + "This module contains a YANG module for the mapping of Layer 3 + Service Model (L3SM) to the TE and VN. - revision 2019-03-05 { + Copyright (c) 2019 IETF Trust and the persons identified as + authors of the code. All rights reserved. + + Redistribution and use in source and binary forms, with or + without modification, is permitted pursuant to, and subject + to the license terms contained in, the 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 + RFC itself for full legal notices."; + + revision 2019-09-09 { description - "initial version."; + "Initial revision."; reference - "TBD"; + "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; } /* - * Configuration data nodes + * Augmentation to L3SM */ - augment "/l1:l1-connectivity/l1:services/l1:service" { + augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services" + + "/l3vpn-svc:vpn-service" { description - "l1csm augmented to include TE parameters and mapping"; + "L3SM 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" { + presence + "Indicates L3 service to TE mapping"; description - "This augment is only valid for TE mapping -- - te mapping is added"; + "Container to augment l3sm to TE parameters and mapping"; uses tsm-types:te-mapping; } + }//augment - augment "/l1:l1-connectivity/l1:services/l1:service/l1:endpoint-1" { - description - "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" { + augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site" + + "/l3vpn-svc:site-network-accesses" + + "/l3vpn-svc:site-network-access" { description - "This augment is only valid for TE mapping -- - endpoint-2 te-reference is added"; + "This augment is only valid for TE mapping of L3SM network-access + to TE endpoints"; uses tsm-types:te-endpoint-ref; - } - } + }//augment + }//module - file "ietf-l2sm-te-service-mapping@2019-03-05.yang" +7.3. ietf-l2sm-te-service-mapping + file "ietf-l2sm-te-service-mapping@2019-09-09.yang" module ietf-l2sm-te-service-mapping { + yang-version 1.1; + namespace "urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping"; - prefix "tm"; + prefix l2-tsm; import ietf-te-service-mapping-types { - prefix "tsm-types"; + prefix tsm-types; + reference + "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; } import ietf-l2vpn-svc { - prefix "l2vpn-svc"; + prefix l2vpn-svc; + reference + "RFC 8466: A YANG Data Model for Layer 2 Virtual Private Network + (L2VPN) Service Delivery"; } organization "IETF Traffic Engineering Architecture and Signaling (TEAS) Working Group"; contact - "Editor: Young Lee - Dhruv Dhody - Qin Wu "; + "WG Web: + WG List: + + Editor: Young Lee + + Editor: Dhruv Dhody + + Editor: Qin Wu + "; + description - "This module contains a YANG module for the mapping of - Layer 2 Service Model (L1CSM) to the TE and VN "; + "This module contains a YANG module for the mapping of Layer 2 + Service Model (L2SM) to the TE and VN. - revision 2019-03-05 { + Copyright (c) 2019 IETF Trust and the persons identified as + authors of the code. All rights reserved. + + Redistribution and use in source and binary forms, with or + without modification, is permitted pursuant to, and subject + to the license terms contained in, the 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 + RFC itself for full legal notices."; + + revision 2019-09-09 { description - "initial version."; + "Initial revision."; reference - "TBD"; + "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; } /* - * Configuration data nodes + * Augmentation to L3SM */ - augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services/l2vpn-svc:vpn-service" { + augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:vpn-services/" + + "l2vpn-svc:vpn-service" { description - "l2sm augmented to include TE parameters and mapping"; + "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" { + presence + "indicates L2 service to te mapping"; description - "This augment is only valid for TE mapping -- - te mapping is added"; + "Container to augment L2SM to TE parameters and mapping"; uses tsm-types:te-mapping; } + }//augment augment "/l2vpn-svc:l2vpn-svc/l2vpn-svc:sites/l2vpn-svc:site" - +"/l2vpn-svc:site-network-accesses/l2vpn-svc:site-network-access" { + + "/l2vpn-svc:site-network-accesses" + + "/l2vpn-svc:site-network-access" { description - "This augment is only valid for TE mapping -- - network-access te-reference is added"; - uses tsm-types:te-endpoint-ref; - } - } + "This augment is only valid for TE mapping of L2SM network-access + to TE endpoints"; + uses tsm-types:te-endpoint-ref; + }//augment + }//module - file "ietf-l3sm-te-service-mapping@2019-03-05.yang" +7.4. ietf-l1csm-te-service-mapping - module ietf-l3sm-te-service-mapping { + file "ietf-l1csm-te-service-mapping@2019-09-09.yang" +module ietf-l1csm-te-service-mapping { - namespace "urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping"; + yang-version 1.1; - prefix "tm"; + namespace "urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping"; + + prefix l1-tsm; import ietf-te-service-mapping-types { - prefix "tsm-types"; + prefix tsm-types; + reference + "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; } - import ietf-l3vpn-svc { - prefix "l3vpn-svc"; + import ietf-l1csm { + prefix l1csm; + reference + "I-D.ietf-ccamp-l1csm-yang: A YANG Data Model for L1 Connectivity + Service Model (L1CSM)"; } + organization "IETF Traffic Engineering Architecture and Signaling (TEAS) Working Group"; contact - "Editor: Young Lee - Dhruv Dhody - Qin Wu "; + "WG Web: + WG List: + + Editor: Young Lee + + Editor: Dhruv Dhody + + Editor: Qin Wu + "; + description "This module contains a YANG module for the mapping of - Layer 3 Service Model (L3SM) to the TE and VN "; + 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. - revision 2019-03-05 { + 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). + + This version of this YANG module is part of RFC XXXX; see the + RFC itself for full legal notices."; + + revision 2019-09-09 { description - "initial version."; + "Initial revision."; reference - "TBD"; + "RFC XXXX: Traffic Engineering and Service Mapping Yang Model"; } /* - * Configuration data nodes + * Augmentation to L1CSM */ - augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services/l3vpn-svc:vpn-service" { + augment "/l1csm:l1-connectivity/l1csm:services/l1csm:service" { description - "l3sm augmented to include TE parameters and mapping"; + "L1CSM 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" { + presence + "Indicates L1 service to TE mapping"; description - "This augment is only valid for TE mapping -- - te mapping is added"; + "Container to augment L1CSM to TE parameters and mapping"; uses tsm-types:te-mapping; } + }//augment - augment "/l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site" - +"/l3vpn-svc:site-network-accesses/l3vpn-svc:site-network-access" { + augment "/l1csm:l1-connectivity/l1csm:access/l1csm:unis/" + + "l1csm:uni" { description - "This augment is only valid for TE mapping -- - network-access te-reference is added"; + "This augment is only valid for TE mapping of L1CSM UNI to TE + endpoints"; uses tsm-types:te-endpoint-ref; - } - - } + }//augment +}//module +8. Security Considerations -8. Security + 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 configuration, state, and action data defined in this document - are designed to be accessed via a management protocol with a secure - transport layer, such as NETCONF [RFC6241]. The NETCONF access - control model [RFC6536] provides the means to restrict access for - particular NETCONF users to a preconfigured subset of all available - NETCONF protocol operations and content. + 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. - A number of configuration data nodes defined in this document are - writable/deletable (i.e., "config true") These data nodes may be - considered sensitive or vulnerable in some network environments. + 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., ) + 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 registers the following namespace URIs in the IETF XML - registry [RFC3688]: + 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 Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. - -------------------------------------------------------------------- - -------------------------------------------------------------------- - URI: urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping + URI: urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. - -------------------------------------------------------------------- - -------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. - -------------------------------------------------------------------- - -------------------------------------------------------------------- - URI: urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping + URI: urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. - -------------------------------------------------------------------- - - This document registers the following YANG modules in the YANG - Module. - - Names registry [RFC7950]: - -------------------------------------------------------------------- - name: ietf-te-service-mapping-types - namespace: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping- - types - reference: RFC XXXX (TDB) - -------------------------------------------------------------------- + This document request the IANA to register four YANG modules in the + "YANG Module Names" registry [RFC6020], as follows - + Name: ietf-te-service-mapping-types + Namespace: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping-types + Prefix: tsm + Reference: [This.I-D] - -------------------------------------------------------------------- - name: ietf-l1csm-te-service-mapping - namespace: urn:ietf:params:xml:ns:yang:ietf-l1cms-te-service- - mapping - reference: RFC XXXX (TDB) - -------------------------------------------------------------------- + Name: ietf-l3sm-te-service-mapping + Namespace: urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service-mapping + Prefix: l3-tsm + Reference: [This.I-D] - -------------------------------------------------------------------- - name: ietf-l2sm-te-service-mapping - namespace: urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service- - mapping - reference: RFC XXXX (TDB) - -------------------------------------------------------------------- + Name: ietf-l2sm-te-service-mapping + Namespace: urn:ietf:params:xml:ns:yang:ietf-l2sm-te-service-mapping + Prefix: l2-tsm + Reference: [This.I-D] - -------------------------------------------------------------------- - name: ietf-l3sm-te-service-mapping - namespace: urn:ietf:params:xml:ns:yang:ietf-l3sm-te-service- - mapping - reference: RFC XXXX (TDB) - -------------------------------------------------------------------- + Name: ietf-l1csm-te-service-mapping + Namespace: urn:ietf:params:xml:ns:yang:ietf-l1csm-te-service-mapping + Prefix: l1-tsm + Reference: [This.I-D] 10. Acknowledgements We thank Diego Caviglia and Igor Bryskin for useful discussions and motivation for this work. 11. References -11.1. Informative References +11.1. Normative References - [RFC4110] R. Callon and M. Suzuki, "A Framework for Layer 3 - Provider-Provisioned Virtual Private Networks (PPVPNs)", - RFC 4110, July 2005. + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + DOI 10.17487/RFC3688, January 2004, + . - [RFC6020] M. Bjorklund, Ed., "YANG - A Data Modeling Language for - the Network Configuration Protocol (NETCONF)", RFC 6020, - October 2010. + [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure + Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, + . - [RFC8309] Q. Wu, W. Liu and A. Farrel, "Service Models Explained", - RFC 8309, January 2018. + [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., + 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, + . - [RFC8199] D. Bogdanovic, B. Claise, and C. Moberg, "YANG Module - Classification", RFC 8199, July 2017. + [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", + RFC 7950, DOI 10.17487/RFC7950, August 2016, + . - [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., - and A. Bierman, Ed., "Network Configuration Protocol - (NETCONF)", RFC 6241. + [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF + Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, + . - [RFC8453] D. Cecarelli and Y. Lee, "Framework for Abstraction and - Control of Traffic Engineered Networks", RFC 8453, August - 2018. + [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, + "YANG Data Model for L3VPN Service Delivery", RFC 8299, + DOI 10.17487/RFC8299, January 2018, + . - [TE-Topo] X. Liu, et. al., "YANG Data Model for TE Topologies", - draft-ietf-teas-yang-te-topo, work in progress. + [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", + BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, + . - [TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic - Engineering Tunnels and Interfaces", draft-ietf-teas-yang- - te, work in progress. + [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration + Access Control Model", STD 91, RFC 8341, + DOI 10.17487/RFC8341, March 2018, + . - [TE-Types] T. Saad (Editor), "Traffic Engineering Common YANG - Types", draft-ietf-teas-yang-te-types, work in progress. + [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., + Ananthakrishnan, H., and X. Liu, "A YANG Data Model for + Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March + 2018, . - [ACTN-VN-YANG] Y. Lee (Editor), "A Yang Data Model for ACTN VN - Operation", draft-lee-teas-actn-vn-yang, work in progress. + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + . - [ACTN-Applicability] Y. Lee, et al, "Applicability of YANG models - for Abstraction and Control of Traffic Engineered - Networks, draft-ietf-teas-actn-yang, work in progress. + [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG + Data Model for Layer 2 Virtual Private Network (L2VPN) + Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October + 2018, . - [RFC8299] Q. Wu, S. Litkowski, L.Tomotaki, and K. Ogaki, "YANG Data - Model for L3VPN service delivery", RFC 8299, January 2018. + [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-10 (work in + progress), September 2019. - [L2SM] B. Wen, et al, "A YANG Data Model for L2VPN Service - Delivery", draft-ietf-l2sm-l2vpn-service-model, work in - progress. + [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-06 (work in progress), July 2019. - [L1CSM] G. Fioccola, et al, "A Yang Data Model for L1 Connectivity - Service Model (L1CSM)", draft-ietf-ccamp-l1csm-yang, work - in progress. + [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-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, + . + + [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, + . + + [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module + Classification", RFC 8199, DOI 10.17487/RFC8199, July + 2017, . + + [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models + Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, + . + + [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, + . + + [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, + . + + [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 Old Dog Consulting - Email: adrian@olddog.co.uk + EMail: adrian@olddog.co.uk Italo Busi Huawei Technologies - Email: Italo.Busi@huawei.com + EMail: Italo.Busi@huawei.com + + Haomian Zheng + Huawei Technologies + + EMail: zhenghaomian@huawei.com Authors' Addresses - Young Lee - Huawei Technologies - 5340 Legacy Drive - Plano, TX 75023, USA - Phone: (469)277-5838 + Young Lee (editor) + SKKU - Email: leeyoung@huawei.com + Email: younglee.tx@gmail.com - Dhruv Dhody + Dhruv Dhody (editor) Huawei Technologies 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 Ericsson Torshamnsgatan,48 Stockholm, Sweden Email: daniele.ceccarelli@ericsson.com Jeff Tantsura Apstra - EMail: jefftant@gmail.com - - Giuseppe Fioccola - Huawei - Email: giuseppe.fioccola@huawei.com - - Qin Wu - Huawei - Email: bill.wu@huawei.com + Email: jefftant@gmail.com