> -----Message d'origine----- > De : Moses, Danny [mailto:danny.mo...@intel.com] > Envoyé : mercredi 6 avril 2016 19:40 > À : SEITE Pierrick IMT/OLN > Cc : dmm@ietf.org; sarik...@ieee.org > Objet : RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 > > H Pierrick, > > Thanks for the support. > Yes, we will look for a place to add the clarification that these API > extension rely > on other protocol enhancements to communicate the address type request to the > network. We cannot currently provide reference to the specific documents you > gave in your examples because they are not RFCs (yet...). >
Correct.. thanks. > Danny > > -----Original Message----- > From: pierrick.se...@orange.com [mailto:pierrick.se...@orange.com] > Sent: Wednesday, April 06, 2016 05:43 > To: Moses, Danny; sarik...@ieee.org > Cc: dmm@ietf.org > Subject: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01 > > 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. > > --------------------------------------------------------------------- > 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. _________________________________________________________________________________________________________________________ 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
