Opened 13 years ago

Closed 13 years ago

Last modified 12 years ago

#45 closed defect (invalid)

Editorial Changes for the REQ draft from Vidya Narayanan

Reported by: kempf@… Owned by: kempf@…
Priority: minor Milestone:
Component: nohost-req Severity:
Keywords: REQ draft Cc: netlmm@…

Description

Terminology (Section 1.1):


The terminology section needs serious revision. The definitions are puzzling to me. In a nutshell, here is my interpretation of the terms defined per the I-D:

Host-Based Approach = HMIPv6 Micromobility Approach = host route propogation Edge Mobility Approach = 3gpp mobility management

These are neither consistent with RFC3753, nor intuitive. I would suggest that the terminology follow something along the following lines:

Node-Based Mobility Management: A term used to identify the case where IP mobility management is handled by the end node. This may be node-triggered or network-triggered (trigger to perform IP mobility management may come from either entity). However, the mobility management updates itself are done by the host. *Note that I used "Node" instead of "Host" on purpose to include mobile routers.

Network-Based Mobility Management: A term used to identify the case where IP mobility management is handled by the network. The host may be involved in triggering the mobility management process, but the updates are contained within the network.

I'd suggest sticking to the definitions in RFC3753 for the terms Local Mobility Management and Micro Mobility.

Node-Based Local Mobility Management (or Node-Based Micro Mobility): Self-explanatory term - examples of protocols that fall under this category would be HMIP, FMIP, host route propogation, etc.

Network-Based Local Mobility Management (or Network-Based Micro Mobility): A term used to identify the case where the network is responsible for handling mobility management within a local domain for nodes within that domain. An example is the anchor-based mobility management that is currently described under "Edge Mobility Approach". Network-based HMIP (direction in which NETLMM could be seen heading) and Network-based FMIP are potential examples.

Requirements (Section 2.0)


I see that the document is really written as requirements for "local mobility", rather than requirements for "network-based local mobility" - this allows the gap analysis to lead to the conclusion that NETLMM is needed. This is okay, but it does give an impression that the requirements have been written with a solution in mind.

Section 2.1 - This is really a goal, not a requirement. A protocol developed cannot really be evaluated against this. Also, what is really specific to NETLMM here? NETLMM is going to rely on the availability of certain triggers that would help detect the mobile so that the network can trigger the update - if those triggers are available at the end node at the same time, it can perform mobility management (local or global) on its own with the same type of performance.

Section 2.2 - This is the biggest advantage going for NETLMM, as I see it. It would be good to streamline this section to identify IP-level handoff steps only. Also, this section will benefit from a 2-step approach - i) host-based global mobility management steps and ii) host-based global and local mobility management steps (say, HMIPv6 or FMIPv6). For instance, NETLMM is not getting rid of all the 7 steps shown in this section. So, structuring this section in a way that brings out the salient points would greatly help.

Section 2.3 - Why is this a requirement for LMM protocols? By design, NETLMM will naturally provide location privacy as described here, but the description leads to the question of whether the requirement was reverse engineered? If so, is it really a requirement? Privacy is a bigger problem of mobility management in general, nothing specific to LMM per say. At best, I'd say this is a goal, not a requirement.

Section 2.4 - This section is confusing. The description is all about data path overhead, but the last sentence summarizes it as "...should not require any new *signaling*...". Per the last sentence, how does this differ from 2.2? I think this section should be re-worded as "Minimizing Data Path Overhead" and be described as such.

Section 2.5 - This is a minor point. I don't really see how NETLMM will do anything to help with this anyway. In my view, this should not be listed as a requirement.

Section 2.6 - If this section talked only about eliminating the need for per-MN SA for LMM, that makes sense to me. I am not sure how there is any difference in DoS attacks whatsoever between host-based and network-based mobility. For instance, if a mobile node configured n number of IP addresses, the network will assume the presence of n nodes and perform LMM for the node. SeND even does not help here - a node can claim any number of IP addresses. Today, network access authentication does not have a means to perform tight IP address authorization/control. Without it, the claims about DoS attack mitigation don't make sense to me. It would be good to remove all reference to this from the section.

Section 2.7 - This section talks about how it is impractical to assume a non-changing IP address across interfaces. What would be the motivation for talking about this? Heterogeneous links have two cases of interest for mobility - vertical handoffs per say and multi-homing. I don't see any reason why vertical handoffs would disallow the same IP address from being used across technologies (assuming the interfaces are part of the same LMM Domain). Multi-homing, OTOH, is a different story. I assume this section meant to discuss vertical handoffs - so, why preclude the use of the same IP address if it is feasible?

Section 2.8 - Text in this section can be truncated to a large extent for sake of clarity. This is also one of those things I view as a goal, not a requirement.

Section 2.9 - This section was not clear to me. I think what it is getting at is that the protocol is intended to be IPv6, but it must support mobility for IPv4 nodes within the LMM domain. Some clarification would be good to that effect.

Gap Analysis (Section 3.0)


I didn't review this section - my take is that it belongs in an appendix and should not be part of the main draft.

Security Considerations (Section 4.0)


It would be good to elaborate on the MN to network and inter-network element security a bit more for completeness. Cross referencing the threat analysis draft is okay, but some summary would help. Also, the points about currently lacking means of IP address authorization need to be brought out (part of the bogus mobility event trigger problem).

Recommendations (Section 5.0)


Same comment as earlier on the DoS attacks issue.

Change History (2)

comment:1 Changed 13 years ago by kempf@…

  • Resolution set to invalid
  • Status changed from new to closed

These comments apply to the text in the 00 draft and were addressed by the changes put into the 01 draft, which is the current version.

comment:2 Changed 12 years ago by anonymous

  • Milestone milestone2 deleted

Milestone milestone2 deleted

Note: See TracTickets for help on using tickets.