[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

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