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

* 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