Re: [RRG] thoughts on the design space 3: caching

[Dino Farinacci <dino@cisco.com>]

> One of the conclusions that I drew from our exercise was that  
> caching mapping resolution is the culprit for many of the issues.  
> Deterministic packet delay/drop, for instance. And the source of  
> most of the complexity. Can we rethink some of the solutions in this  
> light?
>
> It seems that we have bundled the design of our encapsulation and  
> mapping protocols with the way routers arrange their forwarding cache.
>
> First, I am not at all convinced that we actually HAVE to employ a  
> cache for the forwarding lookup. The designs such as LISP are based  
> on the idea that a subset of routers has to do more work than most  
> routers in the Internet. This may be all that is needed; build those  
> routers with the capability to have a full table. The rest of the  
> routers will only need minimal amount of memory. If you believe  
> this, then something like LISP + NERD would be far simpler and  
> efficient than the other alternatives.

As you might now, LISP can work with a cache or a table. We have shown  
that with the various mapping proposals that have been documented.

> Hasn't the industry built caching routers before, and what happened  
> to them? Think we need a second try? I have not seen any ideas on  
> how to remove the problems inherent with the caches, such as  
> vulnerability to being hit by random destination addresses.

The BGP data indicates that out of 250K stored routes, most routers  
use only 25K of those routes. So isn't that a bit of wasted memory as  
well as come-up convergence time?

> Second, even if you believe that we DO need a cache, there's really  
> no reason why the cache design has to be cast into the rest of the  
> architecture. Even if your forwarding ASIC can't employ enough  
> memory for all the entries, I have a hard time convincing myself  
> that we can't have a general purpose computer sitting next to it  
> that holds the full table. I'm writing this on a laptop that has a  
> 160G disk. That would be enough for several mapping tables  
> containing EVERY IPV4 ADDRESS.

That is correct. The capacity is not the issue. It's getting the data  
there and updating it when it changes.

> Third, if you believe we must use an alternate topology for routing  
> the initial packets while we are fetching for the cache entry, is  
> that alternate topology a global infrastructure or a local device?  
> Again, I have hard time getting myself convinced that we

What do you mean?

> need to build a global infrastructure. The cost of the  
> infrastructure is immense, and if you use the current BGP  
> infrastructure you end up keeping there precisely the information  
> that you wanted to get rid of. My take is that if you cannot build  
> an ITR/ETR that holds the entire mapping table in memory, maybe it  
> would be better to attach it to a general purpose computer that can  
> (slowly) handle the cache misses and hand the packets back to the  
> router.

LISP can do both Jari. It's not wedded to one way or the other.

Dino

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


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