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]