Subject: RE: [nemo] Alternative to TD: forbid MR become AR until BAck received

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Fri, 27 Aug 2004 12:27:04 +0200

Hi Alex;

I agree there's value in looking at that. It could improve both the speed at which things come up and the shape of the result; so it goes the right direction. There are limitations though:

1) nodes in the MNP can not form global addresses till the MR is registered. This prevents a bunch of things including MANET in the nested structure and limits node to node communication to link local. 

2) there's not much control/optimization on the resulting shape.

3) What happens when the TLMR moves and looses access? 

4) The binding lifetime is orders of magnitude longer then RAs that TD uses. So the reaction to changes may take quite some time. You need to write up something more complete to detail your proposal 

5) you know that RRH allows a configuration where a mobile Home Agent is nested behind its own MRs, and that was presented twice at the WG. Your proposal kills this kind if stuff.

Pascal 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
> Sent: jeudi 26 août 2004 18:35
> To: IETF NEMO WG
> Subject: [nemo] Alternative to TD: forbid MR become AR until BAck received
> 
> Hi all,
> 
> I propose that instead of using TD, require MR's to not set Router
> Lifetime in their RA's on their ingress interfaces to zero, until
> they haven't received positive BAcks (don't become AR until BAck).
> Thus, if other MR's attach to it, they know that this MR can not be
> quite used as a default router.
> 
> A MR connected to the Internet is a MR that has a tunnel up to its HA
> and it too has a tunnel to the MR.
> 
> This may help with the not-so-clear looping problem.
> 
> This is a matter of configuration, not any protocol matter.
> 
> Aleex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Aug 2004 12:48:14 +0200

Pascal Thubert (pthubert) wrote:
> 1) nodes in the MNP can not form global addresses till the MR is 
> registered.

First, nodes in the moving network immediately under MR _may_ form
global addresses, they just won't have a default route if the Router
Lifetime is not zero.

All other nodes in the moving network (not immediately under MR) may
form and addresses and default routes towards their respective FR's.

> This prevents a bunch of things including MANET in the nested 
> structure

Which MANET?

> and limits node to node communication to link local.

This is not a limitation.  If the MR is not connected to its HA then
nodes under MR don't have to whom to communicate outside the local link.

> 2) there's not much control/optimization on the resulting shape.

There's no control and no optimization, it just works.

> 3) What happens when the TLMR moves and looses access?

When TLMR moves and looses access then nodes within the moving network
can only talk to each other, this is as natural as it gets.  No node in
the moving network needs to use TLMR as a default router if that default
router is not connected to the Internet.

> 4) The binding lifetime is orders of magnitude longer then RAs that 
> TD uses. So the reaction to changes may take quite some time.

Every 4 seconds the MR can know whether it's connected to its HA or not.
  I find 4 seconds to be enough to avoid loop forming.  You find it's too
long?  Maybe propose something to the MIP6 WG.

> You need to write up something more complete to detail your proposal

Maybe... before starting writing anything I want to be sure there's a
need for that thing, that there's a problem to be solved, that there's
value to customers, that it's priority, that there's interoperability
needed, etc.

> 5) you know that RRH allows a configuration where a mobile Home Agent
>  is nested behind its own MRs, and that was presented twice at the 
> WG. Your proposal kills this kind if stuff.

Huh???

What is my proposal killing more exactly, I don't get it, frankly speaking.

Why mentioning a mobile HA behind its own MR, is this solving
"cross-over tunnel" or something? I wouldn't propose anything against
that...

Alex

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 30 Aug 2004 18:56:22 +0900

Alex and Pascal.

Your proposal works. MR can send RA with router lifetime
set to zero and prefix lifetime set to non-zero.

I found following possible issues. 

When MR stop serving a default route to MNNs even for short time, MNN
sessions will be cut off because of "no route".  Some of applications
cannot recover connectivity.  You can add some modification to MNN to
handle the in-out default route, but it is not easily accepted.

It also has same problem of routing approach of the basic NEMO. NDP
must be aware of the NEMO state. When does MR set router lifetime to
zero? as soon as (re-)sending BU? 

Actually the looping problem is occurred while MR1 lost connectivity
and is retrying BU. Another MR2 can connect to MR1 before giving up
BAck.

I think you just came up with this idea, it will be nice to write
complete spec. as a draft.

regards,
ryuji

At Fri, 27 Aug 2004 12:48:14 +0200,
Alexandru Petrescu wrote:
> 
> [1  <text/plain; us-ascii (7bit)>]
> [2 OpenPGP digital signature <application/pgp-signature (7bit)>]
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 30 Aug 2004 14:03:49 +0200

Hi Ryuji,

Ryuji Wakikawa wrote:
> Your proposal works. MR can send RA with router lifetime set to zero 
> and prefix lifetime set to non-zero.

True.  And thanks to this it is possible for LFN's to autoconfigure
addresses and talk to each other even if they can't talk to CN's on the
Internet.  And this is normal as long as MR is disconnected from its HA.

MR connected to its HA means: MR has a tunnel up with its HA.
MR connected to AR means: MR is connected to AR.

MR can be connected to AR but not its HA.

LFN's are connected to the Internet when MR is connected its HA; it is
not sufficient for MR to be connected to AR in order for LFN's to be
connected to the Internet.

>  sessions will be cut off because of "no route".

It is an issue if you look at it in isolation.

But, if MR does advertise itself as a default router (although it's not
connected to its HA) then MNN sessions will be cut off because of "no
TCP ACK".

For one reason or another, the MNN-CN sessions will be cut off if MR is
not connected to its HA.  It is not the "Router Lifetime 0" in the RA
that makes the MNN sessions to be cut off.  It's because MR has not
received BAck, so having Router Lifetime 0 or non-zero makes no
difference to MNN sessions being cut off.

Not to be forgotten the fact that all sessions between all LFN's within
the moving network will not be cut off if the MR is disconnected from
its HA and MR does not advertise as a default router.

> Some of applications cannot recover connectivity.

Applications that need to recover connectivity when MR re-connects to
its HA are not helped by some packets that LFN had sent and have arrived
at MR (MR simply drops them if no tunnel).  So applications that need to
recover do not care whether the Router Lifetime was 0 or not.

> You can add some modification to MNN to handle the in-out default 
> route, but it is not easily accepted.

I wouldn't write such an application looking at flapping routes either.

>  zero? as soon as (re-)sending BU?

I don't get it... HA runs NDP when it has sent BAck to MN... no?

MR sets ingress router lifetime to 0 always.  Only when it has a
confirmed entry in its BC list (received positive BAck) can it set the
router lifetime different than 0.

>  and is retrying BU. Another MR2 can connect to MR1 before giving up

Could you please explain in more detail?

First, do you agree this is not a true complete "looping problem"?  The
packets will not loop between two MR's, do you agree with this?  Even if
TD is not used, even if the ingress router lifetime=0 is not zero, the
packets do not loop within the MR1-MR2 pair, even if the two MR's are
connected in a looping fashion...

> complete spec. as a draft.

Yes, I've had just thought of it, only to improve somehow the picture
that Pascal was seeing about loops everywhere, and such as to say that
it is sufficient to have some configuration helpers.

About writing a draft... I'm not sure... not until a problem is clearer.

Alex

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 30 Aug 2004 22:03:38 +0900

Alex

At Mon, 30 Aug 2004 14:03:49 +0200,
> connected to the Internet.

right. 

> connected to its HA) then MNN sessions will be cut off because of "no

Yes, if this is the case when MR lost the Internet connectivity.

Can you clarify the timing when MR stop advertising its default router!?
During normal movement detection, the tunnel will be re-established due to CoA change.
It takes certain time of "sending BU and receiving BA" from the movement
detection to the tunnel re-establishment. Does MR stop advertising
default route at the movement detection?  The point is that MR is no
idea whether it can re-establish tunnel right after movement detection.

> difference to MNN sessions being cut off.

right. 

I was talking about normal movement detection (change AR and renew tunnel).
see above.

> recover do not care whether the Router Lifetime was 0 or not.

Slightly different. If MNN keeps a default router, it sends packets to
MR (default router) regardless of MR's tunnel availability. 
Then, MR can buffer certain packets till the tunnel is recovered.  
Or it can just drops these packets without issuing any ICMP error
messages to MNN. In such case, session is still active although TCP
window size will be closed.

On the other hand, if MNN lost its default route, applications get
unreachable error and may stop.

> Could you please explain in more detail?

MR detects movement and sends BU at the time "t1".
It gives up tunnel establishment and stop sending default route at the time "t2".

During "t2-t1", other MR (MR2) can connect to MR1 and will try to send BU via MR1.

I am not clear whether MR stop advertising default router after failure of
single BU or numbers of BU. In latter case, (t2-t1) will not be negligible.
According to MIP6 spec, MAX_BINDACK_TIMEOUT is 32 seconds. 

So my question is when does MR decide to stop default route advertisement?
 
> connected in a looping fashion...

I saw looong discussions on ML and can agree both you and Pascal.
It is true that the topological loop is occurred. But packets are never
looped as you noted.

> About writing a draft... I'm not sure... not until a problem is clearer.

:-)

ryuji

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 30 Aug 2004 15:50:23 +0200

> Can you clarify the timing when MR stop advertising its default 

Suppose MR is currently default router. Next time it sends a second BU
because the first has not been answered is a good time to stop
advertising itself as a default router. Just an idea.

> During normal movement detection, the tunnel will be re-established 
> due to CoA change. It takes certain time of "sending BU and receiving
>  BA" from the movement detection to the tunnel re-establishment. Does
>  MR stop advertising default route at the movement detection?

Stop advertising as DR when a second BU has been sent because the
previous was not answered.

> Slightly different. If MNN keeps a default router, it sends packets 
> to MR (default router) regardless of MR's tunnel availability. Then, 
> MR can buffer certain packets till the tunnel is recovered. Or it can
>  just drops these packets without issuing any ICMP error messages to 
> MNN. In such case, session is still active although TCP window size 
> will be closed.

I see what you mean, I think the issue is important.

I think in practice, the application behaviour depends on a large number
of parameters of MR re-connecting to new AR.

I am sure we don't want default route flapping on the LFN's to induce
bad application performance.

For this matter, I'd say that we need good handovers.

It may also be that we don't want default route flapping all the time,
or we just want some intelligent default route set up and tear down.

> MR detects movement and sends BU at the time "t1". It gives up tunnel
>  establishment and stop sending default route at the time "t2".
> 
> I am not clear whether MR stop advertising default router after 
> failure of single BU or numbers of BU. In latter case, (t2-t1) will 
> not be negligible.

After failure of first BU for same pair HoA-CoA.  #Defined as 1 true and 
set in stone.

>> First, do you agree this is not a true complete "looping problem"? 
>> The packets will not loop between two MR's, do you agree with this?
>>  Even if TD is not used, even if the ingress router lifetime=0 is 
>> not zero, the packets do not loop within the MR1-MR2 pair, even if 
>> the two MR's are connected in a looping fashion...
> 
> I saw looong discussions on ML and can agree both you and Pascal. It 
> is true that the topological loop is occurred. But packets are never
>  looped as you noted.

Yes, me too I think the same.

Alex