NVO3 Z. Gu Internet-Draft T. Ao Intended status: Standards Track ZTE Corp Expires: July 8, 2015 Q. Sun China Telecom Vic. Liu China Mobile January 4, 2015 Virtual Network Auto-Provisioning Requirements draft-gu-nvo3-auto-provisioning-reqs-01.txt Abstract [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 NVO3 general virtual network provisioning processes and discusses how VN can be automatically provided and related requirements in or out of the scope of NVO3. 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 July 8, 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 Gu, et al. Expires July 8, 2015 [Page 1] Internet-Draft VN Auto-Provisioning Reqs January 2015 (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 . . . . . . . . 6 4.2.1. Management initiated mechanism requirements . . . . . 7 4.2.2. Conclusion Remarks . . . . . . . . . . . . . . . . . 7 4.3. VM initiated VN Auto-provisioning . . . . . . . . . . . . 7 4.3.1. VM initiated mechanism requirements . . . . . . . . . 8 4.3.2. VNE Auto-discovery protocol Comparison with VDP . . . 9 4.3.3. Conclusion Remarks . . . . . . . . . . . . . . . . . 9 5. Discussions and Conclusions . . . . . . . . . . . . . . . . . 9 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative references . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction 1.1. General motivations for automatic VN provisioning There are Tens of thousands servers or even more in datacenters, and up to millions of virtual networks 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]. Gu, et al. Expires July 8, 2015 [Page 2] Internet-Draft VN Auto-Provisioning Reqs January 2015 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. 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. Gu, et al. Expires July 8, 2015 [Page 3] Internet-Draft VN Auto-Provisioning Reqs January 2015 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. 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 Gu, et al. Expires July 8, 2015 [Page 4] Internet-Draft VN Auto-Provisioning Reqs January 2015 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. 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. Gu, et al. Expires July 8, 2015 [Page 5] Internet-Draft VN Auto-Provisioning Reqs January 2015 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. 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. Gu, et al. Expires July 8, 2015 [Page 6] Internet-Draft VN Auto-Provisioning Reqs January 2015 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. 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. Gu, et al. Expires July 8, 2015 [Page 7] Internet-Draft VN Auto-Provisioning Reqs January 2015 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. 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. Gu, et al. Expires July 8, 2015 [Page 8] Internet-Draft VN Auto-Provisioning Reqs January 2015 4.3.2. VNE Auto-discovery protocol Comparison with VDP To be provided. 4.3.3. 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. 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, based on NVE auto-discovery protocol and some extensions of existing protocols, is simple and flexible and it owns other advantages such as support VM migration and further to provide high secure transport mechanism potentially. It shall be noted that a whole automatic VN service provisioning is out of the scope of NVO3, but some partial automatic provisioning mechanism is helpful for VN service provisioning. This document may be helpful for NVO3 control plane interfaces 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, March 1997. [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, 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, February 1999. Gu, et al. Expires July 8, 2015 [Page 9] Internet-Draft VN Auto-Provisioning Reqs January 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-02 (work in progress), October 2014. [I-D.ietf-nvo3-use-case] Yong, L., Toy, M., Isaac, A., Manral, V., and L. Dunbar, "Use Cases for DC Network Virtualization Overlays", draft- ietf-nvo3-use-case-04 (work in progress), July 2014. [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., Gray, E., Black, D., Fang, L., Kreeger, L., and M. Napierala, "Problem Statement: Overlays for Network Virtualization", RFC 7364, October 2014. [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. Rekhter, "Framework for Data Center (DC) Network Virtualization", RFC 7365, October 2014. Authors' Addresses Zhongyu Gu ZTE Corp 50 Software Ave. Nanjing, Jiangsu, China Email: gu.zhongyu@zte.com.cn Gu, et al. Expires July 8, 2015 [Page 10] Internet-Draft VN Auto-Provisioning Reqs January 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 Gu, et al. Expires July 8, 2015 [Page 11]