None of these protocols (NVGRE, VXLAN or STT) are mentioned in the charter.
Thanks, --David > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Tina > TSOU > Sent: Tuesday, May 01, 2012 1:01 PM > To: [email protected] > Cc: [email protected] > Subject: Re: [nvo3] WG Action: Network Virtualization Overlays (nvo3) > > 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
