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