Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures

[Tony Li <tli@cisco.com>]

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.


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


Which stats are these?  From an enterprise?  Or a core box?


> > Caching is NOT worthwhile when the working set is 80% of the full  
> > table.
>
> I agree with that.


You seem to disagree with it above.


> > > 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?   ;-)


I do remember that.  I also remember who wrote it.  ;-)


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


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

Tony


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