+1. Linda > -----Original Message----- > From: nvo3-bounces@xxxxxxxx [mailto:nvo3-bounces@xxxxxxxx] On Behalf Of > Alan Kavanagh > Sent: Thursday, April 26, 2012 1:55 PM > To: Joe Pelissier (jopeliss); nvo3@xxxxxxxx; iesg@xxxxxxxx > Cc: IETF Discussion > Subject: Re: [nvo3] WG Review: Network Virtualization Overlays (nvo3) - > 25-Apr-2012 update > > +1 Lets not re-invent the wheel if not needed. > > Alan > > -----Original Message----- > From: nvo3-bounces@xxxxxxxx [mailto:nvo3-bounces@xxxxxxxx] On Behalf Of > Joe Pelissier (jopeliss) > Sent: April-25-12 7:35 PM > To: nvo3@xxxxxxxx; iesg@xxxxxxxx > Cc: IETF Discussion > Subject: Re: [nvo3] WG Review: Network Virtualization Overlays (nvo3) - > 25-Apr-2012 update > > I too am uncomfortable with the wording regarding the IETF protocols. > It seems that we should be striving to choose the best technical > solution regardless of whether its an IETF protocol or that from > another SDO. This can, and should, be covered as part of the gap > analysis. > Also, we should give preference to using existing suitable protocols > (IETF or from other SDOs) over development of new protocols. > > Regards, > Joe Pelissier > > > -----Original Message----- > From: nvo3-bounces@xxxxxxxx [mailto:nvo3-bounces@xxxxxxxx] On Behalf Of > Pat Thaler > Sent: Wednesday, April 25, 2012 5:55 PM > To: Stewart Bryant (stbryant); nvo3@xxxxxxxx; iesg@xxxxxxxx > Cc: IETF Discussion > Subject: Re: [nvo3] WG Review: Network Virtualization Overlays (nvo3) - > 25-Apr-2012 update > > Stewart, > > The charter is looking pretty good. I'd like to get on to the next > phase, but not with this text: > 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 a non- > IETF protocol. > > There are two issues with this: > Is now the right time to be defining the boundaries on what we might > request being chartered next? Framework, requirements and gap analysis > drafts are still to be written. If we get to the end and find we need > something other than or in addition to a data plan encapsulation or > control plane protocol, would we not request it to be chartered? Surely > once the work is done. > > Secondly, as this text got rewritten, it gives a preference for IETF > protocols over other protocols even if they are standards. There is a > part of the work where an IEEE 802.1 protocol, VDP, may turn out to be > suitable. Obviously any IETF protocols that are also suitable should be > considered but not to the exclusion of consideration for an IEEE > protocol. > > Presumably there is always a preference for using existing protocol if > suitable rather than inventing new. It seems unnecessary to state that > - when the time comes, we will debate what is suitable anyway. > > Therefore, at least " 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 a non-IETF protocol." should be deleted. > > Regards, > Pat > > -----Original Message----- > From: nvo3-bounces@xxxxxxxx [mailto:nvo3-bounces@xxxxxxxx] On Behalf Of > Stewart Bryant > Sent: Wednesday, April 25, 2012 2:39 PM > To: nvo3@xxxxxxxx; iesg@xxxxxxxx > Cc: IETF Discussion > Subject: [nvo3] WG Review: Network Virtualization Overlays (nvo3) - > 25-Apr-2012 update > > This version of the NVO3 charter reflects the discussions on the list > and comments received as of this afternoon. > > I propose to take this to the IESG for their second review tomorrow. > > Stewart > > ====== > > NVO3: Network Virtualization Over Layer 3 > > Chairs - TBD > Area - Routing > Area Director - Stewart Bryant > INT Area Adviser - TBD > 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). 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 > nvo3@xxxxxxxx > https://www.ietf.org/mailman/listinfo/nvo3 > > > _______________________________________________ > nvo3 mailing list > nvo3@xxxxxxxx > https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ > nvo3 mailing list > nvo3@xxxxxxxx > https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ > nvo3 mailing list > nvo3@xxxxxxxx > https://www.ietf.org/mailman/listinfo/nvo3