[ppml] 2005-1 or its logical successor

[Tony Hain]

Paul Vixie wrote:
> ...
> # 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.

But that is exactly what is argued as necessary to align the cost with the
pain. The super-regional addresses are the source of the pain in the routing
system so why shouldn't they carry the cost? Multi-homing within a region
does have impact on the routers serving that region, but ONLY the routers
within that region.

> 
> # 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?

I didn't say they were provider centric, just that they could be aggregated
out. In any case, who gets to decide the value of 'need' and why do they get
to decide that? 

> 
> # 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.)

ARIN policy allows this, but there is an external conflict in 'use of public
funds to compete with industry'. It really doesn't matter if the exchange
operator is a city, a consortium of ISPs, or an independent enterprise as in
the current set. The bottom line is that all the 'insanity' that is
necessary to sort those things out within the city/region is contained at
that exchange and the transit providers have a clean demarc to compete over.


> 
> # 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.

One of the biggest issues that gets overlooked is that we are not restricted
to choosing one or the other. PA space is fine for those that don't care
where the space comes from. Some entities (including DNS roots) have needs
that don't fit in the PA model. The current debate is about who gets to pass
judgment on the value of 'need'. The most effective judge of value is the
organization requesting the resource. If they are presented with a menu of
resource bundles and prices they can make the clear determination of the
bundle that actually meets their need with the value measure that will
naturally pushback to keep them from demanding more than they need.

A sequential allocation of PI space creates the swamp that becomes
impossible to deal with over time. A structured allocation builds the option
that down the road it is possible to enforce exchange point based
aggregation if and/or where that becomes necessary. It really doesn't matter
what structure you choose, the constraint of topology to fit that structure
is what reduces the impact on the routing system. The point is to think
about ways to allocate PI space that will allow for long terms options.

Tony