Subject: Re: [RAM] LISP and the Global Internet Architecture

From: [email-masked] (Noel Chiappa)
Date: Wed, 4 Apr 2007 10:39:03 -0400 (EDT)

> From: David Conrad <[email-masked]>

    > On Apr 2, 2007, at 7:08 PM, Noel Chiappa wrote:

    >> Which leads me to wonder what the future really is, though. What
    >> happens when the IPv4 addresses really do start to run out in a few
    >> years? Will we see a market develop for IPv4 addresses, plus
    >> continued use of NAT?

    > Yes. And this will drive increased fragmentation of the routing
    > space, resulting in increased routing information load.

Excellent point. An architectural addition of a mapping from identifiers to
locators will really help deal with this; fragmentation of what is (mostly)
a pure identifier-space wouldn't be anything as problematic, I suspect.

As a generic point, we have to deal with the network we actually have, not
the network we wish we had...

Which leads me to another thought, having to do with migration of endpoint
identification (or, more generally, end-end naming) to a new namespace.
(As Jim Bound suggested, we probably want to migrate *both* existing uses
of IPv4 "addresses" to new namespaces.)

Deployment of a "jack-up" design will give us a new locator namespace, but
it leaves the hard job: migration of the endpoint naming functionality,
which necessarily involves touching the hosts.

One theory I've had for some years now is that we won't be able to deploy a
whole new end-end namespace at the transport level, because there is simply
too much deployed base. (".. we have to deal with the network we actually
have ..") Rather, we'll only be able to deploy new namespaces on a
per-application basis: we see this now with the way the WWW uses cookies.

The WWW naming system is "NAT-friendly", in that as far as WWW interactions
are concerned, the IPv4 addresses are simply local forwarding tags (which
is what I see the long-term future of IPv4 addresses being).

So perhaps that, plus continued use of NAT in end-end naming for legacy
applications, is what the future looks like...

	Noel

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: [email-masked] (Noel Chiappa)
Date: Sun, 15 Apr 2007 10:51:22 -0400 (EDT)

> From: Yakov Rekhter <[email-masked]>

    >> even more importantly, is there really any scope left for good
    >> fundamentals-based engineering, or will we always be restricted by
    >> economic/business considerations to the cheapest thing we can possibly
    >> come up with that more or less kludges the network into continued
    >> operation?

    > The choice between various options is *not* going to be driven by
    > whether one option is defined by some individuals as "good
    > fundamental-based engineering" vs another option is being defined as a
    > "kludge", but by the cost/benefit analysis between these two options.

IMO, I can express the exact same sentiment, but in purely economic terms -
which will take economics out of the equation. So let me do so:

Even more importantly, is there really any scope left for design which tries
to maximize the cost/benefit integrated over the long term (which almost
always means good fundamentals-based engineering), or will we always be
restricted by short-term economic/business cost/benefit considerations to the
cheapest thing we can possibly come up quickly (which almost equally
inevitably means kludging the network into continued operation), even if
repeated application of that path choice, over the long term, has a lower
overall cost/benefit ratio than the first choice?

In other words, looked at in purely economic terms, are you trying to
optimize the short-term cost/benefit, or the long-term cost/benefit?
Economics alone won't make that choice for you.

	Noel