Subject: [nvo3] Fwd: Re: Revised NVO3 charter for discussion today

From: Stewart Bryant <[email-masked]>
Date: Thu, 12 Apr 2012 16:19:07 +0100

FYI

-------- Original Message --------
Subject: 	Re: Revised NVO3 charter for discussion today
Date: 	Thu, 12 Apr 2012 16:18:23 +0100
From: 	Stewart Bryant <[email-masked]>
Reply-To: 	[email-masked]
To: 	[email-masked] <[email-masked]>

Some requested edits

OLD
NVO3 will develop an approach to multi-tenancy that uses an
encapsulation header that resides above IP 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.

NEW
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.
END

I have been asked to consider

OLD
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
NEW

NVO3 will produce informational RFCs that cover each of the following
topics:
     Problem Statement
     Framework document
     Control plane requirements document
     Data plane requirements document
     Operational Requirements
     Gap Analysis
These  must be substantially complete before rechartering can be
considered.

Stewart

On 12/04/2012 15:36, Stewart Bryant wrote:
>
>
>  NVO3: Network Virtualization Over Layer 3
>
>  Chairs - TBD
>  Area - Routing
>  Area Director - Stewart Bryant
>  OPS Area Adviser - TBD
>
>
>  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).  A key multi-tenancy requirement
>  is traffic isolation, so that a tenant's traffic (and internal address
>  usage) is not visible to any other tenant and does not collide 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 over two million VMs running on greater
>  than 100K physical servers. It thus has good scaling properties
>  from relatively small networks to networks with hundreds of
>  thousands of DCVPN endpoints and several million 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 an
>  encapsulation header that resides above IP 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 operational,
>  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,
>  it is anticipated that the WG will 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 Gap Analysis submitted for IESG review
>  Dec 2012 Recharter or close Working Group
>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html