Network Working Group D. Zhang Internet Draft Alibaba Intended status: Standard Track A. Zaalouk Expires: July 2015 K. Pentikousis EICT January 30, 2015 VPN Service Management YANG Data Model draft-adel-vpn-service-management-model-00 Abstract Currently new services create new opportunities for both network providers and service providers. Shared Unified Policy Automation (SUPA) was proposed to develop a model that abstracts network resources and services and a methodology by which the management and monitoring of network services can be done using standardized policy rules. This document defines a VPN service management yang data model and gives an example for DDC use case. Status of this Memo 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 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on July 28, 2015. Adel, et al. Expires July 28, 2015 [Page 1] Internet-Draft SUPA Configuration Model January 2015 Copyright Notice Copyright (c) 2014 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 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. Table of Contents 1. Introduction ......................................... 2 2. Conventions used in this document..................... 3 3. Network Configuration Model Overview ................. 3 4. Network Configuration Modules ........................ 3 4.1. L3VPN Service Module............................. 4 4.1.1. L3VPN YANG Model ........................... 5 5. Module for DDC services .............................. 9 5.1.1. Model for DDC services ..................... 10 6. Security Considerations .............................. 17 7. IANA Considerations .................................. 17 8. Acknowledgments ...................................... 17 9. References ........................................... 17 9.1. Normative References ............................ 17 9.2. Informative References .......................... 18 1. Introduction Currently new services bring new challenges and opportunities for both network providers and service providers. Meanwhile, legacy services such as VPN [RFC4110] also need specialized management and controlling capability from the network management systems to improve the experiences for fast deployment and dynamic configuration. Shared Unified Policy Automation (SUPA) [SUPA-problem-statement] [SUPA-framework] was proposed to introduce the concepts of multi- level and multi-technology network abstractions to address the current separation between development and deployment operations. The first example that SUPA will focus on will be VPN management. Adel, et al. Expires July 28, 2015 [Page 2] Internet-Draft SUPA Configuration Model January 2015 This document introduces YANG [RFC6020] [RFC6021] data models for SUPA configuration. Such models can facilitate the standardization for the interface of SUPA, as they are compatible to a variety of protocols such as NETCONF [RFC6241] and [RESTCONF]. Please note that in the context of SUPA, the term "application" refers to a operational and management applications employed, and possibly implemented, by an operator. The first configuration model is based on the first example - VPN management. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying [RFC2119] significance. 3. Network Configuration Model Overview Figure 1 illustrates the network configuration model which contains several modules for specific services such as VPN management. +------------------------------------------+ | +----------------+ | | | VPN Management | ... | | +----------------+ | | | | Network Service Configuration | +------------------------------------------+ Figure 1: Overview of configuration model structure 4. Network Configuration Modules In this section, several specific network configuration models are described based on a set of specific network services and the framework of SUPA [SUPA-framework]. Adel, et al. Expires July 28, 2015 [Page 3] Internet-Draft SUPA Configuration Model January 2015 4.1. L3VPN Service Module A Layer 3 Virtual Private Network (L3VPN) interconnects sets of hosts and routers based on Layer 3 addresses and forwarding. L3VPN can be based on MPLS or IP technologies. L3VPN is a PE-based VPN managed by operators. L3VPN is widely used in carrier metro networks to provide VPN service for enterprise users. A L3VPN model is a collection of L3VPN instances. A L3VPN instance contains a set of access interfaces to network devices as well as other attributes, such as routing protocol, address family, topology, and so on. To configure a L3VPN instance, the administrator needs to specify which port(s) of a network device belongs to a L3VPN instance. Those ports and network device information can be derived from a network topology model in a network management system. The administrator also needs to specify what routing protocol needs to be configured for a L3VPN instance. The following describes the information model for L3VPN, based on which programmers can develop applications to configure L3VPN instances. Adel, et al. Expires July 28, 2015 [Page 4] Internet-Draft SUPA Configuration Model January 2015 module: SUPA-netl3vpn +--rw netl3vpnInstance* [instanceName] +--rw instanceName string +--rw servicType? enumeration +--rw afType? enumeration +--rw acIfs +--rw acIf* [vncAcIfId] +--rw acIfId string +--rw acIfAddr? +--rw acIfMask? unsignedByte +--rw role? enumeration +--rw userName? string +--rw userPassword? string +--rw phyNodeId? string +--rw physAcIfId? string +--rw protocol* 4.1.1. L3VPN YANG Model module SUPA-netl3vpn { namespace ""; prefix "nc"; organization ""; description ""; revision "2014-08-13"; list netl3vpnInstance { key "instanceName"; max-elements "unbounded"; min-elements "0"; description "."; leaf instanceName { description "."; config "true"; type string { length "1..64"; pattern "([^?]*)"; } } leaf servicType { description "."; config "true"; Adel, et al. Expires July 28, 2015 [Page 5] Internet-Draft SUPA Configuration Model January 2015 default "full-mesh"; type enumeration { enum full-mesh { value "0"; description "full-mesh"; } enum hub-spoke { value "1"; description "hub-spoke"; } } } leaf afType { description "."; config "true"; default "ipv4uni"; type enumeration { enum ipv4uni { value "0"; description "ipv4uni"; } enum ipv6uni { value "1"; description "ipv6uni"; } } } list acIf { key "acIfId"; max-elements "unbounded"; min-elements "0"; description "."; leaf acIfId { description "."; config "true"; type string { length "1..64"; pattern "([^?]*)"; } } leaf acIfAddr { description "."; config "true"; Adel, et al. Expires July 28, 2015 [Page 6] Internet-Draft SUPA Configuration Model January 2015 type string { pattern "([^?]*)"; } } leaf acIfMask { description "."; config "true"; type uint8 { range "0..128"; } } leaf role { description "."; config "true"; type enumeration { enum edge-if { value "0"; description "edge-if:"; } enum center-if { value "1"; description "center:"; } } } leaf userName { description "."; config "true"; type string { length "1..64"; pattern "([^?]*)"; } } leaf userPassword { description "."; config "true"; type string { length "1..64"; pattern "([^?]*)"; } } leaf phyNodeId { Adel, et al. Expires July 28, 2015 [Page 7] Internet-Draft SUPA Configuration Model January 2015 description "."; config "true"; type string { length "1..64"; pattern "([^?]*)"; } } leaf phyAcIfId { description "."; config "true"; type string { length "1..64"; pattern "([^?]*)"; } } container protocol { description "."; leaf protocolType { description "."; config "true"; default "ospf"; type enumeration { enum bgp { value "0"; description "bgp"; } enum ospf { value "1"; description "ospf"; } enum isis { value "2"; description "isis"; } } } container igpAttr { description "."; leaf protocolId { description "."; config "true"; default "0"; Adel, et al. Expires July 28, 2015 [Page 8] Internet-Draft SUPA Configuration Model January 2015 type uint32 { } } } container bgpAttr { description "."; leaf remoteAsNumber { description "."; config "true"; default "0"; type string { length "1..11"; } } leaf remotePeerAddr { description "."; config "true"; type string { } } } } } } } 5. Module for DDC services The following describes SUPA VPN management model designed for DDC services use case [SUPA-DDC]. [SUPA-DDC] took a large-scale Internet Data Center (IDC) operator as an example to describe what SUPA needs to do including DDC service initiation, VPN-based connectivity initiation, optimize traffic route, traffic adjustment and monitor. Module "ietf-supa-ddc" defines generic VPN management aspects which are common to all DDC services use case regardless of their type of vendor. In effect, the module can be viewed as providing a generic VPN management for DDC services. Adel, et al. Expires July 28, 2015 [Page 9] Internet-Draft SUPA Configuration Model January 2015 module: ietf-supa-ddc +--rw ddc-operation +--rw create-ddc-Services | +--rw ddc-service* [tenant-name] | +--rw tenant-name string | +--rw dc-name* string | +--rw tenant-network-id* string | +--rw connection-type-between-dc? enumeration +--rw create-vpn-instances-for-ddc | +--rw vpn-instance* [vpn-name] | +--rw vpn-name string | +--rw vlan-id? uint16 | +--rw dc-information* [dc-name] | | +--rw dc-name string | | +--rw interface-name? string | +--rw vpn-type? enumeration | +--rw bandwidth? uint32 | +--rw latency? uint32 +--rw optimize-traffic-Services | +--rw optimize-traffic-service* [vpn-name] | +--rw vpn-name string | +--rw bandWidth? uint32 | +--rw latency? uint32 +--rw specify-flow-paths +--rw specify-flow-path* [vpn-name] +--rw vpn-name string +--rw vpn-type? enumeration +--rw flow-name? string +--rw threshold? uint32 +--rw pass-node* string +--rw bypass-node* string 5.1.1. Model for DDC services module ietf-supa-ddc { namespace "urn:ietf:params:xml:ns:yang:ietf-supa-ddc"; // replace with IANA namespace when assigned prefix ddc; import ietf-inet-types { prefix inet; } organization "IETF"; contact "Editor: Ying Cheng Adel, et al. Expires July 28, 2015 [Page 10] Internet-Draft SUPA Configuration Model January 2015 chengying10@chinaunicom.cn"; description "This YANG module defines a component that describing the ddc service model for creating and optimizing tenant's DC (data center) services that are deployed in multiple data centers. Terms and Acronyms DDC: Distributed Data Center L2VPN: Layer 2 Virtual Private Network L3VPN: Layer 3 Virtual Private Network"; revision 2014-12-25 { description "Initial revision."; reference "RFC XXXX: A YANG Data Model for DDC Operation"; } container ddc-operation{ description "Distributed Data Center Service Operation Data"; container create-ddc-Services { description "Management system/ application requires controller to create tenant's network that are deployed in multiple data centers. The controller(s) is/are told the following data: name of data centers that the tenant's service are deployed in, connected method between data centers for the tenant (e.g. L2VPN, l3VPN, etc.), name of tenant, ID of networks that belong to the tenant"; list ddc-service { key "tenant-name"; description "Overall ddc operational data, including the names of data center,the connection method between data centers, name of tenant, ID of networks that belong to the tenants"; leaf tenant-name { type string; mandatory true; description "Indicates the name of the tenant that the ddc service is created for"; } Adel, et al. Expires July 28, 2015 [Page 11] Internet-Draft SUPA Configuration Model January 2015 leaf-list dc-name { type string; description "List of the names of data center that the tenant's service is deployed in."; } leaf-list tenant-network-id { type string; description "list of the tenant networks in different data centers. These networks should be integrated into the tenant's vitual data center"; } leaf connection-type-between-dc { type enumeration { enum L2VPN { description "L2VPN"; } enum L3VPN { description "L2VPN"; } } description "Indicates the connection method between data centers that the tenant service is deployed in. The connection type may be L2VPN or L3VPN"; } } } container create-vpn-instances-for-ddc { description "Management system/ application requires controller to create VPN for a tenant between data centers. VPN name, tennant VLAN ID, VPN sites and interfaces, VPN type, bandwidth requirement and latency requirement should be told to controller"; list vpn-instance { key "vpn-name"; description "Overall VPN operational data, including the name of VPN, the VLAN ID of tenant, the sites information of the VPN, the interface names of VPN endpoints, the type of VPN, Adel, et al. Expires July 28, 2015 [Page 12] Internet-Draft SUPA Configuration Model January 2015 the bandwidth and latency requirements of VPN"; leaf vpn-name { type string; mandatory true; description "Indicates the name of the VPN instance"; } leaf vlan-id { type uint16 { range "1 .. 4094"; } description "Indicates the VLAN id of the tenant in data centers"; } list dc-information { key dc-name; description "dc information"; leaf dc-name { type string; description "List of the names of data center that the tenant's service is deployed in."; } leaf interface-name { type string; description "Indicates a set of access interface names of the network device that the data centers (deployment of tenant's service) are connected to."; } } leaf vpn-type { type enumeration { enum L2VPN { description "L2VPN"; } enum L3VPN { description "L3VPN"; } } description "Indicates the type of VPN instance that is created for tenant. It can be L2VPN or L3VPN"; Adel, et al. Expires July 28, 2015 [Page 13] Internet-Draft SUPA Configuration Model January 2015 } leaf bandwidth { type uint32; units "Kbps"; description "Indicates the bandwidth requirement of the VPN instance that is created for tenant."; } leaf latency { type uint32; units "microseconds"; description "Indicates the latency requirement of the VPN instance that is created for tenant."; } } } container optimize-traffic-Services { description "Management system/ application requires controller to adjust the bandwidth of VPN to optimize the traffic when the bandwidth utilization is below or over certain threshold. vpn name, vpn type and adjusted bandwidth should be told to controller."; list optimize-traffic-service { key "vpn-name"; description "The list of VPN that need to be adjusted for optimizing traffic for the VPN between data centers. The data includes: the name of adjusted VPN instance, the type of VPN instance will be, the bandwidth and the latency requirement will be"; leaf vpn-name { type string; mandatory true; description "Indicates the name of VPN that needs to be adjusted. A VPN instance is identified by vpn-name. It should be one of the created VPN instance names"; } leaf vpn-type { type enumeration { enum L2VPN { Adel, et al. Expires July 28, 2015 [Page 14] Internet-Draft SUPA Configuration Model January 2015 description "L2VPN"; } enum L3VPN { description "L3VPN"; } } description "Indicates the type of VPN instance that needs to be adjusted. L2VPN or L3VPN"; } leaf bandWidth { type uint32; units "Kbps"; description "Indicates the bandwidth requirement of the VPN instance that is created for tenant."; } leaf latency { type uint32; units "microseconds"; description "Indicates the latency requirement of the VPN instance that is created for tenant."; } } } container specify-flow-paths { description "To improve the bandwidth utilization (or reduce the cost, or other reason) and miligate traffic congestion,management system/ application requires controller to adjust certain flows to pass/bypass certain nodes(or links), when, e.g., bandwidth utilization exceed certain threshold. Vpn name, vpn type, adjusted flow and specified nodes (that the flow should pass) should be told to controller. so that the controller can configure the network elements to change the VRF table and routing table"; list specify-flow-path { key "vpn-name"; description "The list of VPN and flow that need to be adjusted in specific paths. So as to optimizing traffic in the links that are between data centers."; leaf vpn-name { Adel, et al. Expires July 28, 2015 [Page 15] Internet-Draft SUPA Configuration Model January 2015 type string; mandatory true; description "Indicates the name of VPN that the adjusted flow belongs to. A VPN instance is identified by vpn-name. It should be one of the created VPN instance names"; } leaf vpn-type { type enumeration { enum L2VPN { description "L2VPN"; } enum L3VPN { description "L3VPN"; } } description "Indicates the type of VPN instance that the adjusted flow belongs to. L2VPN or L3VPN"; } leaf flow-name { type string; description "The name of the adjusted flow. So as to tell the Controller which flow should be adjusted"; } leaf threshold { type uint32; description "The bandwidth threshold of the link. If the link usage is greater than the threshold, the specified node will be by bypassed."; } leaf-list pass-node { type string; description "List of nodes that the adjusted flow needs to pass. So as to adjust the flow path between data centers."; } leaf-list bypass-node { type string; description "List of nodes that the adjusted flow needs to bypass if the link usage is greater than the threshold. So as to adjust the flow path between data centers."; } Adel, et al. Expires July 28, 2015 [Page 16] Internet-Draft SUPA Configuration Model January 2015 } } } 6. Security Considerations TBD 7. IANA Considerations This document has no actions for IANA. 8. Acknowledgments This document has benefited from reviews, suggestions, comments and proposed text provided by the following members, listed in alphabetical order: Feng Dong, Jing Huang, Junru Lin, Felix Lu, Wu Nan, Juergen Schoenwaelder, Yiyong Zha, and Cathy Zhou. Will Liu contributed to an early version of this draft. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, October 2010. [RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4110, July 2005. Adel, et al. Expires July 28, 2015 [Page 17] Internet-Draft SUPA Configuration Model January 2015 [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, May 2002. [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. 9.2. Informative References [SUPA-framework] C. Zhou, L. M. Contreras, Q. Sun, and P. Yegani, " The Framework of Shared Unified Policy Automation (SUPA) ", IETF Internet draft, draft-zhou-supa-framework, January 2015. [SUPA-problem-statement] G. Karagiannis, Q. Sun, Luis M. Contreras, P. Yegani, and JF Tremblay, "Problem Statement for Shared Unified Policy Automation (SUPA)", IETF Internet draft, draft-karagiannis- supa-problem-statement, January 2015. [SUPA-DDC] Y. Cheng,and JF. Tremblay, "Use Cases for Distributed Data Center Applications in SUPA", IETF Internet draft, draft- cheng-supa-ddc-use-cases, January 2015 [RESTCONF] Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando, "RESTCONF Protocol", draft-ietf-netconf-restconf (work in progress), July 2014. Adel, et al. Expires July 28, 2015 [Page 18] Internet-Draft SUPA Configuration Model January 2015 Authors' Addresses Dacheng Zhang Alibaba Chaoyang Dist Beijing 100000 P.R. China dacheng.zdc@alibaba-inc.com Adel Zaalouk EICT GmbH Torgauer Strasse 12-15 Berlin 10829 Germany Email: adel.ietf@gmail.com Kostas Pentikousis EICT GmbH Torgauer Strasse 12-15 Berlin 10829 Germany Email: k.pentikousis@eict.de Adel, et al. Expires July 28, 2015 [Page 19]