routing table go boom

Wed Mar 20 06:16:42 UTC 2013

On Wed, Mar 20, 2013 at 1:40 AM, Masataka Ohta
<mohta at 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 at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004