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

Hi Marcus,

> 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.

Thank you for pointing that out, Marcus. You are totally correct, the analysis does not tell you anything about how fast IXPs grow. Another limitation I would like to add: the data source is peeringDB and there is an unknown amount of ASes that do not add an entry to peeringDB if they join an IXP. Thus I would refrain from defining an extremely tight-knit policy based on this analysis.

I don't get the point of the /29 discussion anyways. It is based on the false assumption that we need to stretch the pool to eternity and beyond. We need to stretch the pool until we can test and establish IPv4 over IPv6 peering LANs. A /26 default is perfectly fine for that.

Regards,
Matthias

--
Dr.-Ing. Matthias Wichtlhuber
Senior Researcher
------------------------------
DE-CIX Management GmbH
Lindleystr. 12, 60314 Frankfurt (Germany)
phone: +49 69 1730902 141
mobile: +49 171 3836036
fax: +49 69 4056 2716
e-mail: matthias.wichtlhuber at de-cix.net
web: www.de-cix.net
------------------------------
DE-CIX Management GmbH
Executive Directors: Ivaylo Ivanov and Sebastian Seifert
Trade registry: District court (Amtsgericht) Cologne, HRB 51135
Registered office: Lichtstr. 43i, 50825 Cologne
------------------------------
DE-CIX 25th anniversary: Without you the Internet would not be the same!
Join us on the journey at https://withoutyou.de-cix.net


________________________________________
Von: address-policy-wg <address-policy-wg-bounces at ripe.net> im Auftrag von Marcus Stoegbauer <marcus at grmpf.org>
Gesendet: Montag, 7. November 2022 23:48:42
An: address-policy-wg at ripe.net
Betreff: Re: [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