Re: [address-policy-wg] IXP pool lower boundary of assignments
Hello, I feel that /26 is the smallest reasonable subnet size for an IXP, no matter how small the IXP is initially. If it starts growing, it will quickly grow past /27, but might just stay inside the /26. This is based on empirical experience over the decades. I do agree that it would be nice if the vendors took RFC 5549 seriously. A lot of IXPs would be ready to adopt it, if it was an option. It will create some headaches for route server scalability, but perhaps bird3 will fix those... anyway I digress... My two cents, PS. I don't think Tore appreciates how much more difficult it is to renumber an IXP compared to a data centre or an access provider. -- Aleksi Suhonen / TREX () ascii ribbon campaign /\ support plain text e-mail
* Aleksi Suhonen
I feel that /26 is the smallest reasonable subnet size for an IXP, no matter how small the IXP is initially. If it starts growing, it will quickly grow past /27, but might just stay inside the /26. This is based on empirical experience over the decades.
Could you please share the actual data on which your «empirical experience» is founded with the list? Reason I am asking is that the only actual data that has been shared with the list so far is https://github.com/mwichtlh/address-policy-wg/, which appears to disagree with you. Looking at Figure 2 here, it would appear that «~55% of all IXPs would fit into a /27 including 100% overprovisioning». In other words, a majority of all IX-es would fit into a subnet smaller than your claimed «smallest reasonable size» while having ample elbow room – enough to at least double their current member count.
PS. I don't think Tore appreciates how much more difficult it is to renumber an IXP compared to a data centre or an access provider.
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). Most members opted to have both addresses simultaneously active during the migration period to facilitate hitless migration of traffic to the new addresses without needing to coordinate with each individual peer. 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». Tore
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
Le Mon, Nov 07, 2022 at 04:56:14PM +0100, Radu-Adrian FEURDEAN a écrit :
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 ...
Thank you very much for your message Radu-Adrian, I was about to send something along the same line :) -- Denis Fondras / Liopen / AuvernIX Mob: +33.761.029.186
* 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
participants (4)
-
Aleksi Suhonen
-
Denis Fondras - Liopen
-
Radu-Adrian FEURDEAN
-
Tore Anderson