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.
Yes, agree. That is what I implied since control-plane memory won't have to run at speeds 40-100G.
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
Let me put it another way. Could any box run with a full set of DNS entries for the entire Internet. At some point you have no choice but to go with on-demand caching.
of "magic" all the problems that motivated development of CEF would disappear in the context of ITR/ETR caches ? And if they would not
You don't do packet-time population of the cache like CEF did. In LISP, you do packet-time Map-Requests, but the Replies populate the cache at control-plane time. That is the difference, subtle but important.
Dino -- 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