CEF was not created because caching failed. It was created because
the way caching was implemented was not optimal.
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.
And from today's statistics that in an average router, only 10% of the
FIB entries are typically in use, the forwarding cache could be much
smaller than the RIB.
Caching is NOT worthwhile when the working set is 80% of the full
table.
I agree with that.
It was not a question of having a partial table (i.e. cache) versus
a full table (i.e. a RIB's worth of data), but how the forwarding
table was populated.
The population was expensive, but originally it was deemed
worthwhile because the cached lookups were faster and certain folks
didn't know how to do a tree walk and there was no regard for the
resulting space complexity when used in the core. The original host
cache was simply designed for the enterprise and made no sense
anywhere else. In fact, even in large enterprises, there were
issues simply due to the number of hosts and the smallish number of
cache buckets originally allocated.
Yes, I am well aware there were more than one problem.
Who do you think reviewed for original CEF code? ;-)
1) Populate the mapping cache for active flows only.
2) Install a default mapping cache entry that points to an ETR that
has more mapping
entries.
3) Put all mapping entries from the Internet into the site ITR.
DNS does 1), CEF does 3), and 2) is done by doing a hybrid. We can
swing on this pendulum based on traffic patterns. But here are the
disadvantages of each:
1) Data-plane induced requests cause population. So latency is
incurred. But latency
is only for the first destination site request.
2) Stretch is increased to not require all ITRs must have a full
table.
3) Requires lots of memory to store all mappings so latency can be
eliminated. Solving
this in one in scalable way will help scale xTRs in 2).
So choose your poison, you have to make a hard decision. So we
start with caching and if the cache gets as large as full table,
then we have moved the pendulum full swing.
Or.... you cache in some locations, where the working set is small
and you can afford latency (which, as we've discussed many times,
can be further eliminated by piggybacking the mapping request with
the DNS request) and you have other locations that get a partial or
full feed. [Sean Doran will note that this is Yet Another Problem
That Was Already Solved Once For NNTP.]
As you know, all the LISP mapping database mechanisms touches on all
tradeoffs. We know how to do it each way, what's left is
experimentation and a decision to pick one, or blend two.
LISP 2.0 is this design but many objected to having routing depend on
directory when directory needed to depend on routing.
The nice thing about this approach is that you make this "hard
decision" on a per-box basis, so that you don't have to make one
decision for the entire 'net. Ya pays your money and you get
service proportional to the money that you put in...
We can do that with a blend of LISP-ALT and NERD. Or LISP-ALT in the
core with ITRs having a default mapping (so it's the default-mapper
approach).
We presented this at the last two RRGs.
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
