[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