Subject: RE: [nemo] Announcing Tree Discovery

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Tue, 18 May 2004 08:47:18 +0100

> -----Original Message-----
> From: marcelo bagnulo [mailto:[email-masked]]
> Sent: lundi 17 mai 2004 17:49
> To: Pascal Thubert (pthubert); [email-masked]; [email-masked]
> Subject: RE: [nemo] Announcing Tree Discovery
> 
> 
> > Seems you are assuming the specific case of group mobility. If this
> > happens, I expect that the TIO will carry a GID and that the members
of
> > the group will prefer a tree sourced at GID as one metric. In that
case,
> > the root MR may omit forwarding the TIO from AR and set itself
> > clusterhead. This policy is allowed by the draft.
> 
> Ok, i didn't read the draft that way...
Actually you're right, 

the draft is not too clear about that. I have to fix it. Any router can
be clusterhead if it finds that the available clusters are not good
enough. And if a root MR has internet connectivity to an AR, it can
forward packets to the infrastructure. I hope that this much is clear
enough.

But you are right that a MR can not be clusterhead and then attach
anywhere in a tree without joining that tree, otherwise it would create
loops. The only case where it's valid for sure is when the clusterhead
attaches to a fixed AR, whether that fixed AR advertises itself as
clusterhead or not. This needs additional wording. Thanks :)

> 
> >
> > On the other hand, it may happen that MRs move arbitrarily regarding
> > each other, e.g. cars in a city. In that case, you may want the
> > clusterhead to be a fixed antenna.
> 
> This is the case that i don't understand why would you want that?
> I mean, if the clusterhead is a fixed AR then when the nemo moves it
has
> rebuild the tree, right?
> So what is the benefit of doing so? I am not saying that the draft
should
> prevent this situation, but it seems to me that you may have
considered some
> scenario where this configuration may be useful and provide some
benefits,
> if this is so, could you describe it?
> 
In fact, yes, very much so. Some is related to RO but I do not want such
discussions to cloud tree discovery and make it look like it's an RO
feature, since it's required for nemo basic, imho.

The classical use case is cars in a city. Cars do not move as a group,
so if a car drags a tree, the other (not necessarily moving) cars will
have to jump all the time. Having a fixed AR as clusterhead stabilizes
the situation and enables parked cars to relay for moving ones.

As for RO, once a tree is built around a fixed antenna, you may use the
antenna for Local mobility management. For instance, a fixed clusterhead
is ideally placed to be the DHCP-PD + Home Agent in our nemo LMM draft
http://www.ietf.org/internet-drafts/draft-droms-nemo-dhcpv6-pd-01.txt .

Finally, a car may stay for a while in a radius around a few blocks,
even if the immediate vicinity with other cars changes rapidly. So a car
may be able to stay within the same tree if that tree is based on a
fixed antenna; this enables all sorts of routing, within the tree and
between clusterheads. In fact, this is why I call these clusterheads in
the first .

> >
> [...]
> 
> > Right, we have to discuss the role of local fixed nodes that are
> > routers. A plain router like that will not know about the TIO and
will
> > drop it. In turn, it may be mistaken for a fixed AR by a roaming MR.
> 
> I an not parsing the last sentence, sorry...
Just acknowledging your words. A legacy router will be mistaken for a
fixed router even if it is permanently attached to a MR and moving with
it. So I guess a roaming MR should always prefer an Attachment Router
with TIO, be it fixed or mobile. But in order to prevent loops, it is
also recommended that legacy MR be configured not to accept roaming MRs,
what can we do, right?

> 
> > So
> > I guess this limits the role of such routers as stubs. This is the
> > assumption in the draft, they are leaves. But maybe we could devise
a
> > new class of lfn routers, that would propagate TIOs
> 
> I understood that this is what it is required in order the mechanism
to
> work, as described in section 4.2 when talking about non-MR... So just
to
> clarify the discussion what do you mean by a non-MR in section 4.2?
> 
> My concer regarding this point and the next one is how does the TD
works
> when a router LFN exists in the nemo

Understood and agreed with the concern, though I saw it as secondary for
the lack of use cases.

This is one discussion where help from the group would be appreciated.
We already simulated that draft, and actually that was a concern. We
ended up moving the TIO support from a MR feature to a ND optional
feature for all routers. It may be harder to move it to IETF that way,
though.
 
The same question arises for a MR that is at home in a tree. Should it
propagate TIO? Should it increase the depth? We started with no for both
and ended up with yes for both. Really we have to weight this as a group
and make a decision.

> 
> IMHO I guess that there are two cases here:
> 
> - when a router LFN doesn't support the TD in any form
> - When a router LFN supports the TD
> 
  and when a MR is at home in a tree (mobile home stuff) as a third

> According to the draft the TD has two goals,:
> - Loop prevention
> - enhanced route selection
> 
> IMHO the loop prevetnion is critical, while the enhanced route
selection is
> one of those nice-to-have features.
Yes

Actually we try to avoid the enhanced thing. We intend to present just
the mere common part, not a specific route selection. We have a number
of algorithms for various use cases. One is cars (again) where all you
want is minimizing the depth with optionally some stickiness to a given
antenna, one is the fleet where the infrastructure connectivity is
secondary, but you want a managed tree (thus the preference), an other
one is a group of tourist where a group ID is critical... But all those
need to share the core presented in the draft.
> 
> IMHO the support when there are router LFN in the nemo would be that:
> 
> - the loop prevention doesn't breaks
> - get as much as possible of the enhanced route selection as possible
cool

> As far as is understand in its current form, the proposed TD
mechanisms
> breaks if a router LFN that doesn't supports TD exists in the nemo,
right? 
> This is beacuse, the the non upgraded router LFN won't forward the TIO
> opction so, the tree discovery mechanism will be broken, right?

Well, they are supposed to reject visitors (eg no RA or M bit),
otherwise yes, exactly.

> 
> I guess that it would be better to have a more robust TD mechanism
that
> supports non upgraded router LFN in the nemo. This would require using
some
> other signaling instead of using a RA option. The new signaling
message
> shouldn't be link scoped but its scope should be the nemo.
Not too easy to do. And remember you want to be damn quick and
efficient. Sometimes, an apparent beauty results in a living nightmare.
My proposal is to leave those as leaves and see what we can do for case
2 (LFN Router with TD) and 3 (MR at home within tree).

> But before discusin options about how to do this, do you agree that it
would
> be intersting that the TD mechanism can support non upgraded routers
LFN?
Not really. Being a MR is pretty cool. Can add features like RO to the
picture. Again I need a convincing use case. TD builds the tree
dynamically and is you support RRH, you can source route down that tree.
TD on MRs (even more with an RO solution like RRH in place) results in a
pretty efficient feature and I would definitely enable MR on all boxes
in a roaming cloud.

> 
> The other issue is about enahnced route selection.
> I am not sure that we can do much when we have to deal with non
upgraded
> router LFN in this case, but i guess that including upgraded router
LFN in
> the tree topology would provide more information about intermediate
hosts,
> so the selection would be improved. So i guess that all the routers
that
> support the TD mechanisms could be included in the tree as a form to
provide
> more detailed information for route selection support.
Yes, this seems reasonable and we have to figure that out. I believe we
should concentrate on that case as opposed to legacy LFN routers. If we
do so, again, this impacts all routers, making it harder to move forward
at IETF...

> 
> [...]
> 
> > Boot time random is used for collision avoidance but can not be used
to
> > identify a root MR. On the other hand, the tree id is a constant so
> > other routers may be configured to prefer that tree, referenced by
ID.
> >
> > Path digest changes if the list above you has changed, even if the
depth
> > and tree id did not. This is useful to trigger a BU for instance.
> >
> > The G bit guarantees the connectivity to the infrastructure. An
> > Algorithm that requires internet connectivity will prioritize a G
bit on
> > in AR selection. Now what the infrastructure is context dependent.
Same
> > context as that allowing the L2 access, hopefully.
> >
> > The H bit is informational for the time being. We have to discuss if
a
> > MR with H on actually incremements the depth. But there's no
practical
> > use for it for the time being...
> 
> I may have missed some of this stuff, but if they are not in the
draft,
> including them would provide clearer view of the mechanisms.

Well, chapter 5 explains the collision stuff. In particular 5.3.3 gives
you the extended preference stuff based on the Boot time random. This
seems almost impossible in real life but it is the first thing you get
in a simulation :)

> My pleasure, nice draft.

:)

Pascal

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 18 May 2004 18:57:55 +0200

El 18/05/2004, a las 9:47, Pascal Thubert (pthubert) escribió:

[...]
> between clusterheads. In fact, this is why I call these clusterheads in

Ok, in this case about cars, you are assuming that car A and car B have 
nemos within them and that car A is sort of providing transit for Car 
B´s nemo, i.e. the car A´s nemo is the parent nemo and car B´s nemo is 
the sub nemo, so car B´s nemo attaches to car A´s nemo. If this is so, 
my question is why do you consider that this is a possible scenario, i 
mean why car A would accept car B as a sub nemo? this would be a sort 
of mobile ISP, but i fail to see why this would be possible...

> also recommended that legacy MR be configured not to accept roaming 

IMHO it would be reasonable to assume that all MR support the TD 
mechanism, and also that AR within the nemo also support the TD 
mechanism.
However, i am not so sure that it would be reasonable to assume that 
all the router LFN support the the TD mechanism.
IMHO, both the MR and the AR within the nemo are devices closely 
related with mobility support so i guess that it is reasonable to 
assume that the have proper mobility support. OTOH, router LFN may not 
even be aware of movement. An example of this case for me would be a 
train. In this case, i would say that a possible configuration is that 
there is one MR in the train and then there are some router LFNs inside 
the train between different links inside the train. I guess that it 
would be beneficial if those routers could be just regular routers and 
that the special support is only required in the MR and possible AR.

[...]

> propagate TIO?

nice question...
IMHO when the nemo is at home, the AR within that nemo are AR belonging 
to the fixed infrastructure, so according to this rule this would imply 
that each AR of the nemo that is at home should be a clusterhead on its 
own, right?
But what happens when the nemo moves? in this case, the MR of the nemo 
will become the clusterhead, and the AR within the nemo should announce 
the tree of the mr and not their own, which is reasonable since they 
are no longer a AR of the fixed infrastructure.
I would say that i prefer the first option, since the AR within a nemo 
probably is not as good as a fixed AR in any case, so this is reflected 
in the tree depth in the TIO
[...]

> Actually we try to avoid the enhanced thing.

I agree with you. the critical stuff is the loop prevention.

However, IMHO this is not really reflected in the draft considering 
that the first point in the motivation section is related to route 
selection and the loop detection is the second one.
I would suggest that you put the loop prevention as the first 
motivation and then explicitly state that route selection is just a 
plus, nice to have feature (perhaps put it in a separate section?)
[...]

> Not too easy to do.

agree

>  And remember you want to be damn quick and

Well, basically what is needed here is a mechanism to communicate with 
all the MR of a nemo.
I would assume, as i mentioned earlier that all the MR and all the AR 
within the nemo support the TD mechanism. The problem then is how to 
allow a communication between all those devices when maybe there are 
some devices between that don´t support the TD mechanism.
Using RAdv doesn´t solve this problem since the non upgraded 
intermediate router will not propagate the TIO.
I guess that an option could be to use site scoped multicast for this 
i.e. use messages that are sent to the all router multicast address 
with a site scope. In this way, if multicast is supported in the site, 
it would work even if intermediate routers don't understand the TD 
mechanism.
Note that this option would at least work as good as the RAdv option, 
since, at least all the routers directly connected in the link will 
receive the message, and if multicast routing is available, routers in 
other links will also receive it. Upgraded routers would also forward 
the messages. Moreover, there is no need of upgrading the routers LFN, 
just turn on multicast routing for this multicast group.
since it is assumed that MR and AR within the nemo support the TD, 
intra nemo multicast routing is required, and not inter nemo multicast 
routing is required.

> picture.

MR and AR within the nemo are required to support it, agree.
My concern is about the robustness of the TD mechanism, w.r.t. non 
upgraded devices in the path

>  Again I need a convincing use case.

Do you think it is reasonable that nemos may have legacy routers within 
or you assume that all routers within the nemo will be upgraded?

>  TD builds the tree

Yes but you are assuming that will be able to do so, what about legacy 
routers? you just won't be able to use them within a nemo?

> do so, again, this impacts all routers, making it harder to move 

Well, adding all the routers that support the TD to the tree shouldn't 
be a problem, i guess

regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 18 May 2004 18:57:55 +0200

[...]

[...]

nice question...

agree

regards, marcelo