[RAM] Detecting multihoming failures

[Robin Whittle <rw at firstpr.com.au>]

In "Re: the separation of ID/RLOC" Noel Chiappa wrote, in part:

> . . . because in the push model, when the binding from
> identifier (in the sense 'location-independent name') I to
> locator (in the sense 'location-dependent name') L changes from
> L1 to L2, that knowledge starts near L1/L2 and has to propagate
> across the network.

I imagine that for multihoming, there needs to be a detection
system implemented well away from either L1 or L2, ideally as some
kind of distributed system with no single point of failure.  That
system would probably be a commercial service, and the end-user
would pay them and give them the credentials to alter the mapping
of their IP address or prefix in the LISP or Ivip system
automatically as soon as the system detected something was amiss.

> Now, you do have an interesting question on the
> cache-invalidation issue; do you depend on an explicit
> detection-update mechanism (i.e. distant box D sends packet to
> I, arrives at L1, I is no longer there, L1 sends an error
> message to D with L2, and D updates its cache), . . .

Assuming the D detector system is monitoring how well the
end-user's host or router can be reached via the ETR at L1, D
can't rely on that ETR to report every source of trouble, because
perhaps that ETR at L1 will die or become unreachable.

I think D needs to be well outside whatever provider networks or
AS-end-user edge networks the ETRs L1 or L2 are located in, so it
can detect if those networks become unreachable.

There is a SHIM6 failure detection I-D:

http://tools.ietf.org/html/draft-ietf-shim6-failure-detection

but that is where there is a remote correspondent host on the
scene.  A remote multihoming failure detection and mapping
changing system for LISP or Ivip would be independent of all
corresponding hosts etc.


Regarding "cache-invalidation", perhaps this is similar to what I
call "Notification".  I discuss that in a recent message "1 Ivip
ITR strategies, including in the host" and in a message I will
send soon.


 - Robin      http://www.firstpr.com.au/ip/ivip/


_______________________________________________
RAM mailing list
RAM at iab.org
https://www1.ietf.org/mailman/listinfo/ram