Subject: RE: FW: [seamoby] CT trigger or CT completion? was: proactive an d re active CT definitions

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Mon, 2 Jul 2001 13:52:25 -0500

Hi Rajeev,

I actually asked this question long time ago and the answer that
I got was that CT is supposed to be AR-AR and handle AR changes
not AP changes. If you have a different interpretation, then please
let me know.

Pat, if I misunderstood the scope of CT, please let me know,
I thought CT is scoped handle AR-AR only.

So If my observation is current, I don't see a relevance to CT
in your argument below.
Change of L2 link without change of AR is not what CT is dealing with.

Now opening up the issue a bit, I think what we were discussing was
whether link establishment is the same as having the new AR as default
router, and I am not sure whether that is the case.

I see the link establishment as more of a L2 event and default router
as a L3 event, so I think they are simultanous. 

BTW, I need to go look at the MIPv6 draft again to see how they
define change of default there :)

Madjid

-----Original Message-----
From: Rajeev Koodli [mailto:[email-masked]]
Sent: Thursday, June 28, 2001 5:51 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: 'Pat Calhoun'; 'Charles E. Perkins'; [email-masked]'
Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive
and re active CT definitions

Hello madjid,

Nakhjiri Madjid-MNAKHJI1 wrote:

> Hi Rajeev,
>
> -Rajeev: I have a question here. Is it possible that you can establish a new
> L2
> and still not change your AR ? If yes, if you don't change AR, is there is
> still any CT ? Is this too naive ?
> It seems to me that the AR is the key entity (for our defintion) since that
> holds the feature contexts.
>
> MN>>> But without broadening the scope of CT, lets assume that CT is AR1-AR2
>
> (change of AR is part of the scenario)
>
> *So the discussion is what is difference between new-L2 establishment and
> change
> of default router. I say difference is the timing.*
>
>

Rajeev: Actually, I am not sure if this is all..If you only change APs and are
still with the same AR, you don't change your default router. So, the point is
that changing L2 does not necessarily constitute changing AR, independent of
time.

> The case that comes to my mind, when you change L2 but newAR is still not
> your default router, is say:
> MN is at new L2, but did not have time to sent binding update to
> the oldAR before moving, so its using new L2 to start the L3 routing
> change procedure, it does not have newAR as default router but
> has L2 with newAR.
>

Rajeev: The new AR needs an entry in its neighbor cache before it could forward
packets, including Binding Updates.

> The other case is, if it has obtained its new IP address through
> stateless autoconfiguration, but the new address is rejected by
> newAR, although MN has L2 with newAR.
>

Rajeev: In this case, it (the MN) has not completed acquiring an IP address
yet.

In both the two cases you mentioned, you are assuming that new L2 implies new
AR. This need not be the case. So, the only definitive point of reference is if
the MN changes its default AR.

>
> So you can base your proactive CT on *predictions* based on L2 information
> Do the proactive CT and manage to get your context over to newAR
>
>

[snip].

>
> Rajeev: There is IP router discovery that indicates to a node when some AR
> has
> become the default AR.
>
> Any CT that happens prior to this phase is "Pre"-something. This includes
> using
> L2 triggers etc. When none of this is possible, the MN realizes that it has
> changed its AR through router advertisements and does CT, which is
> "Post"-something. Sure there is delay here. It is a matter of
> classification,
> not debating performance.
> Anyway, let's see if we can resolve the previous question.
>
> MN>> as I said earlier, the important point is to cover all the scenarios.
> whether proactive is pre-A or Pre-B is not important, but I think using
> default router which is probably one of the absolute last things that
> happens in handover might not be very suitable and is at least as ambiguous
> as other definitions, so we should not be creating new ambiguous definitions
> everyday.
>

Rajeev: could you say why it is ambiguous and why is it not very suitable ?

Regards,

-Rajeev

> Madjid

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 10 Jul 2001 06:46:33 -0700

back from vacation. Sorry for the latency.

> I thought CT is scoped handle AR-AR only.

well, I am not sure that I know the scope more than you do, but
I don't see a reason to restrict its usage to AR-AR only. An AP
implementor could use our protocol to transfer state as well.

Thanks,

PatC