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

My understanding of scope, based on Yongbing's scope suggestion, is as follows.

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. 

We need to be aware that, not all L2 subnet has enough bandwidth or shared storage or reasonable migration distance to make VM migration succeed. In our scope, I suggest we only consider the L2 subnet which can support successful VM migration, in which case we has the reason to consider state migration. Let's call it "qualified L2 subnet", which equals to Yongbing's " L2 subnet with good enough performance ". It should be the users of "State Migration mechanism" to judge whether their L2 subnet is suitable for VM Migration and whether they should adopt State Migration mechanism in their subnet.
Of course, even in a "qualified L2 subnet", VM migration can not be successful all the time. So, we also need to consider failure feedback mechanism.

State migration should be agnostic to applications/services running on migrating VM. Some applications/services are sensitive to time to different extents, some are not. However, no matter what kind of applications/services are running on the migrating VM, state migration must be completed or response Sate-Migration-Fail as soon as possible.

States Definition: States on network devices that are essential to service/application continuity. That means, if the state is missing, the running service/applications will be disrupted. Let's name this kind of state as Essential State, e.g. TCP states on Firewall. The other kind of state is states on network devices that may influence the accuracy of billing and accounting, or increase attack risks. At the very beginning, we can focus on Essential State.  We will figure out the Essential State on Firewall and Load Balancer, which I think is a good start. 

Please speak out your opinions on the above scope definition.

Two coming drafts: 
1) Use cases introduction: In this document, we will list use cases from providers, showing the real requirements they see for state migration, in addition to scenarios of VM Migration, services running on the VM and networking. 
2) Essential States Analysis: In this document, we will enumerate essential states on Firewall and Load Balancer and the common representation of the states.

We hope more people can contribute to these two drafts. Please let me know if you are interested in any or both of the drafts.

Thank you very much.

Best Regards
Gu Yingjie

-----邮件原件-----
发件人: Fan Yongbing [mailto:fanyb@gsta.com] 
发送时间: 2011年8月18日 乐乐11:30
收件人: Melinda Shore; Yingjie Gu(yingjie)
抄送: sami@ietf.org
主题: Re: [sami] Welcome to SAMI and something you may like to know.

Thanks for Melinda's suggestion.

A revision version about the scope:

 The work will cover state migration of associated middleboxes(for 
example,firewall,switch and so on)needed to
 maintain existing service as a VM is hot-migrated to another position in 
the same layer 2 subnet.

Fan Yongbing
China Telecom

樊勇兵  博士
--------------------------------------------------
中国电信股份有限公司广州研究院
数据通信研究部
Mobile：13316090609（主用）；13922438897（辅用）
Tel：020-38639121；PHS：020-88338121
Fax：020-38639487
--------------------------------------------------

----- Original Message ----- 
From: "Melinda Shore" <melinda.shore@gmail.com>
To: "Yingjie Gu(yingjie)" <guyingjie@huawei.com>
Cc: <sami@ietf.org>
Sent: Thursday, August 18, 2011 8:51 AM
Subject: Re: [sami] Welcome to SAMI and something you may like to know.

> On 08/17/2011 12:58 AM, Yingjie Gu(yingjie) wrote:
>> So,pehhaps we can define the scope as such:A layer 2 subnet with good 
>> enough
>> performance which makes the hot migration successful."
>
> I think it would be worthwhile, should this work go forward, to
> describe what happens (or what should happen) if the failover
> is unsuccessful - things like at what point state transfer happens.
> It seems to me that there's a pretty clear decision point around
> whether or not you wait until the failover is complete and
> successful (can you know if it's successful before it's complete?)
> before transferring middlebox state, and I definitely would
> not like to see that dismissed as out-of-scope before any work
> is even chartered.
>
> I'd also stay away from "good enough performance" - not really
> sure what that means in a technical context.
>
> Scope would be something along the lines of:
>
>    The work will cover transfer of associated middlebox state [and
>    i'd probably enumerate examples - probably includes firewall
>    pinholes, probably does not include layer 3 routing] needed to
>    maintain existing network flows as a network services fail
>    over to a hot standby.  Doing the hokey-pokey is out-of-scope.
>
> That needs a lot of work and it would need definition of terms
> like "hot standby" and "middlebox," etc., but it describes what
> will be included in the work and what will not.
>
> Melinda
> _______________________________________________
> sami mailing list
> sami@ietf.org
> https://www.ietf.org/mailman/listinfo/sami 