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

Tao Ma <abcdmatao@gmail.com> Tue, 19 October 2010 05:08 UTC

Return-Path: <abcdmatao@gmail.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 80EB93A6BAF for <alto@core3.amsl.com>; Mon, 18 Oct 2010 22:08:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6]
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 TMUYzYxbjvSw for <alto@core3.amsl.com>; Mon, 18 Oct 2010 22:08:41 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id BC40A3A6C15 for <alto@ietf.org>; Mon, 18 Oct 2010 22:08:38 -0700 (PDT)
Received: by qwc9 with SMTP id 9so1383425qwc.31 for <alto@ietf.org>; Mon, 18 Oct 2010 22:10:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=dLDeFjdWt7fdaWhVWCROL1WuyjI4nWd+ao9qt8FF4S0=; b=rSajwtYC9REwVRrBPdCvqeWLndijDWcDe9nZivgplNEUt2u/pJ8HHEvTyu4pKsczG3 ikv3GR0dp2QqL4sdgBj20H6aZCeeGz6Q8DiR7UDfPEdO3Blj0sdvEDozZSvTbSRa9Zx9 d7hQUo4B/6pb7ogIJHBjjhrfqfeQIE+GFlT8c=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wUpY+/dzNuY88oPEKzDscuEb7A6AXEGrQ/Ks0+xdv1ZfS5pAQ45JBMuAtDKcLHhynu 9WY9XgemKYP8BdSNm4f7+uBNDkLvIMybEJcm6nCgjWO96xzEElZQfOCyFqHhy8iG5Iuv Qmgwfm83iat7KtNVXPrN09xYixvui7BHsWbBk=
MIME-Version: 1.0
Received: by 10.229.238.197 with SMTP id kt5mr4724217qcb.25.1287465002483; Mon, 18 Oct 2010 22:10:02 -0700 (PDT)
Received: by 10.229.41.143 with HTTP; Mon, 18 Oct 2010 22:10:02 -0700 (PDT)
In-Reply-To: <005e01cb6a86$df92c190$50298a0a@china.huawei.com>
References: <AANLkTi=V0YnzzKGih5F-2uOXzCkrD1wimSSmf1uo9s2R@mail.gmail.com> <005e01cb6a86$df92c190$50298a0a@china.huawei.com>
Date: Tue, 19 Oct 2010 13:10:02 +0800
Message-ID: <AANLkTi=W=FARHDd+aLgLDeAGQXwdFndzpafokJXLVs_N@mail.gmail.com>
From: Tao Ma <abcdmatao@gmail.com>
To: "Y.J. GU" <guyingjie@huawei.com>, sprevidi@cisco.com
Content-Type: multipart/alternative; boundary="001485f89a3c2240120492f14e9e"
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: Tue, 19 Oct 2010 05:08:46 -0000

Maybe the key question is how the change or update is possible if "VMs can
migrate to arbitrary site, not under the control and knowledge of ISP"(or
unknown to ALTO service provider). Like the secion 9.2 in "
draft-ietf-alto-protocol-05",  "In particular, a particular ALTO Service
provider may not be able to determine if connectivity with a particular
endhost will succeed over IPv4 or IPv6, as this may depend upon information
unknown to the ISP such as particular application implementations." I think
VM migration has the similar challenge and should be considered.

2010/10/15 Y.J. GU <guyingjie@huawei.com>

> 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 <sprevidi> at cisco.com]
> > Sent: Wednesday, October 13, 2010 7:22 PM
> > To: Y.J. GU
> > Cc: alto at 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.
> >
>
>
>
>
>   ------------------------------
>
> *From:* Tao Ma [mailto:abcdmatao@gmail.com]
> *Sent:* Tuesday, October 12, 2010 10:45 AM
> *To:* guyingjie@huawei.com
> *Cc:* qiuxiaofeng@gmail.com; alto@ietf.org; chunhong zhang;
> wifnstone@gmail.com; miwei1985@gmail.com
> *Subject:* Re: [alto] How Data Center Virtualization influence ALTO
> mechanism.
>
>
>
> Hi,
>     I think it is an interesting aspect for ALTO protocol to be considered.
> The current ALTO uses IP address as the endpoint adress for grouping and
> locating. For the VM migration, this would fail, especailly without the
> contol of the ISP or ALTO service provider. Can ALTO mechanism make some
> changes to reflect this migration in some way? By using other alternatives
> such as geolocations or PoP to group, can we avoid this and how?
> PS: I have a question personally. How the routing would succeed after VM
> are migrated without changing IP adress? Can you tell me some current
> mechanism? Thanks:)
> Tao Ma
> Beijing University of Posts and Telecommunications
>
>
>  From: *Y.J. GU* <guyingjie@huawei.com>
> Date: Sat, Oct 9, 2010 at 3:18 AM
> Subject: [alto] How Data Center Virtualization influence ALTO mechanism.
> To: alto@ietf.org
>
>
> 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.
>
> 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.
>
> 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.
>
> Does anyone think this is an interesting aspect to study?
>
>
>
> _______________________________________________
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>
>
>
>
>