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

[Yakov Rekhter <yakov@juniper.net>]

Dino,

> > Dino Farinacci wrote:
> >>> P.S. Since the ITR/ETR use caches, and reactively populate the  
> >>> caches, IMHO, it's a step backwards, from CEF to pre-CEF bad-old- 
> >>> days. (Sorry. Old wounds still ache from time to time :-). Not so  
> >>> old if you include MSFC's...)
> >>
> >> We are not talking about the same scale. I can sell you a 10  
> >> million entry cache, but you probably won't buy it.  ;-)
> >>
> > MacBook w/2GB running quagga - already have one, thanks. :-) :-)
> 
> We are not talking about the same sort of products either.  ;-) If  
> this needs to go fast, the MacBook memory won't run at 40-100G.

For the purpose of this discussion we need to look separately at
the memory used by the control plane and the memory used by the
data plane. Your arguments that "the MacBook memory won't run at
40-100G" may be relevant in the context of the memory used by the
data plane, but is *totally irrelevant* in the context of the memory
used by the control plane.

The point raised by Brian about "a step backwards, from CEF to
pre-CEF bad-old-days" is an important one. Namely, by what kind
of "magic" all the problems that motivated development of CEF would
disappear in the context of ITR/ETR caches ?  And if they would not
disappear, then why would they be not as important now, as they
have been when CEF was developed ?

Yakov.

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