Hello Gert and colleagues,

On 09/08/2019 21:43, Gert Doering wrote:

As I understand the current proposal and the NCC's impact analysis, implementation of this proposal would necessarily mean that the resulting IXP pool would be at best two disjoint /16s, at worst one /16 plus a bunch of smaller fragments scattered all over the address space. That'd be a shame, in my opinion.

Mmmh.  Marco, can you comment on whether this is an implementation thing
at the NCC, or whether you'd need a formal statement in the policy text
to make this happen?

(While it's all just numbers, some numbers look more familiar than others,
so having all IXP space "in one block" is a bit easier on "oh, these 
numbers look IXPish" - so I can see that it would be nice)

Yes, this is an implementation thing. While the IPv4 Policy requires
that we set aside a /16 for unforseen circumstances, it doesn't specify
the range or that it must be a contiguous block.

At RIPE 77, Andrea Cima suggested that this (currently contiguous) /16
could be replaced with an equivalent of /23s and /24s as we near IPv4
runout:
https://ripe77.ripe.net/wp-content/uploads/presentations/71-Andrea_Cima_RIPE_77_APWG.pdf

There was general support for the idea, though some questioned the
intent of doing this to create more convenient /22 allocations. Now with
this proposal, we plan to replace the currently-reserved 185.0.0.0/16
and use this for the IXP pool if this proposal reaches consensus. So
Tore's suggestion would be achieved.

It should be noted that for this to happen, there must be at least a /16
of regular space in our remaining pool when rough consensus is reached,
to allow us to make the swap. The IPv4 Policy is clear that this
reserved space must be used for IPv4 allocations as per section 5.1.

Kind regards,

Marco Schmidt
Policy Officer
RIPE NCC