<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 2, 2022 at 3:00 AM Tore Anderson <<a href="mailto:tore@fud.no">tore@fud.no</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* David Farmer<br>
<br>
> I think maybe we want something in between; what do /27 and /28 look<br>
> like?<br>
> <br>
> /29 could be forcing too much pain into the system, and /26<br>
> probably isn't enough pain in the system.<br>
> <br>
> Furthermore, /29 seems a little too small for a reasonable growth<br>
> cycle before having to renumber. 50% fill of a /29 would be 3 of 6<br>
> usable addresses. Meaning many IXes could almost immediately qualify<br>
> for a larger subnet, and they would have very much time to implement<br>
> a renumbering process.<br>
<br>
The policy states that you get what you need to have a 50% utilisation<br>
one year from assignment.<br>
<br>
Thus, in order to get an initial /28 assignment and skip over a default<br>
/29, the IX would need to have a realistic plan to have eight members<br>
within a year of the founding of the IX (or possibly just six, if the<br>
NCC considers the network and broadcast addresses as «utilised»).<br>
<br>
That is a *very* low bar to clear.<br>
<br>
But if IX cannot clear that low bar, I'd say they should not start out<br>
with a /28 (or larger) either.<br>
<br>
<a href="https://www.ripe.net/publications/docs/ripe-733#61" rel="noreferrer" target="_blank">https://www.ripe.net/publications/docs/ripe-733#61</a></blockquote><div><br></div><div> I think the need for a creative writing exercise should be avoided by starting with a /28 as the default, then being very skeptical of optimistic growth projections of unproven IXPs.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Basically, a /29 is probably too small to be practical. <br>
> <br>
<br>
Well, according to Mathias's report, 25% of all IX-es would manage just<br>
fine with a /29…<br>
<br>
By the way, last I checked there were a number of unassigned fragments<br>
smaller than /24 rotting away in the NCC's inventory, due to there<br>
being no policy that allowed for their assignment. IX-es are one of the<br>
very few places where those can be used, so they could be all added to<br>
the reserved IXP pool and actually do some good there.<br>
<br>
Tore<br></blockquote><div> </div></div><div>As I see it if an IXP has fewer than three(3) participants it really isn't an IXP. there seem to be quite a few IXPs with less than three(3) participants as required by policy. How is this requirement currently implemented? I would hope RIPE NCC requires at least a letter of intent from three(3) or more participants. </div><div><br>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...</div><div><br>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. Furthermore, starting with a /28 will provide up to 16 times as many IXPs. Obviously, we won't get to that many more IXPs, but 4 or 5 times as many IXPs seems realistic to me. Many IXPs will succeed and grow, consuming more of the reserved pool, but that is a good thing.</div><div><br>Finally, maybe there should be a maximum allocation size of /24. An IXP that is successful enough to need more than a /24 probably can afford to go to the marketplace for the additional IPv4 address space it needs. This reserved pool should be there to facilitate new IXPs and get them to a critical mass of suitability. Not to facilitate the growth of the largest IXPs. While the further growth of IXPs is important, once they get to a critical mass, they can probably fend for themselves in the marketplace without relying on a reserved pool.</div><div><br>Thanks.<br></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">===============================================<br>David Farmer <a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@umn.edu</a><br>Networking & Telecommunication Services<br>Office of Information Technology<br>University of Minnesota <br>2218 University Ave SE Phone: 612-626-0815<br>Minneapolis, MN 55414-3029 Cell: 612-812-9952<br>=============================================== </div></div>