RE: [nvo3] WG Review: Network Virtualization Overlays (nvo3) - 25-Apr-2012 update

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]