Hi Antony Thanks for your reply, please see in-line for more comments.
BR Luowen h chan <[email protected]> 2012/10/25 05:45 收件人 "[email protected]" <[email protected]> 抄送 "[email protected]" <[email protected]> 主题 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: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Tuesday, October 23, 2012 3:21 AM To: [email protected] Cc: [email protected] 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
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
