[MEXT] Comments on "PS for distributed and dynamic mobility management" (draft-chan-distributed-mobility-ps-05).

[Jong-Hyouk Lee <[e-mail]>]

Dear H. Chan and all.

I read the latest Internet-draft, draft-chan-distributed-mobility-ps-05. 
It is generally well written and contains educational and introductory 
text for distributed mobility management.

The followings are some comments:

1. As you know, we will not have "the distributed mobility management 
working group" at the IETF, but it is being considered at the MeXT 
working group.

2. In Section 1.2, the problems or limitations of centralized mobility 
anchoring (i.e., most of existing mobility protocols) are presented. 
However, you should give some descriptions what distributed and dynamic 
mobility management is before. Otherwise, it would be better not to 
compare with (or not to mention) distributed and dynamic mobility 
management because you have not given detailed operations, 
characteristics, and benefits of distributed and dynamic mobility 
management before Section 1.2. Note that we all know about the history 
of it, but others? ;)

3. As one of the problems or limitations of centralized mobility 
anchoring (i.e., most of existing mobility protocols), you have 
identified a complicated deployment due to many variants and extensions. 
I do not see if it is surely the problems or limitations. Could you give 
specific examples for this? Existing extensions to mobility protocols 
have been well selected and developed for enhancing deployment ease, 
performance, security, etc...those are not the specific problems or 
limitations a centralized mobility anchoring approach has...I suppose.

4. "Mobility management functions may be implemented at different layers 
of the network protocol stack." should be rephrased as "... at different 
layers of the communication stack" or "... at different layers of the 
protocol stack".

5. "... between identifier and routing address ..." should be "... 
between identifier and routing addresses ..."

6. In Section 3.1, "Packets destined to an MN are ..." should be 
"Packets destined to the MN are ..."

7. RFC 3775 should be replaced with RFC 6275.

8. It is always better to explicitly distinguish IP protocol version 
numbers, e.g., Mobile IPv4 or Mobile IPv6, at the document. As an 
example, In Section 3.1, "... Mobile IP [RFC3775] and Proxy Mobile IP 
[RFC5213], respectively." should be "Mobile IPv6 [RFC6275] and Proxy 
Mobile IPv6 [RFC5213], respectively."

9. For Figures 1 and 2, it is good if the figure titles are 
"Architectural view of centralized mobility management" and 
"Architectural view of distributed mobility management".

10. In Section 3.2, two terms, i.e., distributed mobility management and 
flat IP architecture, are used, but (from my point of view) a relation 
between them is not well described at Section 3.1 or even before at the 
document. Readers might be confused when the terms, i.e., distributed 
mobility management, dynamic mobility management, and flat IP 
architecture, are used together without explicit descriptions of them, 
e.g., centralized vs. distributed mobility managements, fixed anchor vs. 
dynamic mobility managements, and hierarchical vs. flat architecture. 
Note that for cellular network guys it must be wonderful if this 
document also provides some differences between dynamic mobility 
management (i.e., selectively providing mobility support) and paging (or 
anchor point management schemes) being used in cellular networks.

11. In Section 3.2, you wrote as "It has therefore been proposed to 
adapt MIP or PMIPv6 to achieve distributed mobility management by using 
a distributed mobility anchor architecture." Could you kindly provide 
any reference for this? No offense, I'm also looking for references of 
it. ;)

12. In Section 4.1, you have mentioned about location privacy: when a 
mobile node directly communicates its correspondent node, its location 
is open to the correspondent node. Yes, that's true, but the disclosure 
of address to a communication node, i.e., the correspondent node, is 
natural. In other words, thanks to the use of home address, the hiding 
of the real address, i.e., care-of address, is just an advantage of 
having the mobility anchor. So, the disclosure of care-of address when 
route optimization in MIPv6 is not subject to blame for location 
privacy...it is an prerequisite essential.

13. Any references for "These network functions can be the content 
servers in a CDN, and also the data anchor point." or "Mobile networks 
have been evolving from a hierarchical architecture to a more flattened 
architecture." in Section 4.2.

14. In Section 4.3, the following sentence "... a novel mobility 
management approach should be designed for such networks ..." is enough 
with a "new" word, instead of "novel". I'm sure that it is the 
distributed mobility management with a flatten network architecture, 
which as you mentioned is being required or introduced in existing 
networks to overcome limitations of the centralized mobility management. 
Note that it is better not to use "color words" in standardization 
documents and scientific papers.

15. Section 4.4 describes a tunnel management between mobility entities. 
However, I do not see your justification for low scalability of 
centralized route and mobility context maintenance.

16. In Section 4.5, I suppose the following sentences "In addition, it 
is possible to have the intelligence for applications to manage mobility 
without needing help from the network. Network resources are therefore 
wasted to provide mobility support for the devices that do not really 
need it at the moment." do not quite related to the proposal of Section 
4.5. If an intelligence functionality could help to handle such a case, 
it is also applied to a centralized mobility management, not only to a 
distributed one, isn't it? In addition, as I mentioned before, it would 
be great if you provide some text to describe what the differences 
between the dynamic mobility management mechanism and paging (or anchor 
point management schemes) are.

17. The title of Figure 5 should be changed; it is not only showing the 
bidirectional tunneling case, but also showing the route optimization 
case. ;)

Hope this would help.

Cheers.

-- 
IMARA Team, INRIA, France
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random

#email: jong-hyouk.lee (at) inria.fr || hurryon (at) gmail.com
#webpage: http://sites.google.com/site/hurryon/