Hi, regarding 6.1(4) - (default is /26, /25 is handed out upon request): The idea behind this part of the proposal is that there are two kinds of IXPs, one that is founded due to the need to interconnect a few networks in a specific region and no intent of growth and one that is operated with the explicit intent to grow and generate business. IXPs can decide on their plans on their own and do an appropriate selection of their initial assignment. regarding 6.1 (7) - (assignments down to /27): I agree that the policy can be gamed by asking for a /27 and jumping to a /24; we might consider to restrict this part to only handing out /27s once the IXP pool is depleted, but not upon request. I doubt RIPE has handed out any /27 assignments upon request anyways; maybe someone from RIPE can look into this? regarding the general point of lower bound of assignments and your comment:
Alternatively we would need to consider the supporting data for this proposal bogus.
As I have stated a couple of times in the previous discussions, the data in PeeringDB can only provide a lower bound of connections per IXP; nevertheless it remains the best dataset we currently have. Thus the decision will have to be a mix of listening to experienced people from the IXP community and the results of the analysis. I think a /26 is a good compromise here. 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 Tore Anderson <tore@fud.no> Gesendet: Montag, 16. Januar 2023 14:47:17 An: RIPE Address Policy Working Group Betreff: Re: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26) * Wolfgang Tremmel
a) a new IXP can simply ask for an initial /25 and receive it, no questions asked?
yes. But if a new IXP requests an initial /25 they at least have done some homework about what to expect. And I expect that homework to be shown to the RIPE NCC to get the /25.
What makes you expect any "homework" to be shown to the RIPE NCC, if the policy says they can have the /25, no questions asked? The policy needs to explicitly state that such "homework" is necessary if that is what you want.
b) an existing IXP that has used 50% of an initial /26 will be able to upgrade straight to a /24, i.e., bypassing a /25? (Or even %50-of- /27→/24, in an unlikely but not impossible corner case.)
Also yes. If the IXP grows really fast, they can go directly to a /24. Why? Renumbering an IXP is pain. A lot of pain. I (personally) have run renumbering projects or participated in renumbering projects multiple times.
Wouldn't that mean that the policy can be gamed? Procedure: 1. Request and receive an initial /27 (permitted by new section 8) 2. Reach 50% utilisation (12 members + 2 RSes + net/bcast addrs) 3. Request and receive a replacement /24 This "land-grabbing" IXP has now gotten its hands on a /24 while only at 6.25% utilisation. Nothing in the proposed policy will prevent this from happening, as far as I can tell. Should it?
2) Regarding «Assignments strictly larger than a /24 will only be made to IXPs that offer the exchange of IPv4 routing information over IPv6 at their route servers»:
a) What is the purpose / meaning of the word «strictly» here? I assume it is there for a reason, but removing it does not seem to me to change the meaning of the sentence in any way (but then again, I am not a native English speaker).
idea is: strictly larger > larger >=
Hm. I do believe «larger» means ">", not ">=". Maybe a native speaker could confirm. If so, «strictly» could and should be dropped as it only serves to add confusion.
However, when we are at at a point in time where the IXP pool is completely empty except for such «space dust», why restrict the assignment size to /27? It seems to me that if we have reached a point in time where the only thing remaining in the IXP pool is «space dust» smaller than /27, and there is a small new IXP that could make use of, say, a /28, I see no reason to deny the IXP receiving that assignment.
IMHO a /28 is not useful for an IXP. Or what I consider to be an IXP.
According to https://github.com/mwichtlh/address-policy-wg about 40% of all IXPs would fit in a /28 «with 50% oversubscription», and about 55% all IXPs would fit in a /28 with no oversubscription. I therefore think you might consider adjusting your perception of what an IXP is. Alternatively we would need to consider the supporting data for this proposal bogus. In any case, if the requesting new IXP gets offered a /28 (as that is all that is available at that point), it is of course free to decline. There is no harm in having the NCC make the offer, is there?
We can do that once the pool is empty in another policy change IMHO.
Why wait? What is the harm in doing it now? 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