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

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 06 Sep 2005 13:12:13 +0200

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	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" ??

	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.

	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

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: BFF1 7C7A 6AA7 BCE3 885A  4DF1 ED0C 5952 BF89 B974

---

From: Chan-Wah Ng <[email-masked]>
Date: Tue, 06 Sep 2005 22:33:33 +0800

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.

> solution space (in this section, references to existing solutions are

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

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

> 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

> support it, I think it should be pointed out.

Noted.

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

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

> make also easier the deployment of new NEMO RO solutions.

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

> applies to the section 5.1.2.

Ok.

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

> always mobile (e.g., a LFN is not). IMHO, the text needs to be clear.

OK.

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

> do not support them) and implemented easily.

True.  We will look into that.

> or am I missing something?

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

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

> 	- Page 31: "detailed" instead of "detail" ??

OK.

> 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

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 07 Sep 2005 09:54:51 +0200

Hello Chan-Wah,

	Thanks for your reply. Comments inline...

> references to existing proposals should be moved to Sect 5?

	Yes, that's right. I think that references to existing proposals should
be in the "Analysis of Solution Space" section (section 5).

> bit to make it less confusing.

	OK. I was wrong then. I always think of a VMN as a Mobile Host...

> be supported, they would break session continuity when the prefix is

	Then, IMHO, maybe it would be good to explicitly say in the document
that this RO scheme does not support LFN.

> between (d, d+3d), worse than or at best equal to MIPv6 RO.

	Yes, I agree on the fact the some of the NEMO-RO proposals will
increase the handover delay. What I was trying to point out is that in
Mobile IPv6, the RO also increases the handover delay (Return
Routability, Binding Update, etc.), so this increase is not new in NEMO.
It could be higher than in MIPv6, but it not a new problem, and in MIPv6
they have dealt with it by designing new protocols focused in optimising
the handover delays.

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

	Maybe I missed it ;-) , I'll try to check it.

> equal number of RO sessions.  Thus we say the use of CR scales well.

	OK, I see now. Anyway, I think that it would be also interesting to
include some comments about the problem of scalability and deployability
in terms of number of required CRs (and their location).

> NEMO-BS tunnel, one to try the optimized path.  It may not be such a

	OK, I see. Maybe I was thinking in the way MIPv6 performs RO, in which
the BT is always used until the CN is first signalled with the BU. Maybe
some text clarifying that would be useful in the document.

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

Same comment than in the other case. Maybe it's worth to say that
explicitly.

> document so many different proposals that we probably confuse

	Thanks a lot.

	Kind Regards,

	Carlos J.

---

From: Masafumi Watari <[email-masked]>
Date: Thu, 08 Sep 2005 10:35:55 +0900

Hi Carlos,

Thanks for your comments.   We really appreciate them.

> be in the "Analysis of Solution Space" section (section 5).

The list of issues here are just references to give readers some
information on the fact that there exists solutions which target such
scenario.  We didn't intend to discuss any issues of any solution here.
Do they seem unuseful to you?

> that this RO scheme does not support LFN.

Either that or maybe this example is too solution specific.  I mean,
this is going into a discussion on the tradeoffs of which nodes are
supported and which are not.  I don't know whether we should even
discuss schemes which doesn't support LFNs...

> they have dealt with it by designing new protocols focused in optimising

The problem maybe similar to MIP6, but greater which could be critical
than MIP6.  I would like to rather avoid including such text that may
mislead the readers that the problem is simply the same as that of MIP6.

watari

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 08 Sep 2005 11:06:19 +0200

Hi Watari,

	Please, see comments inline...

> Do they seem unuseful to you?

	The references are not unuseful. On the contrary, IMO they are useful
in a document like this. Nevertheless, I think the reference should be
in the analysis of the NEMO RO space solution, not in the description of
the scenarios, just to keep them separated (IMHO, providing references
in the same section that describes the scenarios may lead to confusion,
since solutions and scenarios are not always in a 1-to-1 relation).

> discuss schemes which doesn't support LFNs...

	The problem is that, IMO, if you don't clarify that some solutions do
not support LFNs, the reader may think that they do (since one of the
advantages of NEMO is providing mobility support to nodes that have
not). I agree, that maybe it'd be better to skip solutions that do not
support LFNs, but I'd suggest to keep them but making clear that they do
not support LFNs.

> mislead the readers that the problem is simply the same as that of MIP6.

	The problem is not "the same", but it is of the same nature than in
MIPv6. Besides, depending on the solution, it could be not greater than
in MIPv6. I think that it could be useful so say somehow that the
problem could be more severe than in MIPv6, but that is of a similar
nature (and therefore, it could be dealt with similarly as well).

	Kind Regards,

	Carlos J.

---

From: Chan-Wah Ng <[email-masked]>
Date: Thu, 08 Sep 2005 18:01:21 +0800

Hello, Carlos, Watari-san,

> support LFNs, but I'd suggest to keep them but making clear that they do

I agree that we should mention such solutions do not support unmodified
LFN, but I think Sect 3.3 may not be the best place.  I am more inclined
to adding that in Sect 5.

> nature (and therefore, it could be dealt with similarly as well).

I would agree to mention that similar delay are experienced by Mobile
IPv6, and also mentioned that principles used in FMIP might be helpful
in countering this.

/rgds
/cwng