Subject: [nemo] RO: what have we learnt so far?

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Mon, 8 Nov 2004 12:52:19 +0100

Hi:

As you know, the RO problem has been around since NEMO stated, and so
have been related drafts. 

As a group, we have focussed on delivering basic support, but still
people could not help working on RO. And we learnt quite a few things
overtime.

- We have distinguished various problems to be addressed, and
categorized the (tenths of) solutions that were proposed. We also have
clues about the specific pro/cons of those numerous solutions.

- We have found that before optimizing the tunnels and data path of a
nested tree of MRs, we should make sure that we build the tree and that
the tree is optimized in shape in the first place. We also know that a
MR might not want to attach anywhere and that some clues might be
needed.

We can not just make as if we were 3 years ago, can we? I believe that
we can and we should give more food for thought then just "what's the
problem here?".

This is why the taxonomy is now built in 3 major parts, plus appendix.
The problem statement is obviously the 1st of the 3 major parts. The
bestiary of the solutions types comes next, and finally the pro/cons.
The specific solutions are introduced only in appendix. Some refs are
still missing (like MIRON, sorry), but then again, it's a work in
progress.

Pascal

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 08 Nov 2004 23:32:54 +0100

Pascal Thubert (pthubert) wrote:
>  nested tree of MRs, we should make sure that we build the tree and 
> that the tree is optimized in shape in the first place.

Pascal, do we agree that, in a nested aggregation of moving networks,
they can form _any_ arbitrary graph and that the "tree" you mention is
more about the logical view that is formed when looking for shortest
paths, and less about how the MR's hardware-ly link to each other?  Do
we agree that  there may be no actual tree other than in the mind of the
human describing how the shortest paths are built?  Do we agree that
every MR may have its own limited view of the network (which view may be
a tree) and that this view has nothing to do with the physical hardware
topology on which this _spanning_ tree is built?

> We also know that a MR might not want to attach anywhere and that 
> some clues might be needed.

MR selecting its attachment point is very much like CARD - Candidate
Access Router Discovery.  I don't think MR is different than MH when
needing to attach, and selecting a better or a worse AR based on
synchronized information that those AR's may broadcast.

I don't think MR's need take care when attaching such as to ensure they
form a tree.  I think they should attach to wherever they can attach
first, with as many interfaces as they can.  After attaching, I think
they should exchange information to each other, and propagate the
similar information received from other similar MR's.  Once all this
information is propagated, every MR may build tables with its own
logical view of the network, and find paths with the help of these tables.

Do you think this is wrong?

> We can not just make as if we were 3 years ago, can we? I believe 
> that we can and we should give more food for thought then just 
> "what's the problem here?".

"Tree Discovery" as is now forces the forming of an aggregation of
moving networks that MUST have the physical link of a tree.  This is
simply not scalable for a network.

So while "Tree Discovery" may solve a problem that is important, it may
itself introduce much bigger problems than it actually solves.

Am I wrong somewhere?  And of course we can discuss this also
face-to-face here.

Alex

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 09 Nov 2004 13:09:05 +0100

Dear Pascal,

	I've read the draft and I've some comments.

	First, thanks for the new version of the draft. I think that this new
version is much better than the previous one and it's closer to the
charter requirements.

	Here they are my comments (I also include some minor typos I've found):

	- Section 2.2. It says "effects of sub-optimal routing with NEMO Basic
Support is amplified" I think it should be "effects of
   sub-optimal routing with NEMO Basic Support are amplified"
	- Section 2.4. The title is "Communications within a Mobile Networks".
I think it should be "Communications within a Mobile Network"
	- Section 3.2. I'd remove any reference to a specific proposed solution
in the text, like [10] or [11], as IMHO in this section you are
describing the solution space, but without referring to any specific
proposed solution. IMHO, the actual structure of the draft is fine, it
first presents the problem space, then the solution space and finally,
in the annex, proposed solutions are presented, mapped to the taxonomy
presented in the solution space.
	- Section 3.2. It says "through dome". I think it should be "through
some"
	- Section 3.3. I'd would add a bullet with solutions based on Ad-Hoc
routing in the nested NEMO (e.g. something similar to the solution
described in draft-clausen-nemo-ro-problem-statement-00.txt). IMHO,
providing a globally reachable IPv6 address to every MR in the nested
topology (to be used as MR's CoA) and then using an Ad-Hoc routing
protocol to route the packets within the nested NEMO would be a possible
solution to avoid the encapsulation due nesting.
	- Section 4.1.4. It says "In general, it is desirable to keep the
number of nodes that require new functionalities to be kept as small as
possible". I think it should be "In general, it is desirable to keep the
number of nodes that require new functionalities as small as possible"

	And a last comment/question: you said in the mail, that MIRON reference
is still missing... what do you mean? Because in your draft is reference
[15]

	Kind Regards,

	Carlos J.

-- 
Carlos Jesús Bernardos Cano - http://www.netcoms.net
GPG FP: 58C3 4227 AF8D 01D4 5A09  A617 E6F2 B23E DAD6 AA40