[nemo] Re: Comments on draft-ietf-nemo-ro-space-analysis-00.txt

[Chan-Wah Ng <[e-mail]>]

Hello Carlos,

Thank you for reading the draft so soon, and the valuable comments.  See
my response in-line.  I will try my best to respond to all your
comments, but some I will leave to my other co-authors to address.


On Tue, 2005-09-06 at 13:12 +0200, Carlos Jesús Bernardos Cano wrote:
> Hi draft authors and all,
> 
> 	I've read the draft and I have some comments.
> 
> 	First of all, a general comment about the structure of the document.
> IMHO, I'm not quite sure about if it's a good idea to present the
> different scenarios of NEMO RO in the way it is done now. In my
> understanding, a discussion about the scenarios of NEMO RO is needed,
> but more focused in which and how the different aspects that contribute
> to the inefficiencies due to the use of the NEMO Basic Support protocol
> could be mitigated/avoided, without taking into account and making any
> explicit reference to existing solutions. After that, it's fine to
> present the issues of potential NEMO RO solution, before exploring the
> solution space (in this section, references to existing solutions are
> more appropriate, IMHO).

So, if I understand your point of view correctly, you feel that all
references to existing proposals should be moved to Sect 5?

> 
> 	Regarding more specific comments of some parts of the document, I have
> the following:
> 
> 	- In the section 3.2.2, it is said "The aim is to reduce the
> amplification effect of nested tunnels due to the nesting of tunnels
> between the Visiting Mobile Node and its Home Agent within the tunnel
> between the parent Mobile Router and the parent Mobile Router's Home
> Agent". I don't fully understand why it says "Visiting Mobile Node",
> since there may be several tunnels not only because a VMN visits a NEMO,
> but also because of several nested MRs. I think that the terminology may
> lead to confusion in some parts of the document, when Mobile Node,
> Visiting Mobile Node and Mobile Network Node is used. Again, the text is
> confusing to me when says "Such a solution will seek to minimize the
> number of tunnels possibly by collapsing the amount of tunnels required
> through some form of signaling between Mobile Nodes, or between Mobile
> Nodes and their Home Agents".

We are tyring to be consistent with draft-ietf-nemo-terminology.  It is,
i think, an unfortunate circumstances that RFC3775 uses the term Mobile
Node when Mobile Host is more appropriate.

The term VMN refers to both visiting mobile hosts and visiting mobile
routers, so the use of VMN includes the case of nested MRs.  We are
trying to write as concisely as possible here, considering the draft is
already 39 pages long.  However, we may have overdone it and lose some
clarity for the sake of conciseness.  I will try to clean up the text a
bit to make it less confusing.

> 
> 	- In the section 3.3. it is said that "This may be used to eliminate
> the multiple tunnels caused by nesting of Mobile Nodes.". What is
> nesting of Mobile Nodes? Again, for me the terminology used is
> confusing. Does it refer to VMNs that connect to a NEMO?
> 
> 	- In the section 3.4, the use of delegation of a single prefix to a
> nested NEMO is pointed out. It is said that in that case, the MRs would
> have to perform ND on behalf of the MNNs. If so, then the addresses of
> the MNNs would change when the NEMO (or a sub-NEMO) moves, right? In
> that case, LFNs would not be supported. I think that some kind of
> address delegation may be useful for a potential NEMO RO solution, but
> I'm not so sure about the direct delegation of a prefix to every node in
> the nested NEMO. OTOH, I have to admit that I have not read the last
> drafts about prefix delegation, so maybe I'm missing something.
> 

This is one RO scheme where LFN is not supported.  Because if LFN are to
be supported, they would break session continuity when the prefix is
changed.

The latest draft on prefix delegation has nothing to do with RO, AFAICS.
The draft we are referring to when the text was written is quite an old
draft, draft-leekj-nemo-ro-pd-02.txt


> 	- In the section 4, I would add an additional issue (or at least
> comment somewhere in the document) about the NEMO RO supporting
> non-mobile routers within a NEMO. Some of the currently proposed
> solutions does not support/cannot be applied when there is a legacy
> non-mobile router within a NEMO. Since, the NEMO Basic Support does
> support it, I think it should be pointed out.

Noted.

> 
> 	- In the section 4.1, it is said that the signalling overhead may scale
> to be unacceptable, especially to the resource-scarce mobile node. Is it
> assumed in this section that the MNN is the one that performs the RO
> tasks? In that case, and IMHO, introducing changes in the protocol
> operation of the MNNs is even worse than the limited capabilities that
> these nodes may have. OTOH, if the MR is the one that performs the RO
> tasks, although the limited capability problem of the MR remains to be
> valid, I'm not so sure about which nodes we are expecting to play the
> role of a MR. Maybe, it is not the general case that a limited device
> plays that role (for example in a NEMO deployed in a bus or a plane).

Noted, perhaps a more detailed analysis would be required here.  I would
follow up on this with a separate mail by this week.

> 
> 	- The section 4.3 points out the problem of the increased delay during
> handoff that may occur due to NEMO RO. I agree on that, but maybe it'd
> be worth to say that this problem is similar to the one that is present
> in MIPv6. The Route Optimisation mechanism defined for MIPv6 (especially
> because of the Return Routability procedure) also adds latency, but to
> deal with that problem there are other proposals (e.g., FMIPv6 or
> HMIPv6) that are somehow independent to the RO problem.

Well, we expect that in some NEMO-RO proposals, the handoff delay will
be greater.  For instance, consider a node behind 3 MRs.  Certain NEMO
RO proposals may require each of these MR to signal the CA.  Assuming
the signaling delay is d, then the delay for the node is anything
between (d, d+3d), worse than or at best equal to MIPv6 RO.

> 
> 	- The section 4.4 describes the New functionalities that may be needed
> for NEMO RO. It says that the smaller number of nodes required to be
> changed, the better and also points that there are some nodes that would
> be preferred not to be changed (like LFNs). IMHO, maybe it would be
> useful also to say that reusing existing protocols (like MIPv6) would
> make also easier the deployment of new NEMO RO solutions.

Hmm.. I thought that is mentioned somewhere, but perhaps not explicitly.
Noted.

> 
> 	- The section 5.1.1 describes the RO solution involving the MNN and the
> CN. IMHO, I'd say "new functionalities would be required" instead of
> "are required", since for example, MIPv6 capabilities of the nodes may
> be reused in some solutions falling in this category. The same comment
> applies to the section 5.1.2.

Ok.

> 
> 	- The section 5.1.3 says that solutions involving MR and CR may scale
> well, since a single RO session between the MR and CR can achieve RO
> between any MNN and any CN managed by the CR. I don't see this better
> scalability so well, I mean, IMHO there is a trade-off, depending on the
> specific scenario. Of course, if the CR is very close to the CN, the
> route would be very optimal, but in that case, if a MNN is communicating
> to several CN located in different physical locations, then several CRs
> would be needed (so there is here an scalability problem, in terms of
> number of CRs neede). OTOH, if the CR is not so close to the CNs, there
> may be less CRs, but then the optimisation is not so optimal. I see
> something similar with the case described in the section 5.1.4.

You mention a very relevant point about tradeoff of the proximity of CR
to CN.  But the text is not about this.  Worst case scenario is that the
MR/MNN is communicating with one CR per CN.  The number of session
maintained is the same as MIPv6 (i.e. 1 RO-session per CN).  However,
the best case scenario is that the MR/MNN is communicating with multiple
CNs behind a CR.  SO, using a CR would always result in less or at most
equal number of RO sessions.  Thus we say the use of CR scales well.

> 
> 	- In the section 5.2, it is said that the node that is mobile is in the
> best position to detect its mobility, but what do you mean by "mobile"?
> that is physically moving or that is changing its point of attachment?
> Because, if the latter is meant, I don't see a MNN to necessarily be
> always mobile (e.g., a LFN is not). IMHO, the text needs to be clear.

OK.

> 
> 	- In the section 5.3, it is said that the detection of the RO
> capability may incur in additional delay. I suppose that it would be
> dependant on the specific solution, but as I see it, a NEMO RO solution
> would use the NEMO Basic Solution while trying to setup a RO session, so
> I don't see the delay due to the detection capability.

That is if it continues to use the NEMO-BS tunnel while detecting RO.
Some RO proposals may make it difficult to do this, for example a RO
proposal that embed signaling on-plane.  To use NEMO-BS support at the
same, require the MR to duplicate a data packet, one to go through the
NEMO-BS tunnel, one to try the optimized path.  It may not be such a
good idea in this case.

> 
> 	- The section 5.5.2 says that adding new options in Router
> Advertisements is to modify the protocol. IMHO, adding new options is
> just making use of the protocol, extending it with a new functionality,
> since new options can be defined (they would be discarded by nodes that
> do not support them) and implemented easily.

True.  We will look into that.

> 
> 	- As I've pointed out before, I'm not so sure about the applicability
> of the Prefix Delegation and Neighbour Discovery Proxy solution with
> LFNs, since they involve changing the MNN's address when the NEMO moves,
> or am I missing something?

As I responded before, RO this scheme does not support LFN.

> 
> 	- The section 5.8.1 points out that there are some WGs currently
> looking at the concern over the authenticity of addresses. We wrote a
> paper [1] about the general problem of making the NEMO RO secure,
> exploring some possible solution schemes (using CGAs for example, etc.).
> We can extend the paper in form of I-D if the WG considers it useful.

Yes, I think I have read the paper before,  just that I got lazy trying
to seek out the complete bibliography.  Thanks.

> 
> 	Some Editorial comments:
> 
> 	- Page 5, "lesser" instead of "least" in "... of a least cost ..." ??
> 	- Page 5, "Quality of Service" instead of "Quality of Services" ??
> 	- Page 12, "do" instead of "does" in "... the scenarios described in
> Section 3 does so ..." ??
> 	- Page 23: "worthwhile" instead of "worth while" ??
> 	- Page 26: "may be" instead of "maybe" in "... transmission maybe
> disrupted ..." ??
> 	- Page 31: "detailed" instead of "detail" ??

OK.

> 
> 	I have some comments about how MIRON (a NEMO RO particular solution
> cited in the draft that I'm co-author of) is described in the draft, and
> in general about the Mobile Router as a Proxy family of solutions. I'll
> send them in a separate mail.

You are welcomed.  We interpret each proposal in our own way, and its
good to have authors of the proposals referred to in the draft to point
out to us some of our mis-interpretation.  Plus please also remember
that (1) we are trying to be concise, (2) we generalize, and (3) we
document so many different proposals that we probably confuse
ourselves :).

/rgds
/cwng

> 
> 	Hope this helps.
> 
> 	Thanks a lot for writing the draft.
> 
> 	Kind regards,
> 
> 	Carlos J.  
> 
> [1] Securing Route Optimisation in NEMO
> María Calderón, Carlos Jesús Bernardos, Marcelo Bagnulo, Ignacio Soto
> Modeling and Optimization in Mobile, Ad Hoc, and Wireless Networks,
> 2005. WIOPT 2005. Third International Symposium on 
> 3-7 April 2005 Page(s): 248 - 254
>