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

[Tony Li <tli@cisco.com>]

> I don't believe the 80% number.


Fine.  Call me a liar.  No more donuts for you.


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


Hello...  that's not a related point.

DNS resolvers don't have a working set that's 80% of all possible  
domain names.  Browsers don't have a working set that's 80% of all  
web pages.

A mapping cache is a fine and tractable object IF AND ONLY IF the  
working set at that location is tractable.


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


I don't fall into "you guys" because a) I'm in favor of caches in  
some places and b) I'm against them in others.  I haven't noticed  
that opinion expressed by anyone else yet.  Yes, that's something of  
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.


No, what I saw was a total mess of mechanisms, with no coherency.

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