Re: [sami] Trying to figure out where we are

"zhangyunfei" <zhangyunfei@chinamobile.com> Wed, 24 August 2011 06:04 UTC

Return-Path: <zhangyunfei@chinamobile.com>
X-Original-To: sami@ietfa.amsl.com
Delivered-To: sami@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5716B21F8B3F for <sami@ietfa.amsl.com>; Tue, 23 Aug 2011 23:04:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -95.733
X-Spam-Level:
X-Spam-Status: No, score=-95.733 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, CN_BODY_35=0.339, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPr6WugGQl5o for <sami@ietfa.amsl.com>; Tue, 23 Aug 2011 23:04:04 -0700 (PDT)
Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id BF42421F86DD for <sami@ietf.org>; Tue, 23 Aug 2011 23:04:03 -0700 (PDT)
Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 4A194A473; Wed, 24 Aug 2011 14:05:10 +0800 (CST)
Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 2D994A45B; Wed, 24 Aug 2011 14:05:10 +0800 (CST)
Received: from zyf-PC ([10.2.2.8]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2011082414042969-9592 ; Wed, 24 Aug 2011 14:04:29 +0800
Date: Wed, 24 Aug 2011 14:03:54 +0800
From: "zhangyunfei" <zhangyunfei@chinamobile.com>
To: "Yingjie Gu(yingjie)" <guyingjie@huawei.com>, "'Melinda Shore'" <melinda.shore@gmail.com>, "sami@ietf.org" <sami@ietf.org>
References: <CA77E180.13DD5%bschlies@cisco.com> <4E541EE7.1080605@gmail.com> <000c01cc6220$3b18fa70$b14aef50$@com>
Message-ID: <201108241403546051654@chinamobile.com>
X-mailer: Foxmail 6, 2, 103, 20 [cn]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-08-24 14:04:30, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-08-24 14:05:09, Serialize complete at 2011-08-24 14:05:09
Content-Type: multipart/alternative; boundary="=====003_Dragon584666206555_====="
X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18342.005
X-TM-AS-Result: No--27.489-7.0-31-10
X-imss-scan-details: No--27.489-7.0-31-10;No--27.489-7.0-31-10
X-TM-AS-User-Approved-Sender: No;No
X-TM-AS-User-Blocked-Sender: No
Subject: Re: [sami] Trying to figure out where we are
X-BeenThere: sami@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: State Migration <sami.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sami>, <mailto:sami-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sami>
List-Post: <mailto:sami@ietf.org>
List-Help: <mailto:sami-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sami>, <mailto:sami-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Aug 2011 06:04:05 -0000

I can share a use case here from our point of view in data center operation(will detail this in the upcoming draft as Yingjie said):
We are considering running different services (e.g., VoIP and streaming services) by VM in the same cluster withinn data center. We know different services show different user visiting behaviors. For example, in the midnight, there are few VoIP usage while there are still large amount of streaming usage( this is just an example, maybe not so accurate to fit with the reality). In such case, we'd like merge the existing VoIP and streaming services into fewer machines and cut down the machines running only few VoIP usage to reduce the power consumption.
In this senario, we need to consider how to migrate the existing VM states.

Looking forward to discussing more use cases in the mailing list.

BR
Yunfei




zhangyunfei
2011-08-24



发件人: Yingjie Gu(yingjie)
发送时间: 2011-08-24 13:41:04
收件人: 'Melinda Shore'; sami@ietf.org
抄送: 
主题: Re: [sami] Trying to figure out where we are

I  think  we  are  still  on  the  right  way  to  move  forward.  
We  need  to  hear  different  voice  so  that  we  can  know  what  go  to  people's  mind
when  they  see  "State  Migration".

For  now,  we  have  heard  different  opinions,  e.g.  
'state  migration  for  service  failover'  
'need  differentiate  requirements  for  Optimization-based  migration  and
restoration-based  migration',  
'layer  2  connectivity  over  L3  infrastructure',  
'think  about  IP  mobility  instead  of  state  migration'
'services  running  on  VM  will  impact  the  way  of  state  migration'  and  many
others.  
Sorry  that  I  don't  list  all  of  the  input.  
Though  not  all  of  them  will  finally  be  in  scope,  or  we  finally  fail  to
charter  a  workable  scope  in  IETF,  they  are  highly  valuable  input  for  scope
discussion.  
Thank  you  very  much.

Meanwhile,  I  also  try  to  ask  DC  provider  to  share  their  use  cases.  China
Telecom  and  China  Mobile,  who  are  also  looking  forward  to  become  DC
provider,  see  the  concrete  requirements  and  prepare  to  write  down  a  draft  to
introduce  the  use  cases  in  real  scenarios.  But  they  may  introduce  some  use
cases  to  mail  list  before  the  draft  is  completed.


Best  Regards
Gu  Yingjie


-----邮件原件-----
发件人:  sami-bounces@ietf.org  [mailto:sami-bounces@ietf.org]  代表  Melinda
Shore
发送时间:  2011年8月24日  乐乐5:43
收件人:  sami@ietf.org
主题:  [sami]  Trying  to  figure  out  where  we  are

As  the  discussion  has  progressed  it's  become  more-or-less  clear
that  there  might  possibly  perhaps  be  one  or  two  interesting
problems  here,  maybe,  although  the  people  pushing  for  the
chartering  of  something-or-other  (anything!)  to  do  with
data  centers  and  virtualization  seem  to  be  working  very  hard
indeed  to  obscure  anything  that  might  turn  out  to  have  some
value.

First,  there  appears  to  be  a  substantial  problem  related  to
moving  flow-associated  state  in  middleboxes  when  a  network
connection  (deliberately  keeping  "connection"  vague  for  the
moment)  fails  over.    This  has  certainly  come  up  in  the  context
of  multihomed  connections  in  sctp,  and  to  be  honest  I
haven't  followed  that  as  closely  as  I  should.    Still,  even
if  sctp  has  something  that  works  brilliantly  there  would  be
questions  about  applying  their  mechanism  in  a  different
context.

Second,  there  appears  to  be  another  substantial  problem,
this  one  related  to  how  to  handle  routing  and  network
state  when  a  VM  is  migrated  from  one  hypervisor  to  a
network-topographically-remote  hypervisor  when  both  are
on  the  same  layer  2  subnet  being  tunneled  over  a  layer
3  transport  (or  when  they're  not  on  the  same  subnet
at  all,  which  I  gather  is  considerably  less  common).

The  problem  here  is  that  it's  not  at  all  clear  that  there's
a  constituency  for  the  work.    I'm  not  talking  about  people
to  write  and  review  internet  drafts,  but  rather  companies
standing  up  and  saying  "We  want  this  problem  solved  and  we
think  it  should  be  solved  through  an  open  standards  process,"
and  data  centers/service  providers  standing  up  and  saying
"We  would  deploy  this."    Saying  that  you're  absolutely
certain  that  somebody  else  would  say  one  of  these  things
does  not  count.

It  would  be  unfortunate  if  the  IETF  were  to  sink  valuable
resources  into  another  effort  that  nobody  cares  about
other  than  people  looking  for  stuff  to  put  on  their  CV.
Is  there  an  audience  for  this  work?

Melinda
_______________________________________________
sami  mailing  list
sami@ietf.org
https://www.ietf.org/mailman/listinfo/sami

_______________________________________________
sami  mailing  list
sami@ietf.org
https://www.ietf.org/mailman/listinfo/sami