This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] IXP pool lower boundary of assignments
- Previous message (by thread): [address-policy-wg] [ncc-announce] [news] RIPE NCC Response to Committee of the Verkhovna Rada of Ukraine
- Next message (by thread): [address-policy-wg] IXP pool lower boundary of assignments
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Matthias Wichtlhuber
matthias.wichtlhuber at de-cix.net
Thu Oct 27 10:33:24 CEST 2022
Hi address policy WG, 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). Regards, Matthias -- 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
- Previous message (by thread): [address-policy-wg] [ncc-announce] [news] RIPE NCC Response to Committee of the Verkhovna Rada of Ukraine
- Next message (by thread): [address-policy-wg] IXP pool lower boundary of assignments
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]