On Jan 10, 2008, at 1:45 AM, Dino Farinacci wrote:
Excuse me? Caching failed miserably. Per-host caching was
growing to be larger than the number of prefixes in the RIB, and
per-prefix caching would have covered 80% of the RIB.
That's because of the granularity of the cache which required more
entries. If the original fastswitching design used prefix-based
population, it would have suffice.
Negatory there, good buddy. Please read what I wrote. A prefix
based cache would have provided NO advantages whatsoever, as it
would have instantly been fully populated.
I don't believe the 80% number.
So we are not going anywhere. So let me ask this, if DNS resolvers
need to have caches and browsers need to have caches, why shouldn't a
mapping cache that could be as large as these other databases have a
cache.
You guys that are not favoring caches can other favor full tables and
that can't scale to 10^10.
So do you have a proposal?
? You missed my point: you pick all, simultaneously. You let your
particular working set characteristics in your particular location
select which particular approach you use at that particular
location. All of the choices need to be integrated so that they
result in one clean mechanism.
We have already made that conclusion. You should have seen that at RRG.
Dino
--
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
