Subject: Re: [lisp] ETR connectivity to site - question on EID reachability (section 6.4)

From: [email-masked] (Noel Chiappa)
Date: Mon, 23 May 2011 12:29:05 -0400 (EDT)

> From: Yakov Rekhter <[email-masked]>

    > the ITRs that are communicating with that site via that ETR need to find
    > out that the ETR lost connectivity to that site.

Another mechanism to do this, one which has not been mentioned so far, is to
use the mapping versioning mechanism. I'm not sure if this is the way to go (in
some sense, I think the concept there was to use that for more permanent
changes, i.e. changes in configuration) but it might be.

    > Another solution proposed in the above is for the ETR to clear its
    > locator-status-bit in the encapsulation data header. But it applies only
    > when the ETR is also an ITR for the traffic going in the opposite
    > direction

If an ETR can no longer reach some of the EIDs it has claimed to be able to
reach, and some entity is trying to use it to send traffic to those EIDs, it
needs to communicate that _as soon as possible_ to those entities. The ETR
should notify the ITR which sent it that traffic ASAP, and not wait for some
other unrelated (and possibly long delayed) event (e.g. user traffic back to
the source ITR) to provide an opportunity to do so.

Depending on the exact failure mode (e.g. 'the ETR is still configured for
those EIDS but connectivity is gone' versus 'configuration has changed and the
ETR is no longer appropriate for that EID') the exact form of the notification
will change - an unsolicited LISP packet with the appropriate LSB bit cleared
for the former, a unsolicited Map-Reply in the latter, etc, etc.

	Noel