+1 Lets not re-invent the wheel if not needed.
Alan
-----Original Message-----
From: nvo3-bounces(_at_)ietf(_dot_)org
[mailto:nvo3-bounces(_at_)ietf(_dot_)org] On Behalf Of Joe Pelissier (jopeliss)
Sent: April-25-12 7:35 PM
To: nvo3(_at_)ietf(_dot_)org; iesg(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
[mailto:nvo3-bounces(_at_)ietf(_dot_)org] On Behalf Of Pat Thaler
Sent: Wednesday, April 25, 2012 5:55 PM
To: Stewart Bryant (stbryant); nvo3(_at_)ietf(_dot_)org;
iesg(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
[mailto:nvo3-bounces(_at_)ietf(_dot_)org] On Behalf Of Stewart Bryant
Sent: Wednesday, April 25, 2012 2:39 PM
To: nvo3(_at_)ietf(_dot_)org; iesg(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
nvo3(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
nvo3(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/nvo3