[address-policy-wg] IXP pool lower boundary of assignments

* 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