Re: [dc] draft-khasnabish-vmmi-problems-00.txt

liu.bin21@zte.com.cn Wed, 01 February 2012 04:35 UTC

Return-Path: <liu.bin21@zte.com.cn>
X-Original-To: dc@ietfa.amsl.com
Delivered-To: dc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78BD711E80A5 for <dc@ietfa.amsl.com>; Tue, 31 Jan 2012 20:35:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -95.714
X-Spam-Level:
X-Spam-Status: No, score=-95.714 tagged_above=-999 required=5 tests=[AWL=5.524, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, 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 NqmyrHwYrJOJ for <dc@ietfa.amsl.com>; Tue, 31 Jan 2012 20:34:59 -0800 (PST)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 09F4A11E808D for <dc@ietf.org>; Tue, 31 Jan 2012 20:34:58 -0800 (PST)
Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 53829122734555; Wed, 1 Feb 2012 12:30:28 +0800 (CST)
Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 5467.122734555; Wed, 1 Feb 2012 12:34:50 +0800 (CST)
Received: (from root@localhost) by mse01.zte.com.cn id q114YnPX010960 for <dc@ietf.org>; Wed, 1 Feb 2012 12:34:49 +0800 (GMT-8) (envelope-from liu.bin21@zte.com.cn)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q113unSV082136; Wed, 1 Feb 2012 11:56:50 +0800 (GMT-8) (envelope-from liu.bin21@zte.com.cn)
Message-Id: <201202010434.q114YnPX010960@mse01.zte.com.cn>
To: narten@us.ibm.com, vumip1@gmail.com
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006
From: liu.bin21@zte.com.cn
Date: Wed, 01 Feb 2012 11:56:47 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-02-01 11:56:51, Serialize complete at 2012-02-01 11:56:51
Content-Type: multipart/alternative; boundary="=_alternative 0015AECF48257997_="
X-MAIL: mse01.zte.com.cn q114YnPX010960
X-MSS: AUDITRELEASE@mse01.zte.com.cn
Cc: dc@ietf.org
Subject: Re: [dc] draft-khasnabish-vmmi-problems-00.txt
X-BeenThere: dc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Data Center Mailing List <dc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dc>, <mailto:dc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dc>
List-Post: <mailto:dc@ietf.org>
List-Help: <mailto:dc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dc>, <mailto:dc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Feb 2012 04:35:00 -0000

Thomas, thank you for your comments! 

About VM migration in the draft, we did not demand forcibly between the 
different vender(or SPs), so your concerns may not 
exist. As you say, "let's be realistic", our intention is to improve the 
flexibility of VM migration, as well as the breadth 
of applications under the premise of market heavyweights are not opposed 
to it.In order to achieve these goals, analyse possible problems, discuss 
and resolve these problems, such as: VM migration is due to a non-public 
sector energy-efficient needs, rather than to public access without 
interruption, or business needs of the user's desktop migration, this 
demand may exist within a same service provider, or you say a same vender 
with mixed network, for example:

With the promotion of IPv6 technology, the existing IPv4 networks will be 
more and more IPv6 hosts, these applications driven 
a series of tunnel technologies to provide solutions, such as: 6to4 tunnel 
technology, ISATAP tunnel technology, and so on. 
Virtual machine migration technology will also be the basis of these 
network environments,in the transition network using tunneling transition 
technique, the connections between the subnets and the backbone network 
are achieved through the tunneling gateway. In the IPv4/IPv6 transition 
period, a variety of tunnels coexist. The establishment of the tunnel 
varies with different gateways. The traditional tunneling gateway only 
establishes tunnels for communication with the same type of gateway, the 
different types of traditional tunneling gateway cannot communicate with 
each other, which cannot meet the requirements of VPN communications in 
the transition period. A multi-tunnel VPN gateway is used to solve the 
problem of establishing the tunnel between the heterogeneous gateways.

Many thanks for guidance

Regards,

Bin Liu

liu.bin21@zte.com.cn
Richard.BoHan.liu@gmail.com


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.