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

Last time we extended the pool, but we did not change the burn rate by setting /24s as the default. You can easily see that in Marco's presentation, the extended pool is currently emptied at a comparable rate as before.

If we change the default to /26, that would mean a quarter of the previous burn rate thus quadrupling the lifetime of the pool (if we assume a constant burn rate). I do not see the pattern repeating here.

Moreover, I have updated the analysis to include /29s (which I previously cut off). Only ~25% of all IXPs would fit into such a small peering LAN. Setting the default to /29 will likely cripple the growth of IXes. There is also no benefit in retaining these resources if they are needed.

https://github.com/mwichtlh/address-policy-wg

--
Dr.-Ing. Matthias Wichtlhuber
Senior Researcher
------------------------------
DE-CIX Management GmbH
Lindleystr. 12, 60314 Frankfurt (Germany)
phone: +49 69 1730902 141
mobile: +49 171 3836036
fax: +49 69 4056 2716
e-mail: matthias.wichtlhuber at de-cix.net
web: www.de-cix.net
------------------------------
DE-CIX Management GmbH
Executive Directors: Ivaylo Ivanov and Sebastian Seifert
Trade registry: District court (Amtsgericht) Cologne, HRB 51135
Registered office: Lichtstr. 43i, 50825 Cologne
------------------------------
DE-CIX 25th anniversary: Without you the Internet would not be the same!
Join us on the journey at https://withoutyou.de-cix.net


________________________________________
Von: Tore Anderson <tore at fud.no>
Gesendet: Dienstag, 1. November 2022 12:18:45
An: Matthias Wichtlhuber; Kurt Kayser; address-policy-wg at ripe.net
Cc: Sander Steffann; Arnold Nipper; Gert Doering
Betreff: Re: AW: [address-policy-wg] IXP pool lower boundary of assignments

* Matthias Wichtlhuber

> While I think a /29 would be too radical (renumbering peering LANs
> can be a real headache, you don't want to do that more often than
> needed), a /26 as a default might be a good compromise. 62 usable
> addresses are still enough for ~70% of all IXes including 100% over
> provisioning. This would likely stretch the pool well into the 2030s.

The IXP pool was created in 2012 (2011-05).

In 2019 (2019-05) we went «whoops, we're burning through it too fast,
more is needed», and doubled its size.

In 2022, today, we're again going «whoops, we're burning through it too
fast», proposing to only slightly change the default assignment value
to /25 (or /26).

I see a pattern here…

How long before the next «whoops, we're burning through it too fast»?
Will we at that point change the default by another bit, going to /26
(or /27)?

Renumbering is a headache, but it is doable (it has been done many
times before), and the IXP community could certainly create a BCP
document on how to best do it – if one does not exist already.

Conditioning new IXPs already from their very infancy that they will
need to renumber every time they double in size already (when
renumbering is the least painful) is not unreasonable, in my opinion.
This requirement is balanced against the preservation of the IXP pool
for future and growing IXPs, after all.

If a new IXP with three founding members and a small/unrealistic
prospect of future growth applies for an IXP assignment, I think the
radical approach is to give that IXP something larger than the /29 it
actually requires. Doing so will inevitably mean that some other IXP
will be told «sorry, fresh out, no assignment for you» at some point in
the future.

Tore