Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

From: <[email-masked]>
Date: Wed, 6 Apr 2016 12:42:33 +0000

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:[email-masked]] De la part de Moses, Danny
> Envoyé : jeudi 31 mars 2016 18:44
> À : [email-masked]
> Cc : [email-masked]
> 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:[email-masked]]
> Sent: Wednesday, March 30, 2016 12:12
> To: Moses, Danny
> Cc: [email-masked]
> 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-masked]
> 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.

---

From: "Moses, Danny" <[email-masked]>
Date: Wed, 6 Apr 2016 17:39:55 +0000

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

	Danny

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, April 06, 2016 05:43
To: Moses, Danny; [email-masked]
Cc: [email-masked]
Subject: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

Hi Dany,

BR,
Pierrick

> Envoyé : jeudi 31 mars 2016 18:44 À : [email-masked] Cc : 
> [email-masked] Objet : Re: [DMM] WGLC #1 for 
> draft-ietf-dmm-ondemand-mobility-01
> 
> Hi,
> 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 moves to a different location and needs to 
> refresh its source IP address.
>  - 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
> 
> 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.
> 
>  the IP address used at the beginning of the session remains usable 
> despite the movement of the mobile host.
> 
> and then you say
> 
> 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
> 
> 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.
> 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.
> 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
> 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.

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.

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 6 Apr 2016 13:01:20 -0500

I am hoping that someone can show me a protocol that exists in some
form, maybe a draft, that implements fine-grained anchoring as
required by Sustained IP Addresses.

We will write sometime in the future is not acceptable, then this and
similar drafts have to wait until that time comes.

One implication of this is such a protocol is willing to cope with the
host routes.

Behcet

---

From: <[email-masked]>
Date: Thu, 7 Apr 2016 09:02:53 +0000

> De : Moses, Danny [mailto:[email-masked]]
> Envoyé : mercredi 6 avril 2016 19:40
> À : SEITE Pierrick IMT/OLN
> Cc : [email-masked]; [email-masked]
> 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.

> 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
> 
> > only three source IP addresses are required by the mobile node: One Fixed IP
> address, one Sustained and one Nomadic IP address.
> ______________________________________________________________________
> ___________________________________________________
> 
> 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.

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 19 Apr 2016 02:51:41 -0500

Hello Folks,

At IETF 95 session, there was some discussion on the mention of on
demand mobility in 3GPP 5G documents, e.g. 23.799.

It seems like 3GPP meaning of on demand mobility is that the UE asks
or demands mobility support or not.

So that has nothing to do with the sustained IP addresses.

Regards,

Behcet

On Tue, Dec 1, 2015 at 12:07 PM, Jouni Korhonen <[email-masked]> wrote:
> Folks,
>
> This mail starts two week WGLC for the I-D:
>         https://tools.ietf.org/html/draft-ietf-dmm-ondemand-mobility-01
>
> The WGLC ends 12/15/2015.
>
> Provide your reviews and comments to the mailing list. For the better
> tracking of issues and proposed changed use the Issue Tracker to submit your
> issues/proposals.
>
> - Jouni & Dapeng
>

---

From: "Seil Jeon" <[email-masked]>
Date: Wed, 20 Apr 2016 19:35:30 +0900

Hi Behcet,

As I was not there, what discussions was given.
However, let me speak a few words.

The specs. you referenced seems talking about need of different levels of
mobility support, e.g. high/medium/low mobility and so on.
Within the frame, I think having a proper level of mobility support based on
IP session continuity and IP address reachability for an application, with
the defined source IP address type request will make sense in the scope of
mobility support in the specs.

Besides, as you know, the spec. currently remains at 0.2 version, describing
work items briefly and concisely. It doesn't constraint potentials for
on-demand mobility. And we don't know how/where the direction will be going.

Regards,
Seil Jeon

-----Original Message-----
From: dmm [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
Sent: Tuesday, April 19, 2016 4:52 PM
To: Jouni Korhonen <[email-masked]>
Cc: [email-masked]
Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

Hello Folks,

At IETF 95 session, there was some discussion on the mention of on demand
mobility in 3GPP 5G documents, e.g. 23.799.

It seems like 3GPP meaning of on demand mobility is that the UE asks or
demands mobility support or not.

Regards,

Behcet

On Tue, Dec 1, 2015 at 12:07 PM, Jouni Korhonen <[email-masked]>
wrote:
> tracking of issues and proposed changed use the Issue Tracker to 
> submit your issues/proposals.
>
> - Jouni & Dapeng
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 21 Apr 2016 02:23:49 -0500

> mobility support in the specs.

Did I say below that it does or does not say these things?

What I said is the current thinking is to tie it to the UE asking for
mobility support or not.

If you have time, I would recommend spending it on coming up with a
solution for the so-called sustained IP address.

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 21 Apr 2016 03:43:02 -0500

> mobility support, e.g. high/medium/low mobility and so on.

I am looking at Rev 0.3, they no longer have those.
I am hearing that Rev 0.4 is being worked out and maybe posted
sometime next week.
I hope this clarifies.

Behcet

---

From: "Moses, Danny" <[email-masked]>
Date: Thu, 21 Apr 2016 09:06:43 +0000

Hi guys,

Alper and I are in the process of compiling all the new comments we received in the last DMM face to face. We plan to issue a new version of the draft that, hopefully, clarifies the definitions and will provide a written response on the mailing list with further explanation and responses to all the comments.

Please be patient for a couple of days.

Thanks,

Alper and Danny

-----Original Message-----
From: dmm [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
Sent: Thursday, April 21, 2016 11:43
To: Seil Jeon
Cc: [email-masked]
Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

On Wed, Apr 20, 2016 at 5:35 AM, Seil Jeon <[email-masked]> wrote:
> The specs. you referenced seems talking about need of different levels 
> of mobility support, e.g. high/medium/low mobility and so on.

I am looking at Rev 0.3, they no longer have those.
I am hearing that Rev 0.4 is being worked out and maybe posted sometime next week.
I hope this clarifies.

Behcet

> Within the frame, I think having a proper level of mobility support 
> based on IP session continuity and IP address reachability for an 
> application, with the defined source IP address type request will make 
> sense in the scope of mobility support in the specs.
>
> Besides, as you know, the spec. currently remains at 0.2 version, 
> describing work items briefly and concisely. It doesn't constraint 
> potentials for on-demand mobility. And we don't know how/where the direction will be going.
>
> Regards,
> Seil Jeon
>

---

From: "Seil Jeon" <[email-masked]>
Date: Thu, 21 Apr 2016 19:02:29 +0900

Hi Behcet,

I don't know where you could get rev 0.3. Currently in my access, rev 0.2 is the latest one.
http://www.3gpp.org/DynaReport/23799.htm

And it is saying following

"The types of mobility the system should support, e.g. high mobility, medium mobility, low mobility, no mobility and mobility on demand;"

Regards,
Seil Jeon

-----Original Message-----
From: Behcet Sarikaya [mailto:[email-masked]] 
Sent: Thursday, April 21, 2016 5:43 PM
To: Seil Jeon <[email-masked]>
Cc: [email-masked]; Jouni Korhonen <[email-masked]>
Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

Behcet

---

From: "Seil Jeon" <[email-masked]>
Date: Thu, 21 Apr 2016 19:05:17 +0900

Hi Behcet

See inline, please.

Regards,
Seil Jeon

-----Original Message-----
From: Behcet Sarikaya [mailto:[email-masked]] 
Sent: Thursday, April 21, 2016 4:24 PM
To: Seil Jeon <[email-masked]>
Cc: [email-masked]; Jouni Korhonen <[email-masked]>
Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

What I said is the current thinking is to tie it to the UE asking for mobility support or not.

SJ) Yes, it is based on a terminal-driven approach. We may consider a network-driven approach, if submitted by a person being interested in.

If you have time, I would recommend spending it on coming up with a solution for the so-called sustained IP address.

SJ) I spent my time for it.

Behcet