[RRG] Host changes & user costs of adopting map-encap addresses

[Robin Whittle <rw@firstpr.com.au>]

In "Re: [RRG] Why delaying initial packets matters", Tony Li wrote
of my agreement with Lars Eggert's: "Deploying something new at the
network layer that might require changes to host stacks or
applications to maintain performance at current levels would be a
non-starter.":

> Oh good, so then we can cancel IPv6 too?

IPv6 has been available for a decade or so and hardly anyone uses
it.  As far as I know, no-one uses it exclusively.  The problem is
not so much with IPv6 but that there's no backwards compatible
upgrade from IPv4.

Host operating systems and applications (in some or many cases?)
need to be upgraded, and all routers need to be upgraded or have a
second layer of configuration added to them.  Then there needs to be
IPv6 space, if your ISP could provide it - and in general that has
meant no portability or multihoming.  All this effort for no obvious
benefit, until the end user finds there are sites or services which
work best, or only, on IPv6.  This hasn't happened, nor is it likely
to happen any time soon, because IPv4 does the job fine.

In msg 282, Feb 8th, Tony also wrote:

> The incentive for everyone is to deploy a scalable routing
> architecture that serves us for the long term.  Regardless of the
> proposal that RRG puts forward, it's thermodynamically impossible
> that it will have no cost.  There will be deployment costs,
> forwarding plane changes, and a mapping subsystem to support.

We should reduce the end-users costs of adopting the new address
space as much as possible.  I think our task includes:

1 - Create an architecture which solves the routing scalability
    problem for multihomed, transport engineering end-users who
    also want and need number portability.

2 - Make the architecture as elegant, open and extensible as we
    can.

3 - Ideally, have the architecture solve other problems and/or
    provide new services, such as mobility with optimal or near
    optimal path lengths.

4 - Make the new kind of address space have as few downsides
    as possible for end-users of all sizes.  (See my msg 275:
    Large companies with PI, small with map-encap space?)

I think we should aim to have the direct costs borne by ISPs - and
perhaps larger end-users who currently have PI space, and who would
reduce costs and get more flexibility by migrating their space to
the map-encap scheme (or giving it up and adopting a separate
map-encap set of addresses).  Then, the rest of the end-users will
feel no direct incremental cost in adopting the new kind of address
space.  Ideally, they will do so en-masse because there are
immediate overall benefits, even if the space costs them more than
the PA space they currently use.

End-users ultimately pay all the expenses of ISPs, so the end-users
pay in the end.  But everyone benefits in the long run, because the
BGP system can be left to run merrily for many more years without
bloat in the number of DFZ routes, and because even end-users who
don't adopt the space will benefit from cheaper, better services
provided by end-users who do adopt it.

> Having a functioning Internet for our great grandchildren is
> the benefit and without that, the hosting companies are simply out
> of business.

Sure, but no company is going to put resources into IPv6 or some new
map-encap scheme just because of purported long-term benefits to
humanity.

We need to make the map-encap scheme an immediately positive
experience for all the end-users who adopt it, because we want it to
be very widely used, by end-users large and small.  I think this can
be done, and I think the benefits of the new kind of address space
will make it a marketable, potentially profitable, business
proposition for the organisations (typically ISPs) who provide it.

The new scheme will be incrementally deployable, with immediate
benefits to the early adoptors.  This is not the case with IPv6,
which is why it is hardly used at all.  But that is not the fault of
IPv6, since no-one has been able to think of any incrementally
deployable upgrade from IPv4.

The ITR - ETR infrastructure is a very powerful tool which has never
been contemplated before.  I wonder if a good map-encap architecture
could be used as part of some migration plan from IPv4, in ways we
have not thought of before.

  - Robin

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg