On Fri, Nov 4, 2022 at 04:56 Tore Anderson <tore@fud.no> wrote:

* 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».

I did not say or even imply “all.” I said "most," maybe a more descriptive quantifier would have been "majority." However, at 75%, "super-majority" is probably an even more accurate term. So, "most" still seems to be an appropriate quantifier in my opinion.

Furthermore, looking at the graph on Matthias' GitHub site, even a /28 only covers 40% of IXPs; therefore even with a /28, the majority or most of IPXs, 60%, are still larger than that.

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? If those tiniest IXPs, get 14 usable addresses instead of only 6, that doesn't seem like it's that much of a waste. We were giving those tiniest IXPs a /24 or 254 usable addresses until now. How stingy do we have to be?

Thanks.