Subject: RE: [nemo] Questions on multiple mobile network prefixes in a BU

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Wed, 28 Apr 2004 16:19:38 +0100

> -----Original Message-----
> From: Tan, Tat Kin [mailto:[email-masked]]
> Sent: lundi 26 avril 2004 05:47
> To: Pascal Thubert (pthubert); Alexandru Petrescu
> Cc: [email-masked]
> Subject: RE: [nemo] Questions on multiple mobile network prefixes in a
BU
> 
> Hello Pascal and Alex,
> 
> Thanks for both your explainations. I still have further questions if
> you do not mind.
> 
> With what Alex had explained, that if there is 10 or 20 different
nested
> networks then each of the MR of these 10 or 20 networks will send its
> own BU for updates and not all consolidated into 1 single BU by the
> upper most (in this text, the term "aggregated" is used).

Note that you can not aggregate in classical terms unless you know that
all the longer prefixes are below you, or that but some that are
advertised separately. I'd rather use the word consolidated. 

> First, how will the 10 or 20 networks know there needs an update and
> hence trigger the sending of BUs? 

With nemo basic, if your careof does not change, you do not need to
rebind. Meaning that there a change high above you or below you in the
tree, you do not need to know and rebind.

But this happens at the cost of nested tunnels. If you want to do nested
NEMO RO, it's a different story. You need to know, and depending on the
solution, you may need a number of BUs. This is explained in the RO
taxonomy draft
http://www.ietf.org/internet-drafts/draft-thubert-nemo-ro-taxonomy-02.tx
t (see 5.1 Nested Tunnels Optimization), and there's a solution for the
problem in
http://www.ietf.org/internet-drafts/draft-thubert-nemo-reverse-routing-h
eader-04.txt. 

So there is a need for some new messaging in nested Nemo to know that
something above you has changed. There are a number of drafts that
suggest extending RA, including RRH, HMRA... You'll soon find a new one
called tree discovery :)

> If the 10 or 20 networks were told to
> update by some mechanism such as the upper most MR sending out
> information telling all its lower link to update, then would this be
too
> much overhead interms of BU traffics? If this is true, this also mean
See  
1.  Binding Update storm   in 
6.2 Recursive complexity in route optimization  in the RO taxonomy
draft.
Avoiding the storm is one key design point for RRH...

> the moving of the entire NEMO is not transparent to the networks
within?
> The objective of the NEMO isnt it true that is to make the move of the
> network transparent to other nested network within?
I guess that RO contradicts that postulate, though it's true for basic.
But basic does not know how to avoid loops... Also, MRs may not trust
each other and the MNP may be 'home' in various places of the world. So
I do not see MRs proxy registering for other nested MRs when the move...

In the other hand, there are local mobility management solutions. For
Nemo, you may want to look at
http://www.ietf.org/internet-drafts/draft-droms-nemo-dhcpv6-pd-01.txt
which can be seen as a NEMO version of HMIP.

> 
> Second, based on the assumption of first question, will more security
> concerns be arise if the upper most MR is moving constantly (from
> Network A to B and then to C ....and so on), and the inner networks
that
> updating the BU is being confused? (inner network may still be
updating
> Network A while upper MR is already in C maybe....) ? Maybe this
> question is not valid since the NEMO objective is to make the network
> movement not a concern to inner networks...?
We will need a pretty efficient mechanism there. I believe that the
question is highly relevant, as part of the RO effort. But the solution
is not in our charter, and may not be MIP based (its more like and
efficient adhoc stuff based on the nested tree...

> I agree with Pascal's suggestion that to make a clean trees and then
> later worry abt the idea of proxying BU. Somehow, thoughts just came
and
> it might just be too confusing :)
> 
I really like your thinking. Thanks for all.

Pascal
> -----Original Message-----
> From: Pascal Thubert (pthubert) [mailto:[email-masked]]
> Sent: Monday, April 19, 2004 4:21 PM
> To: Tan, Tat Kin; [email-masked]
> Subject: RE: [nemo] Questions on multiple mobile network prefixes in a
> BU
> 
> 
> >> My question is, how can this be achieved? I mean if there is 10 or
20
> different nested networks are within that moving networks and could a
> single BU be able to cater all information?
> 
> Hi Tatkin,
> 
> I will not paraphrase Alex since I had a chance to read his mail and
> agree with his answer concerning the coverage of the nemo basic
support.
> 
> 
> But I must admit that like you, I toyed with the idea of proxying BU
> prefix information, in the context of nested RO. Note that there's a
> number of issues to fix first like loop avoidance. I suggest we start
> looking at making clean trees of mobile routers and then we know that
we
> can start proxying/bridging is a loopless fashion.
> 
> Pascal

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 29 Apr 2004 00:10:54 +0200

Pascal Thubert (pthubert) wrote:
> I guess that RO contradicts that postulate, though it's true for 
> basic. But basic does not know how to avoid loops...

Loops with basic nemo support have been mentioned here at least twice.
The earliest mention I know of was autumn last year (J. Arkko) in an
email to nemo and then in the winter by E. K. Paik in
draft-cho-nemo-hmra named "RA confliction problem".

I've looked closely at both concerns and it is still unclear to me how
the looping problem can be defined and potentially solved.

In order to reduce the problem scope, I can say that its simplest form
appears when a single MR is in a visited network and has one egress and
one ingress interface, both wireless.  The RA's sent by the ingress
interface may be received by the egress interface (on the wireless air
space between the two antennas) and then the egress interface configures
a CoA (by the nemo and mip6 specs) that is valid in the internal link;
thus making a sort of loop.

Initially, I was thinking that such a problem has little chance to occur
in practice with 802.11b because when one configures such a router s/he
is forced to determine two different L2 networks for the two interfaces
(via essid/enc) and thus the egress interface could not receive the RA's
of the ingress interface.

True, restricting the reasoning to 802.11b exclusively is little
relevant to an IP solution that shoudl work over several wireless types.
  But imposing hte multiplicity of wireless links as a requirement is
even more advantageous for avoiding the existence of loop problem: if
egress is CDMA and ingress is WLAN then there is absolutely 0 chance for
egress to receive RA from ingress.

IMHO, that's what I think right now about the looping problem, looking
for a better definition.

So, I take advantage of your mentioning of the looping problem to ask:
how do you Pascal think more exactly the looping problem looks like with
nemo basic, thanks,

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 29 Apr 2004 00:10:54 +0200

Alex