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

From: George Tsirtsis <[email-masked]>
Date: Wed, 19 Dec 2001 12:53:03 -0500

-----Original Message-----
From: Karim El-Malki (ERA) [mailto:[email-masked]]
Sent: Wednesday, December 19, 2001 5:39 PM
To: [email-masked]'
Subject: RE: [mobile-ip] WG Feedback Requested

 > IMO unless we finish the work off people won't have a chance
 > to see if it fits their requirements. Until we have an RFC we
 > can't really say IETF has a stable solution for low latency
 > MIPv4 handoffs which people can implement and try out. Early
 > implementation is useful but few implementations doesn't
 > mean it shouldn't make it to RFC. We also need to consider that
 > low latency is closely knit to wireless (through L2 triggers and
 > their timing) which makes the real implementation harder than
 > many other drafts.
 > 
 > GT> I think that the community has been overwhelmed by the 
 > MIPv6 security
 > discussion and has reviewed the fast handoff specs very 
 > little. Also these
 > specs are full of new mechanisms...some of them very 
 > complex. Fast handoffs
 > are also "optimizations" and as Eric N. said recently, IETF 
 > is not very good
 > at producing optimization techniques. Even worst, parts of 
 > the fast handoff
 > specs are about optimizing the optimization...see Handoff To Third
 > (HTT)....what about the Forth, Fifth and Hundredth? What I 
 > am saying is that
 > the IETF must be very careful and rather conservative in this
 > standardization effort. Peer review and experimentation is 
 > needed here more
 > than anywhere.

I agree that experimentation is useful. The point is that here
experimentation is not easy since you need to make this work with
your wireless L2, so we can't expect everyone to implement it
or for it to fit all wireless systems. If there's no stable solution
there's no chance wireless people will implement this, so it would be
like going round in circles if we didn't finish this work. The lack of
fast MIP handoff on most L2s (as you say those which do not allow the
make-before-break where the MN talks both to oFA and nFA contemporarily)
has been given as a problem of Mobile IP which we aim to solve in low
latency. That's stated in the spec and is as far as this draft goes.
Regarding the optimisations I agree things should be kept simple but so
far people have not opposed things like HTT. By the way, HTT is a SHOULD
for those wireless systems where the MN moves fast enough for it not to be
able to register with nFA. It isn't needed for all cases. If you want
to propose ways of simplifying the spec like removing HTT or other parts
while keeping the basic functionality and the WG agrees I'm all for it.

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

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:22:54 -0800

> 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