Subject: Questions: WG Review: Network Virtualization Overlays (nvo3) - 23-Apr-2012 update

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 24 Apr 2012 21:04:55 +0100

Hi,

A couple of questions of some substance below.

> 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). Two key requirements needed
> to support multi-tenancy are traffic isolation, so that a tenant's
> traffic is not visible to any other tenant, and address independence,
> so that one tenant's addressing does not collide with other tenants
> addressing schemes or with addresses used within the data center itself.
> Another key requirement is to 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 100K 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.
> 
> 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

I know we have been dancing around this and there is a lot of paranoia. It is
clear that we mean that no IETF technology will be excluded from consideration a
priori. This may be sensitive because the PWE3 charter (which had to handle a
similar question) explicitly called out IP and MPLS. I can't think of a better
way of saying what the text says other than "network layer" but perhaps, for the
avoidance of doubt, Stewart could put an email in the archive that says "I
confirm that the phrase 'network layer' in the context of the NVO3 charter does
not exclude MPLS." Then (hopefully) we can all move along and do the real work
:-)

> that rely on the underlying layer 2 technology (e.g., VLANs).
> The NVO3 WG will determine which types of  service 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, and provide the network functions
> required for the migration of VMs within the network in a
> sub-second timeframe.

This has been discussed a bit, but I still can't believe that it won't cause
contention down the line. The term "migration" will mean different things to
different people and some will expect it to mean the picking up of one active
operational environment and its transportation to run in a different place. We
need to be clear whether we mean simply that the "re-registration" of a VM at a
different location and the associated "convergence" of the network is intended
to be sub-second, or whether it is the whole transportation of the VM.

I don't have an immediate suggestion for wording around this other than to say
that the bald word "migration" is not enough.

> Based on this framework, the NVO3 WG will develop requirements for both
> control plane protocol(s) and data plane encapsulation format(s), 

I find this rather clumsy and suggest:

Based on this framework, the NVO3 WG will develop requirements for control plane
protocols and data plane encapsulation formats, 

> 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.

I can see how this might give rise to requirements and architectural work. I am
not clear what "determine if any specific work is needed" because that may
substantially depend on which solutions have been selected. Perhaps replacement
text...

The NVO3 WG will investigate the interconnection of the DCVPNs and their tenants
with non-NVO3 IP networks, and will document any additional requirements and
architectural functions.

> The NVO3 WG will write the following informational RFCs, which
> must be substantially complete before rechartering can be
> considered:

"substantially complete" is sufficiently subjective to risk a riot at some point
in the future!
Can we be more precise with some well-known process step such as WG last call or
publication request.
I do not believe that rechartering at that point would take more than a couple
of weeks, so it is not as though the WG will grind to a halt for a season.

>      Problem Statement
>      Framework document
>      Control plane requirements document
>      Data plane requirements document
>      Operational Requirements
>      Gap Analysis

I see how the three requirements documents have been arrived at from the text in
the previous paragraphs. Where does Security fit in? Is it distributed amongst
the three documents? If so, why were operational requirements not similarly
distributed?

> 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.

s/a non-IETF protocol/non-IETF protocols/

[snip]

Thanks,
Adrian

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 24 Apr 2012 22:28:43 +0100

> not exclude MPLS." Then (hopefully) we can all move along and do the real work

For the avoidance of doubt, in the context of the NVO3 charter, the term
'network layer' does not exclude MPLS.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 24 Apr 2012 22:33:27 +0100

> that the bald word "migration" is not enough.
I think that discussion on the list has clarified this to mean that network
will not be a gate to subsecond migration of the VM, but the process
of migrating the VM is outside the scope of the charter.

Perhaps we can say:

"This will support the delivery
of packets to the destination VM, and provide the network functions
required to support the migration of VMs within the network in a
sub-second timeframe."

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 24 Apr 2012 22:33:27 +0100

Perhaps we can say:

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 24 Apr 2012 22:47:31 +0100

>>       Data plane requirements document
Perhaps we should set WGLC as the marker for recharter to be considered.
> the three documents? If so, why were operational requirements not similarly
It's always difficult to design the document structure during chartering.

I think that we need to give the WG the flexibility to add documents that
are within charter, or to merge documents as they think fit when they
analyze the work in detail.

> s/a non-IETF protocol/non-IETF protocols/

I think that we should accept all nit level proposals.

Stewart

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 25 Apr 2012 11:09:27 +0100

Hi Stewart,

> > Can we be more precise with some well-known process step such as WG last
> > call or publication request.

That would work for me.

A

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 25 Apr 2012 11:24:55 +0100

Hi,

> > need to be clear whether we mean simply that the "re-registration" of a VM
at
> > a different location and the associated "convergence" of the network is
> > intended to be sub-second, or whether it is the whole transportation of the
> > VM.
> >

This is getting close, and I appreciate the intent.
And I understand this is getting wrapped around the axle of requirements that
have not yet been written.
What we want to do is include a description of the migration rate and speed of
VMs. This is useful material like the scaling parameters.
What we need to do is say what the WG works on. 
But I am not clear what a "network function" is in this context, or how such a
function "supports the migration" of VMs without actually being involved in the
migration.

On reflection, we can also do something to improve the sentence because the two
halves are not really related.

How about solving this with two changes...

OLD

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 100K 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.

NEW

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 100K 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.

END

...and...

OLD

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, and provide the 
network functions required for the migration of VMs within the
network in a sub-second timeframe.

NEW

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.

END

Thanks,
Adrian

PS To Thomas who thinks we are needlessly wordsmithing...
When I see the spectre of fist-fights about the outcome of this work, I prefer
to spend one or two weeks extra at this stage nailing down all loose corners
rather than several months in ICU sometime in the future.