Updated ARIN allocation information

Owen DeLong owen at delong.com
Fri Jan 31 23:10:56 UTC 2014

On Jan 31, 2014, at 1:29 PM, Matt Palmer <mpalmer at hezmatt.org> wrote:

> On Fri, Jan 31, 2014 at 11:09:43AM -0500, John Curran wrote:
>>   better utilization.  It would be nice if there was a way to fairly 
>>   "settle up" for the imputed cost of adding a given route to the 
>>   routing table, as this would provide some proportionate backpressure 
>>   on growth, would create incentives for deaggregate cleanup, etc.  
>>   We don't have such a system, so it falls to each ISP to decide what 
>>   route is worth accepting based on type and the offering peer's 
>>   business relationship...
> I almost hesitate to mention this, just in case I put ideas into some
> beancounter's head, but it seems to me that the cost model of carrying
> packets isn't that different to carrying routes.  In both cases, practically
> everyone is acting as a middleman, and money flows hither and yon and
> (presumably) balances out in the end, with everyone having their costs
> covered with a little left over for the shareholders.

Meh, sort of…

> Imagine one of the big players saying, "we're going to charge you $X per
> route you send to us" (just like transit agreements that state, "we will
> charge you $X/GB of traffic"), or "your contract allows you to send us N
> routes" (just like, "your contract allows you to send us N Gb of traffic"). 
> About 15 minutes later everyone else would start doing it, to recoup the
> costs of sending routes to that provider.  Peering would be considered not
> only if the volume of traffic was mutually advantageous, but also if the
> routes exchanged were mutually advantageous.

That’s the optimistic outcome. The pessimistic outcome is that they get
rapidly depeered by everyone unwilling to pay $X/GB and then start losing
customers because their customers can no longer reach anyone else’s
customers through them.

The reality probably lies somewhere in between. I suspect whoever chooses
to conduct this little experiment first should be prepared for substantial pain.



More information about the NANOG mailing list