RE: [nemo] Question on TD

["Pascal Thubert \(pthubert\)" <[e-mail]>]

> -----Original Message-----
> From: Masafumi Watari [mailto:[e-mail]]
> Sent: mardi 31 août 2004 17:38
> To: Pascal Thubert (pthubert)
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [nemo] Question on TD
> 
> Hi all,
> 
> On Tue, 31 Aug 2004 14:24:20 +0200,
> "Pascal Thubert (pthubert)" <[e-mail]> 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?
> 

Sure :) the eye of the beholder. By attaching to MAP, MR would like to see what it really attaches to in terms of nested NEMO.

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

Yes. As you point out, TD is even more critical for NEMO when you do not have RO, since each additional MR means an additional tunnelling. So we really want to optimize for shallowness.

> BTW, if we allow a fixed router to be attached behind a MR, those
> routers must also provide the TIO with TD.
> 

If such a fixed router accepts visitors, yes. If you have a 'legacy' local fixed router that cannot propagate TIOs, then it should have a lifetime of 0, or be hidden from visitors.


Pascal