Re: [sami] A new draft on state migration use cases is submitted.

"Yingjie Gu(yingjie)" <guyingjie@huawei.com> Wed, 12 October 2011 09:22 UTC

Return-Path: <guyingjie@huawei.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 1502421F886A for <sami@ietfa.amsl.com>; Wed, 12 Oct 2011 02:22:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.022
X-Spam-Level:
X-Spam-Status: No, score=-105.022 tagged_above=-999 required=5 tests=[AWL=1.577, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 zgSsmFQIhc6l for <sami@ietfa.amsl.com>; Wed, 12 Oct 2011 02:22:36 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0962721F877F for <sami@ietf.org>; Wed, 12 Oct 2011 02:22:36 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSY00J3K4MZM0@szxga04-in.huawei.com> for sami@ietf.org; Wed, 12 Oct 2011 17:20:59 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSY00GK44MYQM@szxga04-in.huawei.com> for sami@ietf.org; Wed, 12 Oct 2011 17:20:59 +0800 (CST)
Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEE70615; Wed, 12 Oct 2011 17:20:30 +0800
Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 12 Oct 2011 17:20:23 +0800
Received: from g00107907 (10.138.41.134) by szxeml411-hub.china.huawei.com (10.82.67.138) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 12 Oct 2011 17:20:21 +0800
Date: Wed, 12 Oct 2011 17:22:39 +0800
From: "Yingjie Gu(yingjie)" <guyingjie@huawei.com>
In-reply-to: <4E95368D.7000406@gmail.com>
X-Originating-IP: [10.138.41.134]
To: 'Melinda Shore' <melinda.shore@gmail.com>, 'Juergen Schoenwaelder' <j.schoenwaelder@jacobs-university.de>
Message-id: <005e01cc88c0$7d3315a0$779940e0$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: text/plain; charset="UTF-8"
Content-language: zh-cn
Content-transfer-encoding: quoted-printable
Thread-index: AcyIqfgWaK0wcm+jSG+IvfzNac+anwAAX1kw
X-CFilter-Loop: Reflected
References: <CAB+71L3btz_h8Lkm9jW-WHUeS4=K-Jq-r9mmX94=NdHiepkJ-Q@mail.gmail.com> <2CE4AB2F9CD06543A3F2B0FE76661E12125C8295@fzex.ruijie.com.cn> <20111009160138.GB99820@elstar.local> <000601cc86eb$829967f0$87cc37d0$@com> <2CE4AB2F9CD06543A3F2B0FE76661E12125C85F9@fzex.ruijie.com.cn> <4A95BA014132FF49AE685FAB4B9F17F61209F3D1@dfweml506-mbx> <169529F73649BF469B4F61792955CD5C125E230D@fzex.ruijie.com.cn> <20111011075143.GB9466@elstar.local> <CAB+71L1Ltu4TMTwejEzBDPuKcC+_cwF5YqV1fJc_o0t3WhW2gg@mail.gmail.com> <003c01cc888a$a0a230b0$e1e69210$@com> <20111012061738.GB13515@elstar.local> <4E95368D.7000406@gmail.com>
Cc: 'A tao' <yangjingtao@gmail.com>, "'\"'卓志强(研七 福州)'\"'" <zhuozq@ruijie.com.cn>, "'\"'刘茗(研六 福州)'\"'" <lium@ruijie.com.cn>, 'Linda Dunbar' <linda.dunbar@huawei.com>, sami@ietf.org
Subject: Re: [sami] A new draft on state migration use cases is submitted.
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, 12 Oct 2011 09:22:37 -0000

Thank you Melinda. You have mentioned a very interesting area, that is Mobile IP.
At last IETF meeting, I prepared a picture of flow of state migration mime UMTS Serving RNC Handoff. I believe we can learn from UMTS Serving RNC Handoff when we try to resolve this problem.

About NAT, we removed this issue from the latest use case draft, that's a decision based on our investigating. The draft-gu-opsawg-policies-migration is an old version of problem description, in which some of the use cases are not applicable. I plan to ask authors to merge problem statement and use case drafts to make a consistent description of the problem.

Sorry for my bad English, by " they won't let it stew quietly at the back of the stove for a little while." do you mean the advocates should stay a little quiet on the mail list? If that's what you mean, I feel confused. We do a lot of work to investigate and present it to persons, and reply to questions on the problem. When someone raise a question on the mail list, isn't he looking forward to a response? Well, I am not very familiar of how to make new work proposal. My understanding of a advocate of a proposal in IETF should try his best to investigate problems and invite experts to join discussion. I would hear more suggestions on how to manage the mail list, you can send private mails to me. 

Thanks.

Best Regards
Gu Yingjie


-----邮件原件-----
发件人: Melinda Shore [mailto:melinda.shore@gmail.com] 
发送时间: 2011年10月12日 乐乐14:41
收件人: Juergen Schoenwaelder
抄送: Yingjie Gu(yingjie); 'A tao'; "'卓志强(研七 福州)'"; sami@ietf.org; "'刘茗(研六 福州)'"; 'Linda Dunbar'
主题: Re: [sami] 答复: A new draft on state migration use cases is submitted.

On 10/11/11 10:17 PM, Juergen Schoenwaelder wrote:
> My understanding is that today neither hypervisors nor 'switches'
> support the state live migration you want.

There's been some work done around a more static scenario - SCTP and
NAT - although I'm not sure what state it's in.  Probably worth
checking out whether anything's been done with regard to this in
mobile IP.

I will say, based on the midcom architectural work and the follow-on
stuff with route-coupled signaling protocols that the topology-related
problems with moving flow-coupled state around the network is
exceptionally difficult - sufficiently difficult, I think, that
it really is a good idea to avoid it when possible.

I still think there's a core of an interesting idea here and I'm
pretty frustrated that on the one hand its advocates have not been
able to make a stronger case and that on the other hand they won't
let it stew quietly at the back of the stove for a little while.
In particular, in a crunchy-on-the-outside network security model
there's state associated with firewalling and with NAT *in* *network*
*devices* that will probably need to move, but the authors haven't
presented a case for that, the service providers are apparently not
asking for that, and it seems to have drifted out of the picture.
Instead, we're getting some fairly confusing (and unsupported)
assertions about performance and DHCP sniffing and all sorts of
things that mostly leave me doubting what I'm reading (they're
not helped much by the early history of the cloud/datacenter
advocacy at the IETF).

If you can forgive a badly-mixed metaphor I think this particular
stewpot has run out of track.

Melinda