[address-policy-wg] IXP pool lower boundary of assignments

Matthias,

Thanks for kicking this off!

On 27/10/2022 10.33, Matthias Wichtlhuber wrote:
> 
> Marco pointed out in the WG session, that we should probably start a discussion on the lower boundary of assignments from the IXP pool. I would like to kick off this discussion with this post.
> 
> When we had the discussion on the current policy in 2019, I posted an analysis of PeeringDB data, which I have updated with data from 2022 now (https://github.com/mwichtlh/address-policy-wg). The comparison of both analyses provides some interesting data points:
> 
> 1.) The overall number of IXPs is growing fast (951 IXPs up from 672 in 2019 with 1014 peering LANs up from 726 in 2019). To me, this looks more like exponential growth and honestly speaking I doubt the linear projection of depletion in 2029 presented in the WG. I think this will happen earlier.
> 
> 2.) The updated data clearly shows that the lower boundary of /24 assignments continues to create a lot of waste in terms of IP space, as ~80% of all IXPs would fit into a /25 (including 100% overprovisioning) and roughly 70% of all IXPs would even fit into a /26 (including 100% overprovisioning). Thus, decreasing the assignmemt size is unlikely to cause harm but might be very helpful to extend the lifetime of the pool into the 2030s.
> 
> Another pro I see here is that lowering the boundary would allow to extend the overall size of the pool, as we could ask RIPE to add IP space dust </24 to the pool, that cannot be assigned anyways because it cannot be routed; please note that IXPs commonly have no interest in routing their peering LAN space, e.g., leaking the peering LAN space at DE-CIX is explicitly disallowed for members and will quickly lead to a port shutdown for the respective AS because we don't want a route into the peering LAN for security reasons. With regard to that, the "bug" of non-routeable IP space could even be a feature for many IXPs, because it does not require monitoring external BGP collectors for route leaks.
> 
> At the same time, we should be well aware that we are only buying time. That's why we should kick off some initiative to test and deploy multi protocol BGP at IXPs (but that is probably a question for the IXP community).

My own feeling is that we should not do any of this, and require that 
IXP's get their IPv4 address space by buying it like everyone else has 
to do to run their businesses. Or use IPv6 and/or IPv4 space reserved 
for private use.

The IXP policy possibly made sense when it was impossible to meet the 
RIPE requirements for allocations, and there was concern about 
conflict-of-interest from IXP getting their space from an LIR. However, 
for most LIR there is no space from the RIPE NCC no matter how urgent 
their needs. So there is no longer a concern about conflict of interest.

Cheers,

--
Shane
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x3732979CF967B306.asc
Type: application/pgp-keys
Size: 11617 bytes
Desc: OpenPGP public key
URL: </ripe/mail/archives/address-policy-wg/attachments/20221030/a3a9b575/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: </ripe/mail/archives/address-policy-wg/attachments/20221030/a3a9b575/attachment.sig>