Hi Dany, I support this I-D. I find the document very useful, and well written. We all agree that mobility management must be activated on purpose, it likely requires an enhanced source address selection framework where applications can obtain IP address with specific properties. By allowing applications to request prefix properties, this I-D is clearly a part of this framework. Maybe the document could be better by stressing clearly that it should be used together with solutions allowing the network to expose prefix properties to the host, for example with draft-korhonen-dmm-prefix-properties and draft-moses-dmm-dhcp-ondemand-mobility, which are somehow complementary... Like I said, it is a framework :-)
BR, Pierrick > -----Message d'origine----- > De : dmm [mailto:dmm-boun...@ietf.org] De la part de Moses, Danny > Envoyé : jeudi 31 mars 2016 18:44 > À : sarik...@ieee.org > Cc : dmm@ietf.org > Objet : Re: [DMM] 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:sarikaya2...@gmail.com] > Sent: Wednesday, March 30, 2016 12:12 > To: Moses, Danny > Cc: dmm@ietf.org > 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 > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
