Subject: RE: Summary Re: [nemo] comments on "Tree Discovery" draft

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Fri, 27 Aug 2004 13:13:25 +0200

Hi Fan:

This is a very good summary. Thanks for it.

Pascal

> 
> 
> Hi, Pascal, Alex and all,
> 
> I have followed this long discussion and want to sort of make a
summary.
> Hope it helps.
> 
> Problem statement:
> When one MR moves to a (nested) NEMO network and wants to connect to
the
> Internet, we need to have an efficient and scalable mechanism for MR
to
> choose which AR to attach to as fast as possible. Note that this
problem
> may share some similarity with others in different scenarios. We need
to
> know whether there is something specific to NEMO here or a more
efficient
> solution works well with this problem in NEMO only but not in other
> scenarios.
> 
> There are several possible solutions to this problem.
> 1. Routing protocol: Routing protocol is running on each MR in order
to
> propagate the connectivity information. However it is heavy in terms
of
> the routing table and slow to propagate and converge when the topology
> changes.
> 
> 2. Detection solution: MR may use BU to discover the usable AR to the
> Internet. Firstly, without any helpful metrics, MR has to randomly
select
> one AR from (maybe) multiple ARs. MR has no idea about AR and may end
up
> with a "bad" (according to its preference) AR even though a better AR
is
> available. Secondly, MR has to start the BU procedure and wait until
> either BAck arrives or an error is detected.
> 
> 3. TD is efficient because MR just needs to make a decision based on
the
> received RA and its preference. No state or routing table is needed.
> However, this doesn't guarantee the connectivity to the Internet (No
one
> does). MR at least needs to wait until the BU procedure succeeds
before
> sending the data packet. A "shadow" tree may reduce the length of the
> routing path inside the nested NEMO, but the resulting tree can be any
> shape because it is totally up to the decision of MR.
> 
> Do I miss something here?
> 
> Fan

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Mon, 30 Aug 2004 17:17:51 +0200

> > For a RO scheme where the HA knows about the path down the nested
> > tree to its MR (like RRH) the MR needs to update its own HA if that
> > path changes.
> 
> So, in the beginning there were bindings HoA-CoA, then there were
> bindings HoA-MNP and now there are bindings HoA-Ad1-Ad2...Adn?
> 
> Do you know which current RO proposals assume that HA uses such "path"
> bindings?
> 
> Such bindings sound like DSR...

Does :) RRH is source routing. This accommodates with quick movements
within the nested tree; it is optimized for maintaining the path to the
outside, as opposed to providing any-to-any; if things stabilize, RRH
can be 'compressed' using local states, allowing to navigate dynamically
between a source route and a transparent (stateful) model, on a per hop
basis.

> 
> > So if a subtree moves, each MR down that subtree rebinds with the
new
> >  path. There is an obvious value in using our DHCP PD draft so that
> > this all happens locally...
> 
> PD together with RRH and TD would actually constitute an entire and
> complete solution for the whole RO space?
> 
> We don't even have a problem description for the RO space (while
> Chartered to do so) but the solution is there :-(
Yes...

> We do have, however, personal drafts gen-ro-model and
nemo-ro-taxonomy.
> Would RRH+TD+PD fit both models?
> 
Taxonomy does not provide a model but attempts to list what was (or
could be?) proposed around, grouped into families. We need to update the
draft but yes, it's all in there.

Gen-ro-model abstracts the solutions to enable a discussion at a higher
level, between those families. It looked good when I read it, but then I
did not make the exercise to map everything in there. I'd need to do the
exercise to be able to give my answer.

Pascal

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Mon, 30 Aug 2004 17:28:16 +0200

> Please clarify... if a leaf MR receives a digest and deduces some
router
> has changed in its upper path, it is this leaf MR that will send RO
> messages?
> 
> Or is it the MR immediately below the MR that has changed that sends
the
> RO messaging?
> 
> Or is it the new MR that appeared that actually sends the RO
messaging?
Sorry Alex, it will depend on the RO solution, and by now we have seen
it all.
In the case of RRH, each MR updates its own HA about the changes on its
egress path. 
There have been proposals where the parent MRs above would all bind to
the HA of the MR below. The associated complexity is detailed in the
taxonomy draft.
 
Pascal