Internet DRAFT - draft-gu-nvo3-auto-provisioning-reqs
draft-gu-nvo3-auto-provisioning-reqs
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,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, DOI 10.17487/RFC2234,
November 1997, <http://www.rfc-editor.org/info/rfc2234>.
[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, <http://www.rfc-editor.org/info/rfc2516>.
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,
<http://www.rfc-editor.org/info/rfc7364>.
[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, <http://www.rfc-editor.org/info/rfc7365>.
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]