Updated ARIN allocation information
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