Subject: Re: [nemo] Question on TD

From: Nicolas Montavont <[email-masked]>
Date: Thu, 02 Sep 2004 11:51:56 +0200

Hi all,

Sorry for the late reply...

I don't think we should remove the multihoming case in the draft.
If we agree that we need new option(s) to discover and build trees,
it is also important to forward useful information to MNNs for their 
configuration.

As you point out, in a nested NEMO, several encapsulations might be needed.
So, if we could forward the MR's level in RAs, this information may help 
the MNNs to choose their default router, before configuring anything 
(MNNs establishes L2 link and then began the level 3 configuration).

My point here is to consider the nested NEMO issue in its globality: how 
to avoid loops, how to build the trees, how to recover from a failure, 
how to optimize the route selection and so on.

Nicolas

Masafumi Watari wrote:

>Hi all,
>
>On Tue, 31 Aug 2004 14:24:20 +0200,
>"Pascal Thubert (pthubert)" <[email-masked]> wrote:
>
>  
>
>>I agree that the multihoming case in the draft may not be the most appropriate and we might remove it for simplicity (Nicolas, what do you think?).
>>
>>There's still something that surprises me. In the discussions, it seems that the nested tree is taken for granted and then NEMO can start. Here, the MN is connected to the MR, etc...
>>
>>Well actually that's not granted at all. This tree has to be established and maintained. A VMR permanently does its 'DNA' and might change its AR at any time...and that AR can be a MR as well -> a MAR. The question at DNA level might be 'am I connected to the same link'. But for nested NEMO, you want to know what's behind a MAR before you even try it. For instance the level of nesting, or whether you can get to the infrastructure, etc...
>>    
>>
>
>You mean, a MR would want to know where the MAR is connected behind,
>and not what's behind a MAR, correct?
>
>I don't know how to assure that AR or MAR actually provides a path to
>the infrastructure, but knowing the level of nesting before trying to
>connect to is important to avoid forming the nest itself.  We all know
>that the more deeper the nest gets, the more delay it causes to
>packets and the less MTU we have.  If there is more MRs than the MTU
>allows in a tree without any loops, thats what I think is the real
>problem of nested NEMO.  In that sense, TD is one of the solution to
>solve the forming of such state.
>
>BTW, if we allow a fixed router to be attached behind a MR, those
>routers must also provide the TIO with TD.
>
>Masafumi Watari
>
>  
>
>>Pascal
>>
>>    
>>
>>>-----Original Message-----
>>>From: [email-masked] [mailto:[email-masked]] On Behalf Of Thierry Ernst
>>>Sent: mardi 31 août 2004 05:57
>>>To: [email-masked]
>>>Subject: Re: [nemo] Question on TD
>>>
>>>
>>>Hi,
>>>
>>>      
>>>
>>>>"When the NEMO where the MN is connected to is multihomed, the MN may
>>>>have the choice between several AR to be its default router"
>>>>
>>>>What does this mean?
>>>>        
>>>>
>>>I concur, 'what does it mean' ? If a MN attaches to the NEMO (and thus
>>>becomes a VMN from our terminology), its default router is the MR (or
>>>one of the MR if the NEMO is multihomed (cases [n,*,1] from
>>>http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-00.txt).
>>>The AR is the default router of the MR.
>>>
>>>      
>>>
>>>>If MNis connected to a NEMO then it is connected, so it has no choice
>>>>between several AR's.  MN has a default router already.  It's that
>>>>NEMO's TLMR that has choice, no?
>>>>
>>>>Or maybe it is meant that MN may use one of the two MR's (TLMR's) as its
>>>>default route?
>>>>        
>>>>
>>>in which case the default router of the VMN would still be one of the
>>>root-MRs (what some people call TLMR - note that the decision at IETF60
>>>is to remove this term and solely use root-MR).
>>>
>>>Thierr
>>>
>y
>  
>