What's really needed is a routing slot market

Sun Feb 6 17:15:09 UTC 2011

On 2/6/11 8:00 AM, John Curran wrote:
> On Feb 5, 2011, at 9:40 PM, Mark Andrews wrote:
> 
>> What's really needed is seperate the routing slot market from the
>> address allocation market.
> 
> Bingo! In fact, having an efficient market for obtaining routing of a 
> given prefix, combined with IPv6 vast identifier space, could actually
> satisfy the primary goals that we hold for a long-term scalable address
> architecture, and enable doing it in a highly distributed, automatable
> fashion:

So assuming this operates on a pollution model the victims of routing
table bloat are compensated by the routing table pollutors for the use
of the slots which they have to carry. so I take the marginal cost of
the slots that I need subtract the royalities I recieve from the other
participants and if I'm close to the mean number of slots per
participant then it nets out to zero.

 Routing table growth continues but with some illusion of fairness and
the cost of maintaining an elaborate system which no-one needs.

Yay?

> Aggregation would be encouraged, since use of non-aggregatable address
> space would entail addition costs. These costs might be seen as minimal 
> for some organizations that desire addressing autonomy, but others might
> decide treating their address space portable and routable results in 
> higher cost than is desired. Decisions about changing prefixes with 
> ISPs can be made based on a rational tradeoff of costs, rather than in
> a thicket of ISP and registry policies.  
> 
> Conservation would actually be greatly improved, since address space 
> would only be sought after because of the need for additional unique 
> identifiers, rather than obtaining an address block of a given size 
> to warrant implied routability.  In light of IPv6's vast address 
> space, it actually would be possible to provide minimally-sized but
> assured unique prefixes automatically via nearly any mechanism (i.e.
> let your local user or trade association be a registry if they want)
> 
> With a significantly reduced policy framework, Registration could be
> fully automated, with issuance being as simple as assurance the right
> level of verification of requester identity (You might even get rid
> of this, if you can assure that ISPs obtain clear identity of clients 
> before serving them but that would preclude any form of reputation 
> systems based on IP address prefix such as we have in use today...)
> 
> Just think: the savings in storage costs alone (from the reduction in 
> address policy-related email on all our mailing lists) could probably
> fund the system. :-)
> 
> Oh well, one project at a time...
> /John
> 
> 