TEAS WG Young Lee Dhruv Dhody Internet Draft Huawei Intended status: standard Daniele Ceccarrelli Expires: September 2017 Ericsson - March 9, 2017 Traffic Engineering and Service Mapping Yang Model draft-lee-teas-te-service-mapping-yang-00 Status of this Memo This Internet-Draft is submitted to IETF 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 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 9, 2017. Copyright Notice Copyright (c) 2017 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 Lee, et al. Expires September 9, 2017 [Page 1]
Internet-Draft TE & Service Mapping March 2017 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. Abstract This document provides a YANG data model to map service model (e.g. L3SM) and Traffic Engineering model (e.g. TE Tunnel or ACTN VN model). This model is referred to as TE service Mapping Model. This model is applicable to the operation's need for a seamless control and management of their L3VPN with TE tunnel support. Table of Contents 1. Introduction...................................................2 2. L3VPN Architecture in ACTN context.............................4 3. TE-Service Mapping Model.......................................7 4. YANG Data Tree.................................................7 5. Yang Data Model................................................9 6. Security......................................................16 7. Acknowledgements..............................................16 8. References....................................................17 8.1. Informative References...................................17 9. Contributors..................................................18 Authors' Addresses...............................................18 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 language of choice for documenting data models, and YANG models have been produced to allow configuration or modeling of a variety of network devices, protocol instances, and network services. YANG data models have been classified in [Netmod-Yang-Model-Classification] and [Service-YANG]. [RFC4110] provides a framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs). [L3SM-YANG] provides a L3VPN service delivery YANG model for PE-based VPNs. Lee, et al. Expires September 9, 2017 [Page 2]
Internet-Draft TE & Service Mapping March 2017 [ACTN-VN-YANG] describes how customers or end to end orchestrators can request and/or instantiate a generic virtual network service. [ACTN-Applicability] describes a connection between IETF YANG model classifications to ACTN interfaces. In particular, it describes the customer service model can be mapped into the CMI (CNC-MDSC Interface) of the ACTN architecture. The YANG model on the ACTN CMI is known as customer service model in [Service-YANG]. The YANG model developed in this document describes how operator's end to end orchestrator interacts with the MDSC so that the MDSC then can coordinate the control and management of L3VPN MPLS TE tunnels that traverse both IP/MPLS and Transport networks. While IP/MPLS PNC is responsible for provisioning the VPN service on the PE nodes, the MDSC can coordinate how to map the VPN services with TE tunnels. This is consistent with the two of the core functions of the MDSC specified in [ACTN-Frame]: . Customer mapping/translation function: This function is to map customer requests/commands into network provisioning requests that can be sent to the Physical Network Controller (PNC) according to business policies 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 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. In some cases, under the confines of service policy, dynamic TE tunnel creation may need to be supported for the VPN service. This may occur when there are no suitable existing TE tunnels that can support VPN service requirements. Or the operator would like to dynamically create and bind tunnels to the VPN, which could not be shared for network slicing. Lee, et al. Expires September 9, 2017 [Page 3]
Internet-Draft TE & Service Mapping March 2017 To summarize there are two mode of operations - . VN/Tunnel Binding - Customer could use the VPN service model [L3SM-Yang] to communicate to the network operator to deliver a L3VPN service. Based on the sites, QoS parameters, VPN service topology, the network operator could create an ACTN VN [ACTN-VN- YANG]. Further the mapping yang model described in Section 5 of this document is used to set this mapping between the L3VPN service and the ACTN VN. Note that this could be done dynamically. The VN (and TE tunnels) could be bound to the L3VPN and not used for any other VPN. . VN/Tunnel Selection - Customer could request an L3VPN service [L3SM-Yang], and with this model as input, the PNC configures the different network elements to deliver the service. Each network element would select a tunnel based on the configuration. With this mode, new tunnels (or VN) are not created for each VPN. Thus, the tunnels can be shared across multiple VPN. Further the mapping yang model described in Section 5 of this document is used to get the mapping between the L3VPN and the tunnels in use. The YANG model described in this document provides an ACTN TE- service mapping model that enables a seamless service mapping across L3VPN, ACTN VN and TE-tunnel models at the controllers. 2. L3VPN Architecture in ACTN context Figure 1 shows the architectural context of this document. Lee, et al. Expires September 9, 2017 [Page 4]
Internet-Draft TE & Service Mapping March 2017 | L3SM (+CMI) V +------+ | MDSC | +------+ | +-------------------------------+ | | | V V V +--------+ +--------+ +--------+ |IP/MPLS | | Transp.| |IP/MPLS | | PNC 1 | | PNC | | PNC 2 | +--------+ +--------+ +--------+ CE CE \ AS 100 AS 200 / \ / A----B----C----ASBR1------ASBR2----D----E----F /: / /: /: /: /: /: /: / : / / : / : / : / : / : / : CE----G--:-H----I--:-ASBR3-:----ASBR4-:--J--:-K--:-L--:---CE : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : M-:----:--P---:---S------:---U-----V-:--X-:--Y : / : : / : / : / : / : / :/ : :/ : / : / :/ :/ N----O----Q-------R----------T----------W----Z Transport Network Figure 1: L3VPN Architecture from the IP+Optical Network Perspective There are three main entities in the architecture. . MDSC: This entity is responsible for coordinating a L3VPN service request (expressed in L3SM) with the IP PNC and the Transport PNC. One of the key responsibilities of the MDSC for TE services is to coordinate with both the IP PNC and the Transport PNC for the mapping of L3VPN Service Model and ACTN VN/TE-Tunnel models. With the VN/TE-tunnel binding case, the MDSC will need to coordinate with the Transport PNC to dynamically create the TE-tunnel(s) in the Transport network as needed. These tunnels are added as links in the IP Layer topology. The MDSC coordinates with IP PNC to Lee, et al. Expires September 9, 2017 [Page 5]
Internet-Draft TE & Service Mapping March 2017 create the TE-tunnel(s) in the IP layer, as part of the ACTN VN creation. . IP/MPLS PNC: This entity is responsible for device configuration to create PE-PE L3VPN tunnels for the VPN customer and for the configuration of the L3VPN VRF on the PE nodes. Each network element would select a tunnel based on the configuration. . Transport PNC: This entity is responsible for device configuration for TE tunnels in the transport networks. High-Level Control Flows 1. Customer asks for a L3VPN between CE1 and CE2 with TE constraints using L3SM model. The customer can provide tunnel creation policy where it allows dynamic VN/TE tunnel creation or not. Under this policy, dynamic VN/TE tunnels can be created when there are no proper VN/TE-tunnels that can support L3VPN tunnels or when there is a strict isolation requirement for the VPN service, e.g., no sharing with other tunnels is allowed. 2. The MDSC determines if it needs to create a new VN, 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 ACTN VN. In case an existing tunnel is to be used, each device will select which tunnel to use and populates 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 are passed to the IP/MPLS PNC for the actual VPN configuration and activation. a. The Transport PNC creates the corresponding TE tunnel matching with the access point and egress point. b. The IP/MPLS PNC maps the VPN ID with the corresponding TE tunnel ID to bind these two IDs. 4. The IP/MPLS PNC creates/updates a VRF instance for this VPN customer. (This is not covered by the Yang Model presented in this draft). Lee, et al. Expires September 9, 2017 [Page 6]
Internet-Draft TE & Service Mapping March 2017 3. TE-Service Mapping Model The role of TE-service Mapping model is to create a binding relationship across L3SM and TE Tunnel model via generic ACTN VN Model. The ACTN VN YANG model is a generic virtual network service model that allows customers (internal or external) to create a VN that meets the customer's service objective with various constraints. The TE-service mapping model is needed to bind L3VPN specific service model with TE-specific parameters. This binding will facilitate a seamless service operation with underlay-TE network visibility. The TE-service model developed in this document can also be extended to support other services such as L2SM and so one. +---------+ +-------------+ +----------+ | L3SM | <------> | | <-----> | TE-Tunnel| +---------+ | | | Model | | TE-Service | +-----^----+ |Mapping Model| | +---------+ | | +-----v----+ | L2SM | <------> | | <-----> | ACTN VN | +---------+ +-------------+ | Model | +----------+ . . . 4. YANG Data Tree module: ietf-te-service-mapping +--rw te-service-mapping | +--rw service-mapping | | +--rw mapping-list* [map-id] | | +--rw map-id uint32 | | +--rw map-type? map-type | | +--rw (service)? | | | +--:(l3vpn) | | | | +--rw l3vpn-ref? -> /l3:l3vpn-svc/vpn-services/vpn- service/vpn-id | | | +--:(l2vpn) | | | +--rw l2vpn-ref? -> /l2:l2vpn-svc/vpn-services/vpn- svc/vpn-id Lee, et al. Expires September 9, 2017 [Page 7]
Internet-Draft TE & Service Mapping March 2017 | | +--rw (te)? | | +--:(actn-vn) | | | +--rw actn-vn-ref? -> /vn:actn/vn/vn-list/vn-id | | +--:(te) | | +--rw te-tunnel-list* te:tunnel-ref | +--rw site-mapping | +--rw mapping-list* [map-id] | +--rw map-id uint32 | +--rw (service)? | | +--:(l3vpn) | | | +--rw l3vpn-ref? -> /l3:l3vpn-svc/sites/site/site-id | | +--:(l2vpn) | | +--rw l2vpn-ref? -> /l2:l2vpn-svc/sites/site/site-id | +--rw (te)? | +--:(actn-vn) | | +--rw actn-vn-ref? -> /vn:actn/ap/access-point-list/access- point-id | +--:(te) +--ro te-service-mapping-state +--ro service-mapping | +--ro mapping-list* [map-id] | +--ro map-id uint32 | +--ro map-type? map-type | +--ro (service)? | | +--:(l3vpn) | | | +--ro l3vpn-ref? -> /l3:l3vpn-svc/vpn-services/vpn- service/vpn-id | | +--:(l2vpn) | | +--ro l2vpn-ref? -> /l2:l2vpn-svc/vpn-services/vpn- svc/vpn-id | +--ro (te)? | +--:(actn-vn) | | +--ro actn-vn-ref? -> /vn:actn/vn/vn-list/vn-id | +--:(te) | +--ro te-tunnel-list* te:tunnel-ref +--ro site-mapping +--ro mapping-list* [map-id] +--ro map-id uint32 +--ro (service)? | +--:(l3vpn) | | +--ro l3vpn-ref? -> /l3:l3vpn-svc/sites/site/site-id | +--:(l2vpn) | +--ro l2vpn-ref? -> /l2:l2vpn-svc/sites/site/site-id +--ro (te)? +--:(actn-vn) | +--ro actn-vn-ref? -> /vn:actn/ap/access-point-list/access- point-id +--:(te) Lee, et al. Expires September 9, 2017 [Page 8]
Internet-Draft TE & Service Mapping March 2017 5. Yang Data Model The YANG code is as follows: <CODE BEGINS> file "ietf-te-service-mapping@2017-03-09.yang" module ietf-te-service-mapping { namespace "urn:ietf:params:xml:ns:yang:ietf-te-service-mapping"; prefix "tm"; import ietf-l3vpn-svc { prefix "l3"; } import ietf-l2vpn-svc { prefix "l2"; } import ietf-te { prefix "te"; } import ietf-actn-vn { prefix "vn"; } organization "IETF Traffic Engineering Architecture and Signaling (TEAS) Working Group"; contact "Editor: Young Lee <leeyoung@huawei.com> Dhruv Dhody <dhruv.ietf@gmail.com>"; description "This module contains a YANG module for the mapping of service (e.g. L3VPN) to the TE tunnels or ACTN VN."; Lee, et al. Expires September 9, 2017 [Page 9]
Internet-Draft TE & Service Mapping March 2017 revision 2017-03-09 { description "initial version."; reference "TBD"; } /* * Identities */ identity service-type { description "Base identity from which specific service types are derived."; } identity l3vpn-service { base service-type; description "L3VPN service type."; } identity l2vpn-service { base service-type; description "L2VPN service type."; } /* * Enum */ typedef map-type { type enumeration { enum "bind" { description "The VN/tunnels are binded to the service"; } enum "select" { description "The VPN service select an existing tunnel"; Lee, et al. Expires September 9, 2017 [Page 10]
Internet-Draft TE & Service Mapping March 2017 } } description "The map-type"; } /* * Groupings */ grouping service-ref{ description "The reference to the service."; choice service { description "The service"; case l3vpn { leaf l3vpn-ref { type leafref { path "/l3:l3vpn-svc/l3:vpn-services/" + "l3:vpn-service/l3:vpn-id"; } description "The reference to L3VPN Service Yang Model"; } } case l2vpn { leaf l2vpn-ref { type leafref { path "/l2:l2vpn-svc/l2:vpn-services/" + "l2:vpn-svc/l2:vpn-id"; } description "The reference to L2VPN Service Yang Model"; } } } } grouping site-ref { Lee, et al. Expires September 9, 2017 [Page 11]
Internet-Draft TE & Service Mapping March 2017 description "The reference to the site."; choice service { description "The service choice"; case l3vpn { leaf l3vpn-ref{ type leafref { path "/l3:l3vpn-svc/l3:sites/l3:site/" + "l3:site-id"; } description "The reference to L3VPN Service Yang Model"; } } case l2vpn { leaf l2vpn-ref{ type leafref { path "/l2:l2vpn-svc/l2:sites/l2:site/" + "l2:site-id"; } description "The reference to L2VPN Service Yang Model"; } } } } grouping te-ref { description "The reference to TE."; choice te { description "The TE"; case actn-vn { leaf actn-vn-ref { type leafref { path "/vn:actn/vn:vn/vn:vn-list/vn:vn-id"; } Lee, et al. Expires September 9, 2017 [Page 12]
Internet-Draft TE & Service Mapping March 2017 description "The reference to ACTN VN"; } } case te { leaf-list te-tunnel-list { type te:tunnel-ref; description "Reference to TE Tunnels"; } } } } grouping te-endpoint-ref { description "The reference to TE endpoints."; choice te { description "The TE"; case actn-vn { leaf actn-vn-ref { type leafref { path "/vn:actn/vn:ap/vn:access-point-list" + "/vn:access-point-id"; } description "The reference to ACTN VN"; } } case te { /*should we refer to Te-topology or Te-tunnel's endpoint(?)*/ } } } Lee, et al. Expires September 9, 2017 [Page 13]
Internet-Draft TE & Service Mapping March 2017 grouping service-mapping { description "Mapping between Services and TE"; container service-mapping { description "Mapping between Services and TE"; list mapping-list { key "map-id"; description "Mapping identified via a map-id"; leaf map-id { type uint32; description "a unique mapping identifier"; } leaf map-type { type map-type; description "Tunnel Bind or Tunnel Selection"; } uses service-ref; uses te-ref; } } } grouping site-mapping { description "Mapping between VPN access site and TE endpoints or AP"; container site-mapping { description "Mapping between VPN access site and TE endpoints or AP"; list mapping-list { key "map-id"; description "Mapping identified via a map-id"; leaf map-id { type uint32; Lee, et al. Expires September 9, 2017 [Page 14]
Internet-Draft TE & Service Mapping March 2017 description "a unique mapping identifier"; } uses site-ref; uses te-endpoint-ref; } } } /* * Configuration data nodes */ container te-service-mapping { description "Mapping between Services and TE"; uses service-mapping; uses site-mapping; } /* * Operational data nodes */ container te-service-mapping-state{ config false; description "Mapping between Services and TE"; uses service-mapping; uses site-mapping; } Lee, et al. Expires September 9, 2017 [Page 15]
Internet-Draft TE & Service Mapping March 2017 } <CODE ENDS> 6. Security This document is an informational draft. When the models mentioned in this draft are implemented, detailed security consideration will be given in such work. How security fits into the whole architecture has the following components: - the use of Restconf security between components - the use of authentication and policy to govern which services can be requested by different parties. - how security may be requested as an element of a service and mapped down to protocol security mechanisms as well as separation (slicing) of physical resources) 7. IANA Considerations This document registers the following namespace URIs in the IETF XML registry [RFC3688]: -------------------------------------------------------------------- URI: urn:ietf:params:xml:ns:yang:ietf-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]: -------------------------------------------------------------------- Lee, et al. Expires September 9, 2017 [Page 16]
Internet-Draft TE & Service Mapping March 2017 name: ietf-service-mapping namespace: urn:ietf:params:xml:ns:yang:ietf-te-service-mapping prefix: rip reference: RFC XXXX (TDB) -------------------------------------------------------------------- 8. Acknowledgements We thank Diego Caviglia and Igor Bryskin for useful discussions and motivation for this work. 9. References 9.1. Informative References [RFC4110] R. Callon and M. Suzuki, "A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4110, July 2005. [RFC6020] M. Bjorklund, Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. [Service-YANG] Q. Wu, W. Liu and A. Farrel, "Service Models Explained", draft-wu-opsawg-service-model-explained, work in progress. [Netmod-Yang-Model-Classification] D. Bogdanovic, B. Claise, and C. Moberg, "YANG Module Classification", draft-ietf-netmod- yang-model-classification, work in progress. [Netconf] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241. [Restconf] A. Bierman, M. Bjorklund, and K. Watsen, "RESTCONF Protocol", draft-ietf-netconf-restconf, work in progress. [ACTN-Frame] D. Cecarelli and Y. Lee, "Framework for Abstraction and Control of Traffic Engineered Networks", draft-ietf-teas- actn-framework, work in progress. [TE-Topology] X. Liu, et. al., "YANG Data Model for TE Topologies", draft-ietf-teas-yang-te-topo, work in progress. Lee, et al. Expires September 9, 2017 [Page 17]
Internet-Draft TE & Service Mapping March 2017 [TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic Engineering Tunnels and Interfaces", draft-ietf-teas-yang- te, work in progress. [ACTN-VN-YANG] Y. Lee (Editor), "A Yang Data Model for ACTN VN Operation", draft-lee-teas-actn-vn-yang, work in progress. [L3SM-YANG] S. Litkowski, L.Tomotaki, and K. Ogaki, "YANG Data Model for L3VPN service delivery", draft-ietf-l3sm-l3vpn- service-model, work in progress. 10. Contributors Authors' Addresses Young Lee Huawei Technologies 5340 Legacy Drive Plano, TX 75023, USA Phone: (469)277-5838 Email: leeyoung@huawei.com Dhruv Dhody Huawei Technologies Email: dhruv.ietf@gmail.com Daniele Ceccarelli Ericsson Torshamnsgatan,48 Stockholm, Sweden Email: daniele.ceccarelli@ericsson.com Lee, et al. Expires September 9, 2017 [Page 18]