<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html;
      charset=windows-1252">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Hello Gert and colleagues,<br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 09/08/2019 21:43, Gert Doering
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:20190809194336.GN55186@Space.Net">
      <blockquote type="cite" style="color: #000000;">
        <pre wrap="">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.
</pre>
      </blockquote>
      <pre wrap="">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)</pre>
    </blockquote>
    Yes, this is an implementation thing. While the IPv4 Policy requires
    <br>
    that we set aside a /16 for unforseen circumstances, it doesn't
    specify <br>
    the range or that it must be a contiguous block.<br>
    <br>
    At RIPE 77, Andrea Cima suggested that this (currently contiguous)
    /16 <br>
    could be replaced with an equivalent of /23s and /24s as we near
    IPv4 <br>
    runout:<br>
<a class="moz-txt-link-freetext" href="https://ripe77.ripe.net/wp-content/uploads/presentations/71-Andrea_Cima_RIPE_77_APWG.pdf">https://ripe77.ripe.net/wp-content/uploads/presentations/71-Andrea_Cima_RIPE_77_APWG.pdf</a><br>
    <br>
    There was general support for the idea, though some questioned the <br>
    intent of doing this to create more convenient /22 allocations. Now
    with <br>
    this proposal, we plan to replace the currently-reserved
    185.0.0.0/16 <br>
    and use this for the IXP pool if this proposal reaches consensus. So
    <br>
    Tore's suggestion would be achieved.<br>
    <br>
    It should be noted that for this to happen, there must be at least a
    /16 <br>
    of regular space in our remaining pool when rough consensus is
    reached, <br>
    to allow us to make the swap. The IPv4 Policy is clear that this <br>
    reserved space must be used for IPv4 allocations as per section 5.1.<br>
    <br>
    Kind regards,<br>
    <br>
    Marco Schmidt<br>
    Policy Officer<br>
    RIPE NCC<br>
  </body>
</html>