Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 --

[Dave Dolson]

Danny,
Thank you for explaining. I read this draft without knowing the back story, and 
I did not glean the explanation below from the draft.

If you want the explanation recorded for posterity, it should be in the draft.

Having said that, it would be better, in my opinion, if this API is NOT 
specific to proxy-based architectures.
An application programmer is concerned with whether it needs a long-lasting 
address or whether an ephemeral address is acceptable.
(i.e., am I a client or a server?)

I don’t see many application programmers concerned with on-demand DMM per se.

-Dave


From: Moses, Danny [mailto:danny.mo...@intel.com]
Sent: Monday, December 19, 2016 6:16 AM
To: Lorenzo Colitti; Dave Dolson
Cc: draft-ietf-dmm-ondemand-mobil...@ietf.org; dmm@ietf.org
Subject: RE: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 --

OK, two is a crowd…

I am thinking of the appropriate example and will send a draft for review.

I think there might be a confusion regarding the HOME and CoA flags. Although 
they are also related to mobility and enable applications a selection between 
two types of source IP addresses, they are very different and should not be 
discussed in the context of OnDemand.

The HOME and CoA flags are defined to enable an application to select between a 
HOME address and a Care-of address. This is in the context of Mobile IP (no 
Proxy Mobile IP) in which the network allocates both a Home Address and a 
Care-of Address to the mobile host. These flags enable applications to select 
the type of IP session continuity in this context (where the host is one 
termination point of the tunnel).

The context of the OnDemand draft is PMIP (or any proxy-based architecture, 
like GTP). In this context, the mobile host does not have a Home Address and a 
Care-of-Address since the tunnel is terminated by a proxy agent. So an 
application cannot specify its preference regarding Home or CoA.

Danny


From: Lorenzo Colitti [mailto:lore...@google.com]
Sent: Monday, December 19, 2016 03:04
To: Dave Dolson <ddol...@sandvine.com>
Cc: Moses, Danny <danny.mo...@intel.com>; 
draft-ietf-dmm-ondemand-mobil...@ietf.org; dmm@ietf.org
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 --

rOn Fri, Dec 9, 2016 at 3:59 AM, Dave Dolson 
<ddol...@sandvine.com<mailto:ddol...@sandvine.com>> wrote:
5. Are there new errors from bind(), listen() or connect(), etc.?
E.g., socket option is FIXED, but user explicitly specified a COA address to 
bind to?

+1. An implementer would probably choose to return EADDRNOTAVAIL if an API 
requested a type of address that is not available, but the draft makes no 
mention of that.

The draft also fails to mention which of the APIs will result in a request to 
the network (which can block for a long period of time) and which will not. It 
will be quite unexpected to app developers if system calls such as bind() and 
setsockopt(), which always return immediately, can suddenly block for whole 
seconds. It would also be highly unexpected if connect() on a UDP socket took a 
long time since it currently returns immediately.

I don't think it's a good idea to overload these existing system calls with new 
"obtain an prefix from the network" semantics. It's better to add a new system 
call for that.

-
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 for draft-ietf-dmm-ondemand-mobility-08 --

[Moses, Danny]

OK, two is a crowd…

I am thinking of the appropriate example and will send a draft for review.

I think there might be a confusion regarding the HOME and CoA flags. Although 
they are also related to mobility and enable applications a selection between 
two types of source IP addresses, they are very different and should not be 
discussed in the context of OnDemand.

The HOME and CoA flags are defined to enable an application to select between a 
HOME address and a Care-of address. This is in the context of Mobile IP (no 
Proxy Mobile IP) in which the network allocates both a Home Address and a 
Care-of Address to the mobile host. These flags enable applications to select 
the type of IP session continuity in this context (where the host is one 
termination point of the tunnel).

The context of the OnDemand draft is PMIP (or any proxy-based architecture, 
like GTP). In this context, the mobile host does not have a Home Address and a 
Care-of-Address since the tunnel is terminated by a proxy agent. So an 
application cannot specify its preference regarding Home or CoA.

Danny


From: Lorenzo Colitti [mailto:lore...@google.com]
Sent: Monday, December 19, 2016 03:04
To: Dave Dolson <ddol...@sandvine.com>
Cc: Moses, Danny <danny.mo...@intel.com>; 
draft-ietf-dmm-ondemand-mobil...@ietf.org; dmm@ietf.org
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 --

rOn Fri, Dec 9, 2016 at 3:59 AM, Dave Dolson 
<ddol...@sandvine.com<mailto:ddol...@sandvine.com>> wrote:
5. Are there new errors from bind(), listen() or connect(), etc.?
E.g., socket option is FIXED, but user explicitly specified a COA address to 
bind to?

+1. An implementer would probably choose to return EADDRNOTAVAIL if an API 
requested a type of address that is not available, but the draft makes no 
mention of that.

The draft also fails to mention which of the APIs will result in a request to 
the network (which can block for a long period of time) and which will not. It 
will be quite unexpected to app developers if system calls such as bind() and 
setsockopt(), which always return immediately, can suddenly block for whole 
seconds. It would also be highly unexpected if connect() on a UDP socket took a 
long time since it currently returns immediately.

I don't think it's a good idea to overload these existing system calls with new 
"obtain an prefix from the network" semantics. It's better to add a new system 
call for that.
-
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 for draft-ietf-dmm-ondemand-mobility-08 --

[Dave Dolson]

Danny,
Please see inline [DD]

In general, I feel the specification of the programming API is incomplete, 
which may cause incompatibilities in different operating systems.
(I'm not concerned with the implementation specifics of communicating with the 
network, just the API.)

-Dave


From: Moses, Danny [mailto:danny.mo...@intel.com]
Sent: Wednesday, December 14, 2016 4:47 AM
To: Dave Dolson
Cc: draft-ietf-dmm-ondemand-mobil...@ietf.org; dmm@ietf.org
Subject: RE: WGLC for draft-ietf-dmm-ondemand-mobility-08 --

Hi,

I have fixed the two typos you indicated in the previous emails.
Please see my embedded reply.
I am waiting for you reply on my question below regarding the source code 
example comment before uploading rev 10.

Thanks for the useful comments,
Danny

From: Dave Dolson [mailto:ddol...@sandvine.com]
Sent: Thursday, December 08, 2016 21:00
To: Moses, Danny <danny.mo...@intel.com>
Cc: draft-ietf-dmm-ondemand-mobil...@ietf.org; dmm@ietf.org
Subject: WGLC for draft-ietf-dmm-ondemand-mobility-08 --

I'm just catching up on the recent drafts, so apologies if this has been 
covered...

1. It seems like RFC 6724 will need to be updated by dmm-ondemand-mobility.
I'm unclear on how the algorithm should be modified. Has anyone worked this out?
My sense is that Rule 4 needs to be modified to consider the new flags.
Either this document should spell out the new algorithm, or we plan for 
RFC6724bis.

DM>> This is probably true. I am adding an RFC6724 fix to my ToDo list which is 
quite long, so I hope someone else
Takes this work. If not, let's do this together in the future.
[DD] Question to the list: has anyone worked out a viable algorithm for 
selecting source address?

2. Regarding the language about IPV6_PREFER_SRC_HOME and IPV6_PREFER_SRC_COA
with legacy applications, I think it would be right to continue to support 
these.
PREFER_SRC_HOME could ask the network for FIXED, but automatically fall back to 
another address.
I think this is useful so that the application doesn't have to handle 
EAI_REQUIREDIPNOTSUPPORTED and try again.
(This comment goes back to point 1.)
DM>> First, for backwards compatibility, we must support these flags and the 
draft does not suggest otherwise. I prefer not to mix the functionality of the 
legacy flags - IPV6_PREFER_SRC_HOME and IPV6_PREFER_SRC_COA with the new flags 
defined in the OnDemand draft. The main reason is that the former flags are 
related to a MIP environment were the MN terminates the tunnel, while the 
OnDemand flags are related to a proxy MIP environment (PMIP or GTP - for 
example) were the MN is not aware of the mobility support.
[DD] OK, but the tone of the document, including use of the word "legacy" 
implies deprecation. There is even wording "Legacy applications ...  will not 
enjoy On-Demand Mobility feature." In contrast, I think that 
IPV6_PREFER_SRC_HOME should provide a home address when available.

3. I don't understand the need for IPV6_REQUIRE_NON-PERSISTENT_IP as an 
explicit flag.
I would think it works better to provide this behavior if neither of the other 
flags are set.
Literally it says, "I will not accept a FIXED or SESSION_LASTING IP". Is that 
useful?
It can be provided, but I don't think any app would use it. Maybe just for 
testing the network?
DM>> Actually, this flag is one of the main motivation for this work. It 
enables the application to explicitly request the network not to create a 
tunnel for the IP session and avoid the unnecessary overhead associated with 
the tunnel. Opening a socket without using any of these flags means that the 
application does not have a preference to the type of service it receives from 
the network and leave the decision of choosing the type of service to either 
the IP stack in the MN or the network. It is important to enable the 
application to explicitly request a non-persistent service (and to receive an 
error if this service is not supported).
[DD] But wearing the hat of a developer, why would my application ever request 
this, other than for network diagnostics? If I don't care for HOME address, I 
would just let the stack choose... Or is there some benefit to the 
non-persistent address that I'm missing?

4. Consider an appendix showing source code for clients and servers with 
different requirements.
E.g., I believe that the setsockopt() needs to be done after socket() but 
before bind(), connect(), send(), sendmsg(), sendmmsg(), sendto(),etc.
(After any packets are sent is too late.)
I think it would be useful to show this recipe.
DM>> Your description is correct. I am wondering what is better, to add a short 
paragraph describing when setsockopt() should be used (as you described) or 
adding source code example. I prefer the text to be short and clear, and 
whenever we add source code examples we either end up with a long example, or 
limit ourselves to some obvious example that does not address all alternatives. 
Will

Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08 --

[Moses, Danny]

Hi,

I have fixed the two typos you indicated in the previous emails.
Please see my embedded reply.
I am waiting for you reply on my question below regarding the source code 
example comment before uploading rev 10.

Thanks for the useful comments,
Danny

From: Dave Dolson [mailto:ddol...@sandvine.com]
Sent: Thursday, December 08, 2016 21:00
To: Moses, Danny 
Cc: draft-ietf-dmm-ondemand-mobil...@ietf.org; dmm@ietf.org
Subject: WGLC for draft-ietf-dmm-ondemand-mobility-08 --

I'm just catching up on the recent drafts, so apologies if this has been 
covered...

1. It seems like RFC 6724 will need to be updated by dmm-ondemand-mobility.
I'm unclear on how the algorithm should be modified. Has anyone worked this out?
My sense is that Rule 4 needs to be modified to consider the new flags.
Either this document should spell out the new algorithm, or we plan for 
RFC6724bis.

DM>> This is probably true. I am adding an RFC6724 fix to my ToDo list which is 
quite long, so I hope someone else
Takes this work. If not, let's do this together in the future.

2. Regarding the language about IPV6_PREFER_SRC_HOME and IPV6_PREFER_SRC_COA
with legacy applications, I think it would be right to continue to support 
these.
PREFER_SRC_HOME could ask the network for FIXED, but automatically fall back to 
another address.
I think this is useful so that the application doesn't have to handle 
EAI_REQUIREDIPNOTSUPPORTED and try again.
(This comment goes back to point 1.)
DM>> First, for backwards compatibility, we must support these flags and the 
draft does not suggest otherwise. I prefer not to mix the functionality of the 
legacy flags - IPV6_PREFER_SRC_HOME and IPV6_PREFER_SRC_COA with the new flags 
defined in the OnDemand draft. The main reason is that the former flags are 
related to a MIP environment were the MN terminates the tunnel, while the 
OnDemand flags are related to a proxy MIP environment (PMIP or GTP - for 
example) were the MN is not aware of the mobility support.

3. I don't understand the need for IPV6_REQUIRE_NON-PERSISTENT_IP as an 
explicit flag.
I would think it works better to provide this behavior if neither of the other 
flags are set.
Literally it says, "I will not accept a FIXED or SESSION_LASTING IP". Is that 
useful?
It can be provided, but I don't think any app would use it. Maybe just for 
testing the network?
DM>> Actually, this flag is one of the main motivation for this work. It 
enables the application to explicitly request the network not to create a 
tunnel for the IP session and avoid the unnecessary overhead associated with 
the tunnel. Opening a socket without using any of these flags means that the 
application does not have a preference to the type of service it receives from 
the network and leave the decision of choosing the type of service to either 
the IP stack in the MN or the network. It is important to enable the 
application to explicitly request a non-persistent service (and to receive an 
error if this service is not supported).

4. Consider an appendix showing source code for clients and servers with 
different requirements.
E.g., I believe that the setsockopt() needs to be done after socket() but 
before bind(), connect(), send(), sendmsg(), sendmmsg(), sendto(),etc.
(After any packets are sent is too late.)
I think it would be useful to show this recipe.
DM>> Your description is correct. I am wondering what is better, to add a short 
paragraph describing when setsockopt() should be used (as you described) or 
adding source code example. I prefer the text to be short and clear, and 
whenever we add source code examples we either end up with a long example, or 
limit ourselves to some obvious example that does not address all alternatives. 
Will adding the clarification that you pointed out be sufficient?

5. Are there new errors from bind(), listen() or connect(), etc.?
E.g., socket option is FIXED, but user explicitly specified a COA address to 
bind to?
DM>> We considered this, but decided not to go there since we would have to 
think of all the possible erroneous combination and programmer might do. We 
therefore, decided to clearly state that such behavior would be ignored.



David Dolson
Senior Software Architect, Sandvine Inc.

-
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 for draft-ietf-dmm-ondemand-mobility-08 --

[Moses, Danny]

Oops,

Sorry but I missed this email. Sorry.

I will review the comments and if needed, will upload another version.
Hope to complete the work by tomorrow.

Regards,
Danny

From: Dave Dolson [mailto:ddol...@sandvine.com]
Sent: Thursday, December 08, 2016 21:00
To: Moses, Danny 
Cc: draft-ietf-dmm-ondemand-mobil...@ietf.org; dmm@ietf.org
Subject: WGLC for draft-ietf-dmm-ondemand-mobility-08 --

I'm just catching up on the recent drafts, so apologies if this has been 
covered...

1. It seems like RFC 6724 will need to be updated by dmm-ondemand-mobility.
I'm unclear on how the algorithm should be modified. Has anyone worked this out?
My sense is that Rule 4 needs to be modified to consider the new flags.
Either this document should spell out the new algorithm, or we plan for 
RFC6724bis.

2. Regarding the language about IPV6_PREFER_SRC_HOME and IPV6_PREFER_SRC_COA
with legacy applications, I think it would be right to continue to support 
these.
PREFER_SRC_HOME could ask the network for FIXED, but automatically fall back to 
another address.
I think this is useful so that the application doesn't have to handle 
EAI_REQUIREDIPNOTSUPPORTED and try again.
(This comment goes back to point 1.)

3. I don't understand the need for IPV6_REQUIRE_NON-PERSISTENT_IP as an 
explicit flag.
I would think it works better to provide this behavior if neither of the other 
flags are set.
Literally it says, "I will not accept a FIXED or SESSION_LASTING IP". Is that 
useful?
It can be provided, but I don't think any app would use it. Maybe just for 
testing the network?

4. Consider an appendix showing source code for clients and servers with 
different requirements.
E.g., I believe that the setsockopt() needs to be done after socket() but 
before bind(), connect(), send(), sendmsg(), sendmmsg(), sendto(),etc.
(After any packets are sent is too late.)
I think it would be useful to show this recipe.

5. Are there new errors from bind(), listen() or connect(), etc.?
E.g., socket option is FIXED, but user explicitly specified a COA address to 
bind to?



David Dolson
Senior Software Architect, Sandvine Inc.

-
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 for draft-ietf-dmm-ondemand-mobility-08

[Moses, Danny]

Hi Lorenzo,

OK, I can accept the text you proposed. I might add a disclaimer indicating 
that the exact interaction between the MN’s IP stack and the network is outside 
the scope of this draft in order to avoid a new discussion by people who might 
object the term ‘prefix’.

Regarding your question about the IPV6_REQUIRED_SRC_ON_NET flag, I will let 
Seil discuss with you. I would like to point out, however, that in the last DMM 
session, the WG voted to merge the draft that defined this flag with the 
OnDemand draft which had completed WGLC several week ago. This is the reason 
for the new version 08 of the OnDemand draft. I was not in the room during the 
discussion, but understood from the chair that there was a strong consensus for 
this merge.

I will generate a version 09, which hopefully address you concerns.

Regards,
Danny

From: Lorenzo Colitti [mailto:lore...@google.com]
Sent: Tuesday, December 06, 2016 17:20
To: Moses, Danny <danny.mo...@intel.com>
Cc: Peter McCann <peter.mcc...@huawei.com>; jouni.nospam 
<jouni.nos...@gmail.com>; draft-ietf-dmm-ondemand-mobil...@ietf.org; 
dmm@ietf.org
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

Danny,

I don't think assigning addresses vs. assigning prefixes is a question only of 
mechanism.

For example, consider the IPV6_REQUIRE_SRC_ON_NET flag. If the network is 
following IP addressing best practices, I don't see a need for it. If a host 
already has an IPv6 address of the desired type, what's the point of sending a 
request to the network to obtain one? Is it so that the requesting app can 
obtain a new IP address with the desired properties, unique to that particular 
socket? But if so, the host should just create a new address for that socket, 
with the desired properties. The network should not be requiring that the host 
ask for individual IP addresses; it should be allowing the host to form more IP 
addresses without requesting them.

In any case: since the socket options defined in this draft are IPv6-only, it 
only needs to concern itself with IPv6, and we're really only left with one 
case: a prefix. If so, how about the following?


When the IP stack is required to use a source IP address of a specific type, it 
can perform one of the following: it can use an existing address with the 
desired type (if it has one), or it can create a new one from an existing 
prefix of the desired type. If the host does not already have an IPv6 prefix of 
the specific type, it can request one from the network.

Using an address from an existing prefix is faster but might yield a less 
optimal route (if a hand-off event occurred since its configuration), on the 
other hand, acquiring a new IP prefix from the network may take some time (due 
to signaling exchange with the network) and may fail due to network policies.


Cheers,
Lorenzo

On Tue, Dec 6, 2016 at 9:27 PM, Moses, Danny 
<danny.mo...@intel.com<mailto:danny.mo...@intel.com>> wrote:
Firstly, I agree that the only two examples of ‘resource’ type that may result 
with a creation of a source IP address are (i) an IP address and (ii) an IP 
prefix. I cannot think of any other magic, but perhaps some else can…

I am trying to avoid the term ‘prefix’ because it is not directly related to 
the Socket interface and I am trying to separate the definitions related to the 
Socket interface from the definitions related to the interaction between the MN 
and network.

If I mention prefixes, I will have to explain that the network may allocate IP 
addresses or IP sockets and that in cellular networks the recommended mechanism 
is to allocate /64 prefixes… I do not want to get into these details because 
they are not helpful for Socket API users.

However, I do intend to get into these details (and refer to the recommendation 
of RFC 7934) in the drafts that describe the extensions required to convey the 
IP service type between the IP stack in the MN and the network.

From: Lorenzo Colitti [mailto:lore...@google.com<mailto:lore...@google.com>]
Sent: Tuesday, December 06, 2016 13:43
To: Moses, Danny <danny.mo...@intel.com<mailto:danny.mo...@intel.com>>
Cc: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>>; 
jouni.nospam <jouni.nos...@gmail.com<mailto:jouni.nos...@gmail.com>>; 
draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>;
 dmm@ietf.org<mailto:dmm@ietf.org>
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

On Mon, Dec 5, 2016 at 9:50 AM, Moses, Danny 
<danny.mo...@intel.com<mailto:danny.mo...@intel.com>> wrote:
I think it is important to describe that application developer can influence 
the type of service the IP session is receiving, while being vague about the 
mechanism of address allocation. Since you are concern with the draft using the 
term ‘address’ and I am concern with using the term ‘prefix’, I tried

Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

[Seil Jeon]

Hi Lorenzo,

 

You can find my comments inline.

 

Regards,

Seil Jeon

 

From: Lorenzo Colitti [mailto:lore...@google.com] 
Sent: Wednesday, December 07, 2016 1:01 PM
To: Seil Jeon <seilj...@gmail.com>
Cc: dmm@ietf.org; Moses, Danny <danny.mo...@intel.com>; Peter McCann 
<peter.mcc...@huawei.com>; john.kaippallima...@huawei.com
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

 

Seil Jeon,

 

I'm not sure I understand. The draft implies that IPV6_REQUIRE_SRC_ON_NET 
forces the device to talk to the network even if it already has a prefix from 
the current network. Why do this?

 

No. it doesn’t force to the IP stack. It is just telling what additional 
requirement of the application to the IP stack. If the stack has it from the 
current serving network, the best-matched one will be used. Or, it will request 
a new one.

 

Suppose the following sequence of events occurs.

1.  The device has a mobile (e.g., session-lasting) IPv6 prefix only.
2.  The device moves to a new attachment point and its only prefix (and 
only IP addresses) are now subject to suboptimal latency.
3.  An application wants to use an IPv6 address from the local network, in 
order to minimize latency.
4.  The device does not have a local prefix assigned by the local network, 
so it gets a local prefix from the network. This takes 1-2 seconds.
5.  100ms later, another application wants to use an IPv6 address from the 
local network.

At point 5, it is much more faster for the host to say, "I already have a 
prefix from the local network, I will just create a new address from that 
prefix" than to talk to the network.

 

I’m not sure what local prefix you mean. I don’t know what default policy to 
assign an IPv6 prefix to the host in your scenario. But if you mean the local 
prefix as session-lasting IP prefix, once the IP stack gets the prefix at step 
4, it will not need step 5.

 

In step 4, the local prefix could be non-persistent IP address, not 
session-lasting IP address. And suppose one or more session-lasting IP 
addresses are already existing in the stack. Then, a new application requiring 
on-net property will need a session-lasting IP prefix from the current serving 
network.

 

The purpose of the on-net property is to help an application get a prefix 
assigned from the current serving network.

 

 

 

Is IPV6_REQUIRE_SRC_ON_NET defined because at step 2, the device does not know 
it has moved?

 

This draft doesn’t talk about any mobility protocol, but just dealing with how 
application’s IP address requirement can be delivered to the IP stack. The 
on-net API also belongs to the same goal.

 

 

 

Regards,

Lorenzo

 

On Wed, Dec 7, 2016 at 12:42 PM, Seil Jeon <seilj...@gmail.com 
<mailto:seilj...@gmail.com> > wrote:

Hi Lorenzo,

 

Please see inline.

 

Regards,

Seil Jeon

 

From: dmm [mailto:dmm-boun...@ietf.org <mailto:dmm-boun...@ietf.org> ] On 
Behalf Of Lorenzo Colitti
Sent: Wednesday, December 07, 2016 12:20 AM
To: Moses, Danny <danny.mo...@intel.com <mailto:danny.mo...@intel.com> >
Cc: draft-ietf-dmm-ondemand-mobil...@ietf.org 
<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org> ; Peter McCann 
<peter.mcc...@huawei.com <mailto:peter.mcc...@huawei.com> >; dmm@ietf.org 
<mailto:dmm@ietf.org> 
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

 

Danny,

 

I don't think assigning addresses vs. assigning prefixes is a question only of 
mechanism.

 

For example, consider the IPV6_REQUIRE_SRC_ON_NET flag. If the network is 
following IP addressing best practices, I don't see a need for it. If a host 
already has an IPv6 address of the desired type, what's the point of sending a 
request to the network to obtain one?

 

The reason is well described in  
<https://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-05> 
https://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-05 like 
following

 

Acquiring a new session-lasting IP address may take some

   time (due to the exchange with the network) while using an existing

   one is instantaneous.  On the other hand, using the existing one

   might yield less optimal routing.  For example, the use of the IP

   address with an existing one configured might provide a suboptimal

   routing path as a result of a handover.  This situation might not be

   preferred by newly initiated applications because the application

   incurs the costs of IP mobility even though the MN has not moved from

   the current serving network.  Eventually, the new session is served

   by a remote IP mobility anchor with mobility management functions,

   though the MN has not moved yet.

 

Is it so that the requesting app can obtain a new IP address with the desired 
properties, unique to that particular socket? But if so, the host should just 
create a new address for that socket, with the desired properties. The ne

Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

[Peter McCann]

An explicit DHCP exchange (maybe for just a prefix) seems like the cleanest 
approach and the assignment state machine is properly decoupled from the state 
of the link.  However, many people seem to prefer SLAAC (almost religiously) so 
the tracking of used addresses plus NUD after some timeout is what we settled 
on in prefixcost.

Sent from HUAWEI AnyOffice
From:Moses, Danny
To:Peter McCann,Lorenzo Colitti
Cc:draft-ietf-dmm-ondemand-mobil...@ietf.org,dmm@ietf.org
Date:2016-12-06 06:02:48
Subject:RE: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

Well, although the network allocates prefixes it could keep track of addresses 
that were constructed from those prefixes and initiate NUD on these addresses…

Personally, I don’t believe in designs that rely on MNs to volunteer to provide 
such information. The better approach is to have a finite lease time for 
prefixes (like DHCP does) and force the MN to request lease extensions – if 
they required.

Could that be a reasonable approach?

Danny

From: Peter McCann [mailto:peter.mcc...@huawei.com]
Sent: Monday, December 05, 2016 21:02
To: Moses, Danny <danny.mo...@intel.com>; Lorenzo Colitti <lore...@google.com>
Cc: draft-ietf-dmm-ondemand-mobil...@ietf.org; dmm@ietf.org
Subject: RE: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

In the prefixcost draft, we handwaved a solution that would keep soft state in 
the network and have the network initiate NUD when it hadn’t seen a given 
address being used by the MN for a while.  However, NUD only works on 
individual addresses not whole prefixes.  It might be good to have an explicit 
message from a MN that says “I am done using this prefix” but this problem is 
bigger than DMM.  I am not sure what is the right solution.

-Pete


From: Moses, Danny [mailto:danny.mo...@intel.com]
Sent: Monday, December 05, 2016 1:01 PM
To: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>>; 
Lorenzo Colitti <lore...@google.com<mailto:lore...@google.com>>
Cc: 
draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>;
 dmm@ietf.org<mailto:dmm@ietf.org>
Subject: RE: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

That is correct.

Do we need a draft about freeing addresses/prefixes?

Regards,
Danny

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Peter McCann
Sent: Monday, December 05, 2016 17:43
To: Lorenzo Colitti <lore...@google.com<mailto:lore...@google.com>>
Cc: 
draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>;
 dmm@ietf.org<mailto:dmm@ietf.org>
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

That may work for communicating the allocation state of the prefix to the MN, 
but too frequent advertisements may chew up precious wireless bandwidth.  Also, 
it doesn’t solve the problem of allowing the network to detect when the MN is 
done using the prefix.

-Pete


From: Lorenzo Colitti [mailto:lore...@google.com]
Sent: Sunday, December 04, 2016 9:21 PM
To: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>>
Cc: jouni.nospam <jouni.nos...@gmail.com<mailto:jouni.nos...@gmail.com>>; 
draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>;
 dmm@ietf.org<mailto:dmm@ietf.org>
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

Agreed; if we want to support this sort of mobility it needs to be possible to 
tell a MN that its previous prefix is no longer valid.

>From a technical perspective this can be done using router advertisements, 
>except for the 2-hour rule in RFC 4862 section 5.3.3. That rule exists to 
>prevent DOS attacks on shared links, so I think it would be reasonable to 
>update RFC 4862 to say that less-than-2-hour valid lifetimes are acceptable if 
>the link provides strong guarantees that there are no other nodes on link that 
>can mount such an attack.

On Fri, Dec 2, 2016 at 12:36 PM, Peter McCann 
<peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> wrote:
Agree, I am not arguing in favor of sharing a prefix between two or more MNs at 
the same time.  However, I think it is important to reclaim a prefix for use by 
another MN after the current MN has moved to a new attachment point and stopped 
using the prefix it got from the old attachment point.   It is also important 
to refrain from advertising the prefix to another MN until the current MN has 
stopped using it.  That is the network state I am talking about.

-Pete


From: Lorenzo Colitti [mailto:lore...@google.com<mailto:lore...@google.com>]
Sent: Friday, December 02, 2016 3:32 PM

To: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>>
Cc: jouni.nospam <jouni.nos...@gmail.com<mailto:jouni.nos...@gmail.com>>; 
draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-

Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

[Peter McCann]

The problem with using link status is that the MN may want to keep the prefix 
even after it has moved off link.  It may also break the other way: the MN 
wants to give up the prefix while it stays on link.  We need to decouple the 
prefix assignment from the link status.

Sent from HUAWEI AnyOffice
From:Lorenzo Colitti
To:Peter McCann
Cc:Moses, Danny,draft-ietf-dmm-ondemand-mobil...@ietf.org,dmm@ietf.org
Date:2016-12-06 06:43:31
Subject:Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

The network can't do NUD for a prefix, but it can do NUD for the link-local 
IPv6 address that sent the RS that caused it to announce the prefix.

Even better would be to make it the responsibility of the link layer to let the 
network know if the MN is still attached. Most link layers used in mobile 
networks have to do this anyway.

On Mon, Dec 5, 2016 at 11:02 AM, Peter McCann 
<peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> wrote:
In the prefixcost draft, we handwaved a solution that would keep soft state in 
the network and have the network initiate NUD when it hadn’t seen a given 
address being used by the MN for a while.  However, NUD only works on 
individual addresses not whole prefixes.  It might be good to have an explicit 
message from a MN that says “I am done using this prefix” but this problem is 
bigger than DMM.  I am not sure what is the right solution.

-Pete


From: Moses, Danny [mailto:danny.mo...@intel.com<mailto:danny.mo...@intel.com>]
Sent: Monday, December 05, 2016 1:01 PM
To: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>>; 
Lorenzo Colitti <lore...@google.com<mailto:lore...@google.com>>
Cc: 
draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>;
 dmm@ietf.org<mailto:dmm@ietf.org>
Subject: RE: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

That is correct.

Do we need a draft about freeing addresses/prefixes?

Regards,
Danny

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Peter McCann
Sent: Monday, December 05, 2016 17:43
To: Lorenzo Colitti <lore...@google.com<mailto:lore...@google.com>>
Cc: 
draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>;
 dmm@ietf.org<mailto:dmm@ietf.org>
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

That may work for communicating the allocation state of the prefix to the MN, 
but too frequent advertisements may chew up precious wireless bandwidth.  Also, 
it doesn’t solve the problem of allowing the network to detect when the MN is 
done using the prefix.

-Pete


From: Lorenzo Colitti [mailto:lore...@google.com]
Sent: Sunday, December 04, 2016 9:21 PM
To: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>>
Cc: jouni.nospam <jouni.nos...@gmail.com<mailto:jouni.nos...@gmail.com>>; 
draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>;
 dmm@ietf.org<mailto:dmm@ietf.org>
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

Agreed; if we want to support this sort of mobility it needs to be possible to 
tell a MN that its previous prefix is no longer valid.

>From a technical perspective this can be done using router advertisements, 
>except for the 2-hour rule in RFC 4862 section 5.3.3. That rule exists to 
>prevent DOS attacks on shared links, so I think it would be reasonable to 
>update RFC 4862 to say that less-than-2-hour valid lifetimes are acceptable if 
>the link provides strong guarantees that there are no other nodes on link that 
>can mount such an attack.

On Fri, Dec 2, 2016 at 12:36 PM, Peter McCann 
<peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> wrote:
Agree, I am not arguing in favor of sharing a prefix between two or more MNs at 
the same time.  However, I think it is important to reclaim a prefix for use by 
another MN after the current MN has moved to a new attachment point and stopped 
using the prefix it got from the old attachment point.   It is also important 
to refrain from advertising the prefix to another MN until the current MN has 
stopped using it.  That is the network state I am talking about.

-Pete


From: Lorenzo Colitti [mailto:lore...@google.com<mailto:lore...@google.com>]
Sent: Friday, December 02, 2016 3:32 PM

To: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>>
Cc: jouni.nospam <jouni.nos...@gmail.com<mailto:jouni.nos...@gmail.com>>; 
draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>;
 dmm@ietf.org<mailto:dmm@ietf.org>
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

On the particular case of shared links: note that they have substantial 
scalability and performance issues. In order for shared links to work you have 
to engage in DAD proxying, ND 

Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

[Seil Jeon]

Hi Lorenzo,

 

Please see inline.

 

Regards,

Seil Jeon

 

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Lorenzo Colitti
Sent: Wednesday, December 07, 2016 12:20 AM
To: Moses, Danny <danny.mo...@intel.com>
Cc: draft-ietf-dmm-ondemand-mobil...@ietf.org; Peter McCann 
<peter.mcc...@huawei.com>; dmm@ietf.org
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

 

Danny,

 

I don't think assigning addresses vs. assigning prefixes is a question only of 
mechanism.

 

For example, consider the IPV6_REQUIRE_SRC_ON_NET flag. If the network is 
following IP addressing best practices, I don't see a need for it. If a host 
already has an IPv6 address of the desired type, what's the point of sending a 
request to the network to obtain one?

 

The reason is well described in  
<https://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-05> 
https://tools.ietf.org/html/draft-sijeon-dmm-use-cases-api-source-05 like 
following

 

Acquiring a new session-lasting IP address may take some

   time (due to the exchange with the network) while using an existing

   one is instantaneous.  On the other hand, using the existing one

   might yield less optimal routing.  For example, the use of the IP

   address with an existing one configured might provide a suboptimal

   routing path as a result of a handover.  This situation might not be

   preferred by newly initiated applications because the application

   incurs the costs of IP mobility even though the MN has not moved from

   the current serving network.  Eventually, the new session is served

   by a remote IP mobility anchor with mobility management functions,

   though the MN has not moved yet.

 

Is it so that the requesting app can obtain a new IP address with the desired 
properties, unique to that particular socket? But if so, the host should just 
create a new address for that socket, with the desired properties. The network 
should not be requiring that the host ask for individual IP addresses; it 
should be allowing the host to form more IP addresses without requesting them.

 

In any case: since the socket options defined in this draft are IPv6-only, it 
only needs to concern itself with IPv6, and we're really only left with one 
case: a prefix. If so, how about the following?

 

“By issuing a request to the network” you pointed out in the previous mails has 
been described as the on demand nature for a long time in [I-D. 
draft-ietf-dmm-ondemand-mobility]. If it is an issue INDEED, it needs to be 
revised not with individual address but with prefix. Would it be better?

 

Second, from your text, the reason to use the proposed API is not to use the 
address based on the same prefix. “Creating a new one from an existing prefix 
of the desired type” is away from the intention.

 



When the IP stack is required to use a source IP address of a specific type, it 
can perform one of the following: it can use an existing address with the 
desired type (if it has one), or it can create a new one from an existing 
prefix of the desired type. If the host does not already have an IPv6 prefix of 
the specific type, it can request one from the network.

 

Using an address from an existing prefix is faster but might yield a less 
optimal route (if a hand-off event occurred since its configuration), on the 
other hand, acquiring a new IP prefix from the network may take some time (due 
to signaling exchange with the network) and may fail due to network policies.



 

 

 

 

 

Cheers,

Lorenzo

 

On Tue, Dec 6, 2016 at 9:27 PM, Moses, Danny <danny.mo...@intel.com 
<mailto:danny.mo...@intel.com> > wrote:

Firstly, I agree that the only two examples of ‘resource’ type that may result 
with a creation of a source IP address are (i) an IP address and (ii) an IP 
prefix. I cannot think of any other magic, but perhaps some else can…

 

I am trying to avoid the term ‘prefix’ because it is not directly related to 
the Socket interface and I am trying to separate the definitions related to the 
Socket interface from the definitions related to the interaction between the MN 
and network.

 

If I mention prefixes, I will have to explain that the network may allocate IP 
addresses or IP sockets and that in cellular networks the recommended mechanism 
is to allocate /64 prefixes… I do not want to get into these details because 
they are not helpful for Socket API users.

 

However, I do intend to get into these details (and refer to the recommendation 
of RFC 7934) in the drafts that describe the extensions required to convey the 
IP service type between the IP stack in the MN and the network. 

 

From: Lorenzo Colitti [mailto: <mailto:lore...@google.com> lore...@google.com] 
Sent: Tuesday, December 06, 2016 13:43
To: Moses, Danny < <mailto:danny.mo...@intel.com> danny.mo...@intel.com>
Cc: Peter McCann < <mailto:peter.mcc...@huawei.com> peter.mcc...@huawei.com>

Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

[Lorenzo Colitti]

Danny,

I don't think assigning addresses vs. assigning prefixes is a question only
of mechanism.

For example, consider the IPV6_REQUIRE_SRC_ON_NET flag. If the network is
following IP addressing best practices, I don't see a need for it. If a
host already has an IPv6 address of the desired type, what's the point of
sending a request to the network to obtain one? Is it so that the
requesting app can obtain a new IP address with the desired properties,
unique to that particular socket? But if so, the host should just create a
new address for that socket, with the desired properties. The network
should not be requiring that the host ask for individual IP addresses; it
should be allowing the host to form more IP addresses without requesting
them.

In any case: since the socket options defined in this draft are IPv6-only,
it only needs to concern itself with IPv6, and we're really only left with
one case: a prefix. If so, how about the following?


When the IP stack is required to use a source IP address of a specific
type, it can perform one of the following: it can use an existing address
with the desired type (if it has one), or it can create a new one from an
existing prefix of the desired type. If the host does not already have an
IPv6 prefix of the specific type, it can request one from the network.

Using an address from an existing prefix is faster but might yield a less
optimal route (if a hand-off event occurred since its configuration), on
the other hand, acquiring a new IP prefix from the network may take some
time (due to signaling exchange with the network) and may fail due to
network policies.


Cheers,
Lorenzo

On Tue, Dec 6, 2016 at 9:27 PM, Moses, Danny <danny.mo...@intel.com> wrote:

> Firstly, I agree that the only two examples of ‘resource’ type that may
> result with a creation of a source IP address are (i) an IP address and
> (ii) an IP prefix. I cannot think of any other magic, but perhaps some else
> can…
>
>
>
> I am trying to avoid the term ‘prefix’ because it is not directly related
> to the Socket interface and I am trying to separate the definitions related
> to the Socket interface from the definitions related to the interaction
> between the MN and network.
>
>
>
> If I mention prefixes, I will have to explain that the network may
> allocate IP addresses or IP sockets and that in cellular networks the
> recommended mechanism is to allocate /64 prefixes… I do not want to get
> into these details because they are not helpful for Socket API users.
>
>
>
> However, I do intend to get into these details (and refer to the
> recommendation of RFC 7934) in the drafts that describe the extensions
> required to convey the IP service type between the IP stack in the MN and
> the network.
>
>
>
> *From:* Lorenzo Colitti [mailto:lore...@google.com]
> *Sent:* Tuesday, December 06, 2016 13:43
> *To:* Moses, Danny <danny.mo...@intel.com>
> *Cc:* Peter McCann <peter.mcc...@huawei.com>; jouni.nospam <
> jouni.nos...@gmail.com>; draft-ietf-dmm-ondemand-mobil...@ietf.org;
> dmm@ietf.org
> *Subject:* Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08
>
>
>
> On Mon, Dec 5, 2016 at 9:50 AM, Moses, Danny <danny.mo...@intel.com>
> wrote:
>
> I think it is important to describe that application developer can
> influence the type of service the IP session is receiving, while being
> vague about the mechanism of address allocation. Since you are concern with
> the draft using the term ‘address’ and I am concern with using the term
> ‘prefix’, I tried using the term ‘network resources’. Yes, it is vague, but
> that is the intention.
>
>
>
> Ok, but what other type of resource can result in the MN being able to use
> an IP address? It seems to me that only an IP address or a prefix will
> qualify. And if allocating address on request is recommended, then that
> only leaves a prefix.
>
>
>
> If there are other types of resource that I'm missing, then "resource"
> might be OK, as long as it has appropriate examples. But if the only two
> options are "address" and "prefix" and "address" is not recommended, then
> saying "resource" is at best unhelpful and at worst misleading.
>
>
>
> Can you explain why you are concerned with using the term "prefix"?
>
> -
> 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 for draft-ietf-dmm-ondemand-mobility-08

[Moses, Danny]

Well, although the network allocates prefixes it could keep track of addresses 
that were constructed from those prefixes and initiate NUD on these addresses…

Personally, I don’t believe in designs that rely on MNs to volunteer to provide 
such information. The better approach is to have a finite lease time for 
prefixes (like DHCP does) and force the MN to request lease extensions – if 
they required.

Could that be a reasonable approach?

Danny

From: Peter McCann [mailto:peter.mcc...@huawei.com]
Sent: Monday, December 05, 2016 21:02
To: Moses, Danny <danny.mo...@intel.com>; Lorenzo Colitti <lore...@google.com>
Cc: draft-ietf-dmm-ondemand-mobil...@ietf.org; dmm@ietf.org
Subject: RE: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

In the prefixcost draft, we handwaved a solution that would keep soft state in 
the network and have the network initiate NUD when it hadn’t seen a given 
address being used by the MN for a while.  However, NUD only works on 
individual addresses not whole prefixes.  It might be good to have an explicit 
message from a MN that says “I am done using this prefix” but this problem is 
bigger than DMM.  I am not sure what is the right solution.

-Pete


From: Moses, Danny [mailto:danny.mo...@intel.com]
Sent: Monday, December 05, 2016 1:01 PM
To: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>>; 
Lorenzo Colitti <lore...@google.com<mailto:lore...@google.com>>
Cc: 
draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>;
 dmm@ietf.org<mailto:dmm@ietf.org>
Subject: RE: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

That is correct.

Do we need a draft about freeing addresses/prefixes?

Regards,
Danny

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Peter McCann
Sent: Monday, December 05, 2016 17:43
To: Lorenzo Colitti <lore...@google.com<mailto:lore...@google.com>>
Cc: 
draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>;
 dmm@ietf.org<mailto:dmm@ietf.org>
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

That may work for communicating the allocation state of the prefix to the MN, 
but too frequent advertisements may chew up precious wireless bandwidth.  Also, 
it doesn’t solve the problem of allowing the network to detect when the MN is 
done using the prefix.

-Pete


From: Lorenzo Colitti [mailto:lore...@google.com]
Sent: Sunday, December 04, 2016 9:21 PM
To: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>>
Cc: jouni.nospam <jouni.nos...@gmail.com<mailto:jouni.nos...@gmail.com>>; 
draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>;
 dmm@ietf.org<mailto:dmm@ietf.org>
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

Agreed; if we want to support this sort of mobility it needs to be possible to 
tell a MN that its previous prefix is no longer valid.

From a technical perspective this can be done using router advertisements, 
except for the 2-hour rule in RFC 4862 section 5.3.3. That rule exists to 
prevent DOS attacks on shared links, so I think it would be reasonable to 
update RFC 4862 to say that less-than-2-hour valid lifetimes are acceptable if 
the link provides strong guarantees that there are no other nodes on link that 
can mount such an attack.

On Fri, Dec 2, 2016 at 12:36 PM, Peter McCann 
<peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> wrote:
Agree, I am not arguing in favor of sharing a prefix between two or more MNs at 
the same time.  However, I think it is important to reclaim a prefix for use by 
another MN after the current MN has moved to a new attachment point and stopped 
using the prefix it got from the old attachment point.   It is also important 
to refrain from advertising the prefix to another MN until the current MN has 
stopped using it.  That is the network state I am talking about.

-Pete


From: Lorenzo Colitti [mailto:lore...@google.com<mailto:lore...@google.com>]
Sent: Friday, December 02, 2016 3:32 PM

To: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>>
Cc: jouni.nospam <jouni.nos...@gmail.com<mailto:jouni.nos...@gmail.com>>; 
draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>;
 dmm@ietf.org<mailto:dmm@ietf.org>
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

On the particular case of shared links: note that they have substantial 
scalability and performance issues. In order for shared links to work you have 
to engage in DAD proxying, ND snooping, client isolation and all sorts of 
unsavoury and L2/L3 magic that does not scale. Some of these issues are 
described in RFC 7934 section 9.3. On shared links, these forces act to reduce 
the number of IP addresses per host that the network can support a

Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

[Peter McCann]

In the prefixcost draft, we handwaved a solution that would keep soft state in 
the network and have the network initiate NUD when it hadn’t seen a given 
address being used by the MN for a while.  However, NUD only works on 
individual addresses not whole prefixes.  It might be good to have an explicit 
message from a MN that says “I am done using this prefix” but this problem is 
bigger than DMM.  I am not sure what is the right solution.

-Pete


From: Moses, Danny [mailto:danny.mo...@intel.com]
Sent: Monday, December 05, 2016 1:01 PM
To: Peter McCann <peter.mcc...@huawei.com>; Lorenzo Colitti <lore...@google.com>
Cc: draft-ietf-dmm-ondemand-mobil...@ietf.org; dmm@ietf.org
Subject: RE: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

That is correct.

Do we need a draft about freeing addresses/prefixes?

Regards,
Danny

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Peter McCann
Sent: Monday, December 05, 2016 17:43
To: Lorenzo Colitti <lore...@google.com<mailto:lore...@google.com>>
Cc: 
draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>;
 dmm@ietf.org<mailto:dmm@ietf.org>
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

That may work for communicating the allocation state of the prefix to the MN, 
but too frequent advertisements may chew up precious wireless bandwidth.  Also, 
it doesn’t solve the problem of allowing the network to detect when the MN is 
done using the prefix.

-Pete


From: Lorenzo Colitti [mailto:lore...@google.com]
Sent: Sunday, December 04, 2016 9:21 PM
To: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>>
Cc: jouni.nospam <jouni.nos...@gmail.com<mailto:jouni.nos...@gmail.com>>; 
draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>;
 dmm@ietf.org<mailto:dmm@ietf.org>
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

Agreed; if we want to support this sort of mobility it needs to be possible to 
tell a MN that its previous prefix is no longer valid.

From a technical perspective this can be done using router advertisements, 
except for the 2-hour rule in RFC 4862 section 5.3.3. That rule exists to 
prevent DOS attacks on shared links, so I think it would be reasonable to 
update RFC 4862 to say that less-than-2-hour valid lifetimes are acceptable if 
the link provides strong guarantees that there are no other nodes on link that 
can mount such an attack.

On Fri, Dec 2, 2016 at 12:36 PM, Peter McCann 
<peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> wrote:
Agree, I am not arguing in favor of sharing a prefix between two or more MNs at 
the same time.  However, I think it is important to reclaim a prefix for use by 
another MN after the current MN has moved to a new attachment point and stopped 
using the prefix it got from the old attachment point.   It is also important 
to refrain from advertising the prefix to another MN until the current MN has 
stopped using it.  That is the network state I am talking about.

-Pete


From: Lorenzo Colitti [mailto:lore...@google.com<mailto:lore...@google.com>]
Sent: Friday, December 02, 2016 3:32 PM

To: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>>
Cc: jouni.nospam <jouni.nos...@gmail.com<mailto:jouni.nos...@gmail.com>>; 
draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>;
 dmm@ietf.org<mailto:dmm@ietf.org>
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

On the particular case of shared links: note that they have substantial 
scalability and performance issues. In order for shared links to work you have 
to engage in DAD proxying, ND snooping, client isolation and all sorts of 
unsavoury and L2/L3 magic that does not scale. Some of these issues are 
described in RFC 7934 section 9.3. On shared links, these forces act to reduce 
the number of IP addresses per host that the network can support and leads to 
the negative consequences in section 4 of the document, which is why they are 
not recommended.

For these and other reasons, on many public networks we're seeing a shift 
*away* from shared links - see, for example, 
draft-ietf-v6ops-unique-ipv6-prefix-per-host , and the current large 
deployments of that model in the form of Comcast community wifi.

For many years 3GPP networks have been providing those benefits by providing a 
full /64 to every host. I would hate to lose those benefits.

On Fri, Dec 2, 2016 at 12:12 PM, Peter McCann 
<peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> wrote:
With a fixed access network the prefix can be assigned to the link and used by 
anyone who joins the link.

With a prefix offering mobility the prefix belongs to the mobile host and needs 
to move with it.  There aren’t enough prefixes (even in IPv6) to assign a 
permanent prefix t

Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

[Moses, Danny]

That is correct.

Do we need a draft about freeing addresses/prefixes?

Regards,
Danny

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Peter McCann
Sent: Monday, December 05, 2016 17:43
To: Lorenzo Colitti <lore...@google.com>
Cc: draft-ietf-dmm-ondemand-mobil...@ietf.org; dmm@ietf.org
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

That may work for communicating the allocation state of the prefix to the MN, 
but too frequent advertisements may chew up precious wireless bandwidth.  Also, 
it doesn’t solve the problem of allowing the network to detect when the MN is 
done using the prefix.

-Pete


From: Lorenzo Colitti [mailto:lore...@google.com]
Sent: Sunday, December 04, 2016 9:21 PM
To: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>>
Cc: jouni.nospam <jouni.nos...@gmail.com<mailto:jouni.nos...@gmail.com>>; 
draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>;
 dmm@ietf.org<mailto:dmm@ietf.org>
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

Agreed; if we want to support this sort of mobility it needs to be possible to 
tell a MN that its previous prefix is no longer valid.

From a technical perspective this can be done using router advertisements, 
except for the 2-hour rule in RFC 4862 section 5.3.3. That rule exists to 
prevent DOS attacks on shared links, so I think it would be reasonable to 
update RFC 4862 to say that less-than-2-hour valid lifetimes are acceptable if 
the link provides strong guarantees that there are no other nodes on link that 
can mount such an attack.

On Fri, Dec 2, 2016 at 12:36 PM, Peter McCann 
<peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> wrote:
Agree, I am not arguing in favor of sharing a prefix between two or more MNs at 
the same time.  However, I think it is important to reclaim a prefix for use by 
another MN after the current MN has moved to a new attachment point and stopped 
using the prefix it got from the old attachment point.   It is also important 
to refrain from advertising the prefix to another MN until the current MN has 
stopped using it.  That is the network state I am talking about.

-Pete


From: Lorenzo Colitti [mailto:lore...@google.com<mailto:lore...@google.com>]
Sent: Friday, December 02, 2016 3:32 PM

To: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>>
Cc: jouni.nospam <jouni.nos...@gmail.com<mailto:jouni.nos...@gmail.com>>; 
draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>;
 dmm@ietf.org<mailto:dmm@ietf.org>
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

On the particular case of shared links: note that they have substantial 
scalability and performance issues. In order for shared links to work you have 
to engage in DAD proxying, ND snooping, client isolation and all sorts of 
unsavoury and L2/L3 magic that does not scale. Some of these issues are 
described in RFC 7934 section 9.3. On shared links, these forces act to reduce 
the number of IP addresses per host that the network can support and leads to 
the negative consequences in section 4 of the document, which is why they are 
not recommended.

For these and other reasons, on many public networks we're seeing a shift 
*away* from shared links - see, for example, 
draft-ietf-v6ops-unique-ipv6-prefix-per-host , and the current large 
deployments of that model in the form of Comcast community wifi.

For many years 3GPP networks have been providing those benefits by providing a 
full /64 to every host. I would hate to lose those benefits.

On Fri, Dec 2, 2016 at 12:12 PM, Peter McCann 
<peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> wrote:
With a fixed access network the prefix can be assigned to the link and used by 
anyone who joins the link.

With a prefix offering mobility the prefix belongs to the mobile host and needs 
to move with it.  There aren’t enough prefixes (even in IPv6) to assign a 
permanent prefix to each UE for every topological attachment point that it 
might visit or start a session from.

-Pete


From: Lorenzo Colitti [mailto:lore...@google.com<mailto:lore...@google.com>]
Sent: Friday, December 02, 2016 3:09 PM
To: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>>
Cc: jouni.nospam <jouni.nos...@gmail.com<mailto:jouni.nos...@gmail.com>>; 
draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>;
 dmm@ietf.org<mailto:dmm@ietf.org>

Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

But you have that problem with IP addresses as well, right? I don't see how 
"assigning a prefix with certain properties" requires more state in the network 
than "assigning an IP address with certain properties".

On Fri, Dec 2, 2016 at 12:00

Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

[Peter McCann]

That may work for communicating the allocation state of the prefix to the MN, 
but too frequent advertisements may chew up precious wireless bandwidth.  Also, 
it doesn’t solve the problem of allowing the network to detect when the MN is 
done using the prefix.

-Pete


From: Lorenzo Colitti [mailto:lore...@google.com]
Sent: Sunday, December 04, 2016 9:21 PM
To: Peter McCann <peter.mcc...@huawei.com>
Cc: jouni.nospam <jouni.nos...@gmail.com>; 
draft-ietf-dmm-ondemand-mobil...@ietf.org; dmm@ietf.org
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

Agreed; if we want to support this sort of mobility it needs to be possible to 
tell a MN that its previous prefix is no longer valid.

From a technical perspective this can be done using router advertisements, 
except for the 2-hour rule in RFC 4862 section 5.3.3. That rule exists to 
prevent DOS attacks on shared links, so I think it would be reasonable to 
update RFC 4862 to say that less-than-2-hour valid lifetimes are acceptable if 
the link provides strong guarantees that there are no other nodes on link that 
can mount such an attack.

On Fri, Dec 2, 2016 at 12:36 PM, Peter McCann 
<peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> wrote:
Agree, I am not arguing in favor of sharing a prefix between two or more MNs at 
the same time.  However, I think it is important to reclaim a prefix for use by 
another MN after the current MN has moved to a new attachment point and stopped 
using the prefix it got from the old attachment point.   It is also important 
to refrain from advertising the prefix to another MN until the current MN has 
stopped using it.  That is the network state I am talking about.

-Pete


From: Lorenzo Colitti [mailto:lore...@google.com<mailto:lore...@google.com>]
Sent: Friday, December 02, 2016 3:32 PM

To: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>>
Cc: jouni.nospam <jouni.nos...@gmail.com<mailto:jouni.nos...@gmail.com>>; 
draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>;
 dmm@ietf.org<mailto:dmm@ietf.org>
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

On the particular case of shared links: note that they have substantial 
scalability and performance issues. In order for shared links to work you have 
to engage in DAD proxying, ND snooping, client isolation and all sorts of 
unsavoury and L2/L3 magic that does not scale. Some of these issues are 
described in RFC 7934 section 9.3. On shared links, these forces act to reduce 
the number of IP addresses per host that the network can support and leads to 
the negative consequences in section 4 of the document, which is why they are 
not recommended.

For these and other reasons, on many public networks we're seeing a shift 
*away* from shared links - see, for example, 
draft-ietf-v6ops-unique-ipv6-prefix-per-host , and the current large 
deployments of that model in the form of Comcast community wifi.

For many years 3GPP networks have been providing those benefits by providing a 
full /64 to every host. I would hate to lose those benefits.

On Fri, Dec 2, 2016 at 12:12 PM, Peter McCann 
<peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> wrote:
With a fixed access network the prefix can be assigned to the link and used by 
anyone who joins the link.

With a prefix offering mobility the prefix belongs to the mobile host and needs 
to move with it.  There aren’t enough prefixes (even in IPv6) to assign a 
permanent prefix to each UE for every topological attachment point that it 
might visit or start a session from.

-Pete


From: Lorenzo Colitti [mailto:lore...@google.com<mailto:lore...@google.com>]
Sent: Friday, December 02, 2016 3:09 PM
To: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>>
Cc: jouni.nospam <jouni.nos...@gmail.com<mailto:jouni.nos...@gmail.com>>; 
draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>;
 dmm@ietf.org<mailto:dmm@ietf.org>

Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

But you have that problem with IP addresses as well, right? I don't see how 
"assigning a prefix with certain properties" requires more state in the network 
than "assigning an IP address with certain properties".

On Fri, Dec 2, 2016 at 12:00 PM, Peter McCann 
<peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> wrote:
Providing any kind of mobility service for a prefix will require some state 
somewhere in the network.  It would be great to avoid an allocation request / 
response for the prefix, but the state has to be created somehow before the UE 
can use the prefix and it has to be reclaimed eventually after the UE stops 
using the prefix (which may not be until well after it disconnects from the 
current link and moves to another one).

Would 

Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

[Moses, Danny]

Hi Lorenzo,

The intent of this draft is to focus on the Socket API extensions and the 
interaction between applications and the IP stack running on the mobile host. 
Not to describe the interactions between the IP stack and the network.

My understanding is that as long as the draft maintains the above, your 
concerns should be satisfied.

I reviewed the draft once more and found (in addition to some typos which I’ll 
fix) a couple of places in section 3.4 – Conveying the Selection – that need to 
be modified in order to satisfy your concerns:


1. The paragraph before the definition of the IPV6_REQUIRE_SRC_ON_NET flag:
‘When the IP stack in required to assign a source IP address of a specified 
type, it can perform one of the following: It can assign a preconfigured 
address (if one exists) or request a new one from the network. Using an 
existing address is instantaneous but might yield a less optimal route (if a 
hand-off event occurs since its configuration), on the other hand, acquiring a 
new IP address from the network may take some time (due to signaling exchange 
with the network).’

I propose the following modifications:

i. Replace ‘… or request a new one from the 
network…’ to ‘… or configure a new one using new resources from the network…’

  ii. Replace ‘… acquiring a new IP address 
from the network may…’ with ‘… configuring a new one using new network 
resources may…’

The modified paragraph will be:

‘When the IP stack is required to assign a source IP address of a specific 
type, it can perform one of the following: It can assign a preconfigured 
address (if one exists) or configure a new one using new resources from the 
network. Using an existing address is instantaneous but might yield a less 
optimal route (if a hand-off event occurred since its configuration), on the 
other hand, configuring a new one using new network resources may take some 
time (due to signaling exchange with the network).’



2. The paragraph following the definition of the IPV6_REQUIRE_SRC_ON_NET:

‘If set, the IP stack will request a new IP address of the desired type from 
the current serving network…’

I propose the modify this to:

‘If set, the IP stack will request new resources from the network in order to 
configure a new IP address with the desired service type…’

Please also notice the disclaimer in section 3.3 – Granularity of Selection – 
that says:
‘It is outside the scope of this specification to define how the host requests 
a specific type of address (Fixed, Session-lasting or Non-persistent) and how 
the network indicates the type of address in its advertisement of addresses (or 
in its reply to an address request).’

I can modify that to ‘… type of address/prefix…’ but I prefer not to, since 
this draft focuses on Socket APIs (which deal with addresses – not prefixes). I 
hope you can accept this.

Do the above modifications fully address your concerns?

Thanks,

Danny


From: Lorenzo Colitti [mailto:lore...@google.com]
Sent: Monday, December 05, 2016 03:57
To: Moses, Danny <danny.mo...@intel.com>
Cc: Peter McCann <peter.mcc...@huawei.com>; jouni.nospam 
<jouni.nos...@gmail.com>; draft-ietf-dmm-ondemand-mobil...@ietf.org; 
dmm@ietf.org
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

Danny,

yes, there are two documents, but draft-ietf-dmm-ondemand-mobility is the one I 
am objecting to at the moment.

The reason is that it describes a practice where the application gets an IPv6 
address by issuing a request to the network, and RFC 7934 explicitly recommends 
against that. It doesn't matter whether the IPv6 address is requested and 
granted via DHCPv6, PCO options, HTTP requests, or smoke signals - the key 
point is that per RFC 7934, the network should not be handing out individual 
IPv6 addresses based on explicit requests by the host.

The best example of that practice is this text:

   In case an application
   requests one, the IP stack shall make an attempt to configure one by
   issuing a request to the network.  If the operation fails, the IP
   stack shall fail the associated socket request

but there are likely other examples elsewhere in the draft.

I would suggest rewording that text to say that the MN should pick an IP 
address out of a (/64 or shorter) prefix that has the desired properties. If 
there is not already a prefix assigned to it that has the desired properties, 
then it should request a prefix with the desired properties.

I agree that we do not need application developers to think in terms of 
prefixes, but we do need network protocol designers and implementers, and OS 
implementers, to design and implement the request machinery using prefixes and 
not individual IPv6 addresses.

Cheers,
Lorenzo

On Sun, Dec 4, 2016 at 1:13 AM, Moses, Danny 
<danny.mo...@intel.com<mailto:danny.mo...@intel.com>> wrote:
Hi guys,

I hope there isn’t a confusi

Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

[Moses, Danny]

Hi guys,

I hope there isn’t a confusion between draft-ietf-ondemand-mobility and 
draft-moses-dmm-dhcp-ondemand-mobility.


·Draft-ietf-ondemand-mobility defines the ability of the network to 
provide different types of session continuity services and extends the Socket 
interface to enable application to influence the service they require for the 
newly established IP session. It does not specify how the session continuity 
requirements are conveyed to/from the network.


·Draft-moses-dmm-dhcp-ondemand-mobility is the draft that defines 
extensions to DHCPv6 in order to convey session-continuity service type to the 
network.

Lorenzo,
I the last F2F in Seoul, you expressed your concerns that the proposed DHCP 
extensions to enabling the specification of the service type in IP address 
requests, contradict the recommendations specified in RFC 7934. As I mentioned 
in the discussion, I am committed to fix the wording in that draft to resolve 
that contradiction.

But draft-ietf-ondemand-mobility discusses extensions to the Socket interface. 
Sockets are used by application developers to initiated IP sessions. I do not 
think application developers should be networking experts and should be aware 
of what is being allocated by cellular networks to mobile hosts (or UEs, in the 
3GPP jargon…). This draft does not indicate that each invocation of a socket 
API to initiation an IP session, results in a request to the network. It does 
not get into these resolutions intentionally. We are separating the description 
of what an application does, to what the mobile host’s IP stack does.

Therefore, I do not think we should confuse application writers with IP 
prefixes. All they need to know is how to influence the service that are 
getting, like their ability to choose between a reliable transport (TCP) or 
unreliable one (UDP).

I hope you agree with this separation.

Thanks and regards,
Danny

From: Peter McCann [mailto:peter.mcc...@huawei.com]
Sent: Friday, December 02, 2016 22:37
To: Lorenzo Colitti <lore...@google.com>
Cc: jouni.nospam <jouni.nos...@gmail.com>; 
draft-ietf-dmm-ondemand-mobil...@ietf.org; dmm@ietf.org
Subject: RE: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

Agree, I am not arguing in favor of sharing a prefix between two or more MNs at 
the same time.  However, I think it is important to reclaim a prefix for use by 
another MN after the current MN has moved to a new attachment point and stopped 
using the prefix it got from the old attachment point.   It is also important 
to refrain from advertising the prefix to another MN until the current MN has 
stopped using it.  That is the network state I am talking about.

-Pete


From: Lorenzo Colitti [mailto:lore...@google.com]
Sent: Friday, December 02, 2016 3:32 PM
To: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>>
Cc: jouni.nospam <jouni.nos...@gmail.com<mailto:jouni.nos...@gmail.com>>; 
draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>;
 dmm@ietf.org<mailto:dmm@ietf.org>
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

On the particular case of shared links: note that they have substantial 
scalability and performance issues. In order for shared links to work you have 
to engage in DAD proxying, ND snooping, client isolation and all sorts of 
unsavoury and L2/L3 magic that does not scale. Some of these issues are 
described in RFC 7934 section 9.3. On shared links, these forces act to reduce 
the number of IP addresses per host that the network can support and leads to 
the negative consequences in section 4 of the document, which is why they are 
not recommended.

For these and other reasons, on many public networks we're seeing a shift 
*away* from shared links - see, for example, 
draft-ietf-v6ops-unique-ipv6-prefix-per-host , and the current large 
deployments of that model in the form of Comcast community wifi.

For many years 3GPP networks have been providing those benefits by providing a 
full /64 to every host. I would hate to lose those benefits.

On Fri, Dec 2, 2016 at 12:12 PM, Peter McCann 
<peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> wrote:
With a fixed access network the prefix can be assigned to the link and used by 
anyone who joins the link.

With a prefix offering mobility the prefix belongs to the mobile host and needs 
to move with it.  There aren’t enough prefixes (even in IPv6) to assign a 
permanent prefix to each UE for every topological attachment point that it 
might visit or start a session from.

-Pete


From: Lorenzo Colitti [mailto:lore...@google.com<mailto:lore...@google.com>]
Sent: Friday, December 02, 2016 3:09 PM
To: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>>
Cc: jouni.nospam <jouni.nos...@gmail.com<mailto:jouni.nos...@gmail.com>>; 
draft-ietf-dmm-ondemand-mobil...@ietf.org<m

Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

[Peter McCann]

Agree, I am not arguing in favor of sharing a prefix between two or more MNs at 
the same time.  However, I think it is important to reclaim a prefix for use by 
another MN after the current MN has moved to a new attachment point and stopped 
using the prefix it got from the old attachment point.   It is also important 
to refrain from advertising the prefix to another MN until the current MN has 
stopped using it.  That is the network state I am talking about.

-Pete


From: Lorenzo Colitti [mailto:lore...@google.com]
Sent: Friday, December 02, 2016 3:32 PM
To: Peter McCann <peter.mcc...@huawei.com>
Cc: jouni.nospam <jouni.nos...@gmail.com>; 
draft-ietf-dmm-ondemand-mobil...@ietf.org; dmm@ietf.org
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

On the particular case of shared links: note that they have substantial 
scalability and performance issues. In order for shared links to work you have 
to engage in DAD proxying, ND snooping, client isolation and all sorts of 
unsavoury and L2/L3 magic that does not scale. Some of these issues are 
described in RFC 7934 section 9.3. On shared links, these forces act to reduce 
the number of IP addresses per host that the network can support and leads to 
the negative consequences in section 4 of the document, which is why they are 
not recommended.

For these and other reasons, on many public networks we're seeing a shift 
*away* from shared links - see, for example, 
draft-ietf-v6ops-unique-ipv6-prefix-per-host , and the current large 
deployments of that model in the form of Comcast community wifi.

For many years 3GPP networks have been providing those benefits by providing a 
full /64 to every host. I would hate to lose those benefits.

On Fri, Dec 2, 2016 at 12:12 PM, Peter McCann 
<peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> wrote:
With a fixed access network the prefix can be assigned to the link and used by 
anyone who joins the link.

With a prefix offering mobility the prefix belongs to the mobile host and needs 
to move with it.  There aren’t enough prefixes (even in IPv6) to assign a 
permanent prefix to each UE for every topological attachment point that it 
might visit or start a session from.

-Pete


From: Lorenzo Colitti [mailto:lore...@google.com<mailto:lore...@google.com>]
Sent: Friday, December 02, 2016 3:09 PM
To: Peter McCann <peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>>
Cc: jouni.nospam <jouni.nos...@gmail.com<mailto:jouni.nos...@gmail.com>>; 
draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>;
 dmm@ietf.org<mailto:dmm@ietf.org>

Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

But you have that problem with IP addresses as well, right? I don't see how 
"assigning a prefix with certain properties" requires more state in the network 
than "assigning an IP address with certain properties".

On Fri, Dec 2, 2016 at 12:00 PM, Peter McCann 
<peter.mcc...@huawei.com<mailto:peter.mcc...@huawei.com>> wrote:
Providing any kind of mobility service for a prefix will require some state 
somewhere in the network.  It would be great to avoid an allocation request / 
response for the prefix, but the state has to be created somehow before the UE 
can use the prefix and it has to be reclaimed eventually after the UE stops 
using the prefix (which may not be until well after it disconnects from the 
current link and moves to another one).

Would welcome any suggestions on how to manage this state.

-Pete


From: dmm [mailto:dmm-boun...@ietf.org<mailto:dmm-boun...@ietf.org>] On Behalf 
Of Lorenzo Colitti
Sent: Friday, December 02, 2016 12:04 PM
To: jouni.nospam <jouni.nos...@gmail.com<mailto:jouni.nos...@gmail.com>>
Cc: 
draft-ietf-dmm-ondemand-mobil...@ietf.org<mailto:draft-ietf-dmm-ondemand-mobil...@ietf.org>;
 dmm@ietf.org<mailto:dmm@ietf.org>
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

Hi,

I like the goal of reducing network cost by allowing the use of IP addresses 
that do not require network mobility, but we should not be doing this by 
requesting IP addresses from the network, because this violates IPv6 address 
assignment best practices.

Specifically, RFC 7934 recommends that a) the network should provide multiple 
addresses from each prefix and b) the network should allow the host to use new 
addresses without requiring explicit requests to the network. This is in 
conflict with at least this text in the draft, which says:

   In case an application
   requests one, the IP stack shall make an attempt to configure one by
   issuing a request to the network.  If the operation fails, the IP
   stack shall fail the associated socket request

One way to resolve this conflict would be to say that the network must not 
assign individual addresses, but /64 (or shorter) prefixes. So if the device 
desires to use

Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

[Peter McCann]

Maybe I missed Lorenzo's point and talked past him, though.

I agree we should be talking about the state maintained for a prefix and not 
individual addresses.  At least, for IPv6.

There is still a state management problem and we need to decide whether 
explicit signaling is required.

-Pete


-Original Message-
From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com] 
Sent: Friday, December 02, 2016 3:15 PM
To: Peter McCann <peter.mcc...@huawei.com>
Cc: Lorenzo Colitti <lore...@google.com>; 
draft-ietf-dmm-ondemand-mobil...@ietf.org; dmm@ietf.org
Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

Lorenzo,
It is 3GPP practice (or law, should I say) is to assign a prefix in
IPv6 to the UE. That is what Peter is talking about.

Regards,

Behcet

On Fri, Dec 2, 2016 at 2:12 PM, Peter McCann <peter.mcc...@huawei.com> wrote:
> With a fixed access network the prefix can be assigned to the link and 
> used by anyone who joins the link.
>
>
>
> With a prefix offering mobility the prefix belongs to the mobile host 
> and needs to move with it.  There aren’t enough prefixes (even in 
> IPv6) to assign a permanent prefix to each UE for every topological 
> attachment point that it might visit or start a session from.
>
>
>
> -Pete
>
>
>
>
>
> From: Lorenzo Colitti [mailto:lore...@google.com]
> Sent: Friday, December 02, 2016 3:09 PM
> To: Peter McCann <peter.mcc...@huawei.com>
> Cc: jouni.nospam <jouni.nos...@gmail.com>; 
> draft-ietf-dmm-ondemand-mobil...@ietf.org; dmm@ietf.org
> Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08
>
>
>
> But you have that problem with IP addresses as well, right? I don't 
> see how "assigning a prefix with certain properties" requires more 
> state in the network than "assigning an IP address with certain properties".
>
>
>
> On Fri, Dec 2, 2016 at 12:00 PM, Peter McCann 
> <peter.mcc...@huawei.com>
> wrote:
>
> Providing any kind of mobility service for a prefix will require some 
> state somewhere in the network.  It would be great to avoid an 
> allocation request / response for the prefix, but the state has to be 
> created somehow before the UE can use the prefix and it has to be 
> reclaimed eventually after the UE stops using the prefix (which may 
> not be until well after it disconnects from the current link and moves to 
> another one).
>
>
>
> Would welcome any suggestions on how to manage this state.
>
>
>
> -Pete
>
>
>
>
>
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Lorenzo Colitti
> Sent: Friday, December 02, 2016 12:04 PM
> To: jouni.nospam <jouni.nos...@gmail.com>
> Cc: draft-ietf-dmm-ondemand-mobil...@ietf.org; dmm@ietf.org
> Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08
>
>
>
> Hi,
>
>
>
> I like the goal of reducing network cost by allowing the use of IP 
> addresses that do not require network mobility, but we should not be 
> doing this by requesting IP addresses from the network, because this 
> violates IPv6 address assignment best practices.
>
>
>
> Specifically, RFC 7934 recommends that a) the network should provide 
> multiple addresses from each prefix and b) the network should allow 
> the host to use new addresses without requiring explicit requests to the 
> network.
> This is in conflict with at least this text in the draft, which says:
>
>
>
>In case an application
>
>requests one, the IP stack shall make an attempt to configure one 
> by
>
>issuing a request to the network.  If the operation fails, the IP
>
>stack shall fail the associated socket request
>
>
>
> One way to resolve this conflict would be to say that the network must 
> not assign individual addresses, but /64 (or shorter) prefixes. So if 
> the device desires to use fixed IPv6 addresses, then the network 
> should give the host a fixed IPv6 prefix from which the host can form 
> as many addresses as it wants.
>
>
>
> I do not think we should advance this document until the conflicts are 
> resolved. This document is about IPv6 address assignment to mobile 
> nodes, and we should not publish a document about IPv6 address 
> assignment that conflicts with best current practices on IPv6 address 
> assignment.
>
>
>
> Regards,
>
> Lorenzo
>
>
>
> On Mon, Nov 28, 2016 at 12:56 PM, jouni.nospam 
> <jouni.nos...@gmail.com>
> wrote:
>
> Folks,
>
>
>
> The authors of draft-ietf-dmm-ondemand-mobility-07 and 
> draft-sijeon-dmm-use-cases-api-source have come up with a merged 
> document draft-ietf-dmm-ondemand-mobility-08.
>
>
>
> This email starts a

Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08

[Behcet Sarikaya]

Lorenzo,
It is 3GPP practice (or law, should I say) is to assign a prefix in
IPv6 to the UE. That is what Peter is talking about.

Regards,

Behcet

On Fri, Dec 2, 2016 at 2:12 PM, Peter McCann <peter.mcc...@huawei.com> wrote:
> With a fixed access network the prefix can be assigned to the link and used
> by anyone who joins the link.
>
>
>
> With a prefix offering mobility the prefix belongs to the mobile host and
> needs to move with it.  There aren’t enough prefixes (even in IPv6) to
> assign a permanent prefix to each UE for every topological attachment point
> that it might visit or start a session from.
>
>
>
> -Pete
>
>
>
>
>
> From: Lorenzo Colitti [mailto:lore...@google.com]
> Sent: Friday, December 02, 2016 3:09 PM
> To: Peter McCann <peter.mcc...@huawei.com>
> Cc: jouni.nospam <jouni.nos...@gmail.com>;
> draft-ietf-dmm-ondemand-mobil...@ietf.org; dmm@ietf.org
> Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08
>
>
>
> But you have that problem with IP addresses as well, right? I don't see how
> "assigning a prefix with certain properties" requires more state in the
> network than "assigning an IP address with certain properties".
>
>
>
> On Fri, Dec 2, 2016 at 12:00 PM, Peter McCann <peter.mcc...@huawei.com>
> wrote:
>
> Providing any kind of mobility service for a prefix will require some state
> somewhere in the network.  It would be great to avoid an allocation request
> / response for the prefix, but the state has to be created somehow before
> the UE can use the prefix and it has to be reclaimed eventually after the UE
> stops using the prefix (which may not be until well after it disconnects
> from the current link and moves to another one).
>
>
>
> Would welcome any suggestions on how to manage this state.
>
>
>
> -Pete
>
>
>
>
>
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Lorenzo Colitti
> Sent: Friday, December 02, 2016 12:04 PM
> To: jouni.nospam <jouni.nos...@gmail.com>
> Cc: draft-ietf-dmm-ondemand-mobil...@ietf.org; dmm@ietf.org
> Subject: Re: [DMM] WGLC for draft-ietf-dmm-ondemand-mobility-08
>
>
>
> Hi,
>
>
>
> I like the goal of reducing network cost by allowing the use of IP addresses
> that do not require network mobility, but we should not be doing this by
> requesting IP addresses from the network, because this violates IPv6 address
> assignment best practices.
>
>
>
> Specifically, RFC 7934 recommends that a) the network should provide
> multiple addresses from each prefix and b) the network should allow the host
> to use new addresses without requiring explicit requests to the network.
> This is in conflict with at least this text in the draft, which says:
>
>
>
>In case an application
>
>requests one, the IP stack shall make an attempt to configure one by
>
>issuing a request to the network.  If the operation fails, the IP
>
>stack shall fail the associated socket request
>
>
>
> One way to resolve this conflict would be to say that the network must not
> assign individual addresses, but /64 (or shorter) prefixes. So if the device
> desires to use fixed IPv6 addresses, then the network should give the host a
> fixed IPv6 prefix from which the host can form as many addresses as it
> wants.
>
>
>
> I do not think we should advance this document until the conflicts are
> resolved. This document is about IPv6 address assignment to mobile nodes,
> and we should not publish a document about IPv6 address assignment that
> conflicts with best current practices on IPv6 address assignment.
>
>
>
> Regards,
>
> Lorenzo
>
>
>
> On Mon, Nov 28, 2016 at 12:56 PM, jouni.nospam <jouni.nos...@gmail.com>
> wrote:
>
> Folks,
>
>
>
> The authors of draft-ietf-dmm-ondemand-mobility-07 and
> draft-sijeon-dmm-use-cases-api-source have come up with a merged document
> draft-ietf-dmm-ondemand-mobility-08.
>
>
>
> This email starts a 2 week WGLC for draft-ietf-dmm-ondemand-mobility-08.
>
> The WGLC starts 11/28/16 and ends 12/12/16.
>
>
>
> Provide your comments, concerns and approvals to the email list (and
> hopefully also to IssueTracker).
>
>
>
> - Jouni & Dapeng
>
>
>
>
>
>
>
> Begin forwarded message:
>
>
>
> From: IETF Secretariat <ietf-secretariat-re...@ietf.org>
>
> Subject: IETF WG state changed for draft-ietf-dmm-ondemand-mobility
>
> Date: November 28, 2016 at 12:51:34 PM PST
>
> To: <draft-ietf-dmm-ondemand-mobil...@ietf.org>, <dmm-cha...@ietf.org>,
> <max@alibaba-inc.com>
>
> Resent-From: