[ppml] 2005-1 or its logical successor

[Paul Vixie]

# On a global scale there are very few paths between major regions.

that's not the forest i can see from here.  but even if i agreed, i'd ask you
to transform this numerology into science by showing actual numbers, and
explaining why the current numbers are likely to be similar to future ones.
(that's me channelling kc in case anybody's keeping score at home.)

# The totally random interconnect model is not a technical requirement; it is
# a business choice that directly impacts the global routing system.  People
# are complaining about the size of the routing table, but that table could be
# contracted by restricting topology.

ah, well, if you want to talk about ways that architectural choices can
influence business choices, let's start with IPv4 PA space and CIDR, which was
an architectural choice that led to large scale ISP lock-in.  even if current
numbers justified your proposed design, and if you had strong arguments as to
why future numbers would also justify your proposed design, would the industry
be well served by an address assignment architecture which favoured the "very
few very fat pipes between regions" model?  i think if we could get far enough
through these weeds to reach that argument, i'd argue the opposite case VERY
strongly.

# All of that misses the point though. Today we don't want to think about
# restricting topology. I was not suggesting that by using a geo method for PI
# would actually change anything in the short term. As long as everyone that
# gets PI has a real global routing slot it really doesn't matter how those
# are handed out. The point of the note was to look at the option that PI be
# allocated such that down the road if the decision about random interconnects
# changed we would have the option to aggregate out many of those PI prefixes
# that are not necessary in the 'local' context where local is truly defined
# by operators/policy makers in any given space. Structured interconnects have
# a different business model than we are currently operating under, but they
# do have substantial impact on the size of the routing system.

just as some folks have to pay more to route PI space than PA space, and some
folks have to pay more for fixed than dynamic addresses, and some folks have
to pay more for real than NAT'd addresses, we could some day live in a world
where folks have to pay more for super-regional than regional addresses.  i'm
not sure i like where this is going.

# There is no reason for ARIN to even bother with evaluating 'need' or
# 'appropriate use' of PI space as long as there is a way for providers to
# aggregate out the ones that have not paid enough to support a global slot.

if we're going to do provider-centric address allocation design, why would we
say we wanted PI space at all?  how about we allocate space based on need and
appropriate use, and let providers compete on how well they can serve their
customers?

# Most small/home multi-homers would be perfectly happy with failover between
# local providers in a city.

then let such cities get themselves some address space, build an internet
exchange, build a wireless network, number their citizens, and let transit
providers compete over the result.  ARIN's current policies would allow this.
(and it's a damned damned DAMNED fine idea.)

# Trying to set a threshold of number of hosts/subnets to get PI space is
# strictly about trying to limit the routing table size. That is not ARIN's
# problem, it is the provider's problem. ARIN has a role in that the
# assignments need to be done in a way that allows the providers to do the
# aggregation.

ARIN also has to balance the needs of the people who will use the addresses.
if the only consideration was "what providers need", we'd stick with PA space.