>> (Given the history of IP addressing, and the recent discussions
>> on this list, I don't know any other assumption we can make
>> except that IDs will look like meaningless randomly distributed
>> numbers.)
>>
>
> That is the worst case: a swamp. I don't think it'll be that bad
> overall, but there will definitely be pockets of it here and there. How
> desirable that is, and how often it will happen, depends on whether
> creating a swamp for your own benefit results in external or internal
> costs. Part of the problem with deaggregation in the DFZ is that the
> cost is almost entirely an externality -- I get the benefit, but every
> other operator pays.
I fully agree, and what I'm suggesting is that the (sad) history of
the initial success of CIDR followed by the recent backsliding which
I call "the PI heresy" shows us that economics will always tend to create
a swamp, so we'd better engineer the system for a swamp. And in a swamp,
any benefit from aggregation is both limited and unpredictable. (Would
anybody like to predict the effect of the collapse of the US financial
system on BGP4 aggregation two years from now?)
Robin argues:
> One way of improving scaling is for any of these million SPI
> networks which have adjoining address space to advertise their two
> or more UABs as a single MAB, instead of each UAB being a separate
> MAB.
True. But that is, to use the technical term, a crap-shoot, just as
BGP aggregation of adjoining PI prefixes is a crap-shoot. It will
be the exception rather than the rule; that's the nature of a swamp.
There are no natural economic forces that provide incentives for
aggregation.
So I stick to my guns: we need to map the edge-swamp into a significantly
smaller core-swamp, or nothing will change. Relying on aggregation at
the edge hasn't worked for BGP, so why should it work for any form
of EID/RLOC mapping (regardless of terminology)?
Brian
--------------------------
I disagree. In a network topology you can add to each node an additional attribute. E.g. a color like red or blue. But also a geo-location id which is like a second identifier, and it is as stable as can be and as aggregatable as can be:
James A. Michener writes in "Alaska" that one day in the far future San Francisco will smoothly arrive at the North Pole. a) we don't have to bother when this day will come. b) even then the geopatch of S.F. as of today will still be the same.
You can make any geolocation to be the center of multiple circles (neighborhoods) of different radius.
Regrettably, LISP creates a new namespace but hereby uses the same old IPv4 swamp address
space :-(
Heiner