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

[h chan <[e-mail]>]

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.
The abstract functions are used to build up the protocols by adding functions one step at a time to the network.

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

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?

So, it does not intend to say compatible to each other, and the wording should be corrected.

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