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

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 26 Aug 2004 16:59:04 +0200

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: jeudi 26 août 2004 16:31
> To: Pascal Thubert (pthubert)
> Cc: Fan Zhao; [email-masked]
> Subject: Re: [nemo] comments on "Tree Discovery" draft
> 
> Pascal Thubert (pthubert) wrote:
> > The so called RA confliction is just a very narrow instance of the
> > loop problem.
> 
> I'd say the reverse.  The RA confliction problem is more generic and the
> Jari problem is very narrow; RA confliction description involves only
> one router and with it says all, no need to depict three routers to
> express the same problem.
> 
> RA confliction problem has a MR with two wireless interfaces.  The
> egress interface receives RA from the ingress, configures CoA and sends
> BU over wireless towards its own ingress interface, receives it, and
> will not encapsulate it again towards its egress interface because it
> has not yet received a BAck.  Actually this BAck will never come so no
> loop nor infinite encapsulation.
> 
> The RA confliction problem assumes that the egress and ingress interface
> of MR can talk to each other wirelessly.  In 802.11b this is the case
> _only_ if they both use ESSID, or same keys, or same ad-hoc mode, or any
> other same something.  This is bad configuration, not bad protocol.
> 
> Please disagree with a more exact setup using any wireless techno.

It's very easy for a MR to detect a loop with itself. The RA has its own prefix and in MIP, it's own address. Since the prefix is already present on the ingress interface, the router will not create an address and a connected route on the egress. This, no effect. What is impossible for a MR is that 3 hops away in a chain of careof, there's itself again.

> 
> > Jari's case had 3 routers forming careofs from each other in a loop.
> >  No way out. The discussion was that since they can not bind, one
> > would eventually try a careof from an available AR and make it.
> 
> YEs, and at this exact point, when this successful MR connects to AR it
> cuts its egress connection to any other MR (keeping its ingress).  Thus,
> no loop.
> 
> > Then another would eventually use that successful MR and bind via it,
> >  etc...
> 
> Fact which does not lead to a loop.
Yes, this is the reason why we could neglect the issue. Please see the slides on the nemo site: 
http://www.mobilenetworks.org/nemo/ietf60/nemo-ietf60-RO-TreeDiscovery.pdf
 
You'll fond my words:"
Without a coordination
- the startup of a nested nemo is very slow
- the shape of the resulting tree is not optimized
"
This is what TD is improving. Quite dramatically.

Pascal

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 26 Aug 2004 17:46:29 +0200

Pascal Thubert (pthubert) wrote:
> It's very easy for a MR to detect a loop with itself. The RA has its
>  own prefix and in MIP, it's own address. Since the prefix is already
>  present on the ingress interface, the router will not create an 
> address and a connected route on the egress. This, no effect.

Ok.

> What is impossible for a MR is that 3 hops away in a chain of careof,
>  there's itself again.

Ah, I see.  Can we talk about only two MR's instead of 3?

So assume two MR's like this:

   +---> MR1 -> MR2 ->+
   |                  |
   +------------------+

MR1's egress is to MR2's ingress and MR2 egress is to MR1's ingress.

MR1's BU goes to MR2.  And MR2's BU goes to MR1.  Neither MR1 nor MR2
will send those BU's any further because none has received the
corresponding BAck's expected from their respective HA's.

So this is not a "loop" but a sort of a deadlock.  What else would one
expect from a topology set in a loop.

A protocol - whatever that is - can not prevent people from arranging
computers in a certain way such that nothing works.

> http://www.mobilenetworks.org/nemo/ietf60/nemo-ietf60-RO-TreeDiscovery.pdf

I've studied them once posted.  Nice graphs.  They seem to be optimizing
something but not raising any actual unsolved problem.

In a nested aggregation of moving networks, any number of MR's, any
number of interfaces per MR, forming any arbitrary topology, all MR's
will be able to send their BU's as long as each one uses a unique
default route.  This can be guaranteed by designating a unique interface
on each MR to be _the_ outgoing (or egress) interface.  There will be no
loops.

If, on the other hand, I think about the dangers of each MR changing its
default route at the reception of a new RA on a different interface,
then there can be instabilities, loops, etc.  This may be seen as a
problem at the first glance.

But then if I think about this as fixed routers, not MR's, that form a
graph, they'd still have the same problems.  Fixed routers manage this
with routing protocols, or statically assigned routes.  And even so,
they'd always have a unique default route.

"Preventing loops in nested NEMO topology"

I don't think there are loops in a nested NEMO topology as long as each
router uses a unique default route.

"Optimize Default Route selection into shallow trees"

Why shallow and not deep.  Anyways, seems to be about optimizing, as I said.

"Attachment selection fixed vs Mobile Router"

What?

"Which metrics"

This is indeed a good question.  Hop count is a good metric.

"Fast reconfiguration upon movements"

Brings back our other issue about movements.  Your optimization seems to
imply that there are fast movements that are inducing some drawbacks and
that TD may keep up with those fast movements (while other solutions may
not).  That's maybe a problem, but let's define it, see it in practice
and only then optimize it.

Or does it mean that only a unique minor movement of one MR may induce
large changes in the routing tables of the nested NEMO aggregation and
OSPF does not cope with, while TD does?

> You'll fond my words:" Without a coordination - the startup of a 
> nested nemo is very slow - the shape of the resulting tree is not 
> optimized " This is what TD is improving. Quite dramatically.

Ok, I think TD is a solution but we're not quite sure about the problem.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 26 Aug 2004 18:09:33 +0200

> This is what TD is improving. Quite dramatically.

Come on, in what is a shallow tree better than a "resulting tree" and
better than a deep tree in terms of NEMO?

This risks seeing a DT (reverse TD) proposal that builds a deep tree
instead, and claiming also that it's better.

Is there a NEMO problem in having arbitrary-tree topologies of nested
moving networks?

Besides, if there are loops in any nested aggregation of moving
networks, they obviously don't depend on the tree being shallow or deep...

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 26 Aug 2004 17:57:43 +0200

TD draft:

> In order to build trees of Mobile Routers, we propose an extension to
>  the ICMP Router Advertisement (RA) message, the Tree Information 
> Option (TIO). The RA/TIO allows MRs to advertise the tree they belong
>  to, and to select and move to the best location within the available
>  trees. MRs propagate the TIO down the tree, updating some metrics 
> such as the tree depth, leaving alone root information such as the 
> tree identifier, and sending the result in RAs over the ingress 
> interfaces.

Propagating information from a received RA down in another RA is getting
TD out of the scope of ND (of which it is a "minimum extension") in a
quite substantial way.  ND is scoped to a link only. (RFC2461: "IPv6
nodes on the same link use Neighbor Discovery").

A large number of proposals for many NEMO aspects rely on some form of
propagating RA information.  Outside NEMO too, the HMIPv6 MAP option.

(I think that whenever there's a need to propagate RA information, one
can better do with routing protocols.  But in the TD case, I'm not sure
about the problem itself.)

So let's define a problem first, before enforcing a solution, no?

Alex