[arin-ppml] Aggregation fees

[Milton L Mueller]

May as well provide the text of the report segment here. 
Interested in your comments

Appendix 2
Aggregation fees
We considered, but ultimately do not recommend, modifying the proposed system of address block fees to encourage route aggregation. Earlier discussions of the routing tragedy of the commons explored the notion of charging for route announcements. (Rekhter, Resnick and Bellovin, 1996) These explorations led many to conclude that it was impossible to do so, because it was assumed that ISPs would have to directly negotiate and compensate each other for route announcements on a bilateral basis. 
It is, however, possible to reward route aggregation (or conversely, to penalize de-aggregation) by linking the address block fees to aggregation efficiency. The fee for initial allocations would be based strictly on the size of the block, and the periodic recurring fee would be based on both the size of the block and on the address block holder's aggregation efficiency. Recipients of address allocations could pay recurring charges on an annual or quarterly basis.  Recurring charges would be based on the size of the block with an added charge for the number of routes an organization announces per allocated block. E.g., if only 1 route is announced into the exterior routing domain for the allocated block, perhaps the recurring charge is 0; then it increases until it reaches its highest level when the routes announced are completely disaggregated to the /64 level. Such a fee would have to vary depending on the size of the block, increasing for smaller blocks and decreasing for larger ones. (This aspect requires further exploration.) Such a fee structure might combine and integrate the incentive to conserve with the incentive to aggregate routes.
The purpose of such a fee structure would be to internalize the externality associated with routing table growth. Such an approach "taxes" deaggregation. Calibrating recurring fees to reward aggregation efficiency might make it possible to have a more liberal trading regime that would allow holders of TABLs to sell portions of their blocks, because it would ensure that trading of deaggregated blocks would occur mainly when it increased routing efficiency (or at worse, left it the same). Address block trades that led to deaggregation would increase the trading parties' recurring costs. The costs of deaggregation would overpower initial allocation costs unless extreme scarcity developed in the ipv6 space, which seems highly unlikely for the next 50-60 years at least.
We do not recommend an aggregation fee, for two reasons. First, it is unclear whether the problem of routing table bloat is serious enough to justify it. Currently, ISPs can filter prefixes that exceed a certain length if they are concerned about that problem, and as noted earlier the projected growth of the routing table may fall within the technological capacity of improvements in router capacity. Second, the number of routing announcements often reflects traffic engineering concerns. That is, organizations and ISPs use route announcements to steer traffic over specific link facilities. Traffic engineering can be as important to the efficiency of the Internet as route aggregation. Unless a serious crisis of routing table scalability emerges, it is probably better to avoid any route aggregation fees and allow ISPs to make these tradeoffs on their own.