Message info
 
To:nvo3@ietf.org From:Stewart Bryant Subject:[nvo3] Fwd: Re: Revised NVO3 charter for discussion today 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 <stbryant@cisco.com>
Reply-To: stbryant@cisco.com
To: iesg@ietf.org <iesg@ietf.org>


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