Re: [nemo] Question on TD

Masafumi Watari <watari@sfc.wide.ad.jp> Tue, 31 August 2004 15:49 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26633 for <nemo-archive@lists.ietf.org>; Tue, 31 Aug 2004 11:49:03 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2AjY-0005ai-Fu; Tue, 31 Aug 2004 11:39:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2AiJ-0005Pn-G3 for nemo@megatron.ietf.org; Tue, 31 Aug 2004 11:38:27 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25951 for <nemo@ietf.org>; Tue, 31 Aug 2004 11:38:24 -0400 (EDT)
Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2AkJ-00065V-54 for nemo@ietf.org; Tue, 31 Aug 2004 11:40:31 -0400
Received: from localhost (style.sfc.wide.ad.jp [2001:200:0:8801:202:b3ff:fe87:cb44]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id F3EFB5D1B9; Wed, 1 Sep 2004 00:37:53 +0900 (JST)
Date: Wed, 01 Sep 2004 00:37:35 +0900
Message-Id: <20040901.003735.74751084.watari@sfc.wide.ad.jp>
To: pthubert@cisco.com
Subject: Re: [nemo] Question on TD
From: Masafumi Watari <watari@sfc.wide.ad.jp>
In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC104334@xmb-ams-337.emea.cisco.com>
References: <7892795E1A87F04CADFCCF41FADD00FC104334@xmb-ams-337.emea.cisco.com>
Organization: Keio University
X-Mailer: Mew version 4.0.68 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 386e0819b1192672467565a524848168
Content-Transfer-Encoding: quoted-printable
Cc: nemo@ietf.org, ernst@sfc.wide.ad.jp, montavont@clarinet.u-strasbg.fr
X-BeenThere: nemo@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: NEMO Working Group <nemo.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nemo>, <mailto:nemo-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:nemo@ietf.org>
List-Help: <mailto:nemo-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nemo>, <mailto:nemo-request@ietf.org?subject=subscribe>
Sender: nemo-bounces@ietf.org
Errors-To: nemo-bounces@ietf.org
Content-Transfer-Encoding: quoted-printable

Hi all,

On Tue, 31 Aug 2004 14:24:20 +0200,
"Pascal Thubert (pthubert)" <pthubert@cisco.com> 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: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Thierry Ernst
> > Sent: mardi 31 août 2004 05:57
> > To: nemo@ietf.org
> > 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