Re: Some thoughts about "path failover"

Jari Arkko writes:
> >    - The initiator does a couple of retransmissions over those
> >      paths which don't seem to work.
> 
> Ok, I think. This is to make sure we didn't miss a faster
> path just because one packet was dropped?

What about if the other end only replies to the first packet, i.e. it
does not reply to those retransmissions coming during short time
period, it will simply pick the first and answer to that, and ignore
rest?

> we could also skip CHANGE_YOUR_ADDRESS. What we would
> lose is the ability to do M*N path testing; if both

I do not really think the M*N path testing is needed. If we assume
that we can detect the problems in the local end, then we should be
able to select on of the N ip-addresses. If we also assume that we are
not really trying to fix general routing problems in the core network,
i should be enough to use M*1 test packets, i.e. pick best working
local IP-address for each remote address and send one packet to that
remote end. 

> One case where this might lead to problems is
> a simple one: two GWs connected using two different
> networks. Both GWs use a current address from network
> 1. But then network 1 goes down. Now, there GWs are
> unable to reach each other. This is because both are
> able to use an address from network 2, but they can
> only test it against network 1 address of the peer.

I think this is quite important case, thus I think we want to have
address lists, i.e. so the both ends have knowledge of the all the
ip-addresses of the both ends, thus either end have enough knowledge
to try to fix the problem. 

> Overall conclusion: I think your list looks very good
> and complete. Based on my 2 GW example, I am starting
> to think we need the address lists and not just a single
> address. 

I agree on that. I also think we do need address lists. 

> But perhaps we could have address lists and still fix the path
> testing role for one of the participants only, such as the IKEv2
> initiator.

I also think this should be fine. BTW, original IKEv2 initiator is
better party to do the recovery, as it is most likely going to be the
roaming laptop. Thus it is the party which might move to behind NAT
box, and it is only party which can fix that problem (i.e. move to use
the NAT-T instead).
-- 
[email protected]