From wwwrun@ietfa.amsl.com Wed Aug 10 14:22:25 2011 Return-Path: X-Original-To: sami@ietf.org Delivered-To: sami@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 4803721F8715; Wed, 10 Aug 2011 14:22:25 -0700 (PDT) From: IETF Secretariat To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110810212225.4803721F8715@ietfa.amsl.com> Date: Wed, 10 Aug 2011 14:22:25 -0700 (PDT) Cc: guyingjie@huawei.com, opsawg@ietf.org, dromasca@avaya.com, sami@ietf.org Subject: [sami] New Non-WG Mailing List: sami -- State Migration X-BeenThere: sami@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: State Migration List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 21:22:25 -0000 A new IETF non-working group email list has been created. List address: sami@ietf.org Archive: http://www.ietf.org/mail-archive/web/sami/ To subscribe: https://www.ietf.org/mailman/listinfo/sami (Subject to List Administrator Approval) Purpose: To facilitate Virtual Machine(VM) migration without disruption to running applications and security, service state associated with the specific migrating VM needs to be migrated too. This mail list is used for discussions on use cases, scope, and potential standard works. For additional information, please contact the list administrators. From guyingjie@huawei.com Wed Aug 10 23:06:45 2011 Return-Path: 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 5966421F8A30 for ; Wed, 10 Aug 2011 23:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.387 X-Spam-Level: X-Spam-Status: No, score=-104.387 tagged_above=-999 required=5 tests=[AWL=2.211, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 eUtUjgtQwGX2 for ; Wed, 10 Aug 2011 23:06:44 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 821BE21F8ACE for ; Wed, 10 Aug 2011 23:06:43 -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 <0LPR00LIE29GVJ@szxga04-in.huawei.com> for sami@ietf.org; Thu, 11 Aug 2011 14:05:40 +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 <0LPR00KN520IUA@szxga04-in.huawei.com> for sami@ietf.org; Thu, 11 Aug 2011 14:00:34 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADC19301; Thu, 11 Aug 2011 14:00:33 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 11 Aug 2011 14:00:28 +0800 Received: from g00107907 (10.138.41.134) by szxeml401-hub.china.huawei.com (10.82.67.31) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 11 Aug 2011 14:00:32 +0800 Date: Thu, 11 Aug 2011 14:04:14 +0800 From: "Yingjie Gu(yingjie)" X-Originating-IP: [10.138.41.134] To: sami@ietf.org Message-id: <004c01cc57ec$7f602ed0$7e208c70$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_q63Z7nz5i+JxJKXThd5osA)" Content-language: zh-cn Thread-index: AcxX7HVRuZrPxcYMSPmyPWkIvb/VTA== x-cr-hashedpuzzle: Govo JGpK Jasp J4vy KnjF KtJC VyDy Wj7s ayeh cd7J hH42 hiRy jK/t nWCT pG2F uJT3; 5; ZAByAG8AbQBhAHMAYwBhAEAAYQB2AGEAeQBhAC4AYwBvAG0AOwBpAGUAdABmAGQAYgBoAEAAYwBvAG0AYwBhAHMAdAAuAG4AZQB0ADsAcgBiAG8AbgBpAGMAYQBAAGoAdQBuAGkAcABlAHIALgBuAGUAdAA7AHMAYQBtAGkAQABpAGUAdABmAC4AbwByAGcAOwB3AGUAcwBAAG0AdABpAC0AcwB5AHMAdABlAG0AcwAuAGMAbwBtAA==; Sosha1_v1; 7; {A7A6588E-AD3B-4566-83A3-0D94DD98D713}; ZwB1AHkAaQBuAGcAagBpAGUAQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Thu, 11 Aug 2011 06:03:57 GMT; VwBlAGwAYwBvAG0AZQAgAHQAbwAgAFMAQQBNAEkAIABhAG4AZAAgAHMAbwBtAGUAdABoAGkAbgBnACAAeQBvAHUAIABtAGEAeQAgAGwAaQBrAGUAIAB0AG8AIABrAG4AbwB3AC4A x-cr-puzzleid: {A7A6588E-AD3B-4566-83A3-0D94DD98D713} X-CFilter-Loop: Reflected Cc: 'Wesley Eddy' , "'Romascanu, Dan \(Dan\)'" , 'David Harrington' , rbonica@juniper.net Subject: [sami] Welcome to SAMI and something you may like to know. X-BeenThere: sami@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: State Migration List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 06:06:45 -0000 --Boundary_(ID_q63Z7nz5i+JxJKXThd5osA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi all, Thank you very much for your interest in StAte Migration (SAMI). In this email, I would like to introduce some background of this mail list, so that you can get better understanding of what we need and want to do as the first target of this mail list. At IETF81 meeting, we had a small size BarBoF. The topic is what you have seen in mail list description. To let those who haven't attend the BarBoF know what is state in our context, an example of the state is TCP state on firewall. For detail information, please go to https://datatracker.ietf.org/meeting/81/materials.html ->Tsvarea->Yingjie-policies migration, and http://tools.ietf.org/id/draft-gu-opsawg-policies-migration-00.txt. 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. Please contribute your ideas to the mail list. _____ Best Regards Gu Yingjie --Boundary_(ID_q63Z7nz5i+JxJKXThd5osA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi= all,

Th= ank you very much for your interest in StAte Migration (SAMI). =

 

In= this email, I would like to introduce some background of this mail = list, so that you can get better understanding of what we need and want = to do as the first target of this mail list.

 

At= IETF81 meeting, we had a small size BarBoF. The topic is what you have = seen in mail list description. To let those who haven’t attend the = BarBoF know what is state in our context, an example of the state is TCP = state on firewall. For detail information, please go to https://d= atatracker.ietf.org/meeting/81/materials.html = ->Tsvarea->Yingjie-policies migration, and http://tools.ietf.org/id/draft-gu-opsawg-policies-migration-00.txt= .

 

At= tendees 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.

 

Pl= ease contribute your ideas to the mail list.

 

B= est Regards
Gu Yingjie

 

= --Boundary_(ID_q63Z7nz5i+JxJKXThd5osA)-- From j.schoenwaelder@jacobs-university.de Thu Aug 11 00:40:17 2011 Return-Path: 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 7276D21F86D2 for ; Thu, 11 Aug 2011 00:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.083 X-Spam-Level: X-Spam-Status: No, score=-103.083 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, 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 15ontLURQeP7 for ; Thu, 11 Aug 2011 00:40:15 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2377621F86CA for ; Thu, 11 Aug 2011 00:40:11 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id EC2B520C18; Thu, 11 Aug 2011 09:40:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 81MLl4aWbysB; Thu, 11 Aug 2011 09:40:42 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CA3C320C17; Thu, 11 Aug 2011 09:40:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A5C411A2CF86; Thu, 11 Aug 2011 09:40:35 +0200 (CEST) Date: Thu, 11 Aug 2011 09:40:35 +0200 From: Juergen Schoenwaelder To: "Yingjie Gu(yingjie)" Message-ID: <20110811074034.GA12533@elstar.local> References: <004c01cc57ec$7f602ed0$7e208c70$@com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004c01cc57ec$7f602ed0$7e208c70$@com> User-Agent: Mutt/1.5.21 (2010-09-15) 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. X-BeenThere: sami@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: State Migration List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 07:40:17 -0000 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 From guyingjie@huawei.com Thu Aug 11 02:03:50 2011 Return-Path: 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 CC46C21F8ACE for ; Thu, 11 Aug 2011 02:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.078 X-Spam-Level: X-Spam-Status: No, score=-103.078 tagged_above=-999 required=5 tests=[AWL=0.732, BAYES_00=-2.599, CN_BODY_35=0.339, 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 F8vQOfXDws6B for ; Thu, 11 Aug 2011 02:03:50 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id F29F221F86C2 for ; Thu, 11 Aug 2011 02:03:49 -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 <0LPR00J31AHCUK@szxga03-in.huawei.com> for sami@ietf.org; Thu, 11 Aug 2011 17:03:13 +0800 (CST) Received: from szxrg02-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 <0LPR00DTNAHCFH@szxga03-in.huawei.com> for sami@ietf.org; Thu, 11 Aug 2011 17:03:12 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml205-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADC41128; Thu, 11 Aug 2011 17:03:11 +0800 (CST) Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 11 Aug 2011 17:03:07 +0800 Received: from g00107907 (10.138.41.134) by szxeml406-hub.china.huawei.com (10.82.67.93) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 11 Aug 2011 17:03:11 +0800 Date: Thu, 11 Aug 2011 17:06:53 +0800 From: "Yingjie Gu(yingjie)" In-reply-to: <20110811074034.GA12533@elstar.local> X-Originating-IP: [10.138.41.134] To: 'Juergen Schoenwaelder' Message-id: <005701cc5806$03cd8370$0b688a50$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=gb2312 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: AcxX+gQmKjN6vzg7RySnApAgSygj8QACByjw X-CFilter-Loop: Reflected References: <004c01cc57ec$7f602ed0$7e208c70$@com> <20110811074034.GA12533@elstar.local> 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. X-BeenThere: sami@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: State Migration List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 09:03:50 -0000 Hi Juergen, I accept your suggestion. I will be more careful with my words.=20 We don't need yet more high level discussion on whether it's useful or = not.=20 Let's first figure out the context: scope, use cases and so on. Best Regards Gu Yingjie -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: sami-bounces@ietf.org [mailto:sami-bounces@ietf.org] = =B4=FA=B1=ED Juergen Schoenwaelder =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA8=D4=C211=C8=D5 =C0=D6=C0=D615:41 =CA=D5=BC=FE=C8=CB: Yingjie Gu(yingjie) =B3=AD=CB=CD: 'Wesley Eddy'; 'Romascanu, Dan (Dan)'; = rbonica@juniper.net; 'David Harrington'; sami@ietf.org =D6=F7=CC=E2: 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 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ sami mailing list sami@ietf.org https://www.ietf.org/mailman/listinfo/sami From linda.dunbar@huawei.com Thu Aug 11 09:13:19 2011 Return-Path: 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 10C5821F8C1E for ; Thu, 11 Aug 2011 09:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.139 X-Spam-Level: X-Spam-Status: No, score=-4.139 tagged_above=-999 required=5 tests=[AWL=-2.082, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] 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 tl0jq1ZXaeXS for ; Thu, 11 Aug 2011 09:13:18 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 5F15721F8C0C for ; Thu, 11 Aug 2011 09:13:15 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPR00E98UF1JY@usaga04-in.huawei.com> for sami@ietf.org; Thu, 11 Aug 2011 11:13:49 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPR00BO2UEZ9W@usaga04-in.huawei.com> for sami@ietf.org; Thu, 11 Aug 2011 11:13:49 -0500 (CDT) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 11 Aug 2011 09:13:49 -0700 Received: from DFWEML504-MBX.china.huawei.com ([169.254.4.122]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Thu, 11 Aug 2011 09:13:44 -0700 Date: Thu, 11 Aug 2011 16:13:44 +0000 From: Linda Dunbar In-reply-to: <005701cc5806$03cd8370$0b688a50$@com> X-Originating-IP: [10.47.132.41] To: "Yingjie Gu(yingjie)" , 'Juergen Schoenwaelder' Message-id: <4A95BA014132FF49AE685FAB4B9F17F605189C80@dfweml504-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US Thread-topic: [sami] Welcome to SAMI and something you may like to know. Thread-index: AcxX7HVRuZrPxcYMSPmyPWkIvb/VTAASCu2AAAMDlYAABBPOgA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <004c01cc57ec$7f602ed0$7e208c70$@com> <20110811074034.GA12533@elstar.local> <005701cc5806$03cd8370$0b688a50$@com> 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. X-BeenThere: sami@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: State Migration List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 16:13:19 -0000 SSB0aG91Z2h0IGF0IHRoZSBiYXJCT0YgdGhhdCB0aGUgbmV4dCBzdGVwIGlzIHRvIGlkZW50aWZ5 IHNvbWUgdXNlIGNhc2VzLiBJdCB3aWxsIGJlIHZlcnkgYmVuZWZpY2lhbCB0byBhY2NlbGVyYXRl IHRoZSBwcm9ncmVzcyBieSBpZGVudGlmeWluZyBzb21lIHN0YXRlcyAob3IgY29uZGl0aW9ucykg d2hpY2ggdG9kYXkncyBmaXJld2FsbCBvciBzZWN1cml0eSBkZXZpY2VzIGNhbiB1c2UgdG8gY29u dGludWUgdGhlIHByb3BlciBmdW5jdGlvbi4gDQoNCkxpbmRhDQoNCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogc2FtaS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2FtaS1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gWWluZ2ppZSBHdSh5aW5namllKQ0KPiBT ZW50OiBUaHVyc2RheSwgQXVndXN0IDExLCAyMDExIDQ6MDcgQU0NCj4gVG86ICdKdWVyZ2VuIFNj aG9lbndhZWxkZXInDQo+IENjOiAnV2VzbGV5IEVkZHknOyAnUm9tYXNjYW51LCBEYW4gKERhbikn OyBzYW1pQGlldGYub3JnOyAnRGF2aWQNCj4gSGFycmluZ3Rvbic7IHJib25pY2FAanVuaXBlci5u ZXQNCj4gU3ViamVjdDogUmU6IFtzYW1pXSBXZWxjb21lIHRvIFNBTUkgYW5kIHNvbWV0aGluZyB5 b3UgbWF5IGxpa2UgdG8ga25vdy4NCj4gDQo+IEhpIEp1ZXJnZW4sDQo+IA0KPiBJIGFjY2VwdCB5 b3VyIHN1Z2dlc3Rpb24uIEkgd2lsbCBiZSBtb3JlIGNhcmVmdWwgd2l0aCBteSB3b3Jkcy4NCj4g DQo+IFdlIGRvbid0IG5lZWQgeWV0IG1vcmUgaGlnaCBsZXZlbCBkaXNjdXNzaW9uIG9uIHdoZXRo ZXIgaXQncyB1c2VmdWwgb3INCj4gbm90Lg0KPiANCj4gTGV0J3MgZmlyc3QgZmlndXJlIG91dCB0 aGUgY29udGV4dDogc2NvcGUsIHVzZSBjYXNlcyBhbmQgc28gb24uDQo+IA0KPiANCj4gQmVzdCBS ZWdhcmRzDQo+IEd1IFlpbmdqaWUNCj4gDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6 IHNhbWktYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNhbWktYm91bmNlc0BpZXRmLm9yZ10gtPqx 7Q0KPiBKdWVyZ2VuDQo+IFNjaG9lbndhZWxkZXINCj4gt6LLzcqxvOQ6IDIwMTHE6jjUwjExyNUg wNbA1jE1OjQxDQo+IMrVvP7IyzogWWluZ2ppZSBHdSh5aW5namllKQ0KPiCzrcvNOiAnV2VzbGV5 IEVkZHknOyAnUm9tYXNjYW51LCBEYW4gKERhbiknOyByYm9uaWNhQGp1bmlwZXIubmV0Ow0KPiAn RGF2aWQNCj4gSGFycmluZ3Rvbic7IHNhbWlAaWV0Zi5vcmcNCj4g1vfM4jogUmU6IFtzYW1pXSBX ZWxjb21lIHRvIFNBTUkgYW5kIHNvbWV0aGluZyB5b3UgbWF5IGxpa2UgdG8ga25vdy4NCj4gDQo+ IE9uIFRodSwgQXVnIDExLCAyMDExIGF0IDAyOjA0OjE0UE0gKzA4MDAsIFlpbmdqaWUgR3UoeWlu Z2ppZSkgd3JvdGU6DQo+IA0KPiA+IEF0dGVuZGVlcyBhZ3JlZSB0aGF0IHN0YXRlIG1pZ3JhdGlv biBpcyB1c2VmdWwuIFdoYXQgd2UgbmVlZCB0byBkbw0KPiBuZXh0IGlzDQo+ID4gdG8gbmFycm93 IGRvd24gdGhlIHNjb3BlLCBlLmcuIHN0YXRlIG1pZ3JhdGlvbiB3aXRoaW4gdGhlIHNhbWUNCj4g PiBBZG1pbmlzdHJhdGlvbiBkb21haW4gb3IgYmV0d2VlbiBkb21haW5zLCBhbmQgY29sbGVjdCB0 aGUgdXNlIGNhc2VzDQo+IGluDQo+IHRoYXQNCj4gPiBzY29wZS4gVGhlbiB3ZSBuZWVkIHRvIGZp Z3VyZSBvdXQgd2hhdCBraW5kIG9mIHN0YXRlIG5lZWQgdG8gYmUNCj4gbWlncmF0ZWQNCj4gaW4N Cj4gPiB0aGUgbmFycm93IHNjb3BlLCB3aGF0J3MgdGhlIGNvbW1vbiByZXByZXNlbnRhdGlvbiBv ZiB0aGUgc3RhdGVzLCBhbmQsDQo+IGlmDQo+IHdlDQo+ID4gZ28gdGhhdCBmYXIsIHRoZSBwb3Rl bnRpYWwgc29sdXRpb25zIGZvciBzdGF0ZSBtaWdyYXRpb24uDQo+IA0KPiBGb3IgbWUsIGl0IGlz IGNydWNpYWwgdG8gZmlyc3QgZGVmaW5lIHRoZSBzY29wZSBiZWZvcmUgSSBjYW4gYWdyZWUNCj4g d2hldGhlciBzdGF0ZSBtaWdyYXRpb24gaXMgYSB1c2VmdWwgY29uY2VwdCBvciBub3QuIERlcGVu ZGluZyBvbiB0aGUNCj4gdGltaW5nIGFuZCB0aGUgYWRkcmVzc2luZy9yb3V0aW5nIGlzc3Vlcywg b3RoZXIgbWVjaGFuaXNtcyBtaWdodCBiZQ0KPiBtb3JlIGFwcHJvcHJpYXRlLg0KPiANCj4gQm90 dG9tIGxpbmU6IEJlIGNhcmVmdWwgd2l0aCBnZW5lcmFsIHN0YXRlbWVudHMgbGlrZSAiQXR0ZW5k ZWVzIGFncmVlDQo+IHRoYXQgc3RhdGUgbWlncmF0aW9uIGlzIHVzZWZ1bC4iIGJlZm9yZSB3ZSBl dmVuIGFncmVlIG9uIHRoZSBjb250ZXh0Lg0KPiANCj4gL2pzDQo+IA0KPiAtLQ0KPiBKdWVyZ2Vu IFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0K PiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEsIDI4NzU5IEJy ZW1lbiwgR2VybWFueQ0KPiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwOi8v d3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gc2FtaSBtYWlsaW5nIGxpc3QNCj4gc2FtaUBpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhbWkNCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNhbWkgbWFp bGluZyBsaXN0DQo+IHNhbWlAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zYW1pDQo= From guyingjie@huawei.com Wed Aug 17 01:58:42 2011 Return-Path: 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 E98C821F85AA for ; Wed, 17 Aug 2011 01:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.205 X-Spam-Level: X-Spam-Status: No, score=-102.205 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, CN_BODY_35=0.339, 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 SzBGJOISX+S6 for ; Wed, 17 Aug 2011 01:58:42 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 025D221F8AE6 for ; Wed, 17 Aug 2011 01:58:41 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ2002PRE91VA@szxga05-in.huawei.com> for sami@ietf.org; Wed, 17 Aug 2011 16:58:13 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ2004JVE8UUU@szxga05-in.huawei.com> for sami@ietf.org; Wed, 17 Aug 2011 16:58:13 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADG26773; Wed, 17 Aug 2011 16:58:09 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 17 Aug 2011 16:58:04 +0800 Received: from g00107907 (10.138.41.134) by szxeml402-hub.china.huawei.com (10.82.67.32) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 17 Aug 2011 16:58:05 +0800 Date: Wed, 17 Aug 2011 16:58:43 +0800 From: "Yingjie Gu(yingjie)" In-reply-to: <4A95BA014132FF49AE685FAB4B9F17F605189C80@dfweml504-mbx.china.huawei.com> X-Originating-IP: [10.138.41.134] To: 'Linda Dunbar' , 'Juergen Schoenwaelder' Message-id: <006001cc5cbb$de6c48e0$9b44daa0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=gb2312 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: AcxX7HVRuZrPxcYMSPmyPWkIvb/VTAASCu2AAAMDlYAABBPOgAEaloXw X-CFilter-Loop: Reflected References: <004c01cc57ec$7f602ed0$7e208c70$@com> <20110811074034.GA12533@elstar.local> <005701cc5806$03cd8370$0b688a50$@com> <4A95BA014132FF49AE685FAB4B9F17F605189C80@dfweml504-mbx.china.huawei.com> 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. X-BeenThere: sami@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: State Migration List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 08:58:43 -0000 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. =20 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 -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: Linda Dunbar [mailto:linda.dunbar@huawei.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA8=D4=C212=C8=D5 =C0=D6=C0=D60:14 =CA=D5=BC=FE=C8=CB: Yingjie Gu(yingjie); 'Juergen Schoenwaelder' =B3=AD=CB=CD: 'Wesley Eddy'; 'Romascanu, Dan (Dan)'; sami@ietf.org; = 'David Harrington'; rbonica@juniper.net =D6=F7=CC=E2: 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.=20 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. >=20 > Hi Juergen, >=20 > I accept your suggestion. I will be more careful with my words. >=20 > We don't need yet more high level discussion on whether it's useful or > not. >=20 > Let's first figure out the context: scope, use cases and so on. >=20 >=20 > Best Regards > Gu Yingjie >=20 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: sami-bounces@ietf.org = [mailto:sami-bounces@ietf.org] =B4=FA=B1=ED > Juergen > Schoenwaelder > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA8=D4=C211=C8=D5 =C0=D6=C0=D615:41 > =CA=D5=BC=FE=C8=CB: Yingjie Gu(yingjie) > =B3=AD=CB=CD: 'Wesley Eddy'; 'Romascanu, Dan (Dan)'; = rbonica@juniper.net; > 'David > Harrington'; sami@ietf.org > =D6=F7=CC=E2: Re: [sami] Welcome to SAMI and something you may like to = know. >=20 > On Thu, Aug 11, 2011 at 02:04:14PM +0800, Yingjie Gu(yingjie) wrote: >=20 > > 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. >=20 > 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. >=20 > Bottom line: Be careful with general statements like "Attendees agree > that state migration is useful." before we even agree on the context. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > sami mailing list > sami@ietf.org > https://www.ietf.org/mailman/listinfo/sami >=20 > _______________________________________________ > sami mailing list > sami@ietf.org > https://www.ietf.org/mailman/listinfo/sami From ning.so@verizon.com Wed Aug 17 06:58:38 2011 Return-Path: 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 4B47621F85CE for ; Wed, 17 Aug 2011 06:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.818 X-Spam-Level: X-Spam-Status: No, score=-1.818 tagged_above=-999 required=5 tests=[AWL=-1.019, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_84=0.6] 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 aoxscRvxJBY7 for ; Wed, 17 Aug 2011 06:58:37 -0700 (PDT) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id A522121F84F9 for ; Wed, 17 Aug 2011 06:58:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe02.verizon.com with ESMTP; 17 Aug 2011 13:59:26 +0000 From: "So, Ning" X-IronPort-AV: E=Sophos;i="4.68,240,1312156800"; d="scan'208";a="116175492" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi02.verizon.com with ESMTP; 17 Aug 2011 13:59:21 +0000 Received: from FHDP1LUMXC7V41.us.one.verizon.com ([169.254.1.38]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Wed, 17 Aug 2011 09:59:21 -0400 To: "Yingjie Gu(yingjie)" , 'Linda Dunbar' , 'Juergen Schoenwaelder' Date: Wed, 17 Aug 2011 09:59:19 -0400 Thread-Topic: [sami] Welcome to SAMI and something you may like to know. Thread-Index: AcxX7HVRuZrPxcYMSPmyPWkIvb/VTAASCu2AAAMDlYAABBPOgAEaloXwAAmfeMA= Message-ID: <6665BC1FEA04AB47B1F75FA641C43BC08146326D@FHDP1LUMXC7V41.us.one.verizon.com> References: <004c01cc57ec$7f602ed0$7e208c70$@com> <20110811074034.GA12533@elstar.local> <005701cc5806$03cd8370$0b688a50$@com> <4A95BA014132FF49AE685FAB4B9F17F605189C80@dfweml504-mbx.china.huawei.com> <006001cc5cbb$de6c48e0$9b44daa0$@com> In-Reply-To: <006001cc5cbb$de6c48e0$9b44daa0$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 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. X-BeenThere: sami@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: State Migration List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 13:58:38 -0000 WWluZ2ppZSwNCg0KWW91IG1pZ2h0IHdhbnQgdG8gY29uc2lkZXIgbGltaXRpbmcgdGhlIHNjb3Bl IHRvIHByb2JsZW0gZGVmaW5pdGlvbiBhbmQgcHJvdmlkZXIgcmVxdWlyZW1lbnRzIGNvbGxlY3Rp b24gZmlyc3QuICBJIGtub3cgYSBsb3Qgb2Ygd29yayBoYXMgZ29uZSBpbnRvIGRvY3VtZW50aW5n IHdoYXQgaXMgYXZhaWxhYmxlIHRvZGF5LiAgSG93ZXZlciwgdGhlIHByb3ZpZGVyIHJlcXVpcmVt ZW50cyBpbiB0aGlzIGFyZWEgaXMgc3RpbGwgcmF0aGVyIHRoaW4uICAgRm9yIGV4YW1wbGUsIHRo ZSByZXF1aXJlbWVudHMgZm9yIG9wdGltaXphdGlvbi1iYXNlZCBtaWdyYXRpb24gY2FuIGJlIHF1 aXRlIGRpZmZlcmVudCBmcm9tIGZhaWx1cmUgcmVzdG9yYXRpb24tYmFzZWQgbWlncmF0aW9uLiAg VGhlIHR5cGUgb2Ygc2VydmljZXMgdGhlIFZNcyBhcmUgc3VwcG9ydGluZyBjYW4gYWxzbyBpbXBh Y3QgdGhlIG1pZ3JhdGlvbiByZXF1aXJlbWVudHMsIHRodXMgaW1wYWN0aW5nIHRoZSBzb2x1dGlv bnMuICBEZWZpbmluZyBkaWZmZXJlbnQgdHlwZXMgb2YgVk0gbWlncmF0aW9uIGFuZCB0aGUgYXNz b2NpYXRlZCByZXF1aXJlbWVudHMgc2hvdWxkIGJlIGEgaGlnaGVyIHByaW9yaXR5LCBpbiBteSBv cGluaW9uLiANCg0KwqANCkJlc3QgcmVnYXJkcywNCsKgDQpOaW5nIFNvDQpWZXJpem9uIENvcnBv cmF0ZSBUZWNobm9sb2d5DQoob2ZmaWNlKSA5NzItNzI5LTc5MDUNCihDZWxsKSA5NzItOTU1LTA5 MTQNCsKgDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzYW1pLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpzYW1pLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBZaW5n amllIEd1KHlpbmdqaWUpDQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAxNywgMjAxMSAzOjU5IEFN DQpUbzogJ0xpbmRhIER1bmJhcic7ICdKdWVyZ2VuIFNjaG9lbndhZWxkZXInDQpDYzogJ1dlc2xl eSBFZGR5JzsgJ1JvbWFzY2FudSwgRGFuIChEYW4pJzsgcmJvbmljYUBqdW5pcGVyLm5ldDsgJ0Rh dmlkIEhhcnJpbmd0b24nOyBzYW1pQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NhbWldIFdlbGNv bWUgdG8gU0FNSSBhbmQgc29tZXRoaW5nIHlvdSBtYXkgbGlrZSB0byBrbm93Lg0KDQpUaGUgZm9s bG93aW5nIGlzIGEgc2NvcGUgc3VnZ2VzdGVkIGJ5IERyLiBGYW4uDQoNCiIgQWNjb3JkaW5nIHRv IHRoZSBjdXJyZW50IGltcGxlbWVudGF0aW9uLFZNIG1pZ3JhdGlvbiBpcyBzY29wZWQgaW4gYSBs YXllcg0KMiBuZXR3b3JrIHdpdGggc2hhcmVkIHN0b3JhZ2UuS2V5IGZhY3RvcnMgdGhhdCBkZWNp ZGUgd2hldGhlciBob3QgbWlncmF0aW9uIGlzIHN1Y2Nlc3NmdWwgaW5jbHVkZXMsZnJvbSB0aGUg bmV0d29yaydzIHNpZGUsIGJhbmR3aXRoIGFuZCBkZWxheS5FdmVuIHRoZSBtaWdyYXRpb24gaGFw cGVucyBiZXR3ZWVuIHR3byBzaXRlcyxpdCBtYXkgc3VjY2VlZCBpZiB0aGUgYmFuZHdpZHRoIGlz IHdpZGUgZW5vdWdoIGFuZCB0aGUgZGVsYXkgaXMgc21hbGwgZW5vdWdoLg0KIA0KU28scGVoaGFw cyB3ZSBjYW4gZGVmaW5lIHRoZSBzY29wZSBhcyBzdWNoOkEgbGF5ZXIgMiBzdWJuZXQgd2l0aCBn b29kIGVub3VnaCBwZXJmb3JtYW5jZSB3aGljaCBtYWtlcyB0aGUgaG90IG1pZ3JhdGlvbiBzdWNj ZXNzZnVsLiINCg0KV2hhdCBpcyB5b3VyIG9waW5pb24gb24gdGhpcyBzY29wZT8NCg0KQmVzdCBS ZWdhcmRzDQpHdSBZaW5namllDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujog TGluZGEgRHVuYmFyIFttYWlsdG86bGluZGEuZHVuYmFyQGh1YXdlaS5jb21dDQrlj5HpgIHml7bp l7Q6IDIwMTHlubQ45pyIMTLml6Ug5LmQ5LmQMDoxNA0K5pS25Lu25Lq6OiBZaW5namllIEd1KHlp bmdqaWUpOyAnSnVlcmdlbiBTY2hvZW53YWVsZGVyJw0K5oqE6YCBOiAnV2VzbGV5IEVkZHknOyAn Um9tYXNjYW51LCBEYW4gKERhbiknOyBzYW1pQGlldGYub3JnOyAnRGF2aWQgSGFycmluZ3Rvbic7 IHJib25pY2FAanVuaXBlci5uZXQNCuS4u+mimDogUkU6IFtzYW1pXSBXZWxjb21lIHRvIFNBTUkg YW5kIHNvbWV0aGluZyB5b3UgbWF5IGxpa2UgdG8ga25vdy4NCg0KSSB0aG91Z2h0IGF0IHRoZSBi YXJCT0YgdGhhdCB0aGUgbmV4dCBzdGVwIGlzIHRvIGlkZW50aWZ5IHNvbWUgdXNlIGNhc2VzLiBJ dCB3aWxsIGJlIHZlcnkgYmVuZWZpY2lhbCB0byBhY2NlbGVyYXRlIHRoZSBwcm9ncmVzcyBieSBp ZGVudGlmeWluZyBzb21lIHN0YXRlcyAob3IgY29uZGl0aW9ucykgd2hpY2ggdG9kYXkncyBmaXJl d2FsbCBvciBzZWN1cml0eSBkZXZpY2VzIGNhbiB1c2UgdG8gY29udGludWUgdGhlIHByb3BlciBm dW5jdGlvbi4gDQoNCg0KDQpMaW5kYQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IHNhbWktYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNhbWktYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIA0KPiBPZiBZaW5namllIEd1KHlpbmdqaWUpDQo+IFNlbnQ6IFRodXJzZGF5 LCBBdWd1c3QgMTEsIDIwMTEgNDowNyBBTQ0KPiBUbzogJ0p1ZXJnZW4gU2Nob2Vud2FlbGRlcicN Cj4gQ2M6ICdXZXNsZXkgRWRkeSc7ICdSb21hc2NhbnUsIERhbiAoRGFuKSc7IHNhbWlAaWV0Zi5v cmc7ICdEYXZpZCANCj4gSGFycmluZ3Rvbic7IHJib25pY2FAanVuaXBlci5uZXQNCj4gU3ViamVj dDogUmU6IFtzYW1pXSBXZWxjb21lIHRvIFNBTUkgYW5kIHNvbWV0aGluZyB5b3UgbWF5IGxpa2Ug dG8ga25vdy4NCj4gDQo+IEhpIEp1ZXJnZW4sDQo+IA0KPiBJIGFjY2VwdCB5b3VyIHN1Z2dlc3Rp b24uIEkgd2lsbCBiZSBtb3JlIGNhcmVmdWwgd2l0aCBteSB3b3Jkcy4NCj4gDQo+IFdlIGRvbid0 IG5lZWQgeWV0IG1vcmUgaGlnaCBsZXZlbCBkaXNjdXNzaW9uIG9uIHdoZXRoZXIgaXQncyB1c2Vm dWwgb3IgDQo+IG5vdC4NCj4gDQo+IExldCdzIGZpcnN0IGZpZ3VyZSBvdXQgdGhlIGNvbnRleHQ6 IHNjb3BlLCB1c2UgY2FzZXMgYW5kIHNvIG9uLg0KPiANCj4gDQo+IEJlc3QgUmVnYXJkcw0KPiBH dSBZaW5namllDQo+IA0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7tuS6ujogc2Ft aS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2FtaS1ib3VuY2VzQGlldGYub3JnXSDku6PooagN Cj4gSnVlcmdlbg0KPiBTY2hvZW53YWVsZGVyDQo+IOWPkemAgeaXtumXtDogMjAxMeW5tDjmnIgx MeaXpSDkuZDkuZAxNTo0MQ0KPiDmlLbku7bkuro6IFlpbmdqaWUgR3UoeWluZ2ppZSkNCj4g5oqE 6YCBOiAnV2VzbGV5IEVkZHknOyAnUm9tYXNjYW51LCBEYW4gKERhbiknOyByYm9uaWNhQGp1bmlw ZXIubmV0OyAnRGF2aWQgDQo+IEhhcnJpbmd0b24nOyBzYW1pQGlldGYub3JnDQo+IOS4u+mimDog UmU6IFtzYW1pXSBXZWxjb21lIHRvIFNBTUkgYW5kIHNvbWV0aGluZyB5b3UgbWF5IGxpa2UgdG8g a25vdy4NCj4gDQo+IE9uIFRodSwgQXVnIDExLCAyMDExIGF0IDAyOjA0OjE0UE0gKzA4MDAsIFlp bmdqaWUgR3UoeWluZ2ppZSkgd3JvdGU6DQo+IA0KPiA+IEF0dGVuZGVlcyBhZ3JlZSB0aGF0IHN0 YXRlIG1pZ3JhdGlvbiBpcyB1c2VmdWwuIFdoYXQgd2UgbmVlZCB0byBkbw0KPiBuZXh0IGlzDQo+ ID4gdG8gbmFycm93IGRvd24gdGhlIHNjb3BlLCBlLmcuIHN0YXRlIG1pZ3JhdGlvbiB3aXRoaW4g dGhlIHNhbWUgDQo+ID4gQWRtaW5pc3RyYXRpb24gZG9tYWluIG9yIGJldHdlZW4gZG9tYWlucywg YW5kIGNvbGxlY3QgdGhlIHVzZSBjYXNlcw0KPiBpbg0KPiB0aGF0DQo+ID4gc2NvcGUuIFRoZW4g d2UgbmVlZCB0byBmaWd1cmUgb3V0IHdoYXQga2luZCBvZiBzdGF0ZSBuZWVkIHRvIGJlDQo+IG1p Z3JhdGVkDQo+IGluDQo+ID4gdGhlIG5hcnJvdyBzY29wZSwgd2hhdCdzIHRoZSBjb21tb24gcmVw cmVzZW50YXRpb24gb2YgdGhlIHN0YXRlcywgDQo+ID4gYW5kLA0KPiBpZg0KPiB3ZQ0KPiA+IGdv IHRoYXQgZmFyLCB0aGUgcG90ZW50aWFsIHNvbHV0aW9ucyBmb3Igc3RhdGUgbWlncmF0aW9uLg0K PiANCj4gRm9yIG1lLCBpdCBpcyBjcnVjaWFsIHRvIGZpcnN0IGRlZmluZSB0aGUgc2NvcGUgYmVm b3JlIEkgY2FuIGFncmVlIA0KPiB3aGV0aGVyIHN0YXRlIG1pZ3JhdGlvbiBpcyBhIHVzZWZ1bCBj b25jZXB0IG9yIG5vdC4gRGVwZW5kaW5nIG9uIHRoZSANCj4gdGltaW5nIGFuZCB0aGUgYWRkcmVz c2luZy9yb3V0aW5nIGlzc3Vlcywgb3RoZXIgbWVjaGFuaXNtcyBtaWdodCBiZSANCj4gbW9yZSBh cHByb3ByaWF0ZS4NCj4gDQo+IEJvdHRvbSBsaW5lOiBCZSBjYXJlZnVsIHdpdGggZ2VuZXJhbCBz dGF0ZW1lbnRzIGxpa2UgIkF0dGVuZGVlcyBhZ3JlZSANCj4gdGhhdCBzdGF0ZSBtaWdyYXRpb24g aXMgdXNlZnVsLiIgYmVmb3JlIHdlIGV2ZW4gYWdyZWUgb24gdGhlIGNvbnRleHQuDQo+IA0KPiAv anMNCj4gDQo+IC0tDQo+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVu aXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAg Q2FtcHVzIFJpbmcgMSwgMjg3NTkgQnJlbWVuLCBHZXJtYW55DQo+IEZheDogICArNDkgNDIxIDIw MCAzMTAzICAgICAgICAgPGh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzYW1pIG1haWxp bmcgbGlzdA0KPiBzYW1pQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2FtaQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gc2FtaSBtYWlsaW5nIGxpc3QNCj4gc2FtaUBpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhbWkNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNhbWkgbWFpbGluZyBsaXN0DQpzYW1p QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhbWkNCg== From melinda.shore@gmail.com Wed Aug 17 17:50:37 2011 Return-Path: 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 4600E11E8095 for ; Wed, 17 Aug 2011 17:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_27=0.6, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-1] 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 G3K+qhfTG6Ri for ; Wed, 17 Aug 2011 17:50:36 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id C665E21F8AF7 for ; Wed, 17 Aug 2011 17:50:36 -0700 (PDT) Received: by pzk33 with SMTP id 33so3279586pzk.18 for ; Wed, 17 Aug 2011 17:51:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=7wViil3NAZ9LVprX3rvfxVCaxmrrHnX2atWo7ckLgQA=; b=NmTGHVq4w65q11FGj0B7Vw0SvVp1eb1xc5sk1UK92WZnIAnsJdwHxYeA665ANlPLWT OJj/aGN5q9ZlGvfuGnFxo7jrM6FQYcuME013P+415WPmUrNrs2TQZIQe8ilLE8O+K8do 6fzPBbE63ljuceSjTXNiK+0uTcF3T9f+e7l3k= Received: by 10.143.69.12 with SMTP id w12mr49609wfk.298.1313628689240; Wed, 17 Aug 2011 17:51:29 -0700 (PDT) Received: from [137.229.12.236] (drake.swits.alaska.edu [137.229.12.236]) by mx.google.com with ESMTPS id n3sm1030464pbi.21.2011.08.17.17.51.27 (version=SSLv3 cipher=OTHER); Wed, 17 Aug 2011 17:51:28 -0700 (PDT) Message-ID: <4E4C6214.3010800@gmail.com> Date: Wed, 17 Aug 2011 16:51:32 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Yingjie Gu(yingjie)" References: <004c01cc57ec$7f602ed0$7e208c70$@com> <20110811074034.GA12533@elstar.local> <005701cc5806$03cd8370$0b688a50$@com> <4A95BA014132FF49AE685FAB4B9F17F605189C80@dfweml504-mbx.china.huawei.com> <006001cc5cbb$de6c48e0$9b44daa0$@com> In-Reply-To: <006001cc5cbb$de6c48e0$9b44daa0$@com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Cc: sami@ietf.org Subject: Re: [sami] Welcome to SAMI and something you may like to know. X-BeenThere: sami@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: State Migration List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 00:50:37 -0000 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 From guyingjie@huawei.com Thu Aug 18 05:01:44 2011 Return-Path: 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 94DEB21F8AAC for ; Thu, 18 Aug 2011 05:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.593 X-Spam-Level: X-Spam-Status: No, score=-103.593 tagged_above=-999 required=5 tests=[AWL=1.206, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_84=0.6, 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 WFfJMxPGnZQf for ; Thu, 18 Aug 2011 05:01:43 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 56FE621F8A96 for ; Thu, 18 Aug 2011 05:01:43 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ4006ZGHGBOZ@szxga05-in.huawei.com> for sami@ietf.org; Thu, 18 Aug 2011 20:02:35 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ4000Q3HG9C9@szxga05-in.huawei.com> for sami@ietf.org; Thu, 18 Aug 2011 20:02:35 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml206-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADH23241; Thu, 18 Aug 2011 20:02:31 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 18 Aug 2011 20:02:24 +0800 Received: from g00107907 (10.138.41.134) by szxeml402-hub.china.huawei.com (10.82.67.32) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 18 Aug 2011 20:02:26 +0800 Date: Thu, 18 Aug 2011 20:03:00 +0800 From: "Yingjie Gu(yingjie)" In-reply-to: <6665BC1FEA04AB47B1F75FA641C43BC08146326D@FHDP1LUMXC7V41.us.one.verizon.com> X-Originating-IP: [10.138.41.134] To: "'So, Ning'" , 'Linda Dunbar' , 'Juergen Schoenwaelder' Message-id: <004b01cc5d9e$c7015130$5503f390$@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: AcxX7HVRuZrPxcYMSPmyPWkIvb/VTAASCu2AAAMDlYAABBPOgAEaloXwAAmfeMAAJ6eRMA== 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> 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. X-BeenThere: sami@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: State Migration List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 12:01:44 -0000 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 -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: So, Ning [mailto:ning.so@verizon.com]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2011=E5=B9=B48=E6=9C=8817=E6=97=A5 = =E4=B9=90=E4=B9=9021:59 =E6=94=B6=E4=BB=B6=E4=BA=BA: Yingjie Gu(yingjie); 'Linda Dunbar'; = 'Juergen Schoenwaelder' =E6=8A=84=E9=80=81: 'Wesley Eddy'; 'Romascanu, Dan (Dan)'; = rbonica@juniper.net; 'David Harrington'; sami@ietf.org =E4=B8=BB=E9=A2=98: 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.=20 =20 Best regards, =20 Ning So Verizon Corporate Technology (office) 972-729-7905 (Cell) 972-955-0914 =20 -----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. =20 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 -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: Linda Dunbar = [mailto:linda.dunbar@huawei.com] =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2011=E5=B9=B48=E6=9C=8812=E6=97=A5 = =E4=B9=90=E4=B9=900:14 =E6=94=B6=E4=BB=B6=E4=BA=BA: Yingjie Gu(yingjie); 'Juergen = Schoenwaelder' =E6=8A=84=E9=80=81: 'Wesley Eddy'; 'Romascanu, Dan (Dan)'; = sami@ietf.org; 'David Harrington'; rbonica@juniper.net =E4=B8=BB=E9=A2=98: 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.=20 Linda > -----Original Message----- > From: sami-bounces@ietf.org [mailto:sami-bounces@ietf.org] On Behalf=20 > 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=20 > Harrington'; rbonica@juniper.net > Subject: Re: [sami] Welcome to SAMI and something you may like to = know. >=20 > Hi Juergen, >=20 > I accept your suggestion. I will be more careful with my words. >=20 > We don't need yet more high level discussion on whether it's useful or = > not. >=20 > Let's first figure out the context: scope, use cases and so on. >=20 >=20 > Best Regards > Gu Yingjie >=20 > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: sami-bounces@ietf.org = [mailto:sami-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 > Juergen > Schoenwaelder > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2011=E5=B9=B48=E6=9C=8811=E6=97=A5 =E4=B9=90=E4=B9=9015:41 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Yingjie Gu(yingjie) > =E6=8A=84=E9=80=81: 'Wesley Eddy'; 'Romascanu, Dan (Dan)'; = rbonica@juniper.net; 'David=20 > Harrington'; sami@ietf.org > =E4=B8=BB=E9=A2=98: Re: [sami] Welcome to SAMI and something you may = like to know. >=20 > On Thu, Aug 11, 2011 at 02:04:14PM +0800, Yingjie Gu(yingjie) wrote: >=20 > > 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=20 > > 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,=20 > > and, > if > we > > go that far, the potential solutions for state migration. >=20 > For me, it is crucial to first define the scope before I can agree=20 > whether state migration is a useful concept or not. Depending on the=20 > timing and the addressing/routing issues, other mechanisms might be=20 > more appropriate. >=20 > Bottom line: Be careful with general statements like "Attendees agree=20 > that state migration is useful." before we even agree on the context. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > sami mailing list > sami@ietf.org > https://www.ietf.org/mailman/listinfo/sami >=20 > _______________________________________________ > 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 From guyingjie@huawei.com Thu Aug 18 05:55:41 2011 Return-Path: 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 951D121F8B1A for ; Thu, 18 Aug 2011 05:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.634 X-Spam-Level: X-Spam-Status: No, score=-103.634 tagged_above=-999 required=5 tests=[AWL=1.165, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_41=0.6, 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 maSaHZSMU7uh for ; Thu, 18 Aug 2011 05:55:40 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1B421F8AC9 for ; Thu, 18 Aug 2011 05:55:40 -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 <0LQ4008TFJY9XP@szxga04-in.huawei.com> for sami@ietf.org; Thu, 18 Aug 2011 20:56:33 +0800 (CST) Received: from szxrg01-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 <0LQ400DOLJY45D@szxga04-in.huawei.com> for sami@ietf.org; Thu, 18 Aug 2011 20:56:33 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml207-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADF88156; Thu, 18 Aug 2011 20:56:32 +0800 (CST) Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 18 Aug 2011 20:56:26 +0800 Received: from g00107907 (10.138.41.134) by szxeml412-hub.china.huawei.com (10.82.67.91) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 18 Aug 2011 20:56:32 +0800 Date: Thu, 18 Aug 2011 20:57:15 +0800 From: "Yingjie Gu(yingjie)" In-reply-to: <12969308CE9E48DEAB5B5745D9482303@fanybP> X-Originating-IP: [10.138.41.134] To: 'Fan Yongbing' , 'Melinda Shore' Message-id: <004c01cc5da6$5adb5660$10920320$@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: AcxdV3TMyJpZL1i1SgKy7BXTYeDhQAAR2NZA 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> <4E4C6214.3010800@gmail.com> <12969308CE9E48DEAB5B5745D9482303@fanybP> Cc: sami@ietf.org Subject: Re: [sami] Welcome to SAMI and something you may like to know. X-BeenThere: sami@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: State Migration List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 12:55:41 -0000 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.=20 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.=20 Please speak out your opinions on the above scope definition. Two coming drafts:=20 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.=20 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 -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: Fan Yongbing [mailto:fanyb@gsta.com]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2011=E5=B9=B48=E6=9C=8818=E6=97=A5 = =E4=B9=90=E4=B9=9011:30 =E6=94=B6=E4=BB=B6=E4=BA=BA: Melinda Shore; Yingjie Gu(yingjie) =E6=8A=84=E9=80=81: sami@ietf.org =E4=B8=BB=E9=A2=98: 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=20 example,firewall,switch and so on)needed to maintain existing service as a VM is hot-migrated to another position = in=20 the same layer 2 subnet. Fan Yongbing China Telecom =E6=A8=8A=E5=8B=87=E5=85=B5 =E5=8D=9A=E5=A3=AB -------------------------------------------------- =E4=B8=AD=E5=9B=BD=E7=94=B5=E4=BF=A1=E8=82=A1=E4=BB=BD=E6=9C=89=E9=99=90=E5= =85=AC=E5=8F=B8=E5=B9=BF=E5=B7=9E=E7=A0=94=E7=A9=B6=E9=99=A2 =E6=95=B0=E6=8D=AE=E9=80=9A=E4=BF=A1=E7=A0=94=E7=A9=B6=E9=83=A8 Mobile=EF=BC=9A13316090609=EF=BC=88=E4=B8=BB=E7=94=A8=EF=BC=89=EF=BC=9B13= 922438897=EF=BC=88=E8=BE=85=E7=94=A8=EF=BC=89 Tel=EF=BC=9A020-38639121=EF=BC=9BPHS=EF=BC=9A020-88338121 Fax=EF=BC=9A020-38639487 -------------------------------------------------- ----- Original Message -----=20 From: "Melinda Shore" To: "Yingjie Gu(yingjie)" Cc: 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=20 From ning.so@verizon.com Thu Aug 18 06:57:26 2011 Return-Path: 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 4643221F85AC for ; Thu, 18 Aug 2011 06:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.745 X-Spam-Level: X-Spam-Status: No, score=-1.745 tagged_above=-999 required=5 tests=[AWL=-0.946, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_84=0.6] 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 5UpczMZwp2Th for ; Thu, 18 Aug 2011 06:57:25 -0700 (PDT) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id CDB8E21F85CE for ; Thu, 18 Aug 2011 06:57:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe01.verizon.com with ESMTP; 18 Aug 2011 13:58:17 +0000 From: "So, Ning" X-IronPort-AV: E=Sophos;i="4.68,245,1312156800"; d="scan'208";a="116977862" Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by fldsmtpi03.verizon.com with ESMTP; 18 Aug 2011 13:58:17 +0000 Received: from FHDP1LUMXC7V41.us.one.verizon.com ([169.254.1.38]) by FHDP1LUMXC7HB03.us.one.verizon.com ([166.68.59.190]) with mapi; Thu, 18 Aug 2011 09:58:16 -0400 To: "Yingjie Gu(yingjie)" , 'Linda Dunbar' , 'Juergen Schoenwaelder' Date: Thu, 18 Aug 2011 09:58:15 -0400 Thread-Topic: [sami] Welcome to SAMI and something you may like to know. Thread-Index: AcxX7HVRuZrPxcYMSPmyPWkIvb/VTAASCu2AAAMDlYAABBPOgAEaloXwAAmfeMAAJ6eRMAALeEcA Message-ID: <6665BC1FEA04AB47B1F75FA641C43BC0814637AE@FHDP1LUMXC7V41.us.one.verizon.com> 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> In-Reply-To: <004b01cc5d9e$c7015130$5503f390$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 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. X-BeenThere: sami@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: State Migration List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 13:57:26 -0000 WWluZ2ppZSwNCg0KSSBjYW4gaGVscCB3aXRoIG9uZSBraW5kIG9mIHByb3ZpZGVycycgcmVxdWly ZW1lbnRzLCB0aGUgdHJhZGl0aW9uYWwgdGVsZWNvbSBzZXJ2aWNlIHByb3ZpZGVyIHdobyBvd25z IHRoZSBpbmZyYXN0cnVjdHVyZSBlbmQtdG8tZW5kLiAgTXkgdW5kZXJzdGFuZGluZyBpcyBub3Qg bmVhcmx5IGFzIGdvb2Qgd2hlbiBpdCBjb21lcyB0byBvdGhlciB0eXBlIG9mIHByb3ZpZGVycyBz dWNoIGFzIEdPT0dMRSwgWUFIT08sIG9yIHNlcnZpY2UgYnJva2VyL3dob2xlIHNlbGxlci9pbnRl Z3JhdG9yLiAgDQoNCsKgDQpCZXN0IHJlZ2FyZHMsDQrCoA0KTmluZyBTbw0KVmVyaXpvbiBDb3Jw b3JhdGUgVGVjaG5vbG9neQ0KKG9mZmljZSkgOTcyLTcyOS03OTA1DQooQ2VsbCkgOTcyLTk1NS0w OTE0DQrCoA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2FtaS1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86c2FtaS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWWlu Z2ppZSBHdSh5aW5namllKQ0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAxOCwgMjAxMSA3OjAzIEFN DQpUbzogU28sIE5pbmc7ICdMaW5kYSBEdW5iYXInOyAnSnVlcmdlbiBTY2hvZW53YWVsZGVyJw0K Q2M6ICdXZXNsZXkgRWRkeSc7ICdSb21hc2NhbnUsIERhbiAoRGFuKSc7IHNhbWlAaWV0Zi5vcmc7 ICdEYXZpZCBIYXJyaW5ndG9uJzsgcmJvbmljYUBqdW5pcGVyLm5ldA0KU3ViamVjdDogUmU6IFtz YW1pXSBXZWxjb21lIHRvIFNBTUkgYW5kIHNvbWV0aGluZyB5b3UgbWF5IGxpa2UgdG8ga25vdy4N Cg0KTmluZywNCg0KV2hlbiB3ZSB0YWxrZWQgYXQgUXVlYmVjLCBJIHJlbWVtYmVyZWQgdGhhdCB5 b3UgaGF2ZSBpbXByZXNzaXZlIHVuZGVyc3RhbmRpbmcgb24gVk0gbWlncmF0aW9uIHJlcXVpcmVt ZW50cyBpbi9iZXR3ZWVuIHN1Ym5ldHMuIEhvcGUgeW91IGNhbiBzaGFyZSB5b3VyIHVzZSBjYXNl cyBmcm9tIHByb3ZpZGVyJ3MgcGVyc3BlY3RpdmUuDQpJIGhhdmUgdGFsa2VkIHdpdGggdHdvIHBy b3ZpZGVycyBpbiBkZXRhaWwsIGFuZCB0aGV5IGJvdGggc2VlIHRoZSBzdHJvbmcgcmVxdWlyZW1l bnRzIGZvciBzdGF0ZSBtaWdyYXRpb24gYXMgVk0gbWlncmF0ZXMuIFBlcmhhcHMgd2UgbmVlZCB0 byBkb2N1bWVudCBwcm92aWRlcidzIHJlcXVpcmVtZW50cyBmb3IgcGVvcGxlJ3MgcmVmZXJlbmNl LiBJIGFtIHdvcmtpbmcgd2l0aCBwcm92aWRlcnMgb24gdGhpcyBkb2N1bWVudCB0byBpbnRyb2R1 Y2UgdXNlIGNhc2VzLg0KDQoNCg0KQmVzdCBSZWdhcmRzDQpHdSBZaW5namllDQoNCg0KLS0tLS3p gq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBTbywgTmluZyBbbWFpbHRvOm5pbmcuc29AdmVy aXpvbi5jb21dDQrlj5HpgIHml7bpl7Q6IDIwMTHlubQ45pyIMTfml6Ug5LmQ5LmQMjE6NTkNCuaU tuS7tuS6ujogWWluZ2ppZSBHdSh5aW5namllKTsgJ0xpbmRhIER1bmJhcic7ICdKdWVyZ2VuIFNj aG9lbndhZWxkZXInDQrmioTpgIE6ICdXZXNsZXkgRWRkeSc7ICdSb21hc2NhbnUsIERhbiAoRGFu KSc7IHJib25pY2FAanVuaXBlci5uZXQ7ICdEYXZpZCBIYXJyaW5ndG9uJzsgc2FtaUBpZXRmLm9y Zw0K5Li76aKYOiBSRTogW3NhbWldIFdlbGNvbWUgdG8gU0FNSSBhbmQgc29tZXRoaW5nIHlvdSBt YXkgbGlrZSB0byBrbm93Lg0KDQpZaW5namllLA0KDQpZb3UgbWlnaHQgd2FudCB0byBjb25zaWRl ciBsaW1pdGluZyB0aGUgc2NvcGUgdG8gcHJvYmxlbSBkZWZpbml0aW9uIGFuZCBwcm92aWRlciBy ZXF1aXJlbWVudHMgY29sbGVjdGlvbiBmaXJzdC4gIEkga25vdyBhIGxvdCBvZiB3b3JrIGhhcyBn b25lIGludG8gZG9jdW1lbnRpbmcgd2hhdCBpcyBhdmFpbGFibGUgdG9kYXkuICBIb3dldmVyLCB0 aGUgcHJvdmlkZXIgcmVxdWlyZW1lbnRzIGluIHRoaXMgYXJlYSBpcyBzdGlsbCByYXRoZXIgdGhp bi4gICBGb3IgZXhhbXBsZSwgdGhlIHJlcXVpcmVtZW50cyBmb3Igb3B0aW1pemF0aW9uLWJhc2Vk IG1pZ3JhdGlvbiBjYW4gYmUgcXVpdGUgZGlmZmVyZW50IGZyb20gZmFpbHVyZSByZXN0b3JhdGlv bi1iYXNlZCBtaWdyYXRpb24uICBUaGUgdHlwZSBvZiBzZXJ2aWNlcyB0aGUgVk1zIGFyZSBzdXBw b3J0aW5nIGNhbiBhbHNvIGltcGFjdCB0aGUgbWlncmF0aW9uIHJlcXVpcmVtZW50cywgdGh1cyBp bXBhY3RpbmcgdGhlIHNvbHV0aW9ucy4gIERlZmluaW5nIGRpZmZlcmVudCB0eXBlcyBvZiBWTSBt aWdyYXRpb24gYW5kIHRoZSBhc3NvY2lhdGVkIHJlcXVpcmVtZW50cyBzaG91bGQgYmUgYSBoaWdo ZXIgcHJpb3JpdHksIGluIG15IG9waW5pb24uIA0KDQogDQpCZXN0IHJlZ2FyZHMsDQogDQpOaW5n IFNvDQpWZXJpem9uIENvcnBvcmF0ZSBUZWNobm9sb2d5DQoob2ZmaWNlKSA5NzItNzI5LTc5MDUN CihDZWxsKSA5NzItOTU1LTA5MTQNCiANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IHNhbWktYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNhbWktYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIFlpbmdqaWUgR3UoeWluZ2ppZSkNClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0 IDE3LCAyMDExIDM6NTkgQU0NClRvOiAnTGluZGEgRHVuYmFyJzsgJ0p1ZXJnZW4gU2Nob2Vud2Fl bGRlcicNCkNjOiAnV2VzbGV5IEVkZHknOyAnUm9tYXNjYW51LCBEYW4gKERhbiknOyByYm9uaWNh QGp1bmlwZXIubmV0OyAnRGF2aWQgSGFycmluZ3Rvbic7IHNhbWlAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbc2FtaV0gV2VsY29tZSB0byBTQU1JIGFuZCBzb21ldGhpbmcgeW91IG1heSBsaWtlIHRv IGtub3cuDQoNClRoZSBmb2xsb3dpbmcgaXMgYSBzY29wZSBzdWdnZXN0ZWQgYnkgRHIuIEZhbi4N Cg0KIiBBY2NvcmRpbmcgdG8gdGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb24sVk0gbWlncmF0aW9u IGlzIHNjb3BlZCBpbiBhIGxheWVyDQoyIG5ldHdvcmsgd2l0aCBzaGFyZWQgc3RvcmFnZS5LZXkg ZmFjdG9ycyB0aGF0IGRlY2lkZSB3aGV0aGVyIGhvdCBtaWdyYXRpb24gaXMgc3VjY2Vzc2Z1bCBp bmNsdWRlcyxmcm9tIHRoZSBuZXR3b3JrJ3Mgc2lkZSwgYmFuZHdpdGggYW5kIGRlbGF5LkV2ZW4g dGhlIG1pZ3JhdGlvbiBoYXBwZW5zIGJldHdlZW4gdHdvIHNpdGVzLGl0IG1heSBzdWNjZWVkIGlm IHRoZSBiYW5kd2lkdGggaXMgd2lkZSBlbm91Z2ggYW5kIHRoZSBkZWxheSBpcyBzbWFsbCBlbm91 Z2guDQogDQpTbyxwZWhoYXBzIHdlIGNhbiBkZWZpbmUgdGhlIHNjb3BlIGFzIHN1Y2g6QSBsYXll ciAyIHN1Ym5ldCB3aXRoIGdvb2QgZW5vdWdoIHBlcmZvcm1hbmNlIHdoaWNoIG1ha2VzIHRoZSBo b3QgbWlncmF0aW9uIHN1Y2Nlc3NmdWwuIg0KDQpXaGF0IGlzIHlvdXIgb3BpbmlvbiBvbiB0aGlz IHNjb3BlPw0KDQpCZXN0IFJlZ2FyZHMNCkd1IFlpbmdqaWUNCg0KLS0tLS3pgq7ku7bljp/ku7Yt LS0tLQ0K5Y+R5Lu25Lq6OiBMaW5kYSBEdW5iYXIgW21haWx0bzpsaW5kYS5kdW5iYXJAaHVhd2Vp LmNvbV0NCuWPkemAgeaXtumXtDogMjAxMeW5tDjmnIgxMuaXpSDkuZDkuZAwOjE0DQrmlLbku7bk uro6IFlpbmdqaWUgR3UoeWluZ2ppZSk7ICdKdWVyZ2VuIFNjaG9lbndhZWxkZXInDQrmioTpgIE6 ICdXZXNsZXkgRWRkeSc7ICdSb21hc2NhbnUsIERhbiAoRGFuKSc7IHNhbWlAaWV0Zi5vcmc7ICdE YXZpZCBIYXJyaW5ndG9uJzsgcmJvbmljYUBqdW5pcGVyLm5ldA0K5Li76aKYOiBSRTogW3NhbWld IFdlbGNvbWUgdG8gU0FNSSBhbmQgc29tZXRoaW5nIHlvdSBtYXkgbGlrZSB0byBrbm93Lg0KDQpJ IHRob3VnaHQgYXQgdGhlIGJhckJPRiB0aGF0IHRoZSBuZXh0IHN0ZXAgaXMgdG8gaWRlbnRpZnkg c29tZSB1c2UgY2FzZXMuIEl0IHdpbGwgYmUgdmVyeSBiZW5lZmljaWFsIHRvIGFjY2VsZXJhdGUg dGhlIHByb2dyZXNzIGJ5IGlkZW50aWZ5aW5nIHNvbWUgc3RhdGVzIChvciBjb25kaXRpb25zKSB3 aGljaCB0b2RheSdzIGZpcmV3YWxsIG9yIHNlY3VyaXR5IGRldmljZXMgY2FuIHVzZSB0byBjb250 aW51ZSB0aGUgcHJvcGVyIGZ1bmN0aW9uLiANCg0KDQoNCkxpbmRhDQoNCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogc2FtaS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2Ft aS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgDQo+IE9mIFlpbmdqaWUgR3UoeWluZ2ppZSkN Cj4gU2VudDogVGh1cnNkYXksIEF1Z3VzdCAxMSwgMjAxMSA0OjA3IEFNDQo+IFRvOiAnSnVlcmdl biBTY2hvZW53YWVsZGVyJw0KPiBDYzogJ1dlc2xleSBFZGR5JzsgJ1JvbWFzY2FudSwgRGFuIChE YW4pJzsgc2FtaUBpZXRmLm9yZzsgJ0RhdmlkIA0KPiBIYXJyaW5ndG9uJzsgcmJvbmljYUBqdW5p cGVyLm5ldA0KPiBTdWJqZWN0OiBSZTogW3NhbWldIFdlbGNvbWUgdG8gU0FNSSBhbmQgc29tZXRo aW5nIHlvdSBtYXkgbGlrZSB0byBrbm93Lg0KPiANCj4gSGkgSnVlcmdlbiwNCj4gDQo+IEkgYWNj ZXB0IHlvdXIgc3VnZ2VzdGlvbi4gSSB3aWxsIGJlIG1vcmUgY2FyZWZ1bCB3aXRoIG15IHdvcmRz Lg0KPiANCj4gV2UgZG9uJ3QgbmVlZCB5ZXQgbW9yZSBoaWdoIGxldmVsIGRpc2N1c3Npb24gb24g d2hldGhlciBpdCdzIHVzZWZ1bCBvciANCj4gbm90Lg0KPiANCj4gTGV0J3MgZmlyc3QgZmlndXJl IG91dCB0aGUgY29udGV4dDogc2NvcGUsIHVzZSBjYXNlcyBhbmQgc28gb24uDQo+IA0KPiANCj4g QmVzdCBSZWdhcmRzDQo+IEd1IFlpbmdqaWUNCj4gDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0N Cj4g5Y+R5Lu25Lq6OiBzYW1pLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzYW1pLWJvdW5jZXNA aWV0Zi5vcmddIOS7o+ihqA0KPiBKdWVyZ2VuDQo+IFNjaG9lbndhZWxkZXINCj4g5Y+R6YCB5pe2 6Ze0OiAyMDEx5bm0OOaciDEx5pelIOS5kOS5kDE1OjQxDQo+IOaUtuS7tuS6ujogWWluZ2ppZSBH dSh5aW5namllKQ0KPiDmioTpgIE6ICdXZXNsZXkgRWRkeSc7ICdSb21hc2NhbnUsIERhbiAoRGFu KSc7IHJib25pY2FAanVuaXBlci5uZXQ7ICdEYXZpZCANCj4gSGFycmluZ3Rvbic7IHNhbWlAaWV0 Zi5vcmcNCj4g5Li76aKYOiBSZTogW3NhbWldIFdlbGNvbWUgdG8gU0FNSSBhbmQgc29tZXRoaW5n IHlvdSBtYXkgbGlrZSB0byBrbm93Lg0KPiANCj4gT24gVGh1LCBBdWcgMTEsIDIwMTEgYXQgMDI6 MDQ6MTRQTSArMDgwMCwgWWluZ2ppZSBHdSh5aW5namllKSB3cm90ZToNCj4gDQo+ID4gQXR0ZW5k ZWVzIGFncmVlIHRoYXQgc3RhdGUgbWlncmF0aW9uIGlzIHVzZWZ1bC4gV2hhdCB3ZSBuZWVkIHRv IGRvDQo+IG5leHQgaXMNCj4gPiB0byBuYXJyb3cgZG93biB0aGUgc2NvcGUsIGUuZy4gc3RhdGUg bWlncmF0aW9uIHdpdGhpbiB0aGUgc2FtZSANCj4gPiBBZG1pbmlzdHJhdGlvbiBkb21haW4gb3Ig YmV0d2VlbiBkb21haW5zLCBhbmQgY29sbGVjdCB0aGUgdXNlIGNhc2VzDQo+IGluDQo+IHRoYXQN Cj4gPiBzY29wZS4gVGhlbiB3ZSBuZWVkIHRvIGZpZ3VyZSBvdXQgd2hhdCBraW5kIG9mIHN0YXRl IG5lZWQgdG8gYmUNCj4gbWlncmF0ZWQNCj4gaW4NCj4gPiB0aGUgbmFycm93IHNjb3BlLCB3aGF0 J3MgdGhlIGNvbW1vbiByZXByZXNlbnRhdGlvbiBvZiB0aGUgc3RhdGVzLCANCj4gPiBhbmQsDQo+ IGlmDQo+IHdlDQo+ID4gZ28gdGhhdCBmYXIsIHRoZSBwb3RlbnRpYWwgc29sdXRpb25zIGZvciBz dGF0ZSBtaWdyYXRpb24uDQo+IA0KPiBGb3IgbWUsIGl0IGlzIGNydWNpYWwgdG8gZmlyc3QgZGVm aW5lIHRoZSBzY29wZSBiZWZvcmUgSSBjYW4gYWdyZWUgDQo+IHdoZXRoZXIgc3RhdGUgbWlncmF0 aW9uIGlzIGEgdXNlZnVsIGNvbmNlcHQgb3Igbm90LiBEZXBlbmRpbmcgb24gdGhlIA0KPiB0aW1p bmcgYW5kIHRoZSBhZGRyZXNzaW5nL3JvdXRpbmcgaXNzdWVzLCBvdGhlciBtZWNoYW5pc21zIG1p Z2h0IGJlIA0KPiBtb3JlIGFwcHJvcHJpYXRlLg0KPiANCj4gQm90dG9tIGxpbmU6IEJlIGNhcmVm dWwgd2l0aCBnZW5lcmFsIHN0YXRlbWVudHMgbGlrZSAiQXR0ZW5kZWVzIGFncmVlIA0KPiB0aGF0 IHN0YXRlIG1pZ3JhdGlvbiBpcyB1c2VmdWwuIiBiZWZvcmUgd2UgZXZlbiBhZ3JlZSBvbiB0aGUg Y29udGV4dC4NCj4gDQo+IC9qcw0KPiANCj4gLS0NCj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyICAg ICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4gUGhvbmU6ICs0OSA0MjEg MjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxLCAyODc1OSBCcmVtZW4sIEdlcm1hbnkNCj4g RmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cDovL3d3dy5qYWNvYnMtdW5pdmVy c2l0eS5kZS8+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IHNhbWkgbWFpbGluZyBsaXN0DQo+IHNhbWlAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYW1pDQo+IA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzYW1pIG1haWxpbmcgbGlzdA0KPiBzYW1p QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FtaQ0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2FtaSBt YWlsaW5nIGxpc3QNCnNhbWlAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2FtaQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0Kc2FtaSBtYWlsaW5nIGxpc3QNCnNhbWlAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FtaQ0K From melinda.shore@gmail.com Thu Aug 18 09:01:32 2011 Return-Path: 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 D7ED621F8C21 for ; Thu, 18 Aug 2011 09:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 179tm6yke7Fn for ; Thu, 18 Aug 2011 09:01:32 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 49AC821F8C20 for ; Thu, 18 Aug 2011 09:01:32 -0700 (PDT) Received: by ywm21 with SMTP id 21so1677464ywm.31 for ; Thu, 18 Aug 2011 09:02:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=BKPSDlqZEfcj8qmyVUWFJdkK01pdXhiXCBJBPQvSwMM=; b=b+I5Grh/I33M0ZQNmQCnW9UU5ISoOmHR1P94Z/xbzpVWCGqiawSzCp4R+D2X7b5SYm RbqKuqh/7nigVNGm+23rI4CYK8bGl3asdEP4aobkh9Mqj2mi5se5gPgxYfaZygiqA3Sa PzXxPqre5TjtxJsd0VRyfQppy4VH2XqAmR9ZA= Received: by 10.142.6.6 with SMTP id 6mr475835wff.126.1313683346107; Thu, 18 Aug 2011 09:02:26 -0700 (PDT) Received: from polypro.local (66-230-82-131-rb1.fai.dsl.dynamic.acsalaska.net [66.230.82.131]) by mx.google.com with ESMTPS id l7sm1566894pbh.42.2011.08.18.09.02.23 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 18 Aug 2011 09:02:24 -0700 (PDT) Message-ID: <4E4D378E.6020705@gmail.com> Date: Thu, 18 Aug 2011 08:02:22 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: sami@ietf.org References: <004c01cc57ec$7f602ed0$7e208c70$@com> <20110811074034.GA12533@elstar.local> <005701cc5806$03cd8370$0b688a50$@com> <4A95BA014132FF49AE685FAB4B9F17F605189C80@dfweml504-mbx.china.huawei.com> <006001cc5cbb$de6c48e0$9b44daa0$@com> <4E4C6214.3010800@gmail.com> <12969308CE9E48DEAB5B5745D9482303@fanybP> <004c01cc5da6$5adb5660$10920320$@com> In-Reply-To: <004c01cc5da6$5adb5660$10920320$@com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sami] Welcome to SAMI and something you may like to know. X-BeenThere: sami@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: State Migration List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 16:01:33 -0000 On 8/18/11 4:57 AM, Yingjie Gu(yingjie) wrote: > 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. Absolutely. It seems to me that if you think that - for the purposes of state migration - failing because there's insufficient network resources is different from failing for some other reason, it might be a good thing to explain why. I could be convinced otherwise but for the moment I don't think this is a particularly defensible distinction. I'm also not clear on how much network bandwidth is needed to support failover. Intuitively it seems like the answer is "nearly none." There may be issues around bandwidth available to the hot spare when it goes live but if they're on the same layer 2 subnet/network segment, the failed-from and failed-to servers are going to have pretty much the same resources available to them. Melinda From melinda.shore@gmail.com Thu Aug 18 13:29:54 2011 Return-Path: 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 AC4CB21F8AA9 for ; Thu, 18 Aug 2011 13:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 nK2YnDcYk25o for ; Thu, 18 Aug 2011 13:29:53 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 92EC421F8A69 for ; Thu, 18 Aug 2011 13:29:53 -0700 (PDT) Received: by pzk33 with SMTP id 33so5881588pzk.18 for ; Thu, 18 Aug 2011 13:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=u3H/KfLCm7gm5Uiu083zIaTvCujUsLvGy3PKZ0ydISw=; b=YIVokIj1+vXkt2Y1xM8TxUC/qr6z+DFlQQBZu40CftjAzhPPsmObQT01yRgh8LPc53 v1qYsMXmtAUOBbSH1vQpNiph+yhoXuN71MTnhF13Dxt8pr2quKN+C6P/3sgNbB4oZR77 8K7QILWEcK8qFuQmDSxo/ZdDpzq50H+lz0swg= Received: by 10.142.215.4 with SMTP id n4mr625208wfg.187.1313699448475; Thu, 18 Aug 2011 13:30:48 -0700 (PDT) Received: from [137.229.12.236] (drake.swits.alaska.edu [137.229.12.236]) by mx.google.com with ESMTPS id i8sm1726824pbi.76.2011.08.18.13.30.46 (version=SSLv3 cipher=OTHER); Thu, 18 Aug 2011 13:30:47 -0700 (PDT) Message-ID: <4E4D767C.3090909@gmail.com> Date: Thu, 18 Aug 2011 12:30:52 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: sami@ietf.org References: <004c01cc57ec$7f602ed0$7e208c70$@com> <20110811074034.GA12533@elstar.local> <005701cc5806$03cd8370$0b688a50$@com> <4A95BA014132FF49AE685FAB4B9F17F605189C80@dfweml504-mbx.china.huawei.com> <006001cc5cbb$de6c48e0$9b44daa0$@com> <4E4C6214.3010800@gmail.com> <12969308CE9E48DEAB5B5745D9482303@fanybP> <004c01cc5da6$5adb5660$10920320$@com> In-Reply-To: <004c01cc5da6$5adb5660$10920320$@com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [sami] Scope [was Re: Welcome to SAMI and something you may like to know.] X-BeenThere: sami@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: State Migration List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 20:29:54 -0000 I have to admit that I'm becoming more confused rather than less as the discussions progress. 1) My understanding earlier was that we were talking about failing over services between existing VMs rather than copying a VM as part of a failover. Is anybody actually doing that? Aren't you concerned that you'll be copying the failed state? 2) If you're copying a live VM, along with its runtime state (i.e. memory), things like IP addresses, MAC addresses, and so on will be moving with it. If the VM stays on the same subnet presumably it will be behind the same middlebox. The only thing I could think of that might become an issue is the MAC address being mapped to a particular switch port. What network state do you think will need to move with a VM relocation on the same subnet? It seems to me that there's some interesting work here regarding transferring middlebox state when the service is being failed over, not so much when a VM is just being shuttled around a subnet (and I'm not sure that really happens, anyway). That said, if what's at issue is middlebox state moving that probably belongs in the transport area rather than the ops area. But first, let's figure out what's actually under discussion. Melinda From guyingjie@huawei.com Thu Aug 18 18:15:39 2011 Return-Path: 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 ; 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 ; 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 ; 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)" In-reply-to: X-Originating-IP: [10.138.41.134] To: 'David Harrington' , 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> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 01:15:39 -0000 --Boundary_(ID_1C3F/OGg1E2ObW/5y8cEZQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hi David, Thank you so much for your attention and such detail suggestion. I = really appreciate it. =20 I believe there are some misunderstanding. But I appreciate the chance = to clarify our target. =20 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 =A1=AEState Migration=A1=AF means. How to do = virtualization and how to migrate the VM is out of the scope.=20 You can do VM migration either by a standardized way(I am not sure there = is a standard way) or proprietary way. It doesn=A1=AFt 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.=20 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.=20 =20 =20 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.=20 =20 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. =20 =20 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. =20 Again, thank you for your detail suggestion.=20 =20 Best Regards Gu Yingjie =20 -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: David Harrington [mailto:ietfdbh@comcast.net]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA8=D4=C218=C8=D5 =C0=D6=C0=D623:25 =CA=D5=BC=FE=C8=CB: 'Yingjie Gu(yingjie)'; sami@ietf.org =D6=F7=CC=E2: Bringing new work into the IETF =20 Hi Yingjie, =20 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. =20 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. =20 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.=20 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.=20 =20 =20 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. =20 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. =20 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. =20 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. =20 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. =20 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.=20 =20 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.=20 =20 David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) =20 > -----Original Message----- > From: Yingjie Gu(yingjie) [mailto:guyingjie@huawei.com]=20 > Sent: Thursday, August 18, 2011 8:03 AM > To: 'So, Ning'; 'Linda Dunbar'; 'Juergen Schoenwaelder' > Cc: 'Wesley Eddy'; 'Romascanu, Dan (Dan)';=20 > rbonica@juniper.net; 'David Harrington'; sami@ietf.org > Subject: Re: [sami] Welcome to SAMI and something you may=20 > like to know. >=20 > Ning, >=20 > When we talked at Quebec, I remembered that you have=20 > impressive understanding on VM migration requirements=20 > in/between subnets. Hope you can share your use cases from=20 > provider's perspective. > I have talked with two providers in detail, and they both see=20 > the strong requirements for state migration as VM migrates.=20 > Perhaps we need to document provider's requirements for=20 > people's reference. I am working with providers on this=20 > document to introduce use cases. >=20 >=20 >=20 > Best Regards > Gu Yingjie >=20 >=20 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: So, Ning [mailto:ning.so@verizon.com]=20 > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA8=D4=C217=C8=D5 =C0=D6=C0=D621:59 > =CA=D5=BC=FE=C8=CB: Yingjie Gu(yingjie); 'Linda Dunbar'; 'Juergen = Schoenwaelder' > =B3=AD=CB=CD: 'Wesley Eddy'; 'Romascanu, Dan (Dan)';=20 > rbonica@juniper.net; 'David Harrington'; sami@ietf.org > =D6=F7=CC=E2: RE: [sami] Welcome to SAMI and something you may like to = know. >=20 > Yingjie, >=20 > You might want to consider limiting the scope to problem=20 > definition and provider requirements collection first. I=20 > know a lot of work has gone into documenting what is=20 > available today. However, the provider requirements in this=20 > area is still rather thin. For example, the requirements=20 > for optimization-based migration can be quite different from=20 > failure restoration-based migration. The type of services=20 > the VMs are supporting can also impact the migration=20 > requirements, thus impacting the solutions. Defining=20 > different types of VM migration and the associated=20 > requirements should be a higher priority, in my opinion.=20 >=20 > =20 > Best regards, > =20 > Ning So > Verizon Corporate Technology > (office) 972-729-7905 > (Cell) 972-955-0914 > =20 >=20 > -----Original Message----- > From: sami-bounces@ietf.org [mailto:sami-bounces@ietf.org] On=20 > Behalf Of Yingjie Gu(yingjie) > Sent: Wednesday, August 17, 2011 3:59 AM > To: 'Linda Dunbar'; 'Juergen Schoenwaelder' > Cc: 'Wesley Eddy'; 'Romascanu, Dan (Dan)';=20 > rbonica@juniper.net; 'David Harrington'; sami@ietf.org > Subject: Re: [sami] Welcome to SAMI and something you may=20 > like to know. >=20 > The following is a scope suggested by Dr. Fan. >=20 > " According to the current implementation,VM migration is=20 > scoped in a layer > 2 network with shared storage.Key factors that decide whether=20 > hot migration is successful includes,from the network's side,=20 > bandwith and delay.Even the migration happens between two=20 > sites,it may succeed if the bandwidth is wide enough and the=20 > delay is small enough. > =20 > So,pehhaps we can define the scope as such:A layer 2 subnet=20 > with good enough performance which makes the hot migration=20 > successful." >=20 > What is your opinion on this scope? >=20 > Best Regards > Gu Yingjie >=20 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Linda Dunbar [mailto:linda.dunbar@huawei.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA8=D4=C212=C8=D5 =C0=D6=C0=D60:14 > =CA=D5=BC=FE=C8=CB: Yingjie Gu(yingjie); 'Juergen Schoenwaelder' > =B3=AD=CB=CD: 'Wesley Eddy'; 'Romascanu, Dan (Dan)'; sami@ietf.org;=20 > 'David Harrington'; rbonica@juniper.net > =D6=F7=CC=E2: RE: [sami] Welcome to SAMI and something you may like to = know. >=20 > I thought at the barBOF that the next step is to identify=20 > some use cases. It will be very beneficial to accelerate the=20 > progress by identifying some states (or conditions) which=20 > today's firewall or security devices can use to continue the=20 > proper function.=20 >=20 >=20 > Linda >=20 > > -----Original Message----- > > From: sami-bounces@ietf.org [mailto:sami-bounces@ietf.org]=20 > On Behalf=20 > > 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=20 > > Harrington'; rbonica@juniper.net > > Subject: Re: [sami] Welcome to SAMI and something you may=20 > like to know. > >=20 > > Hi Juergen, > >=20 > > I accept your suggestion. I will be more careful with my words. > >=20 > > We don't need yet more high level discussion on whether=20 > it's useful or=20 > > not. > >=20 > > Let's first figure out the context: scope, use cases and so on. > >=20 > >=20 > > Best Regards > > Gu Yingjie > >=20 > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > =B7=A2=BC=FE=C8=CB: sami-bounces@ietf.org = [mailto:sami-bounces@ietf.org] =B4=FA=B1=ED > > Juergen > > Schoenwaelder > > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA8=D4=C211=C8=D5 = =C0=D6=C0=D615:41 > > =CA=D5=BC=FE=C8=CB: Yingjie Gu(yingjie) > > =B3=AD=CB=CD: 'Wesley Eddy'; 'Romascanu, Dan (Dan)';=20 > rbonica@juniper.net; 'David=20 > > Harrington'; sami@ietf.org > > =D6=F7=CC=E2: Re: [sami] Welcome to SAMI and something you may like = to know. > >=20 > > On Thu, Aug 11, 2011 at 02:04:14PM +0800, Yingjie Gu(yingjie) wrote: > >=20 > > > 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=20 > > > Administration domain or between domains, and collect the=20 > 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,=20 > > > and, > > if > > we > > > go that far, the potential solutions for state migration. > >=20 > > For me, it is crucial to first define the scope before I can agree =20 > > whether state migration is a useful concept or not.=20 > Depending on the=20 > > timing and the addressing/routing issues, other mechanisms might be=20 > > more appropriate. > >=20 > > Bottom line: Be careful with general statements like=20 > "Attendees agree=20 > > that state migration is useful." before we even agree on=20 > the context. > >=20 > > /js > >=20 > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > _______________________________________________ > > sami mailing list > > sami@ietf.org > > https://www.ietf.org/mailman/listinfo/sami > >=20 > > _______________________________________________ > > sami mailing list > > sami@ietf.org > > https://www.ietf.org/mailman/listinfo/sami >=20 > _______________________________________________ > sami mailing list > sami@ietf.org > https://www.ietf.org/mailman/listinfo/sami >=20 >=20 --Boundary_(ID_1C3F/OGg1E2ObW/5y8cEZQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

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 =A1=AEState Migration=A1=AF 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=A1=AFt 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

 

-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE=C8=CB: David Harrington [mailto:ietfdbh@comcast.net] =
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA8=D4=C218=C8=D5 =C0=D6=C0=D623:25
=CA=D5=BC=FE=C8=CB: 'Yingjie Gu(yingjie)'; sami@ietf.org
=D6=F7=CC=E2: 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

>

>

> -----=D3=CA=BC=FE=D4=AD=BC=FE-----

> =B7=A2=BC=FE=C8=CB: So, Ning [mailto:ning.so@verizon.com] =

> = =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA8=D4=C217=C8=D5 =C0=D6=C0=D621:59

> =CA=D5=BC=FE=C8=CB: Yingjie Gu(yingjie); 'Linda Dunbar'; 'Juergen = Schoenwaelder'

> =B3=AD=CB=CD: 'Wesley Eddy'; 'Romascanu, Dan (Dan)'; =

> = rbonica@juniper.net; 'David Harrington'; = sami@ietf.org

> =D6=F7=CC=E2: 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

>

> -----=D3=CA=BC=FE=D4=AD=BC=FE-----

> =B7=A2=BC=FE=C8=CB: Linda Dunbar = [mailto:linda.dunbar@huawei.com]

> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA8=D4=C212=C8=D5 =C0=D6=C0=D60:14

> =CA=D5=BC=FE=C8=CB: Yingjie Gu(yingjie); 'Juergen = Schoenwaelder'

> =B3=AD=CB=CD: 'Wesley Eddy'; 'Romascanu, Dan (Dan)'; sami@ietf.org; =

> = 'David Harrington'; rbonica@juniper.net

> =D6=F7=CC=E2: 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

> >

> > -----=D3=CA=BC=FE=D4=AD=BC=FE-----

> > =B7=A2=BC=FE=C8=CB: sami-bounces@ietf.org [mailto:sami-bounces@ietf.org] = =B4=FA=B1=ED

> > Juergen

> > = Schoenwaelder

> > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA8=D4=C211=C8=D5 =C0=D6=C0=D615:41

> > =CA=D5=BC=FE=C8=CB: Yingjie Gu(yingjie)

> > =B3=AD=CB=CD: 'Wesley Eddy'; 'Romascanu, Dan (Dan)'; =

> = rbonica@juniper.net; 'David

> > Harrington'; = sami@ietf.org

> > =D6=F7=CC=E2: 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

>

> =

= --Boundary_(ID_1C3F/OGg1E2ObW/5y8cEZQ)-- From ietfdbh@comcast.net Thu Aug 18 08:24:22 2011 Return-Path: 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 CD59C21F8B63 for ; Thu, 18 Aug 2011 08:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.988 X-Spam-Level: X-Spam-Status: No, score=-99.988 tagged_above=-999 required=5 tests=[AWL=-2.578, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_27=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_84=0.6, MIME_CHARSET_FARAWAY=2.45, 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 5bHoE-LBc85y for ; Thu, 18 Aug 2011 08:24:21 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC4E21F8B1F for ; Thu, 18 Aug 2011 08:24:21 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta15.westchester.pa.mail.comcast.net with comcast id MrGE1h00A1wpRvQ5FrRGhS; Thu, 18 Aug 2011 15:25:16 +0000 Received: from davidPC ([67.189.235.106]) by omta18.westchester.pa.mail.comcast.net with comcast id MrR81h00A2JQnJT3erR8Hx; Thu, 18 Aug 2011 15:25:10 +0000 From: "David Harrington" To: "'Yingjie Gu\(yingjie\)'" , 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> In-Reply-To: <004b01cc5d9e$c7015130$5503f390$@com> Date: Thu, 18 Aug 2011 11:25:04 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-index: AcxX7HVRuZrPxcYMSPmyPWkIvb/VTAASCu2AAAMDlYAABBPOgAEaloXwAAmfeMAAJ6eRMAAMDvuQ X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 X-Mailman-Approved-At: Thu, 18 Aug 2011 18:29:22 -0700 Subject: [sami] Bringing new work into the IETF X-BeenThere: sami@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: State Migration List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 15:24:22 -0000 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.=20 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.=20 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.=20 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.=20 David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) =20 > -----Original Message----- > From: Yingjie Gu(yingjie) [mailto:guyingjie@huawei.com]=20 > Sent: Thursday, August 18, 2011 8:03 AM > To: 'So, Ning'; 'Linda Dunbar'; 'Juergen Schoenwaelder' > Cc: 'Wesley Eddy'; 'Romascanu, Dan (Dan)';=20 > rbonica@juniper.net; 'David Harrington'; sami@ietf.org > Subject: Re: [sami] Welcome to SAMI and something you may=20 > like to know. >=20 > Ning, >=20 > When we talked at Quebec, I remembered that you have=20 > impressive understanding on VM migration requirements=20 > in/between subnets. Hope you can share your use cases from=20 > provider's perspective. > I have talked with two providers in detail, and they both see=20 > the strong requirements for state migration as VM migrates.=20 > Perhaps we need to document provider's requirements for=20 > people's reference. I am working with providers on this=20 > document to introduce use cases. >=20 >=20 >=20 > Best Regards > Gu Yingjie >=20 >=20 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: So, Ning [mailto:ning.so@verizon.com]=20 > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA8=D4=C217=C8=D5 =C0=D6=C0=D621:59 > =CA=D5=BC=FE=C8=CB: Yingjie Gu(yingjie); 'Linda Dunbar'; 'Juergen = Schoenwaelder' > =B3=AD=CB=CD: 'Wesley Eddy'; 'Romascanu, Dan (Dan)';=20 > rbonica@juniper.net; 'David Harrington'; sami@ietf.org > =D6=F7=CC=E2: RE: [sami] Welcome to SAMI and something you may like to = know. >=20 > Yingjie, >=20 > You might want to consider limiting the scope to problem=20 > definition and provider requirements collection first. I=20 > know a lot of work has gone into documenting what is=20 > available today. However, the provider requirements in this=20 > area is still rather thin. For example, the requirements=20 > for optimization-based migration can be quite different from=20 > failure restoration-based migration. The type of services=20 > the VMs are supporting can also impact the migration=20 > requirements, thus impacting the solutions. Defining=20 > different types of VM migration and the associated=20 > requirements should be a higher priority, in my opinion.=20 >=20 > =20 > Best regards, > =20 > Ning So > Verizon Corporate Technology > (office) 972-729-7905 > (Cell) 972-955-0914 > =20 >=20 > -----Original Message----- > From: sami-bounces@ietf.org [mailto:sami-bounces@ietf.org] On=20 > Behalf Of Yingjie Gu(yingjie) > Sent: Wednesday, August 17, 2011 3:59 AM > To: 'Linda Dunbar'; 'Juergen Schoenwaelder' > Cc: 'Wesley Eddy'; 'Romascanu, Dan (Dan)';=20 > rbonica@juniper.net; 'David Harrington'; sami@ietf.org > Subject: Re: [sami] Welcome to SAMI and something you may=20 > like to know. >=20 > The following is a scope suggested by Dr. Fan. >=20 > " According to the current implementation,VM migration is=20 > scoped in a layer > 2 network with shared storage.Key factors that decide whether=20 > hot migration is successful includes,from the network's side,=20 > bandwith and delay.Even the migration happens between two=20 > sites,it may succeed if the bandwidth is wide enough and the=20 > delay is small enough. > =20 > So,pehhaps we can define the scope as such:A layer 2 subnet=20 > with good enough performance which makes the hot migration=20 > successful." >=20 > What is your opinion on this scope? >=20 > Best Regards > Gu Yingjie >=20 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Linda Dunbar [mailto:linda.dunbar@huawei.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA8=D4=C212=C8=D5 =C0=D6=C0=D60:14 > =CA=D5=BC=FE=C8=CB: Yingjie Gu(yingjie); 'Juergen Schoenwaelder' > =B3=AD=CB=CD: 'Wesley Eddy'; 'Romascanu, Dan (Dan)'; sami@ietf.org;=20 > 'David Harrington'; rbonica@juniper.net > =D6=F7=CC=E2: RE: [sami] Welcome to SAMI and something you may like to = know. >=20 > I thought at the barBOF that the next step is to identify=20 > some use cases. It will be very beneficial to accelerate the=20 > progress by identifying some states (or conditions) which=20 > today's firewall or security devices can use to continue the=20 > proper function.=20 >=20 >=20 > Linda >=20 > > -----Original Message----- > > From: sami-bounces@ietf.org [mailto:sami-bounces@ietf.org]=20 > On Behalf=20 > > 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=20 > > Harrington'; rbonica@juniper.net > > Subject: Re: [sami] Welcome to SAMI and something you may=20 > like to know. > >=20 > > Hi Juergen, > >=20 > > I accept your suggestion. I will be more careful with my words. > >=20 > > We don't need yet more high level discussion on whether=20 > it's useful or=20 > > not. > >=20 > > Let's first figure out the context: scope, use cases and so on. > >=20 > >=20 > > Best Regards > > Gu Yingjie > >=20 > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > =B7=A2=BC=FE=C8=CB: sami-bounces@ietf.org = [mailto:sami-bounces@ietf.org] =B4=FA=B1=ED > > Juergen > > Schoenwaelder > > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA8=D4=C211=C8=D5 = =C0=D6=C0=D615:41 > > =CA=D5=BC=FE=C8=CB: Yingjie Gu(yingjie) > > =B3=AD=CB=CD: 'Wesley Eddy'; 'Romascanu, Dan (Dan)';=20 > rbonica@juniper.net; 'David=20 > > Harrington'; sami@ietf.org > > =D6=F7=CC=E2: Re: [sami] Welcome to SAMI and something you may like = to know. > >=20 > > On Thu, Aug 11, 2011 at 02:04:14PM +0800, Yingjie Gu(yingjie) wrote: > >=20 > > > 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=20 > > > Administration domain or between domains, and collect the=20 > 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,=20 > > > and, > > if > > we > > > go that far, the potential solutions for state migration. > >=20 > > For me, it is crucial to first define the scope before I can agree > > whether state migration is a useful concept or not.=20 > Depending on the=20 > > timing and the addressing/routing issues, other mechanisms might be=20 > > more appropriate. > >=20 > > Bottom line: Be careful with general statements like=20 > "Attendees agree=20 > > that state migration is useful." before we even agree on=20 > the context. > >=20 > > /js > >=20 > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > _______________________________________________ > > sami mailing list > > sami@ietf.org > > https://www.ietf.org/mailman/listinfo/sami > >=20 > > _______________________________________________ > > sami mailing list > > sami@ietf.org > > https://www.ietf.org/mailman/listinfo/sami >=20 > _______________________________________________ > sami mailing list > sami@ietf.org > https://www.ietf.org/mailman/listinfo/sami >=20 >=20 From melinda.shore@gmail.com Thu Aug 18 19:04:53 2011 Return-Path: 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 29D8F21F86EC for ; Thu, 18 Aug 2011 19:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 c7AHO3e24DKs for ; Thu, 18 Aug 2011 19:04:52 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id A84A721F86BE for ; Thu, 18 Aug 2011 19:04:52 -0700 (PDT) Received: by pzk33 with SMTP id 33so6589718pzk.18 for ; Thu, 18 Aug 2011 19:05:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=zv7FAOIul3SzvPjXbg7I9VFEhKdtG7oqgLovovdiyUU=; b=jy3zXTVoM4qxR22u2aIPcdowrudVJIRUcGw7bsIH97X8sYGZxhbPnfboPwfcGm+acD iFBuzIIuq80EbCw5NNkeApqaWi9/t4U5inkB2Osipt59uREyki5qiHynav/Gy4zEympM gTR0uq7Geku4nnW7+itqJmWpatZmnSPvB/3Rg= Received: by 10.142.14.5 with SMTP id 5mr142110wfn.159.1313719548132; Thu, 18 Aug 2011 19:05:48 -0700 (PDT) Received: from polypro.local (66-230-82-131-rb1.fai.dsl.dynamic.acsalaska.net [66.230.82.131]) by mx.google.com with ESMTPS id f8sm1927471pbk.54.2011.08.18.19.05.45 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 18 Aug 2011 19:05:47 -0700 (PDT) Message-ID: <4E4DC4F7.4060703@gmail.com> Date: Thu, 18 Aug 2011 18:05:43 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: sami@ietf.org 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> <003501cc5e0d$b1701440$14503cc0$@com> In-Reply-To: <003501cc5e0d$b1701440$14503cc0$@com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 02:04:53 -0000 On 8/18/11 5:16 PM, Yingjie Gu(yingjie) wrote: > 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. I'm still unclear on what middlebox state needs to be migrated with a VM. If the IP address is the same, if you're keeping the same ephemeral ports and the same MAC address, etc., and you're staying on the same subnet, what needs to be moved where? Melinda From narten@us.ibm.com Thu Aug 18 19:54:35 2011 Return-Path: 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 40CB421F863A for ; Thu, 18 Aug 2011 19:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.729 X-Spam-Level: X-Spam-Status: No, score=-105.729 tagged_above=-999 required=5 tests=[AWL=0.870, 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 6+EUn32BxdfZ for ; Thu, 18 Aug 2011 19:54:34 -0700 (PDT) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by ietfa.amsl.com (Postfix) with ESMTP id BD3C821F85C0 for ; Thu, 18 Aug 2011 19:54:34 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e39.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p7J2eBLM008121 for ; Thu, 18 Aug 2011 20:40:11 -0600 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id p7J2tLeq150338 for ; Thu, 18 Aug 2011 20:55:21 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p7J2tKl5032331 for ; Thu, 18 Aug 2011 20:55:21 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-49-158-96.mts.ibm.com [9.49.158.96]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p7J2tJ6X032239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Aug 2011 20:55:20 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p7J2tILI027722; Thu, 18 Aug 2011 22:55:18 -0400 Message-Id: <201108190255.p7J2tILI027722@cichlid.raleigh.ibm.com> To: "Yingjie Gu(yingjie)" In-reply-to: <003501cc5e0d$b1701440$14503cc0$@com> 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> <003501cc5e0d$b1701440$14503cc0$@com> Comments: In-reply-to "Yingjie Gu(yingjie)" message dated "Fri, 19 Aug 2011 09:16:56 +0800." Date: Thu, 18 Aug 2011 22:55:18 -0400 From: Thomas Narten Cc: 'David Harrington' , sami@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 02:54:35 -0000 "Yingjie Gu(yingjie)" writes: > 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. Well, there are 2 separate problems above. Each involves different state, and possibly different challenges. It would be useful to ask specifically for these two scenaros, whether there is a compelling need to migrate such state. I.e., who needs a solution to this problem? Which data center operator? Which customer? Or is this just a theoretical problem for which if there was a solution, it *might* get used? > 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. IMO, this is the less interesting question regarding scope. The first question is whether there is a compelling case to move state at all. If so, for which devices? And what do the vendors for those devices say? If the vendors that own the market for firewalls, load-balancer, are not interested in a solution as is being discussed here, what is the likelyhood that any solution (if it was developed) would ever be used? IMO, we should start by first talking about specific scenarios, where migrating state is necessary, and why the lack of a solution today is a problem that the IETF needs to develop solutions for. Thomas From j.schoenwaelder@jacobs-university.de Fri Aug 19 06:45:22 2011 Return-Path: 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 C41C621F86E0 for ; Fri, 19 Aug 2011 06:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.088 X-Spam-Level: X-Spam-Status: No, score=-103.088 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, 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 haDqmr7lcotd for ; Fri, 19 Aug 2011 06:45:22 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B316321F8B32 for ; Fri, 19 Aug 2011 06:45:21 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 424E320C1D; Fri, 19 Aug 2011 15:46:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id XSYivolhoooc; Fri, 19 Aug 2011 15:46:15 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0AFE320C18; Fri, 19 Aug 2011 15:45:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6D3FF1A34CC8; Fri, 19 Aug 2011 15:45:37 +0200 (CEST) Date: Fri, 19 Aug 2011 15:45:37 +0200 From: Juergen Schoenwaelder To: "Yingjie Gu(yingjie)" Message-ID: <20110819134536.GC28373@elstar.local> References: <004c01cc57ec$7f602ed0$7e208c70$@com> <20110811074034.GA12533@elstar.local> <005701cc5806$03cd8370$0b688a50$@com> <4A95BA014132FF49AE685FAB4B9F17F605189C80@dfweml504-mbx.china.huawei.com> <006001cc5cbb$de6c48e0$9b44daa0$@com> <4E4C6214.3010800@gmail.com> <12969308CE9E48DEAB5B5745D9482303@fanybP> <004c01cc5da6$5adb5660$10920320$@com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004c01cc5da6$5adb5660$10920320$@com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 'Melinda Shore' , 'Fan Yongbing' , sami@ietf.org Subject: Re: [sami] Welcome to SAMI and something you may like to know. X-BeenThere: sami@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: State Migration List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 13:45:22 -0000 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. 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: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ning.so@verizon.com Fri Aug 19 09:53:46 2011 Return-Path: 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 5535C21F8B1B for ; Fri, 19 Aug 2011 09:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.382 X-Spam-Level: X-Spam-Status: No, score=-1.382 tagged_above=-999 required=5 tests=[AWL=-1.183, BAYES_00=-2.599, J_CHICKENPOX_27=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_84=0.6] 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 z7W7UXZgbIWu for ; Fri, 19 Aug 2011 09:53:45 -0700 (PDT) Received: from fldsmtpe03.verizon.com (fldsmtpe03.verizon.com [140.108.26.142]) by ietfa.amsl.com (Postfix) with ESMTP id CF44C21F8A30 for ; Fri, 19 Aug 2011 09:53:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe03.verizon.com with ESMTP; 19 Aug 2011 16:54:41 +0000 From: "So, Ning" X-IronPort-AV: E=Sophos;i="4.68,251,1312156800"; d="scan'208";a="117822303" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi03.verizon.com with ESMTP; 19 Aug 2011 16:54:41 +0000 Received: from FHDP1LUMXC7V41.us.one.verizon.com ([169.254.1.38]) by FHDP1LUMXC7HB04.us.one.verizon.com ([166.68.59.191]) with mapi; Fri, 19 Aug 2011 12:54:41 -0400 To: David Harrington , "'Yingjie Gu(yingjie)'" , "sami@ietf.org" Date: Fri, 19 Aug 2011 12:54:37 -0400 Thread-Topic: [sami] Bringing new work into the IETF Thread-Index: AcxX7HVRuZrPxcYMSPmyPWkIvb/VTAASCu2AAAMDlYAABBPOgAEaloXwAAmfeMAAJ6eRMAAMDvuQADbiOxA= Message-ID: <6665BC1FEA04AB47B1F75FA641C43BC0814DB910@FHDP1LUMXC7V41.us.one.verizon.com> 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> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 16:53:46 -0000 RGF2aWQsDQoNCkkgYWdyZWUgd2l0aCB5b3UgdGhhdCB0aGUgcHJvYmxlbXMgYXJlIG5vdCBjbGVh cmx5IGRlZmluZWQsIHRoZSByZXF1aXJlbWVudHMgYXJlIG5vdCBjbGVhciwgYW5kIHRoZSBzY29w ZSBpcyB0b28gbGFyZ2UuICBIb3dldmVyLCBJIGRpc2FncmVlIHRoYXQgcHJvdmlkZXJzIGRvIG5v dCB3YW50IHN0YW5kYXJkaXplZCBzb2x1dGlvbi4gQXQgbGVhc3QgdGhhdCBpcyBub3QgdGhlIGNh c2UgZm9yIHRoZSB0cmFkaXRpb25hbCB0ZWxlY29tIHNlcnZpY2UgcHJvdmlkZXJzIHdobyBhcmUg YWxzbyB0cnlpbmcgdG8gYmVjb21lIHRoZSBjbG91ZC9kYXRhIGNlbnRlciBzZXJ2aWNlIHByb3Zp ZGVycy4gDQoNClRlbGVjb20gc2VydmljZSBwcm92aWRlciBzdWNoIGFzIFZlcml6b24gaGF2ZSBz aWduaWZpY2FudCBidXNpbmVzcyB3aXRoIGVudGVycHJpc2VzIGFuZCBnb3Zlcm5tZW50IGFnZW5j aWVzLiAgT25lIHNpZ25pZmljYW50IGNsb3VkIHNlcnZpY2UgYnVzaW5lc3MgZm9yIHRoYXQgbWFy a2V0IGluIHRoZSBmb3Jlc2VlYWJsZSBmdXR1cmUgaXMgdG8gaG9zdCBvdmVyZmxvdy9leHBhbnNp b24gY2FwYWNpdHkgZm9yIHRoZSBlbnRlcnByaXNlL2dvdmVybm1lbnQgZGF0YSBjZW50ZXJzLiAg VGhhdCBtZWFucyB0aGUgcHJvdmlkZXIgZGF0YSBjZW50ZXJzIHdpbGwgaGF2ZSB0byBiZSBtdWx0 aS10ZW5hbnQgaW4gbmF0dXJlIHdpdGggc2VhbWxlc3MgaW50ZXItd29ya2luZyB3aXRoIHRoZSBj dXN0b21lciBkYXRhIGNlbnRlcnMuICBUaGVyZSBhcmUgcXVpdGUgYSBmZXcgKEkgY2Fubm90IG51 bWJlciB0aGVtKSBoeXBlcnZpc29ycyBvdXQgdGhlcmUgaW4gdGhlIG1hcmtldCB0b2RheSwgYW5k IHRoZSBjdXN0b21lcnMgSSBrbm93IGhhdmUgYWxsIG9mIHRoZW0gKGFsdGhvdWdoIHVzdWFsbHkg ZWFjaCBjdXN0b21lciBoYXMgb25lIG9yIHR3byBoeXBlcnZpc29ycyBvbmx5KS4gICBXaXRob3V0 IHN0YW5kYXJkaXphdGlvbiBtZWFucyB0aGUgcHJvdmlkZXIgZGF0YSBjZW50ZXIgaGFzIHRvIGhh dmUgYWxsIG9mIHRoZSBoeXBlcnZpc29ycyBpbiBlYWNoIGFuZCBldmVyeSBkYXRhIGNlbnRlciBp biBvcmRlciB0byBwcm92aWRlIHRoZSBzZXJ2aWNlcywgYW5kIGl0IGFsc28gbWVhbnMgdGhlIHNl cnZlci9uZXR3b3JrIGNhcGFjaXR5IGluIHRoZSBwcm92aWRlciBkYXRhIGNlbnRlcnMgYXJlIGRl ZGljYXRlZCBwZXIgSHlwZXJ2aXNvciB3aXRob3V0IGNhcGFjaXR5IHNoYXJpbmcuICANCg0KT2Yg Y291cnNlIEkgYW0gb25seSBzdGF0aW5nIGEgbGFyZ2UgcHJvYmxlbSBmb3Igc29tZSBwcm92aWRl cnMsIG5vdCB0aGUgb25lcyBsaWtlIEdPT0dMRSBhbmQgWUFIT08gd2hvIGhhdmUgdG90YWwgY29u dHJvbCBvZiB0aGVpciBkYXRhIGNlbnRlcnMgc28gdGhleSBjYW4gZGVwbG95IHRoZSBzYW1lIGh5 cGVydmlzb3IgZXZlcnl3aGVyZS4gIEFuZCBJIGFsc28gdW5kZXJzdGFuZCB2ZW5kb3JzIGxvdmUg dGhlIHByb3ByaWV0YXJ5IGVudmlyb25tZW50IGJlY2F1c2Ugd2FzdGVkIHByb3ZpZGVyIGNhcGFj aXR5IG1lYW5zIG1vcmUgYnVzaW5lc3MgZm9yIHRoZW0uICBIb3dldmVyLCBwcm92aWRlcnMgYXJl IG5vdCBhbGwgZHVtbWllcy4gIFdlIHdpbGwgZXZlbnR1YWxseSBzZWUgd2hhdCBpcyBoYXBwZW5p bmcsIGFuZCB3ZSB3aWxsIHVzZSB0aGUgd2VsbC1lc3RhYmxpc2hlZCBlcXVpcG1lbnQgc2VsZWN0 aW9uIHByb2Nlc3MgKFJGUCkgdG8gZHJpdmUgc3RhbmRhcmRpemF0aW9uIGluIG9yZGVyIHRvIGJl Y29tZSBtb3JlIGVmZmljaWVudC4gIA0KDQpWZXJpem9uIGhhcyBhbHdheXMgYmVlbiBiaWcgb24g bmV0d29ya2luZyB0ZWNobm9sb2d5IHN0YW5kYXJkaXphdGlvbiwgYW5kIEkgZG9uJ3Qgc2VlIGFu eSBkaWZmZXJlbmNlIHdoZW4gaXQgY29tZXMgdG8gZGF0YSBjZW50ZXIgYW5kIGNsb3VkLiAgIEZy b20gbXkgcGVyc3BlY3RpdmUsIHN0YW5kYXJkaXphdGlvbiBpcyBnb29kIGZvciBJRVRGLCBhbmQg Z29vZCBmb3IgdGhlIGluZHVzdHJ5IGFzIGEgd2hvbGUuICANCiANCsKgDQpCZXN0IHJlZ2FyZHMs DQrCoA0KTmluZyBTbw0KVmVyaXpvbiBDb3Jwb3JhdGUgVGVjaG5vbG9neQ0KKG9mZmljZSkgOTcy LTcyOS03OTA1DQooQ2VsbCkgOTcyLTk1NS0wOTE0DQrCoA0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogc2FtaS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2FtaS1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGF2aWQgSGFycmluZ3Rvbg0KU2VudDogVGh1cnNkYXks IEF1Z3VzdCAxOCwgMjAxMSAxMDoyNSBBTQ0KVG86ICdZaW5namllIEd1KHlpbmdqaWUpJzsgc2Ft aUBpZXRmLm9yZw0KU3ViamVjdDogW3NhbWldIEJyaW5naW5nIG5ldyB3b3JrIGludG8gdGhlIElF VEYNCg0KSGkgWWluZ2ppZSwNCg0KSSB0cmltbWVkIHRoZSBDQzogbGlzdCB0byB0aGUgc2FtaSBt YWlsaW5nIGxpc3QuDQpUaG9zZSB3aG8gYXJlIGludGVyZXN0ZWQgaW4gdGhlIHNhbWkgZGlzY3Vz c2lvbiBjYW4gam9pbiB0aGUgc2FtaSBsaXN0IGFuZCBmaW5kIHRoaXMgZGlzY3Vzc2lvbiBpbiB0 aGUgc2FtaSBhcmNoaXZlLg0KDQpTbyBmYXIsIEkgdGhpbmsgeW91ciBwcm9wb3NhbCBpcyBub3Qg YmVpbmcgYWNjZXB0ZWQgYnkgdGhlIElFVEYgYmVjYXVzZSBpdCBpcyB0b28gZ2VuZXJhbCBhbmQg dG9vIGFic3RyYWN0Lg0KWW91IGFyZSBzdGlsbCB0cnlpbmcgdG8gZmlndXJlIG91dCB3aGF0IHBy b2JsZW0geW91IHdhbnQgdG8gc29sdmUuDQoNClRvIG1ha2UgVk0gbWlncmF0aW9uIHN0YW5kYXJk aXphdGlvbiBhIHZpYWJsZSBwcm9ibGVtIHRvIHdvcmsgb24sIHlvdSBwcm9iYWJseSBuZWVkIHRv IGdldCB2ZW5kb3JzIGFuZCBvcGVyYXRvcnMgdG8gYWxsIGFncmVlIG9uIGNvbXBsZXRlIHN0YW5k YXJkaXphdGlvbiBmb3IgdGhlaXIgdmFyaW91cyB0ZWNobm9sb2dpZXMgLSB2aXJ0dWFsaXphdGlv biwgVENQL0lQIHN0YWNrcywgbmV0d29yayBtYW5hZ2VtZW50IHByb3RvY29scywgYW5kIHNvIG9u LiANCkkgdGhpbmsgeW91IGFyZSB2ZXJ5IHVubGlrZWx5IHRvIGV2ZXIgYWNoaWV2ZSB0aGF0IGJl Y2F1c2UgdmVuZG9ycyB3YW50IHRvIGNvbnRpbnVlIHRvIGVuaGFuY2UgdGhlaXIgc29sdXRpb25z IHZlcnN1cyB0aGVpciBjb21wZXRpdG9ycy4NClN0YW5kYXJkaXphdGlvbiBpcyBub3QgYXBwcm9w cmlhdGUgdG8gc29sdmUgZXZlcnkgcHJvYmxlbS4gDQoNCk1vc3QgZW50ZXJwcmlzZXMvcHJvdmlk ZXJzIHdpbGwgY2hvb3NlIGEgc3BlY2lmaWMgdmlydHVhbGl6YXRpb24gc29sdXRpb24sIHN1Y2gg YXMgVk13YXJlLg0KSG93IFZNIG1pZ3JhdGlvbiBpcyBkb25lIGRlcGVuZHMgYSBncmVhdCBkZWFs IG9uIHRoZSB2aXJ0dWFsaXphdGlvbiBzb2x1dGlvbiBpbiB1c2UuDQpIeXBlcnZpc29ycyBoYXZl IG5vdCBiZWVuIHN0YW5kYXJkaXplZCBiZWNhdXNlIHRoZSBjb21wYW5pZXMgdGhhdCBwcm92aWRl IHZpcnR1YWxpemF0aW9uIHNvbHV0aW9ucyBnYWluIGNvbXBldGl0aXZlIGFkdmFudGFnZSBmcm9t IHRoZWlyIGh5cGVydmlzb3IgY2FwYWJpbGl0aWVzLiBUaGV5IGRvbid0IG5lY2Vzc2FyaWx5IHdh bnQgdG8gc3RhbmRhcmRpemUgdGhlaXIgaHlwZXJ2aXNvcnMgYWNyb3NzIHZlbmRvcnMuDQoNCk1v c3QgZW50ZXJwcmlzZXMvcHJvdmlkZXJzIHdpbGwgY2hvb3NlIGEgc3BlY2lmaWMgc3RvcmFnZSBz b2x1dGlvbiwgc3VjaCBhcyBFTUMgb3IgTmV0QXBwLg0KSG93IFZNIG1pZ3JhdGlvbiBpcyBkb25l IGRlcGVuZHMgYSBncmVhdCBkZWFsIG9uIHRoZSBzdG9yYWdlIHNvbHV0aW9uIGluIHVzZS4NClN0 b3JhZ2UgZGV2aWNlcyB1c3VhbGx5IHVzZSBzdGFuZGFyZHMsIGJ1dCBoYXZlIG5vdCBiZWVuIGNv bXBsZXRlbHkgc3RhbmRhcmRpemVkIGJlY2F1c2UgdGhlIGNvbXBhbmllcyB0aGF0IHByb3ZpZGUg c3RvcmFnZSBzb2x1dGlvbnMgZ2FpbiBjb21wZXRpdGl2ZSBhZHZhbnRhZ2UgZnJvbSB0aGVpciBz dG9yYWdlIHNvbHV0aW9uIGVuaGFuY2VtZW50cy4gVGhleSBkb24ndCB3YW50IHRvIHRvdGFsbHkg c3RhbmRhcmRpemUgc3RvcmFnZSBhY3Jvc3MgdmVuZG9ycy4NCg0KTW9zdCBlbnRlcnByaXNlcy9w cm92aWRlcnMgd2lsbCBjaG9vc2Ugc3BlY2lmaWMgZXF1aXBtZW50IHZlbmRvcnMgdG8gZGVwbG95 IGluIHRoZWlyIG5ldHdvcmtzLg0KVGhvc2UgY2hvaWNlcyBvZnRlbiBoYXZlIHRvIGRvIHdpdGgg dGhlIHByb3ByaWV0YXJ5IGVuaGFuY2VtZW50cyBvZmZlcmVkIGJ5IGRpZmZlcmVudCB2ZW5kb3Jz Lg0KVGhlIHZlbmRvcnMgaGF2ZSBubyBkZXNpcmUgdG8gYWxsIG9mZmVyIGlkZW50aWNhbCBwcm9k dWN0cyBhbmQgaWRlbnRpY2FsIGZlYXR1cmVzLg0KSG93IFZNIG1pZ3JhdGlvbiBpcyBkb25lIGRl cGVuZHMgYSBncmVhdCBkZWFsIG9uIHRoZSBuZXR3b3JraW5nIGVxdWlwbWVudCBpbiB1c2UuDQpJ UC9UQ1Agc3RhY2tzIGhhdmUgbm90IGJlZW4gdG90YWxseSBzdGFuZGFyZGl6ZWQgYmVjYXVzZSB0 aGUgY29tcGFuaWVzIHRoYXQgcHJvdmlkZSBuZXR3b3JraW5nIGVxdWlwbWVudCBnYWluIGNvbXBl dGl0aXZlIGFkdmFudGFnZSBmcm9tIHRoZWlyIGVxdWlwbWVudCdzIGVuaGFuY2VkIGNhcGFiaWxp dGllcy4gVGhleSBkb24ndCB3YW50IHRvIHRvdGFsbHkgc3RhbmRhcmRpemUgdGhlaXIgZXF1aXBt ZW50IGFjcm9zcyB2ZW5kb3JzLg0KDQpNb3N0IGVudGVycHJpc2VzL3Byb3ZpZGVycyB3aWxsIGNo b29zZSBzcGVjaWZpYyBlcXVpcG1lbnQgdG8gZGVwbG95IGluIHRoZWlyIG5ldHdvcmtzLg0KVGhv c2UgY2hvaWNlcyBvZnRlbiBoYXZlIHRvIGRvIHdpdGggdGhlIHByb3ByaWV0YXJ5IHNvbHV0aW9u cyB0byBtYW5hZ2UgdGhlIGNob3NlbiBlcXVpcG1lbnQuDQpUaGUgdmVuZG9ycyBoYXZlIG5vIGRl c2lyZSB0byBhbGwgb2ZmZXIgaWRlbnRpY2FsIG1hbmFnZW1lbnQgZmVhdHVyZXMuDQpIb3cgYSBt aWdyYXRpb24gaXMgZG9uZSBkZXBlbmRzIGEgZ3JlYXQgZGVhbCBvbiB0aGUgbmV0d29ya2luZyBt YW5hZ2VtZW50IHRvb2xzIGluIHVzZS4NCkNMSXMgYW5kIHByb3ByaWV0YXJ5IE1JQiBtb2R1bGVz IGFuZCBvdGhlciBtYW5hZ2VtZW50IGludGVyZmFjZXMgaGF2ZSBub3QgYmVlbiB0b3RhbGx5IHN0 YW5kYXJkaXplZCBiZWNhdXNlIHRoZSBjb21wYW5pZXMgdGhhdCBwcm92aWRlIHRoZXNlIHRvb2xz IGdhaW4gY29tcGV0aXRpdmUgYWR2YW50YWdlIGZyb20gdGhlaXIgbWFuYWdlbWVudCBwcm9kdWN0 cycNCmVuaGFuY2VkIGNhcGFiaWxpdGllcy4gVGhleSBkb24ndCB3YW50IHRvIHRvdGFsbHkgc3Rh bmRhcmRpemUgdGhlaXIgbWFuYWdlbWVudCBpbnRlcmZhY2VzLg0KDQpUbyBzdGFuZGFyZGl6ZSBW TSBtaWdyYXRpb24gYWNyb3NzIGFsbCB0aGUgVk0gaW1wbGVtZW50YXRpb25zLCB0aGUgVENQL0lQ IGltcGxlbWVudGF0aW9ucywgdGhlIHN0b3JhZ2UgaW1wbGVtZW50YXRpb25zLCB0aGUgcm91dGlu ZyBpbXBsZW1lbnRhdGlvbnMsIHRoZSBzZWN1cml0eSBpbXBsZW1lbnRhdGlvbnMsIHRoZSBhcHBs aWNhdGlvbiBpbXBsZW1lbnRhdGlvbnMsIHRoZSBuZXR3b3JrIG1hbmFnZW1lbnQgaW1wbGVtZW50 YXRpb25zLCBhbmQgdGhlIGVudGVycHJpc2Utc3BlY2lmaWMgZGVwbG95bWVudCBjaG9pY2VzLCBp cyBsaWtlICJib2lsaW5nIHRoZSBvY2VhbiIuDQpOb3QgYSB2ZXJ5IGFjaGlldmVhYmxlIGdvYWwu DQoNClRoZSBJRVRGIGRvZXMgKiplbmdpbmVlcmluZyoqLg0KWW91IHdvdWxkIGRvIG11Y2ggYmV0 dGVyIHRvIGZvY3VzIHlvdXIgZW5lcmd5IG9uIGEgKipzbWFsbCoqIHByb2JsZW0sIHNvbHZhYmxl IGJ5IHN0YW5kYXJkaXphdGlvbiwgdGhhdCBjYW4gYmUgdHVybmVkIGludG8gYW4gZW5naW5lZXJp bmcgcHJvamVjdCBhcHByb3ByaWF0ZSB0byB0aGUgSUVURi4gDQoNCkZvciBleGFtcGxlLCB5b3Ug bWlnaHQgZm9jdXMgb24gZGV2ZWxvcGluZyBhIHN0YW5kYXJkIERIQ1AgYXR0cmlidXRlIG9yIGEg c3RhbmRhcmQgbmV0Y29uZi9ZQU5HIG1vZHVsZSBmb3Igc29tZSBhc3BlY3Qgb2YgdmlydHVhbCBo b3N0IGNvbmZpZ3VyYXRpb24gdGhhdCBjb3VsZCBiZSByZWFzb25hYmx5IHN0YW5kYXJkaXplZCBh Y3Jvc3MgdmlydHVhbGl6YXRpb24gcGxhdGZvcm1zIGFuZCBlcXVpcG1lbnQgdmVuZG9ycy4gRWFj aCBzdGFuZGFyZGl6YXRpb24gb2YgYSBzbWFsbCBwaWVjZSBvZiBJbnRlcm5ldC1yZWxhdGVkIFZN IGNvbmZpZ3VyYXRpb24gY291bGQgaGVscCBzdGFuZGFyZGl6ZSBWTSBtaWdyYXRpb24gaW4gdGhl IGxvbmcgcnVuLiBBbmQgdGhhdCB3b3VsZCBiZSBlbmdpbmVlcmluZyB3b3JrIGFwcHJvcHJpYXRl IHRvIHRoZSBJRVRGLiANCg0KRGF2aWQgSGFycmluZ3Rvbg0KRGlyZWN0b3IsIElFVEYgVHJhbnNw b3J0IEFyZWENCmlldGZkYmhAY29tY2FzdC5uZXQgKHByZWZlcnJlZCBmb3IgaWV0ZikgZGJoYXJy aW5ndG9uQGh1YXdlaXN5bWFudGVjLmNvbQ0KKzEgNjAzIDgyOCAxNDAxIChjZWxsKQ0KIA0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFlpbmdqaWUgR3UoeWluZ2ppZSkg W21haWx0bzpndXlpbmdqaWVAaHVhd2VpLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIEF1Z3VzdCAx OCwgMjAxMSA4OjAzIEFNDQo+IFRvOiAnU28sIE5pbmcnOyAnTGluZGEgRHVuYmFyJzsgJ0p1ZXJn ZW4gU2Nob2Vud2FlbGRlcicNCj4gQ2M6ICdXZXNsZXkgRWRkeSc7ICdSb21hc2NhbnUsIERhbiAo RGFuKSc7IHJib25pY2FAanVuaXBlci5uZXQ7ICdEYXZpZCANCj4gSGFycmluZ3Rvbic7IHNhbWlA aWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtzYW1pXSBXZWxjb21lIHRvIFNBTUkgYW5kIHNvbWV0 aGluZyB5b3UgbWF5IGxpa2UgdG8gDQo+IGtub3cuDQo+IA0KPiBOaW5nLA0KPiANCj4gV2hlbiB3 ZSB0YWxrZWQgYXQgUXVlYmVjLCBJIHJlbWVtYmVyZWQgdGhhdCB5b3UgaGF2ZSBpbXByZXNzaXZl IA0KPiB1bmRlcnN0YW5kaW5nIG9uIFZNIG1pZ3JhdGlvbiByZXF1aXJlbWVudHMgaW4vYmV0d2Vl biBzdWJuZXRzLiBIb3BlIA0KPiB5b3UgY2FuIHNoYXJlIHlvdXIgdXNlIGNhc2VzIGZyb20gcHJv dmlkZXIncyBwZXJzcGVjdGl2ZS4NCj4gSSBoYXZlIHRhbGtlZCB3aXRoIHR3byBwcm92aWRlcnMg aW4gZGV0YWlsLCBhbmQgdGhleSBib3RoIHNlZSB0aGUgDQo+IHN0cm9uZyByZXF1aXJlbWVudHMg Zm9yIHN0YXRlIG1pZ3JhdGlvbiBhcyBWTSBtaWdyYXRlcy4NCj4gUGVyaGFwcyB3ZSBuZWVkIHRv IGRvY3VtZW50IHByb3ZpZGVyJ3MgcmVxdWlyZW1lbnRzIGZvciBwZW9wbGUncyANCj4gcmVmZXJl bmNlLiBJIGFtIHdvcmtpbmcgd2l0aCBwcm92aWRlcnMgb24gdGhpcyBkb2N1bWVudCB0byBpbnRy b2R1Y2UgDQo+IHVzZSBjYXNlcy4NCj4gDQo+IA0KPiANCj4gQmVzdCBSZWdhcmRzDQo+IEd1IFlp bmdqaWUNCj4gDQo+IA0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7tuS6ujogU28s IE5pbmcgW21haWx0bzpuaW5nLnNvQHZlcml6b24uY29tXQ0KPiDlj5HpgIHml7bpl7Q6IDIwMTHl ubQ45pyIMTfml6Ug5LmQ5LmQMjE6NTkNCj4g5pS25Lu25Lq6OiBZaW5namllIEd1KHlpbmdqaWUp OyAnTGluZGEgRHVuYmFyJzsgJ0p1ZXJnZW4gU2Nob2Vud2FlbGRlcicNCj4g5oqE6YCBOiAnV2Vz bGV5IEVkZHknOyAnUm9tYXNjYW51LCBEYW4gKERhbiknOyByYm9uaWNhQGp1bmlwZXIubmV0OyAn RGF2aWQgDQo+IEhhcnJpbmd0b24nOyBzYW1pQGlldGYub3JnDQo+IOS4u+mimDogUkU6IFtzYW1p XSBXZWxjb21lIHRvIFNBTUkgYW5kIHNvbWV0aGluZyB5b3UgbWF5IGxpa2UgdG8ga25vdy4NCj4g DQo+IFlpbmdqaWUsDQo+IA0KPiBZb3UgbWlnaHQgd2FudCB0byBjb25zaWRlciBsaW1pdGluZyB0 aGUgc2NvcGUgdG8gcHJvYmxlbSBkZWZpbml0aW9uIA0KPiBhbmQgcHJvdmlkZXIgcmVxdWlyZW1l bnRzIGNvbGxlY3Rpb24gZmlyc3QuICBJIGtub3cgYSBsb3Qgb2Ygd29yayBoYXMgDQo+IGdvbmUg aW50byBkb2N1bWVudGluZyB3aGF0IGlzIGF2YWlsYWJsZSB0b2RheS4gIEhvd2V2ZXIsIHRoZSBw cm92aWRlciANCj4gcmVxdWlyZW1lbnRzIGluIHRoaXMNCj4gYXJlYSBpcyBzdGlsbCByYXRoZXIg dGhpbi4gICBGb3IgZXhhbXBsZSwgdGhlIHJlcXVpcmVtZW50cyANCj4gZm9yIG9wdGltaXphdGlv bi1iYXNlZCBtaWdyYXRpb24gY2FuIGJlIHF1aXRlIGRpZmZlcmVudCBmcm9tIGZhaWx1cmUgDQo+ IHJlc3RvcmF0aW9uLWJhc2VkIG1pZ3JhdGlvbi4gIFRoZSB0eXBlIG9mIHNlcnZpY2VzIHRoZSBW TXMgYXJlIA0KPiBzdXBwb3J0aW5nIGNhbiBhbHNvIGltcGFjdCB0aGUgbWlncmF0aW9uIHJlcXVp cmVtZW50cywgdGh1cyBpbXBhY3RpbmcgDQo+IHRoZSBzb2x1dGlvbnMuICBEZWZpbmluZyBkaWZm ZXJlbnQgdHlwZXMgb2YgVk0gbWlncmF0aW9uIGFuZCB0aGUgDQo+IGFzc29jaWF0ZWQgcmVxdWly ZW1lbnRzIHNob3VsZCBiZSBhIGhpZ2hlciBwcmlvcml0eSwgaW4gbXkgb3Bpbmlvbi4NCj4gDQo+ ICANCj4gQmVzdCByZWdhcmRzLA0KPiAgDQo+IE5pbmcgU28NCj4gVmVyaXpvbiBDb3Jwb3JhdGUg VGVjaG5vbG9neQ0KPiAob2ZmaWNlKSA5NzItNzI5LTc5MDUNCj4gKENlbGwpIDk3Mi05NTUtMDkx NA0KPiAgDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBzYW1pLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzYW1pLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiAN Cj4gT2YgWWluZ2ppZSBHdSh5aW5namllKQ0KPiBTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAxNywg MjAxMSAzOjU5IEFNDQo+IFRvOiAnTGluZGEgRHVuYmFyJzsgJ0p1ZXJnZW4gU2Nob2Vud2FlbGRl cicNCj4gQ2M6ICdXZXNsZXkgRWRkeSc7ICdSb21hc2NhbnUsIERhbiAoRGFuKSc7IHJib25pY2FA anVuaXBlci5uZXQ7ICdEYXZpZCANCj4gSGFycmluZ3Rvbic7IHNhbWlAaWV0Zi5vcmcNCj4gU3Vi amVjdDogUmU6IFtzYW1pXSBXZWxjb21lIHRvIFNBTUkgYW5kIHNvbWV0aGluZyB5b3UgbWF5IGxp a2UgdG8gDQo+IGtub3cuDQo+IA0KPiBUaGUgZm9sbG93aW5nIGlzIGEgc2NvcGUgc3VnZ2VzdGVk IGJ5IERyLiBGYW4uDQo+IA0KPiAiIEFjY29yZGluZyB0byB0aGUgY3VycmVudCBpbXBsZW1lbnRh dGlvbixWTSBtaWdyYXRpb24gaXMgc2NvcGVkIGluIGEgDQo+IGxheWVyDQo+IDIgbmV0d29yayB3 aXRoIHNoYXJlZCBzdG9yYWdlLktleSBmYWN0b3JzIHRoYXQgZGVjaWRlIHdoZXRoZXIgaG90IA0K PiBtaWdyYXRpb24gaXMgc3VjY2Vzc2Z1bCBpbmNsdWRlcyxmcm9tIHRoZSBuZXR3b3JrJ3Mgc2lk ZSwgYmFuZHdpdGggYW5kIA0KPiBkZWxheS5FdmVuIHRoZSBtaWdyYXRpb24gaGFwcGVucyBiZXR3 ZWVuIHR3byBzaXRlcyxpdCBtYXkgc3VjY2VlZCBpZiANCj4gdGhlIGJhbmR3aWR0aCBpcyB3aWRl IGVub3VnaCBhbmQgdGhlIGRlbGF5IGlzIHNtYWxsIGVub3VnaC4NCj4gIA0KPiBTbyxwZWhoYXBz IHdlIGNhbiBkZWZpbmUgdGhlIHNjb3BlIGFzIHN1Y2g6QSBsYXllciAyIHN1Ym5ldCB3aXRoIGdv b2QgDQo+IGVub3VnaCBwZXJmb3JtYW5jZSB3aGljaCBtYWtlcyB0aGUgaG90IG1pZ3JhdGlvbiBz dWNjZXNzZnVsLiINCj4gDQo+IFdoYXQgaXMgeW91ciBvcGluaW9uIG9uIHRoaXMgc2NvcGU/DQo+ IA0KPiBCZXN0IFJlZ2FyZHMNCj4gR3UgWWluZ2ppZQ0KPiANCj4gLS0tLS3pgq7ku7bljp/ku7Yt LS0tLQ0KPiDlj5Hku7bkuro6IExpbmRhIER1bmJhciBbbWFpbHRvOmxpbmRhLmR1bmJhckBodWF3 ZWkuY29tXQ0KPiDlj5HpgIHml7bpl7Q6IDIwMTHlubQ45pyIMTLml6Ug5LmQ5LmQMDoxNA0KPiDm lLbku7bkuro6IFlpbmdqaWUgR3UoeWluZ2ppZSk7ICdKdWVyZ2VuIFNjaG9lbndhZWxkZXInDQo+ IOaKhOmAgTogJ1dlc2xleSBFZGR5JzsgJ1JvbWFzY2FudSwgRGFuIChEYW4pJzsgc2FtaUBpZXRm Lm9yZzsgJ0RhdmlkIA0KPiBIYXJyaW5ndG9uJzsgcmJvbmljYUBqdW5pcGVyLm5ldA0KPiDkuLvp opg6IFJFOiBbc2FtaV0gV2VsY29tZSB0byBTQU1JIGFuZCBzb21ldGhpbmcgeW91IG1heSBsaWtl IHRvIGtub3cuDQo+IA0KPiBJIHRob3VnaHQgYXQgdGhlIGJhckJPRiB0aGF0IHRoZSBuZXh0IHN0 ZXAgaXMgdG8gaWRlbnRpZnkgc29tZSB1c2UgDQo+IGNhc2VzLiBJdCB3aWxsIGJlIHZlcnkgYmVu ZWZpY2lhbCB0byBhY2NlbGVyYXRlIHRoZSBwcm9ncmVzcyBieSANCj4gaWRlbnRpZnlpbmcgc29t ZSBzdGF0ZXMgKG9yIGNvbmRpdGlvbnMpIHdoaWNoIHRvZGF5J3MgZmlyZXdhbGwgb3IgDQo+IHNl Y3VyaXR5IGRldmljZXMgY2FuIHVzZSB0byBjb250aW51ZSB0aGUgcHJvcGVyIGZ1bmN0aW9uLg0K PiANCj4gDQo+IExpbmRhDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4g RnJvbTogc2FtaS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2FtaS1ib3VuY2VzQGlldGYub3Jn XQ0KPiBPbiBCZWhhbGYNCj4gPiBPZiBZaW5namllIEd1KHlpbmdqaWUpDQo+ID4gU2VudDogVGh1 cnNkYXksIEF1Z3VzdCAxMSwgMjAxMSA0OjA3IEFNDQo+ID4gVG86ICdKdWVyZ2VuIFNjaG9lbndh ZWxkZXInDQo+ID4gQ2M6ICdXZXNsZXkgRWRkeSc7ICdSb21hc2NhbnUsIERhbiAoRGFuKSc7IHNh bWlAaWV0Zi5vcmc7ICdEYXZpZCANCj4gPiBIYXJyaW5ndG9uJzsgcmJvbmljYUBqdW5pcGVyLm5l dA0KPiA+IFN1YmplY3Q6IFJlOiBbc2FtaV0gV2VsY29tZSB0byBTQU1JIGFuZCBzb21ldGhpbmcg eW91IG1heQ0KPiBsaWtlIHRvIGtub3cuDQo+ID4gDQo+ID4gSGkgSnVlcmdlbiwNCj4gPiANCj4g PiBJIGFjY2VwdCB5b3VyIHN1Z2dlc3Rpb24uIEkgd2lsbCBiZSBtb3JlIGNhcmVmdWwgd2l0aCBt eSB3b3Jkcy4NCj4gPiANCj4gPiBXZSBkb24ndCBuZWVkIHlldCBtb3JlIGhpZ2ggbGV2ZWwgZGlz Y3Vzc2lvbiBvbiB3aGV0aGVyDQo+IGl0J3MgdXNlZnVsIG9yDQo+ID4gbm90Lg0KPiA+IA0KPiA+ IExldCdzIGZpcnN0IGZpZ3VyZSBvdXQgdGhlIGNvbnRleHQ6IHNjb3BlLCB1c2UgY2FzZXMgYW5k IHNvIG9uLg0KPiA+IA0KPiA+IA0KPiA+IEJlc3QgUmVnYXJkcw0KPiA+IEd1IFlpbmdqaWUNCj4g PiANCj4gPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+ID4g5Y+R5Lu25Lq6OiBzYW1pLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpzYW1pLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqA0KPiA+IEp1 ZXJnZW4NCj4gPiBTY2hvZW53YWVsZGVyDQo+ID4g5Y+R6YCB5pe26Ze0OiAyMDEx5bm0OOaciDEx 5pelIOS5kOS5kDE1OjQxDQo+ID4g5pS25Lu25Lq6OiBZaW5namllIEd1KHlpbmdqaWUpDQo+ID4g 5oqE6YCBOiAnV2VzbGV5IEVkZHknOyAnUm9tYXNjYW51LCBEYW4gKERhbiknOw0KPiByYm9uaWNh QGp1bmlwZXIubmV0OyAnRGF2aWQNCj4gPiBIYXJyaW5ndG9uJzsgc2FtaUBpZXRmLm9yZw0KPiA+ IOS4u+mimDogUmU6IFtzYW1pXSBXZWxjb21lIHRvIFNBTUkgYW5kIHNvbWV0aGluZyB5b3UgbWF5 IGxpa2UgdG8NCmtub3cuDQo+ID4gDQo+ID4gT24gVGh1LCBBdWcgMTEsIDIwMTEgYXQgMDI6MDQ6 MTRQTSArMDgwMCwgWWluZ2ppZSBHdSh5aW5namllKQ0Kd3JvdGU6DQo+ID4gDQo+ID4gPiBBdHRl bmRlZXMgYWdyZWUgdGhhdCBzdGF0ZSBtaWdyYXRpb24gaXMgdXNlZnVsLiBXaGF0IHdlIG5lZWQg dG8NCmRvDQo+ID4gbmV4dCBpcw0KPiA+ID4gdG8gbmFycm93IGRvd24gdGhlIHNjb3BlLCBlLmcu IHN0YXRlIG1pZ3JhdGlvbiB3aXRoaW4gdGhlIHNhbWUgDQo+ID4gPiBBZG1pbmlzdHJhdGlvbiBk b21haW4gb3IgYmV0d2VlbiBkb21haW5zLCBhbmQgY29sbGVjdCB0aGUNCj4gdXNlIGNhc2VzDQo+ ID4gaW4NCj4gPiB0aGF0DQo+ID4gPiBzY29wZS4gVGhlbiB3ZSBuZWVkIHRvIGZpZ3VyZSBvdXQg d2hhdCBraW5kIG9mIHN0YXRlIG5lZWQgdG8gYmUNCj4gPiBtaWdyYXRlZA0KPiA+IGluDQo+ID4g PiB0aGUgbmFycm93IHNjb3BlLCB3aGF0J3MgdGhlIGNvbW1vbiByZXByZXNlbnRhdGlvbiBvZiB0 aGUNCnN0YXRlcywgDQo+ID4gPiBhbmQsDQo+ID4gaWYNCj4gPiB3ZQ0KPiA+ID4gZ28gdGhhdCBm YXIsIHRoZSBwb3RlbnRpYWwgc29sdXRpb25zIGZvciBzdGF0ZSBtaWdyYXRpb24uDQo+ID4gDQo+ ID4gRm9yIG1lLCBpdCBpcyBjcnVjaWFsIHRvIGZpcnN0IGRlZmluZSB0aGUgc2NvcGUgYmVmb3Jl IEkgY2FuIGFncmVlDQoNCj4gPiB3aGV0aGVyIHN0YXRlIG1pZ3JhdGlvbiBpcyBhIHVzZWZ1bCBj b25jZXB0IG9yIG5vdC4gDQo+IERlcGVuZGluZyBvbiB0aGUNCj4gPiB0aW1pbmcgYW5kIHRoZSBh ZGRyZXNzaW5nL3JvdXRpbmcgaXNzdWVzLCBvdGhlciBtZWNoYW5pc21zIG1pZ2h0DQpiZSANCj4g PiBtb3JlIGFwcHJvcHJpYXRlLg0KPiA+IA0KPiA+IEJvdHRvbSBsaW5lOiBCZSBjYXJlZnVsIHdp dGggZ2VuZXJhbCBzdGF0ZW1lbnRzIGxpa2UNCj4gIkF0dGVuZGVlcyBhZ3JlZQ0KPiA+IHRoYXQg c3RhdGUgbWlncmF0aW9uIGlzIHVzZWZ1bC4iIGJlZm9yZSB3ZSBldmVuIGFncmVlIG9uDQo+IHRo ZSBjb250ZXh0Lg0KPiA+IA0KPiA+IC9qcw0KPiA+IA0KPiA+IC0tDQo+ID4gSnVlcmdlbiBTY2hv ZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4gPiBQ aG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEsIDI4NzU5IEJyZW1l biwNCkdlcm1hbnkNCj4gPiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwOi8v d3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHNhbWkgbWFpbGluZyBsaXN0DQo+ID4gc2FtaUBp ZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FtaQ0K PiA+IA0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4gc2FtaSBtYWlsaW5nIGxpc3QNCj4gPiBzYW1pQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYW1pDQo+IA0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzYW1pIG1haWxpbmcgbGlzdA0KPiBz YW1pQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Ft aQ0KPiANCj4gDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpzYW1pIG1haWxpbmcgbGlzdA0Kc2FtaUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zYW1pDQo= From melinda.shore@gmail.com Fri Aug 19 12:13:19 2011 Return-Path: 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 E8AB721F8B59 for ; Fri, 19 Aug 2011 12:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.479 X-Spam-Level: X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Aw62Bkrw7bKh for ; Fri, 19 Aug 2011 12:13:17 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id DBBD321F8BF7 for ; Fri, 19 Aug 2011 12:13:16 -0700 (PDT) Received: by pzk33 with SMTP id 33so8841207pzk.18 for ; Fri, 19 Aug 2011 12:14:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=eEMzKbti4shf/XgBk/cacg7QxJaHjVywIDe4qGkMhZE=; b=l+RnOJiO2UwqJQRhwJVkR63MltfM7/QOSUYTdnUYwniGmdtMDytoSkHnF0IKlBNQAN SRDSgeICPi0fuD3Kj0czjtw3x1SKLrb5vc6AYKNKxpDBAM0bYpGg/cXHKldTJnK7I3sF w+GL0rqsQrxPphg2VlbVkbEZVlTfctOFPqiPs= Received: by 10.143.82.5 with SMTP id j5mr38907wfl.280.1313781254246; Fri, 19 Aug 2011 12:14:14 -0700 (PDT) Received: from [137.229.12.236] (drake.swits.alaska.edu [137.229.12.236]) by mx.google.com with ESMTPS id i8sm2544177pbi.76.2011.08.19.12.14.12 (version=SSLv3 cipher=OTHER); Fri, 19 Aug 2011 12:14:13 -0700 (PDT) Message-ID: <4E4EB603.7080903@gmail.com> Date: Fri, 19 Aug 2011 11:14:11 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: sami@ietf.org 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> <6665BC1FEA04AB47B1F75FA641C43BC0814DB910@FHDP1LUMXC7V41.us.one.verizon.com> In-Reply-To: <6665BC1FEA04AB47B1F75FA641C43BC0814DB910@FHDP1LUMXC7V41.us.one.verizon.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 19:13:19 -0000 On 08/19/2011 08:54 AM, So, Ning wrote: > [ ... ] > Telecom service provider such as Verizon have significant business > with enterprises and government agencies. One significant cloud > service business for that market in the foreseeable future is to > host overflow/expansion capacity for the enterprise/government > data centers. That means the provider data centers will have to > be multi-tenant in nature with seamless inter-working with the > customer data centers. There are quite a few (I cannot number them) > hypervisors out there in the market today, and the customers I know > have all of them (although usually each customer has one or two > hypervisors only). Without standardization means the provider > data center has to have all of the hypervisors in each and every > data center in order to provide the services, and it also means > the server/network capacity in the provider data centers are > dedicated per Hypervisor without capacity sharing. You guys are being asked for a technical discussion of what's being proposed. This is marketing. I've mostly been appalled by how stuff (I initially typed "work," realized that that was not correct, and "stuff" is the only thing I could come up with to describe what's under discussion) related to clouds/data centers has been brought to the IETF. There's never been a clear statement of need for a specific piece of work, no requirements, just fishing for something that someone might possibly be able to get a publication out of. The service migration stuff struck me as different, because for better or worse there's a lot of flow-coupled state inside the network, often related to security but sometimes related to transport optimization, policy routing, etc. How to move that when live network sessions move is a real problem, and one that's hard to solve. Unfortunately you guys totally blew that one out of the water when you reframed this as 1) moving VMs, and 2) moving them within the same subnet. If this is really, truly, honestly what you want to do, you're going to start to identify specific use cases and pieces of state that you think will need to be transferred. The only thing I can come up with is address/port mappings in switches, and honestly that's not very compelling. This piece of email from Ning continues the vagueness and really doesn't provide any information that might help evaluate the work on its technical merit. Melinda Shore From narten@us.ibm.com Mon Aug 22 05:24:23 2011 Return-Path: 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 7500721F8B48 for ; Mon, 22 Aug 2011 05:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 q9G8niWqyrLn for ; Mon, 22 Aug 2011 05:24:22 -0700 (PDT) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by ietfa.amsl.com (Postfix) with ESMTP id ABEAA21F8B46 for ; Mon, 22 Aug 2011 05:24:19 -0700 (PDT) Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e7.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p7MBwbDW027856 for ; Mon, 22 Aug 2011 07:58:37 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p7MCPBwY222600 for ; Mon, 22 Aug 2011 08:25:11 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p7MCPBBg030737 for ; Mon, 22 Aug 2011 09:25:11 -0300 Received: from cichlid.raleigh.ibm.com (sig-9-48-44-45.mts.ibm.com [9.48.44.45]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p7MCP9td030604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Aug 2011 09:25:10 -0300 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p7MCP8Ih021246; Mon, 22 Aug 2011 08:25:08 -0400 Message-Id: <201108221225.p7MCP8Ih021246@cichlid.raleigh.ibm.com> To: "So, Ning" In-reply-to: <6665BC1FEA04AB47B1F75FA641C43BC0814DB910@FHDP1LUMXC7V41.us.one.verizon.com> 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> <6665BC1FEA04AB47B1F75FA641C43BC0814DB910@FHDP1LUMXC7V41.us.one.verizon.com> Comments: In-reply-to "So, Ning" message dated "Fri, 19 Aug 2011 12:54:37 -0400." Date: Mon, 22 Aug 2011 08:25:08 -0400 From: Thomas Narten Cc: "'Yingjie Gu\(yingjie\)'" , David Harrington , "sami@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 12:24:23 -0000 Just so I understand... "So, Ning" writes: > Telecom service provider such as Verizon have significant business > with enterprises and government agencies. One significant cloud > service business for that market in the foreseeable future is to > host overflow/expansion capacity for the enterprise/government data > centers. That means the provider data centers will have to be > multi-tenant in nature with seamless inter-working with the customer > data centers. There are quite a few (I cannot number them) > hypervisors out there in the market today, and the customers I know > have all of them (although usually each customer has one or two > hypervisors only). Without standardization means the provider data > center has to have all of the hypervisors in each and every data > center in order to provide the services, and it also means the > server/network capacity in the provider data centers are dedicated > per Hypervisor without capacity sharing. Are you saying you want interoperabilty between hypervisors? That is, You want to be able to move a VM from hypervisor type A (i.e, from vendor A) to a hypervisor of type B (i.e,. from Vendor B), and you'd like the IETF to develop standards that allow this? If so, that seems like trying to bite off a pretty big task, well beyound what most others have been calling for. It would be good to get clarity as to whether this is a goal and whether there any of the key players (i.e., hypervisor vendors) agree. Thomas From ning.so@verizon.com Mon Aug 22 06:51:21 2011 Return-Path: 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 0FD9921F863A for ; Mon, 22 Aug 2011 06:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599] 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 YHYdTORy-Iw2 for ; Mon, 22 Aug 2011 06:51:20 -0700 (PDT) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2181221F8A7D for ; Mon, 22 Aug 2011 06:51:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe01.verizon.com with ESMTP; 22 Aug 2011 13:52:24 +0000 From: "So, Ning" X-IronPort-AV: E=Sophos;i="4.68,263,1312156800"; d="scan'208";a="118853615" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi02.verizon.com with ESMTP; 22 Aug 2011 13:52:19 +0000 Received: from FHDP1LUMXC7V41.us.one.verizon.com ([169.254.1.38]) by FHDP1LUMXC7HB04.us.one.verizon.com ([166.68.59.191]) with mapi; Mon, 22 Aug 2011 09:52:19 -0400 To: Thomas Narten Date: Mon, 22 Aug 2011 09:52:18 -0400 Thread-Topic: [sami] Bringing new work into the IETF Thread-Index: AcxgxormVlgBbhKlQ4yaQ7iW18rKdQACX3wA Message-ID: <6665BC1FEA04AB47B1F75FA641C43BC0814DBCB1@FHDP1LUMXC7V41.us.one.verizon.com> 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> <6665BC1FEA04AB47B1F75FA641C43BC0814DB910@FHDP1LUMXC7V41.us.one.verizon.com> <201108221225.p7MCP8Ih021246@cichlid.raleigh.ibm.com> In-Reply-To: <201108221225.p7MCP8Ih021246@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sami@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 13:51:21 -0000 Thomas, Please see my reply inline. =20 =A0 Best regards, =A0 Ning So Verizon Corporate Technology (office) 972-729-7905 (Cell) 972-955-0914 =A0 -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com]=20 Sent: Monday, August 22, 2011 7:25 AM To: So, Ning Cc: David Harrington; 'Yingjie Gu(yingjie)'; sami@ietf.org Subject: Re: [sami] Bringing new work into the IETF Just so I understand... "So, Ning" writes: > Telecom service provider such as Verizon have significant business=20 > with enterprises and government agencies. One significant cloud=20 > service business for that market in the foreseeable future is to host=20 > overflow/expansion capacity for the enterprise/government data=20 > centers. That means the provider data centers will have to be=20 > multi-tenant in nature with seamless inter-working with the customer=20 > data centers. There are quite a few (I cannot number them)=20 > hypervisors out there in the market today, and the customers I know=20 > have all of them (although usually each customer has one or two=20 > hypervisors only). Without standardization means the provider data=20 > center has to have all of the hypervisors in each and every data=20 > center in order to provide the services, and it also means the=20 > server/network capacity in the provider data centers are dedicated per=20 > Hypervisor without capacity sharing. Are you saying you want interoperabilty between hypervisors? That is, You w= ant to be able to move a VM from hypervisor type A (i.e, from vendor A) to = a hypervisor of type B (i.e,. from Vendor B), and you'd like the IETF to de= velop standards that allow this? [Ning]: Yes.=20 If so, that seems like trying to bite off a pretty big task, well beyound w= hat most others have been calling for. It would be good to get clarity as to whether this is a goal and whether th= ere any of the key players (i.e., hypervisor vendors) agree. [Ning]: It is important to have a common agreement on requirements. I sta= ted my opinion and use case. I will reach out to the carriers I have been = work with in other areas to see if they also have the similar requirements.= If it is true, then IETF has to play a key role in this. Other SDO such = as DMTF will also play a key role. I hope the use cases and requirements c= an drive player agreement/participation, especially secondary players. = =20 Thomas From david.black@emc.com Mon Aug 22 07:16:48 2011 Return-Path: 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 86E6121F8B38 for ; Mon, 22 Aug 2011 07:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.471 X-Spam-Level: X-Spam-Status: No, score=-106.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 vtsnp2OX+sPa for ; Mon, 22 Aug 2011 07:16:47 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4558A21F8B2B for ; Mon, 22 Aug 2011 07:16:46 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7MEHoZh026282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Aug 2011 10:17:50 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Mon, 22 Aug 2011 10:17:36 -0400 Received: from mxhub28.corp.emc.com (mxhub28.corp.emc.com [10.254.110.184]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7MEHKXJ032376; Mon, 22 Aug 2011 10:17:35 -0400 Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub28.corp.emc.com ([10.254.110.184]) with mapi; Mon, 22 Aug 2011 10:16:26 -0400 From: To: , Date: Mon, 22 Aug 2011 10:16:25 -0400 Thread-Topic: [sami] Bringing new work into the IETF Thread-Index: AcxepFcgBFzX3RG1RE+vwpnvfbABAACLYplQ Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E0589672343@MX14A.corp.emc.com> 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> <6665BC1FEA04AB47B1F75FA641C43BC0814DB910@FHDP1LUMXC7V41.us.one.verizon.com> <4E4EB603.7080903@gmail.com> In-Reply-To: <4E4EB603.7080903@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 14:16:48 -0000 Hi Melinda, > I've mostly been appalled by how stuff (I initially typed "work," > realized that that was not correct, and "stuff" is the only thing > I could come up with to describe what's under discussion) related to > clouds/data centers has been brought to the IETF. There's never > been a clear statement of need for a specific piece of work, no > requirements, just fishing for something that someone might possibly > be able to get a publication out of. I concur with that viewpoint. The former "clouds" mailing list was a time-sink that I had to pay attention to. > The service migration stuff struck me as different, because for > better or worse there's a lot of flow-coupled state inside the > network, often related to security but sometimes related to > transport optimization, policy routing, etc. How to move > that when live network sessions move is a real problem, and one > that's hard to solve. I also agree with this - there is an actual state migration problem in here struggling to get out. > Unfortunately you guys totally blew that > one out of the water when you reframed this as 1) moving VMs, > and 2) moving them within the same subnet. If this is really, > truly, honestly what you want to do, you're going to start to > identify specific use cases and pieces of state that you think > will need to be transferred. The only thing I can come up with > is address/port mappings in switches, and honestly that's not > very compelling. This piece of email from Ning continues the > vagueness and really doesn't provide any information that might > help evaluate the work on its technical merit. Ah, that I can help with ... ;-). If one restricts a subnet to a physical L2 subnet, I think your conclusion has a lot of merit (I reserve the right to quibble later, but this message is about something else ...). OTOH, L2 connectivity is being provided over L3 infrastructure where one may not expect it - examples of technologies that can do that include GRE, L2TP and OTV. For OTV, see draft-hasmit-otv-03, http://datatracker.ietf.org/doc/draft-hasmit-otv/ - that's a good place to start as it contains a lot of worked-out details for stretching L2 connectivity over L3 carrier infrastructure. Live migration of a virtual machine across this sort of stretched L2 connectivity is an important use case, because it's interesting (yes, people really do want to do this), and the VM's L2 and L3 addresses can't change during the migration. To a first approximation, changing any of the VM's addresses makes the VM migration non- transparent and disruptive courtesy of things like ARP caches in other VMs. One of the first things that is often done when stretching L2 subnets in this fashion is to distribute the L3 default gateway. If one moves a VM from San Jose, CA to San Francisco, CA (about 50mi), one would prefer to hand off that VM's traffic to/from the (public) Internet to an ISP in San Francisco, as opposed to hauling it back to San Jose (the latter is colloquially referred to as "hairpinning"). If it helps to understand the scenario, assume that the AS that encompasses the San Francisco and San Jose facilities (and the connection between them) is multi-homed to different ISPs in San Francisco and San Jose. The good news is that routing protocols don't like hairpinning, and will try to move the traffic to use the ISP connection in San Francisco. The bad news is that there's a stateful inspection firewall on the ISP connection in San Jose that contains things like TCP state. Hence moving the VM's TCP connections to San Francisco results in trying to use the corresponding stateful inspection firewall on the ISP connection in San Francisco, which has no state for those TCP connections, and hence bit buckets all of their packets. That would be bad, and the result is that the middlebox (firewall) requires that the TCP connections be hairpinned back to San Jose even though the routing protocols are perfectly capable of optimizing that hairpinning away via the ISP in San Francisco. So, I'm confident that there's a real problem in here, but I also strongly encourage re-reading Dave Harrington's message that started this "Bringing new work ..." thread, because it outlines some important practical considerations about whether the IETF can usefully solve this problem. To put those concerns bluntly: If we built "it", would anyone "come"? Thanks, --David > -----Original Message----- > From: sami-bounces@ietf.org [mailto:sami-bounces@ietf.org] On Behalf Of M= elinda Shore > Sent: Friday, August 19, 2011 3:14 PM > To: sami@ietf.org > Subject: Re: [sami] Bringing new work into the IETF >=20 > On 08/19/2011 08:54 AM, So, Ning wrote: > > [ ... ] > > Telecom service provider such as Verizon have significant business > > with enterprises and government agencies. One significant cloud > > service business for that market in the foreseeable future is to > > host overflow/expansion capacity for the enterprise/government > > data centers. That means the provider data centers will have to > > be multi-tenant in nature with seamless inter-working with the > > customer data centers. There are quite a few (I cannot number them) > > hypervisors out there in the market today, and the customers I know > > have all of them (although usually each customer has one or two > > hypervisors only). Without standardization means the provider > > data center has to have all of the hypervisors in each and every > > data center in order to provide the services, and it also means > > the server/network capacity in the provider data centers are > > dedicated per Hypervisor without capacity sharing. >=20 > You guys are being asked for a technical discussion of what's > being proposed. This is marketing. >=20 > I've mostly been appalled by how stuff (I initially typed "work," > realized that that was not correct, and "stuff" is the only thing > I could come up with to describe what's under discussion) related to > clouds/data centers has been brought to the IETF. There's never > been a clear statement of need for a specific piece of work, no > requirements, just fishing for something that someone might possibly > be able to get a publication out of. >=20 > The service migration stuff struck me as different, because for > better or worse there's a lot of flow-coupled state inside the > network, often related to security but sometimes related to > transport optimization, policy routing, etc. How to move > that when live network sessions move is a real problem, and one > that's hard to solve. Unfortunately you guys totally blew that > one out of the water when you reframed this as 1) moving VMs, > and 2) moving them within the same subnet. If this is really, > truly, honestly what you want to do, you're going to start to > identify specific use cases and pieces of state that you think > will need to be transferred. The only thing I can come up with > is address/port mappings in switches, and honestly that's not > very compelling. This piece of email from Ning continues the > vagueness and really doesn't provide any information that might > help evaluate the work on its technical merit. >=20 > Melinda Shore > _______________________________________________ > sami mailing list > sami@ietf.org > https://www.ietf.org/mailman/listinfo/sami From melinda.shore@gmail.com Mon Aug 22 08:26:38 2011 Return-Path: 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 72FB921F8AF8 for ; Mon, 22 Aug 2011 08:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 o-WJxDfXMoYs for ; Mon, 22 Aug 2011 08:26:38 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id D487521F8AF0 for ; Mon, 22 Aug 2011 08:26:37 -0700 (PDT) Received: by gyf3 with SMTP id 3so4458078gyf.31 for ; Mon, 22 Aug 2011 08:27:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=6rLcZoYt8Zg4+tXm1NPHr2yr34ZgeHszl6KPVn6kWLU=; b=J/MN/0iZ7K+yKsOzyj+kWo70K1SWcbt6uGxk6VbZ7NeLmq7ga5vmJoX9DhGOfqWJ9L 2/b181XdSzKib/cJi3nxkONZUZWD4zrrM5yf9fgx36fIBvSa1anmJST+Pc/FKdwCnjD/ zHJpAVnEaglOsF9JIOceWFEN4zXx0xeKqF9O4= Received: by 10.68.17.38 with SMTP id l6mr173619pbd.353.1314026861800; Mon, 22 Aug 2011 08:27:41 -0700 (PDT) Received: from polypro.local (66-230-82-131-rb1.fai.dsl.dynamic.acsalaska.net [66.230.82.131]) by mx.google.com with ESMTPS id q3sm972991pbo.55.2011.08.22.08.27.39 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Aug 2011 08:27:40 -0700 (PDT) Message-ID: <4E527569.4080906@gmail.com> Date: Mon, 22 Aug 2011 07:27:37 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: "So, Ning" , "sami@ietf.org" 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> <6665BC1FEA04AB47B1F75FA641C43BC0814DB910@FHDP1LUMXC7V41.us.one.verizon.com> <201108221225.p7MCP8Ih021246@cichlid.raleigh.ibm.com> <6665BC1FEA04AB47B1F75FA641C43BC0814DBCB1@FHDP1LUMXC7V41.us.one.verizon.com> In-Reply-To: <6665BC1FEA04AB47B1F75FA641C43BC0814DBCB1@FHDP1LUMXC7V41.us.one.verizon.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 15:26:38 -0000 On 8/22/11 5:52 AM, So, Ning wrote: > It is important to have a common agreement on requirements. I > stated my opinion and use case. I will reach out to the carriers > I have been work with in other areas to see if they also have the > similar requirements. If it is true, then IETF has to > play a key role in this. I tend to think that this is basically of a piece with wishing for a pony. That said, as important it is to reach an agreement on requirements, it's even more important to reach an agreement on what piece of work is to be done. That said, the IETF is the Internet Engineering Task Force. Just because something moves across a network doesn't mean that it's necessarily a network problem. There's also the question of past being prologue - in an odd feat of chartering rserpool tackled moving live servers but not moving any of the state associated with them, and the question of moving middlebox state didn't even come up. I tend to think that it's because people involved in the chartering decision looked at the problem and decided that if the working group took it on they'd never finish. Anyway, to circle back around it seems to me that it's probably a good idea to stay focused on the network aspects of, erm, whatever it is you think the IETF should do. This is not just because of the question of organizational scope, but also because of the expertise within the group. I've also thought about the question of running layer 2 subnets over the transport layer but that's really not what has been proposed so far. I think that a good way to get a handle on the answer to David's question, "If we build it, will they come?" would be for one of the proponents of this work to try to convince Huge Virtualization Vendor to participate in developing a mechanism that would allow their images to run on Freeware Hypervisor . Melinda From bschlies@cisco.com Mon Aug 22 08:34:55 2011 Return-Path: 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 C13BC21F8B73 for ; Mon, 22 Aug 2011 08:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.309 X-Spam-Level: X-Spam-Status: No, score=-3.309 tagged_above=-999 required=5 tests=[AWL=-0.710, BAYES_00=-2.599] 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 nJJRQtntgrEx for ; Mon, 22 Aug 2011 08:34:55 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id E3D1721F8B6E for ; Mon, 22 Aug 2011 08:34:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=1320; q=dns/txt; s=iport; t=1314027360; x=1315236960; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=+d4zzfwNVf0TBwm0EFokQPotJs3xVyUV9MXT2nLS9BQ=; b=m/dHYo42Dwpl/TcAm6kDLaNfwojp0biVCJrfhGVdffDZZUzNQ4lbBFDE Qpb7Q2D8vH0O5rd7RbUQ9fiodgK01pJRuU6tcJImkcwOO4oFSO0K3LMbm hFa2kNOeH2Ize0OUOJXQ18E86/FWQ/lgbK30/v/YhaX8OhxUuWIesipRK s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABd3Uk6tJV2b/2dsb2JhbABBqAt3gUABAQEBAxIBJwIBKhISAQgYgQUBAQQBDQUih1OWdgGeO4ZIBIdgizSFFYwA X-IronPort-AV: E=Sophos;i="4.68,263,1312156800"; d="scan'208";a="15338356" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 22 Aug 2011 15:35:49 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p7MFZmBC014947; Mon, 22 Aug 2011 15:35:48 GMT Received: from xmb-rcd-206.cisco.com ([72.163.62.213]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Aug 2011 10:35:48 -0500 Received: from 10.21.65.250 ([10.21.65.250]) by XMB-RCD-206.cisco.com ([72.163.62.213]) via Exchange Front-End Server email.cisco.com ([171.70.151.174]) with Microsoft Exchange Server HTTP-DAV ; Mon, 22 Aug 2011 15:35:48 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Mon, 22 Aug 2011 10:35:44 -0500 From: Benson Schliesser To: "So, Ning" , Thomas Narten Message-ID: Thread-Topic: [sami] Bringing new work into the IETF Thread-Index: AcxgxormVlgBbhKlQ4yaQ7iW18rKdQACX3wAAARHw8Y= In-Reply-To: <6665BC1FEA04AB47B1F75FA641C43BC0814DBCB1@FHDP1LUMXC7V41.us.one.verizon.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Aug 2011 15:35:48.0627 (UTC) FILETIME=[2AA50E30:01CC60E1] Cc: "sami@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 15:34:55 -0000 Hi, Ning. On 8/22/11 8:52 AM, "So, Ning" wrote: >> Thomas Narten said: > Are you saying you want interoperabilty between hypervisors? That is, You want > to be able to move a VM from hypervisor type A (i.e, from vendor A) to a > hypervisor of type B (i.e,. from Vendor B), and you'd like the IETF to develop > standards that allow this? > > [Ning]: Yes. > ... > [Ning]: It is important to have a common agreement on requirements. I stated > my opinion and use case. I will reach out to the carriers I have been work > with in other areas to see if they also have the similar requirements. If it > is true, then IETF has to play a key role in this. Other SDO such as DMTF > will also play a key role. I hope the use cases and requirements can drive > player agreement/participation, especially secondary players. It's good that you mention the DMTF. You should also investigate other groups such as ODCA (http://www.opendatacenteralliance.org/), which has a working group on this topic. Assuming that hypervisor compatibility, control APIs, etc, are worked out in a different forum - what role do you think the IETF has in this space? I have my own thoughts on this topic, but I don't want to put words in your mouth. Can you be specific? Thanks, -Benson From ning.so@verizon.com Mon Aug 22 11:48:44 2011 Return-Path: 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 7663321F8C09 for ; Mon, 22 Aug 2011 11:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] 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 XkOMZeFOq56l for ; Mon, 22 Aug 2011 11:48:43 -0700 (PDT) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCB721F8BE8 for ; Mon, 22 Aug 2011 11:48:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe02.verizon.com with ESMTP; 22 Aug 2011 18:49:47 +0000 From: "So, Ning" X-IronPort-AV: E=Sophos;i="4.68,264,1312156800"; d="scan'208";a="119086523" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by fldsmtpi02.verizon.com with ESMTP; 22 Aug 2011 18:49:47 +0000 Received: from FHDP1LUMXC7V41.us.one.verizon.com ([169.254.1.38]) by FHDP1LUMXC7HB04.us.one.verizon.com ([166.68.59.191]) with mapi; Mon, 22 Aug 2011 14:49:47 -0400 To: "sami@ietf.org" Date: Mon, 22 Aug 2011 14:49:46 -0400 Thread-Topic: [sami] Bringing new work into the IETF Thread-Index: AcxgxormVlgBbhKlQ4yaQ7iW18rKdQACX3wAAARHw8YABpV4IA== Message-ID: <6665BC1FEA04AB47B1F75FA641C43BC0814DBF10@FHDP1LUMXC7V41.us.one.verizon.com> References: <6665BC1FEA04AB47B1F75FA641C43BC0814DBCB1@FHDP1LUMXC7V41.us.one.verizon.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 18:48:44 -0000 Benson, Thank you for bringing ODCA to my attention. I have had very limited expos= ure to DMTF, and no exposure to ODCA at all. After reading a bit more on t= heir work, those SDOs appear to be better places for the type of work I hav= e in mind. I cannot cover those SDOs, so I will alert internally to have o= ther people involved. =20 =A0 Best regards, =A0 Ning So Verizon Corporate Technology (office) 972-729-7905 (Cell) 972-955-0914 =A0 -----Original Message----- From: Benson Schliesser [mailto:bschlies@cisco.com]=20 Sent: Monday, August 22, 2011 10:36 AM To: So, Ning; Thomas Narten Cc: sami@ietf.org Subject: Re: [sami] Bringing new work into the IETF Hi, Ning. On 8/22/11 8:52 AM, "So, Ning" wrote: >> Thomas Narten said: > Are you saying you want interoperabilty between hypervisors? That is,=20 > You want to be able to move a VM from hypervisor type A (i.e, from=20 > vendor A) to a hypervisor of type B (i.e,. from Vendor B), and you'd=20 > like the IETF to develop standards that allow this? >=20 > [Ning]: Yes.=20 > ... > [Ning]: It is important to have a common agreement on requirements. =20 > I stated my opinion and use case. I will reach out to the carriers I=20 > have been work with in other areas to see if they also have the=20 > similar requirements. If it is true, then IETF has to play a key role=20 > in this. Other SDO such as DMTF will also play a key role. I hope=20 > the use cases and requirements can drive player agreement/participation, = especially secondary players. It's good that you mention the DMTF. You should also investigate other gro= ups such as ODCA (http://www.opendatacenteralliance.org/), which has a work= ing group on this topic. Assuming that hypervisor compatibility, control APIs, etc, are worked out i= n a different forum - what role do you think the IETF has in this space? I= have my own thoughts on this topic, but I don't want to put words in your = mouth. Can you be specific? Thanks, -Benson From warren@kumari.net Mon Aug 22 17:11:53 2011 Return-Path: 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 9771A21F8B19 for ; Mon, 22 Aug 2011 17:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.138 X-Spam-Level: X-Spam-Status: No, score=-102.138 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, 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 wuvXfnRq13iw for ; Mon, 22 Aug 2011 17:11:52 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 3062721F8B18 for ; Mon, 22 Aug 2011 17:11:51 -0700 (PDT) Received: from [192.168.0.203] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 489F21B416FF; Mon, 22 Aug 2011 20:12:55 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <20110819134536.GC28373@elstar.local> Date: Mon, 22 Aug 2011 20:12:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8A0B68AD-E303-4C79-BD1F-E9ACEE210514@kumari.net> References: <004c01cc57ec$7f602ed0$7e208c70$@com> <20110811074034.GA12533@elstar.local> <005701cc5806$03cd8370$0b688a50$@com> <4A95BA014132FF49AE685FAB4B9F17F605189C80@dfweml504-mbx.china.huawei.com> <006001cc5cbb$de6c48e0$9b44daa0$@com> <4E4C6214.3010800@gmail.com> <12969308CE9E48DEAB5B5745D9482303@fanybP> <004c01cc5da6$5adb5660$10920320$@com> <20110819134536.GC28373@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1084) Cc: "Yingjie Gu\(yingjie\)" , 'Melinda Shore' , 'Fan Yongbing' , sami@ietf.org Subject: Re: [sami] Welcome to SAMI and something you may like to know. X-BeenThere: sami@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: State Migration List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 00:11:53 -0000 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: >=20 >> 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. >=20 > 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=85 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. >=20 > 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 >=20 > 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. >=20 >=20 >=20 >=20 > The IETF Secretariat This will probably not help the scope discussions :-P W >=20 > 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). >=20 > 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. >=20 > 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. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > sami mailing list > sami@ietf.org > https://www.ietf.org/mailman/listinfo/sami >=20 From melinda.shore@gmail.com Tue Aug 23 14:41:58 2011 Return-Path: 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 5A09421F8C94 for ; Tue, 23 Aug 2011 14:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 dDJLAJz5FOdS for ; Tue, 23 Aug 2011 14:41:57 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id CAC4C21F8C8F for ; Tue, 23 Aug 2011 14:41:57 -0700 (PDT) Received: by pzk33 with SMTP id 33so274634pzk.18 for ; Tue, 23 Aug 2011 14:43:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=PycsBua7A14s54mojL31vQu2u+6L5hp5tVG4CaC7zo0=; b=R+IidkRZAy5NA41v9WB52atjHwOeMNM/yYULuAb+B6HbaML5RZgDNMGCxjEMg/mjnZ OytD+3tQRu6jTG7JOldJsONBxaMQRIPGoTvlsPYstOX2vuToAz/VTzNI0FuFtCercNbq x79elA14zii7PVLfszZzWTJTn13vPj4tiBCyg= Received: by 10.142.226.8 with SMTP id y8mr1278971wfg.287.1314135784140; Tue, 23 Aug 2011 14:43:04 -0700 (PDT) Received: from [137.229.12.236] (drake.swits.alaska.edu [137.229.12.236]) by mx.google.com with ESMTPS id i2sm87108wfd.8.2011.08.23.14.43.02 (version=SSLv3 cipher=OTHER); Tue, 23 Aug 2011 14:43:03 -0700 (PDT) Message-ID: <4E541EE7.1080605@gmail.com> Date: Tue, 23 Aug 2011 13:43:03 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: sami@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 21:41:58 -0000 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 From guyingjie@huawei.com Tue Aug 23 22:39:46 2011 Return-Path: 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 7AD9D21F8B25 for ; Tue, 23 Aug 2011 22:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.151 X-Spam-Level: X-Spam-Status: No, score=-103.151 tagged_above=-999 required=5 tests=[AWL=0.659, BAYES_00=-2.599, CN_BODY_35=0.339, 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 u1wMhHQ0+x1i for ; Tue, 23 Aug 2011 22:39:45 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id A448C21F8BAD for ; Tue, 23 Aug 2011 22:39:45 -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 <0LQF0057C3OWUV@szxga04-in.huawei.com> for sami@ietf.org; Wed, 24 Aug 2011 13:38:56 +0800 (CST) Received: from szxrg01-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 <0LQF00CHW3OW4Q@szxga04-in.huawei.com> for sami@ietf.org; Wed, 24 Aug 2011 13:38:56 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml207-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADJ47152; Wed, 24 Aug 2011 13:38:55 +0800 (CST) Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 24 Aug 2011 13:38:52 +0800 Received: from g00107907 (10.138.41.134) by szxeml412-hub.china.huawei.com (10.82.67.91) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 24 Aug 2011 13:38:55 +0800 Date: Wed, 24 Aug 2011 13:39:45 +0800 From: "Yingjie Gu(yingjie)" In-reply-to: <4E541EE7.1080605@gmail.com> X-Originating-IP: [10.138.41.134] To: 'Melinda Shore' , sami@ietf.org Message-id: <000c01cc6220$3b18fa70$b14aef50$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=gb2312 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: Acxh3bbVu6B/JRyFQG6Szg/adcVTmwAQGBGQ X-CFilter-Loop: Reflected References: <4E541EE7.1080605@gmail.com> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 05:39:46 -0000 I think we are still on the right way to move forward.=20 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.=20 'state migration for service failover'=20 'need differentiate requirements for Optimization-based migration and restoration-based migration',=20 'layer 2 connectivity over L3 infrastructure',=20 'think about IP mobility instead of state migration' 'services running on VM will impact the way of state migration' and many others.=20 Sorry that I don't list all of the input.=20 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.=20 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 -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: sami-bounces@ietf.org [mailto:sami-bounces@ietf.org] = =B4=FA=B1=ED Melinda Shore =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA8=D4=C224=C8=D5 =C0=D6=C0=D65:43 =CA=D5=BC=FE=C8=CB: sami@ietf.org =D6=F7=CC=E2: [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 From zhangyunfei@chinamobile.com Tue Aug 23 23:04:05 2011 Return-Path: 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 ; 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 ; 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 ; 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" To: "Yingjie Gu(yingjie)" , "'Melinda Shore'" , "sami@ietf.org" References: <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 06:04:05 -0000 This is a multi-part message in MIME format. --=====003_Dragon584666206555_===== Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SSBjYW4gc2hhcmUgYSB1c2UgY2FzZSBoZXJlIGZyb20gb3VyIHBvaW50IG9mIHZpZXcgaW4gZGF0 YSBjZW50ZXIgb3BlcmF0aW9uKHdpbGwgZGV0YWlsIHRoaXMgaW4gdGhlIHVwY29taW5nIGRyYWZ0 IGFzIFlpbmdqaWUgc2FpZCk6DQpXZSBhcmUgY29uc2lkZXJpbmcgcnVubmluZyBkaWZmZXJlbnQg c2VydmljZXMgKGUuZy4sIFZvSVAgYW5kIHN0cmVhbWluZyBzZXJ2aWNlcykgYnkgVk0gaW4gdGhl IHNhbWUgY2x1c3RlciB3aXRoaW5uIGRhdGEgY2VudGVyLiBXZSBrbm93IGRpZmZlcmVudCBzZXJ2 aWNlcyBzaG93IGRpZmZlcmVudCB1c2VyIHZpc2l0aW5nIGJlaGF2aW9ycy4gRm9yIGV4YW1wbGUs IGluIHRoZSBtaWRuaWdodCwgdGhlcmUgYXJlIGZldyBWb0lQIHVzYWdlIHdoaWxlIHRoZXJlIGFy ZSBzdGlsbCBsYXJnZSBhbW91bnQgb2Ygc3RyZWFtaW5nIHVzYWdlKCB0aGlzIGlzIGp1c3QgYW4g ZXhhbXBsZSwgbWF5YmUgbm90IHNvIGFjY3VyYXRlIHRvIGZpdCB3aXRoIHRoZSByZWFsaXR5KS4g SW4gc3VjaCBjYXNlLCB3ZSdkIGxpa2UgbWVyZ2UgdGhlIGV4aXN0aW5nIFZvSVAgYW5kIHN0cmVh bWluZyBzZXJ2aWNlcyBpbnRvIGZld2VyIG1hY2hpbmVzIGFuZCBjdXQgZG93biB0aGUgbWFjaGlu ZXMgcnVubmluZyBvbmx5IGZldyBWb0lQIHVzYWdlIHRvIHJlZHVjZSB0aGUgcG93ZXIgY29uc3Vt cHRpb24uDQpJbiB0aGlzIHNlbmFyaW8sIHdlIG5lZWQgdG8gY29uc2lkZXIgaG93IHRvIG1pZ3Jh dGUgdGhlIGV4aXN0aW5nIFZNIHN0YXRlcy4NCg0KTG9va2luZyBmb3J3YXJkIHRvIGRpc2N1c3Np bmcgbW9yZSB1c2UgY2FzZXMgaW4gdGhlIG1haWxpbmcgbGlzdC4NCg0KQlINCll1bmZlaQ0KDQoN Cg0KDQp6aGFuZ3l1bmZlaQ0KMjAxMS0wOC0yNA0KDQoNCg0Kt6K8/sjLo7ogWWluZ2ppZSBHdSh5 aW5namllKQ0Kt6LLzcqxvOSjuiAyMDExLTA4LTI0IDEzOjQxOjA0DQrK1bz+yMujuiAnTWVsaW5k YSBTaG9yZSc7IHNhbWlAaWV0Zi5vcmcNCrOty82juiANCtb3zOKjuiBSZTogW3NhbWldIFRyeWlu ZyB0byBmaWd1cmUgb3V0IHdoZXJlIHdlIGFyZQ0KDQpJICB0aGluayAgd2UgIGFyZSAgc3RpbGwg IG9uICB0aGUgIHJpZ2h0ICB3YXkgIHRvICBtb3ZlICBmb3J3YXJkLiAgDQpXZSAgbmVlZCAgdG8g IGhlYXIgIGRpZmZlcmVudCAgdm9pY2UgIHNvICB0aGF0ICB3ZSAgY2FuICBrbm93ICB3aGF0ICBn byAgdG8gIHBlb3BsZSdzICBtaW5kDQp3aGVuICB0aGV5ICBzZWUgICJTdGF0ZSAgTWlncmF0aW9u Ii4NCg0KRm9yICBub3csICB3ZSAgaGF2ZSAgaGVhcmQgIGRpZmZlcmVudCAgb3BpbmlvbnMsICBl LmcuICANCidzdGF0ZSAgbWlncmF0aW9uICBmb3IgIHNlcnZpY2UgIGZhaWxvdmVyJyAgDQonbmVl ZCAgZGlmZmVyZW50aWF0ZSAgcmVxdWlyZW1lbnRzICBmb3IgIE9wdGltaXphdGlvbi1iYXNlZCAg bWlncmF0aW9uICBhbmQNCnJlc3RvcmF0aW9uLWJhc2VkICBtaWdyYXRpb24nLCAgDQonbGF5ZXIg IDIgIGNvbm5lY3Rpdml0eSAgb3ZlciAgTDMgIGluZnJhc3RydWN0dXJlJywgIA0KJ3RoaW5rICBh Ym91dCAgSVAgIG1vYmlsaXR5ICBpbnN0ZWFkICBvZiAgc3RhdGUgIG1pZ3JhdGlvbicNCidzZXJ2 aWNlcyAgcnVubmluZyAgb24gIFZNICB3aWxsICBpbXBhY3QgIHRoZSAgd2F5ICBvZiAgc3RhdGUg IG1pZ3JhdGlvbicgIGFuZCAgbWFueQ0Kb3RoZXJzLiAgDQpTb3JyeSAgdGhhdCAgSSAgZG9uJ3Qg IGxpc3QgIGFsbCAgb2YgIHRoZSAgaW5wdXQuICANClRob3VnaCAgbm90ICBhbGwgIG9mICB0aGVt ICB3aWxsICBmaW5hbGx5ICBiZSAgaW4gIHNjb3BlLCAgb3IgIHdlICBmaW5hbGx5ICBmYWlsICB0 bw0KY2hhcnRlciAgYSAgd29ya2FibGUgIHNjb3BlICBpbiAgSUVURiwgIHRoZXkgIGFyZSAgaGln aGx5ICB2YWx1YWJsZSAgaW5wdXQgIGZvciAgc2NvcGUNCmRpc2N1c3Npb24uICANClRoYW5rICB5 b3UgIHZlcnkgIG11Y2guDQoNCk1lYW53aGlsZSwgIEkgIGFsc28gIHRyeSAgdG8gIGFzayAgREMg IHByb3ZpZGVyICB0byAgc2hhcmUgIHRoZWlyICB1c2UgIGNhc2VzLiAgQ2hpbmENClRlbGVjb20g IGFuZCAgQ2hpbmEgIE1vYmlsZSwgIHdobyAgYXJlICBhbHNvICBsb29raW5nICBmb3J3YXJkICB0 byAgYmVjb21lICBEQw0KcHJvdmlkZXIsICBzZWUgIHRoZSAgY29uY3JldGUgIHJlcXVpcmVtZW50 cyAgYW5kICBwcmVwYXJlICB0byAgd3JpdGUgIGRvd24gIGEgIGRyYWZ0ICB0bw0KaW50cm9kdWNl ICB0aGUgIHVzZSAgY2FzZXMgIGluICByZWFsICBzY2VuYXJpb3MuICBCdXQgIHRoZXkgIG1heSAg aW50cm9kdWNlICBzb21lICB1c2UNCmNhc2VzICB0byAgbWFpbCAgbGlzdCAgYmVmb3JlICB0aGUg IGRyYWZ0ICBpcyAgY29tcGxldGVkLg0KDQoNCkJlc3QgIFJlZ2FyZHMNCkd1ICBZaW5namllDQoN Cg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6ICBzYW1pLWJvdW5jZXNAaWV0Zi5vcmcgIFtt YWlsdG86c2FtaS1ib3VuY2VzQGlldGYub3JnXSAgtPqx7SAgTWVsaW5kYQ0KU2hvcmUNCreiy83K sbzkOiAgMjAxMcTqONTCMjTI1SAgwNbA1jU6NDMNCsrVvP7IyzogIHNhbWlAaWV0Zi5vcmcNCtb3 zOI6ICBbc2FtaV0gIFRyeWluZyAgdG8gIGZpZ3VyZSAgb3V0ICB3aGVyZSAgd2UgIGFyZQ0KDQpB cyAgdGhlICBkaXNjdXNzaW9uICBoYXMgIHByb2dyZXNzZWQgIGl0J3MgIGJlY29tZSAgbW9yZS1v ci1sZXNzICBjbGVhcg0KdGhhdCAgdGhlcmUgIG1pZ2h0ICBwb3NzaWJseSAgcGVyaGFwcyAgYmUg IG9uZSAgb3IgIHR3byAgaW50ZXJlc3RpbmcNCnByb2JsZW1zICBoZXJlLCAgbWF5YmUsICBhbHRo b3VnaCAgdGhlICBwZW9wbGUgIHB1c2hpbmcgIGZvciAgdGhlDQpjaGFydGVyaW5nICBvZiAgc29t ZXRoaW5nLW9yLW90aGVyICAoYW55dGhpbmchKSAgdG8gIGRvICB3aXRoDQpkYXRhICBjZW50ZXJz ICBhbmQgIHZpcnR1YWxpemF0aW9uICBzZWVtICB0byAgYmUgIHdvcmtpbmcgIHZlcnkgIGhhcmQN CmluZGVlZCAgdG8gIG9ic2N1cmUgIGFueXRoaW5nICB0aGF0ICBtaWdodCAgdHVybiAgb3V0ICB0 byAgaGF2ZSAgc29tZQ0KdmFsdWUuDQoNCkZpcnN0LCAgdGhlcmUgIGFwcGVhcnMgIHRvICBiZSAg YSAgc3Vic3RhbnRpYWwgIHByb2JsZW0gIHJlbGF0ZWQgIHRvDQptb3ZpbmcgIGZsb3ctYXNzb2Np YXRlZCAgc3RhdGUgIGluICBtaWRkbGVib3hlcyAgd2hlbiAgYSAgbmV0d29yaw0KY29ubmVjdGlv biAgKGRlbGliZXJhdGVseSAga2VlcGluZyAgImNvbm5lY3Rpb24iICB2YWd1ZSAgZm9yICB0aGUN Cm1vbWVudCkgIGZhaWxzICBvdmVyLiAgICBUaGlzICBoYXMgIGNlcnRhaW5seSAgY29tZSAgdXAg IGluICB0aGUgIGNvbnRleHQNCm9mICBtdWx0aWhvbWVkICBjb25uZWN0aW9ucyAgaW4gIHNjdHAs ICBhbmQgIHRvICBiZSAgaG9uZXN0ICBJDQpoYXZlbid0ICBmb2xsb3dlZCAgdGhhdCAgYXMgIGNs b3NlbHkgIGFzICBJICBzaG91bGQuICAgIFN0aWxsLCAgZXZlbg0KaWYgIHNjdHAgIGhhcyAgc29t ZXRoaW5nICB0aGF0ICB3b3JrcyAgYnJpbGxpYW50bHkgIHRoZXJlICB3b3VsZCAgYmUNCnF1ZXN0 aW9ucyAgYWJvdXQgIGFwcGx5aW5nICB0aGVpciAgbWVjaGFuaXNtICBpbiAgYSAgZGlmZmVyZW50 DQpjb250ZXh0Lg0KDQpTZWNvbmQsICB0aGVyZSAgYXBwZWFycyAgdG8gIGJlICBhbm90aGVyICBz dWJzdGFudGlhbCAgcHJvYmxlbSwNCnRoaXMgIG9uZSAgcmVsYXRlZCAgdG8gIGhvdyAgdG8gIGhh bmRsZSAgcm91dGluZyAgYW5kICBuZXR3b3JrDQpzdGF0ZSAgd2hlbiAgYSAgVk0gIGlzICBtaWdy YXRlZCAgZnJvbSAgb25lICBoeXBlcnZpc29yICB0byAgYQ0KbmV0d29yay10b3BvZ3JhcGhpY2Fs bHktcmVtb3RlICBoeXBlcnZpc29yICB3aGVuICBib3RoICBhcmUNCm9uICB0aGUgIHNhbWUgIGxh eWVyICAyICBzdWJuZXQgIGJlaW5nICB0dW5uZWxlZCAgb3ZlciAgYSAgbGF5ZXINCjMgIHRyYW5z cG9ydCAgKG9yICB3aGVuICB0aGV5J3JlICBub3QgIG9uICB0aGUgIHNhbWUgIHN1Ym5ldA0KYXQg IGFsbCwgIHdoaWNoICBJICBnYXRoZXIgIGlzICBjb25zaWRlcmFibHkgIGxlc3MgIGNvbW1vbiku DQoNClRoZSAgcHJvYmxlbSAgaGVyZSAgaXMgIHRoYXQgIGl0J3MgIG5vdCAgYXQgIGFsbCAgY2xl YXIgIHRoYXQgIHRoZXJlJ3MNCmEgIGNvbnN0aXR1ZW5jeSAgZm9yICB0aGUgIHdvcmsuICAgIEkn bSAgbm90ICB0YWxraW5nICBhYm91dCAgcGVvcGxlDQp0byAgd3JpdGUgIGFuZCAgcmV2aWV3ICBp bnRlcm5ldCAgZHJhZnRzLCAgYnV0ICByYXRoZXIgIGNvbXBhbmllcw0Kc3RhbmRpbmcgIHVwICBh bmQgIHNheWluZyAgIldlICB3YW50ICB0aGlzICBwcm9ibGVtICBzb2x2ZWQgIGFuZCAgd2UNCnRo aW5rICBpdCAgc2hvdWxkICBiZSAgc29sdmVkICB0aHJvdWdoICBhbiAgb3BlbiAgc3RhbmRhcmRz ICBwcm9jZXNzLCINCmFuZCAgZGF0YSAgY2VudGVycy9zZXJ2aWNlICBwcm92aWRlcnMgIHN0YW5k aW5nICB1cCAgYW5kICBzYXlpbmcNCiJXZSAgd291bGQgIGRlcGxveSAgdGhpcy4iICAgIFNheWlu ZyAgdGhhdCAgeW91J3JlICBhYnNvbHV0ZWx5DQpjZXJ0YWluICB0aGF0ICBzb21lYm9keSAgZWxz ZSAgd291bGQgIHNheSAgb25lICBvZiAgdGhlc2UgIHRoaW5ncw0KZG9lcyAgbm90ICBjb3VudC4N Cg0KSXQgIHdvdWxkICBiZSAgdW5mb3J0dW5hdGUgIGlmICB0aGUgIElFVEYgIHdlcmUgIHRvICBz aW5rICB2YWx1YWJsZQ0KcmVzb3VyY2VzICBpbnRvICBhbm90aGVyICBlZmZvcnQgIHRoYXQgIG5v Ym9keSAgY2FyZXMgIGFib3V0DQpvdGhlciAgdGhhbiAgcGVvcGxlICBsb29raW5nICBmb3IgIHN0 dWZmICB0byAgcHV0ICBvbiAgdGhlaXIgIENWLg0KSXMgIHRoZXJlICBhbiAgYXVkaWVuY2UgIGZv ciAgdGhpcyAgd29yaz8NCg0KTWVsaW5kYQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCnNhbWkgIG1haWxpbmcgIGxpc3QNCnNhbWlAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FtaQ0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2FtaSAgbWFpbGluZyAgbGlzdA0K c2FtaUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYW1p DQo= --=====003_Dragon584666206555_===== Content-Transfer-Encoding: base64 Content-Type: text/html; charset="gb2312" PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250 ZW50PSJNU0hUTUwgOS4wMC44MTEyLjE2NDM0Ij4NCjxTVFlMRT4NCjwhLS0NCiAvKiBGb250IERl ZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrLzszlOw0KCXBhbm9zZS0x OjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5h Ow0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlxAy87M5SI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQogLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246 anVzdGlmeTsNCgl0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoOw0KCWZvbnQtc2l6ZToxMC41 cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe2NvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6VmVyZGFuYTsNCgljb2xvcjp3aW5k b3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0 LWRlY29yYXRpb246bm9uZSBub25lO30NCiAvKiBQYWdlIERlZmluaXRpb25zICovDQogQHBhZ2Ug U2VjdGlvbjENCgl7c2l6ZTo1OTUuM3B0IDg0MS45cHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQg NzIuMHB0IDkwLjBwdDsNCglsYXlvdXQtZ3JpZDoxNS42cHQ7fQ0KZGl2LlNlY3Rpb24xDQoJe3Bh Z2U6U2VjdGlvbjE7fQ0KLS0+DQo8L1NUWUxFPg0KPC9IRUFEPg0KPEJPRFk+DQo8RElWPjxGT05U IGNvbG9yPSMwMDAwZmYgc2l6ZT0yIGZhY2U9VmVyZGFuYT5JIGNhbiBzaGFyZSBhIHVzZSBjYXNl IGhlcmUgZnJvbSANCm91ciBwb2ludCBvZiB2aWV3IGluIGRhdGEgY2VudGVyIG9wZXJhdGlvbih3 aWxsIGRldGFpbCB0aGlzIGluIHRoZSB1cGNvbWluZyANCmRyYWZ0IGFzIFlpbmdqaWUgc2FpZCk6 PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmIHNpemU9MiBmYWNlPVZlcmRh bmE+V2UgYXJlIGNvbnNpZGVyaW5nIHJ1bm5pbmcgDQpkaWZmZXJlbnQgc2VydmljZXMgKGUuZy4s IFZvSVAgYW5kIHN0cmVhbWluZyBzZXJ2aWNlcykgYnkgVk0mbmJzcDtpbiB0aGUgc2FtZSANCmNs dXN0ZXIgd2l0aGlubiBkYXRhIGNlbnRlci4gV2Uga25vdyBkaWZmZXJlbnQgc2VydmljZXMmbmJz cDtzaG93IGRpZmZlcmVudCB1c2VyIA0KdmlzaXRpbmcgYmVoYXZpb3JzLiBGb3IgZXhhbXBsZSwg aW4gdGhlIG1pZG5pZ2h0LCB0aGVyZSBhcmUgZmV3IFZvSVAgdXNhZ2Ugd2hpbGUgDQp0aGVyZSBh cmUgc3RpbGwgbGFyZ2UgYW1vdW50IG9mIHN0cmVhbWluZyB1c2FnZSggdGhpcyBpcyBqdXN0IGFu IGV4YW1wbGUsIG1heWJlIA0Kbm90IHNvIGFjY3VyYXRlIHRvIGZpdCB3aXRoIHRoZSByZWFsaXR5 KS4gSW4gc3VjaCBjYXNlLCB3ZSdkIGxpa2UgbWVyZ2UgDQp0aGUmbmJzcDtleGlzdGluZyBWb0lQ IGFuZCBzdHJlYW1pbmcgc2VydmljZXMgaW50byBmZXdlciBtYWNoaW5lcyBhbmQgY3V0IGRvd24g DQp0aGUgbWFjaGluZXMgcnVubmluZyBvbmx5IGZldyBWb0lQIHVzYWdlIHRvIHJlZHVjZSB0aGUg cG93ZXIgDQpjb25zdW1wdGlvbi48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAw ZmYgc2l6ZT0yIGZhY2U9VmVyZGFuYT5JbiB0aGlzIHNlbmFyaW8sIHdlIG5lZWQgdG8gDQpjb25z aWRlciBob3cgdG8gbWlncmF0ZSB0aGUgZXhpc3RpbmcgVk0gc3RhdGVzLjwvRk9OVD48L0RJVj4N CjxESVY+PEZPTlQgY29sb3I9IzAwMDBmZiBzaXplPTIgZmFjZT1WZXJkYW5hPjwvRk9OVD4mbmJz cDs8L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDBmZiBzaXplPTIgZmFjZT1WZXJkYW5hPkxv b2tpbmcgZm9yd2FyZCB0byBkaXNjdXNzaW5nIG1vcmUgDQp1c2UgY2FzZXMgaW4gdGhlIG1haWxp bmcgbGlzdC48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwZmYgc2l6ZT0yIGZh Y2U9VmVyZGFuYT48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwZmYg c2l6ZT0yIGZhY2U9VmVyZGFuYT5CUjxCUj5ZdW5mZWk8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IHNpemU9MiBmYWNlPVZlcmRhbmE+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJViBhbGlnbj1sZWZ0 Pg0KPERJViBhbGlnbj1sZWZ0PjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+DQo8SFIgc3R5bGU9 IldJRFRIOiAxMjJweDsgSEVJR0hUOiAycHgiIFNJWkU9Mj4NCjwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgY29sb3I9I2MwYzBjMD48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPnpoYW5neXVuZmVp PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPjIwMTEtMDgtMjQ8 L0ZPTlQ+PC9GT05UPjwvRElWPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5h Pg0KPEhSPg0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmE+PEZPTlQgc2l6 ZT0yPjxTVFJPTkc+t6K8/sjLo7o8L1NUUk9ORz4gWWluZ2ppZSANCkd1KHlpbmdqaWUpPC9GT05U PjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hPjxGT05UIHNpemU9Mj48U1RS T05HPreiy83Ksbzko7o8L1NUUk9ORz4gDQoyMDExLTA4LTI0Jm5ic3A7MTM6NDE6MDQ8L0ZPTlQ+ PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmE+PEZPTlQgc2l6ZT0yPjxTVFJP Tkc+ytW8/sjLo7o8L1NUUk9ORz4gJ01lbGluZGEgU2hvcmUnOyANCnNhbWlAaWV0Zi5vcmc8L0ZP TlQ+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmE+PEZPTlQgc2l6ZT0yPjxT VFJPTkc+s63LzaO6PC9TVFJPTkc+IDwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9VmVyZGFuYT48Rk9OVCBzaXplPTI+PFNUUk9ORz7W98zio7o8L1NUUk9ORz4gUmU6IFtzYW1p XSBUcnlpbmcgdG8gDQpmaWd1cmUgb3V0IHdoZXJlIHdlIGFyZTwvRk9OVD48L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPg0KPERJVj5JICZuYnNwO3RoaW5rICZuYnNwO3dl ICZuYnNwO2FyZSAmbmJzcDtzdGlsbCAmbmJzcDtvbiAmbmJzcDt0aGUgJm5ic3A7cmlnaHQgDQom bmJzcDt3YXkgJm5ic3A7dG8gJm5ic3A7bW92ZSAmbmJzcDtmb3J3YXJkLiAmbmJzcDs8L0RJVj4N CjxESVY+V2UgJm5ic3A7bmVlZCAmbmJzcDt0byAmbmJzcDtoZWFyICZuYnNwO2RpZmZlcmVudCAm bmJzcDt2b2ljZSAmbmJzcDtzbyANCiZuYnNwO3RoYXQgJm5ic3A7d2UgJm5ic3A7Y2FuICZuYnNw O2tub3cgJm5ic3A7d2hhdCAmbmJzcDtnbyAmbmJzcDt0byANCiZuYnNwO3Blb3BsZSdzICZuYnNw O21pbmQ8L0RJVj4NCjxESVY+d2hlbiAmbmJzcDt0aGV5ICZuYnNwO3NlZSAmbmJzcDsiU3RhdGUg Jm5ic3A7TWlncmF0aW9uIi48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkZvciAmbmJz cDtub3csICZuYnNwO3dlICZuYnNwO2hhdmUgJm5ic3A7aGVhcmQgJm5ic3A7ZGlmZmVyZW50IA0K Jm5ic3A7b3BpbmlvbnMsICZuYnNwO2UuZy4gJm5ic3A7PC9ESVY+DQo8RElWPidzdGF0ZSAmbmJz cDttaWdyYXRpb24gJm5ic3A7Zm9yICZuYnNwO3NlcnZpY2UgJm5ic3A7ZmFpbG92ZXInICZuYnNw OzwvRElWPg0KPERJVj4nbmVlZCAmbmJzcDtkaWZmZXJlbnRpYXRlICZuYnNwO3JlcXVpcmVtZW50 cyAmbmJzcDtmb3IgDQombmJzcDtPcHRpbWl6YXRpb24tYmFzZWQgJm5ic3A7bWlncmF0aW9uICZu YnNwO2FuZDwvRElWPg0KPERJVj5yZXN0b3JhdGlvbi1iYXNlZCAmbmJzcDttaWdyYXRpb24nLCAm bmJzcDs8L0RJVj4NCjxESVY+J2xheWVyICZuYnNwOzIgJm5ic3A7Y29ubmVjdGl2aXR5ICZuYnNw O292ZXIgJm5ic3A7TDMgDQombmJzcDtpbmZyYXN0cnVjdHVyZScsICZuYnNwOzwvRElWPg0KPERJ Vj4ndGhpbmsgJm5ic3A7YWJvdXQgJm5ic3A7SVAgJm5ic3A7bW9iaWxpdHkgJm5ic3A7aW5zdGVh ZCAmbmJzcDtvZiANCiZuYnNwO3N0YXRlICZuYnNwO21pZ3JhdGlvbic8L0RJVj4NCjxESVY+J3Nl cnZpY2VzICZuYnNwO3J1bm5pbmcgJm5ic3A7b24gJm5ic3A7Vk0gJm5ic3A7d2lsbCAmbmJzcDtp bXBhY3QgJm5ic3A7dGhlIA0KJm5ic3A7d2F5ICZuYnNwO29mICZuYnNwO3N0YXRlICZuYnNwO21p Z3JhdGlvbicgJm5ic3A7YW5kICZuYnNwO21hbnk8L0RJVj4NCjxESVY+b3RoZXJzLiAmbmJzcDs8 L0RJVj4NCjxESVY+U29ycnkgJm5ic3A7dGhhdCAmbmJzcDtJICZuYnNwO2Rvbid0ICZuYnNwO2xp c3QgJm5ic3A7YWxsICZuYnNwO29mIA0KJm5ic3A7dGhlICZuYnNwO2lucHV0LiAmbmJzcDs8L0RJ Vj4NCjxESVY+VGhvdWdoICZuYnNwO25vdCAmbmJzcDthbGwgJm5ic3A7b2YgJm5ic3A7dGhlbSAm bmJzcDt3aWxsICZuYnNwO2ZpbmFsbHkgDQombmJzcDtiZSAmbmJzcDtpbiAmbmJzcDtzY29wZSwg Jm5ic3A7b3IgJm5ic3A7d2UgJm5ic3A7ZmluYWxseSAmbmJzcDtmYWlsIA0KJm5ic3A7dG88L0RJ Vj4NCjxESVY+Y2hhcnRlciAmbmJzcDthICZuYnNwO3dvcmthYmxlICZuYnNwO3Njb3BlICZuYnNw O2luICZuYnNwO0lFVEYsICZuYnNwO3RoZXkgDQombmJzcDthcmUgJm5ic3A7aGlnaGx5ICZuYnNw O3ZhbHVhYmxlICZuYnNwO2lucHV0ICZuYnNwO2ZvciAmbmJzcDtzY29wZTwvRElWPg0KPERJVj5k aXNjdXNzaW9uLiAmbmJzcDs8L0RJVj4NCjxESVY+VGhhbmsgJm5ic3A7eW91ICZuYnNwO3Zlcnkg Jm5ic3A7bXVjaC48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPk1lYW53aGlsZSwgJm5i c3A7SSAmbmJzcDthbHNvICZuYnNwO3RyeSAmbmJzcDt0byAmbmJzcDthc2sgJm5ic3A7REMgDQom bmJzcDtwcm92aWRlciAmbmJzcDt0byAmbmJzcDtzaGFyZSAmbmJzcDt0aGVpciAmbmJzcDt1c2Ug Jm5ic3A7Y2FzZXMuIA0KJm5ic3A7Q2hpbmE8L0RJVj4NCjxESVY+VGVsZWNvbSAmbmJzcDthbmQg Jm5ic3A7Q2hpbmEgJm5ic3A7TW9iaWxlLCAmbmJzcDt3aG8gJm5ic3A7YXJlICZuYnNwO2Fsc28g DQombmJzcDtsb29raW5nICZuYnNwO2ZvcndhcmQgJm5ic3A7dG8gJm5ic3A7YmVjb21lICZuYnNw O0RDPC9ESVY+DQo8RElWPnByb3ZpZGVyLCAmbmJzcDtzZWUgJm5ic3A7dGhlICZuYnNwO2NvbmNy ZXRlICZuYnNwO3JlcXVpcmVtZW50cyAmbmJzcDthbmQgDQombmJzcDtwcmVwYXJlICZuYnNwO3Rv ICZuYnNwO3dyaXRlICZuYnNwO2Rvd24gJm5ic3A7YSAmbmJzcDtkcmFmdCAmbmJzcDt0bzwvRElW Pg0KPERJVj5pbnRyb2R1Y2UgJm5ic3A7dGhlICZuYnNwO3VzZSAmbmJzcDtjYXNlcyAmbmJzcDtp biAmbmJzcDtyZWFsIA0KJm5ic3A7c2NlbmFyaW9zLiAmbmJzcDtCdXQgJm5ic3A7dGhleSAmbmJz cDttYXkgJm5ic3A7aW50cm9kdWNlICZuYnNwO3NvbWUgDQombmJzcDt1c2U8L0RJVj4NCjxESVY+ Y2FzZXMgJm5ic3A7dG8gJm5ic3A7bWFpbCAmbmJzcDtsaXN0ICZuYnNwO2JlZm9yZSAmbmJzcDt0 aGUgJm5ic3A7ZHJhZnQgDQombmJzcDtpcyAmbmJzcDtjb21wbGV0ZWQuPC9ESVY+DQo8RElWPiZu YnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+QmVzdCAmbmJzcDtSZWdhcmRzPC9E SVY+DQo8RElWPkd1ICZuYnNwO1lpbmdqaWU8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj4tLS0tLdPKvP7Urbz+LS0tLS08L0RJVj4NCjxESVY+t6K8/sjL OiAmbmJzcDtzYW1pLWJvdW5jZXNAaWV0Zi5vcmcgJm5ic3A7W21haWx0bzpzYW1pLWJvdW5jZXNA aWV0Zi5vcmddIA0KJm5ic3A7tPqx7SAmbmJzcDtNZWxpbmRhPC9ESVY+DQo8RElWPlNob3JlPC9E SVY+DQo8RElWPreiy83KsbzkOiAmbmJzcDsyMDExxOo41MIyNMjVICZuYnNwO8DWwNY1OjQzPC9E SVY+DQo8RElWPsrVvP7IyzogJm5ic3A7c2FtaUBpZXRmLm9yZzwvRElWPg0KPERJVj7W98ziOiAm bmJzcDtbc2FtaV0gJm5ic3A7VHJ5aW5nICZuYnNwO3RvICZuYnNwO2ZpZ3VyZSAmbmJzcDtvdXQg Jm5ic3A7d2hlcmUgDQombmJzcDt3ZSAmbmJzcDthcmU8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+ DQo8RElWPkFzICZuYnNwO3RoZSAmbmJzcDtkaXNjdXNzaW9uICZuYnNwO2hhcyAmbmJzcDtwcm9n cmVzc2VkICZuYnNwO2l0J3MgDQombmJzcDtiZWNvbWUgJm5ic3A7bW9yZS1vci1sZXNzICZuYnNw O2NsZWFyPC9ESVY+DQo8RElWPnRoYXQgJm5ic3A7dGhlcmUgJm5ic3A7bWlnaHQgJm5ic3A7cG9z c2libHkgJm5ic3A7cGVyaGFwcyAmbmJzcDtiZSANCiZuYnNwO29uZSAmbmJzcDtvciAmbmJzcDt0 d28gJm5ic3A7aW50ZXJlc3Rpbmc8L0RJVj4NCjxESVY+cHJvYmxlbXMgJm5ic3A7aGVyZSwgJm5i c3A7bWF5YmUsICZuYnNwO2FsdGhvdWdoICZuYnNwO3RoZSAmbmJzcDtwZW9wbGUgDQombmJzcDtw dXNoaW5nICZuYnNwO2ZvciAmbmJzcDt0aGU8L0RJVj4NCjxESVY+Y2hhcnRlcmluZyAmbmJzcDtv ZiAmbmJzcDtzb21ldGhpbmctb3Itb3RoZXIgJm5ic3A7KGFueXRoaW5nISkgJm5ic3A7dG8gDQom bmJzcDtkbyAmbmJzcDt3aXRoPC9ESVY+DQo8RElWPmRhdGEgJm5ic3A7Y2VudGVycyAmbmJzcDth bmQgJm5ic3A7dmlydHVhbGl6YXRpb24gJm5ic3A7c2VlbSAmbmJzcDt0byANCiZuYnNwO2JlICZu YnNwO3dvcmtpbmcgJm5ic3A7dmVyeSAmbmJzcDtoYXJkPC9ESVY+DQo8RElWPmluZGVlZCAmbmJz cDt0byAmbmJzcDtvYnNjdXJlICZuYnNwO2FueXRoaW5nICZuYnNwO3RoYXQgJm5ic3A7bWlnaHQg DQombmJzcDt0dXJuICZuYnNwO291dCAmbmJzcDt0byAmbmJzcDtoYXZlICZuYnNwO3NvbWU8L0RJ Vj4NCjxESVY+dmFsdWUuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5GaXJzdCwgJm5i c3A7dGhlcmUgJm5ic3A7YXBwZWFycyAmbmJzcDt0byAmbmJzcDtiZSAmbmJzcDthIA0KJm5ic3A7 c3Vic3RhbnRpYWwgJm5ic3A7cHJvYmxlbSAmbmJzcDtyZWxhdGVkICZuYnNwO3RvPC9ESVY+DQo8 RElWPm1vdmluZyAmbmJzcDtmbG93LWFzc29jaWF0ZWQgJm5ic3A7c3RhdGUgJm5ic3A7aW4gJm5i c3A7bWlkZGxlYm94ZXMgDQombmJzcDt3aGVuICZuYnNwO2EgJm5ic3A7bmV0d29yazwvRElWPg0K PERJVj5jb25uZWN0aW9uICZuYnNwOyhkZWxpYmVyYXRlbHkgJm5ic3A7a2VlcGluZyAmbmJzcDsi Y29ubmVjdGlvbiIgJm5ic3A7dmFndWUgDQombmJzcDtmb3IgJm5ic3A7dGhlPC9ESVY+DQo8RElW Pm1vbWVudCkgJm5ic3A7ZmFpbHMgJm5ic3A7b3Zlci4gJm5ic3A7ICZuYnNwO1RoaXMgJm5ic3A7 aGFzICZuYnNwO2NlcnRhaW5seSANCiZuYnNwO2NvbWUgJm5ic3A7dXAgJm5ic3A7aW4gJm5ic3A7 dGhlICZuYnNwO2NvbnRleHQ8L0RJVj4NCjxESVY+b2YgJm5ic3A7bXVsdGlob21lZCAmbmJzcDtj b25uZWN0aW9ucyAmbmJzcDtpbiAmbmJzcDtzY3RwLCAmbmJzcDthbmQgDQombmJzcDt0byAmbmJz cDtiZSAmbmJzcDtob25lc3QgJm5ic3A7STwvRElWPg0KPERJVj5oYXZlbid0ICZuYnNwO2ZvbGxv d2VkICZuYnNwO3RoYXQgJm5ic3A7YXMgJm5ic3A7Y2xvc2VseSAmbmJzcDthcyAmbmJzcDtJIA0K Jm5ic3A7c2hvdWxkLiAmbmJzcDsgJm5ic3A7U3RpbGwsICZuYnNwO2V2ZW48L0RJVj4NCjxESVY+ aWYgJm5ic3A7c2N0cCAmbmJzcDtoYXMgJm5ic3A7c29tZXRoaW5nICZuYnNwO3RoYXQgJm5ic3A7 d29ya3MgDQombmJzcDticmlsbGlhbnRseSAmbmJzcDt0aGVyZSAmbmJzcDt3b3VsZCAmbmJzcDti ZTwvRElWPg0KPERJVj5xdWVzdGlvbnMgJm5ic3A7YWJvdXQgJm5ic3A7YXBwbHlpbmcgJm5ic3A7 dGhlaXIgJm5ic3A7bWVjaGFuaXNtICZuYnNwO2luIA0KJm5ic3A7YSAmbmJzcDtkaWZmZXJlbnQ8 L0RJVj4NCjxESVY+Y29udGV4dC48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPlNlY29u ZCwgJm5ic3A7dGhlcmUgJm5ic3A7YXBwZWFycyAmbmJzcDt0byAmbmJzcDtiZSAmbmJzcDthbm90 aGVyIA0KJm5ic3A7c3Vic3RhbnRpYWwgJm5ic3A7cHJvYmxlbSw8L0RJVj4NCjxESVY+dGhpcyAm bmJzcDtvbmUgJm5ic3A7cmVsYXRlZCAmbmJzcDt0byAmbmJzcDtob3cgJm5ic3A7dG8gJm5ic3A7 aGFuZGxlIA0KJm5ic3A7cm91dGluZyAmbmJzcDthbmQgJm5ic3A7bmV0d29yazwvRElWPg0KPERJ Vj5zdGF0ZSAmbmJzcDt3aGVuICZuYnNwO2EgJm5ic3A7Vk0gJm5ic3A7aXMgJm5ic3A7bWlncmF0 ZWQgJm5ic3A7ZnJvbSANCiZuYnNwO29uZSAmbmJzcDtoeXBlcnZpc29yICZuYnNwO3RvICZuYnNw O2E8L0RJVj4NCjxESVY+bmV0d29yay10b3BvZ3JhcGhpY2FsbHktcmVtb3RlICZuYnNwO2h5cGVy dmlzb3IgJm5ic3A7d2hlbiAmbmJzcDtib3RoIA0KJm5ic3A7YXJlPC9ESVY+DQo8RElWPm9uICZu YnNwO3RoZSAmbmJzcDtzYW1lICZuYnNwO2xheWVyICZuYnNwOzIgJm5ic3A7c3VibmV0ICZuYnNw O2JlaW5nIA0KJm5ic3A7dHVubmVsZWQgJm5ic3A7b3ZlciAmbmJzcDthICZuYnNwO2xheWVyPC9E SVY+DQo8RElWPjMgJm5ic3A7dHJhbnNwb3J0ICZuYnNwOyhvciAmbmJzcDt3aGVuICZuYnNwO3Ro ZXkncmUgJm5ic3A7bm90ICZuYnNwO29uIA0KJm5ic3A7dGhlICZuYnNwO3NhbWUgJm5ic3A7c3Vi bmV0PC9ESVY+DQo8RElWPmF0ICZuYnNwO2FsbCwgJm5ic3A7d2hpY2ggJm5ic3A7SSAmbmJzcDtn YXRoZXIgJm5ic3A7aXMgJm5ic3A7Y29uc2lkZXJhYmx5IA0KJm5ic3A7bGVzcyAmbmJzcDtjb21t b24pLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+VGhlICZuYnNwO3Byb2JsZW0gJm5i c3A7aGVyZSAmbmJzcDtpcyAmbmJzcDt0aGF0ICZuYnNwO2l0J3MgJm5ic3A7bm90IA0KJm5ic3A7 YXQgJm5ic3A7YWxsICZuYnNwO2NsZWFyICZuYnNwO3RoYXQgJm5ic3A7dGhlcmUnczwvRElWPg0K PERJVj5hICZuYnNwO2NvbnN0aXR1ZW5jeSAmbmJzcDtmb3IgJm5ic3A7dGhlICZuYnNwO3dvcmsu ICZuYnNwOyAmbmJzcDtJJ20gDQombmJzcDtub3QgJm5ic3A7dGFsa2luZyAmbmJzcDthYm91dCAm bmJzcDtwZW9wbGU8L0RJVj4NCjxESVY+dG8gJm5ic3A7d3JpdGUgJm5ic3A7YW5kICZuYnNwO3Jl dmlldyAmbmJzcDtpbnRlcm5ldCAmbmJzcDtkcmFmdHMsIA0KJm5ic3A7YnV0ICZuYnNwO3JhdGhl ciAmbmJzcDtjb21wYW5pZXM8L0RJVj4NCjxESVY+c3RhbmRpbmcgJm5ic3A7dXAgJm5ic3A7YW5k ICZuYnNwO3NheWluZyAmbmJzcDsiV2UgJm5ic3A7d2FudCAmbmJzcDt0aGlzIA0KJm5ic3A7cHJv YmxlbSAmbmJzcDtzb2x2ZWQgJm5ic3A7YW5kICZuYnNwO3dlPC9ESVY+DQo8RElWPnRoaW5rICZu YnNwO2l0ICZuYnNwO3Nob3VsZCAmbmJzcDtiZSAmbmJzcDtzb2x2ZWQgJm5ic3A7dGhyb3VnaCAm bmJzcDthbiANCiZuYnNwO29wZW4gJm5ic3A7c3RhbmRhcmRzICZuYnNwO3Byb2Nlc3MsIjwvRElW Pg0KPERJVj5hbmQgJm5ic3A7ZGF0YSAmbmJzcDtjZW50ZXJzL3NlcnZpY2UgJm5ic3A7cHJvdmlk ZXJzICZuYnNwO3N0YW5kaW5nIA0KJm5ic3A7dXAgJm5ic3A7YW5kICZuYnNwO3NheWluZzwvRElW Pg0KPERJVj4iV2UgJm5ic3A7d291bGQgJm5ic3A7ZGVwbG95ICZuYnNwO3RoaXMuIiAmbmJzcDsg Jm5ic3A7U2F5aW5nICZuYnNwO3RoYXQgDQombmJzcDt5b3UncmUgJm5ic3A7YWJzb2x1dGVseTwv RElWPg0KPERJVj5jZXJ0YWluICZuYnNwO3RoYXQgJm5ic3A7c29tZWJvZHkgJm5ic3A7ZWxzZSAm bmJzcDt3b3VsZCAmbmJzcDtzYXkgDQombmJzcDtvbmUgJm5ic3A7b2YgJm5ic3A7dGhlc2UgJm5i c3A7dGhpbmdzPC9ESVY+DQo8RElWPmRvZXMgJm5ic3A7bm90ICZuYnNwO2NvdW50LjwvRElWPg0K PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+SXQgJm5ic3A7d291bGQgJm5ic3A7YmUgJm5ic3A7dW5m b3J0dW5hdGUgJm5ic3A7aWYgJm5ic3A7dGhlICZuYnNwO0lFVEYgDQombmJzcDt3ZXJlICZuYnNw O3RvICZuYnNwO3NpbmsgJm5ic3A7dmFsdWFibGU8L0RJVj4NCjxESVY+cmVzb3VyY2VzICZuYnNw O2ludG8gJm5ic3A7YW5vdGhlciAmbmJzcDtlZmZvcnQgJm5ic3A7dGhhdCAmbmJzcDtub2JvZHkg DQombmJzcDtjYXJlcyAmbmJzcDthYm91dDwvRElWPg0KPERJVj5vdGhlciAmbmJzcDt0aGFuICZu YnNwO3Blb3BsZSAmbmJzcDtsb29raW5nICZuYnNwO2ZvciAmbmJzcDtzdHVmZiAmbmJzcDt0byAN CiZuYnNwO3B1dCAmbmJzcDtvbiAmbmJzcDt0aGVpciAmbmJzcDtDVi48L0RJVj4NCjxESVY+SXMg Jm5ic3A7dGhlcmUgJm5ic3A7YW4gJm5ic3A7YXVkaWVuY2UgJm5ic3A7Zm9yICZuYnNwO3RoaXMg DQombmJzcDt3b3JrPzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+TWVsaW5kYTwvRElW Pg0KPERJVj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwv RElWPg0KPERJVj5zYW1pICZuYnNwO21haWxpbmcgJm5ic3A7bGlzdDwvRElWPg0KPERJVj5zYW1p QGlldGYub3JnPC9ESVY+DQo8RElWPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2FtaTwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188L0RJVj4NCjxESVY+c2FtaSAmbmJzcDttYWls aW5nICZuYnNwO2xpc3Q8L0RJVj4NCjxESVY+c2FtaUBpZXRmLm9yZzwvRElWPg0KPERJVj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhbWk8L0RJVj48L0ZPTlQ+PC9ESVY+ PC9CT0RZPjwvSFRNTD4NCg== --=====003_Dragon584666206555_=====-- From narten@us.ibm.com Wed Aug 24 05:22:07 2011 Return-Path: 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 629B721F8548 for ; Wed, 24 Aug 2011 05:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.453 X-Spam-Level: X-Spam-Status: No, score=-106.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 33hkWzcV8Oni for ; Wed, 24 Aug 2011 05:22:07 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by ietfa.amsl.com (Postfix) with ESMTP id C8D8D21F843B for ; Wed, 24 Aug 2011 05:22:06 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p7OBx011016341 for ; Wed, 24 Aug 2011 07:59:00 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p7OCN9Iw266698 for ; Wed, 24 Aug 2011 08:23:09 -0400 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p7O6N7Hs014575 for ; Wed, 24 Aug 2011 00:23:08 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-218-237.mts.ibm.com [9.65.218.237]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p7O6N6CU014509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Aug 2011 00:23:07 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p7OCN51m005937; Wed, 24 Aug 2011 08:23:06 -0400 Message-Id: <201108241223.p7OCN51m005937@cichlid.raleigh.ibm.com> To: "zhangyunfei" In-reply-to: <201108241403546051654@chinamobile.com> References: <4E541EE7.1080605@gmail.com> <000c01cc6220$3b18fa70$b14aef50$@com> <201108241403546051654@chinamobile.com> Comments: In-reply-to "zhangyunfei" message dated "Wed, 24 Aug 2011 14:03:54 +0800." Date: Wed, 24 Aug 2011 08:23:05 -0400 From: Thomas Narten Cc: "Yingjie Gu\(yingjie\)" , 'Melinda Shore' , "sami@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 12:22:07 -0000 "zhangyunfei" writes: > 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. How is this any different than standard VM migration as practiced today? What special requirements result from the above scenario? The topic of this effort is "state migration". In order to make progress, we need to be very specific about what kind of state and in what devices needs to be transferred. And why existing approaches as practiced today are insufficient. If folk cannot (in one or two paragraphs) answer the above questions, I do not think writing an Internet Draft about the above would be a good use of anyone's time. Thomas From hadi@mojatatu.com Wed Aug 24 05:29:16 2011 Return-Path: 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 0BFC421F8751 for ; Wed, 24 Aug 2011 05:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.624 X-Spam-Level: X-Spam-Status: No, score=-102.624 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 wSP4xqpi4I2J for ; Wed, 24 Aug 2011 05:29:15 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBE621F8B4A for ; Wed, 24 Aug 2011 05:29:15 -0700 (PDT) Received: by fxe6 with SMTP id 6so1048924fxe.31 for ; Wed, 24 Aug 2011 05:30:25 -0700 (PDT) Received: by 10.223.100.145 with SMTP id y17mr2102847fan.32.1314189024721; Wed, 24 Aug 2011 05:30:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.108.1 with HTTP; Wed, 24 Aug 2011 05:30:04 -0700 (PDT) In-Reply-To: <201108241223.p7OCN51m005937@cichlid.raleigh.ibm.com> References: <4E541EE7.1080605@gmail.com> <000c01cc6220$3b18fa70$b14aef50$@com> <201108241403546051654@chinamobile.com> <201108241223.p7OCN51m005937@cichlid.raleigh.ibm.com> From: Jamal Hadi Salim Date: Wed, 24 Aug 2011 08:30:04 -0400 Message-ID: To: Thomas Narten Content-Type: text/plain; charset=ISO-8859-1 Cc: "Yingjie Gu\(yingjie\)" , Melinda Shore , "sami@ietf.org" , zhangyunfei 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 12:29:16 -0000 On Wed, Aug 24, 2011 at 8:23 AM, Thomas Narten wrote: > How is this any different than standard VM migration as practiced > today? What special requirements result from the above scenario? > > The topic of this effort is "state migration". In order to make > progress, we need to be very specific about what kind of state and in > what devices needs to be transferred. And why existing approaches as > practiced today are insufficient. > > If folk cannot (in one or two paragraphs) answer the above questions, > I do not think writing an Internet Draft about the above would be a > good use of anyone's time. +1. cheers, jamal From guyingjie@huawei.com Thu Aug 25 05:52:20 2011 Return-Path: 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 62E7E21F86D0 for ; Thu, 25 Aug 2011 05:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.171 X-Spam-Level: X-Spam-Status: No, score=-103.171 tagged_above=-999 required=5 tests=[AWL=0.639, BAYES_00=-2.599, CN_BODY_35=0.339, 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 DF35YLiQgEWd for ; Thu, 25 Aug 2011 05:52:19 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 57CE721F8532 for ; Thu, 25 Aug 2011 05:52:19 -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 <0LQH00JMFICIQJ@szxga04-in.huawei.com> for sami@ietf.org; Thu, 25 Aug 2011 20:50:43 +0800 (CST) Received: from szxrg01-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 <0LQH00G8XICI8J@szxga04-in.huawei.com> for sami@ietf.org; Thu, 25 Aug 2011 20:50:42 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADK90753; Thu, 25 Aug 2011 20:50:42 +0800 (CST) Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 25 Aug 2011 20:50:36 +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; Thu, 25 Aug 2011 20:50:42 +0800 Date: Thu, 25 Aug 2011 20:51:52 +0800 From: "Yingjie Gu(yingjie)" In-reply-to: <201108241223.p7OCN51m005937@cichlid.raleigh.ibm.com> X-Originating-IP: [10.138.41.134] To: 'Thomas Narten' , 'zhangyunfei' Message-id: <005e01cc6325$c3bceca0$4b36c5e0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=gb2312 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: AcxiWKTku2fpVyHZTzmaV3zatU2rKQAgLAlQ X-CFilter-Loop: Reflected References: <4E541EE7.1080605@gmail.com> <000c01cc6220$3b18fa70$b14aef50$@com> <201108241403546051654@chinamobile.com> <201108241223.p7OCN51m005937@cichlid.raleigh.ibm.com> Cc: 'Melinda Shore' , sami@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 12:52:20 -0000 In previous mail discussion, there are questions on why should VM be migrated.=20 And also, in the side meeting at Quebec, people want to learn the use = case from real scenario.=20 I guess Yunfei's use case could be an answer to that.=20 Here are some of the states that I can see on the devices that need to = be migrated. 1. States on switches: 1.1 DHCP snooping table on ports; 1.2 IGMP snooping table on ports; 1.3 Dynamic ACL which is created by traffic or authentication; 2. States on FW 2.1 TCP Connect States 2.2 Dynamic ACL 3. States on LB 3.1 Connect States. 3.2 Session States. 4. States on IPS/IDS. 4.1 Cumulative data We can think about two scenarios: 1. VM migrate within the subnet under the same FW/LB/IPS. In this case, states also migrate under the same FW/LB/IPS etc. States need to be migrated include 1.1, 1.2, 1.3. 2. VM migrate between two geographic data center sites, but the two = sites are in the same subnet (refer to David Black's email). In this case, = states also migrate between FW/LB/IPS etc All the above states need to be migrated. Best Regards Gu Yingjie -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: sami-bounces@ietf.org [mailto:sami-bounces@ietf.org] = =B4=FA=B1=ED Thomas Narten =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA8=D4=C224=C8=D5 =C0=D6=C0=D620:23 =CA=D5=BC=FE=C8=CB: zhangyunfei =B3=AD=CB=CD: Yingjie Gu(yingjie); 'Melinda Shore'; sami@ietf.org =D6=F7=CC=E2: Re: [sami] Trying to figure out where we are "zhangyunfei" writes: > 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. How is this any different than standard VM migration as practiced today? What special requirements result from the above scenario? The topic of this effort is "state migration". In order to make progress, we need to be very specific about what kind of state and in what devices needs to be transferred. And why existing approaches as practiced today are insufficient. If folk cannot (in one or two paragraphs) answer the above questions, I do not think writing an Internet Draft about the above would be a good use of anyone's time. Thomas _______________________________________________ sami mailing list sami@ietf.org https://www.ietf.org/mailman/listinfo/sami From narten@us.ibm.com Thu Aug 25 06:11:18 2011 Return-Path: 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 CDC6121F87FC for ; Thu, 25 Aug 2011 06:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.467 X-Spam-Level: X-Spam-Status: No, score=-106.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 6reUVfa0mO97 for ; Thu, 25 Aug 2011 06:11:18 -0700 (PDT) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id 0409021F8783 for ; Thu, 25 Aug 2011 06:11:17 -0700 (PDT) Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by e8.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p7PCwiko014540 for ; Thu, 25 Aug 2011 08:58:44 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p7PDBEDt177196 for ; Thu, 25 Aug 2011 09:11:14 -0400 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p7P7BALj018886 for ; Thu, 25 Aug 2011 01:11:12 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-200-237.mts.ibm.com [9.65.200.237]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p7P7B97e018786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Aug 2011 01:11:09 -0600 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p7PDB8e1019968; Thu, 25 Aug 2011 09:11:09 -0400 Message-Id: <201108251311.p7PDB8e1019968@cichlid.raleigh.ibm.com> To: "Yingjie Gu(yingjie)" In-reply-to: <005e01cc6325$c3bceca0$4b36c5e0$@com> References: <4E541EE7.1080605@gmail.com> <000c01cc6220$3b18fa70$b14aef50$@com> <201108241403546051654@chinamobile.com> <201108241223.p7OCN51m005937@cichlid.raleigh.ibm.com> <005e01cc6325$c3bceca0$4b36c5e0$@com> Comments: In-reply-to "Yingjie Gu(yingjie)" message dated "Thu, 25 Aug 2011 20:51:52 +0800." Date: Thu, 25 Aug 2011 09:11:08 -0400 From: Thomas Narten Cc: 'Melinda Shore' , sami@ietf.org, 'zhangyunfei' 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 13:11:19 -0000 "Yingjie Gu(yingjie)" writes: > In previous mail discussion, there are questions on why should VM be > migrated. I think we should take it as a given that VMs move around. People do that today, we all see the value. > And also, in the side meeting at Quebec, people want to learn the use case > from real scenario. Yes. looking at specific scenarios allows us to ask the question of whether the scenario is realistic and corresponds to what operators actual do today (or want to do), or whether it is just a theoretical problem (in which case it's very questionable whether the IETF should do work.) > I guess Yunfei's use case could be an answer to that. See my previous posting, I don't understand what use case this is yet. > Here are some of the states that I can see on the devices that need to be > migrated. > 1. States on switches: > 1.1 DHCP snooping table on ports; How often does DHCP snooping take place in data centers? In other words, is this a real problem, or a theoretical one? > 1.2 IGMP snooping table on ports; I think we need to outline some specific scenarios that describe what the problem actually is here. Who is doing snooping, why, and why a VM move leaves something not working. > 1.3 Dynamic ACL which is created by traffic or authentication; A specific scenario would be helpful here. Both so I can understand the details of the problem, and so we can discuss whether the scenario is a real problem in existing datacenters today, or just a theoretical problem. > 2. States on FW > 2.1 TCP Connect States > 2.2 Dynamic ACL Same as above. > 3. States on LB > 3.1 Connect States. > 3.2 Session States. Same as above. > 4. States on IPS/IDS. > 4.1 Cumulative data Same as above. > We can think about two scenarios: > 1. VM migrate within the subnet under the same FW/LB/IPS. In this case, > states also migrate under the same FW/LB/IPS etc. > States need to be migrated include 1.1, 1.2, 1.3. Before we spend a lot of time on this, we need to establish that there are actual real scenarios that correspond to real problems happening in data centers today. If a problem is just theoretical, it becomes very unclear whether the IETF should do any work (at this time). I am not interested in discussing solutions, or even the problem in much detail, if there is no compelling scenario motivating the problems for which solutions are being considred. Thomas From warren@kumari.net Mon Aug 29 10:19:00 2011 Return-Path: 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 3215E21F8A97 for ; Mon, 29 Aug 2011 10:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, 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 wzMCAC9MhxQu for ; Mon, 29 Aug 2011 10:18:59 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 2345421F8A96 for ; Mon, 29 Aug 2011 10:18:58 -0700 (PDT) Received: from dhcp-172-19-118-113.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 1EFCC1B416C1; Mon, 29 Aug 2011 13:20:21 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <201108251311.p7PDB8e1019968@cichlid.raleigh.ibm.com> Date: Mon, 29 Aug 2011 13:20:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7E65C50E-F8F2-46D9-8675-0894B64B6D59@kumari.net> References: <4E541EE7.1080605@gmail.com> <000c01cc6220$3b18fa70$b14aef50$@com> <201108241403546051654@chinamobile.com> <201108241223.p7OCN51m005937@cichlid.raleigh.ibm.com> <005e01cc6325$c3bceca0$4b36c5e0$@com> <201108251311.p7PDB8e1019968@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1084) Cc: sami@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 17:19:00 -0000 On Aug 25, 2011, at 9:11 AM, Thomas Narten wrote: > "Yingjie Gu(yingjie)" writes: >=20 >> In previous mail discussion, there are questions on why should VM be >> migrated. >=20 > I think we should take it as a given that VMs move around. People do > that today, we all see the value. Yup. >=20 >> And also, in the side meeting at Quebec, people want to learn the use = case >> from real scenario. >=20 > Yes. looking at specific scenarios allows us to ask the question of > whether the scenario is realistic and corresponds to what operators > actual do today (or want to do), or whether it is just a theoretical > problem (in which case it's very questionable whether the IETF should > do work.) >=20 >> I guess Yunfei's use case could be an answer to that. >=20 > See my previous posting, I don't understand what use case this is yet. >=20 >> Here are some of the states that I can see on the devices that need = to be >> migrated. >=20 >> 1. States on switches: >> 1.1 DHCP snooping table on ports; >=20 > How often does DHCP snooping take place in data centers? In other > words, is this a real problem, or a theoretical one? >=20 >> 1.2 IGMP snooping table on ports; >=20 > I think we need to outline some specific scenarios that describe what > the problem actually is here. Who is doing snooping, why, and why a VM > move leaves something not working. >=20 >> 1.3 Dynamic ACL which is created by traffic or authentication; >=20 > A specific scenario would be helpful here. Both so I can understand > the details of the problem, and so we can discuss whether the > scenario is a real problem in existing datacenters today, or just a > theoretical problem. >=20 >> 2. States on FW >> 2.1 TCP Connect States >> 2.2 Dynamic ACL >=20 > Same as above. >=20 >=20 >> 3. States on LB >> 3.1 Connect States. >> 3.2 Session States. >=20 > Same as above. >=20 >> 4. States on IPS/IDS. >> 4.1 Cumulative data >=20 > Same as above. >=20 >> We can think about two scenarios: >> 1. VM migrate within the subnet under the same FW/LB/IPS. In this = case, >> states also migrate under the same FW/LB/IPS etc. >> States need to be migrated include 1.1, 1.2, 1.3. >=20 > Before we spend a lot of time on this, we need to establish that there > are actual real scenarios that correspond to real problems happening > in data centers today. If a problem is just theoretical, it becomes > very unclear whether the IETF should do any work (at this time). Yes. >=20 > I am not interested in discussing solutions, or even the problem in > much detail, if there is no compelling scenario motivating the > problems for which solutions are being considred. My message here is basically content free, I just wanted to support / = agree with what Thomas said -- this is fairly unusual, so worth = noting... W >=20 > Thomas > _______________________________________________ > sami mailing list > sami@ietf.org > https://www.ietf.org/mailman/listinfo/sami >=20 From guyingjie@huawei.com Mon Aug 29 18:29:38 2011 Return-Path: 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 9D64B21F8513 for ; Mon, 29 Aug 2011 18:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.715 X-Spam-Level: X-Spam-Status: No, score=-100.715 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345, 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 giwdS-193zsI for ; Mon, 29 Aug 2011 18:29:38 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id E8ACB21F8512 for ; Mon, 29 Aug 2011 18:29:37 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQP001B9W690O@szxga05-in.huawei.com> for sami@ietf.org; Tue, 30 Aug 2011 09:30:10 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQP00FRNW690C@szxga05-in.huawei.com> for sami@ietf.org; Tue, 30 Aug 2011 09:30:09 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml208-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADM09190; Tue, 30 Aug 2011 09:30:08 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 30 Aug 2011 09:30:05 +0800 Received: from g00107907 (10.138.41.134) by szxeml402-hub.china.huawei.com (10.82.67.32) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 30 Aug 2011 09:30:06 +0800 Date: Tue, 30 Aug 2011 09:30:58 +0800 From: "Yingjie Gu(yingjie)" In-reply-to: <201108251311.p7PDB8e1019968@cichlid.raleigh.ibm.com> X-Originating-IP: [10.138.41.134] To: 'Thomas Narten' Message-id: <001901cc66b4$789ad060$69d07120$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=gb2312 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: AcxjKKZ9/K94vpAmSF675tdIpJXszQDi6mZA X-CFilter-Loop: Reflected References: <4E541EE7.1080605@gmail.com> <000c01cc6220$3b18fa70$b14aef50$@com> <201108241403546051654@chinamobile.com> <201108241223.p7OCN51m005937@cichlid.raleigh.ibm.com> <005e01cc6325$c3bceca0$4b36c5e0$@com> <201108251311.p7PDB8e1019968@cichlid.raleigh.ibm.com> Cc: 'Melinda Shore' , sami@ietf.org, 'zhangyunfei' Subject: [sami] =?gb2312?b?tPC4tDogIFRyeWluZyB0byBmaWd1cmUgb3V0IHdoZXJl?= =?gb2312?b?IHdlIGFyZQ==?= X-BeenThere: sami@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: State Migration List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 01:29:38 -0000 Hi Thomas and all, We are making effort on a use case draft now, and will present it at = early Sep. Best Regards Gu Yingjie -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: Thomas Narten [mailto:narten@us.ibm.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA8=D4=C225=C8=D5 =C0=D6=C0=D621:11 =CA=D5=BC=FE=C8=CB: Yingjie Gu(yingjie) =B3=AD=CB=CD: 'zhangyunfei'; 'Melinda Shore'; sami@ietf.org =D6=F7=CC=E2: Re: [sami] Trying to figure out where we are "Yingjie Gu(yingjie)" writes: > In previous mail discussion, there are questions on why should VM be > migrated. I think we should take it as a given that VMs move around. People do that today, we all see the value. > And also, in the side meeting at Quebec, people want to learn the use = case > from real scenario. Yes. looking at specific scenarios allows us to ask the question of whether the scenario is realistic and corresponds to what operators actual do today (or want to do), or whether it is just a theoretical problem (in which case it's very questionable whether the IETF should do work.) > I guess Yunfei's use case could be an answer to that. See my previous posting, I don't understand what use case this is yet. > Here are some of the states that I can see on the devices that need to = be > migrated. > 1. States on switches: > 1.1 DHCP snooping table on ports; How often does DHCP snooping take place in data centers? In other words, is this a real problem, or a theoretical one? > 1.2 IGMP snooping table on ports; I think we need to outline some specific scenarios that describe what the problem actually is here. Who is doing snooping, why, and why a VM move leaves something not working. > 1.3 Dynamic ACL which is created by traffic or authentication; A specific scenario would be helpful here. Both so I can understand the details of the problem, and so we can discuss whether the scenario is a real problem in existing datacenters today, or just a theoretical problem. > 2. States on FW > 2.1 TCP Connect States > 2.2 Dynamic ACL Same as above. > 3. States on LB > 3.1 Connect States. > 3.2 Session States. Same as above. > 4. States on IPS/IDS. > 4.1 Cumulative data Same as above. > We can think about two scenarios: > 1. VM migrate within the subnet under the same FW/LB/IPS. In this = case, > states also migrate under the same FW/LB/IPS etc. > States need to be migrated include 1.1, 1.2, 1.3. Before we spend a lot of time on this, we need to establish that there are actual real scenarios that correspond to real problems happening in data centers today. If a problem is just theoretical, it becomes very unclear whether the IETF should do any work (at this time). I am not interested in discussing solutions, or even the problem in much detail, if there is no compelling scenario motivating the problems for which solutions are being considred. Thomas