idnits 2.17.1 draft-gu-nvo3-auto-provisioning-reqs-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 6 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([RFC7364], [RFC7365]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (August 20, 2015) is 3171 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2234' is defined on line 445, but no explicit reference was found in the text == Unused Reference: 'RFC2516' is defined on line 449, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-nvo3-arch' is defined on line 456, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-nvo3-use-case' is defined on line 461, but no explicit reference was found in the text == Unused Reference: 'I-D.pt-nvo3-vdp-vm2nve-gap-analysis' is defined on line 467, but no explicit reference was found in the text == Unused Reference: 'I-D.yizhou-nvo3-hpvr2nve-cp-req' is defined on line 473, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Downref: Normative reference to an Informational RFC: RFC 2516 == Outdated reference: A later version (-08) exists of draft-ietf-nvo3-arch-03 == Outdated reference: A later version (-17) exists of draft-ietf-nvo3-use-case-06 Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NVO3 Z. Gu 3 Internet-Draft T. Ao 4 Intended status: Standards Track ZTE Corp 5 Expires: February 21, 2016 Q. Sun 6 China Telecom 7 Vic. Liu 8 China Mobile 9 B. Khasnabish 10 ZTE (TX) Inc. 11 August 20, 2015 13 Virtual Network Auto-Provisioning Requirements 14 draft-gu-nvo3-auto-provisioning-reqs-02.txt 16 Abstract 18 The automatic provisioning of services may be helpful for almost 19 every kind of service because of short service time to market, less 20 TCO, and so on. In NVO3, [RFC7365] and [RFC7364] all have some 21 information on "Auto-provisioning/Service discovery" or "Dynamic 22 Provisioning". Some further information should be helpful to clarify 23 how automatic virtual network/service provisioning can be done in 24 NVO3 partially if total automatic service provisioning is difficult. 25 This document describes the general virtual network provisioning 26 processes and discusses how VN can be automatically provided and 27 related requirements. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on February 21, 2016. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. General motivations for automatic VN provisioning . . . . 2 65 1.2. Automatic provisioning vs dynamic provisioning . . . . . 3 66 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 67 3. NVO3 Virtual Network provisioning . . . . . . . . . . . . . . 3 68 4. Automatic VN provisioning Discussions . . . . . . . . . . . . 4 69 4.1. Detailed VN provisioning procedures . . . . . . . . . . . 4 70 4.2. Management initiated VN Auto-provisioning . . . . . . . . 7 71 4.2.1. Management initiated mechanism requirements . . . . . 7 72 4.2.2. Conclusion Remarks . . . . . . . . . . . . . . . . . 8 73 4.3. VM initiated VN Auto-provisioning . . . . . . . . . . . . 8 74 4.3.1. VM initiated mechanism requirements . . . . . . . . . 9 75 4.3.2. Conclusion Remarks . . . . . . . . . . . . . . . . . 9 76 4.4. VDP extension based VN Auto-provisioning . . . . . . . . 9 77 5. Discussions and Conclusions . . . . . . . . . . . . . . . . . 10 78 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 7.1. Normative references . . . . . . . . . . . . . . . . . . 10 81 7.2. Informative References . . . . . . . . . . . . . . . . . 11 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 84 1. Introduction 86 1.1. General motivations for automatic VN provisioning 88 The automatic provisioning of services may be helpful for almost 89 every kind of services, because it can realize the short service time 90 to market, less TCO, and avoid manual configuration errors, and so 91 on. So does it for NVO3 virtual network provisioning. For large 92 scale datacenter, it may contain hundreds of thousands servers or 93 even more in datacenters, and up to millions of virtual networks 94 should be supported for the public/Internet users. It's a huge 95 burden for provider_s network administrators to configure the NVEs 96 and to deploy these virtual networks. It should be much better 97 there're automatic configuration tools exist for network 98 administrators. [RFC7365] had already discussed the possibilities of 99 Auto-provisioning of VN Service[3.1.5.2]. 101 1.2. Automatic provisioning vs dynamic provisioning 103 To be provided. 105 This document first shows the basic and main steps for VN 106 provisioning, then clarifies the functions needed for automatic 107 provisioning of VN, and further discusses two mechanisms for VN 108 automatic provisioning and the related requirements are discussed in 109 the end. 111 2. Conventions Used in This Document 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119]. 117 3. NVO3 Virtual Network provisioning 119 Currently customers can obtain virtual network service from cloud/ 120 datacenter services providers. The process may include some main 121 steps: 123 Step1. The customer submits the VN requirements to services 124 provider. Note that, customers can submit their services 125 requirements by provider_s web portal, or, email, telephone, fax, or 126 even visiting provider_s office, etc. 128 Step2. The provider_s network administrators (properbally after 129 clarification) map these requirements to some network nodes and 130 further to network configurations which can be used to realize the VN 131 provisioning. 133 Step3. The provider_s network administrators configure each related 134 network nodes manually. These configurations include VM platforms, 135 related NVE/switch and Gateway configurations. 137 Step4. After all related configurations have been successfully 138 executed the VN provisioning is done and the provider can inform the 139 customer the VN has been available and can be used regularly. 141 In current practices always there are tens thousands of servers in 142 datacenter, an there are large amount of VN needs to provision and 143 the network administrator can not finish the related configuration 144 soon, so the customer needs to wait to get the VN. Then in some 145 circumstances the VN automatic provisioning mechanisms are necessary. 147 This document provides some detailed discussion. 149 4. Automatic VN provisioning Discussions 151 4.1. Detailed VN provisioning procedures 153 According to draft-ietf-nvo3-use-case, RFC7365, and draft-ietf- 154 nvo3-arch, and the current services practices, Figure 1 shows the 155 typical and abstract VN provisioning and usage environments. 157 Generally, the Internet users/ (enterprise) VN customers use the VN 158 services provider_s website/Web Portal to submit the VN requirements. 159 In figure 1, for simplicity the assumption been made that the NVA_s 160 functionalities include some more related services provisioning roles 161 which may be finished by administrators. The gateway/NVE supports 162 secure access to customer_s VPN or enterprise_s gateway to connect 163 the VN to enterprise internal network. And the hypervisor and its 164 connected switch or other network appliances can be used as NVE 165 concurrently in this document. 167 Typical VN provisioning and usage environments: 169 +-----+ +------+ 170 | VNA |----|Portal| 171 +-----+ +------+ 172 / | \ \ +----------+ 173 / | \ \ | Customer | 174 / | \ \ / +----------+ 175 / | \ \ ---------- / 176 / | \ / \ 177 / | \ / \ +-- -------+ 178 +----------------+ | \ | Internet | --| Customer | 179 |VM Orchestration| | \ \ / +- --------+ 180 | System | | \ \ / 181 +----------------+ | | ------------ 182 | | | / \ +----------+ 183 | | +---+ | / -----|Enterprise| 184 | | |NVE| | / +----------+ 185 | | +---+ | / 186 | | / \| / 187 +----+ +----------+ +---+ +---+ 188 | VM |----|Hypervisor|---|NVE|-----|NVE| 189 +----+ +----------+ +---+ +---+ 190 NVE Switch Gateway 192 Figure 1 194 Customers can automatic login into the portal and do the services 195 requirements submission. The related parameters include, for 196 example, No of sites, No of VM in each site, VM access bandwidth, 197 Internet access support, Internet access bandwidth, IP address type 198 and/or IP address range, the bandwidth between sites or access 199 points, security gateway connections, etc. 201 The portal clarifies the services requirements, maps to underlining 202 networks, translates the requirements to parameters and configuration 203 commands, and distributes the parameters and configuration commands 204 to related NVE(s) and/or VM orchestration system. 206 VM orchestration system prepares the requested VMs using the related 207 parameters. 209 NVE executes the configuration commands using the related parameters. 211 Configure each VM to connect it to related NVE according some rules. 213 For each VM configure related NVE interface to connect to the VM. 215 Optionally configure NVE to execute related protocols to realize 216 information exchange between NVEs and other functions. 218 Optionally configure related GW to connect VN to Internet to realize 219 VN_s Internet access. 221 Optionally, support VN network administrators configure and manage 222 their own VN automatically or manually. 224 NVEs send execution and/or status information to NVA, and NVA 225 synthesis these related information to form a VN provisioning report 226 which will be sent to customer. 228 The following are the key steps for VN provisioning: 230 1. Web-based VN requirements collection; 232 2. Web portal/NVA maps the requirements to related NVEs and servers, 233 and optional gateways, and further translates the requirements to 234 configuration activities/commands. 236 3. NVA delivers these configurations commands to related NVEs/ 237 gateways. 239 4. NVA delivers these configurations commands to VM orchestration 240 system to prepare requested VMs. 242 5. VMs join the VN. 244 6. NVEs exchange information each other by protocols or other 245 mechanisms. 247 7. NVEs send status and execution information to NVA. 249 8. NVA forms VN provisioning status information to customer. 251 Note that some steps can be executed concurrently. 253 Step 1, 2, and 8 are out of scope of NVO3, we will give no further 254 discussion here and will focus on the other steps. Note that for 255 step 2, at least some mapping information shall be obtained from the 256 requirements for consequent configurations/execution. 258 Step 3-4, and step 6-7 can be implemented using existing technologies 259 or by current practice, for example, manual configuration and so on. 261 This document mainly discusses how step 3-5 can be automatically 262 executed, includes two auto-provisioning mechanisms. 264 The first mechanism follows the traditional management process but 265 provide automatic executions of some manual configurations. The 266 second method based on NVE auto-discovery mechanism/protocol. 268 4.2. Management initiated VN Auto-provisioning 270 Management initiated VN Auto-provisioning means the VN automatic 271 provisioning procedures initiated by provider_s network administrator 272 after VN provisioning parameters are already. 274 Generally, a VN can be deployed on (mapped to) some VNEs and all the 275 related VNEs connected each other through the underlining 276 infrastructure network, and all the VN_s related VM/server are 277 connected to one or more NVEs. The VN Auto provisioning 278 configuration includes: 280 Automatic collecting of VN requirements. 282 Mapping the requirements to NVEs, VM platforms and other related 283 network entities. 285 Translating the requirements to corresponding configuration commands 286 and related parameters. 288 Deliver these configuration commands and related parameters to 289 related network entities. 291 Automatic execution of these commands in nodes, for example, 292 including the automatic creation of VRF,the configuration of the 293 interfaces which connect VM to NVE, routing protocol configuration, 294 optionally other protocol configuration, etc. 296 Update configurations executions. 298 Execution results and status information reporting. 300 4.2.1. Management initiated mechanism requirements 302 Req-1: Standard NVA-NVE/GW management interfaces, includes interface 303 protocol and related parameters. 305 Req-2: Standard NVA-Hypervisor/VM Orchestration System management 306 interfaces, includes interface protocol and related parameters. 308 Req-3: Optional, automatic routing protocol configuration. 310 Detailed information, TBD 312 4.2.2. Conclusion Remarks 314 As shows above, following the typical manual configuration procedures 315 there are lot of works to do to standardize the related protocols to 316 support VN auto-provisioning if it were impossible. 318 In future, the VN auto-provisioning is hopeful for NETCONF/NETMOD in 319 IETF, NSMWG in DMTF all have already started to do some works to help 320 to realize the VN automatic provisioning. 322 4.3. VM initiated VN Auto-provisioning 324 Initial preparation for VN provisioning: obtain the VN requirements, 325 clarifying/auditing, VN name or/and VN-ID decision, optional security 326 information decision, for example User-ID/password decision, and the 327 VN_s Internet access Gateway_s configuration information. And the 328 basic assumption is all related network entities or underlining 329 infrastructure supports mentioned functions. 331 VM preparation, incl. VM creation and optional related network 332 configuration, e.g. MAC address and or IP address allocation, etc. 334 VM broadcasts auto-discovery packet to discover NVE. All the NVEs in 335 the broadcast domain acknowledged the NVE auto-discovery packets. 337 VM chooses one NVE as the serving NVE according some rules and send 338 request packet to join the VN. 340 NVE authenticates the VM for specific VN, supported by NVA. If VM 341 pass the authentication then VNA return the related VN parameters to 342 NVE. The parameters may include VN-ID, MAC address, IP address, 343 create VRF, and so on. 345 NVE creates the VRF and auto-configure NVE using received parameters. 347 NVE choose Session-ID, or other parameters as NVE-VM connection 348 identifier (and form a secure tunnel) and return these parameters to 349 VM. 351 VM uses these parameters to communicate with NVE. 353 Optionally, VM authentication triggers NVA send Create VRF command 354 and related parameters/information to GW for specific VN to establish 355 secure tunnel for VN_s Internet access. 357 VNE through NVA reports VN execution results and other status. 359 Finished all above steps, a VN is created automatically for the 360 customer. 362 4.3.1. VM initiated mechanism requirements 364 Req-1: NVE auto-discovery protocol, be used to discover NVE 365 automatically and further automatic join NVE and trigger NVE to auto- 366 configure the related VN. 368 Req-2: NVE auto-discovery protocol support and efficiently deliver 369 the related parameters, include MAC address, IP address, VN-ID, 370 Session-ID, etc. 372 Req-3: VM authentication to VN by using the existing protocols such 373 as EAP or IEEE802.1x, etc. 375 Req-4: NVE supports automatic execution of create VRF command and 376 configuration. 378 Req-5: Optional, automatic routing protocol configuration. 380 Req-6: NVE auto-discovery protocol, shall be supported by NVEs and 381 VMs which will join VNs. 383 Req-7: NVE auto-discovery protocol, shall be suitable for or 384 supported by all mainstream operating systems. 386 4.3.2. Conclusion Remarks 388 This VM-initiated mechanism based on VNE auto-discovery protocol and 389 some extensions of existing protocols to find the serving VNE and 390 auto-join the NVE. It_s flexible and avoids some difficulties 391 inherited from typical management procedures. It's hopeful to help 392 to realize VN auto-provisioning in datacenter, at least partially. 394 4.4. VDP extension based VN Auto-provisioning 396 VDP can be extended to support VM automatically join the VN. The 397 main point is, using reserved VDP TLV Type to define some associate 398 commands with auto join VN commands; or using a new filter 399 information format to define this function, e.g. automatic join the 400 VN, for the existing associate commands. 402 When the EVB bridge, which also works as NVE, received the extended 403 VDP commands it associates the VSI with a SBP, and further to create 404 VN context for the VN which the VM wants to join, if the VN context 405 does not exist; and further create an entry for the VM in the VRF 406 table, if this entry does not exists. The associate can be done by 407 choosing one SBP from the SBP list which are configured by network 408 administrator for automatic service provisioning purposes. 410 Then, the NVE using NVE-NVA protocol to synchronize with other NVEs 411 in the same VN, to realize the VN. 413 5. Discussions and Conclusions 415 This document discussed two different kinds of automatic VN 416 provisioning mechanism. The first one, management initiated 417 automatic procedures include lots of general management interface 418 standardization works. The second one, VM-initiated automatic VN 419 provisioning further includes two mechanisms. The first one is based 420 on NVE auto-discovery protocol,which is simple and flexible and it 421 further owns other advantages such as support VM migration and to 422 provide high secure transport mechanism potentially; the other one is 423 based on VDP extensions. 425 So we have two different mechanisms to realize the automatic VN 426 provisioning. The VN automatic service provision requirements seems 427 reasonable. 429 This document may also be helpful for NVO3 control plane protocols 430 discussions. 432 6. Acknowledgement 434 To be added 436 7. References 438 7.1. Normative references 440 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 441 Requirement Levels", BCP 14, RFC 2119, 442 DOI 10.17487/RFC2119, March 1997, 443 . 445 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 446 Specifications: ABNF", RFC 2234, DOI 10.17487/RFC2234, 447 November 1997, . 449 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., 450 and R. Wheeler, "A Method for Transmitting PPP Over 451 Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516, 452 February 1999, . 454 7.2. Informative References 456 [I-D.ietf-nvo3-arch] 457 Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. 458 Narten, "An Architecture for Overlay Networks (NVO3)", 459 draft-ietf-nvo3-arch-03 (work in progress), March 2015. 461 [I-D.ietf-nvo3-use-case] 462 Yong, L., Toy, M., Isaac, A., Manral, V., and L. Dunbar, 463 "Use Cases for Data Center Network Virtualization 464 Overlays", draft-ietf-nvo3-use-case-06 (work in progress), 465 August 2015. 467 [I-D.pt-nvo3-vdp-vm2nve-gap-analysis] 468 Pelissier, J., Thaler, P., and P. Bottorff, "NVO3 VDP Gap 469 Analysis - VM-to-NVE Specific Control-Plane Requirements", 470 draft-pt-nvo3-vdp-vm2nve-gap-analysis-00 (work in 471 progress), June 2014. 473 [I-D.yizhou-nvo3-hpvr2nve-cp-req] 474 Yizhou, L., Yong, L., Kreeger, L., Narten, T., and D. 475 Black, "Hypervisor to NVE Control Plane Requirements", 476 draft-yizhou-nvo3-hpvr2nve-cp-req-00 (work in progress), 477 May 2014. 479 [RFC7364] Narten, T., Ed., Gray, E., Ed., Black, D., Fang, L., 480 Kreeger, L., and M. Napierala, "Problem Statement: 481 Overlays for Network Virtualization", RFC 7364, 482 DOI 10.17487/RFC7364, October 2014, 483 . 485 [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 486 Rekhter, "Framework for Data Center (DC) Network 487 Virtualization", RFC 7365, DOI 10.17487/RFC7365, October 488 2014, . 490 Authors' Addresses 492 Zhongyu Gu 493 ZTE Corp 494 50 Software Ave. 495 Nanjing, Jiangsu, 496 China 498 Email: gu.zhongyu@zte.com.cn 499 Ting Ao 500 ZTE Corp 501 50 Software Ave. 502 Nanjing, Jiangsu, 503 China 505 Email: ao.ting@zte.com.cn 507 Qiong Sun 508 China Telecom 509 No.118, Xizhimennei Street, 510 Beijing, 511 China 513 Email: sunqiong@ctbri.com.cn 515 Vic Liu 516 China Mobile 517 32 Xuanwumen West Ave 518 Beijing, 519 China 521 Email: liuzhiheng@chinamobile.com 523 Bhumip Khasnabish 524 ZTE (TX) Inc. 525 55 Madison Ave, Suite 302 526 Morristown, New Jersey 07960 527 USA 529 Phone: +001-781-752-8003 530 Email: vumip1@gmail.com, bhumip.khasnabish@ztetx.com 531 URI: http://tinyurl.com/bhumip/