Re: [sami] Bringing new work into the IETF
"Yingjie Gu(yingjie)" <guyingjie@huawei.com> Fri, 19 August 2011 01:15 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 98AE521F8593 for <sami@ietfa.amsl.com>; Thu, 18 Aug 2011 18:15:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.678
X-Spam-Level:
X-Spam-Status: No, score=-101.678 tagged_above=-999 required=5 tests=[AWL=-0.869, BAYES_00=-2.599, CN_BODY_35=0.339, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_84=0.6, MIME_CHARSET_FARAWAY=2.45, 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 1dfd8hPHB2sB for <sami@ietfa.amsl.com>; Thu, 18 Aug 2011 18:15:37 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id D26A321F8571 for <sami@ietf.org>; Thu, 18 Aug 2011 18:15:36 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ500J63I7I8G@szxga03-in.huawei.com> for sami@ietf.org; Fri, 19 Aug 2011 09:16:30 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ5007KDI7HMQ@szxga03-in.huawei.com> for sami@ietf.org; Fri, 19 Aug 2011 09:16:30 +0800 (CST)
Received: from 172.24.2.119 (EHLO szxeml202-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADG05601; Fri, 19 Aug 2011 09:16:29 +0800 (CST)
Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 19 Aug 2011 09:16:17 +0800
Received: from g00107907 (10.138.41.134) by szxeml410-hub.china.huawei.com (10.82.67.137) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 19 Aug 2011 09:16:29 +0800
Date: Fri, 19 Aug 2011 09:16:56 +0800
From: "Yingjie Gu(yingjie)" <guyingjie@huawei.com>
In-reply-to: <CDDE62FF82604D09B92836C30BE7AD07@davidPC>
X-Originating-IP: [10.138.41.134]
To: 'David Harrington' <ietfdbh@comcast.net>, sami@ietf.org
Message-id: <003501cc5e0d$b1701440$14503cc0$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: multipart/alternative; boundary="Boundary_(ID_1C3F/OGg1E2ObW/5y8cEZQ)"
Content-language: zh-cn
Thread-index: AcxX7HVRuZrPxcYMSPmyPWkIvb/VTAASCu2AAAMDlYAABBPOgAEaloXwAAmfeMAAJ6eRMAAMDvuQABY1DjA=
X-CFilter-Loop: Reflected
References: <004c01cc57ec$7f602ed0$7e208c70$@com> <20110811074034.GA12533@elstar.local> <005701cc5806$03cd8370$0b688a50$@com> <4A95BA014132FF49AE685FAB4B9F17F605189C80@dfweml504-mbx.china.huawei.com> <006001cc5cbb$de6c48e0$9b44daa0$@com> <6665BC1FEA04AB47B1F75FA641C43BC08146326D@FHDP1LUMXC7V41.us.one.verizon.com> <004b01cc5d9e$c7015130$5503f390$@com> <CDDE62FF82604D09B92836C30BE7AD07@davidPC>
Subject: Re: [sami] Bringing new work into the IETF
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: Fri, 19 Aug 2011 01:15:39 -0000
Hi David, Thank you so much for your attention and such detail suggestion. I really appreciate it. I believe there are some misunderstanding. But I appreciate the chance to clarify our target. The intention of State Migration is not to standardize VM Migration. The focus is how to migrate state on network devices when VM is migrating, just like the name ‘State Migration’ means. How to do virtualization and how to migrate the VM is out of the scope. You can do VM migration either by a standardized way(I am not sure there is a standard way) or proprietary way. It doesn’t matter. The problem is the state associated with the VM on old network devices, e.g. Hardware Firewall, Load Balancer or switches, also need to be correctly presented on new network devices at the new location. Otherwise the running service will have to be stopped. The state could be TCP states on Firewall or Session states on Load Balancer. When migrating state, one may find that he has to migrate state between devices designed by different vendors. That is why we need a standardized way to do this. Currently we are try to narrow down the scope: e.g. do we consider state migration within a L2 subnet, or also consider state migration between L2 subnets. We will also figure our the state that is essential to service continuity after VM Migration. As conclusion, we are not working on VM Migration or Virtualization. We are not trying to standardize virtualization, VM migration, TCP/IP stacks, storage, etc. Neither does virtual host configuration in the scope. Also I would like to know whether there is confusing text in the mail list description or in my ever reply to the mail list or in my draft that make people feel that we are working on VM Migration. If there is, I will definitely revise them at once. Again, thank you for your detail suggestion. Best Regards Gu Yingjie -----邮件原件----- 发件人: David Harrington [mailto:ietfdbh@comcast.net] 发送时间: 2011年8月18日 乐乐23:25 收件人: 'Yingjie Gu(yingjie)'; sami@ietf.org 主题: Bringing new work into the IETF Hi Yingjie, I trimmed the CC: list to the sami mailing list. Those who are interested in the sami discussion can join the sami list and find this discussion in the sami archive. So far, I think your proposal is not being accepted by the IETF because it is too general and too abstract. You are still trying to figure out what problem you want to solve. To make VM migration standardization a viable problem to work on, you probably need to get vendors and operators to all agree on complete standardization for their various technologies - virtualization, TCP/IP stacks, network management protocols, and so on. I think you are very unlikely to ever achieve that because vendors want to continue to enhance their solutions versus their competitors. Standardization is not appropriate to solve every problem. Most enterprises/providers will choose a specific virtualization solution, such as VMware. How VM migration is done depends a great deal on the virtualization solution in use. Hypervisors have not been standardized because the companies that provide virtualization solutions gain competitive advantage from their hypervisor capabilities. They don't necessarily want to standardize their hypervisors across vendors. Most enterprises/providers will choose a specific storage solution, such as EMC or NetApp. How VM migration is done depends a great deal on the storage solution in use. Storage devices usually use standards, but have not been completely standardized because the companies that provide storage solutions gain competitive advantage from their storage solution enhancements. They don't want to totally standardize storage across vendors. Most enterprises/providers will choose specific equipment vendors to deploy in their networks. Those choices often have to do with the proprietary enhancements offered by different vendors. The vendors have no desire to all offer identical products and identical features. How VM migration is done depends a great deal on the networking equipment in use. IP/TCP stacks have not been totally standardized because the companies that provide networking equipment gain competitive advantage from their equipment's enhanced capabilities. They don't want to totally standardize their equipment across vendors. Most enterprises/providers will choose specific equipment to deploy in their networks. Those choices often have to do with the proprietary solutions to manage the chosen equipment. The vendors have no desire to all offer identical management features. How a migration is done depends a great deal on the networking management tools in use. CLIs and proprietary MIB modules and other management interfaces have not been totally standardized because the companies that provide these tools gain competitive advantage from their management products' enhanced capabilities. They don't want to totally standardize their management interfaces. To standardize VM migration across all the VM implementations, the TCP/IP implementations, the storage implementations, the routing implementations, the security implementations, the application implementations, the network management implementations, and the enterprise-specific deployment choices, is like "boiling the ocean". Not a very achieveable goal. The IETF does **engineering**. You would do much better to focus your energy on a **small** problem, solvable by standardization, that can be turned into an engineering project appropriate to the IETF. For example, you might focus on developing a standard DHCP attribute or a standard netconf/YANG module for some aspect of virtual host configuration that could be reasonably standardized across virtualization platforms and equipment vendors. Each standardization of a small piece of Internet-related VM configuration could help standardize VM migration in the long run. And that would be engineering work appropriate to the IETF. David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) > -----Original Message----- > From: Yingjie Gu(yingjie) [mailto:guyingjie@huawei.com] > Sent: Thursday, August 18, 2011 8:03 AM > To: 'So, Ning'; 'Linda Dunbar'; 'Juergen Schoenwaelder' > Cc: 'Wesley Eddy'; 'Romascanu, Dan (Dan)'; > rbonica@juniper.net; 'David Harrington'; sami@ietf.org > Subject: Re: [sami] Welcome to SAMI and something you may > like to know. > > Ning, > > When we talked at Quebec, I remembered that you have > impressive understanding on VM migration requirements > in/between subnets. Hope you can share your use cases from > provider's perspective. > I have talked with two providers in detail, and they both see > the strong requirements for state migration as VM migrates. > Perhaps we need to document provider's requirements for > people's reference. I am working with providers on this > document to introduce use cases. > > > > Best Regards > Gu Yingjie > > > -----邮件原件----- > 发件人: So, Ning [mailto:ning.so@verizon.com] > 发送时间: 2011年8月17日 乐乐21:59 > 收件人: Yingjie Gu(yingjie); 'Linda Dunbar'; 'Juergen Schoenwaelder' > 抄送: 'Wesley Eddy'; 'Romascanu, Dan (Dan)'; > rbonica@juniper.net; 'David Harrington'; sami@ietf.org > 主题: RE: [sami] Welcome to SAMI and something you may like to know. > > Yingjie, > > You might want to consider limiting the scope to problem > definition and provider requirements collection first. I > know a lot of work has gone into documenting what is > available today. However, the provider requirements in this > area is still rather thin. For example, the requirements > for optimization-based migration can be quite different from > failure restoration-based migration. The type of services > the VMs are supporting can also impact the migration > requirements, thus impacting the solutions. Defining > different types of VM migration and the associated > requirements should be a higher priority, in my opinion. > > > Best regards, > > Ning So > Verizon Corporate Technology > (office) 972-729-7905 > (Cell) 972-955-0914 > > > -----Original Message----- > From: sami-bounces@ietf.org [mailto:sami-bounces@ietf.org] On > Behalf Of Yingjie Gu(yingjie) > Sent: Wednesday, August 17, 2011 3:59 AM > To: 'Linda Dunbar'; 'Juergen Schoenwaelder' > Cc: 'Wesley Eddy'; 'Romascanu, Dan (Dan)'; > rbonica@juniper.net; 'David Harrington'; sami@ietf.org > Subject: Re: [sami] Welcome to SAMI and something you may > like to know. > > The following is a scope suggested by Dr. Fan. > > " According to the current implementation,VM migration is > scoped in a layer > 2 network with shared storage.Key factors that decide whether > hot migration is successful includes,from the network's side, > bandwith and delay.Even the migration happens between two > sites,it may succeed if the bandwidth is wide enough and the > delay is small enough. > > So,pehhaps we can define the scope as such:A layer 2 subnet > with good enough performance which makes the hot migration > successful." > > What is your opinion on this scope? > > Best Regards > Gu Yingjie > > -----邮件原件----- > 发件人: Linda Dunbar [mailto:linda.dunbar@huawei.com] > 发送时间: 2011年8月12日 乐乐0:14 > 收件人: Yingjie Gu(yingjie); 'Juergen Schoenwaelder' > 抄送: 'Wesley Eddy'; 'Romascanu, Dan (Dan)'; sami@ietf.org; > 'David Harrington'; rbonica@juniper.net > 主题: RE: [sami] Welcome to SAMI and something you may like to know. > > I thought at the barBOF that the next step is to identify > some use cases. It will be very beneficial to accelerate the > progress by identifying some states (or conditions) which > today's firewall or security devices can use to continue the > proper function. > > > Linda > > > -----Original Message----- > > From: sami-bounces@ietf.org [mailto:sami-bounces@ietf.org] > On Behalf > > Of Yingjie Gu(yingjie) > > Sent: Thursday, August 11, 2011 4:07 AM > > To: 'Juergen Schoenwaelder' > > Cc: 'Wesley Eddy'; 'Romascanu, Dan (Dan)'; sami@ietf.org; 'David > > Harrington'; rbonica@juniper.net > > Subject: Re: [sami] Welcome to SAMI and something you may > like to know. > > > > Hi Juergen, > > > > I accept your suggestion. I will be more careful with my words. > > > > We don't need yet more high level discussion on whether > it's useful or > > not. > > > > Let's first figure out the context: scope, use cases and so on. > > > > > > Best Regards > > Gu Yingjie > > > > -----邮件原件----- > > 发件人: sami-bounces@ietf.org [mailto:sami-bounces@ietf.org] 代表 > > Juergen > > Schoenwaelder > > 发送时间: 2011年8月11日 乐乐15:41 > > 收件人: Yingjie Gu(yingjie) > > 抄送: 'Wesley Eddy'; 'Romascanu, Dan (Dan)'; > rbonica@juniper.net; 'David > > Harrington'; sami@ietf.org > > 主题: Re: [sami] Welcome to SAMI and something you may like to know. > > > > On Thu, Aug 11, 2011 at 02:04:14PM +0800, Yingjie Gu(yingjie) wrote: > > > > > Attendees agree that state migration is useful. What we need to do > > next is > > > to narrow down the scope, e.g. state migration within the same > > > Administration domain or between domains, and collect the > use cases > > in > > that > > > scope. Then we need to figure out what kind of state need to be > > migrated > > in > > > the narrow scope, what's the common representation of the states, > > > and, > > if > > we > > > go that far, the potential solutions for state migration. > > > > For me, it is crucial to first define the scope before I can agree > > whether state migration is a useful concept or not. > Depending on the > > timing and the addressing/routing issues, other mechanisms might be > > more appropriate. > > > > Bottom line: Be careful with general statements like > "Attendees agree > > that state migration is useful." before we even agree on > the context. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > _______________________________________________ > > 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 > > _______________________________________________ > sami mailing list > sami@ietf.org > https://www.ietf.org/mailman/listinfo/sami > >
- [sami] Welcome to SAMI and something you may like… Yingjie Gu(yingjie)
- Re: [sami] Welcome to SAMI and something you may … Juergen Schoenwaelder
- Re: [sami] Welcome to SAMI and something you may … Yingjie Gu(yingjie)
- Re: [sami] Welcome to SAMI and something you may … Linda Dunbar
- Re: [sami] Welcome to SAMI and something you may … Yingjie Gu(yingjie)
- Re: [sami] Welcome to SAMI and something you may … So, Ning
- Re: [sami] Welcome to SAMI and something you may … Melinda Shore
- Re: [sami] Welcome to SAMI and something you may … Yingjie Gu(yingjie)
- Re: [sami] Welcome to SAMI and something you may … Yingjie Gu(yingjie)
- Re: [sami] Welcome to SAMI and something you may … So, Ning
- Re: [sami] Welcome to SAMI and something you may … Melinda Shore
- [sami] Scope [was Re: Welcome to SAMI and somethi… Melinda Shore
- Re: [sami] Bringing new work into the IETF Yingjie Gu(yingjie)
- [sami] Bringing new work into the IETF David Harrington
- Re: [sami] Bringing new work into the IETF Melinda Shore
- Re: [sami] Bringing new work into the IETF Thomas Narten
- Re: [sami] Welcome to SAMI and something you may … Juergen Schoenwaelder
- Re: [sami] Bringing new work into the IETF So, Ning
- Re: [sami] Bringing new work into the IETF Melinda Shore
- Re: [sami] Bringing new work into the IETF Thomas Narten
- Re: [sami] Bringing new work into the IETF So, Ning
- Re: [sami] Bringing new work into the IETF david.black
- [sami] 答复: Trying to figure out where we are Yingjie Gu(yingjie)
- Re: [sami] Bringing new work into the IETF Melinda Shore
- Re: [sami] Bringing new work into the IETF Benson Schliesser
- Re: [sami] Bringing new work into the IETF So, Ning
- Re: [sami] Welcome to SAMI and something you may … Warren Kumari
- [sami] Trying to figure out where we are Melinda Shore
- Re: [sami] Trying to figure out where we are Yingjie Gu(yingjie)
- Re: [sami] Trying to figure out where we are zhangyunfei
- Re: [sami] Trying to figure out where we are Thomas Narten
- Re: [sami] Trying to figure out where we are Jamal Hadi Salim
- Re: [sami] Trying to figure out where we are Yingjie Gu(yingjie)
- Re: [sami] Trying to figure out where we are Thomas Narten
- Re: [sami] Trying to figure out where we are Warren Kumari