[address-policy-wg] 2019-07 New Policy Proposal (Default assignment size for IXPs)

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
>