Subject: RE: [mobile-ip] WG Feedback Requested

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 19 Dec 2001 19:01:06 +0100

Jonathan Wood wrote:

  > > => Certainly, that's a possibility, but the question
  > > is why ?
  > > I sure hope this wasn't due to the last presentation
  > > in SLC. It was already shown on the mailing list
  > > that the understanding of RFC2002 and the low
  > > latency draft were not correct in that implementation.
  > 
  > This has not been shown, either on the mailing list or elsewhere.
  > 

=> Please see Karim's response to you some weeks
ago, I've attached it below in case you missed it.

Also the same claim is made in section 4.1.1 of your 
paper. This is clearly wrong. 

There are also other claims about race conditions which
are false.

  > 
  > I agree that we need more implementation experience with 
  > these complex 
  > proposals. If we move the draft to proposed now, yes, more 
  > people will 
  > implement it, but only because they assume it's stable and 
  > well-understood, when that is not the case.
  > 
  
=> So what do you propose ? Keep it a WG item for another
year till enough people prove that it is implementable ?

Hesham

-----Original Message-----
From: Karim El-Malki (ERA) 
Sent: den 7 november 2001 16:56
To: [email-masked]'
Subject: RE: [mobile-ip] Low Latency MIPv4 Handoffs: Coverage Area
Transit ion

> > > First I should call out one place where it looks like we may have
> > > differing assumptions. I assert that the MN MUST know whether or
> > > not it is in a PRE-REG or rfc2002 coverage area, since the actions
> > > it takes on movement detection will be different. For rfc2002, a
> > > MN typically on receipt on an advert will flush L2 caches and
> > > routing tables, add a default and host route through the FA, and
> > > send a registration reply.
> > 
> > It would do that after it received a registration reply. I 
> guess that's
> > what you meant.
> 
> Actually the MN can set the default route whenever it wants after it
> gets an advert; so far as I can tell rfc2002 is silent on the matter
> and it makes little difference. The implementation I am using sets
> the default route after getting the advert and before sending the
> registration request (yes I typoed above - s/reply/request/). This
> is significantly different for PRE-REG, where it is critical the
> default route is not reset until the MN is on the new FAs link. (You
> do touch on this in section 3.6.)

I don't think RFC2002bis is silent on this. It says the following under
MN considerations (4.2.1):

  When registered on a foreign network, the mobile node chooses a
  default router by the following rules:

     -  If the mobile node is registered using a foreign agent care-of
        address, it MAY use its foreign agent as a first-hop router.
     .....

From the above I understand that the MN chooses the default router
once registered and MAY use the FA with which it is registered. When a MN
has an active registration and receives another agent advertisement it
shouldn't immediately change default router. It has to do movement detection
and wait until a successful registration goes through before making routing
changes. Otherwise any ongoing communication (through the current FA) would
be disrupted since the new FA shouldn't let traffic through (to and from MN)
until it gets the successful reply.

/Karim

---

From: "James Kempf" <[email-masked]>
Date: Wed, 19 Dec 2001 11:05:05 -0800

Hesham,

> There are also other claims about race conditions which

Karim and I discussed this before the MIP meeting and
he agreed that Prereg has this problem, but so does
standard MIPv4. Are you saying that Karim is wrong
here?

Also, I would like you to specifically answer this question,
without any prevarication or attempt to divert the
debate in another direction:

        Do you disagree with the theoretical data presented
        to the list last summer, and the experimental data
        presented at the SLC meeting, that Prereg will
        have worse performance than standard MIPv4
        handover if the MN moves too fast for the
        Prereg signaling to complete while the MN
        is still on the old FA?

*That* is the issue, not the implementation. If you think
we implemented it wrong, then implement it yourself
and prove it!

> year till enough people prove that it is implementable ?

If Raj, Phil, and Thomas don't want to make the hard call
and separate out Prereg, then let's take the whole thing
to experimental. 

                jak