* 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