Subject: RE: [Mobike] New issue 16: No packets from other end?

From: <[email-masked]>
Date: Mon, 16 Aug 2004 14:38:14 +0300

Hi Atul,

The other end could be a mobile host or SGW, depending 
on your point of view.

The issue is what to do if we have not received a "link 
down" signal from layer 2 (or somewhere), but we don't 
get any responses (to IKEv2 requests) from the other end 
either. In this situation,  should we just close the 
connection, or "somehow" trigger MOBIKE to change to 
some other address(es)? 

(Some details of the "somehow" part will be beyond 
the scope of the MOBIKE specification, but probably  
something needs to be said to ensure interoperability.)

Best regards,
Pasi

> -----Original Message-----
> From: [email-masked]
> Sent: Friday, August 13, 2004 5:40 PM
> To: Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]
> Subject: RE: [Mobike] New issue 16: No packets from other end?
> 
> I needed some clarifications from MOBIKE veterans, before 
> expressing an opinion:
> 
> What is the "other end" here? The mobile host? or the 
> multihoming SGW?
> 
> Who initiates the MOBIKE protocol? I would guess:
>    (1) a mobile host after the move, needs to notify the 
>        remote SGW of its new address.
>    (2) a multihoming SGW, upon detecting that one of its 
>        interfaces (which was used to contact the mobile host)
>        is down and it needs to notify the mobile host of its
>        new interface address to be used.
> 
> Are there any other scenarios of how MOBIKE can be initiated? 
> When would we use the information that there is "lack of packets 
> from the other end", to initiate the MOBIKE protocol?
> 
> Thanks,
> Atul
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]]On
> > Behalf Of ext 
> > Sent: Thursday, August 12, 2004 9:01 AM
> > To: [email-masked]
> > Subject: [Mobike] New issue 16: No packets from other end?
> > 
> > 
> > I've created a new issue in the issue list:
> > 
> >    "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/issues.html)
> > 
> > Many people at the WG meeting expressed opinions that this 
> > should be handled somehow (in addition to handling e.g. 
> > link-down triggers from layer 2, or something similar).
> > 
> > So far, I do not remember anyone saying that the protocol
> > does not need to handle this situation. But comments
> > are welcome.
> > 
> > Best regards,
> > Pasi
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: <[email-masked]>
Date: Mon, 16 Aug 2004 08:33:18 -0400

Thanks Passi,

....for the explanation. I think in that case you are trying
to solve network failure recovery inside the MOBIKE protocol.

I think Francis and someone else on the list commented such
functionality should probably be outside the MOBIKE protocol
specification.

MOBIKE's mandate, in my opinion, is to notify the "other end"
of the change in address or plurality of addresses due to 
mobility or multihoming using IKE mechanism (information 
exchange). Trying to solve a general problem within MOBIKE,
may complicate MOBIKE protocol unnecessarily. Network failure
recovery (without notifications) should be solved elsewhere
IMHO.

Best,
Atul

> From: Eronen Pasi (Nokia-NRC/Helsinki) 
> Sent: Monday, August 16, 2004 7:38 AM
> To: Sharma Atul (Nokia-ES/Boston); [email-masked]

---

From: <[email-masked]>
Date: Mon, 16 Aug 2004 08:50:35 -0400

Thanks Francis,

....for the answers. It does clarify the questions raised in
the original mail. I had some follow up comments/doubts, though:

Plurality of addresses can be communicated statically, but change
of address(es) need to be communicated dynamically, unless the
change is to a predetermined address(es) only.

In the dynamic scenario, a mobile host detecting a move or
a multihomed SGW detecting a network interface failure shall
notify the other end of the change. Are there any other "dynamic"
scenarios?

In the static or predetermined case, the end aware of the change
is required to notify the change to the other end? Or it is not
mandatory and the other end will try different prior known addresses?
We have to be clear in specifying what is a MUST and what is an option,
to guarantee interoperability. Do we have that already in the protocol?

Best,
Atul

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Sunday, August 15, 2004 2:25 PM
> To: Sharma Atul (Nokia-ES/Boston)
> Cc: Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]
> Subject: Re: [Mobike] New issue 16: No packets from other end? 
> 
> 
>  In your previous mail you wrote:
> 
> expressing 
>    an opinion:
>    What is the "other end" here?
> 
> => you are at one side, the other end is the other.
> 
>    The mobile host? or the multihoming SGW?
> 
> => you are narrowing the scope of MOBIKE without good reasons.
> MOBIKE supports one or both ends mobile and/or multi-homed.
>    
>    	(2) a multihoming SGW, upon detecting that one of its interfaces
>    	    (which was used to contact the mobile host) is down 
> and it needs 
>    	    to notify the mobile host of its new interface 
> address to be used.
>    
> => many, for instance two multi-homed hosts, two multi-homed SGWs,
> a mobile SGW, a multi-homed host, etc.
> 
>    When would
>    we use the information that there is "lack of packets from 
> the other end",
>    to initiate the MOBIKE protocol?
>    
> => IMHO this is not in the scope of the MOBIKE protocol so I 
> can't give
> an answer. But if this end knows alternate peer addresses of 
> the other end,
> obviously to try them seems a good idea...
> 
> Regards
> 
> [email-masked]
>

---

From: <[email-masked]>
Date: Mon, 16 Aug 2004 16:41:53 +0300

Hi Atul,

My impression was that the main reason we are adding 
multihoming support to IKEv2 is to recover from failures 
(since load balancing is explicitly beyond the scope). 

I think that restricting ourselves to those network failures 
where we get an explicit "link down" signal will seriously 
limit the usefulness of the protocol's multihoming features.
(For instance, the multihoming features of SCTP don't
have that kind of restriction.)

Best regards,
Pasi

> From: [email-masked]
> Sent: Monday, August 16, 2004 3:33 PM