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

["Pascal Thubert \(pthubert\)" <[e-mail]>]

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:[e-mail]]
> Sent: mardi 9 novembre 2004 13:09
> To: Pascal Thubert (pthubert); [e-mail]
> 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