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