Hi, On Thu, Oct 27, 2022 at 04:23:20PM +0200, Sander Steffann wrote:

To add to this discussion: I took this to the Connect WG, and the initial feedback I got from there is that they have no problem with reevaluating this every 8 or so years (what seems to be the current rate of use of the IXP pool), and that they would be perfectly happy with not doing anything right now and reevaluating this in 2027 or so.

By then, all the IXP landscape will be DECIX global layer2 anyway, so all we need is a /15 for DECIX, and all the ASes in the world can connect to it. Now, getting that /15 might be a bit complicated... maybe we really need to go for "ipv4 over ipv6 transport", then, like the cloudfolks already do... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

On Thu, Oct 27, 2022 at 4:21 PM Arnold Nipper <arnold.nipper@de-cix.net> wrote:

I would have expected that you have to add serious content. Looks like you are getting old, too.

Hopefully, you find this to be a serious comment; if not, my apologies ahead of time. ARIN has a policy for Reserved Pool Replentishemnet. https://www.arin.net/participate/policy/nrpm/#4-1-7-reserved-pool-replenishm... It was ARIN-2019-21; https://www.arin.net/participate/policy/drafts/2019_21/ The basic idea of the policy is to return recovered resources allocated from reserved pools to their respective reserved pool, if they are ever returned, and to have a default action of replenishing the reserved pools when or if they get down to a three-year or less supply. Until then, other recovered resources go to the waiting list. Even then the idea is to only replenish reserved pools to or maintain a running three-year supply in each reserved pool; any resources recovered beyond that would still go to the waiting list. Without this policy, when or if ARIN's reserved pools get low, they would run out unless we had a consensus for a policy to change things at that time to replenish them. However, with this policy, the default action is to replenish the reserved pools when or if they get low. Unless there is consensus at that time to let them run out, requiring policy action at that time. Note ARIN policy has two reserved pools defined in sections 4.4 and 4.10 4.4. Micro-allocation (for Critical Infrastructure, including IXPs) and; 4.10. Dedicated IPv4 Block to Facilitate IPv6 Deployment https://www.arin.net/participate/policy/nrpm/#4-4-micro-allocation https://www.arin.net/participate/policy/nrpm/#4-10-dedicated-ipv4-block-to-f... Also, resources from the reserved pool can only be transferred through M&A and not on the open market since they were reserved for special purposes. This may or may not be how the RIPE community wishes to do things, but I thought it would be an option worth considering. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================

Hi,

On Thu, Oct 27, 2022 at 04:23:20PM +0200, Sander Steffann wrote: To add to this discussion: I took this to the Connect WG, and the initial feedback I got from there is that they have no problem with reevaluating this every 8 or so years (what seems to be the current rate of use of the IXP pool), and that they would be perfectly happy with not doing anything right now and reevaluating this in 2027 or so. This will be taken to the Connect WG mailing list, so let's keep an eye on that to see whether action is necessary at all.

As per my analysis, there has been a ~40% increase in IXPs world-wide over the last three years (see my initial mail). Given that number, I don't think we should wait and continue wasting space with too large assignments until 2027.

On Thu, Oct 27, 2022 at 20:59:20PM +0200, Gert Döring wrote: Now, getting that /15 might be a bit complicated... maybe we really need to go for "ipv4 over ipv6 transport", then, like the cloudfolks already do...

Sure, we should go for multihop hop BGP in the future. But (correct me if I'm wrong) this is probably a question for the Euro-IX folks. This will require a major testing effort from the IXP community with all kinds of vendors and route server implementations and we need to develop best practices for that; thus, it makes sense to stretch the existing pool as long as possible. Please note this proposal also affects DE-CIX, because most of our IXPs are not exactly the size of Frankfurt. IMHO, the default assignment should be something like /25. 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@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: address-policy-wg <address-policy-wg-bounces@ripe.net> im Auftrag von Kurt Kayser <Kurt.Kayser@online.de> Gesendet: Freitag, 28. Oktober 2022 00:49:25 An: address-policy-wg@ripe.net Cc: Sander Steffann; Arnold Nipper; Gert Doering Betreff: Re: [address-policy-wg] IXP pool lower boundary of assignments Arnold, yes we are all getting older..

I would have expected that you have to add serious content. Looks like you are getting old, too.

Arnold Btw.: It's DE-CIX, not DECIX, DEC-IX or any other variation :)

DE-CIX - easy to remember, like DE-PEER oder DE-ICE :-) .kurt PS: yes, just having fun :-) -- 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

* Matthias Wichtlhuber

As per my analysis, there has been a ~40% increase in IXPs world-wide over the last three years (see my initial mail). Given that number, I don't think we should wait and continue wasting space with too large assignments until 2027.

I agree, but as I also said back when 2019-05 was being discussed…

IMHO, the default assignment should be something like /25.

…I believe the default (and minimum) should be /29. Lavishing /25s on IXPs with just a handful of members is really not that much better than the /24s we currently give them. If the ISP needs something larger than the default, there is no problem. All it has to do is to ask for a larger assignment, just like today. Tore

* 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

* Matthias Wichtlhuber

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

Thank you for updating! It is always nice to have real data to look at. I think I disagree with your use of «only». 25% isn't «only» in my opinion, that's a quite considerable share of the total. If I read your report correctly, the group of IX-es that will manage comfortably with a /29 is in fact the largest group of them all! (Here I do say manage "comfortably" since your report state that it assumes 100% oversubscription, which I take to mean that the IX-es in each bracket can *at least* double their member count without running out of addresses.) Also I don't understand your «crippling the growth» concern. The 75% if IX-es that need something bigger then a /29, they would of course get something bigger – just like they do today, if they need something bigger than a /24. Has today's policy, where /24 is the default, «crippled» any IX from growing past 254 connected members? If not, how exactly would a default /29 policy «cripple» an IX from growing past 6 members, or a default /28 «cripple» it from growing past 14 members for that matter? Or to put it another way: if we change the default to /25 or /26 as you propose, wouldn't that change – in the exact same way as for /29 – «cripple the growth» of those IX-es past 126 or 62 connected members? If so, how come that is OK, if it isn't OK for /29? Tore

On Tue, Nov 1, 2022 at 10:31 AM Wolfgang Tremmel < wolfgang.tremmel@de-cix.net> wrote:

No. But renumbering an IX is *pain*. A lot of pain. You want to avoid that if possible. A /26 allows (given that the IX uses about 2-4 IPs itself) about 60 customers.

So according to the numbers, for 70% of the IXes this will never fill up, so no need for renumbering. Depending on how quickly it filled up, you then go either for a /25 or a /24.

To sum up: - if you start with a /26 ==> 30% has to renumber - if you start with a /29 ==> 75% has to renumber ---> more pain!

I think maybe we want something in between; what do /27 and /28 look like? /29 could be forcing too much pain into the system, and /26 probably isn't enough pain in the system. Furthermore, /29 seems a little too small for a reasonable growth cycle before having to renumber. 50% fill of a /29 would be 3 of 6 usable addresses. Meaning many IXes could almost immediately qualify for a larger subnet, and they would have very much time to implement a renumbering process. Whereas with a /28, 50% fill would be 7 of 14 usable addresses. That seems like it would allow for reasonable growth before having to renumber and some runway to actually accomplish the renumbering process. Basically, a /29 is probably too small to be practical. Thanks

...

Am 1. Nov 2022 um 15:48 schrieb Tore Anderson <tore@fud.no>:

If not, how exactly would a default /29 policy «cripple» an IX from growing past 6 members, or a default /28 «cripple» it from growing past 14 members for that matter?

-- Wolfgang Tremmel

Phone +49 69 1730902 0 | wolfgang.tremmel@de-cix.net Executive Directors: Ivaylo Ivanov and Sebastian Seifert | Trade Registry: AG Cologne, HRB 51135 DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | Germany | www.de-cix.net

--

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

-- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================

On Wed, Nov 2, 2022 at 3:00 AM Tore Anderson <tore@fud.no> wrote:

* David Farmer

...

I think maybe we want something in between; what do /27 and /28 look like?

/29 could be forcing too much pain into the system, and /26 probably isn't enough pain in the system.

Furthermore, /29 seems a little too small for a reasonable growth cycle before having to renumber. 50% fill of a /29 would be 3 of 6 usable addresses. Meaning many IXes could almost immediately qualify for a larger subnet, and they would have very much time to implement a renumbering process.

The policy states that you get what you need to have a 50% utilisation one year from assignment.

Thus, in order to get an initial /28 assignment and skip over a default /29, the IX would need to have a realistic plan to have eight members within a year of the founding of the IX (or possibly just six, if the NCC considers the network and broadcast addresses as «utilised»).

That is a *very* low bar to clear.

But if IX cannot clear that low bar, I'd say they should not start out with a /28 (or larger) either.

https://www.ripe.net/publications/docs/ripe-733#61

I think the need for a creative writing exercise should be avoided by starting with a /28 as the default, then being very skeptical of optimistic growth projections of unproven IXPs.

Basically, a /29 is probably too small to be practical.

...

Well, according to Mathias's report, 25% of all IX-es would manage just fine with a /29…

By the way, last I checked there were a number of unassigned fragments smaller than /24 rotting away in the NCC's inventory, due to there being no policy that allowed for their assignment. IX-es are one of the very few places where those can be used, so they could be all added to the reserved IXP pool and actually do some good there.

Tore

As I see it if an IXP has fewer than three(3) participants it really isn't an IXP. there seem to be quite a few IXPs with less than three(3) participants as required by policy. How is this requirement currently implemented? I would hope RIPE NCC requires at least a letter of intent from three(3) or more participants. So, if an IXP starts with three(3) participants, per policy, with a /29, it is already at 50% full, leaving 3 addresses for growth, and that doesn't include any infrastructure IP addresses, like a route server(s), etc... Therefore, starting at a /28 makes more sense to me. Forcing most IXPs to renumber almost right out of the gate doesn't make much sense to me. Furthermore, starting with a /28 will provide up to 16 times as many IXPs. Obviously, we won't get to that many more IXPs, but 4 or 5 times as many IXPs seems realistic to me. Many IXPs will succeed and grow, consuming more of the reserved pool, but that is a good thing. Finally, maybe there should be a maximum allocation size of /24. An IXP that is successful enough to need more than a /24 probably can afford to go to the marketplace for the additional IPv4 address space it needs. This reserved pool should be there to facilitate new IXPs and get them to a critical mass of suitability. Not to facilitate the growth of the largest IXPs. While the further growth of IXPs is important, once they get to a critical mass, they can probably fend for themselves in the marketplace without relying on a reserved pool. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================

* David Farmer

So, if an IXP starts with three(3) participants, per policy, with a /29, it is already at 50% full, leaving 3 addresses for growth, and that doesn't include any infrastructure IP addresses, like a route server(s), etc...

Exactly, a tiny IXP with three founding members would have enough space to double in size before needing to renumber out of an initial /29. For a slightly larger IXP with six founding members (or four founding members + two route servers and so on), the situation would be exactly the same - it would have enough space to double in size before needing to renumber out of an initial /28. And so on… (BTW: «founding member» here means «connects within the first year»)

Therefore, starting at a /28 makes more sense to me. Forcing most IXPs to renumber almost right out of the gate doesn't make much sense to me.

It seems that you assume here that all/most IXPs will grow out of an initial /29 and therefore require renumbering «right out of the gate». If that was the case, I would not suggest /29 as the default. However, Matthias's numbers seem to suggest otherwise, with plenty of IXPs (~25%) managing just fine with a /29. This does not surprise me all that much. If you set establish IXP in some rural location (in Longyearbyen, let's say), there is an almost zero percent chance there will be more than six members connecting in the foreseeable future because there are so few operators servicing that area. While AMS-IX, DE-CIX, LINX, Netnod and the like are probably what springs to mind when one says «IX», it would appear that behemoths like those are exceptionally rare and few in numbers compared to the small ones with just a handful of members, and I think it would be wise to keep that in mind when developing this policy further. Anyway, for the IXPs that *would* grow out of an /29, it's not like renumbering is *that* hard. Current policy grants 180 days to complete the renumbering, and when the IXP is just 4-5-6 members, it would even be doable to just gather everyone on a teleconference call and just do it all together.

Finally, maybe there should be a maximum allocation size of /24.

Policy currently has a maximum limit of /22, for what it is worth. So even the behemoth IX-es with up to 1K members are catered to by this policy. I'm fine with that. Tore

* David Farmer

You seem to want to optimize for the smallest of the small IXPs, tiny IXPs as you put it. How about we optimize for just plain small IXPs?

No, what I want is to optimise equally for all sizes of IX-es. It is the current optimisation of (read: overassignment to) small IX-es I would like to see ended. In other words: an IX with X members should get the smallest /Y prefix that can fit X. That should go equally for any value of X. That is: …if X=4, then Y=29. …if X=40, then Y=26. …if X=400, then Y=23. …and so forth. If any IX wants to double in size, it would need to renumber exactly once. This would constitute totally fair and equal treatment for all IX-es regardless of size, the way I see it – and it would be the the exact opposite of «optimising for the smallest of the small IXPs».

If those tiniest IXPs, get 14 usable addresses instead of only 6, that doesn't seem like it's that much of a waste.

I doubt the IXPs, that in the future will be denied any assignment whatsoever due to wasteful assignments causing the premature exhaustion of the IXP pool, will see it that way.

We were giving those tiniest IXPs a /24 or 254 usable addresses until now. How stingy do we have to be?

I think we can and should stop *all* waste at this point. We cannot expand the pool like we did in 2019-05, so to make the IXP pool last all we can do is to stop wasting space on IXPs that don't need it, and that does indeed include not giving /28s to IXPs that only need /29s. Giving out /24s by default was IMHO extremely short-sighted, and I did speak out against doing so in the past. I am not therefore not at all surprised that we find ourselves in this situation. Again. Tore

Hi Marcus,

Two, the numbers Matthias supplied are great and we can definitely get some information for this discussion from them. However, they are a snapshot in time. For the argument you are making we would need this data over time, and the question to ask would be "How long does an IXP which fits in a /29 stays in this category?". We cannot get this information from the data, so we shouldn't base assumptions and policy on this.

Thank you for pointing that out, Marcus. You are totally correct, the analysis does not tell you anything about how fast IXPs grow. Another limitation I would like to add: the data source is peeringDB and there is an unknown amount of ASes that do not add an entry to peeringDB if they join an IXP. Thus I would refrain from defining an extremely tight-knit policy based on this analysis. I don't get the point of the /29 discussion anyways. It is based on the false assumption that we need to stretch the pool to eternity and beyond. We need to stretch the pool until we can test and establish IPv4 over IPv6 peering LANs. A /26 default is perfectly fine for that. 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@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: address-policy-wg <address-policy-wg-bounces@ripe.net> im Auftrag von Marcus Stoegbauer <marcus@grmpf.org> Gesendet: Montag, 7. November 2022 23:48:42 An: address-policy-wg@ripe.net Betreff: Re: [address-policy-wg] IXP pool lower boundary of assignments On 5 Nov 2022, at 9:14, Tore Anderson wrote:

* David Farmer

...

You seem to want to optimize for the smallest of the small IXPs, tiny IXPs as you put it. How about we optimize for just plain small IXPs?

No, what I want is to optimise equally for all sizes of IX-es. It is the current optimisation of (read: overassignment to) small IX-es I would like to see ended.

In other words: an IX with X members should get the smallest /Y prefix that can fit X. That should go equally for any value of X. That is:

…if X=4, then Y=29. …if X=40, then Y=26. …if X=400, then Y=23.

…and so forth. If any IX wants to double in size, it would need to renumber exactly once.

This would constitute totally fair and equal treatment for all IX-es regardless of size, the way I see it – and it would be the the exact opposite of «optimising for the smallest of the small IXPs».

In the case of IXPs I consider larger assignments up to a certain point as a technical necessity rather than a situation we need to rectify. Handing out /29s to a new IXP IMO puts a large burden on newly founded IXPs (since they would need to renumber earlier) which gives them an unfair disadvantage. This I consider a larger problem than eventually running out of addresses in the pool altogether. My counter argument is twofold: One, it's easier for an IXP to grow from 4 to 8 members than it is to grow from 40 to 80 members, so the likelihood that a very small IXP would need to renumber is larger than for already established IXPs with larger address space. Two, the numbers Matthias supplied are great and we can definitely get some information for this discussion from them. However, they are a snapshot in time. For the argument you are making we would need this data over time, and the question to ask would be "How long does an IXP which fits in a /29 stays in this category?". We cannot get this information from the data, so we shouldn't base assumptions and policy on this. Marcus

* Matthias Wichtlhuber

I don't get the point of the /29 discussion anyways. It is based on the false assumption that we need to stretch the pool to eternity and beyond. We need to stretch the pool until we can test and establish IPv4 over IPv6 peering LANs. A /26 default is perfectly fine for that.

While I do hope you will be proven to be right about that, I am not so optimistic. The industry's track record on being able to migrate away from IPv4 to IPv6 before the exhaustion of the former is not great, to put it mildly. That even goes for the IXP pool specifically: In 2011, we thought a /16 with a default assignment size of /24 would suffice to «safeguarding future IXPs with IPv4 space». In 2019, we realised that was too optimistic, doubling the pool size to a /15, keeping the default /24. In 2022, we are again realising that we were too optimistic, leaving the pool size unchanged (for obvious reasons), but aiming to reduce the default size to /26. Perhaps third time's the charm. I do hope so, really, but again - not optimistic. George Santayana's observation comes to mind: «those who cannot remember the past are condemned to repeat it». Tore

If we think router vendors are in a position to reliably support v4 AF over BGP in v6, and actually route this traffic

Will Hargrave wrote on 08/11/2022 13:48: this is kinda the problem with RFC 5549, no? I.e. it deals only with signaling rather than transport. So even if it's deployed, the IXP will still need to provide ipv4 addresses for transport purposes. Nick

* Nick Hilliard

this is kinda the problem with RFC 5549, no?  I.e. it deals only with signaling rather than transport. So even if it's deployed, the IXP will still need to provide ipv4 addresses for transport purposes.

Apart from the BGP session itself (which supports multi-AF), the addresses are just needed for resolution of the next-hop layer-2 address. There's no real reason that address needs to be IPv4 and resolved via ARP, it can be resolved just as well with IPv6 ND, as I understand it. For example, on Linux, you can program the FIB in this way: $ ip route add 192.0.2.0/24 via inet6 fe80::1 dev eth0 The 'eth0' interface does not need any IPv4 addresses assigned. Obviously the major router vendors need to build in corresponding capability in their BGP software for IPv6-only IX-es to be a realistic proposition. I have no idea if they have. Tore

Hi, On Tue, Nov 08, 2022 at 04:38:52PM +0000, Nick Hilliard wrote:

...

For example, on Linux, you can program the FIB in this way:

$ ip route add 192.0.2.0/24 via inet6 fe80::1 dev eth0

The 'eth0' interface does not need any IPv4 addresses assigned.

Right, ipv4 forwarding using ipv6 next hop resolution. Wow, that's ugly and likely to introduce an entirely new class of low-level forwarding bugs.

Cloud folks want this anyway, for configuring eBGP peers over link-local on p2p ethernets ("neighbour eth3 remote-as 12345"). Quite a few vendors can do this already. It's not that hard, actually, if the FIB is built "with L2 next-hop info right in the data structure" - when populating the FIB, you either do ARP or ND lookups, store the NH MAC + oif, done. Of course, getting support for this in my trusty 6500 won't be easy... (but vendor willing, even that one could learn to do it - this is pure control plane, and data plane punt if no L2 NH is known) Yeah. Multi-decade journey... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

Actually you want RFC 8950. https://datatracker.ietf.org/doc/html/rfc8950 On Tue, Nov 8, 2022 at 07:55 Nick Hilliard <nick@foobar.org> wrote:

...

If we think router vendors are in a position to reliably support v4 AF over BGP in v6, and actually route this traffic

Will Hargrave wrote on 08/11/2022 13:48: this is kinda the problem with RFC 5549, no? I.e. it deals only with signaling rather than transport. So even if it's deployed, the IXP will still need to provide ipv4 addresses for transport purposes.

Nick

--

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

-- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================

* Marcus Stoegbauer

In the case of IXPs I consider larger assignments up to a certain point as a technical necessity rather than a situation we need to rectify. Handing out /29s to a new IXP IMO puts a large burden on newly founded IXPs (since they would need to renumber earlier) which gives them an unfair disadvantage. This I consider a larger problem than eventually running out of addresses in the pool altogether.

That's a fair position to have, and if it is indeed now the desire of the IXP community to continue overassigning to IX-es founded in the near future at the cost of not being able to assign anything to IX-es in the further future, then by all means, be my guest. I do note that this does seem somewhat at odds with the stated rationales of proposals 2011-05 and 2019-05, though.

My counter argument is twofold:

One, it's easier for an IXP to grow from 4 to 8 members than it is to grow from 40 to 80 members, so the likelihood that a very small IXP would need to renumber is larger than for already established IXPs with larger address space.

Perhaps so, but do keep in mind that an IX that are expected to grow past 5 members within one year of its founding would not get a /29 to begin with, they would start out with an initial /28 (or bigger).

Two, the numbers Matthias supplied are great and we can definitely get some information for this discussion from them. However, they are a snapshot in time. For the argument you are making we would need this data over time, and the question to ask would be "How long does an IXP which fits in a /29 stays in this category?". We cannot get this information from the data, so we shouldn't base assumptions and policy on this.

That is a valid point, and it would indeed be useful to know for how long, on average, an IX stays within a given bracket. However, both the current snapshot and the one back in 2019 showed that small IX-es are overrepresented, with the very smallest («would fit into a /29 with 100% overprovisioning») being the most populous bracket by a wide margin. I can think of only two explanations for this: One being that many small IX-es simply do not grow, or at least are growing very slowly, thus staying for a long time within a bracket. The other one is that the rate of new IX-es being founded is accelerating, in other words that the rate of new small IX-es showing up is exceed the rate of recently founded IX-es growing out of their initial brackets. Either way it seems like continuing a policy of overprovisioning would hasten the total exhaustion of the IX pool, which of course is to the detriment of any new IX-es appearing past that point in time. Matthias's report makes the following observation: «the default policy of assigning /24s has created large amounts of unused space», which is 100% true. I warned against exactly this against during the discussion of 2019-05, but nobody listened, and so here we are again. Anyway, dealing with this now by adjusting down the minimum assignment size to, say, /26 will not solve this fundamental issue that Matthias observed, we will still be overassigning space, just at a reduced rate. I predict that that if we go for a /26 this time, a few years from now we will end up in the exact same spot as we are today, looking to make further policy adjustments in order to further extend the lifetime of what remains of the IXP pool. Of course, space we will have wasted by overassigning /26s until then will not be reclaimable, just like the space we have already wasted by overassigning /24s until today is not. This wasted space is permanently «stolen» from the future IX-es. If that is what the IX community wants, then go for it! I do hereby reserve the right to once again say «I told you so», though. ;-) Tore