Subject: RE: [nemo] Question on TD

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Tue, 31 Aug 2004 14:24:20 +0200

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

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

---

From: Masafumi Watari <[email-masked]>
Date: Wed, 01 Sep 2004 00:37:35 +0900 (JST)

Hi all,

On Tue, 31 Aug 2004 14:24:20 +0200,

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

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 31 Aug 2004 18:42:02 +0200

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

RA's have an MTU option and lifetime options.

Maybe routers may advertise an MTU lower than the physical ingress
MTU's capacity, but based on the MTU received on the egress interface
and substracting the size of a base header (the encapsulating header).
In this way, MR's in a nested aggregation would reduce the advertised
MTU down the path.

In this way, a vistiing MR may decide to connect to the AR's whose RA
has the largest MTU, which leads to shallow trees.

But this woudl require again MR to use the MTU of RA different than the
definition of the link-scoped definition of ND.

Instead of using MTU, maybe play with the lifetimes.  Decrease the
advertised lifetime as you go down the path.

Again, the prefix lifetimes are tight to a local link, not currently
related to any other link of router.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 31 Aug 2004 18:46:40 +0200

Masafumi Watari wrote:
> problem of nested NEMO.

But when the MTU is exceeded then fragmentation occurs, it's not that
the nested NEMO does not work.  And, if MTU is exceeded it does not mean
that there are loops.

Agreed, a nested NEMO is less performant if too much fragmentation
occurs.  Avoiding fragmentation may be an optimization problem.
Avoiding fragmentation can be performed in a local manner (ROHC) or in a
distributed manner (distributed ROHC).

Alex