[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