Re: question about draft-irtf-nsrg-report-09.txt

"J. Noel Chiappa" <jnc@ginger.lcs.mit.edu> Thu, 24 April 2003 16:31 UTC

Received: from ran.ietf.org (ran.ietf.org [10.27.6.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22433; Thu, 24 Apr 2003 12:31:48 -0400 (EDT)
Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 198jw0-0007Bz-00 for ietf-list@ran.ietf.org; Thu, 24 Apr 2003 12:50:56 -0400
Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 198jtu-00079D-00 for ietf@ran.ietf.org; Thu, 24 Apr 2003 12:48:46 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22303 for <ietf@ietf.org>; Thu, 24 Apr 2003 12:26:30 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198jab-00072y-00 for ietf@ietf.org; Thu, 24 Apr 2003 12:28:49 -0400
Received: from ginger.lcs.mit.edu ([18.26.0.82]) by ietf-mx with esmtp (Exim 4.12) id 198jab-00072v-00 for ietf@ietf.org; Thu, 24 Apr 2003 12:28:49 -0400
Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h3OGT9tU002487; Thu, 24 Apr 2003 12:29:09 -0400
Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h3OGT9Hi002486; Thu, 24 Apr 2003 12:29:09 -0400
Date: Thu, 24 Apr 2003 12:29:09 -0400
From: "J. Noel Chiappa" <jnc@ginger.lcs.mit.edu>
Message-Id: <200304241629.h3OGT9Hi002486@ginger.lcs.mit.edu>
To: ietf@ietf.org
Subject: Re: question about draft-irtf-nsrg-report-09.txt
Cc: jnc@ginger.lcs.mit.edu
Sender: owner-ietf@ietf.org
Precedence: bulk

    > From: Keith Moore <moore@cs.utk.edu>

    > you immediately need to build a reliable system to map between the
    > two - where reliable means: fast, up-to-date, highly available,
    > provides repeatable results across the entire network.

Many people keep claiming this, but I've yet to see the case clearly laid
out as to why. Let me explain.

If you start with a design which basically replicates the capabilities of
the system we have today, you arrange it so that whatever transaction (in
the loose sense) that provided you with the IPvn address instead provides
you with the locator/identifier pair. So, if you did a DNS lookup, that
would give you back both; if you're a server and someone opens a
connection to you, that ICP packed would give you both.

Well, that's not a very interesting system, because it just replicates the
capabilities of the system we already have. To make it useful/interesting,
you want to be able to change the binding between the two.

Well, for many cases of current interest, you can in fact do that without
having a mapping system available. E.g. for multi-homing (done with
multiple addresses), at ICP time the multi-homed entity provides all of
its addresses. Etc, etc - I won't go into all the details now.


I'm *not* saying that I'm *sure* we *never* have need of such a mapping
system; I'm just saying that I don't think anyone has sat down and really
tried to work through the details and see how far you can get without one.

	Noel