[address-policy-wg] IXP pool lower boundary of assignments

On 5 Nov 2022, at 9:14, Tore Anderson wrote:

> * David Farmer
>
>> You seem to want to optimize for the smallest of the small IXPs, tiny
>> IXPs as you put it. How about we optimize for just plain small IXPs?
>
> No, what I want is to optimise equally for all sizes of IX-es. It is
> the current optimisation of (read: overassignment to) small IX-es I
> would like to see ended.
>
> In other words: an IX with X members should get the smallest /Y prefix
> that can fit X. That should go equally for any value of X. That is:
>
> …if X=4, then Y=29.
> …if X=40, then Y=26.
> …if X=400, then Y=23.
>
> …and so forth. If any IX wants to double in size, it would need to
> renumber exactly once.
>
> This would constitute totally fair and equal treatment for all IX-es
> regardless of size, the way I see it – and it would be the the exact
> opposite of «optimising for the smallest of the small IXPs».

In the case of IXPs I consider larger assignments up to a certain point as a technical necessity rather than a situation we need to rectify. Handing out /29s to a new IXP IMO puts a large burden on newly founded IXPs (since they would need to renumber earlier) which gives them an unfair disadvantage. This I consider a larger problem than eventually running out of addresses in the pool altogether.

My counter argument is twofold:

One, it's easier for an IXP to grow from 4 to 8 members than it is to grow from 40 to 80 members, so the likelihood that a very small IXP would need to renumber is larger than for already established IXPs with larger address space.

Two, the numbers Matthias supplied are great and we can definitely get some information for this discussion from them. However, they are a snapshot in time. For the argument you are making we would need this data over time, and the question to ask would be "How long does an IXP which fits in a /29 stays in this category?". We cannot get this information from the data, so we shouldn't base assumptions and policy on this.

   Marcus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 858 bytes
Desc: OpenPGP digital signature
URL: </ripe/mail/archives/address-policy-wg/attachments/20221107/b9c17214/attachment.sig>