This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[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 ]
Tore Anderson
tore at fud.no
Wed Nov 2 09:00:25 CET 2022
* Wolfgang Tremmel > > No. But renumbering an IX is *pain*. A lot of pain. You want to > > avoid that if possible. > > A /26 allows (given that the IX uses about 2-4 IPs itself) about 60 > > customers. > > > > So according to the numbers, for 70% of the IXes this will never > > fill up, so no need for renumbering. > > Depending on how quickly it filled up, you then go either for a /25 > > or a /24. > > > > To sum up: > > - if you start with a /26 ==> 30% has to renumber > > - if you start with a /29 ==> 75% has to renumber ---> more pain! I do not think that insulating IX-es from possibly having to renumber when they double in size should be something this policy should aim to accomplish. (If it was, we could simply give everyone /22s or larger.) IPv4 is a limited and finite resource – the goal should be to make it last. Looking at Matthias's graphs, for each new IX that is assigned a /26, there is an about 70% chance of that assignment being wastefully large. Making such assignments will inevitably result in other new IX-es being denied assignments, because there is nothing left, because the space those IX-es *could* have used was given to first IX – even though the first IX had no need for it. So, all in all, I think that assigning IX-es the amount of space they *actually* need, but no more, and require them to renumber into a larger prefix whenever they double in size is a fair deal, when balanced against avoiding waste and preserving space for future IX-es (and existing growing IX-es for that matter). * 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 > 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
- 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 ]