[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. :-) :-)
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?
If I think of something along those lines, I'll share. :-)
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"?
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...
Brian
--
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