NVO3 Z. Gu Internet-Draft T. Ao Intended status: Standards Track ZTE Corp Expires: February 21, 2016 Q. Sun China Telecom Vic. Liu China Mobile B. Khasnabish ZTE (TX) Inc. August 20, 2015 Virtual Network Auto-Provisioning Requirements draft-gu-nvo3-auto-provisioning-reqs-02.txt Abstract The automatic provisioning of services may be helpful for almost every kind of service because of short service time to market, less TCO, and so on. In NVO3, [RFC7365] and [RFC7364] all have some information on "Auto-provisioning/Service discovery" or "Dynamic Provisioning". Some further information should be helpful to clarify how automatic virtual network/service provisioning can be done in NVO3 partially if total automatic service provisioning is difficult. This document describes the general virtual network provisioning processes and discusses how VN can be automatically provided and related requirements. 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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 21, 2016. Gu, et al. Expires February 21, 2016 [Page 1] Internet-Draft VN Auto-Provisioning Req August 2015 Copyright Notice Copyright (c) 2015 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 1.1. General motivations for automatic VN provisioning . . . . 2 1.2. Automatic provisioning vs dynamic provisioning . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 3. NVO3 Virtual Network provisioning . . . . . . . . . . . . . . 3 4. Automatic VN provisioning Discussions . . . . . . . . . . . . 4 4.1. Detailed VN provisioning procedures . . . . . . . . . . . 4 4.2. Management initiated VN Auto-provisioning . . . . . . . . 7 4.2.1. Management initiated mechanism requirements . . . . . 7 4.2.2. Conclusion Remarks . . . . . . . . . . . . . . . . . 8 4.3. VM initiated VN Auto-provisioning . . . . . . . . . . . . 8 4.3.1. VM initiated mechanism requirements . . . . . . . . . 9 4.3.2. Conclusion Remarks . . . . . . . . . . . . . . . . . 9 4.4. VDP extension based VN Auto-provisioning . . . . . . . . 9 5. Discussions and Conclusions . . . . . . . . . . . . . . . . . 10 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative references . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction 1.1. General motivations for automatic VN provisioning The automatic provisioning of services may be helpful for almost every kind of services, because it can realize the short service time to market, less TCO, and avoid manual configuration errors, and so on. So does it for NVO3 virtual network provisioning. For large scale datacenter, it may contain hundreds of thousands servers or even more in datacenters, and up to millions of virtual networks Gu, et al. Expires February 21, 2016 [Page 2] Internet-Draft VN Auto-Provisioning Req August 2015 should be supported for the public/Internet users. It's a huge burden for provider_s network administrators to configure the NVEs and to deploy these virtual networks. It should be much better there're automatic configuration tools exist for network administrators. [RFC7365] had already discussed the possibilities of Auto-provisioning of VN Service[3.1.5.2]. 1.2. Automatic provisioning vs dynamic provisioning To be provided. This document first shows the basic and main steps for VN provisioning, then clarifies the functions needed for automatic provisioning of VN, and further discusses two mechanisms for VN automatic provisioning and the related requirements are discussed in the end. 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 RFC 2119 [RFC2119]. 3. NVO3 Virtual Network provisioning Currently customers can obtain virtual network service from cloud/ datacenter services providers. The process may include some main steps: Step1. The customer submits the VN requirements to services provider. Note that, customers can submit their services requirements by provider_s web portal, or, email, telephone, fax, or even visiting provider_s office, etc. Step2. The provider_s network administrators (properbally after clarification) map these requirements to some network nodes and further to network configurations which can be used to realize the VN provisioning. Step3. The provider_s network administrators configure each related network nodes manually. These configurations include VM platforms, related NVE/switch and Gateway configurations. Step4. After all related configurations have been successfully executed the VN provisioning is done and the provider can inform the customer the VN has been available and can be used regularly. Gu, et al. Expires February 21, 2016 [Page 3] Internet-Draft VN Auto-Provisioning Req August 2015 In current practices always there are tens thousands of servers in datacenter, an there are large amount of VN needs to provision and the network administrator can not finish the related configuration soon, so the customer needs to wait to get the VN. Then in some circumstances the VN automatic provisioning mechanisms are necessary. This document provides some detailed discussion. 4. Automatic VN provisioning Discussions 4.1. Detailed VN provisioning procedures According to draft-ietf-nvo3-use-case, RFC7365, and draft-ietf- nvo3-arch, and the current services practices, Figure 1 shows the typical and abstract VN provisioning and usage environments. Generally, the Internet users/ (enterprise) VN customers use the VN services provider_s website/Web Portal to submit the VN requirements. In figure 1, for simplicity the assumption been made that the NVA_s functionalities include some more related services provisioning roles which may be finished by administrators. The gateway/NVE supports secure access to customer_s VPN or enterprise_s gateway to connect the VN to enterprise internal network. And the hypervisor and its connected switch or other network appliances can be used as NVE concurrently in this document. Gu, et al. Expires February 21, 2016 [Page 4] Internet-Draft VN Auto-Provisioning Req August 2015 Typical VN provisioning and usage environments: +-----+ +------+ | VNA |----|Portal| +-----+ +------+ / | \ \ +----------+ / | \ \ | Customer | / | \ \ / +----------+ / | \ \ ---------- / / | \ / \ / | \ / \ +-- -------+ +----------------+ | \ | Internet | --| Customer | |VM Orchestration| | \ \ / +- --------+ | System | | \ \ / +----------------+ | | ------------ | | | / \ +----------+ | | +---+ | / -----|Enterprise| | | |NVE| | / +----------+ | | +---+ | / | | / \| / +----+ +----------+ +---+ +---+ | VM |----|Hypervisor|---|NVE|-----|NVE| +----+ +----------+ +---+ +---+ NVE Switch Gateway Figure 1 Customers can automatic login into the portal and do the services requirements submission. The related parameters include, for example, No of sites, No of VM in each site, VM access bandwidth, Internet access support, Internet access bandwidth, IP address type and/or IP address range, the bandwidth between sites or access points, security gateway connections, etc. The portal clarifies the services requirements, maps to underlining networks, translates the requirements to parameters and configuration commands, and distributes the parameters and configuration commands to related NVE(s) and/or VM orchestration system. VM orchestration system prepares the requested VMs using the related parameters. NVE executes the configuration commands using the related parameters. Configure each VM to connect it to related NVE according some rules. Gu, et al. Expires February 21, 2016 [Page 5] Internet-Draft VN Auto-Provisioning Req August 2015 For each VM configure related NVE interface to connect to the VM. Optionally configure NVE to execute related protocols to realize information exchange between NVEs and other functions. Optionally configure related GW to connect VN to Internet to realize VN_s Internet access. Optionally, support VN network administrators configure and manage their own VN automatically or manually. NVEs send execution and/or status information to NVA, and NVA synthesis these related information to form a VN provisioning report which will be sent to customer. The following are the key steps for VN provisioning: 1. Web-based VN requirements collection; 2. Web portal/NVA maps the requirements to related NVEs and servers, and optional gateways, and further translates the requirements to configuration activities/commands. 3. NVA delivers these configurations commands to related NVEs/ gateways. 4. NVA delivers these configurations commands to VM orchestration system to prepare requested VMs. 5. VMs join the VN. 6. NVEs exchange information each other by protocols or other mechanisms. 7. NVEs send status and execution information to NVA. 8. NVA forms VN provisioning status information to customer. Note that some steps can be executed concurrently. Step 1, 2, and 8 are out of scope of NVO3, we will give no further discussion here and will focus on the other steps. Note that for step 2, at least some mapping information shall be obtained from the requirements for consequent configurations/execution. Step 3-4, and step 6-7 can be implemented using existing technologies or by current practice, for example, manual configuration and so on. Gu, et al. Expires February 21, 2016 [Page 6] Internet-Draft VN Auto-Provisioning Req August 2015 This document mainly discusses how step 3-5 can be automatically executed, includes two auto-provisioning mechanisms. The first mechanism follows the traditional management process but provide automatic executions of some manual configurations. The second method based on NVE auto-discovery mechanism/protocol. 4.2. Management initiated VN Auto-provisioning Management initiated VN Auto-provisioning means the VN automatic provisioning procedures initiated by provider_s network administrator after VN provisioning parameters are already. Generally, a VN can be deployed on (mapped to) some VNEs and all the related VNEs connected each other through the underlining infrastructure network, and all the VN_s related VM/server are connected to one or more NVEs. The VN Auto provisioning configuration includes: Automatic collecting of VN requirements. Mapping the requirements to NVEs, VM platforms and other related network entities. Translating the requirements to corresponding configuration commands and related parameters. Deliver these configuration commands and related parameters to related network entities. Automatic execution of these commands in nodes, for example, including the automatic creation of VRF,the configuration of the interfaces which connect VM to NVE, routing protocol configuration, optionally other protocol configuration, etc. Update configurations executions. Execution results and status information reporting. 4.2.1. Management initiated mechanism requirements Req-1: Standard NVA-NVE/GW management interfaces, includes interface protocol and related parameters. Req-2: Standard NVA-Hypervisor/VM Orchestration System management interfaces, includes interface protocol and related parameters. Req-3: Optional, automatic routing protocol configuration. Gu, et al. Expires February 21, 2016 [Page 7] Internet-Draft VN Auto-Provisioning Req August 2015 Detailed information, TBD 4.2.2. Conclusion Remarks As shows above, following the typical manual configuration procedures there are lot of works to do to standardize the related protocols to support VN auto-provisioning if it were impossible. In future, the VN auto-provisioning is hopeful for NETCONF/NETMOD in IETF, NSMWG in DMTF all have already started to do some works to help to realize the VN automatic provisioning. 4.3. VM initiated VN Auto-provisioning Initial preparation for VN provisioning: obtain the VN requirements, clarifying/auditing, VN name or/and VN-ID decision, optional security information decision, for example User-ID/password decision, and the VN_s Internet access Gateway_s configuration information. And the basic assumption is all related network entities or underlining infrastructure supports mentioned functions. VM preparation, incl. VM creation and optional related network configuration, e.g. MAC address and or IP address allocation, etc. VM broadcasts auto-discovery packet to discover NVE. All the NVEs in the broadcast domain acknowledged the NVE auto-discovery packets. VM chooses one NVE as the serving NVE according some rules and send request packet to join the VN. NVE authenticates the VM for specific VN, supported by NVA. If VM pass the authentication then VNA return the related VN parameters to NVE. The parameters may include VN-ID, MAC address, IP address, create VRF, and so on. NVE creates the VRF and auto-configure NVE using received parameters. NVE choose Session-ID, or other parameters as NVE-VM connection identifier (and form a secure tunnel) and return these parameters to VM. VM uses these parameters to communicate with NVE. Optionally, VM authentication triggers NVA send Create VRF command and related parameters/information to GW for specific VN to establish secure tunnel for VN_s Internet access. VNE through NVA reports VN execution results and other status. Gu, et al. Expires February 21, 2016 [Page 8] Internet-Draft VN Auto-Provisioning Req August 2015 Finished all above steps, a VN is created automatically for the customer. 4.3.1. VM initiated mechanism requirements Req-1: NVE auto-discovery protocol, be used to discover NVE automatically and further automatic join NVE and trigger NVE to auto- configure the related VN. Req-2: NVE auto-discovery protocol support and efficiently deliver the related parameters, include MAC address, IP address, VN-ID, Session-ID, etc. Req-3: VM authentication to VN by using the existing protocols such as EAP or IEEE802.1x, etc. Req-4: NVE supports automatic execution of create VRF command and configuration. Req-5: Optional, automatic routing protocol configuration. Req-6: NVE auto-discovery protocol, shall be supported by NVEs and VMs which will join VNs. Req-7: NVE auto-discovery protocol, shall be suitable for or supported by all mainstream operating systems. 4.3.2. Conclusion Remarks This VM-initiated mechanism based on VNE auto-discovery protocol and some extensions of existing protocols to find the serving VNE and auto-join the NVE. It_s flexible and avoids some difficulties inherited from typical management procedures. It's hopeful to help to realize VN auto-provisioning in datacenter, at least partially. 4.4. VDP extension based VN Auto-provisioning VDP can be extended to support VM automatically join the VN. The main point is, using reserved VDP TLV Type to define some associate commands with auto join VN commands; or using a new filter information format to define this function, e.g. automatic join the VN, for the existing associate commands. When the EVB bridge, which also works as NVE, received the extended VDP commands it associates the VSI with a SBP, and further to create VN context for the VN which the VM wants to join, if the VN context does not exist; and further create an entry for the VM in the VRF table, if this entry does not exists. The associate can be done by Gu, et al. Expires February 21, 2016 [Page 9] Internet-Draft VN Auto-Provisioning Req August 2015 choosing one SBP from the SBP list which are configured by network administrator for automatic service provisioning purposes. Then, the NVE using NVE-NVA protocol to synchronize with other NVEs in the same VN, to realize the VN. 5. Discussions and Conclusions This document discussed two different kinds of automatic VN provisioning mechanism. The first one, management initiated automatic procedures include lots of general management interface standardization works. The second one, VM-initiated automatic VN provisioning further includes two mechanisms. The first one is based on NVE auto-discovery protocol,which is simple and flexible and it further owns other advantages such as support VM migration and to provide high secure transport mechanism potentially; the other one is based on VDP extensions. So we have two different mechanisms to realize the automatic VN provisioning. The VN automatic service provision requirements seems reasonable. This document may also be helpful for NVO3 control plane protocols discussions. 6. Acknowledgement To be added 7. References 7.1. Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, DOI 10.17487/RFC2234, November 1997, . [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516, February 1999, . Gu, et al. Expires February 21, 2016 [Page 10] Internet-Draft VN Auto-Provisioning Req August 2015 7.2. Informative References [I-D.ietf-nvo3-arch] Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. Narten, "An Architecture for Overlay Networks (NVO3)", draft-ietf-nvo3-arch-03 (work in progress), March 2015. [I-D.ietf-nvo3-use-case] Yong, L., Toy, M., Isaac, A., Manral, V., and L. Dunbar, "Use Cases for Data Center Network Virtualization Overlays", draft-ietf-nvo3-use-case-06 (work in progress), August 2015. [I-D.pt-nvo3-vdp-vm2nve-gap-analysis] Pelissier, J., Thaler, P., and P. Bottorff, "NVO3 VDP Gap Analysis - VM-to-NVE Specific Control-Plane Requirements", draft-pt-nvo3-vdp-vm2nve-gap-analysis-00 (work in progress), June 2014. [I-D.yizhou-nvo3-hpvr2nve-cp-req] Yizhou, L., Yong, L., Kreeger, L., Narten, T., and D. Black, "Hypervisor to NVE Control Plane Requirements", draft-yizhou-nvo3-hpvr2nve-cp-req-00 (work in progress), May 2014. [RFC7364] Narten, T., Ed., Gray, E., Ed., Black, D., Fang, L., Kreeger, L., and M. Napierala, "Problem Statement: Overlays for Network Virtualization", RFC 7364, DOI 10.17487/RFC7364, October 2014, . [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. Rekhter, "Framework for Data Center (DC) Network Virtualization", RFC 7365, DOI 10.17487/RFC7365, October 2014, . Authors' Addresses Zhongyu Gu ZTE Corp 50 Software Ave. Nanjing, Jiangsu, China Email: gu.zhongyu@zte.com.cn Gu, et al. Expires February 21, 2016 [Page 11] Internet-Draft VN Auto-Provisioning Req August 2015 Ting Ao ZTE Corp 50 Software Ave. Nanjing, Jiangsu, China Email: ao.ting@zte.com.cn Qiong Sun China Telecom No.118, Xizhimennei Street, Beijing, China Email: sunqiong@ctbri.com.cn Vic Liu China Mobile 32 Xuanwumen West Ave Beijing, China Email: liuzhiheng@chinamobile.com Bhumip Khasnabish ZTE (TX) Inc. 55 Madison Ave, Suite 302 Morristown, New Jersey 07960 USA Phone: +001-781-752-8003 Email: vumip1@gmail.com, bhumip.khasnabish@ztetx.com URI: http://tinyurl.com/bhumip/ Gu, et al. Expires February 21, 2016 [Page 12]