[address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs)

* Matthias Wichtlhuber

> I have compiled an in-depth analysis of peeringdb data. You can find a
> full description of the method, scripts, data and the main results on
> github:
> 
> https://github.com/mwichtlh/address-policy-wg/

Very nice work! Thank you for sharing this!

> Some interesting takeaways:
> 
> * Roughly 83% of all IXPs would theoretically fit into a /25. This
> already includes 100% overprovisioning, i.e., 2xconnected ASes/IXP. At
> the same time, 74% of all peering LANs are /24s. Consequently, the
> default policy of assigning /24s has created large amounts of unused
> space.

This makes me even more convinced that the default assignment size should not be set at /24, but that the assignment should be right-sized to best match the request - all the way down to the minimum assignment size.

Another takeaway: looking at Figure 2 it would appear that more than 40% of IXPs would fit all their members in a /28.

There are fragments as small as /29 sitting in NCC inventory. They are currently not allocatable or assignable due to the lack of any policy permitting this.

I believe /29 should be minimum assignment size (and not /27 as currently proposed), as IXPs are one of the very few use cases where fragments smaller than /24 are useful. There is no reason to let these fragments rot in the NCC's cellar, if they could possibly be used by an IXP somewhere.

(Just here in Norway there are four different IXPs that could make do with a /29 given their current member count: TRDIX, BIX, TIX and SIX. This is not because they are brand new or anything, they just happen to be located in regional locations where there is a limited number of potential members.)

For IXPs that are about to grow out of an initial small assignment, swapping it for a larger one is doable (and the smaller they are, the less of a hassle the renumbering operation is). The policy already facilitates this (although it should probably not specify that the replacement is a /23, which the current proposal does).

> I back the proposal except for the limitation to a /23. I propose
> having a /21 as an upper limit with thorough checks by RIPE.

I would not object to that.

Tore