Hi Dave, I have replied to part of your message in another thread on LISP-ALT scaling. "Level 1" means an ALT router at the lowest level of the highly aggregated inverted tree ALT hierarchy.
You wrote, in part: >> How can an ALT router, such as this busy level 1 >> aggregation router, detect the failure or >> unreachability of a Map-Server? I guess it would >> find out when it tries to send a Map-Request message >> to the Map-Server via the GRE tunnel. But is there >> a keepalive arrangement so the level 1 router could >> detect the disappearance of this Map-Server before >> it sends a Map-Request? >> >> More on potential problems with caching Map-Resolvers. > > > Regarding "upness": You can make the same argument for > BGP peers in the DFZ (or DNS if you like). In the case of > BGP, we use BGP keepalives, BFD (if you like), and the > existence of the route in the RIB/FIB as basically a > bunch of heuristics, which work pretty well (when was the > last time you couldn't get to Google because of a routing > problem on the Internet?). Hence we don't need to > calculate some exact value of "upness" (which is a good thing). > > BTW, the question "is entity X up" really reduces to > Zeno's paradox (think: what is the granularity of > "upness", and how often do I need to ask?). And we know > what it took to solve Zeno's paradox. But as mentioned > above, we can do a fine job (within our engineering > constraints) with clever heuristics. The operational > Internet is pretty much an existence proof of that. Your answer is pretty general and doesn't seem to apply to the specific situation of the Map-Server and ETR. Can you be more specific about how you would handle this? I understand that routers with physical connections can often use the physical layer to detect a failure of the link - and perhaps the failure of the router at the other end of the link. A Map-Server is just a host with some IP address which has made an arrangement with an ETR on some other IP address to send it Map-Requests. Leaving aside the lack of acknowledgement in the current Map-Register protocol, how does the Map-Server detect that the ETR is dead? The Map-Request packets are UDP and require no acknowledgement. The replies don't come back through the Map-Server, so it can't tell whether the ETR is alive or not. As far as I can see, you will need some kind of protocol to ensure the Map-Server can quickly and easily detect a failed or unreachable ETR. Then, I think it needs to withdraw the advertisement of that ETR's EIDs into the ALT BGP, according to some LISP-specified or locally determined algorithm about how long the outage has been so far. - Robin _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
