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: [email protected] 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 <[email protected]> Gesendet: Dienstag, 1. November 2022 12:18:45 An: Matthias Wichtlhuber; Kurt Kayser; [email protected] 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 -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
