Subject: [nemo] RE: splitting moving networks (was: DND test)

From: "Soliman Hesham" <[email-masked]>
Date: Wed, 24 Mar 2004 21:30:22 -0500

> I think that, first, moving networks in the NEMO sense have a rigid 
 > structure, they just don't separate components from one 
 > another, a basic 
 > definition.

=> Disagree. Where is this definition made? It would be 
a big mistake to make this assumption IMHO. How can 
you say that a moving network will never be divided?
If I have a PAN with 4 devices and one day I left 
2 at home and took 2 with me to work, you're saying 
that this is not _meant_ to work?

 > 
 > I think second that the NEMO context has a kind of support of 
 > "splitting" which is in fact called "nesting" and which is 
 > supported by 
 > a good understanding about how it works.  A PAN can enter a train 
 > entering a ferry and all works; all works also whenever the 
 > PAN gets off 
 > the train (splitting?) and into the ferry, or when the train 
 > gets off 
 > and the PAN back or similar.

=> This is very different from what we're discussing, 
nesting is fine.

Hesham

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 25 Mar 2004 15:12:16 +0900

Hi,

Interesting discussion.

On Wed, 24 Mar 2004 21:30:22 -0500
> that this is not _meant_ to work?

I do understand the issue. Sorry if I repeat myself, but I would like to
try to propose the following actions.

a. May I suggest Vijay to add an issue in his list (although the spec.
is in IESG hands) ?

b. I support open and un-ambiguous standard. So:

b1. I would oppose to add in the NEMO Basic Support spec. sentences
such like:
- 2 MRs do not share the same prefix
- NEMO cannot spit
- etc

b2. To solve ambiguousness, I would rather just say in the top of the
document (a kind of disclaimer) than there is no warranty that NEMO
Basic Support works with configurations other than a single NEMO-link
attached to the Internet via one MR, i.e.:

- multihomed mobile networks (8 cases, as identified by the multihomong
  problem statement, including multiple MRs)

- nested mobile networks [although it's assumed it would, but test
  remains to be done - we will do it in our lab very soon]

- split mobile networks

and that necessary fixes may be done later.

So, everyone is aware that checks remains to be done, and that
additional specs. may be needed for specific configuration [e.g. a
multihoming usage doc), at least in the informational track. Does this
makes sense for everyone ?

> => This is very different from what we're discussing, 

I concur to what Hesham says. Nested is when a sub-NEMO gets into a
parent-NEMO; the sub-NEMO has not the same prefix has the parent-NEMO
and doesnt' get renumbered. Split-NEMO is the opposite: an aggregated
prefix get split in 2 separate entities.

Thierry

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 25 Mar 2004 15:12:16 +0900

Hi,

Interesting discussion.

- split mobile networks

Thierry

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 25 Mar 2004 11:32:27 +0100

Soliman Hesham wrote:

>>  structure, they just don't separate components from one another, a
>>  basic definition.
> 
> => Disagree. Where is this definition made?

In the terminology draft.

> It would be a big mistake to make this assumption IMHO.

IMHO it is a good fixed point on which we can use all sorts of levers.

> How can you say that a moving network will never be divided?

Just assume it; it's like assuming that there will always be a cable on
which to communicate; if there's no such cable then there's no
communication possible at all.

> If I have a PAN with 4 devices and one day I left 2 at home and took
> 2 with me to work, you're saying that this is not _meant_ to work?

It _is_ meant to work. Just make sure you take the device with the MR
sticker with you :-)

I mean, if out of those four devices one is MR all three others are
LFN's, then leaving two LFN's at home will not stop the other LFN to
work just fine when behind the MR.

Also, if the three LFN's are in fact MH's then again it is possible to
leave two MH's at home (in this case they'll actually visit MR's home
link) and have the other MH stay at its home (in the MR's ingress link)
while you're taking the MR and this latter MH with you.

There's no NEMO communication problem, there's no nestedness, there's no
multi-homing and there's no splitting in all this (as long as all
entities stay connected).

  >> supported by a good understanding about how it works.  A PAN can
  >> enter a train entering a ferry and all works; all works also
  >> whenever the PAN gets off the train (splitting?) and into the
  >> ferry, or when the train gets off and the PAN back or similar.
  >
  > => This is very different from what we're discussing, nesting is
  > fine.

Alex

---

From: "marcelo bagnulo" <[email-masked]>
Date: Thu, 25 Mar 2004 15:46:48 +0100

> and that necessary fixes may be done later.

I guess that it should be clearly stated in what configurations the solution
works fine and in which ones is not clear.

Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Thu, 25 Mar 2004 15:46:48 +0100

Regards, marcelo

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 25 Mar 2004 11:32:27 +0100

Alex

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 26 Mar 2004 13:00:22 +0900

On Thu, 25 Mar 2004 15:46:48 +0100

> works fine and in which ones is not clear.

I think we should just state "the solution is guaranteed to work in the
most simple case, a single MR with a single NEMO-link and single
NEMO-prefix. Other configurations may work but are not guaranteed to
work. Necessary fixes are irrelevant to this present document, and may
be addressed in separate documents if need exist".

It's not possible to list the configurations that do not work, because:
- we don't know all the possible configurations
- we don't want to analyse each possible configuration (at least not
  now), it would take  too much time
- the NEMO Basic Support document would become too complex.

Thierry.

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 26 Mar 2004 13:00:22 +0900

Thierry.

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 26 Mar 2004 13:18:46 +0900

> communication possible at all.

Here I agree with Hesham. Even if you prevent it in the spec, people
will do it, because those who will set up the configuration may not be
network administrators (i.e. usual people).

So, it's safe to either: 
1. provide solutions or hints how to do it 

2. say that there is no warranty the spec will work in other cases than
single MR with single NEMO-link.

1. is too complex to address in NEMO Basic Support, so I prefer 2. Other
specs will fix specific cases. 

About stating in the spec something like, "no, you MUST NOT do it", this
is simply a moot statement because it will happen anyway.

Thierry.

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 26 Mar 2004 13:18:46 +0900

So, it's safe to either: 

Thierry.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 26 Mar 2004 10:52:25 +0100

Thierry Ernst wrote:

> On Thu, 25 Mar 2004 15:46:48 +0100 "marcelo bagnulo" 
> <[email-masked]> wrote:
> 
> 
>>> b2. To solve ambiguousness, I would rather just say in the top of
>>>  the document (a kind of disclaimer) than there is no warranty 
>>> that NEMO Basic Support works with configurations other than a 
>>> single NEMO-link attached to the Internet via one MR, i.e.:
>>> 
>>> - multihomed mobile networks (8 cases, as identified by the 
>>> multihomong problem statement, including multiple MRs)
>>> 
>>> - nested mobile networks [although it's assumed it would, but 
>>> test remains to be done - we will do it in our lab very soon]
>>> 
>>> - split mobile networks
>>> 
>> I guess that it should be clearly stated in what configurations the
>>  solution works fine and in which ones is not clear.
> 
> 
> I think we should just state "the solution is guaranteed to work in 
> the most simple case, a single MR with a single NEMO-link and single
>  work. Necessary fixes are irrelevant to this present document, and 
> may be addressed in separate documents if need exist".
> 
> It's not possible to list the configurations that do not work, 
> because: - we don't know all the possible configurations - we don't 
> want to analyse each possible configuration (at least not now), it 
> would take  too much time - the NEMO Basic Support document would 
> become too complex.

I agree, to me there's no need to add more explanations to the base
document about which configs work and which don't.

At the same time, there are several non-multi-homing configurations that
_are_ known not to work with the base protocol, and they have been
identified in scattered public discussions and drafts.  It is also true
that the number of configs to test is potentially illimited, but those
that have been identified seem to me to be relatively basic.

Take for example the "disconnected operation problem" where the TLMR of
a nested aggregation of moving networks becomes disconnected from its
AR; all hosts (be it mobile or fixed) in that aggregation can't talk to
each other even though they are physically connected (they can't because
HAs not available).  This problem has been mentioned from the very
beginning of the Monet BoF IIRC and seems very basic to me.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 26 Mar 2004 10:52:25 +0100

Alex