Re: [alto] How Data Center Virtualization influence ALTO mechanism.

Lars Eggert <lars.eggert@nokia.com> Tue, 12 October 2010 07:16 UTC

Return-Path: <lars.eggert@nokia.com>
X-Original-To: alto@core3.amsl.com
Delivered-To: alto@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6AF33A68B7 for <alto@core3.amsl.com>; Tue, 12 Oct 2010 00:16:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.877
X-Spam-Level:
X-Spam-Status: No, score=-102.877 tagged_above=-999 required=5 tests=[AWL=-0.878, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzJgZuKK4lC1 for <alto@core3.amsl.com>; Tue, 12 Oct 2010 00:16:38 -0700 (PDT)
Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id 027823A682B for <alto@ietf.org>; Tue, 12 Oct 2010 00:16:37 -0700 (PDT)
Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o9C7Hlo1001265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Oct 2010 10:17:47 +0300
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.96.3 at fit.nokia.com
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/signed; boundary="Apple-Mail-22--677011245"; protocol="application/pkcs7-signature"; micalg="sha1"
From: Lars Eggert <lars.eggert@nokia.com>
In-Reply-To: <006201cb6782$2cb463a0$45548a0a@china.huawei.com>
Date: Tue, 12 Oct 2010 10:17:13 +0300
Message-Id: <C8E8F68D-1560-4329-B370-D5A182C7F6F5@nokia.com>
References: <006201cb6782$2cb463a0$45548a0a@china.huawei.com>
To: "Y.J. GU" <guyingjie@huawei.com>
X-Mailer: Apple Mail (2.1081)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Tue, 12 Oct 2010 10:17:41 +0300 (EEST)
X-Nokia-AV: Clean
Cc: "alto@ietf.org" <alto@ietf.org>
Subject: Re: [alto] How Data Center Virtualization influence ALTO mechanism.
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/alto>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Oct 2010 07:16:39 -0000

Hi,

On 2010-10-9, at 10:18, Y.J. GU wrote:
> In Data Center operation, one basic consensus is 'When Virtual Machines move from one site to another, the IP Addresses will not change, so that the existing service connection will not be broken'.

inside one data center, sure. Maybe even across data centers, with PI space and a coordinated route update. But I don't think that'd common practice.

>  VMs can migrate to arbitrary site, not under the control and knowledge of ISP. For example, some VMs in Data Center A(IP subnet 198.1.1.0) move to Data Center B (IP subnet 210.1.1.0).

Huh? Didn't you just say above that the IP addresses wouldn't change?

> IP-based, Vms are closer to DC-A. Physically, these VMs are much closer to hosts in DC-B. However things are not so easy, especially considering how these VMs are routed. Current ALTO may give wrong cost ranking.

If you're moving VMs around in the topology, you'll have to update the announced ALTO information as you do that. 

But since ALTO merely "provide(s) applications with information to perform better-than-random initial peer selection" - a direct quote from the charter - inaccurate or incorrect ALTO information is not catastrophic anyway.

Lars