Re: [RRG] Re: Fast and sparse mapping?

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

Stephen,

On 2008-09-17 07:15, Stephen Sprunk wrote:
> Brian E Carpenter wrote:
>> On 2008-09-16 15:24, Robin Whittle wrote:
>>  
>>> Subject: Re: [RRG] Consequences of no renumbering...
>>>    
>>>> I missed the bit where it was proved that fast mapping
>>>> mathematically requires aggregatable EIDs.
>>>>       
>>> Who suggested this?
>>>     
>>
>> I've seen numerous references to EIDs needing to aggregate.
>> I'd like to know why.
>>   
> 
> It depends on what level you're discussing.  It would be advantageous if
> the entire set of possible EIDs could be aggregated, because that makes
> it easier to inject an aggregate route (or small set of routes) into the
> existing DFZ.
> 
>>>> If not, why can't we start on the assumption that we know how to
>>>> support a map with 8 or 10 million entries, and have many years to
>>>> figure out a sparse  mapping system with several orders of
>>>> magnitude more entries?
>>>>       
>>> I don't understand what "sparse mapping" means.
>>>     
>>
>> One where we assume that no aggregation is possible in the ID space,
>> i.e. the ID space is sparsely populated.
>>   
> 
> I think it's reasonable to assume that EIDs within a site will be
> commonly aggregated so that a site with a million EIDs may only need to
> consume one mapping entry rather than a million.  However, the system
> cannot require that will _always_ be the case, just optimize for it when
> it happens.  It does not help much if a site has to get 20+ EID prefixes
> so that they can have 20 different mappings...
> 
>> (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

--
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