Subject: [nemo] Announcing Tree Discovery

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Mon, 17 May 2004 14:07:49 +0100

Hi:

Please note that a new draft has been published:
http://www.ietf.org/internet-drafts/draft-thubert-tree-discovery-00.txt

Summary:
   The purpose of this paper is to describe a minimum set of features
   that extends the Nemo basic support in order to avoid loops in the
   nested Nemo case. As a result, Mobile Routers assemble into a tree
   that can be optimized based on various metrics.

NEMO basic support does not address the formation of loops as MRs attach
to other MRs indiscriminately. This draft proposes a solution to that
problem, primarily as a complement for NEMO basic support, as opposed to
an RO solution. Nevertheless, shaping the tree optimally is critical for
the forthcoming RO solution.

Pascal

---

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 17 May 2004 16:04:35 +0200

Hi Pascal,

i have been reading the draft and i have some questions about it. Here they
go...

- about the clusterhead: why is it useful to include the fixed AR as the
clusterhead when it is possible. I mean, this would imply that every time
the nemo moves, you have to rebuild the tree. OTOH, if the clustehead is the
root MR, the tree could be preserved through movement. After all, the sub MR
are just MNN of the parent nemo, so they shouldn't be aware of the parent
movement, right?

- about the nodes and leafs of the tree. It is stated in the draft that:
   " The nodes of the tree are Mobile Routers, the root is
   either a fixed or a Mobile Router, called in the latter case the root
   Mobile Router in NEMO terminology [6]. The leaves are mobile or fixed
   hosts, called Local Fixed Nodes, Local Mobile Nodes and Visiting
   Mobile Nodes in the NEMO terminology."

My first point here is that there is an IMHO important difference between
fixed hosts and Local Fixed Nodes (and also between mobile hosts and LMN and
VMN) and that is that AFAIU, MNN can be routers while fixed and mobile hosts
can only be hosts (i guess)
IMHO this is important in this case, because i clearly see that MR are nodes
of the tree and that hosts are leaves of the tree, but what about MNN that
are routers, that is a fixed router within the nemo, is this a node or a
leaf of the tree?
This is also relevant in the case that for instance the access router of a
nemo is not a MR, for instance.

If fixed router within the nemo are not part of the tree, then i am not sure
how useful is this approach to fulfill the first goal stated in the draft:

"  One of the usage of the new option introduced in this document is to
   distribute information on the hierarchy of MRs. This information can
   be distributed to ARs, MRs and MNNs as well in order to allow better
   route selection and to increase the knowledge of the Nemo topology on
   each node."

I mean the tree will not contain all the hops in the path, but only the MR
in the path, so, the shortest path according the tree may not be the
shortest path in terms of hops, for instance.

- about the support of non-MR. I guess that by non-MR you mean fixed routers
within the nemo, right?
The proposed solution that uses an extension of the RA, requires that all
the routers within the nemo are upgraded, right? i mean, MR are part of the
tree so they need to build it, so they need to be upgraded, but non-MR also
need to be upgraded, since the need to copy the option, right?
Wouldn't it be possible to use other ICMP message with a broader scope so
that you don't need support from non-MR? this would, IMHO, simplify adoption
but it would also provide a more robust solution, since in the present
proposal, if one of the router within the nemo doesn't support the protocol,
this would mean that the tree information is lost and the loop prevention
mechanism can fail, right?

- Finally, there are several fields in the proposed TIO format that i am not
sure what they are used for:
The G and the H bits, the Path digest. And what is the difference of the
Boottime random and the treeid? i mean why cannot be the treeid be used
instead of the boottiemrandom

Thanks, marcelo

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]]En nombre de Pascal
> Thubert (pthubert)
> Enviado el: lunes, 17 de mayo de 2004 15:08
> Para: [email-masked]
> Asunto: [nemo] Announcing Tree Discovery
>
>
> Hi:
>

---

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 17 May 2004 16:04:35 +0200

Hi Pascal,

Thanks, marcelo