* 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