Dear Pekka Nikander,
Please forgive the late reply.
Where can I find out more about Dave Crocker's MAST?
See the rest of my message embedded among the qoutation of your text.
Pekka Nikander wrote:
Robert,
I like your analysis very much. Thank you for writing it up.
However, I also see a kind of causality here: it looks to me that
stable end-point identifiers are mainly needed to make applications
survive IP address changes. Dave Crocker's MAST is a good example
how you can do that without having stable end-point identifiers.
There is more to stable end-point identifiers than just the ability to
make an application resilient. I will argue that IP addresses *do not*
identify end-points, but node interfaces. That is, they only specify
objects on the path to the end-points. Applications, users and system
administrators need to specify more than node interfaces They try to do
so by twisting IP addresses to all kinds of usages for which they were
not intended and are ill-suited in my opinion. Indeed it is a feature
that IP addresses and their definition as an identifier for a node
interface are so flexible that it is possible to contemplate extending
their usage for those purposes.
On the other hand, security looks to me as a good reason for having
stable end-point identifiers. If you can securely recognize an
end-point (with emphasis on the *re-* part of re-cognize), you can
develop trust. Trust, in turn, is very handy for lowering
transaction costs.
Indeed it is, and I would add that end-point identifiers (together with
node interface identifiers) are the thing that system administrators and
system security officers want.
Even facing the danger of opening yet another rat hole, in my opinion
we should not have a very strict definition for end-point. That is,
IMHO end-point should and could be a fuzzy concept, somewhat like
the concept of a site is today.
From my point of view, an end-point may be a process, a group of
processes, a host, or even a server cluster offering services as a
unit. To me, it looks like fate sharing and common semantics are the
key points here. An end-point should either work or fail, it should
not be usual for half of an end-point fail while the other half is
continuing. An end-point should also be considered at the
application level as a single unit.
The question that that raises is, whether it is reasonable to use such
an inclusive notion of an end-point, and what is the simplest kind of
structure or object we can use to implement an end-point identifier? We
might have to restrict the notion of an end-point somewhat.
In my opinion, we clearly need solutions to all of these problems.
Furthermore, it looks like introducing stable end-point identifiers
to the stack almost automatically protect applications from the
changes of IP addresses. I also tend to believe that stable
end-point identifiers may also help to build self-organized networks.
However, IMHO the problem of self-organized networks is more
researchy in nature than the other two.
With respect to the protection of applications from changes of IP
addresses, the effectiveness of that protection (or its robustness) will
depend on what the final specification of end-point identifiers is.
With respect to the problem of self-organised networks, that might be a
research problem, but I would argue that it is a here-and-now research
problem.
Now, even though I believe that we should solve the problems (and
apparently believe that there are sensible solutions), achieving
consensus on solutions that require architectural change may take too
long. Hence, I also believe that we need some kind of a road map,
with some "temporary" or intermediate solutions along the way to a
more long-standing set of solutions.
I agree, and your statement corresponds to what Keith Moore says about
the solutions fitting into a framework that is yet to be specified. I
believe specification of that framework begins with our defining what an
end-point is.
Yours sincerely,
Robert Honore.