Dear Stewart, et al., question and proposal to the following goals for NVO3: "NVO3 will develop operational, maintenance, troubleshooting, and security requirements." - should Administration of DCVPN be left outside of scope or it is implicitly in the scope as part of usual interpretation of the OAM? If administration of DCVPN is in scope for NVO3 it might be mentioned explicitly either by direct reference or by substituting "operational, maintenance" with "OAM"; - I think that survivability of DCVPN, including protection and restoration mechanisms, is in scope for NVO3 and can be explicitly mentioned. Thus the sentence might look like the following: "NVO3 will develop operational, administration, maintenance, troubleshooting, as well as, survivability and security requirements for DCVPN."
Regards, Greg On Thu, Apr 12, 2012 at 7:35 AM, Stewart Bryant <[email protected]> wrote: > > In this revised version of the charter I have attempted > to incorporate all of the charter discussion on the list. > > In particular I have used the term Data Center Virtual Private > Network (DCVPN) in place of Overlay. This has lead to > a slight change in WG name, but one that is consistent > with the L3 goals. > > I have tried to take the solutions references out. > > I have added in the scaling requirements which are > a key feature of this work. > > - Stewart > > > 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 > ______________________________**_________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/**listinfo/nvo3<https://www.ietf.org/mailman/listinfo/nvo3> >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
