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

Hello Seil,

> 
>> 
>> #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.
>> 
> 
> 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.
> 

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

>> 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].
>> 
> 
> 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.
> 

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



>> 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.
>> 
> 
> 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. 
> 

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

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

Alper





> Alper
> 
> 
> 
>> -- 
>> -------------------------+----------------------------------------------
>> -------------------------+---
>> Reporter:               |      Owner:  draft-ietf-dmm-ondemand-
>> [email protected]      |  [email protected]
>>    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/>
>> 
>> 
>> _______________________________________________
>> dmm mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/dmm
> 
>