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 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). 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? 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. --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
