[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures
My "elephant" wasn't directed at any specific locator/ID proposal in
particular, but is common to them all.
Right, I was commenting solely on your locator reachability comment.
That said, even if the reachability isn't in the database, it *is*
kept/signaled between ITR/ETR tuples. The problem doesn't go away,
it just gets pushed to the ITRs and ETRs.
Right, in the data-plane, with no extra messages other than the data
itself.
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. ;-)
Things like black holes, routing loops, frame/packet smashing,
errored links, etc., can cause data loss in one direction, without
the ITR knowing or the ETR seeing the encapsulated packets.
This is acknowledge in the comment about there being a dependency on
Host Unreachable ICMP messages, but that looks like a bit of an
Achile's Heel.
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?
Does the routing system today fix block holes, routing loops, etc...
or do they contribute to it?
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