Subject: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support

From: "dmm issue tracker" <[email-masked]>
Date: Tue, 19 May 2015 17:43:11 -0000

#49: full on-demand mobility support

 The three proposed flags express a “type” of source IP address an
 application wants to get to the IP stack. Particularly, the sustained IP
 address is proposed to provide on-demand IP session continuity, which
 activates IP mobility once the terminal moves across other access network.
 While the terminal stays at the same network where the session is
 initiated, regular IP routing is applied.

 The on-demand draft does not assure provide the full on-demand mobility
 for all scenarios by merely indicating the Socket API,
 IPV6_REQ_SUSTAINED_IP. An example scenario raising the aforementioned
 issue is as follows;

 0. The MN is configured with one or more Nomadic IP addresses.

 1. Once an app. requests “sustained IP address” to the IP stack, and it
 will obtain a sustained IP address through a protocol procedure between
 the terminal and network.

 2. Other app. initiated over the same access network will use the same
 sustained IP address while the terminal remains connected at the same
 access network.

 3. The terminal moves to another access network and a new app. requests a
 sustained IP address with the Socket API to the IP stack. Since a
 sustained IP address is already available in the IP stack, the sustained
 IP address is assigned to the new app.

 Besides, in case sustained IP address allocation is used default, there
 may be multiple sustained IP addresses including newly obtained sustained
 IP address over the new access network in the IP stack. However, when an
 app. is initiated, the IP stack may not select the new one in the context
 of the default source IP address selection mechanism [RFC6724][RFC5014].

 For providing the full on-demand mobility, a new flag is needed, letting
 the IP stack request a new sustained IP address or choose a sustained IP
 address not requiring IP mobility anchoring when an application is
 initiated, among the existing ones in the IP stack.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-dmm-ondemand-
  [email-masked]      |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  critical     |  Milestone:
Component:  ondemand-    |    Version:
  mobility               |   Keywords:  on-demand mobility
 Severity:  Submitted    |
  WG Document            |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dmm/trac/ticket/49>
dmm <http://tools.ietf.org/dmm/>

---

From: "Seil Jeon" <[email-masked]>
Date: Wed, 20 May 2015 09:43:00 +0100

Hi DMM folks,

Yesterday, I created a ticket on the on-demand mobility issue. I believe this is critical to be essentially implemented in the on-demand WG draft.
We can start a discussion based on the raised description.

Best Regards,
Seil Jeon 

-----Original Message-----
From: dmm issue tracker [mailto:[email-masked]] 
Sent: Tuesday, May 19, 2015 6:43 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [dmm] #49 (ondemand-mobility): full on-demand mobility support

 The three proposed flags express a “type” of source IP address an  application wants to get to the IP stack. Particularly, the sustained IP  address is proposed to provide on-demand IP session continuity, which  activates IP mobility once the terminal moves across other access network.
 While the terminal stays at the same network where the session is  initiated, regular IP routing is applied.

 The on-demand draft does not assure provide the full on-demand mobility  for all scenarios by merely indicating the Socket API,  IPV6_REQ_SUSTAINED_IP. An example scenario raising the aforementioned  issue is as follows;

 1. Once an app. requests “sustained IP address” to the IP stack, and it  will obtain a sustained IP address through a protocol procedure between  the terminal and network.

 2. Other app. initiated over the same access network will use the same  sustained IP address while the terminal remains connected at the same  access network.

 3. The terminal moves to another access network and a new app. requests a  sustained IP address with the Socket API to the IP stack. Since a  sustained IP address is already available in the IP stack, the sustained  IP address is assigned to the new app.

 Besides, in case sustained IP address allocation is used default, there  may be multiple sustained IP addresses including newly obtained sustained  IP address over the new access network in the IP stack. However, when an  app. is initiated, the IP stack may not select the new one in the context  of the default source IP address selection mechanism [RFC6724][RFC5014].

 For providing the full on-demand mobility, a new flag is needed, letting  the IP stack request a new sustained IP address or choose a sustained IP  address not requiring IP mobility anchoring when an application is  initiated, among the existing ones in the IP stack.

-- 
-------------------------+----------------------------------------------
-------------------------+---
 Reporter:               |      Owner:  draft-ietf-dmm-ondemand-
  [email-masked]      |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  critical     |  Milestone:
Component:  ondemand-    |    Version:
  mobility               |   Keywords:  on-demand mobility
 Severity:  Submitted    |
  WG Document            |
-------------------------+----------------------------------------------
-------------------------+---

---

From: Alper Yegin <[email-masked]>
Date: Fri, 22 May 2015 13:08:16 +0300

Hi Seil,

Thanks for creating the ticket.

Please see below.

> 3. The terminal moves to another access network and a new app. requests a  sustained IP address with the Socket API to the IP stack. Since a  sustained IP address is already available in the IP sta…

Yes, that's what happens.
You are not pointing to an issue up until this point, right? Because, you continuing your email with a "Besides" gives the impression that you are pointing to an issue, but I don't see any issue captured in the above text.

> Besides, in case sustained IP address allocation is used default, there  may be multiple sustained IP addresses including newly obtained sustained  IP address over the new access network in the IP…

OK, is the issue following: When there are multiple sustained IP addresses, how does the IP stack pick one among them?

> For providing the full on-demand mobility, a new flag is needed, letting  the IP stack request a new sustained IP address or choose a sustained IP  address not requiring IP mobility anchoring when…

Your flag is not a solution to what I captured above. It does something else: Instruct the IP stack to go get a new sustained IP address whether there is already one or more configured on the stack or not.

Alper

> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm

---

From: "Seil Jeon" <[email-masked]>
Date: Fri, 22 May 2015 12:26:53 +0100

Hi Alper,

Thanks for your reply.
Please see inline ">>".

Regards,
Seil Jeon

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]] 
Sent: Friday, May 22, 2015 11:08 AM
To: Seil Jeon
Cc: [email-masked]
Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility
support

Hi Seil,

Please see below.

> The three proposed flags express a "type" of source IP address an
for all scenarios by merely indicating the Socket API,
IPV6_REQ_SUSTAINED_IP. An example scenario raising the aforementioned  issue
is as follows;
> 1. Once an app. requests "sustained IP address" to the IP stack, and it
will obtain a sustained IP address through a protocol procedure between  the
terminal and network.
> 3. The terminal moves to another access network and a new app. requests a
sustained IP address with the Socket API to the IP stack. Since a  sustained
IP address is already available in the IP stack, the sustained  IP address
is assigned to the new app.

Yes, that's what happens.
You are not pointing to an issue up until this point, right? Because, you
continuing your email with a "Besides" gives the impression that you are
pointing to an issue, but I don't see any issue captured in the above text.

>> There is an issue. Maybe, we need to be synchronized how have you thought
and defined the meaning of "on-demand mobility". As far as I know, there are
two meanings; one is that by imposing capability among IP address
reachability and IP session continuity, needed for an application, into a
source IP address, on-demand mobility could be achieved; as the other
meaning, it can be rephrased and detailed with dynamic mobility, which
should be applied in the use of sustained IP address. A new application
needs to have non-anchored sustained IP address. This is our consistent
claim. Non-optimal routing issue has been raised in DMM Requirement document
in RFC 7333, which should be critically considered in the solutions.

OK, is the issue following: When there are multiple sustained IP addresses,
how does the IP stack pick one among them?

>> As mentioned and specified in our draft
http://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-00, if
there is no additional preference, we can leave selection to the default
source address selection mechanism. BUT if we have specific preference among
multiple sustained IP addresses and an initiated application wants to have
non-anchored sustained IP address over currently attached access network,
the proposed flag is essential.

Your flag is not a solution to what I captured above. It does something
else: Instruct the IP stack to go get a new sustained IP address whether
there is already one or more configured on the stack or not.

>> Answered in the above. 

Alper

---

From: FIGUEIREDO Sergio <[email-masked]>
Date: Fri, 22 May 2015 15:24:47 +0000

Hi Alper,

As Seil wrote, the problem which this ticket intends to reflect is that of non-optimal routing as a result of not being able to request a non-anchored (or local) source IP address. 
This might be a problem in any scenario where new Sustained IP addresses are not assigned by default at the new network. The intention of the flag is not to request a new prefix, but to assure a source address associated to a local network is used. Which, in cases where it is not available, leads to the configuration of a new one.

Best regards,
Sergio

2, rue Paul Vaillant-Couturier
92300 Levallois-Perret 
FRANCE
Tel. : +33 (0)1 46 17 46 17
-----Original Message-----
From: dmm [mailto:[email-masked]] On Behalf Of Alper Yegin
Sent: sexta-feira, 22 de Maio de 2015 12:08
To: Seil Jeon
Cc: [email-masked]
Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support

Hi Seil,

Please see below.

> The three proposed flags express a "type" of source IP address an  application wants to get to the IP stack. Particularly, the sustained IP  address is proposed to provide on-demand IP session continuity, which  activates IP mobility once the terminal moves across other access network.
> 1. Once an app. requests "sustained IP address" to the IP stack, and it  will obtain a sustained IP address through a protocol procedure between  the terminal and network.
> 

Alper

---

From: Alper Yegin <[email-masked]>
Date: Fri, 29 May 2015 23:41:53 +0300

Hello Seil,

> in RFC 7333, which should be critically considered in the solutions.

Sorry, I don't understand what you meant here.

> how does the IP stack pick one among them? (*)
> 

I think you are meaning the same thing as I said above (*).
Do you agree?

> there is already one or more configured on the stack or not. (**)
> 
>>> Answered in the above. 
> 

There's a discrepancy between (*) and your solution (**).

Are we talking about (*), (**), or something else?

Alper

---

From: Alper Yegin <[email-masked]>
Date: Fri, 29 May 2015 23:44:22 +0300

Hello Sergio,

> As Seil wrote, the problem which this ticket intends to reflect is that of non-optimal routing as a result of not being able to request a non-anchored (or local) source IP address. 

A non-anchored (local) address is called Nomadic IP Address.
If the app needs one such address, then it can ask one and get one. 
API already supports that.

Alper

---

From: FIGUEIREDO Sergio <[email-masked]>
Date: Fri, 29 May 2015 21:34:59 +0000

Hi Alper,

Thanks for the answer. Please check inline.

On 29-05-2015 22:44, Alper Yegin wrote:

Hello Sergio,

Hi Alper,

Alper

Best regards,
Sergio

-----Original Message-----
From: dmm [mailto:[email-masked]] On Behalf Of Alper Yegin
Sent: sexta-feira, 22 de Maio de 2015 12:08
To: Seil Jeon
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support

Hi Seil,

Please see below.

Alper

[email-masked]<mailto:[email-masked]>      |  [email-masked]<mailto:[email-masked]>

Ticket URL: <http://trac.tools.ietf.org/wg/dmm/trac/ticket/49><http://trac.tools.ietf.org/wg/dmm/trac/ticket/49>
dmm <http://tools.ietf.org/dmm/><http://tools.ietf.org/dmm/>

_______________________________________________
dmm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________
dmm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dmm

---

From: FIGUEIREDO Sergio <[email-masked]>
Date: Fri, 29 May 2015 21:41:36 +0000

I'm sorry but I had problems sending the previous message. Hope I succeed this time, my response is inline.

________________________________
De: dmm [[email-masked]] em nome de FIGUEIREDO Sergio [[email-masked]]
Enviado: sexta-feira, 29 de maio de 2015 23:34
Para: Alper Yegin
Cc: [email-masked]
Assunto: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support

Hi Alper,

Hello Sergio,

Hi Alper,

SF: You are right. But I didn't mean a Nomadic IP address, but a Sustained IP address assigned by the current network. So, a description closer to what I meant would be:

"...this ticket intends to reflect is that of non-optimal routing as a result of not being able to request a Sustained IP address assigned by the local network".

Best regards,
Sérgio

Alper

Best regards,
Sergio

-----Original Message-----
From: dmm [mailto:[email-masked]] On Behalf Of Alper Yegin
Sent: sexta-feira, 22 de Maio de 2015 12:08
To: Seil Jeon
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [DMM] [dmm] #49 (ondemand-mobility): full on-demand mobility support

Hi Seil,

Please see below.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Sat, 30 May 2015 13:18:00 +0300

Sergio,

> "...this ticket intends to reflect is that of non-optimal routing as a result of not being able to request a Sustained IP address assigned by the local network".

OK, this I understand! 
But I understood this not from the ticket text but from the solution.
Hence I've been extremely suffering trying to connect the solution back to the ticket definition :-(

OK, if Seil also agrees with this, I hope you guys go back and clean up the ticket, so everyone can understand this the same way.
Meanwhile, we can seek input from the WG members on the "issue" first (and then the solution).

Alper