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

"Y.J. GU" <guyingjie@huawei.com> Fri, 15 October 2010 08:16 UTC

Return-Path: <guyingjie@huawei.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 44A3F3A6C67 for <alto@core3.amsl.com>; Fri, 15 Oct 2010 01:16:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.011
X-Spam-Level:
X-Spam-Status: No, score=-99.011 tagged_above=-999 required=5 tests=[AWL=0.884, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_12=0.6, RDNS_NONE=0.1, 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 SJbp4OFNqfSp for <alto@core3.amsl.com>; Fri, 15 Oct 2010 01:16:54 -0700 (PDT)
Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id BD13F3A6C6B for <alto@ietf.org>; Fri, 15 Oct 2010 01:16:49 -0700 (PDT)
Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAB00C8DODZ0F@szxga02-in.huawei.com> for alto@ietf.org; Fri, 15 Oct 2010 16:18:00 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAB00L3DODZ6K@szxga02-in.huawei.com> for alto@ietf.org; Fri, 15 Oct 2010 16:17:59 +0800 (CST)
Received: from g00107907 ([10.138.41.80]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAB007X7ODZEP@szxml06-in.huawei.com> for alto@ietf.org; Fri, 15 Oct 2010 16:17:59 +0800 (CST)
Date: Fri, 15 Oct 2010 16:17:57 +0800
From: "Y.J. GU" <guyingjie@huawei.com>
In-reply-to: <95CC4772-BE72-403D-A1E8-4696E61BA3B2@cisco.com>
To: 'stefano previdi' <sprevidi@cisco.com>
Message-id: <006f01cb6c41$79fc8f20$50298a0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 7bit
Thread-index: ActqyniheLwzXKrER6eC/Ocn8gq2OgBdCVBw
Cc: 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: Fri, 15 Oct 2010 08:16:55 -0000

I don't see the protocol implications either for now. But I think this is an implementation issue that ALTO needs to consider. ALTO doesn't care about how the information is collected, however ALTO need to define how the network map should be like in this scenario, will the cost map change as well? 
And VMs migration might be a strong motivation for ALTO Server to update the ALTO information that has been distributed among the network.




> -----Original Message-----
> From: stefano previdi [mailto:sprevidi@cisco.com]
> Sent: Wednesday, October 13, 2010 7:22 PM
> To: Y.J. GU
> Cc: alto@ietf.org
> Subject: Re: [alto] How Data Center Virtualization influence ALTO mechanism.
> 
> 
> On Oct 9, 2010, at 9:18 AM, Y.J. GU wrote:
> 
> > Hi all,
> > I was thinking about how Data Center Virtualization and Virtual
> > Machine(VM) Migration will influence ALTO mechanism.
> >
> > Current ALTO Protocol defines clustering of peers according to their
> > IP Addresses. E.g. peers in same subnet will be classified into same
> > PID, and path cost will indicate the cost within and between PIDs,
> > which is also actually based on IP Addresses.
> 
> the methods of grouping are orthogonal to ALTO protocol specification.
> 
> There are ALTO implementations that allow address/prefixes grouping
> relaxed from pure IP aggregation. The fact that you use IP addresses
> in the protocol doesn't mean that locality is solely based on
> address/mask pairs.
> 
> It is mostly a policy definition by the ALTO and infrastructure
> operator.
> 
> 
> > In the current world, peers are partitioned by IP subnet. While
> > considering virtual machines migration, there might be more
> > interesting things to think of.
> >
> > 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'.  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). 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.
> 
> 
> that is true. ALTO relies on accurate infrastructure/topology
> information. It can be derived from lower layers (routing and below)
> or inferred by policy DBs.
> 
> 
> > VMs may migrate under, but not limited to, these situations: 1) to
> > save electricity power, 2) disaster recovery, 3) customer prefer
> > another Data Center, 4) company extension, etc. In the end, the
> > internet will not be a regular world partitioned by IP Addresses.
> 
> 
> the "swamp" already validated the theory...
> 
> 
> > Does anyone think this is an interesting aspect to study?
> 
> probably yes but I'm not sure I see the protocol implication.
> 
> s.
>