Re: [DMM] Response to the early review of draft-dmm-ondemand-mobility

["Moses, Danny" <[e-mail]>]

Hi Sri,

Thanks for the additional comments, they are in line with my views.
I will discuss with Brian an update the WG as you recommended.

Thanks,
Danny


From: Sri Gundavelli (sgundave) [mailto:[e-mail]]
Sent: Wednesday, June 13, 2018 00:10
To: Moses, Danny <[e-mail]>; [e-mail]
Cc: Brian Haberman <[e-mail]>
Subject: Re: [DMM] Response to the early review of draft-dmm-ondemand-mobility

Hi Danny,

You can discuss this with Brian directly (keeping the WG in the loop). You do not need consensus from the WG. If there is any objection from the WG on any of the issue resolutions, then it will become a WG issue.

Please see inline for additional comments.

Sri



From: dmm <[e-mail]<mailto:[e-mail]>> on behalf of "Moses, Danny" <[e-mail]<mailto:[e-mail]>>
Date: Sunday, June 10, 2018 at 4:21 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [DMM] Response to the early review of draft-dmm-ondemand-mobility

Hi all,

This is the initial draft of the response to the Brian Haberman's early review of draft-dmm-ondemand-mobility.

I would like to thank Brian for his review and provide the WG's response.
Please see the first draft of the response below and provide comments. I think that the first issue requires most of our attention. Assuming that most of the people will agree with my opinion that Brian is correct in his comment about the term 'IP session continuity', please help me in using a better term. I have provided some alternatives and am also open to more suggestions.

I have copied Brian's comments and provided a response to each one.

Thanks,
Danny

Response to the early review of  draft-dmm-ondemand-mobility:

Reviewer: Brian Haberman
Review result: Not Ready

This is an early review request for draft-ietf-dmm-ondemand-mobility.

I am having a hard time with the thrust of this document. The following issues really need to be addressed in some form...

1. Where is the concept of an IP session defined? Given that IP is connectionless, this term is really about IP address stability and its lifetime. A new term could/should be coined to reflect what is really needed.

Yes, this is a fare comment.
Most of the work that has been done in relation with mobility boils down to the stableness of the mobile node's source IP address (or source IP prefix). The implication to applications, is their ability or inability to maintain the transfer of packets with the corresponding node - which may be perceived this as a 'session'.
On the other hand, the term 'session' is overloaded and might not be accurate enough in this context.

I checked other RFCs:
RFC5944 uses the text: '...the ability to communicate...' or '... the ability to maintain transport and high-layer connections...'.
RFC4830 uses the text (under the definition of 'Global Mobility Management Protocol'): '...end-to-end routing of packets for the purpose of maintaining session continuity when management causes a topology change...'.
Since I would like to avoid getting into a debate on a new definition (which could take years and is probably on a wider scope than dmm), I would like to suggest some alternatives:

1.      Maintaining transport and higher-layer connections

2.      Continuity of IP connectivity

3.      Session continuity

4.      Source IP prefix validity

5.      Socket operation validity


We have the term, "Mobility Session" defined in MIP specs. But, I do not believe we have provided any explicit definition for the term "IP Session". RFC 7847 (Logical Interface Support) uses the "IP Session" term, but with no explicit definition. I think providing some definition will help. I do not think it will take years to converge on a definition. If you can just state your assumption or technical requirements on what the expectations or from the stack, application or routing point of view, that should do it. You may want to propose some text to Brian.





2. The needs described in this document have a mix of the ID/Location split issues raised in a variety of other specifications. It would be good to clarify what is different here.

This document does not describe a need to perform ID/Location split, or defines a new way to maintain the validity of an IP prefix. It simply defines a new ability of applications in a host to influence the type of service provided by the mobile network.

Most current cellular network performs tunneling automatically to all provisioned IP prefixes regardless of whether or not this is needed. This document defines a way for applications to indicate to networks if such service is actually needed or not.
The benefit of providing this information to the network is saving unnecessary network resources (required for maintaining the validity of the source IP prefix) and enabling more optimized routes to packet transmitted and received by mobile nodes (as mentioned in the document).

I would say, when there are mobility management mechanisms in place In the access network to which a mobile node is attached, the mobile node is unaware of the mobility management support that exists for an IP address. The goal of this spec is to enable the mobile node with such awareness. A given address may have mobility support, or it may mobility support for a transient period of time. The objective here is to extend the socket layer so the mobile node can obtain this additional meta-data about the address from its IP stack.




3. The draft only references host-based Mobile IP specifications. What are the implications when other solutions (e.g., PMIP) are employed?

Please clarify this point.
I checked once more and did not find any reference in the text to the host-based Mobile IP. Furthermore, the context of this document is about management of IP prefixes performed by the network (e.g. proxy...) and the ability of applications to indicate when such operation are not needed. It does not specify specific operations, but clearly, PMIP, GTP, ID/Location separation are examples of such operations.
The documents provides some pointers to RFC that define these operations, among them: RFC5563 - Proxy Mobile IPv4 and RFC 5213 - Proxy Mobile IPv6.
So what exactly is missing?

The focus of the spec in the socket layer extensions and these extensions should work with both client and network based mobility management enabled networks.




4. It is problematic that this document explicitly rules out of scope any discussion of how this API interacts with address assignment methods (e.g., DHCP). Clearly, there will need to be a way for this API to influence each of the address assignment methods available. Some of the classes of IP addresses described in this document require certain lifetime guarantees from the address assignment method. That needs to addressed since it will require changes to every assignment method.

There are two other documents in process in DMM that address the way applications convey the required service from the network and for the network to update the host of the assigned service:

-        draft-moses-dmm-dhcp-ondemand-mobility - specifying extensions to DHCPv6, and

-        draft-feng-dmm-ra-prefixtype - specifying extension to the mobility option in RA messages.


5. The IETF has a very checkered history of success in getting APIs standardized within the appropriate group (POSIX/Austin/Open). Has this proposed API been discussed within that community?
No.
However it has been discussed in 3GPP SA2 WG and the SSC mode feature of release 15 will benefit from this document.
Needless to say, once the document becomes an RFC, it would be good to discuss implementation in the groups that are mentioned.


Given that 3GPP is asking for such support, there is good chance this will make it into host stacks.


Sri


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