Re: [sami] Welcome to SAMI and something you may like to know.

[Warren Kumari <[e-mail]>]

On Aug 19, 2011, at 9:45 AM, Juergen Schoenwaelder wrote:

> On Thu, Aug 18, 2011 at 08:57:15PM +0800, Yingjie Gu(yingjie) wrote:
> 
>> The scope of State migration, i.e. the scope of VM migration, is
>> within a Layer 2 subnet, which guarantees that VM's IP address can
>> keep unchanged. Though some technologies can enable VM migrates
>> between different subnets and keep the IP address unchanged, most
>> requirements for VM migration is within the same L2 subnet for now.
> 
> Those setups that I have seen (but I have not seen too many and
> usually smaller onces) have a single L2 network _behind_ firewalls and
> load balancers and hence there is almost no state to migrate when a VM
> moves. It appears to me that people design their networks to make
> migration feasible (by making it a single L2 network) instead of
> trying to migrate across arbitrary network topologies.

I was unable to find a better place in this thread to put this, so I'm somewhat arbitrarily putting it here…

I have a draft (that seriously needs some revisioning) that outlines, at a VERY high level how VM Mobility can be implemented over a L3 network (tl;dr summary -- you resolver the link-layer address via a directory server and then encapsulate the traffic between the hypervisors)

This isn't the venue to discuss this (it's vaguely being discussed over on ARMD, although it's not really intended as input to ARMD), I just wanted to bring it to y'alls attention (and muddy the water somewhat):

> A new version of I-D, draft-wkumari-dcops-l3-vmmobility-00.txt has been successfully submitted by Warren Kumari and posted to the IETF repository.
> 
> Filename:	 draft-wkumari-dcops-l3-vmmobility
> Revision:	 00
> Title:		 Virtual Machine mobility in L3 Networks.
> Creation date:	 2011-08-11
> WG ID:		 Individual Submission
> Number of pages: 8
> 
> Abstract:
>  This document outlines how Virtual Machine mobility can be
>  accomplished in datacenter networks that are based on L3
>  technologies.  It is not really intended to solve (or fully define)
>  the problem, but rather to outline it at a very high level to
>  determine if standardization within the IETF makes sense.
> 
> 
> 
> 
> The IETF Secretariat


This will probably not help the scope discussions :-P

W


> 
> For me, the problem becomes interesting for the IETF when someone
> wants to migrate a VM from one IP subnet to another IP subnet. In that
> case, we have some form of IP mobility (since the IP connectivity
> changes) and depending on the nature of the applications running on
> the VMs, there might be some period in which some tunneling is needed
> (because the state associated with existing transport connections in
> middleboxes is likely harder to migrate correctly than doing some
> mobile IP like tunneling). Some people said in Quebec that we can
> ignore the IP addressing issues and just focus on the state migration
> but I feel that is wrong because the way you deal with the mobility at
> the IP level will have impact on how much state needs migration or
> whether any operational state needs to be migrated at all (and my
> personal preference would be to design the network to avoid the need
> for state migration - that is to produce guidelines or best practices
> to follow rather than producing more special purpose standards).
> 
> To what extend this is a real-world problem and to what extend vendors
> of middle-boxes are interested to implement a standard in this area, I
> do not know. But a good indication of interest is usually that some of
> those vendors actively participate in the specification of a solution.
> 
> As stated in Quebec, to me this still sounds more like a research
> effort than a standardization effort but I am happy to get convinced
> otherwise.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>
> _______________________________________________
> sami mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sami
>