Re: issue #16

This issue is by the way related to #17, where we decided
that we do not assume all pairs of addresses have connectivity.
I believe the difference between #17 and #16 is that #17
talks about the connectivity upon an address change; #16
talks about whether we test/react if a currently used
path goes broken in a silent way.

I think what you say below is pretty much correct. I would
add that we really have logically two separate tests:

   (1) The one that we use when we search for a new path; I
       feel that MOBIKE needs to define this although there
       was some discussion about whether we should wait for
       some other WG to develop it for us. But this is in the
       domain of issue #17 more than for #16.

   (2) The one that we use to test that the path is still
       alive. This we already have in IKEv2, its called
       DPD. Or do you see why DPD could not be used?

And yes, we there seemed to be agreement in DC that the
path choice decisions of MOBIKE are influenced by multiple
sources, such as what DHCP/DNA/ND/L2 tell us, as well as
what DPD tells us.

--Jari

Tschofenig Hannes wrote:
> hi all, 
> 
> i guess we can close issue # 16:  
> "Can the protocol recover from situations where the only sign of problems is
> lack of packets from the other end?"
> http://www.vpnc.org/ietf-mobike/issue16.txt
> 
> as a conclusion of the discussions we said:
> 
> - mobike defines a mechanism to test connectivity along paths. 
> - both peers might use input from other sources to detect a failure (e.g., a
> local link failure)
> - based on this information mobike might decide to switch to a new address
> (if available).