Re: WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

Hi,
Good, see my reply inline (surrounded by >>>>>>>>>>>>) .

Thanks again for investing the time to review the drafts,
	/Danny

-----Original Message-----
From: Behcet Sarikaya [mailto:[email protected]] 
Sent: Wednesday, March 30, 2016 12:12
To: Moses, Danny
Cc: [email protected]
Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

Hi Danny,

I am removing all previous conversation because it all got mixed up.
Let's start afresh.


I read you dhcp draft also.

There is confusion in several levels. Your API draft talks about different applications on a MN needing different types of mobility services. Your DHCPv6 draft seems to give a solution on how a host can get different types of addresses/prefixes from DHCPv6 server, so is it for a host or an application?
Prefix or address is assigned for an interface, that is another well known concept which your draft seem to completely ignore, i.e. a host may have multiple interfaces.
DM>>>>>>>>>>>>>>>>>>>>>>
Yes, I understand were the confusion might arise. The only entity in the host (or - mobile device) which uses DHCP is the DHCP client that is part of the TCP/IP stack. There may be several triggers to cause the DHCP client to request a source IP address:
 - When the mobile node initially attaches to a network.
 - When the mobile node moves to a different location and needs to refresh its source IP address.
The On-Demand concept implies a new trigger:
 - When an application is launched, opens an IP Socket and requires a special type of source IP address which was not already assigned to the mobile node.
So, it is the responsibility of the TCP/IP stack in the mobile node to figure out when it is required to initiate a DHCP transaction to serve the application's needs.

Regarding multiple interface, you are correct once more. A mobile node may have multiple interfaces. When this occurs, the mobile node needs to send at least one DHCP request on each interface and the network assigns the source IP address to the interface from which the DHCP request had arrived. This is not new and the DHCP draft does not mention it because there are no changes or extensions required.
>>>>>>>>>>>>>>>>>>>>>>>>>DM

Another concept is (as I already mentioned) topological correctness.
If MN changes subnet, its previous prefix becomes topologically incorrect. Either it has to get a new prefix or there must be some system support, e.g. host routes.
Of course another case is anchoring, like in 3GPP or in MIP. If you are anchored your prefix does not change.

So you seem to ignore all these and instead introduce three types of addresses among which the sustained IP address/prefix is the key to your solution.

Sustained address/prefix has this magical property:
 the IP address used at the beginning of the session remains usable despite the movement of the mobile host.

and then you say

access network anchoring, corresponding network anchoring, or some
   other solution
can provide sustained address/prefixes.
what does corresponding network anchoring mean?

DM>>>>>>>>>>>>>>>>>>
Corresponding network is a concept from Alper Yegin's draft - https://datatracker.ietf.org/doc/draft-yegin-dmm-cnet-homing/. It defines the concept of having the mobility anchor in the network of the mobile node's corresponding node, rather than in the access network. It is an interesting concept with its advantages (and disadvantages...).
>>>>>>>>>>>>>>>>>>>DM

I have a feeling that what your drafts are saying that right now we don't know but we anticipate in the future some ways will be found to make sustained IP addresses.
Is this true?
DM>>>>>>>>>>>>>>>>>>>>
Well, we do know how the network can support sustained addresses. But I believe that in our DMM work, new alternatives for supporting Fixed and Sustained IP addresses will be defined.
>>>>>>>>>>>>>>>>>>>>>DM

BTW, your DHCPv6 draft says that DHCPv6 server can give me a Sustained address/prefix but it does not say how it will be different than the fixed one?
DM>>>>>>>>>>>>>>>>>>>>>>>
That is correct. The DHCPv6 draft defines the extensions to DHCPv6 in order to support the requests and replies. DHCP does not define how IP addresses are allocated.
>>>>>>>>>>>>>>>>>>>>>>>>DM

Suppose we want to develop an access network anchoring for sustained IP addresses.
What about the needs for signaling? I have a feeling that a host running very many applications, like in today's smart phones, and so many smart phones in the system that is going to involve huge amount of signaling to get/release sustained address/prefixes, right?
DM>>>>>>>>>>>>>>>>>>>>>
Yes, a mobile host may activate several applications concurrently, but this does not mean that each application requires its own unique source IP address. Let's assume that a large amount of application are launched, some require Fixed IP addresses, some require Sustained IP addresses and the rest settle for Nomadic IP addresses. In that case, only three source IP addresses are required by the mobile node: One Fixed IP address, one Sustained and one Nomadic IP address. So the signaling overhead is not that huge.
>>>>>>>>>>>>>>>>>>>>>>DM


My conclusion from all of the above is that, I think what you propose sounds like a flashy idea but it seems to me that the complications involved in any solution is intractable.
Unless you can show me otherwise.
DM>>>>>>>>>>>>>>>>>>>>>
I hope I managed to convince you that it is not that complicated. I really think (and there are other members who share this belief) that the tunneling overhead and un-optimized routes are much more costly than what we are suggesting in this new concept.
>>>>>>>>>>>>>>>>>>>>>>>DM

 Regards,

Behcet
---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.