Re: [RRG] Long term clean-slate only for the RRG?

["Tom Petch" <nwnetworks@dial.pipex.com>]

----- Original Message -----
From: "Noel Chiappa" <jnc@mercury.lcs.mit.edu>
To: <rrg@psg.com>
Cc: <jnc@mercury.lcs.mit.edu>
Sent: Thursday, June 26, 2008 4:41 PM
Subject: Re: [RRG] Long term clean-slate only for the RRG?


>   > From: Dino Farinacci <dino@cisco.com>
>
>   > the mapping database is something that has to scale on a grander scale
>   > that what we've seen with other mapping or caching databases.
>
> This triggered the following thought, something for people to think about:
>
> If one signs on to the concept of 'separate location from identity', and one
> also decides to support a high percentage of unmodified hosts, then that more
> or less inevitably implies a network-sized (i.e. distributed) mapping database
> (along with its attendent maintainence/deployment/etc costs).
>
Mulling this over, I think that the answer is not quite, at least theoretically.
That is, you need to translate between location and identity, and calling those
two numberspaces for the purposes of this (I know, others will call them one
numberspace), then a database is one way and gives you full flexibility as to
how the translation is done.  But an algorithm, such as a hash, could translate
between a numberspace containing a  24/32/64/128 bit identity and numberspace
with a 22 bit locator (assuming that FIBs will handle an entire number space of
22 bits, or even 23,  in future).

Of course, it is the distribution of numbers within the identity numberspace
that makes it unlikely that such an algorithm would yield a suitable result but
who knows?

Or put differently, there is another constraint, which you have not stated, on
the distribution of numbers in the identity numberspace, and their allocation to
organisations such as ISPs, that means a network sized database is probably the
only answer, but, as has been said before, this is a research group.

Tom Petch

> That's part of the reason I was at one point enamoured of adding identity
> above the internetwork layer: I worked out a TCP option that would make TCP
> connections be between endpoints, and the address-endpoint mapping was
> contained in the connection request - no need for a distributed mapping
> database. However, it did require changing the hosts...
>
> But if one thinks about it, it kind of makes sense that those two together
> imply the need for the mapping database. I mean, if the hosts can't be
> involved in providing bindings (because they don't change), and there's going
> to be a new namespace, how else can one create and promulgate the bindings
> involved in that new namespace, if not in a separate system?
>
> So I can't see anyway around the location-identity-separation +
> unmodified-hosts --> network-sized-mapping-database problem. Or is my brain
> just not working very well today, and there's some clever solution I have
> missed?
>
> If not, people need to seriously re-examine their commitment to the principle
> of separate of location and identity. Like multi-homing, it has benefits, but
> it also has inevitable costs. TANSTAAFL...
>
> Noel
>
> --
> to unsubscribe send a message to rrg-request@psg.com with the
> word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg