Re: [rrg] Ivip exemplifies Noel's support for "Adventurous Practical Design"

Robin Whittle <rw@firstpr.com.au> Mon, 25 January 2010 09:15 UTC

Return-Path: <rw@firstpr.com.au>
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 C3A6E3A68F3 for <rrg@core3.amsl.com>; Mon, 25 Jan 2010 01:15:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.705
X-Spam-Level:
X-Spam-Status: No, score=0.705 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327]
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 z29vOo7cnKRW for <rrg@core3.amsl.com>; Mon, 25 Jan 2010 01:15:26 -0800 (PST)
Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id ED79E28B23E for <rrg@irtf.org>; Mon, 25 Jan 2010 01:15:22 -0800 (PST)
Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 9BE10175C31; Mon, 25 Jan 2010 20:15:23 +1100 (EST)
Message-ID: <4B5D612B.4080500@firstpr.com.au>
Date: Mon, 25 Jan 2010 20:15:23 +1100
From: Robin Whittle <rw@firstpr.com.au>
Organization: First Principles
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: rrg@irtf.org
References: <20100123194200.5429C6BE55A@mercury.lcs.mit.edu>
In-Reply-To: <20100123194200.5429C6BE55A@mercury.lcs.mit.edu>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Noel Chiappa <jnc@mercury.lcs.mit.edu>
Subject: Re: [rrg] Ivip exemplifies Noel's support for "Adventurous Practical Design"
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: Mon, 25 Jan 2010 09:15:31 -0000

Hi Noel,

You wrote:

>>> In a system which is designed for a very long lifetime, design for the
>>> outer envelope of technology today - because tomorrow's will be a lot
>>> more capable.
>
>> I entirely agree with you on this.  I will be tempted to cite it as:
>> ...
>> If there is a practical way of getting mapping in real-time to local
>> full-database query servers

then there would be no need to do a lot of the complex things which
burden LISP ITRs and ETRs.

> Hardware improvements often cannot beat _scaling_ issues (such as keeping up
> with growth in the size of a full database).
> 
> I mean, scaling issues are the reason we are here now, right?
> 
> I was talking about relying on more capable hardware in pushing for more
> advanced _functionality_ - the example that brought up the above was doing
> crypto in portable devices.

I am talking about a specific approach to getting real-time mapping
to local full database query servers:

  http://tools.ietf.org/html/draft-whittle-ivip-fpr-00

Past and current LISP development seems to be predicated on the
belief that this, or anything like it, is and will remain impossible.

None of the LISP team has ever written why this is impossible, except
in the most general terms, as you just did - which is not a response
to this specific suggestion.

 - Robin