* Matthias Wichtlhuber > regarding 6.1(4) - (default is /26, /25 is handed out upon request): > > The idea behind this part of the proposal is that there are two kinds > of IXPs, one that is founded due to the need to interconnect a few > networks in a specific region and no intent of growth and one that is > operated with the explicit intent to grow and generate business. IXPs > can decide on their plans on their own and do an appropriate > selection of their initial assignment.
That places a big trust in the new IXPs to not ask for a /25 if they do not need it. To me, that seems naive - there are strong incentives for new IXPs to ask for as much as possible regardless of actual need. You point them out in the proposal yourself: avoid and/or postponing future renumbering and IPv4 purchases. A similar situation exist in IPv6. LIRs can freely choose initial allocations in the range /29../32. I bet the vast majority of new LIRs do not need anything larger than /32 (they definitively do not have to worry about renumbering or IPv6 purchases), yet in 2022 the numbers were: 1035 /29 allocations 3 /30 allocations 0 /31 allocations 64 /32 allocations So 94% chose the biggest they could get. That's human nature for you. Under the proposed policy I bet you will see the same thing happening, most IXPs will ask for /25s. (I sure would, if I was to start an IXP. There is simply no reason not to.) > regarding 6.1 (7) - (assignments down to /27): > > I agree that the policy can be gamed by asking for a /27 and jumping > to a /24; we might consider to restrict this part to only handing out > /27s once the IXP pool is depleted, but not upon request. I doubt > RIPE has handed out any /27 assignments upon request anyways; maybe > someone from RIPE can look into this? For what it is worth there are currently 32 /27 assignments in the delegated file (52 assignments /27 and smaller), but none of them are from the IXP pool. (They could still be used by IXPs though.) In fact, there are exactly 0 assignments smaller than /24 made from the IXP pool, even though the policy allows for this. This makes me even more convinced that IXPs will generally chose to take the largest prefix policy allows them to. > regarding the general point of lower bound of assignments and your > comment: > > > Alternatively we would need to consider the supporting data for > > this proposal bogus. > > As I have stated a couple of times in the previous discussions, the > data in PeeringDB can only provide a lower bound of connections per > IXP; nevertheless it remains the best dataset we currently have. Thus > the decision will have to be a mix of listening to experienced people > from the IXP community and the results of the analysis. I think a /26 > is a good compromise here. I was not trying to restart that part of the discussion. We can agree to disagree on whether or not /26 is a good value, and leave it at that. (It's better than /24, we can agree on that.) However, this comment was made in the context of my proposal of adding the «IPv4 space dust» to the IXP pool, for use when the pool runs out of /26s. The NCC inventory currently contains 47+ blocks in the range /29../25 that *would* have been perfectly usable for assignment to IXPs, but they can not be assigned to IXPs under this policy because they are not part of the specially designated /15 IXP pool. I say let's add them, so they actually can do some good, instead of rotting away in the NCC inventory. This «IPv4 space dust» also includes some prefixes smaller than /27, which would not be assignable under the proposed policy even if had added the «IPv4 space dust» to the IXP pool. However, there *are* small IXPs that could potentially have used these. There are multiple examples just here in Norway: Trondheim IX: 5 members Bergen IX: 6 members Tromsø IX: 3 members Stavanger IX: 8 members Source: https://www.nix.no/who-is-connected/ (bottom of page) All of them would make do with a /28, and three out of four would make do with a /29. I would further note that these are not newly started IXPs experiencing rapid growth, they are well established. In my opinion, denying a small IXP similar to these the opportunity to receive a small assignment – especially when such small prefixes are the only ones left in the NCC's inventory – just because some folks from DE-CIX do not «consider [it] to be an IXP» just seems cruel. I do not see any harm whatsoever in allowing their assignment. Tore -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/address-policy-wg
