Dino Farinacci wrote:
The "elephant in the room":
While LISP et al appear to solve some problems, when you look at it
just the right way, the real problem is - how do you multihome, and
detect, handle, and respond to failures on one of many paths
available (i.e. "route around" the outage), in a scalable fashion?
In BGP with PI, i.e. using BGP for multihoming, the state is carried
via BGP.
In LISP, the presumption is that the mapping stuff handles the state
- but does that differ much from the BGP solution, other than moving
the problem somewhere else? The state is still needed, and needs to
be propogated in a timely fashion.
Locator reachability and routing around failures is not in the mapping
database. Please read draft-farinacci-lisp-05.txt section 6.3 for the
locator reachability mechanism.
Hi, Dino,
My "elephant" wasn't directed at any specific locator/ID proposal in
particular, but is common to them all.
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.
Brian
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...)
P.P.S. And not to harp on this, but the absence of active reachability
awareness on the ITR/ETR nodes, other than for the immediate local info
(default and CE/PE stuff), means lots of failure modes on the selected
RLOC path take longer to notice, or even can't be detected or handled.
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.
--
to unsubscribe send a message to [EMAIL PROTECTED] 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
