2019-07 New Policy Proposal (Default assignment size for IXPs)
Dear colleagues, A new RIPE Policy proposal, 2019-07, "Default assignment size for IXPs" is now available for discussion. This proposal aims to change the default IXP assignment size from a /24 to a needs-based model, with a /27 as a minimum. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-07 As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal. We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 13 November 2019. Regards, Marco Schmidt Policy Officer RIPE NCC
On Tue, 15 Oct 2019, 13:43 Marco Schmidt, <mschmidt@ripe.net> wrote:
Dear colleagues,
This proposal aims to change the default IXP assignment size from a /24 to a needs-based model, with a /27 as a minimum. L
Whilst I support the goal of the proposal the current wording doesn't parse particularly well. By changing 'once' to 'if' and then referencing returned addresses it (possibly) creates a confusion. I would go with... New IXPs will be assigned a /27 as a minimum. If an IXP requires a larger assignment, they must demonstrate need for at least 50% of the new assignment within two years. A maximum assignment of a /22 is available for a suitablly qualified IXP. Any existing addresses (such as PI) used for an IXP peering LAN shall be returned. Feel free to butcher the text further, but I hope I've explained the reason for the change in the change itself Thx
* Marco Schmidt
A new RIPE Policy proposal, 2019-07, "Default assignment size for IXPs" is now available for discussion.
This proposal aims to change the default IXP assignment size from a /24 to a needs-based model, with a /27 as a minimum.
While I do support the proposal's aim of reducing the default assignment size, I would suggest that we make the default a /29 instead of a /27: - The reserved IXP pool currently contains prefixes sized /29 and /28. These can not be delegated under neither the current nor the proposed policy. However, small IXPs could make use of these just fine. I see why reason why we should «lock them up and throw away the key». - Looking at figure 2 at https://github.com/mwichtlh/address-policy-wg/ it would appear that ~43% of all IXPs would fit into a /28 including 100% overprovisioning (or into a /29 with no overprovisioning). This suggests that /29s and /28s would be useful and sufficient to a significant number of IXPs. - Lowering the default assignment size to a /29 does obviously not mean that IXPs that do require a /27 or larger should not receive it. They simply have to justify it, exactly the same as an IXP requesting a /{26..22} would have to under the proposed policy. This is not a unreasonable thing to ask, in my opinion - IPv4 is a very scarce resource, after all. - This might require growing IXPs to renumber from /29->/28->/27, which they would not have to do under the currently proposed policy. However, I do not think that is an unreasonable thing to ask. The smaller the IXP is, the easier it is to coordinate a renumbering process. Renumbering is in any case a process they will to go through as they grow out of the /27 currently proposed as the new default assignment size. Tore
Marco Schmidt wrote on 15/10/2019 13:43:
This proposal aims to change the default IXP assignment size from a /24 to a needs-based model, with a /27 as a minimum.
This proposal doesn't seem well-thought-out. The first, and main, issue is that renumbering IXPs is a terrible headache and is something that should be avoided if possible. The sorts of problems that regularly erupt would include: - loss of service during renumbering, with traffic being forced over backup paths at times that may not suit - ixp participants being forced to undergo network changes outside their normal maintenance window procedures (some networks cannot do this). - problems with IXP prefix misorigination due to filters not being updated properly, which can cause loss of service problems. - other larger-scale configuration issues due to people making substantial config changes to their peering routers, which usually takes some time to iron out the bugs. I.e. this is not as simple as a global search + replace. INEX was a good internet citizen and started out with a /27 on our main peering LAN in 1996. When that ran out, we moved to a /26 and then a /25. We're now at /23. For each renumbering operation, we ran into the problems above, and a lot more. So from multiple experience, I wouldn't wish it on anyone to have to go through an IXP renumbering without good reason. It really is a thorough pain, especially for the IXP participants. The second issue is that there are ~220 IXPs operating in the countries in the ripe ncc region. This number is pulled from IXPDB (https://api.ixpdb.net/v1/provider/list), and cross-referenced against the list of RIPE NCC countries here: https://www.ripe.net/participate/member-support/list-of-members/list-of-coun... A /15 has enough space for 512x/24 blocks, which means that this block will probably last indefinitely if the minimum assignment size is /24. By reducing this to /27, all that's going to happen is that IXPs and their participants will be dragged through unnecessary renumbering procedures; but it is unlikely to make the block last longer. I'd like to respectfully suggest that the proposal be dropped. Nick
Hello, On 22/10/19 18:24, Nick Hilliard wrote:
INEX was a good internet citizen and started out with a /27 on our main peering LAN in 1996. When that ran out, we moved to a /26 and then a /25. We're now at /23. For each renumbering operation, we ran into the problems above, and a lot more. So from multiple experience, I wouldn't wish it on anyone to have to go through an IXP renumbering without good reason. It really is a thorough pain, especially for the IXP participants.
Having gone through a renumbering exercise for an IXP myself (/22 to /21) I can confirm that this is a painful process. But it is certainly not an insurmountable challenge. Also, the smaller the IXP, the easier it is. Fewer participants means less coordination. The proposal already accommodates two years worth of growth, so it is not like a renumbering exercise would be needed very often.
The second issue is that there are ~220 IXPs operating in the countries in the ripe ncc region. This number is pulled from IXPDB (https://api.ixpdb.net/v1/provider/list), and cross-referenced against the list of RIPE NCC countries here:
https://www.ripe.net/participate/member-support/list-of-members/list-of-coun...
A /15 has enough space for 512x/24 blocks, which means that this block will probably last indefinitely if the minimum assignment size is /24.
Possibly. But there is no guarantee that the growth in the number of IXPs will remain the same. So being a bit conservative when there is little downside seems wise to me. I agree with James that the wording could be made a bit clearer. Furthermore I think it should at least be possible to assign a /28 or a /29 if an IXP requests this or if there are no larger blocks available. But I don't think there's anything wrong with the /27 default, so I support the proposed change in general. Kind regards, Martin
* Martin Pels
On 22/10/19 18:24, Nick Hilliard wrote:
INEX was a good internet citizen and started out with a /27 on our main peering LAN in 1996. When that ran out, we moved to a /26 and then a /25. We're now at /23. For each renumbering operation, we ran into the problems above, and a lot more. So from multiple experience, I wouldn't wish it on anyone to have to go through an IXP renumbering without good reason. It really is a thorough pain, especially for the IXP participants.
Having gone through a renumbering exercise for an IXP myself (/22 to /21) I can confirm that this is a painful process. But it is certainly not an insurmountable challenge.Also, the smaller the IXP, the easier it is. Fewer participants means less coordination.
Precisely. Renumbering is annoying for everyone, but it is an necessary inconvenience in order to deal with IPv4 being in short supply. This is not an IXP specific consideration - I renumber server LANs with public IPv4 regularly, for example. It is definitively not fun, but it necessary to preserve my LIR's IPv4 pool. Besides, by renumbering while the IXP is still small, valuable experience is gained. In the case described by Nick, if INEX had started out with a /24 (per current policy), a renumbering operation would still have had to happen to go to the current /23. In other words, the largest and most difficult renumbering exercise would have had to be performed with zero prior experience. I am not convinced that would be a better situation to find oneself in than having previously renumbered every five years or so (on average).
The proposal already accommodates two years worth of growth, so it is not like a renumbering exercise would be needed very often.
Indeed, although it is actually *four* years, not two (assuming linear growth).
A /15 has enough space for 512x/24 blocks, which means that this block will probably last indefinitely if the minimum assignment size is /24.
Possibly. But there is no guarantee that the growth in the number of IXPs will remain the same. So being a bit conservative when there is little downside seems wise to me.
Personally I take any claim that that an IPv4 resource will last indefinitely with a healthy dose of scepticism. It took the IXP community eight years to go from «a /16 will do» (2011-05) to «um, on second thought, make that a /15» (2019-05). There will be no third serving, so I agree fully that we should be conservative.
I agree with James that the wording could be made a bit clearer. Furthermore I think it should at least be possible to assign a /28 or a /29 if an IXP requests this or if there are no larger blocks available. But I don't think there's anything wrong with the /27 default, so I support the proposed change in general.
Agreed on /29 - the IXP pool does contain /28 and /29 prefixes, so it is glaringly inconsistent that current policy disallows their assignment. However, once you accept that the minimum should be /29, then setting the default to /27 seems rather arbitrary. There's nothing special about /27 that makes it an obvious default value. I believe the logical thing to do is to put the default at the /29 as well. Having the default equal to the minimum is the most conservative and thus the best suited for making the IXP pool last "forever". Of course, that does not mean that an IXP will not get a larger assignment if it needs it. To qualify for an initial /27, for example, the IXP would only need to have 14 connections total (members, RSes, etc.) within two years of assignment. This is sufficiently accommodating for new IXPs, in my opinion. Tore
I believe the logical thing to do is to put the default at the /29 as well. Having the default equal to the minimum is the most conservative and
Hi, Do we know how many /29 we have available in the IXP reserved pool? if there are only few ones, it doesn't make scene to me set the default to /29 as it would be a good practice for just few allocations. Can someone from RIPE NCC provide us with an statistic on number of different prefixes in the IXP pool? Regards, Arash thus the best suited for making the IXP pool last "forever".
* Arash Naderpour
Do we know how many /29 we have available in the IXP reserved pool? if there are only few ones, it doesn't make scene to me set the default to /29 as it would be a good practice for just few allocations.
Can someone from RIPE NCC provide us with an statistic on number of different prefixes in the IXP pool?
Hi Arash, While I'm not from the NCC, below is the complete list of blocks smaller than /24 currently found in the IXP pool (or could be in quarantine, but destined for the IXP pool nevertheless). I spot at least four /29s in it (193.58.0.48/29, 193.188.134.136/29, 193.188.134.200/29, 194.180.226.144/29). An additional 13 /29s are currently assigned; if returned, these will also be added to the IXP pool under current policy. Tore $ curl -s ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-extended-latest | awk '-F|' '$3 == "ipv4" && $5 < 256 && $7 == "reserved"' ripencc||ipv4|193.34.193.128|128||reserved ripencc||ipv4|193.34.196.128|128||reserved ripencc||ipv4|193.34.199.128|128||reserved ripencc||ipv4|193.34.201.128|128||reserved ripencc||ipv4|193.58.0.48|8||reserved ripencc||ipv4|193.164.232.96|64||reserved ripencc||ipv4|193.164.232.224|32||reserved ripencc||ipv4|193.188.134.136|8||reserved ripencc||ipv4|193.188.134.200|56||reserved ripencc||ipv4|193.192.12.0|128||reserved ripencc||ipv4|193.201.145.128|128||reserved ripencc||ipv4|193.201.147.192|32||reserved ripencc||ipv4|193.201.148.128|64||reserved ripencc||ipv4|193.201.149.0|64||reserved ripencc||ipv4|193.201.149.128|64||reserved ripencc||ipv4|193.201.150.192|64||reserved ripencc||ipv4|193.201.151.64|128||reserved ripencc||ipv4|193.201.155.0|128||reserved ripencc||ipv4|193.201.157.128|128||reserved ripencc||ipv4|193.201.159.0|128||reserved ripencc||ipv4|193.218.207.64|16||reserved ripencc||ipv4|193.243.183.0|64||reserved ripencc||ipv4|193.243.183.128|64||reserved ripencc||ipv4|194.42.47.0|128||reserved ripencc||ipv4|194.93.123.0|128||reserved ripencc||ipv4|194.117.50.0|128||reserved ripencc||ipv4|194.117.55.0|128||reserved ripencc||ipv4|194.153.153.0|128||reserved ripencc||ipv4|194.153.157.0|128||reserved ripencc||ipv4|194.153.158.0|128||reserved ripencc||ipv4|194.153.159.128|128||reserved ripencc||ipv4|194.180.159.0|240||reserved ripencc||ipv4|194.180.226.0|152||reserved ripencc||ipv4|194.180.226.160|96||reserved ripencc||ipv4|194.246.39.0|96||reserved ripencc||ipv4|194.246.39.192|32||reserved ripencc||ipv4|195.13.37.128|128||reserved ripencc||ipv4|195.35.104.0|32||reserved ripencc||ipv4|195.60.80.0|96||reserved ripencc||ipv4|195.60.81.128|64||reserved ripencc||ipv4|195.60.83.32|32||reserved ripencc||ipv4|195.60.83.128|32||reserved ripencc||ipv4|195.60.84.128|128||reserved ripencc||ipv4|195.60.85.128|128||reserved ripencc||ipv4|195.60.88.0|128||reserved ripencc||ipv4|195.60.91.128|128||reserved ripencc||ipv4|195.60.92.192|64||reserved ripencc||ipv4|195.60.93.64|64||reserved ripencc||ipv4|195.60.94.128|128||reserved
Greetings, /27 as default seems a sensible approach. While exponential growth is something that most IXPs would like to see, the reality is that it doesn't happen everywhere. Thus, I support 2019-07. Regards, Carlos On Fri, 25 Oct 2019, Tore Anderson wrote:
* Martin Pels
On 22/10/19 18:24, Nick Hilliard wrote:
INEX was a good internet citizen and started out with a /27 on our main peering LAN in 1996. When that ran out, we moved to a /26 and then a /25. We're now at /23. For each renumbering operation, we ran into the problems above, and a lot more. So from multiple experience, I wouldn't wish it on anyone to have to go through an IXP renumbering without good reason. It really is a thorough pain, especially for the IXP participants.
Having gone through a renumbering exercise for an IXP myself (/22 to /21) I can confirm that this is a painful process. But it is certainly not an insurmountable challenge.Also, the smaller the IXP, the easier it is. Fewer participants means less coordination.
Precisely.
Renumbering is annoying for everyone, but it is an necessary inconvenience in order to deal with IPv4 being in short supply. This is not an IXP specific consideration - I renumber server LANs with public IPv4 regularly, for example. It is definitively not fun, but it necessary to preserve my LIR's IPv4 pool.
Besides, by renumbering while the IXP is still small, valuable experience is gained.
In the case described by Nick, if INEX had started out with a /24 (per current policy), a renumbering operation would still have had to happen to go to the current /23. In other words, the largest and most difficult renumbering exercise would have had to be performed with zero prior experience.
I am not convinced that would be a better situation to find oneself in than having previously renumbered every five years or so (on average).
The proposal already accommodates two years worth of growth, so it is not like a renumbering exercise would be needed very often.
Indeed, although it is actually *four* years, not two (assuming linear growth).
A /15 has enough space for 512x/24 blocks, which means that this block will probably last indefinitely if the minimum assignment size is /24.
Possibly. But there is no guarantee that the growth in the number of IXPs will remain the same. So being a bit conservative when there is little downside seems wise to me.
Personally I take any claim that that an IPv4 resource will last indefinitely with a healthy dose of scepticism.
It took the IXP community eight years to go from «a /16 will do» (2011-05) to «um, on second thought, make that a /15» (2019-05).
There will be no third serving, so I agree fully that we should be conservative.
I agree with James that the wording could be made a bit clearer. Furthermore I think it should at least be possible to assign a /28 or a /29 if an IXP requests this or if there are no larger blocks available. But I don't think there's anything wrong with the /27 default, so I support the proposed change in general.
Agreed on /29 - the IXP pool does contain /28 and /29 prefixes, so it is glaringly inconsistent that current policy disallows their assignment.
However, once you accept that the minimum should be /29, then setting the default to /27 seems rather arbitrary. There's nothing special about /27 that makes it an obvious default value.
I believe the logical thing to do is to put the default at the /29 as well. Having the default equal to the minimum is the most conservative and thus the best suited for making the IXP pool last "forever".
Of course, that does not mean that an IXP will not get a larger assignment if it needs it. To qualify for an initial /27, for example, the IXP would only need to have 14 connections total (members, RSes, etc.) within two years of assignment. This is sufficiently accommodating for new IXPs, in my opinion.
Tore
Dear colleagues, On 22/10/2019, 17:24, Nick Hilliard <nick@foobar.org> wrote:
Marco Schmidt wrote on 15/10/2019 13:43:
This proposal aims to change the default IXP assignment size from a /24 to a needs-based model, with a /27 as a minimum. This proposal doesn't seem well-thought-out. [...]
I strongly oppose the 2019-07 policy proposal for the reasons expressed by Nick Hilliard. I think an IXP operator should be able to request a longer prefix than a /24 in the IXP Assignment policy but the default assignment size should not change from a /24. IXPs need to operate on the principle of least surprise, especially as the experience and the expertise of networks connecting continues to expand beyond the traditional boundaries. Best wishes, Andy Davidson
Hello, On Tue, Oct 15, 2019, at 14:43, Marco Schmidt wrote:
Dear colleagues,
A new RIPE Policy proposal, 2019-07, "Default assignment size for IXPs" is now available for discussion.
A little late, but here's my point of view: - /27 is borderline for a default. Hopefully the 50% use within 2 years should alleviate this (even if I find it not enough). - Anything smaller than a /27 is close to useless. - Renumbering is painful and should be avoided as much as possible. - IXP growth may be very variable in time. You may struggle for 1-2 years, then add several dozens members the next year. You may easy get in a situation when renumbering falls in a period of rapid growth, which only makes things worse. The peering landscape has changed quite a lot during the last years. You have to deal with NOCs that function purely "by the book", usually a book not well written. You have to deal with lack of coordination between operations and strategy. You have to deal more and more with "the peering coordinator changed, there is no more peering policy". You have to deal with "there might be a slight impact, we need a change request approved, it will take 3 months at least". This noes not touch only the small participants, this does touch *EVERYONE*. At the end, you end up with x% (where x>10, even x>20) of your user base does not respond in a timely manner (if at all). Because of this you will end up looking as "not serious" (sometimes by the same people that took 3 months to do the renumbering). My suggestion : - if the default assignment size is to be lowered, that should be a /25 or a /26, not smaller. - The "target use" (currently "50% within 2 years"), should be a little more relaxed (either 3 years, or something like 35%-40% use within 2 years). I wouldn't mind reserving space for future enlargement (with reservations being re-allocated or reduced when space is needed by other members), but I think wording for that would render the policy way too complex. -- Radu-Adrian FEURDEAN
On Nov 13, 2019, at 5:43 AM, Radu-Adrian FEURDEAN <ripe-wgs@radu-adrian.feurdean.net> wrote:
Hello,
On Tue, Oct 15, 2019, at 14:43, Marco Schmidt wrote: Dear colleagues,
A new RIPE Policy proposal, 2019-07, "Default assignment size for IXPs" is now available for discussion.
My suggestion : - if the default assignment size is to be lowered, that should be a /25 or a /26, not smaller. - The "target use" (currently "50% within 2 years"), should be a little more relaxed (either 3 years, or something like 35%-40% use within 2 years).
I wouldn't mind reserving space for future enlargement (with reservations being re-allocated or reduced when space is needed by other members), but I think wording for that would render the policy way too complex.
Isn’t that as simple as “use sparse allocation”? As long as less than half of the remaining IXP pool has been used up, everyone can be given an allocation within a larger block with the ability to grow at least 2x. -Scott
On Wed, Nov 13, 2019, at 15:04, Scott Leibrand wrote:
Isn’t that as simple as “use sparse allocation”? As long as less than half of the remaining IXP pool has been used up, everyone can be given an allocation within a larger block with the ability to grow at least 2x.
If "sparse allocation" is the magic word, it's OK for me. -- Radu-Adrian FEURDEAN
On Wed, Nov 13, 2019 at 11:54 AM Radu-Adrian FEURDEAN < ripe-wgs@radu-adrian.feurdean.net> wrote:
On Wed, Nov 13, 2019, at 15:04, Scott Leibrand wrote:
Isn’t that as simple as “use sparse allocation”? As long as less than half of the remaining IXP pool has been used up, everyone can be given an allocation within a larger block with the ability to grow at least 2x.
If "sparse allocation" is the magic word, it's OK for me.
I don't know, does that do what you want? :-) Sparse allocation would mean that each IXP assignment would be out of the block containing the greatest number of adjacent bits of unused space. That could be implemented either on an absolute basis (all allocations go into the biggest unused CIDR block available), or on a bit-shift basis. For a bit-shift sparse allocation strategy, if you have a free pool large enough to shift 4 bits, you'd assign /24s out of empty /20s, /27s out of empty /23s, etc. Then once you run out of blocks to accomplish that at 4-bit shift, you'd switch to 3 bits, and eventually down to 2 and then 1 bit before you have to give up on sparse allocation entirely. The disadvantage of sparse allocation is that it purposefully breaks up larger blocks, which may result in a lack of contiguous space for the largest IXPs sooner than would otherwise occur, in order to allow earlier IXPs to more easily grow their assignments. This is particularly acute with an absolutely sparse strategy, where the biggest blocks get broken up immediately, regardless of how tiny their allocations are. A bit-shift sparse allocation policy, or similarly a "reserved space" strategy, avoids that issue by limiting how much space is reserved for each IXP to grow into. -Scott
Radu-Adrian FEURDEAN wrote on 13/11/2019 13:41:
A little late, but here's my point of view: - /27 is borderline for a default. Hopefully the 50% use within 2 years should alleviate this (even if I find it not enough). - Anything smaller than a /27 is close to useless. - Renumbering is painful and should be avoided as much as possible. - IXP growth may be very variable in time. You may struggle for1-2 years, then add several dozens members the next year. You may easy get in a situation when renumbering falls in a period of rapid growth, which only makes things worse. The purpose of a policy should be to fix a specific problem.
As you're speaking in favour of the proposal, can you describe what problem you want to see fixed here? Nick
On Thu, Nov 14, 2019, at 14:56, Nick Hilliard wrote:
As you're speaking in favour of the proposal, can you describe what problem you want to see fixed here?
Problem : adapt the default assignment to the needs of most, in order to prolong pool's life, while allowing those that need to grow to do so while minimising re-numbering at maximum. To put it other way, I'm in favour of the idea, but not in favour of the current wording. -- Radu-Adrian FEURDEAN
Radu-Adrian FEURDEAN wrote on 14/11/2019 17:46:
On Thu, Nov 14, 2019, at 14:56, Nick Hilliard wrote:
As you're speaking in favour of the proposal, can you describe what problem you want to see fixed here?
Problem : adapt the default assignment to the needs of most, in order to prolong pool's life, while allowing those that need to grow to do so while minimising re-numbering at maximum.
It looks like the pool is probably large enough to last indefinitely under the current assignment policy. It's not clear what changing the assignment policy is going to fix. Nick
Hi, On Fri, Nov 15, 2019 at 12:22:08PM +0000, Nick Hilliard wrote:
Radu-Adrian FEURDEAN wrote on 14/11/2019 17:46:
On Thu, Nov 14, 2019, at 14:56, Nick Hilliard wrote:
As you're speaking in favour of the proposal, can you describe what problem you want to see fixed here?
Problem : adapt the default assignment to the needs of most, in order to prolong pool's life, while allowing those that need to grow to do so while minimising re-numbering at maximum.
It looks like the pool is probably large enough to last indefinitely under the current assignment policy. It's not clear what changing the assignment policy is going to fix.
Not wanting to stop a lively discussion, but technically we're behind the end of the discussion period and Remco is supposed to decide on "does the proposer want to proceed, rewrite, withdraw" now. Do we need more time? Or has any substantial argument been made, and everything else is just repetition now? Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Moin, am 15.11.19 um 13:22 schrieb Nick Hilliard:
It's not clear what changing the assignment policy is going to fix.
As far as I can see, it would give a use case for the fragmented space RIPE NCC holds, while saving on the final IXP-v4 addresses at the same time? Regards, -kai
participants (12)
-
Andy Davidson -
Arash Naderpour -
Carlos Friaças -
Gert Doering -
James Blessing -
Kai 'wusel' Siering -
Marco Schmidt -
Martin Pels -
Nick Hilliard -
Radu-Adrian FEURDEAN -
Scott Leibrand -
Tore Anderson