[arin-ppml] Prop-50 and the differences in the various transfer policy proposals

Scott Leibrand sleibrand at internap.com
Sun Oct 19 23:14:21 EDT 2008

[Cc'ing prop-50 discussion to sig-policy.]

Geoff Huston wrote:
> Hi Scott,
>>> In your article you imply that the RIRs' registry functions are not the
>>> proper lever from which to apply the various regulatory functions 
>>> that the
>>> community has indicated are needed.  Where/how would you propose the
>>> regulatory function reside / be applied instead?
> Again, the real question is, MUST the RIRs have an answer for 
> _everything_? Must the RIR's devise complex procedures that attempt to 
> counter particular behaviours,  at the common community cost of more 
> onerous procedures with higher overheads. And without any practical 
> enforcement mechanism why will others even listen to the RIRs?

I understand that the RIRs don't have to do this.  I'm asking who else (or 
what other set of distributed incentives and emergent properties) should 
do it instead.

If no one / nothing else can do it, and it needs done, maybe we should 
try.  If you think APNIC can't do so for whatever reason, I still think 
ARIN could (and should) for the ARIN region.

>>> Or, to put a more practical face on the same question: how do you 
>>> propose
>>> that the industry deal with the deaggregation that will result from the
>>> widespread transfer of small netblocks (as allowed under prop-50)?
> Thats a very good example, because deaggregation in the address space 
> has been a constant factor for decades. i.e. if enforcing strong 
> aggregation in the routing space was a metric of success of the policy 
> framework associated with allocation, then the metrics of the routing 
> system over the past 10 years would have to assign a failing grade here.

I would argue that current levels of deaggregation have not yet posed 
undue burden on default-free operators, and based on that, the 
historical/current level of routing table growth is manageable.  I am 
therefore only talking about attempting to provide sufficient incentive to 
maintain the current "weak" level of aggregation.

> Again, to quote from the article:
> "However, fragmentation of the routing space has not been directly 
> linked to the further allocation function, and the results of this 
> decoupling of policy with a risk of any negative outcome is clearly 
> evident in the continuing fragmentation observed in the routing space."
> So, no, I don't think that any transfer policy proposal will do any 
> better than the allocation policy framework, and the allocation policy 
> framework has been, on the whole, ineffectual.

I agree that we can't do any better than we do today.  However, we can do 
a lot worse, and likely will under prop-50.

For example, consider two requests from two different organizations, the 
first for a /16 and the second for a /18.  Today, that is obviously two 
allocations and two new routes in the DFZ.  Now consider what happens in a 
simplified transfer market where the supply consists of five discontiguous 
/18s and a /16, with the /18s priced at $1000 each and the /16 at $5000.

Under prop-50, the first organization will get four discontiguous /18s for 
$4000 (passing up the intact /16 at $5000).  The second will get the fifth 
/18 for $1000.  In the end, that means that we will have 4+1=5 new routes 
in the table.

Under an RIR-regulated transfer market, however, the first organization 
would be required to get a contiguous /16, for $5000.  The /18 would still 
be a /18, so that would be 2 new routes in the table.

As you can see from the example above, or from a more general application 
of economic principles to the likely supply and demand of a transfer 
market, constraining the recipient of space under transfer to receiving 
only a single block large enough to meet their needs approximately 
preserves the current rate of routing table growth.  However, moving to a 
transfer policy like prop-50 results in an increase in the rate of routing 
table growth.


More information about the ARIN-PPML mailing list