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 [EMAIL PROTECTED] 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
