Hi, On Mon, Nov 7, 2022, at 13:00, Tore Anderson wrote:

Actually, I do have some real-life experience here as I/AS39029 was part of the NIX renumbering process back in 2017. The whole operation was rather straight-forward and went very smoothly. NIX staff simply informed all members of their new IPs by e-mail and told to migrate within a certain date (different dates for NIX1 and NIX2).

Well, this seems to be the customer-side experience, not the IXP-side. Also, what I can see is that responsiveness of NOCs and peering teams of members is only getting worse with time. At France-IX, just changing a netmask (from /23 to /22) - because we have the biggest 3 out of 5 IXPs numbered from PA space - took just under 2 years to complete (23 months to be precise). More than 80% did the change in less than 3 months, but after 12 months we still had a few members that didn't change their config. OK, things end up in a slightly more violent manner with renumbering, but you sill end up with "zombie members", not all of them being small players. /29 is way too small. It's 6 members, and that supposes that you don't have route-servers or any other internal stuff on the peering LAN. Getting from /29 to /25 that's 4 renumberings, and that may well happen within 2 years. You end up being labelled as "unstable" (read "junk" or "toy" IXP). 3 renumberings to get to /26.

NIX is (and was) a mid-sized IX, currently around 60 participants. Based on that experience I have honestly a very hard time believing that renumbering a small IX is «much more difficult [than renumbering a] data centre or an access provider».

Convincing different distinct parties to do something within a specific timeframe is always difficult. Especially when you have to deal with big companies. Pushing things too hard will only get you losing members..... I do agree that /26 is a decent minimum, and /27 is the strictest acceptable minimum (if there really isn't anything bigger left). ... or getting rid of v4 entirely, which seems to be on nobody's agenda ... -- Radu-Adrian FEURDEAN

* Radu-Adrian FEURDEAN

On Mon, Nov 7, 2022, at 13:00, Tore Anderson wrote:

...

Actually, I do have some real-life experience here as I/AS39029 was part of the NIX renumbering process back in 2017. The whole operation was rather straight-forward and went very smoothly. NIX staff simply informed all members of their new IPs by e-mail and told to migrate within a certain date (different dates for NIX1 and NIX2).

Well, this seems to be the customer-side experience, not the IXP- side. Also, what I can see is that responsiveness of NOCs and peering teams of members is only getting worse with time. At France-IX, just changing a netmask (from /23 to /22) - because we have the biggest 3 out of 5 IXPs numbered from PA space - took just under 2 years to complete (23 months to be precise). More than 80% did the change in less than 3 months, but after 12 months we still had a few members that didn't change their config. OK, things end up in a slightly more violent manner with renumbering, but you sill end up with "zombie members", not all of them being small players.

First off, note current policy already requires renumbering if your IXP grows out of a /23 and into a /22. Second, current policy already contains a hard deadline of 180 days of complete this renumbering process and return the old prefix. Of course, neither the IX nor the RIPE NCC has the power to log into the router of a «zombie member» and forcibly remove the old IP address from the «zombie»'s router. But one cannot (well, should not!) allow unresponsive «zombie» members to block the completion of the project. So in the case of NIX, a deadline was clearly communicated ahead of time and that was the end of the story. Perhaps there were «zombies» that did not act within the deadline back then too, I can't recall, but if so they just got left behind at the platform (peering only amongst themselves using old addresses) while the train with all the «non- zombies» left the station. Such is life. (Hopefully a majority of their peering sessions dropping brought them back to life, but who knows.)

/29 is way too small. It's 6 members, and that supposes that you don't have route-servers or any other internal stuff on the peering LAN. Getting from /29 to /25 that's 4 renumberings, and that may well happen within 2 years. You end up being labelled as "unstable" (read "junk" or "toy" IXP). 3 renumberings to get to /26.

There would not be a requirement for four renumberings within two years, no. Policy states that: «After one year, utilisation of the new assignment must be at least 50%». In other words, a growing IX would need to renumber exactly ONCE within the first two years. So your example IX above would be eligible to receive an initial /26, and would be eligible to receive a /25 replacement one year prior to its expected utilisation reaching 64 addresses. It would make zero difference whatsoever to your example whether the default assignment size was set at /29 or /26 or anywhere in between.

...

NIX is (and was) a mid-sized IX, currently around 60 participants. Based on that experience I have honestly a very hard time believing that renumbering a small IX is «much more difficult [than renumbering a] data centre or an access provider».

Convincing different distinct parties to do something within a specific timeframe is always difficult. Especially when you have to deal with big companies. Pushing things too hard will only get you losing members.....

Well, the RIPE community has clearly laid down a renumbering deadline of 180 days as a condition for getting free prefixes from the IXP pool, this is already in the policy. If the operator of a new IX finds that adhering to this policy is «pushing things too hard», then perhaps it would be better if it got itself a vastly oversized prefix from somewhere else instead of from the RIPE NCC. That way, it can forever avoid having to renumber.

... or getting rid of v4 entirely, which seems to be on nobody's agenda ...

Agreed. For what it is worth, we have for years advertised IPv4 prefixes across IPv6 BGP sessions in our internal networks. It works very well for us, so I see no real reason why it couldn't work on IXPs as well – assuming universal vendor support. I suppose that is the problem… Tore