Re: [sami] Bringing new work into the IETF

[Melinda Shore <[e-mail]>]

On 08/19/2011 08:54 AM, So, Ning wrote:
 > [ ... ]
> Telecom service provider such as Verizon have significant business
 > with enterprises and government agencies.  One significant cloud
 > service business for that market in the foreseeable future is to
 > host overflow/expansion capacity for the enterprise/government
 > data centers.  That means the provider data centers will have to
 > be multi-tenant in nature with seamless inter-working with the
 > customer data centers.  There are quite a few (I cannot number them)
 > hypervisors out there in the market today, and the customers I know
 > have all of them (although usually each customer has one or two
 > hypervisors only).   Without standardization means the provider
 > data center has to have all of the hypervisors in each and every
 > data center in order to provide the services, and it also means
 > the server/network capacity in the provider data centers are
 > dedicated per Hypervisor without capacity sharing.

You guys are being asked for a technical discussion of what's
being proposed.  This is marketing.

I've mostly been appalled by how stuff (I initially typed "work,"
realized that that was not correct, and "stuff" is the only thing
I could come up with to describe what's under discussion) related to
clouds/data centers has been brought to the IETF.  There's never
been a clear statement of need for a specific piece of work, no
requirements, just fishing for something that someone might possibly
be able to get a publication out of.

The service migration stuff struck me as different, because for
better or worse there's a lot of flow-coupled state inside the
network, often related to security but sometimes related to
transport optimization, policy routing, etc.  How to move
that when live network sessions move is a real problem, and one
that's hard to solve.  Unfortunately you guys totally blew that
one out of the water when you reframed this as 1) moving VMs,
and 2) moving them within the same subnet.  If this is really,
truly, honestly what you want to do, you're going to start to
identify specific use cases and pieces of state that you think
will need to be transferred.  The only thing I can come up with
is address/port mappings in switches, and honestly that's not
very compelling.  This piece of email from Ning continues the
vagueness and really doesn't provide any information that might
help evaluate the work on its technical merit.

Melinda Shore