Re: [rrg] Alternative LISP critique

jnc@mercury.lcs.mit.edu (Noel Chiappa) Sat, 23 January 2010 19:34 UTC

Return-Path: <jnc@mercury.lcs.mit.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 EEB753A69E0 for <rrg@core3.amsl.com>; Sat, 23 Jan 2010 11:34:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.591
X-Spam-Level:
X-Spam-Status: No, score=-6.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 lt630P2lCOii for <rrg@core3.amsl.com>; Sat, 23 Jan 2010 11:34:19 -0800 (PST)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 311163A69C8 for <rrg@irtf.org>; Sat, 23 Jan 2010 11:34:19 -0800 (PST)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 1093A6BE55A; Sat, 23 Jan 2010 14:34:13 -0500 (EST)
To: rrg@irtf.org
Message-Id: <20100123193414.1093A6BE55A@mercury.lcs.mit.edu>
Date: Sat, 23 Jan 2010 14:34:13 -0500
From: jnc@mercury.lcs.mit.edu
Cc: jnc@mercury.lcs.mit.edu
Subject: Re: [rrg] Alternative LISP critique
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: Sat, 23 Jan 2010 19:34:20 -0000

    > From: Robin Whittle <rw@firstpr.com.au>

    > CONS, ALT and now, from what you wrote in a previous message, DNS-based
    > mapping. (But I see below "LISP-TREE".) 

LISP-TREE is the DNS-based system.


    > If there is a single DNS server for looking up all mapping

Huh?

    > then in the "vast majority of cases", it must know the mapping itself,
    > or have cached it via a recent ... lookup to an authoritative server. 

That is not how DNS works; DNS allows caching (at the users) of intermediate
nodes in the resolution hierarchy. That's how you get single-RTT lookups in
most cases - with decent fan-out in the hierarchy, the intermediate nodes are
cached by the end-users (ITRs in this case).


    > If the end-user network has a lot of queries, due to being a popular
    > network and/or due to it having very short caching time, then there
    > needs to be a way they can pay whoever runs the DNS for their part of
    > the EID space.

Seems to work now - things in google.com get a zillion hits.

	Noel