[ppml] IPv4 address and routing slot markets

[Scott Leibrand]

Paul Vixie wrote:
> randy at psg.com (Randy Bush) writes:
>   
>> but i personally feel that open market is the best course to flush out
>> and get registered the under-utilized space, whether legacy or not.
>> ...
>> what is important is as open and transparent a marketplace as possible.
>>     
>
> does any of this technology support tli's proposed routing table slot market?
>   

In my opinion a full-settlement routing table slot market is impractical 
and undesirable.  However, as Tony outlined at the markets panel at ABQ, 
there needs to exist some sort of backpressure against the deaggregation 
and global announcement of too many small blocks.  If we set the 
conditions properly, I believe we can create the framework for such 
backpressure to exist, and place the economic cost of announcing 
deaggregates largely on the originator rather than as an externality on 
the entire DFZ.

For your weekend reading pleasure, below is one way it might work.  Keep 
in mind that what I'm outlining is not practical or desirable today, 
because the current underlying cost of a routing slot is so small 
compared to the cost of passing traffic.  The scenario outlined here 
will only come to exist if the post-free-pool-exhaustion demand for IPv4 
space and routing slots outpaces the ability of ISPs to provide 
additional routing slots relatively cheaply.

Firstly, we need to keep something close to the existing IPv4 minimum 
block sizes.  Today multihomed orgs can get /22s and larger from ARIN, 
and non-multihomed orgs can get /20s and larger.  Let's assume that we 
continue such a policy into the post-exhaustion era, allowing transfers 
only of blocks of that size or larger.

The other part of the framework is that major DFZ participants 
(particularly tier 1 NSPs) would need to agree on a BCP to require 
everyone (or their ISP) to announce RIR-minimum-size covering aggregates 
for all their announced space.  For any cases where that is impractical, 
they could instead agree to tag (i.e. with communities) and accept 
more-specifics that don't have a covering aggregate.  If significant 
numbers of such routes exist, they would likely be the subject of 
peering negotiations, much as with traffic ratios today.

With those two pieces in place, it becomes possible to differentiate 
between aggregates, which are required for reachability and should be 
accepted across the DFZ, and more-specifics, which only need to be 
accepted by networks maintaining a business relationship of some kind.  
If routing slots are still cheap, no one would have any real incentive 
to filter such more-specifics, but if the number of routes grows at more 
than 2X the current rate, I could see filtering and routing slot 
backpressure developing along lines something like this:

Say you have a multihomed network who wants finer-grained control over 
their inbound traffic than can be obtained with AS path prepends and 
localpref communities.  They contact their ISPs and ask them to open 
their prefix-lists for their more-specifics.  The ISPs do so (possibly 
charging the customer based on the number of routes announced), and also 
update their prefix-lists to accept the more-specifics from their 
peers.  (If either of the ISPs buys transit, they request that their 
upstreams accept the route as well, and the upstreams also accept the 
route from their peers.)   This ensures that all of the network's 
upstreams accept the route, both directly from their downstreams as well 
as from any other upstreams, and gives the multihomed network full 
control over which of their links inbound traffic arrives on.  However, 
any tier 1s that are not upstreams (and not being paid) need not accept 
the more-specifics, and can simply route based on the covering 
aggregate.  Once traffic hits one of the network's upstreams, the 
more-specific will take over.

All of this may seem rather complicated compared to today's system, but 
remember that this would only make sense if the cost of routing table 
slots goes up dramatically.  If the cost remains low, then we don't have 
a problem and can continue business as usual.  But if it does, we have 
decent mechanisms, using existing deployed technologies and business 
relationships, to relieve the pressure.

The most important factor here, however, is maintaining a reasonable 
minimum top-level prefix size.  As long as that level of aggregation 
exists, we can allow more-specifics to be announced to upstreams for TE, 
while preserving the ability of parties not being paid to filter them 
without losing reachability.  However, if we go ahead and allow full 
deaggregation down to /24, as Geoff's proposal in APNIC would do, then 
we lose the ability to filter such routes without losing reachability.

-Scott