Re: New issue 16: No packets from other end?

hi Jari,

I dont agree with your conclusions. more below.

Jari Arkko wrote:

> Vijay Devarapalli wrote:
> 
>> I am not sure how you can do that. what if the application
>> prefers "failing" to using an expensive link?
>>
>> for example, lets assume my mobile device has a low bandwidth
>> GPRS link (address IP1 on that link) and a high bandwidth WLAN
>> link (address IP2 on that link). I have set it up so that my
>> email is downloaded only when I connect to my Enterprise
>> through a VPN connection when I have the WLAN link. if the
>> WLAN link is not available, I dont want the email client to
>> download email. lets assume I am in the middle of downloading
>> email. I lose WLAN coverage. with your proposal, the MOBIKE
>> protocol switches to using IP1. I dont want that.
> 
> 
> I agree with your scenario.
> 
>> IMHO, I prefer "something in the Mobile Node" telling MOBIKE,
>> "switch to using this address with this VPN GW". then a MOBIKE
>> update should be sent. this is the model I had in my mind.
>>
>> for "something in the Mobile Node" I had assumed DNA, MIP6,
>> Multi6, new address configuration, default router change, etc...
> 
> 
> I believe there's two levels of issue involved here. On
> the first level, I think we have consensus that "something
> in the mobile node" should be able to tell MOBIKE that
> there's a new address or that a particular interface and
> its addresses are no longer usable because the router went
> down. I also think that we have consensus that at least most
> of this is outside MOBIKE protocol and WG scope. They are
> better handled in IPv6/DNA/DHC/MIP6 WGs. Finally, I believe
> your policy issue about which interface should be used
> is also at this level. And like I said, I agree with your
> requirement that it should be possible to express such
> policies. I think the others will agree too.
> 
> However, that's the part that the rest of the stack is
> telling MOBIKE. The second level is what happens after
> MOBIKE has been told something. For instance, lets say
> that it has been told that there's two usable addresses
> at this end and one at the other end; that's two possible
> address pairs. Now we get a problem -- ESP tells IKE
> that there's no packets, IKE attempts DPD which fails.
> There's no information coming from IPv6/DNA/DHC/MIP6
> (and presumably there will not be any information coming
> soon either, because the DPD process took a while).

I dont agree with this statement. IMHO, if IPv6/DNA/DHC/MIP6 are
not able to figure out what happened, MOBIKE should just keep quiet.

> Now what? Are people saying that
> 
>   (1) Its okay for the MOBIKE peers to attempt recovery
>       at the MOBIKE level by switching to another address
>       pair.
> 
>   (2) Its not okay. MOBIKE/IKEv2/IPsec should fail and
>       wait for the rest of the stack to inform when there's
>       again an operational address.

I think (2) is the way to go. I dont want MOBIKE making a
decision that conflicts with IPv6/DNA/DHC/MIP6/SCTP/whatever.

Vijay

> 
>       If problems on the path need to be handled, this would
>       imply the development of a new, separate protocol for
>       testing paths. Note that ICMP/TCP/app may already have
>       told us of a problem with the current communications just
>       as DPD did. But what we need is finding _another_ pair
>       that works. No protocol that I know does that right now.
>       Most of what we have in IPv6/DNA etc is focused on local
>       issues, such as availability of the router.
> 
> (Assuming the "first level" is handled as explained earlier --
> outside MOBIKE -- my personal preference would be #1.)
> 
> --Jari