Re: [rrg] AIS - goals

Lan Wang <lanwang@memphis.edu> Wed, 10 February 2010 00:15 UTC

Return-Path: <lanwang@memphis.edu>
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16D7828C18F for <rrg@core3.amsl.com>; Tue, 9 Feb 2010 16:15:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 pKVAm3PdTpL0 for <rrg@core3.amsl.com>; Tue, 9 Feb 2010 16:15:45 -0800 (PST)
Received: from itmta2.memphis.edu (itmx2.memphis.edu [141.225.112.71]) by core3.amsl.com (Postfix) with ESMTP id A030328C18B for <rrg@irtf.org>; Tue, 9 Feb 2010 16:15:45 -0800 (PST)
Received: from itexfe7.uom.memphis.edu (itexfe7.memphis.edu [10.15.1.68]) by itmta2.memphis.edu (Postfix) with ESMTP id C38A7A0C02C for <rrg@irtf.org>; Tue, 9 Feb 2010 18:16:53 -0600 (CST)
Received: from [192.168.1.2] (209.91.4.136) by ummail.memphis.edu (10.15.1.68) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 9 Feb 2010 18:16:54 -0600
In-Reply-To: <4B662667.3050703@firstpr.com.au>
References: <4B662667.3050703@firstpr.com.au>
MIME-Version: 1.0 (Apple Message framework v753.1)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-ID: <298FC6D1-7284-46F2-8389-09334F842DDA@memphis.edu>
Content-Transfer-Encoding: 7bit
From: Lan Wang <lanwang@memphis.edu>
Date: Tue, 09 Feb 2010 18:16:36 -0600
To: Robin Whittle <rw@firstpr.com.au>
X-Mailer: Apple Mail (2.753.1)
Cc: RRG Mailing List <rrg@irtf.org>
Subject: Re: [rrg] AIS - goals
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Feb 2010 00:15:48 -0000

Robin,

Thank you very much for your questions.  I'll try to answer some of  
your questions.  Lixia and other members of our team will add their  
comments.

On Jan 31, 2010, at 6:55 PM, Robin Whittle wrote:

> Hi Lixia,
>
> Thanks for pointing out (in an off-list message) that I had
> mischaracterised the goals of "Aggregation with Increasing Scopes: An
> Evolutionary Path Towards Global Routing Scalability".
>
> I wrote (msg05835) that this proposal was aimed at "Improving router
> utilization as a prelude to adopting a solution".  My description in
> msg05835 was also inaccurate except for my note that it:
>
>    suggests it is near-term preliminary to a longer-term
>    host-based solution - implicitly a Core-Edge Elimination scheme.

Your interpretation is not exactly what we meant to say.   We aim to  
solve the routing scalability problem both in the near term and in  
the long term through increasing scope of aggregation.  The following  
paragraph from our proposal says that our solution is orthogonal to a  
host-based solution.  Since a host-based solution will not solve the  
routing scalability problem until a large portion of the Internet  
hosts adopt it, we still need a short-term solution (in our proposal,  
the first two steps FIB aggregation and Virtual Aggregation will  
serve this purpose).  If a host-based solution never gets widely  
deployed, the later steps in our proposal (e.g. inter-AS VA) will  
address the long-term scalability needs.

A major consideration for our work is incremental deployability and  
immediate scalability benefit to anyone who adopts our scheme.  You  
may recall that we started with a map-and-encap scheme APT, which  
falls into the core-edge separation category. However, during the  
past couple of years working on APT, we realized that it is difficult  
for a single entity to deploy APT and receive immediate benefit.  Our  
work has evolved based on this understanding.

>
> This is based on this passage from the PDF version of the proposal:
>
>    Note that our proposal neither interferes nor prevents
>    any revolutionary host-based solutions such as ILNP from
>    being rolled out. However, host-based solutions do not
>    bring useful impact until a large portion of hosts have
>    been upgraded. Thus even if a host-based solution is
>    rolled out in the long run, an evolutionary solution is
>    still needed for the near term.
>
> I apologise for these misleading descriptions, which were based on
> only partially reading the proposal.
>
>
> The RRG Report mentions only two of the three documents:
>
>   The Virtual Aggregation presentation:
>    http://tools.ietf.org/agenda/76/slides/grow-5.pdf
>
>   The ID:
>    http://tools.ietf.org/html/draft-zhang-evolution-02
>
> but does not mention the PDF file:
>    http://www.ietf.org/mail-archive/web/rrg/current/pdfkyygpVszbl.pdf
>
> which was posted to the list in (msg05550).  The RRG wiki link is
> only to the PDF file.

The PDF file on the RRG wiki page is our 2-page summary, as requested  
by the chairs.  The ID http://tools.ietf.org/html/draft-zhang- 
evolution-02 provides more information.  It is cited in the 2-page  
PDF file.  The ID contains a more detailed description of the  
mechanisms.
>
>
> Due to caching constraints, I do not plan to read these fully until I
> have tackled the other proposals.  Based on my partial reading, here
> are some questions which I hope you will be able to answer:
>
>   1 - What are the goals of AIS?  How many non-mobile end-user
>       network prefixes do you plan the system to scale to?
>
>       Brian Carpenter and I have both, independently, suggested
>       that 10 million such networks should be a goal.

Our main goal is to scale routing (i.e. FIB size, RIB size, update  
rate).  We're not aiming at a specific size, and I don't think  
there's a specific upper size limit for our approach.  One reason is  
that there are engineering trade-offs involved.   We have some  
evaluation results in a submitted paper.

>
>       I think we must all expect that in the foreseeable future -
>       to 2020 or 2025 - that the majority of hosts will be mobile
>       hand-held devices.  There really needs to be a mobility system
>       so they can continue their sessions despite gaining and losing
>       multiple addresses in various access networks - including IPv4
>       addresses behind NAT, such as by using WiFi in homes and
>       offices.  I think we should consider 10 billion of these the
>       upper limit.
>
>       "Mobility" is not mentioned in your proposal.  To what extent
>       is AIS intended to support large-scale mobility?

Our position for mobility support is that it is best provided by  
mechanisms outside the routing system.   Here's a paper that  
describes the supporting arguments: "Support Mobility in the Global  
Internet", Lixia Zhang, Ryuji Wakikawa, Zhenkai Zhu. http:// 
www.cs.ucla.edu/~lixia/papers/micnet09.pdf

I'll send another email to answer your remaining questions.

Lan