Re: [RRG] Consensus? End-user networks need their own portable address space

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

I am replying to Tony, Randall and Brian.


Tony Li wrote:

> I would say that end some end-user networks _want_ their own portable
> address space.  
> 
> If we provide solutions that give end-users the functionality without that
> particular mechanism, I can't rationally say that there is a _need_.

The point of my argument is that the only possible mechanism is
portability.

This is a well-known, decades old, problem.  The best
non-portability solution anyone has suggested or developed is the
automatic renumbering stuff in IPv6.  This is impressive looking,
but I doubt it has been widely road-tested in real, large, networks
- because few, if any, such networks use IPv6.

As I argued in my original message, even if it works as advertised,
it does not go nearly far enough to meet the real needs for
seamless, reliable, changeover from one ISP to another.

Besides, there is no such auto-renumbering arrangement for IPv4 -
which is where the Internet's routing scaling limitations are a
genuine problem.

I don't think it is reasonable at this late stage in the RRG process
to avoid the conclusion that portability is the only way of giving
end-users what they need in terms of freedom of choice of provider.


Randall Atkinson wrote:

> % OK - but there is no other engineering mechanism than portable
> % address space which enables them to switch to another ISP
> % without unreasonable costs and disruption.
>
> Several approaches that provide those capabilities have been
> discussed here in the past.  So I disagree with "there is no
> other ... mechanism".
>
> % Sure, but there are no other alternatives.
>
> I disagree that "there are no other alternatives".
>
> % What mechanisms other than portable address space
> % are there which would enable any decent sized network
> % to change ISPs without a great deal of error-prone
> % manual work?
>
> One can imagine several methods.
>
> Decoupling the TCP session state from the IP address(es) in use,
> which was one possibility envisioned at the IAB Workshop,
> enables a range of different approaches, for example.

This would involve host changes and would only work for TCP - so
this is not a solution at all.

It wouldn't help with the need for a network changing from one PA
prefix to another to change IP addresses in server config files, IP
addresses in zone files, in ACLs etc.

> % Can you cite an example of techniques in use today which
> % make any end-user network easy to change from one
> % PA prefix to another?
>
> Again, your premise is wrong.  The Routing RG can consider
> any architectural approach -- whether or not that proposed
> approach is "in use today".

Sure.  We have had a year or so for people to propose a solution
other than portability.

So far, no such solution has emerged.

We need to start refining goals, and I believe we should cut out all
this stuff about pretending end-user networks should be happy with
PA space, and recognise that in order to meet the goals set by RAWS
- seamless, reliable, low-cost ease of change of provider (my
paraphrase) - we need to provide a new form of address space which
is portable without adding to the routing scaling problem.


Brian E Carpenter wrote:

> Exactly. IPv6 was designed to remove the _need_, although there's
> no doubt that most IT departments around the world haven't
> understood this.

My guess is that IT departments do not think that IPv6's automated
procedures solve all the problems they face in adopting a new PA
prefix.  Also, they are concerned about IPv4, not IPv6.


> Unfortunately IPv4 prefix assignments, both pre-CIDR and since
> the registries folded by starting to make PI assignments, have led
> to established practice that IPv4 prefixes are viewed as property.

This is unfortunate from the perspective of someone who wants to
ensure that end-users never retain the address space they used with
one ISP when they move to another.

It is fortunate and necessary for all those end-user networks who
have been lucky enough to get PI space.

The two problems we need to solve are closely related:

  1 - Not enough end-user networks can get this PI space.  (The
      map-encap proposals aspire to scale to hundreds of millions
      or billions of such end-user networks.)

  2 - Even the number that do get PI space causes an unacceptable
      burden on DFZ router operators - the routing scaling problem.

Since no-one has a solution other than portability, I believe the
only way we can solve the routing scaling problem while meeting the
goal of reducing provider lock-in is to recognise this and provide
portability to end-user networks of all sizes - from large
corporations to home-office and perhaps cell-phone users.

> It's too late to change that for IPv4, but we shouldn't confuse
> that contingent fact with architecture.

I would appreciate it if you all addressed my detailed argument that
there is no other method than portability of enabling end-user
networks to change providers without giving them portable PI space.

One of the major purposes of all the map-encap schemes (Six/One
Router too?) is that the new kind of space they provide is fully
portable, without burdening the DFZ routing table.  The most fully
developed attempts to meet the RRG's tasks all provide portability -
and I think the objection to portability stems in large part from
the current situation where each portable prefix adds to the routing
scaling problem.


  - 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