A new IETF working group has been proposed in the Routing Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, April 24, 2012. Network Virtualization Overlays (nvo3) ----------------------------------------- Status: Proposed Working Group Last Updated: 2012-04-13 Chair(s): TBD Routing Area Director(s): Stewart Bryant <stbryant@cisco.com> Adrian Farrel <adrian@olddog.co.uk> Routing Area Advisor: Stewart Bryant <stbryant@cisco.com> Internet Area Advisor: TBD Operations Area Advisor: TBD Mailing Lists: Address: nvo3@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/nvo3 Archive: http://www.ietf.org/mail-archive/web/nvo3/ Description of Working Group: Support for multi-tenancy has become a core requirement of data centers (DCs), especially in the context of data centers supporting virtualized hosts known as virtual machines (VMs). Two key requirements needed to support multi-tenancy are traffic isolation, so that a tenant's traffic is not visible to any other tenant, and address independence, so that one tenant's addressing does not collide with other tenants addressing schemes or with addresses used within the data center itself. Another key requirement is to support the placement and migration of VMs anywhere within the data center, without being limited by DC network constraints such as the IP subnet boundaries of the underlying DC network. An NVO3 solution (known here as a Data Center Virtual Private Network (DCVPN)) is a VPN that is viable across a scaling range of a few thousand VMs to several million VMs running on greater than 100K physical servers. It thus has good scaling properties from relativly small networks to networks with several million DCVPN endpoints and hundreds of thousands DCVPNs within a single administrative domain. Note that although this charter uses the term VM throughout, NVO3 must also support connectivity to traditional hosts e.g. hosts that do not have hypervisors. NVO3 will develop an approach to multi-tenancy that uses a Layer 3 encapsulation rather than relying on traditional L2 isolation mechanisms (e.g., VLANs) to support multi-tenancy. The approach will provide an emulated Ethernet service capable of satisfying typical data center deployments. NVO3 will document the problem statement, the applicability, and an architectural framework for DCVPNs within a data center environment. Within this framework, functional blocks will be defined to allow the dynamic attachment / detachment of VMs to their DCVPN, and the interconnection of elements of the DCVPNs over the underlying physical network. This will support delivery of packets to the destination VM, and provide the network functions required for the migration of VMs within the network in a sub-second timeframe. Based on this framework, the WG will develop requirements for both control plane protocol(s) and data plane encapsulation format(s), and perform a gap analysis of existing candidate mechanisms. In addition to functional and architectural requirements, NVO3 will develop management, operational, OAM, maintenance, troubleshooting, and security requirements. The WG will investigate the interconnection of the DCVPNs and their tenants with non-NVO3 IP network(s) to determine if any specific work is needed. The NVO3 will write the following informational RFCs, which must be substantially complete before rechartering can be considered: Problem Statement Framework document Control plane requirements document Data plane requirements document Operational Requirements Gap Analysis Driven by the requirements and consistent with the gap analysis, the WG may request being rechartered to document solutions consisting of one or more data plane encapsulations and control plane protocols as applicable. Any documented solutions will use existing mechanisms if suitable, or will develop new mechanisms if necessary. If the WG anticipates the adoption of the technologies of another SDO, such as the IEEE, as part of the solution, it will liaise with that SDO to ensure the compatibility of the approach. Milestones: Dec 2012 Problem Statement submitted for IESG review Dec 2012 Framework document submitted for IESG review Dec 2012 Control plane requirements submitted for IESG review Dec 2012 Data plane requirements submitted for IESG review Dec 2012 Operational Requirements submitted for IESG review Dec 2012 Gap Analysis submitted for IESG review Dec 2012 Recharter or close Working Group
