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

From: George Tsirtsis <[email-masked]>
Date: Wed, 19 Dec 2001 13:36:33 -0500

Vijay,

Relax. All my references to Fast Handoffs are in plural...meaning both v4
and v6 specs....And yes, I also think that it was a mistake to merge BETH
(as well as HTT) in the specs, although I am partly responsible as a
co-author of FMIPv6 and since I let this happen in a moment of unbelievable
weakness or temporary insanity or both.

So, lets try to correct things.

George

-----Original Message-----
From: Vijay Devarapalli [mailto:[email-masked]]
Sent: Wednesday, December 19, 2001 6:23 PM
To: [email-masked]
Subject: Re: [mobile-ip] WG Feedback Requested

George Tsirtsis wrote:

> GT> Yes I am saying that these specs are too big and complex to go through
> the standards process as they are...they need to be broken down but to do
> that we first need to figure out what is the basic functionality...

this is incredible. Why werent you protesting when FMIPv6 spec 
bloated from 25 pages to over 62 pages? It was nice and simple
when I started implemented it. 

Only a couple of us protested merging BETH with FMIPv6. I wish 
BETH had been a separate proposal.

regards
Vijay

> 
> My point is that this doesn't justify putting low latency on hold.
> 
> GT> If we do break them down then clearly we have some work to do before
we
> can push them forward.
> 
>  > In fact the PFANE is sent by the MN along with the registration
>  > request when it has attached to the new FA and is completing the
>  > L3 handoff. The low latency solutions aim at reducing L3 handoff
>  > latency to zero, which means that the MN must be in communication
>  > as soon as it attaches to the new FA.
>  >
>  > GT> The point is though that PFANE extension has been very
>  > stable for long
>  > time and provides lossless handoff that can be used in the
>  > short term and
>  > until either fast handoffs mature or link layers get make
>  > before break
>  > capability...in which case fast handoff specs are not
>  > needed. The only
>  > reason PFANEs are not a standard today is because they are
>  > part of the Route
>  > Optimization draft that is notionaly kept behind because of the MIPv6
>  > security discussion. Yet PFANEs have no security issue
>  > themselves...hence
>  > the discussion about publishing them independently of
>  > Routing Optimization.
> 
> I'm not against splitting PFANE from route opt. since I agree that
> it solves a different problem than generic route opt.
> However I can't agree with the argument that PFANE can be used for
> loss-less handoff on the way to a next step. PFANE in route opt
> is used after the MN has attached so that implies some latency/loss.
> I say we provide the necessary fast handoff tools and let people
> make their implementation choices.
> 
> GT> Karim, it is well understood that for Make Before Break handoffs such
as
> all the inter-technology handoffs and any good enough link layers that
also
> allow it there is no need for the fast handoff specs. These are
specifically
> needed for break before make handoffs. But lets not get hanged up on this
> the point is that you also agree that the PFANE proposal could be
> standardized independently.
> 
> Cheers
> George

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 19 Dec 2001 10:47:54 -0800

Great!! But I am not sure how to proceed. I guess lot of work
went in merging BETH into FMIPv6. I can see Gopal getting ready
to kill me :)

Vijay

---

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

Vjay,

We are trying to do a complete job with FMIPv6. We did
a lot of work on specifying interaction that was not
done for low latency.

Besides, there is no guarantee that the same discussion
won't occur for FMIPv6 when we have similar simulation
results, though I am willing to wait until the data are
in before making any claims. My feeling is that
the discussion here is not about whether the spec
is too complex, it is more about whether the
theoretical and experimental results presented
so far are sufficient to judge the Prereg
performance claims as inferior. And whether
the promising results for a technique similar
to PFANE are sufficient to justify considering
it as an alternative for Prereg. Perhaps
making the spec simpler would faciliatate
understanding and IESG approval (I'm
told 40 pages is the maximum if you
want the IESG to read it in a short
period of time), but to my mind that
is the lesser issue.

            jak