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

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Tue, 9 Nov 2004 15:22:49 +0100

Hi Carlos :)

Thanks a lot for this review. Chan-Wah and I discussed quite a bit on the light of other Pb Statement drafts and we agree that the MANET based approach did not get a fair treatment in ours. We need to improve on that, maybe comparing with LMM based approaches, which provide quite similar results - the "flatten" the nested tree from the standpoint of the outside.

For LMM based (say DHCPv6PD+NEMO), you need a LMM enabled node close the AR. This would have to be deployed pervasively, on the Access Provider side. But there's no need for a new standard to deploy on the MR side since both PD and NEMO are used as is. The only addition that could be needed is about locating the LMM box.

OTOH, for MANET based, the difficulty is opposite: you need all nodes to agree on a given MANET, one that can transport prefixes and provides a solution for the default route; but a gateway might or might not be needed on the Access Provider side, hopefully not.

As a result, we see that the adoption of one approach vs. the other could depend on the deployment. For a vertical, it could be doable to force a same MANET in all boxes. For a consumer service, it could be easier that the SP deploys LMM boxes around.

Comments anybody?

BTW, yes, we have a ref on MIRON and other drafts but we lacked some naming them at the right place in the appendix. Next version will be better. Hopefully we'll have some experience from you in there as well :)

Pascal
> -----Original Message-----
> From: Carlos Jesús Bernardos Cano [mailto:[email-masked]]
> Sent: mardi 9 novembre 2004 13:09
> To: Pascal Thubert (pthubert); [email-masked]
> Cc: IETF NEMO WG
> Subject: Re: [nemo] RO: what have we learnt so far?
> 
> 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.
> 
> El lun, 08-11-2004 a las 12:52, Pascal Thubert (pthubert) escribió:
> > 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
> --
> Carlos Jesús Bernardos Cano - http://www.netcoms.net
> GPG FP: 58C3 4227 AF8D 01D4 5A09  A617 E6F2 B23E DAD6 AA40

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Fri, 12 Nov 2004 15:25:58 +0100

> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: lundi 8 novembre 2004 23:33
> To: Pascal Thubert (pthubert)
> Cc: IETF NEMO WG
> 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?

YES

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

Yes. Making MH aware of a Nested NEMO or a mesh could improve the
overall operation.

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

How many interfaces (radios?) do you think the MR has? As many as
adjacent MRs? If that was so, then yes, they can form a MANET, and if
that MANET provides a default route out, we are done. We will improve
the RO taxonomy draft to describe that. 

You might see TD as a specific MANET, very fast because it's dedicated
to the default route. 

But actually, the MR MIGHT NOT have enough interfaces. If so, attaching
the radio to the right AP(s) might be critical.

> 
> Do you think this is wrong?

I think it was based on inadequate assumptions.

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

You seem to be mixing problems here. TD does not cover internal RO
within the nested nemo. The tree comes from the fact that at the moment,
NEMO forms a single primary CareOf address, so the NEMO nested structure
IS A TREE. When we have more then one CoA, we'll build overlapping
trees, forming a DAG, as FAN explains in PS draft, when they all exit at
the same root. 

> 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.
> 
I think that THIS discussion is relevant on the ML. I do not understand
from your text that TD introduces any problem. NEMO MRs have to form a
tree, it's not TD's fault.

Pascal