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

[Moses, Danny]

Hi again,

We added text to the draft indicating that the means of communicating required 
address types between the host and the network is outside the scope of the 
OnDemand draft. This is due to the fact that there is no RFC that we could 
refer to.

When we complete the new RFCs that handle this communication, we will add 
reference to the OnDemand draft (hopefully it will become and RFC) to indicate 
how applications can specify the required type of the source IP address.

Regards,
Alper and Danny

-Original Message-
From: Moses, Danny 
Sent: Wednesday, April 06, 2016 20:40
To: pierrick.se...@orange.com
Cc: dmm@ietf.org; sarik...@ieee.org
Subject: 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...).

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

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

[Seil Jeon]

Hi Behcet

See inline, please.

Regards,
Seil Jeon


-Original Message-
From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com] 
Sent: Thursday, April 21, 2016 4:24 PM
To: Seil Jeon <seilj...@gmail.com>
Cc: dmm@ietf.org; Jouni Korhonen <jouni.nos...@gmail.com>
Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

On Wed, Apr 20, 2016 at 5:35 AM, Seil Jeon <seilj...@gmail.com> wrote:
> 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.
>

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.

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
> 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:dmm-boun...@ietf.org] On Behalf Of Behcet Sarikaya
> Sent: Tuesday, April 19, 2016 4:52 PM
> To: Jouni Korhonen <jouni.nos...@gmail.com>
> Cc: dmm@ietf.org
> 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.
>
> So that has nothing to do with the sustained IP addresses.
>
> Regards,
>
> Behcet
>
> On Tue, Dec 1, 2015 at 12:07 PM, Jouni Korhonen 
> <jouni.nos...@gmail.com>
> 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
>>
>> ___
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Moses, Danny]

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:dmm-boun...@ietf.org] On Behalf Of Behcet Sarikaya
Sent: Thursday, April 21, 2016 11:43
To: Seil Jeon
Cc: dmm@ietf.org
Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

On Wed, Apr 20, 2016 at 5:35 AM, Seil Jeon <seilj...@gmail.com> wrote:
> 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.


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
>
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Behcet Sarikaya
> Sent: Tuesday, April 19, 2016 4:52 PM
> To: Jouni Korhonen <jouni.nos...@gmail.com>
> Cc: dmm@ietf.org
> 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.
>
> So that has nothing to do with the sustained IP addresses.
>
> Regards,
>
> Behcet
>
> On Tue, Dec 1, 2015 at 12:07 PM, Jouni Korhonen 
> <jouni.nos...@gmail.com>
> 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
>>
>> ___
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
-
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

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

[Behcet Sarikaya]

On Wed, Apr 20, 2016 at 5:35 AM, Seil Jeon <seilj...@gmail.com> wrote:
> 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.


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
>
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Behcet Sarikaya
> Sent: Tuesday, April 19, 2016 4:52 PM
> To: Jouni Korhonen <jouni.nos...@gmail.com>
> Cc: dmm@ietf.org
> 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.
>
> So that has nothing to do with the sustained IP addresses.
>
> Regards,
>
> Behcet
>
> On Tue, Dec 1, 2015 at 12:07 PM, Jouni Korhonen <jouni.nos...@gmail.com>
> 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
>>
>> ___
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Behcet Sarikaya]

On Wed, Apr 20, 2016 at 5:35 AM, Seil Jeon <seilj...@gmail.com> wrote:
> 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.
>

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
> 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:dmm-boun...@ietf.org] On Behalf Of Behcet Sarikaya
> Sent: Tuesday, April 19, 2016 4:52 PM
> To: Jouni Korhonen <jouni.nos...@gmail.com>
> Cc: dmm@ietf.org
> 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.
>
> So that has nothing to do with the sustained IP addresses.
>
> Regards,
>
> Behcet
>
> On Tue, Dec 1, 2015 at 12:07 PM, Jouni Korhonen <jouni.nos...@gmail.com>
> 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
>>
>> ___
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Seil Jeon]

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:dmm-boun...@ietf.org] On Behalf Of Behcet Sarikaya
Sent: Tuesday, April 19, 2016 4:52 PM
To: Jouni Korhonen <jouni.nos...@gmail.com>
Cc: dmm@ietf.org
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.

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

Regards,

Behcet

On Tue, Dec 1, 2015 at 12:07 PM, Jouni Korhonen <jouni.nos...@gmail.com>
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
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Behcet Sarikaya]

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  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
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[pierrick.seite]

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

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

[Behcet Sarikaya]

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



On Wed, Apr 6, 2016 at 7:42 AM,  <pierrick.se...@orange.com> wrote:
> 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 i

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

[pierrick.seite]

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
> corresp

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

[Moses, Danny]

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 to

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

[Behcet Sarikaya]

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.

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?

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?

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?

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?

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.

 Regards,

Behcet

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Moses, Danny]

Hi Behcet,

Please see my new answers marked with DM>>

Thanks,
/Danny

-Original Message-
From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com] 
Sent: Monday, March 28, 2016 09:22
To: Moses, Danny
Cc: dmm@ietf.org
Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

On Sat, Mar 26, 2016 at 10:31 AM, Moses, Danny <danny.mo...@intel.com> wrote:
> Hi Behcet,
>
> Please see my reply in the text.
>
> Thanks,
> /Danny
>
> -Original Message-
> From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com]
> Sent: Friday, March 25, 2016 22:00
> To: Dave Dolson
> Cc: Moses, Danny; dmm@ietf.org
> Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01
>
> Hi Danny,
>
> I was reading Dave's concerns.
> In my view the real problem in this draft is not with the nomadic IP address, 
> actually Dave's concern was very syntactic.
> I have a semantic concern with the sustained IP address.
> What really is this?
> Sustained IP address is very important for this draft because everything is 
> based on that.
> Reading Section 3.1, Sustained IP Address is kind of a banana, it has the 
> taste that the beholder wants to get. It could be Fixed IP Address or nomadic.
> If Sustained IP Address gets me what I want, i.e. IP session continuity, why 
> do I need anything else?
>
> DM> I am not sure I fully understood your comment/question here. I hope my 
> reply is sufficient.
> DM>I did not understand your attempt to find resemblance between a sustained 
> IP address and a Banana. I also do not understand why you write that it could 
> be a Fixed IP address or a Nomadic IP address. It certainly cannot. What 
> should we modify in section 3.1 to make the distinguish between the different 
> types of services provided to each type of address more clearer?
> DM>If a Sustained IP address gets you what you want - choose it when your 
> application establishes a Socket. If on the other hand, a Nomadic IP address 
> gets you what you want, choose Nomadic when your application establishes a 
> Socket. If you only write applications that require Sustained IP addresses, 
> always choose them when establishing Sockets. But, as we claim in the draft, 
> there are different types of applications in the sense of the IP session 
> continuity they require from the network.

Behcet: You are assigned an address, how do you know it is 
Sustained/fixed/nomadic IP address?
DM>> Good question. Naturally, the network needs to be enhanced to support 
these new alternatives., need to be able to receive a specific request and to 
indicate to the mobile node what type of IP address (or prefix) it had 
allocated for it. This requires enhancements to some protocols who are used to 
provide IP addresses. Please refer to draft-moses-dmm-dhcp-ondemand-mobility-02 
which defines the enhancements to DHCPv6 for supporting the stating of the 
required IP address type.

Next Q: As for nomadic, I understand that I change my address when my network 
changes, i.e. I avoid having topologically incorrect address.
For fixed, I keep my address even if my network changes.
What is the sustained address case?

DM>> The difference from Sustained IP address and Fixed IP address is that the 
Sustained IP address is guaranteed by the network to be valid as long as the IP 
session is alive, while the Fixed IP address is guaranteed to be valid even 
after the IP session ends (in case the application need to re-use it at a later 
time.

I think your draft should better use these types (topologically correct, etc.) 
concepts to make sense and be understandable.
DM>> Thanks for the suggestion. We feel that Sustained and Fixed are 
understandable. We have some debates regarding - Nomadic.

> DM>Some application do not require IP session continuity services from the 
> network and should not be required to endure the overhead accompanied by that 
> service (Tunneling overhead, un-optimal routs etc..). This draft enables 
> application to convey the type of service they require, and may lead to 
> significant reduction of overhead when the above services are not required.
>

Behcet: I understand the API extension part of your draft, but I don't 
understand why you need it. You should clearly explain the use case.
Currently, the main idea is to get sustained IP address but it is not explained 
how the application gets a sustained address because it is not known?
Without a clear case, I don't think the extension is warranted.

DM>> The introduction section and sections 3.1-3.3 provides a decent 
background. Would you like to offer text to improve it?

> It says in the draft, it may be configured by using access network anchoring, 
> corresponding network anchoring, or something else, whatever that is?
> Which access network are you tal

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

[Behcet Sarikaya]

On Sat, Mar 26, 2016 at 10:31 AM, Moses, Danny <danny.mo...@intel.com> wrote:
> Hi Behcet,
>
> Please see my reply in the text.
>
> Thanks,
> /Danny
>
> -Original Message-
> From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com]
> Sent: Friday, March 25, 2016 22:00
> To: Dave Dolson
> Cc: Moses, Danny; dmm@ietf.org
> Subject: Re: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01
>
> Hi Danny,
>
> I was reading Dave's concerns.
> In my view the real problem in this draft is not with the nomadic IP address, 
> actually Dave's concern was very syntactic.
> I have a semantic concern with the sustained IP address.
> What really is this?
> Sustained IP address is very important for this draft because everything is 
> based on that.
> Reading Section 3.1, Sustained IP Address is kind of a banana, it has the 
> taste that the beholder wants to get. It could be Fixed IP Address or nomadic.
> If Sustained IP Address gets me what I want, i.e. IP session continuity, why 
> do I need anything else?
>
> DM> I am not sure I fully understood your comment/question here. I hope my 
> reply is sufficient.
> DM>I did not understand your attempt to find resemblance between a sustained 
> IP address and a Banana. I also do not understand why you write that it could 
> be a Fixed IP address or a Nomadic IP address. It certainly cannot. What 
> should we modify in section 3.1 to make the distinguish between the different 
> types of services provided to each type of address more clearer?
> DM>If a Sustained IP address gets you what you want - choose it when your 
> application establishes a Socket. If on the other hand, a Nomadic IP address 
> gets you what you want, choose Nomadic when your application establishes a 
> Socket. If you only write applications that require Sustained IP addresses, 
> always choose them when establishing Sockets. But, as we claim in the draft, 
> there are different types of applications in the sense of the IP session 
> continuity they require from the network.

Behcet: You are assigned an address, how do you know it is
Sustained/fixed/nomadic IP address?

Next Q: As for nomadic, I understand that I change my address when my
network changes, i.e. I avoid having topologically incorrect address.
For fixed, I keep my address even if my network changes.
What is the sustained address case?

I think your draft should better use these types (topologically
correct, etc.) concepts to make sense and be understandable.

> DM>Some application do not require IP session continuity services from the 
> network and should not be required to endure the overhead accompanied by that 
> service (Tunneling overhead, un-optimal routs etc..). This draft enables 
> application to convey the type of service they require, and may lead to 
> significant reduction of overhead when the above services are not required.
>

Behcet: I understand the API extension part of your draft, but I don't
understand why you need it. You should clearly explain the use case.
Currently, the main idea is to get sustained IP address but it is not
explained how the application gets a sustained address because it is
not known?
Without a clear case, I don't think the extension is warranted.

> It says in the draft, it may be configured by using access network anchoring, 
> corresponding network anchoring, or something else, whatever that is?
> Which access network are you talking about? Is it good old 3GPP? Then, the 
> answer is yes but then what type of new solution is this?
> DM> This draft does not list the various ways of achieving IP session 
> continuity as required for a Sustained IP address. It's true that current 
> cellular networks use tunneling but other methods could be implemented in the 
> future. We do not want to limit the definition of the different services to a 
> specific radio technology.
>
> I think what this draft is trying to say is if I am in 3GPP coverage area I 
> use 3GPP anchoring, if I am in Wi-Fi coverage area, I use MIPv6. Is this what 
> you had in mind?
> DM> Actually it does not say anything about the means of enabling Sustained 
> IP addresses. It only defines what the different services are, and defines 
> extension to the existing Socket interface, to enable applications specify 
> the type of IP continuity service they need.
>

Behcet: Yes but without explaining what is sustained address, I don't
think you can justify the extension. So the draft needs a strong
justification and use case text.

> I do not recall under which category does this draft fall? Is it a 
> maintenance type of draft? Or is it dmm type of draft?
> DM>It’s a DMM draft
>
Behcet: So no fixed anchoring in e.g. 3GPP is assumed?


> Regards,
>
> Behcet
>
> On Sun, Feb 21, 2

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

[Behcet Sarikaya]

Hi Danny,

I was reading Dave's concerns.
In my view the real problem in this draft is not with the nomadic IP
address, actually Dave's concern was very syntactic.
I have a semantic concern with the sustained IP address.
What really is this?
Sustained IP address is very important for this draft because
everything is based on that.
Reading Section 3.1, Sustained IP Address is kind of a banana, it has
the taste that the beholder wants to get. It could be Fixed IP Address
or nomadic.
If Sustained IP Address gets me what I want, i.e. IP session
continuity, why do I need anything else?
It says in the draft, it may be configured by using access network
anchoring, corresponding network anchoring, or something else,
whatever that is?
Which access network are you talking about? Is it good old 3GPP? Then,
the answer is yes but then what type of new solution is this?

I think what this draft is trying to say is if I am in 3GPP coverage
area I use 3GPP anchoring, if I am in Wi-Fi coverage area, I use
MIPv6. Is this what you had in mind?

I do not recall under which category does this draft fall? Is it a
maintenance type of draft? Or is it dmm type of draft?

Regards,

Behcet

On Sun, Feb 21, 2016 at 8:05 PM, Dave Dolson <ddol...@sandvine.com> wrote:
> >From an application developer's point of view, I don't think there should be 
> >a distinction about roaming between providers or with the same provider.
> It should work with WiFi, mobile, even wired Ethernet.
> E.g., as I unplug my laptop from work, use the 3G stick on the train, WiFi in 
> the coffee shop and plug in wired Ethernet at home. I could have a fixed 
> address as well as several temporary (no guarantee) addresses.
>
> I'm not saying all of those access technologies need to have implementation 
> of all types of addresses.
> One might only get a fixed address from one of those providers, all the 
> others being no-guarantee.
>
> -Dave
>
> 
> From: Moses, Danny [danny.mo...@intel.com]
> Sent: Sunday, February 21, 2016 10:05 AM
> To: Dave Dolson; dmm@ietf.org
> Subject: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01
>
> Hi Dave,
>
> Regarding the term "Nomadic" IP address:
> Actually, this draft is about enhancements to the Socket API that are useful 
> in relation with movement of the mobile host. Its intent was to notify the 
> access network as to the type of IP session continuity it requires upon 
> movement between LANs. The idea is to reduce the network support for session 
> continuity (via PMIP, GTP, etc) when it is not needed. This draft is not 
> dealing with devices migrating from one service provider to another as other 
> issues should be handled in such scenario.
>
> "Local" is not good as it clashes with IPv6 Local addresses.
>
> The best term in my mind would be: "An IP address without any NW guarantee to 
> continue to be valid after a potential host movement to a new LAN with a 
> different IP prefix". So far, we could not come with a good name for such an 
> address. May be "Guarantee-less"?
>
> Let's not forget: this is going to be used by application developers who do 
> not necessarily fully understand how networks allocate IP addresses and 
> maintain their validity.
>
> Regarding when On-Demand resolution occurs (Point 6):
> How about if we say:
>
> If applications want to influence the type of IP address their generated 
> traffic will use, they must do so after creating a Socket and prior to 
> generating the first transmitted packet.
>
> We do not want to be too specific since it is not a user's manual.
>
> Does this sound reasonable to you?
>
> Thanks,
>     /Danny
>
> -Original Message-
> From: Dave Dolson [mailto:ddol...@sandvine.com]
> Sent: Thursday, February 18, 2016 22:46
> To: Moses, Danny; dmm@ietf.org
> Subject: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01
>
> Danny and Alper,
> Thanks. I hope your helpful explanations below make it into the draft as well.
>
>
> On the "nomadic address" question, this name really feels wrong to me. The 
> address doesn't move and hence isn't nomadic.
> You don't like "ephemeral" because it doesn't convey movement.
> But a question, does the host have to move for the principles of this 
> document to apply?
> Couldn't a host get a new address (perhaps from a different wireless 
> provider) without moving?
> Maybe "non-nomadic address" or "provider-local address" ?
>
>
> On point 6, yes I think you have to specify when the resolution occurs, since 
> it affects which functions return error codes.
> I don't think the local address can be resolved before connect(), since the 
> choice of l

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

[Moses, Danny]

'Non-persistent topologically-correct' is too long...

But, 'non-persistent' or 'guarantee-less' might be considered.
It seems like this is the only  issue to e resolve. How about I present this in 
the next Face-to-face and we can have a final vote on it.

Regards,
/Danny

-Original Message-
From: Newton, Mathew Mr [mailto:mathew.newton...@mod.uk] 
Sent: Thursday, February 25, 2016 17:30
To: Dave Dolson; Moses, Danny
Cc: dmm@ietf.org
Subject: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

A recent, and hitherto silent, lurker here so apologies for wading in 
unannounced and so late in the day...

-Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Dave Dolson

> On the "nomadic address" question, this name really feels wrong to me. The 
> address doesn't move and hence isn't nomadic.
> You don't like "ephemeral" because it doesn't convey movement.
> But a question, does the host have to move for the principles of this 
> document to apply?
> Couldn't a host get a new address (perhaps from a different wireless 
> provider) without moving?
> Maybe "non-nomadic address" or "provider-local address" ?

Would something along the lines of 'Non-persistent topologically-correct' 
address work here?

The 'topologically-correct' component reflects the fact that the address is 
relevant/usable only on a specific network connection. The 'non-persistent' 
aspect indicates that this address can change (whether that be due to a change 
of attachment or not is immaterial in this context).

Granted it is a bit of a mouthful but perhaps the nuances of what is trying to 
be described require it?

Regards,

Mathew
-
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

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

[Newton, Mathew Mr]

A recent, and hitherto silent, lurker here so apologies for wading in 
unannounced and so late in the day...

-Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Dave Dolson

> On the "nomadic address" question, this name really feels wrong to me. The 
> address doesn't move and hence isn't nomadic.
> You don't like "ephemeral" because it doesn't convey movement.
> But a question, does the host have to move for the principles of this 
> document to apply?
> Couldn't a host get a new address (perhaps from a different wireless 
> provider) without moving?
> Maybe "non-nomadic address" or "provider-local address" ?

Would something along the lines of 'Non-persistent topologically-correct' 
address work here?

The 'topologically-correct' component reflects the fact that the address is 
relevant/usable only on a specific network connection. The 'non-persistent' 
aspect indicates that this address can change (whether that be due to a change 
of attachment or not is immaterial in this context).

Granted it is a bit of a mouthful but perhaps the nuances of what is trying to 
be described require it?

Regards,

Mathew

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Dave Dolson]

>From an application developer's point of view, I don't think there should be a 
>distinction about roaming between providers or with the same provider.
It should work with WiFi, mobile, even wired Ethernet.
E.g., as I unplug my laptop from work, use the 3G stick on the train, WiFi in 
the coffee shop and plug in wired Ethernet at home. I could have a fixed 
address as well as several temporary (no guarantee) addresses.

I'm not saying all of those access technologies need to have implementation of 
all types of addresses.
One might only get a fixed address from one of those providers, all the others 
being no-guarantee.

-Dave


From: Moses, Danny [danny.mo...@intel.com]
Sent: Sunday, February 21, 2016 10:05 AM
To: Dave Dolson; dmm@ietf.org
Subject: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

Hi Dave,

Regarding the term "Nomadic" IP address:
Actually, this draft is about enhancements to the Socket API that are useful in 
relation with movement of the mobile host. Its intent was to notify the access 
network as to the type of IP session continuity it requires upon movement 
between LANs. The idea is to reduce the network support for session continuity 
(via PMIP, GTP, etc) when it is not needed. This draft is not dealing with 
devices migrating from one service provider to another as other issues should 
be handled in such scenario.

"Local" is not good as it clashes with IPv6 Local addresses.

The best term in my mind would be: "An IP address without any NW guarantee to 
continue to be valid after a potential host movement to a new LAN with a 
different IP prefix". So far, we could not come with a good name for such an 
address. May be "Guarantee-less"?

Let's not forget: this is going to be used by application developers who do not 
necessarily fully understand how networks allocate IP addresses and maintain 
their validity.

Regarding when On-Demand resolution occurs (Point 6):
How about if we say:

If applications want to influence the type of IP address their generated 
traffic will use, they must do so after creating a Socket and prior to 
generating the first transmitted packet.

We do not want to be too specific since it is not a user's manual.

Does this sound reasonable to you?

Thanks,
/Danny

-Original Message-
From: Dave Dolson [mailto:ddol...@sandvine.com]
Sent: Thursday, February 18, 2016 22:46
To: Moses, Danny; dmm@ietf.org
Subject: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

Danny and Alper,
Thanks. I hope your helpful explanations below make it into the draft as well.


On the "nomadic address" question, this name really feels wrong to me. The 
address doesn't move and hence isn't nomadic.
You don't like "ephemeral" because it doesn't convey movement.
But a question, does the host have to move for the principles of this document 
to apply?
Couldn't a host get a new address (perhaps from a different wireless provider) 
without moving?
Maybe "non-nomadic address" or "provider-local address" ?


On point 6, yes I think you have to specify when the resolution occurs, since 
it affects which functions return error codes.
I don't think the local address can be resolved before connect(), since the 
choice of local address may depend on the remote address to connect. E.g., 
connections to a peer on a local LAN subnet need to use an address on that 
interface.


-Dave




-Original Message-
From: Moses, Danny [mailto:danny.mo...@intel.com]
Sent: Thursday, February 18, 2016 9:13 AM
To: Dave Dolson; dmm@ietf.org
Subject: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

Hi Dave,

Sorry for the very late response. Somehow we missed the original email and were 
reminded by Jouni (Thanks Jouni).

Anyway, thank you for the thorough and helpful comments. We have produced a new 
version and will publish it shortly.

Please see further details to your comments:

Dave>
1. Was the term "Nomadic" discussed? To me, a nomadic thing moves around, but 
in this draft, Nomadic IP addresses do not move around; they are replaced. 
"Ephemeral IP Address" might convey the idea more clearly.

Reply>
"Nomadic" was discussed, it is not the best name but we could not find a better 
one.
What 'moves around' is the mobile host and as a result of that movement, its 
source IP address might become obsolete (when it moves from its original LAN to 
another with a different prefix). An application on a mobile host requires a 
'Nomadic' IP address when it does not care for the IP continuity guarantee 
services provided by the network. This is either because it knows that the 
mobile host is not really mobile, or because it has other means of maintaining 
session continuity and does not want the overhead associated with 
network-provided IP continuity services.

The term 'Ephemeral' is not associated with m

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

[Moses, Danny]

Hi Dave,

Regarding the term "Nomadic" IP address:
Actually, this draft is about enhancements to the Socket API that are useful in 
relation with movement of the mobile host. Its intent was to notify the access 
network as to the type of IP session continuity it requires upon movement 
between LANs. The idea is to reduce the network support for session continuity 
(via PMIP, GTP, etc) when it is not needed. This draft is not dealing with 
devices migrating from one service provider to another as other issues should 
be handled in such scenario.

"Local" is not good as it clashes with IPv6 Local addresses.

The best term in my mind would be: "An IP address without any NW guarantee to 
continue to be valid after a potential host movement to a new LAN with a 
different IP prefix". So far, we could not come with a good name for such an 
address. May be "Guarantee-less"?

Let's not forget: this is going to be used by application developers who do not 
necessarily fully understand how networks allocate IP addresses and maintain 
their validity.

Regarding when On-Demand resolution occurs (Point 6):
How about if we say:

If applications want to influence the type of IP address their generated 
traffic will use, they must do so after creating a Socket and prior to 
generating the first transmitted packet.

We do not want to be too specific since it is not a user's manual.

Does this sound reasonable to you?

Thanks,
/Danny

-Original Message-
From: Dave Dolson [mailto:ddol...@sandvine.com] 
Sent: Thursday, February 18, 2016 22:46
To: Moses, Danny; dmm@ietf.org
Subject: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

Danny and Alper,
Thanks. I hope your helpful explanations below make it into the draft as well.


On the "nomadic address" question, this name really feels wrong to me. The 
address doesn't move and hence isn't nomadic.
You don't like "ephemeral" because it doesn't convey movement.
But a question, does the host have to move for the principles of this document 
to apply?
Couldn't a host get a new address (perhaps from a different wireless provider) 
without moving?
Maybe "non-nomadic address" or "provider-local address" ?


On point 6, yes I think you have to specify when the resolution occurs, since 
it affects which functions return error codes.
I don't think the local address can be resolved before connect(), since the 
choice of local address may depend on the remote address to connect. E.g., 
connections to a peer on a local LAN subnet need to use an address on that 
interface.


-Dave




-Original Message-
From: Moses, Danny [mailto:danny.mo...@intel.com]
Sent: Thursday, February 18, 2016 9:13 AM
To: Dave Dolson; dmm@ietf.org
Subject: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

Hi Dave,

Sorry for the very late response. Somehow we missed the original email and were 
reminded by Jouni (Thanks Jouni).

Anyway, thank you for the thorough and helpful comments. We have produced a new 
version and will publish it shortly.

Please see further details to your comments:

Dave>
1. Was the term "Nomadic" discussed? To me, a nomadic thing moves around, but 
in this draft, Nomadic IP addresses do not move around; they are replaced. 
"Ephemeral IP Address" might convey the idea more clearly.

Reply>
"Nomadic" was discussed, it is not the best name but we could not find a better 
one.
What 'moves around' is the mobile host and as a result of that movement, its 
source IP address might become obsolete (when it moves from its original LAN to 
another with a different prefix). An application on a mobile host requires a 
'Nomadic' IP address when it does not care for the IP continuity guarantee 
services provided by the network. This is either because it knows that the 
mobile host is not really mobile, or because it has other means of maintaining 
session continuity and does not want the overhead associated with 
network-provided IP continuity services.

The term 'Ephemeral' is not associated with movement - we think it is better to 
have a 'movement'-related name.

Dave>
2. I know this is really picky, but it wouldn't hurt to spell out "REQUIRE" in 
IPV6_REQ_FIXED_IP etc.
 - IPV6_REQUIRE_FIXED_IP in parallel with IPV6_PREFER_SRC_PUBLIC

Reply>
Make sense. Will be changed in the next version.

Dave>
3. There is a "TDB" in section 3.4. "TBD: Disallow this case?"  This needs to 
be resolved. I suggest the most restrictive flag applies.

Reply>
This is about whether to enable the application to set more than one flag or 
not per a given socket. We left that for discussion in the draft but never 
resolved it.

We prefer not to enable setting more than one flag since it add complexity. The 
application can check the returned code and act upon it. For example, if it 
uses setsockopt() with IPV6_REQUIRE_F

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

[Dave Dolson]

Danny and Alper,
Thanks. I hope your helpful explanations below make it into the draft as well.


On the "nomadic address" question, this name really feels wrong to me. The 
address doesn't move and hence isn't nomadic.
You don't like "ephemeral" because it doesn't convey movement.
But a question, does the host have to move for the principles of this document 
to apply?
Couldn't a host get a new address (perhaps from a different wireless provider) 
without moving?
Maybe "non-nomadic address" or "provider-local address" ?


On point 6, yes I think you have to specify when the resolution occurs, since 
it affects which functions return error codes.
I don't think the local address can be resolved before connect(), since the 
choice of local address may depend on the remote address to connect. E.g., 
connections to a peer on a local LAN subnet need to use an address on that 
interface.


-Dave




-Original Message-
From: Moses, Danny [mailto:danny.mo...@intel.com] 
Sent: Thursday, February 18, 2016 9:13 AM
To: Dave Dolson; dmm@ietf.org
Subject: RE: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

Hi Dave,

Sorry for the very late response. Somehow we missed the original email and were 
reminded by Jouni (Thanks Jouni).

Anyway, thank you for the thorough and helpful comments. We have produced a new 
version and will publish it shortly.

Please see further details to your comments:

Dave>
1. Was the term "Nomadic" discussed? To me, a nomadic thing moves around, but 
in this draft, Nomadic IP addresses do not move around; they are replaced. 
"Ephemeral IP Address" might convey the idea more clearly.

Reply>
"Nomadic" was discussed, it is not the best name but we could not find a better 
one.
What 'moves around' is the mobile host and as a result of that movement, its 
source IP address might become obsolete (when it moves from its original LAN to 
another with a different prefix). An application on a mobile host requires a 
'Nomadic' IP address when it does not care for the IP continuity guarantee 
services provided by the network. This is either because it knows that the 
mobile host is not really mobile, or because it has other means of maintaining 
session continuity and does not want the overhead associated with 
network-provided IP continuity services.

The term 'Ephemeral' is not associated with movement - we think it is better to 
have a 'movement'-related name.

Dave>
2. I know this is really picky, but it wouldn't hurt to spell out "REQUIRE" in 
IPV6_REQ_FIXED_IP etc.
 - IPV6_REQUIRE_FIXED_IP in parallel with IPV6_PREFER_SRC_PUBLIC

Reply>
Make sense. Will be changed in the next version.

Dave>
3. There is a "TDB" in section 3.4. "TBD: Disallow this case?"  This needs to 
be resolved. I suggest the most restrictive flag applies.

Reply>
This is about whether to enable the application to set more than one flag or 
not per a given socket. We left that for discussion in the draft but never 
resolved it.

We prefer not to enable setting more than one flag since it add complexity. The 
application can check the returned code and act upon it. For example, if it 
uses setsockopt() with IPV6_REQUIRE_FIXED_IP and the call returns with an error 
code, it can re-attempt with IPV6_REQUEST_SUSTAINED_IP or 
IPV6_REQUEST_NOMADIC_IP (or without the flags - in case they are not supported 
by the network).

So we are replacing the original text:
More than one of these flags may be set on the same socket. In that
case, an IP address compliant with any one of them shall be selected.
TBD: Disallow this case?

With:
Only one flag of these flags may be set on the same socket. If an application 
attempts to set more than one flag, the most recent setting will be the one in 
effect.

Dave>
4. Must resolve "Application of this solution to IPv4 is TBD." 
 - clearly the socket option is IPV6_something, but...
 - there is uncharted territory surrounding IPv4-mapped-IPv6 addresses 
(https://tools.ietf.org/html/rfc4291#section-2.5.5.2 ), when socket option 
IPV6_V6ONLY is false.
 - I think the goal should be that the API *does* apply to IPv4 via 
IPv4-mapped-IPv6 addresses, while acknowledging that the operating system or 
network may not be able to fulfill the request.
- I.e., permit the application to request constraints on IPv4, but also 
expect the application to try for a relaxed address if the initial request 
fails.
 - I see no need to support the API with AF_INET sockets, since AF_INET6 can be 
used with IPV6_ONLY=false and IPv4-mapped-IPv6 addresses.

Reply>
Actually, the charter of DMM addresses IPv6 only. So we are removing the text 
that refers to IPv4 altogether. If we see in the future a need to address IPv4, 
we will do so in a separate draft.

Dave>
5. The error codes are not clearly defined. What is the errno for failure of 
setsockopt() and others?

Reply>
Tr

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

[Dave Dolson]

(I haven't paid close attention to the list, so apologies if I'm raising old 
issues.)

1. Was the term "Nomadic" discussed? To me, a nomadic thing moves around, but 
in this draft, Nomadic IP addresses do not move around; they are replaced. 
"Ephemeral IP Address" might convey the idea more clearly.

2. I know this is really picky, but it wouldn't hurt to spell out "REQUIRE" in 
IPV6_REQ_FIXED_IP etc.
 - IPV6_REQUIRE_FIXED_IP in parallel with IPV6_PREFER_SRC_PUBLIC

3. There is a "TDB" in section 3.4. "TBD: Disallow this case?"  This needs to 
be resolved. I suggest the most restrictive flag applies.

4. Must resolve "Application of this solution to IPv4 is TBD." 
 - clearly the socket option is IPV6_something, but...
 - there is uncharted territory surrounding IPv4-mapped-IPv6 addresses 
(https://tools.ietf.org/html/rfc4291#section-2.5.5.2 ), when socket option 
IPV6_V6ONLY is false.
 - I think the goal should be that the API *does* apply to IPv4 via 
IPv4-mapped-IPv6 addresses, while acknowledging that the operating system or 
network may not be able to fulfill the request.
- I.e., permit the application to request constraints on IPv4, but also 
expect the application to try for a relaxed address if the initial request 
fails.
 - I see no need to support the API with AF_INET sockets, since AF_INET6 can be 
used with IPV6_ONLY=false and IPv4-mapped-IPv6 addresses.

5. The error codes are not clearly defined. What is the errno for failure of 
setsockopt() and others?

6. I'm unclear on when the on-demand resolution occurs? I don't think it can be 
done at the time of setsockopt(); as I understand it, the addresses are 
resolved later, at connect() or listen(). I'm not sure about this, but it 
should be explained. If the resolution is done at connect() time, is a new 
errno required?

7. Some socket interfaces are not mentioned. What about sendto(), sendmsg(), 
which are not connection-oriented?

8. In section 4.1, support for legacy applications does not really say how to 
support legacy applications.
 - my opinion: the default (lacking new socket options) should be to require 
Fixed for listen() and Sustained for connect(), and Nomadic/Ephemeral for 
non-connected datagrams.



-Dave




-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Jouni Korhonen
Sent: Tuesday, December 01, 2015 1:07 PM
To: dmm@ietf.org; Jouni; Dapeng Liu
Subject: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

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

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm