On Wed, Mar 20, 2013 at 1:40 AM, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
Then, how can an ITR, which initially choose a blackholed locator, know that the locator is not working and fall back to another locator?
In general, we should assume protocol used is something unknown to the ITR (not TCP, of course) and/or not assume the ITR is on return path so that the ITR can't have any "knowledge" that an end system receiving any reply.
I can't speak for LISP per se, but the general solution for map-encap systems like LISP is that the ITR tags the first packet to the ETR and some percentage of subsequent packets to the ETR with an ack request. If it doesn't get an ack from the ETR (not the final destination), then the ETR or the path to it is depreferenced. The ack-request tagged tunnel packets and the acks sent in response are protocol-agnostic with respect to the inner packets between the source and destination. If the ETR is unavailable, those carried packets will be dropped. The ITR cares only about promptly discovering that the ETR is unavailable so that it can select an alternate ETR which works. The error correction mechanisms in the carried protocols then take over and resolve the lost packets. The path from the ETR to the destination, and by extension the full path from the ITR to the destination, is not the ITR's responsibility. Some local system is responsible for detecting connectivity between the ETR and destination and updating the destination-to-ETR map accordingly. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004