OK, so the Nvo3 charter is generic and has carefully not selected a solution so it does not mention any of the competing technologies including MPLS/Vxlan/NVGRE etc. all are possibly in scope as are standards that are not in the IETF.
Sent from my iPad On May 1, 2012, at 11:57 AM, "Stewart Bryant" <[email protected]> wrote: > Tina, > > Why would STT be in the charter? > > The work programme is > > Problem Statement > Framework document > Control plane requirements document > Data plane requirements document > Operational Requirements > Gap Analysis > > There is no mention of any particular encapsulation. > > In the particular case of STT, the proponents of that > protocol should note that in addition to work that > they may need to do in NVO3, they will need to > work with the transport area to get their acceptance > that their proposal is not harmful to TCP. Failure > to reach that agreement would be a showstopper. > > Stewart > > > > > > On 01/05/2012 18:01, Tina TSOU wrote: >> 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 > > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
