ETR failure and its implications on connectivity restoration time (review by Y. Rekhter)

[wmhaddad@…]

In today's routing global BGP convergence is NOT required for connectivity restoration. In other words, IP connectivity
restoration takes less time than what it takes to propagate fault
information throughout the Internet (or for that matter even
throughout a site). With LISP connectivity, restoration requires to
propagate fault all the way to the ITRs. In addition, if one relies
on Loc-Status-Bits to determine that a particular RLOC is down,
connectivity restoration would also require to propagate fault
information from one ITR to another. In some case this may not be
feasible (e.g., ETRs are PEs). And even in the cases where it is
feasible, that is likely to increase connectivity restoration time.

[jmh@…]

Text has been added to the documents on path liveness, including ETR liveness, checking, and responses ITRs can take to failures.

[yakov@…]

The text that has been added on path liveness, etc... does not address the issue raised in this ticket, namely that with LISP connectivity restoration requires to propagate fault information from ETR all the way to ITR. To address the issue raised in this ticket I would propose to add the following to section 6.3:

Restoring connectivity in the presence of faults at ETRs requires propagating
fault information from the ETRs to the ITRs. This is in contrast to the
current IP routing system, where restoring connectivity could be accomplished
with a fairly limited scope of propagating fault information. The implication
of these differences are outside the scope of this document.