[resending, with two edits]
I'm sorry, Ran. I shouldn't have been quite so flippant. BUT.
The architecture v. engineering debate is a red herring that gets thrown
around too easily. Every PhD student has to do a literature survey to
understand what has been done, in order to demonstrate that there is at
least something new to do that will improve society. That is what is
needed here. Nothing more, and certainly nothing less, and it has been
woefully lacking in the past. N.B., I am not asking that we get stuck
in history– that is a favorite pastime of this organization, but there
is a balance between the two extremes.
If we are going to create a new mobility architecture we should
understand how the existing ones work and don't work, and recognize what
is worthy of our time and what is not. We've all done the numbers.
What I stated were common pitfalls the conversation usually follows like:
* trying to solve the problem exclusively at L3, a favorite within
the IETF. You and I know that not considering these problems from
the transceiver to the application means poor deployment (more on
this later).
* not using the right tool for the right purpose. I'll spare the
guilty parties, but you know who you are.
* simply not understanding what problem they are solving, and what
problems to leave for others. How many efforts (and perhaps
entire companies) have failed because of scope? The IETF perhaps
goes to the other extreme now, but we'll leave that alone.
* attempting to shoehorn every last problem into a solution. I
believe in the need for locator/id separation, but it is *not* a
panacea. For instance, use of different *locators* may have
involve different costs, that may need to be exposed all the way
to the application layer. The iPhone demonstrates this best of
all with some of its apps. And so the app can't simply cope with
an identifier, as many would like. It has to have additional
information (although it may not need the locators themselves).
But back to that literature survey thing. People are often quite hard
on MIPv6, and often for the wrong reasons. While MIPv6 bind times have
often been viewed as atrocious, often ranging from 20-60 seconds, in
many instances that has been due to poor signaling in the layers below.
The real problems with MIPv6 (putting aside triangular routing in MIP)
is the need for v6, firewall impedance mismatch, and poor interaction of
the layers above and below L3. There are assuredly other problems I'm
not mentioning, like the complexity of dealing with private address
spaces. HIP implementations have some of these problems. But that is
often times it- we may in fact have the right *Internet* *standards* but
need work elsewhere. And some of this, such as FW traversal may be just
poor incentive alignment, or scope creep, depending on how you view the
problem. How do you view the problem?
To restate my main point: if we're going to design a new system, we had
darn well better understand the old systems, and what their limits are.
Eliot
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
