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.
So, one could also add something on top of the data-plane mechanism, but we strongly hesitate. Want to scale or want to solve every reachability problem?Ideally, both. :-)I'm not saying for sure it's possible, but it would be a laudable goal, yes?
We chose to start with something simple rather than put a lot of mechanism in up front.
If there is a solution-space which would work equally well for IPv4 and IPv6, but which would only be really feasible (for address consideration reasons) in IPv6, would that be "good enough"?
Well, the LISP proposal thinks we can.
Does the routing system today fix block holes, routing loops, etc... or do they contribute to it?If an RLOC prefix is withdrawn from the DFZ, it would be better if the xTRs knew that rather than relying on ICMP. I'm just saying...
Sure, but there is aggregation, so you can't depend on it. That is, you can't depend on a lot of mechanism that is in the net. That is the hard part, that is the reasons we all need to make hard decisions, then just throwing more mechanism. Each new mechanism you add will add issues and barrier to deployment.
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