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.
BrianP.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 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