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

From: "Tan, Tat Kin" <[email-masked]>
Date: Sat, 17 Apr 2004 13:14:34 +0800

Hello,

I was reading the NEMO Basic Support Protocol
draft-ietf-nemo-basic-support-02.txt and on page 7 where a statement was
describing :

"If the mobile network has more than one IPv6 prefix and wants the Home
Agent to setup forwarding for all there prefixes, it includes multiple
prefix information options in a single 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? Will there be any risk
associate of setting up such large scale? My concern also goes to the
performance whereby could this be potentially delaying the binding
processes?

Million thanks.

Rgds,
Tatkin

---

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Mon, 19 Apr 2004 09:20:37 +0100

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: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Mon, 19 Apr 2004 09:20:37 +0100

Hi Tatkin, 

Pascal

---

From: "Tan, Tat Kin" <[email-masked]>
Date: Mon, 26 Apr 2004 11:47:16 +0800

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). 

First, how will the 10 or 20 networks know there needs an update and
hence trigger the sending of BUs? 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
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?

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...?

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 :)

Thanks.

rgds,
tatkin

-----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

Hi Tatkin, 

Pascal

---

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

> From: Tan, Tat Kin [mailto:[email-masked]]
> Sent: lundi 26 avril 2004 05:47
> To: Pascal Thubert (pthubert); Alexandru Petrescu
> Cc: [email-masked]
BU
> 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. 

> 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
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...

> 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.

> 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...

> it might just be too confusing :)
I really like your thinking. Thanks for all.

Pascal