[DMM] 答复: RE: Some comments on draft-chan-dmm-framework-gap-analysis-05.

[[e-mail]]

Hi Antony

Thanks for your reply, please see in-line for more comments.

BR
Luowen




h chan <[e-mail]> 
2012/10/25 05:45

收件人
"[e-mail]" <[e-mail]>
抄送
"[e-mail]" <[e-mail]>
主题
RE: [DMM] Some comments on draft-chan-dmm-framework-gap-analysis-05.






Luowen,
 
Let me first explain what was intended to say, and then make corrections 
accordingly. 
 
I think compatibility in the requirement refers to the following:
If one deploys dmm in a network, and the network had an existing 
(centralized) mobility management deployment, the existing deployment 
should continue to work. 

[Luowen] Yes I agree. The existing deployment should continue to work. But 
we should identify what is the meaning when one says the  existing 
deployment can continue to work. One understanding is that those two 
domains (dmm domain and  existing deployment domain such as PMIPv6 domain) 
work independently. Another understanding is that mobile node which is 
belong to dmm domain can access the network via  the existing deployment 
domain ( such as PMIPv6 domain) in a manner of roaming. Or mobile node can 
handover from dmm domain to the existing deployment domain ( such as 
PMIPv6 domain) seamlessly and vice versa. So maybe we should make it clear 
that what is the precise meaning of compatibility.

The abstract functions are used to build up the protocols by adding 
functions one step at a time to the network. 

[Luowen] Yes.

So, the intention of the framework is as follows:
The MR, LM, LU abstract functions are those of HA. So, it is 
straightforward to construct MIPv6 using these functions. 
Then some additional functions are added to construct PMIPv6, then some 
additional functions are added to construct HMIPv6, etc. 

[Luowen] That is true.

So, the configuration and functions in HMIPv6 “under this construction” 
already include those for PMIPv6, and that for PMIPv6 “under this 
construction” include those of MIPv6 etc.
That means MIPv6 should continue to work in the PMIPv6 construction, and 
both PMIPv6 and MIPv6 should work in the HMIPv6 construction. 

[Luowen] I am not sure about this. Maybe it depends on the what  is the 
precise meaning of compatibility. E.g. I don't see how a PMIPv6 mobile 
node can continue to enjoy seamless mobility service when it enters a 
MIPv6 (maybe I am wrong.)
 
One can then continue to construct dynamic mobility management on top of 
HMIPv6, and then continue to construct route optimization with dmm on top 
of dynamic mobility management. And the above interpretation of 
compatibility should apply. 
 
Is that a reasonable approach?

[Luowen] Also, whether it is reasonable or not, may depends on the precise 
meaning of compatibility
 
So, it does not intend to say compatible to each other, and the wording 
should be corrected.

[Luowen] Yes, the wording may need be corrected, otherwise it may make 
people confused. 
 
The gap analysis on the framework with MR, LM, LU is intended to refer to 
that of a mobility solution based on these functions alone.  It has not 
added those additional features needed for DMM, so it is too early to say 
whether it can meet the rest of the requirements other than those met by 
MIPv6. It could have been left blank as you pointed out that N/A is not a 
good description. 
 
H Anthony Chan
 
From: [e-mail] [mailto:[e-mail]] On Behalf Of 
[e-mail]
Sent: Tuesday, October 23, 2012 3:21 AM
To: [e-mail]
Cc: [e-mail]
Subject: [DMM] Some comments on draft-chan-dmm-framework-gap-analysis-05.
 

Hi Antony: 

Thanks to your new draft, 
http://tools.ietf.org/html/draft-chan-dmm-framework-gap-analysis-05. I 
have some comments as following. 

1. I have some concern on the statement (section 6.1.2) 
------------------------------------------------------------------------- 
  "Different deployments using the same abstract functions can be
  compatible with each other if their functions use common message
  formats between these functions."   
--------------------------------------------------------------------------- 

Actually, I don't think it is a sutiable criterion, i.e. I don't think 
that sharing same abstract functions necessary indicate different 
deployments can compatible with each other. 
Taking figure 6 in your draft as an example, this deployment is using the 
abstract functions MR, LM and LU as indicated in the figure. Meantime, 
PMIPv6(RFC[5213]) is also using same abstact functions as described in the 
draft. Then, according to the criterion, these two designs should be 
compatiable with each other. However, consider that, if these two designs 
are deployed together (e.g. one operator deploys both two designs), and 
when MN handover from your AR2 to a RFC[5213] specified MAG, I am not sure 
how to keep all IPv6 prefixes which are anchored at AR1, AR2 and AR3 
respectively alive. Taking figure 8 as anther example, I am not sure how 
to perform  location management if mobile node handovers to a RFC[5213] 
specified PMIPv6 domain from the domain illustrated by this figure. 
Because the RFC[5213] specified LMA or MAG doesn't have such location 
management interface with the LM in figure 8. 

Another concern about the "compatibility" is the analysis comparisons 
"compatibility" in table 1 (section 6.3). You mark "Y" to all items. But, 
for example, I am not very clear about how can HAHA be compatible with 
MIPv6, and how can Multiple MRs and Distributed LM be compatible with 
PMIPv6 (as explained above) and etc. May be we should not jump to a 
conclusion before a carefully examine. Besides, if I am not making 
mistake, the compatibility also includes the compatibility with already 
exsiting end host (e.g. mobile node), right? 

2.  In table 1 section 6.3, why the last four analysis comparisons for 
Unified framework are marked as N/A ? Besides, I think the Unified 
framework is not a mobility solution, so why you put it in this comparison 
table?

3. Still table 1, I think the last analysis comparisons of Multiple MRs 
and Distributed LM database must be missing.   

4. Still table 1, I think the last analysis comparisons item of Optimize 
Route should be "except first few packets". 

BR 
Luowen