Re: [sami] Bringing new work into the IETF

[<[e-mail]>]

Hi Melinda,

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

I concur with that viewpoint.  The former "clouds" mailing list was
a time-sink that I had to pay attention to.

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

I also agree with this - there is an actual state migration problem
in here struggling to get out.

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

Ah, that I can help with ... ;-).

If one restricts a subnet to a physical L2 subnet, I think your
conclusion has a lot of merit (I reserve the right to quibble
later, but this message is about something else ...).  OTOH,
L2 connectivity is being provided over L3 infrastructure where
one may not expect it - examples of technologies that can do
that include GRE, L2TP and OTV. For OTV, see draft-hasmit-otv-03,
http://datatracker.ietf.org/doc/draft-hasmit-otv/ - that's
a good place to start as it contains a lot of worked-out details
for stretching L2 connectivity over L3 carrier infrastructure.

Live migration of a virtual machine across this sort of stretched
L2 connectivity is an important use case, because it's interesting
(yes, people really do want to do this), and the VM's L2 and L3
addresses can't change during the migration.  To a first
approximation, changing any of the VM's addresses makes the VM
migration non- transparent and disruptive courtesy of things
like ARP caches in other VMs.

One of the first things that is often done when stretching L2
subnets in this fashion is to distribute the L3 default gateway.
If one moves  a VM from San Jose, CA to San Francisco, CA (about 50mi),
one would prefer to hand off that VM's traffic to/from the (public)
Internet to an ISP in San Francisco, as opposed to hauling it back
to San Jose (the latter is colloquially referred to as "hairpinning").
If it helps to understand the scenario, assume that the AS that
encompasses the San Francisco and San Jose facilities (and the
connection between them) is multi-homed to different ISPs in
San Francisco and San Jose.

The good news is that routing protocols don't like hairpinning, and
will try to move the traffic to use the ISP connection in San Francisco.
The bad news is that there's a stateful inspection firewall on the
ISP connection in San Jose that contains things like TCP state.  Hence
moving the VM's TCP connections to San Francisco results in trying to
use the corresponding stateful inspection firewall on the ISP connection
in San Francisco, which has no state for those TCP connections, and
hence bit buckets all of their packets.  That would be bad, and the
result is that the middlebox (firewall) requires that the TCP connections
be hairpinned back to San Jose even though the routing protocols are
perfectly capable of optimizing that hairpinning away via the ISP in
San Francisco.

So, I'm confident that there's a real problem in here, but I also
strongly encourage re-reading Dave Harrington's message that started
this "Bringing new work ..." thread, because it outlines some important
practical considerations about whether the IETF can usefully solve this
problem.  To put those concerns bluntly:

	If we built "it", would anyone "come"?

Thanks,
--David

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Melinda Shore
> Sent: Friday, August 19, 2011 3:14 PM
> To: [e-mail]
> Subject: Re: [sami] Bringing new work into the IETF
> 
> 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
> _______________________________________________
> sami mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sami