Re: Some thoughts about "path failover"

[email protected] wrote:
>  
> Hi,
> 
> I was thinking about various multihoming scenarios in MOBIKE, 
> and here are some ideas for starting a discussion...
> 
> First, it seems that there are two kinds of events that might
> cause something to occur:
> 
> 1) Either party notices a change in its own network interfaces
>    For instance, L2 carrier is lost, default router stops 
>    responding to ARP, new link appears, IP address changes, etc.
> 
> 2) There seems to be a problem with the currently used path;
>    e.g. lack of packets, or perhaps an ICMP message.

Yes. And if you view this from the point of view of one
participant, you would get also

   3) An indication from the peer

> In case 1, it's quite clear who should handle the problem. This
> case doesn't even require address lists: the party that notices
> something can simply send an update message saying "my new
> address is X".

Right.

> Case 2 is more complicated, since it does not tell where the
> problem is. Presumably both ends can detect the problem, and
> will eventually do so. But which end should do something about
> it? And if both ends are multihomed, which of the remaining
> paths should be used?

Good questions! There may also be a difference in the reasons
why we get case 2, for instance:

- case 1 is about to happen, but we got the ICMP first
   and will see the L2 event or case 3 indication from the
   peer soon.

- case 1 has happened, but our L2 or L3 is incapable of
   detecting the problem.

- routing problem in the network in between.

These may also require different responses. The right
thing for the first bullet would be to wait, I think.
I don't know what the right response for the other two
bullets is, and I'm not even 100% sure bullet three is in
scope of MOBIKE...

> These two cases seem to also require quite different messages 
> from the protocol. Case 1 is just "my new address is X"
> message: reasonably simple to implement, especially at the
> receiving end.

Yes.

> Case 2 seems to require some kind of address lists, but this

Routing problems might even require address x address pairs.

> might not be enough. For instance, it might make sense to
> distinguish "primary path" (or "primary address") from "current
> path" (that is used for traffic now), since we might want to
> switch back to the primary path when it becomes available again.

Why?

> One option which might simplify case 2 is that the parties
> would agree in the beginning which of them (only one) is 
> responsible for this "path failover" functionality... or
> are there some failure cases I haven't considered?

Yes. Or we could hardcode it in the protocol, say the
IKEv2 initiator handles all path failover problems. (In
addition, we need to decide which of these failover
problems we will solve in MOBIKE.)

--Jari