Re: [dc] draft-khasnabish-vmmi-problems-00.txt
"Richard.BoHan liu" <richard.bohan.liu@gmail.com> Mon, 06 February 2012 23:33 UTC
Return-Path: <richard.bohan.liu@gmail.com>
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 A543421F85ED for <dc@ietfa.amsl.com>; Mon, 6 Feb 2012 15:33:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_62=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 kq+AxW+bOqxo for <dc@ietfa.amsl.com>; Mon, 6 Feb 2012 15:33:57 -0800 (PST)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 042C821F85D4 for <dc@ietf.org>; Mon, 6 Feb 2012 15:33:56 -0800 (PST)
Received: by pbcwz7 with SMTP id wz7so2524654pbc.31 for <dc@ietf.org>; Mon, 06 Feb 2012 15:33:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=gUgeiQmDDrCryqg3JxeB0b/FMbS2JmxPUD7HgICE9UA=; b=TL3lBuK4ulbTgB8MYkAgRibQrYIkUb12eKSx5Ynr1lo4Fbz5I30uVNcCl6Dtlsy/IR NhBEOhqAJL72P42NQUp28sZ2WwLAuatHuHBKosWDRGedR5uH+9lEjSSZVUJhDBvBYVVP g0ECuBnuln+wrTBzN5LPBKWlNjG09Fw5ms/Cw=
MIME-Version: 1.0
Received: by 10.68.232.202 with SMTP id tq10mr52048519pbc.68.1328571236833; Mon, 06 Feb 2012 15:33:56 -0800 (PST)
Received: by 10.143.156.4 with HTTP; Mon, 6 Feb 2012 15:33:56 -0800 (PST)
Date: Tue, 07 Feb 2012 07:33:56 +0800
Message-ID: <CABHc4M0z+eQkL5=EhN9EmTpE6kjbXjjPpVCCsrm0ENjYoXVq-A@mail.gmail.com>
From: "Richard.BoHan liu" <richard.bohan.liu@gmail.com>
To: tboyes@gmail.com
Content-Type: text/plain; charset="ISO-8859-1"
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: Mon, 06 Feb 2012 23:33:57 -0000
> The tunneling technologies mentioned (6to4, ISATAP, etc) should be kept out of data centers. The tunneling technologies mentioned should belong to the scope of VPN4DC. So inevitably, we need to do some work to make them interoperable. -------------------------------------------------------------------------------- On Tue, Jan 31, 2012 at 10:56 PM, <liu.bin21 at zte.com.cn> wrote: 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 at zte.com.cn Richard.BoHan.liu at gmail.com I understand the first section in the above comments regarding virtual machines. In the context of IPv6 adoption for virtual machines or rather generically in data centers, I see native IPv6-only or dual stack as being the choice for numbering VMs. The tunneling technologies mentioned (6to4, ISATAP, etc) should be kept out of data centers. -- --truman
- Re: [dc] draft-khasnabish-vmmi-problems-00.txt Lizhong Jin
- Re: [dc] draft-khasnabish-vmmi-problems-00.txt Vishwas Manral
- Re: [dc] draft-khasnabish-vmmi-problems-00.txt liu.bin21
- Re: [dc] draft-khasnabish-vmmi-problems-00.txt liu.bin21
- Re: [dc] draft-khasnabish-vmmi-problems-00.txt david.black
- Re: [dc] draft-khasnabish-vmmi-problems-00.txt Truman Boyes
- Re: [dc] draft-khasnabish-vmmi-problems-00.txt Richard.BoHan liu