How come STT (Stateless Transport Tunneling) is not there in this ? I thought it is yet another standard along the lines of NVGRE and VXLAN. May be I’m wrong.
Sent from my iPad On May 1, 2012, at 9:26 AM, "IESG Secretary" <[email protected]> wrote: > A new IETF working group has been formed in the Routing Area. For > additional information, please contact the Area Directors or the WG > Chairs. > > > Network Virtualization Overlays (nvo3) > ----------------------------------------- > Status: Active Working Group > > Chairs: > Matthew Bocci <[email protected]> > Benson Schliesser <[email protected]> > > Routing Area Directors: > Stewart Bryant <[email protected]> > Adrian Farrel <[email protected]> > > Routing Area Advisor: > Stewart Bryant <[email protected]> > > Internet Area Advisor: > TBD > > Operations Area Advisor: > Ronald Bonica <[email protected]> > > Mailing Lists: > Address: [email protected] > 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). Three key requirements needed > to support multi-tenancy are: > > o Traffic isolation, so that a tenant's traffic is not visible to > any other tenant, and > > o Address independence, so that one tenant's addressing scheme does > not collide with other tenant's addressing schemes or with addresses > used within the data center itself. > > o 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 one hundred thousand physical servers. It thus has > good scaling properties from relatively small networks to > networks with several million DCVPN endpoints and hundreds of > thousands of DCVPNs within a single administrative domain. > > A DCVPN also supports VM migration between physical servers > in a sub-second timeframe. > > 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 consider approaches to multi-tenancy that reside at the > network layer rather than using traditional isolation mechanisms > that rely on the underlying layer 2 technology (e.g., VLANs). > The NVO3 WG will determine which types of connectivity services > are needed by typical DC deployments (for example, IP and/or > Ethernet). > > 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 the > delivery of packets to the destination VM within the scaling > and migration limits described above. > > Based on this framework, the NVO3 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, the NVO3 WG will develop > management, operational, maintenance, troubleshooting, security and > OAM protocol requirements. > > The NVO3 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 WG will write the following informational RFCs, which > must have completed Working Group Last Call 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 NVO3 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 IETF protocols if suitable. Otherwise, > the NVO3 WG may propose the development of new IETF protocols, > or the writing of an applicability statement for non-IETF > protocols. > > 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 Data plane requirements submitted for IESG review > Dec 2012 Operational Requirements submitted for IESG review > Mar 2013 Control plane requirements submitted for IESG review > Mar 2013 Gap Analysis submitted for IESG review > Apr 2013 Recharter or close Working Group _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
