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

On Fri, Nov 4, 2022 at 04:56 Tore Anderson <tore at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20221104/79d41f9c/attachment.html>