Re: issue 4: how to signal support for MOBIKE

Tarique Mustafa wrote:

> However, just a question or "food for some more thought", here is a 
> scenario:
>  
> 1) Client Peer establishes a Mobike Session with Remote Peer (or server)
> 2) Client Peer moves to a new access point and due to change in the IP 
> address, re-registers with the Remote Peer (or server) - session type 
> now however (for ANY reason) is not to be Mobike Session any more :- It 
> could be anything let's say a simple IKEv1/IKEv2 session
> 3) Client Peer moves again causing the IP address change again, 
> re-registers with Remote Peer (or server) again - BUT the session type 
> now "for some reason can and should be" a Mobike Session
>  
> How will this scenario be supported with the existing recommendtions in 
> Mobike?
> Will Notification vs. Vendor ID approach have any positive or negative 
> impact in the afore mentioned scenario?

I don't think this particular choice has an effect to your
scenario.

As far as your scenario goes, switching on and off support for
some feature (such as MOBIKE) probably does have some ill effects.
In this particular case Step 2 may cause the earlier session to
be thrown away, so you have to re-establish everything.

But the interesting case is Step 3. The question is *when* do
you signal support for MOBIKE? If you did not signal it earlier,
can you switch in mid-session? I believe the answer for that
should be that you can send the notification at any time. But
the notification turns MOBIKE support on -- I don't think we
need a notification to turn it off.

--Jari