Subject: [MOBILE-IP] Architectural v.s. Incremental Lession for Fast Handoff Discussion

From: James Kempf <[email-masked]>
Date: Thu, 14 Dec 2000 12:54:47 -0800

For those of you who were at Randy Bush's talk on Wed. nite, one of the important points I
took away is that DNS is in the mess it is in because the working group did not
exercise enough design control. They chose incremental update as opposed to architectural
update.

I think there is a lession here for the fast handoff discussion. In particular, the
two proposals for IPv4 represent the two choices. The proactive proposal essentially
takes the architectural approach. It is saying that the current mobile IPv4 architecture
needs modification in order to adequately support fast handoff. The Heshim and Karim
proposal (I'll not call it "fast handoff" because that is confusing, both proposals
support fast handoff) takes the incremental approach. As the authors have stated time
and again, their proposal is an incremental update to the existing mobile IP architecture.

If we merge the proposals, I wonder if, two years from now, one of our working group chairs won't be
up on stage at the plenium giving exactly the same presentation as Randy did but for
mobile IP.

I'd therefore like to ask the working group to reconsider its hum for merging.

                jak

---

From: Sebastian Thalanany <[email-masked]>
Date: Fri, 15 Dec 2000 20:47:23 -0600

I support Jim's proposition for the following reasons:

    1. In the context of wireless mobility, the objective of a handoff scheme  is to
        minimize both latency and signaling overhead.

    2. An architectural approach, where Mobile IPv4 utilizes abstract triggers obtained
        from a wireless link, where the triggers are independent of any specific wireless link
        technology, is essential for an efficient wireless mobile handoff scheme.

    3. In the proactive proposal the Mobile IPv4 signaling is used deterministically, since
        an abstract trigger, from the underlying wireless link, is effectively utilized.

Regards,
   Sebastian

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 20 Dec 2000 12:19:47 -0800

>I'd therefore like to ask the working group to reconsider its hum for
merging.

If there's anything I've learned over the last few years in the IETF, it is
that
merging two proposals for the sake of "consensus" is often a very bad idea.
Too
frequently we end up with the worst aspects of both proposals, an outcome
which
is often worse than choosing one or the other. It is often better to choose
one
architecturally clean proposal, even if all of the "features" that are
desired
can't be shoehorned into it.