[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures
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
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.
to unsubscribe send a message to firstname.lastname@example.org 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