[address-policy-wg] IXP pool lower boundary of assignments
- Previous message (by thread): [address-policy-wg] IXP pool lower boundary of assignments
- Next message (by thread): [address-policy-wg] IXP pool lower boundary of assignments
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
David Farmer
farmer at umn.edu
Thu Nov 3 22:11:03 CET 2022
On Wed, Nov 2, 2022 at 3:00 AM Tore Anderson <tore at fud.no> wrote: > * David Farmer > > > I think maybe we want something in between; what do /27 and /28 look > > like? > > > > /29 could be forcing too much pain into the system, and /26 > > probably isn't enough pain in the system. > > > > Furthermore, /29 seems a little too small for a reasonable growth > > cycle before having to renumber. 50% fill of a /29 would be 3 of 6 > > usable addresses. Meaning many IXes could almost immediately qualify > > for a larger subnet, and they would have very much time to implement > > a renumbering process. > > The policy states that you get what you need to have a 50% utilisation > one year from assignment. > > Thus, in order to get an initial /28 assignment and skip over a default > /29, the IX would need to have a realistic plan to have eight members > within a year of the founding of the IX (or possibly just six, if the > NCC considers the network and broadcast addresses as «utilised»). > > That is a *very* low bar to clear. > > But if IX cannot clear that low bar, I'd say they should not start out > with a /28 (or larger) either. > > https://www.ripe.net/publications/docs/ripe-733#61 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. > Basically, a /29 is probably too small to be practical. > > > > Well, according to Mathias's report, 25% of all IX-es would manage just > fine with a /29… > > By the way, last I checked there were a number of unassigned fragments > smaller than /24 rotting away in the NCC's inventory, due to there > being no policy that allowed for their assignment. IX-es are one of the > very few places where those can be used, so they could be all added to > the reserved IXP pool and actually do some good there. > > Tore > 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. 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... 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. 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. Thanks. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.ripe.net/ripe/mail/archives/address-policy-wg/attachments/20221103/96614897/attachment.html>
- Previous message (by thread): [address-policy-wg] IXP pool lower boundary of assignments
- Next message (by thread): [address-policy-wg] IXP pool lower boundary of assignments
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]