<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hello, Tore!<br>
      Thank you for quick feedback.<br>
      After the example you gave - I understood the purpose of the
      introduction for IPv4.<br>
      <blockquote type="cite">I do not quite understand this use case. I
        believe it is not common to split an ASSIGNED PA object into
        more specific ASSIGNED PA objects. To be honest, I didn't even
        know that was possible. Anyway…
        <br>
      </blockquote>
      So sorry.<br>
      My mistake. <br>
      <blockquote type="cite">ASSIGNED PA object (for example /20)</blockquote>
      I had in mind <b>ALLOCATED</b> <b>PA</b> <b>/20</b>, which
      divided to much /<b>24</b>, which is<b> ASSIGNED PA </b>already.<b><br>
      </b>Thank you!<b><br>
        <br>
      </b></p>
    <div class="moz-cite-prefix">On 4/16/24 13:55, Tore Anderson wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:9750a4c6-4813-4136-b6fb-11af6a44df5f@fud.no">Hi there,
      <br>
      <br>
      * APEX NCC ORG
      <br>
      <blockquote type="cite">
        <br>
        Can you provide an example of using and registering an
        AGGREGATED-BY-LIR object for IPV4?
        <br>
        Who is this for and when?
        <br>
        <br>
      </blockquote>
      It has exactly the same use case as AGGREGATED-BY-LIR for IPv6. It
      is primarily intended for LIRs which need to make a large number
      of essentially identical assignments, which can then be aggregated
      into a single database object rather than registering a bunch of
      redundant objects.
      <br>
      <br>
      Here's an example, which represent 256 essential identical
      ASSIGNED PA objects:
      <br>
      <br>
      inetnum: 192.0.2.0 - 192.0.2.255
      <br>
      netname: CLOUDPROVIDER-CUSTOMER-VMS
      <br>
      descr: IP addresses dynamically assigned to virtual machines
      running in CloudProvider's public cloud infrastructure # this is
      optional
      <br>
      assignment-size: 32 # this is optional
      <br>
      country: NO
      <br>
      admin-c: CLOUDPROVIDER-RIPE
      <br>
      tech-c: CLOUDPROVIDER-RIPE
      <br>
      status: AGGREGATED-BY-LIR
      <br>
      mnt-by: CLOUDPROVIDER-MNT
      <br>
      source: RIPE
      <br>
      <br>
      <br>
      <blockquote type="cite">Is its use mandatory?
        <br>
        <br>
      </blockquote>
      Not at all, feel free to ignore it and continue doing whatever
      you've been doing so far.
      <br>
      <br>
      <br>
      <blockquote type="cite">Initially, the assignment policy was
        discussed as an assignment for cloud providers.
        <br>
        What should a provider do, for example, if it has a status
        ASSIGNED PA object (for example /20),
        <br>
        splits it into /24 objects also like ASSIGNED PA with additional
        routes obj. for its end clients (without NAT / with NAT)?
        <br>
        <br>
      </blockquote>
      I do not quite understand this use case. I believe it is not
      common to split an ASSIGNED PA object into more specific ASSIGNED
      PA objects. To be honest, I didn't even know that was possible.
      Anyway…
      <br>
      <br>
      <br>
      <blockquote type="cite">Is it here an AGGREGATED-BY-LIR  status
        objects? Or NOT?
        <br>
        <br>
      </blockquote>
      …as I understand it, in your example, the 16 /24 ASSIGNED PA
      objects have unique mnt-routes: values. If so, that means you
      cannot aggregate the 16 /24s into a single AGGREGATED-BY-LIR
      object.
      <br>
      <br>
      Tore
      <br>
    </blockquote>
    <pre class="moz-signature" cols="72">-- 
Best wishes,
APEX NCC ORG
--------------------------------
+38(056)-731-99-11,
+38(067)-731-99-11,
+38(050)-731-99-11,
<a class="moz-txt-link-abbreviated" href="http://www.trifle.net">www.trifle.net</a></pre>
  </body>
</html>