[arin-ppml] Statistics regarding NRPM 8.3 Transfers to date
farmer at umn.edu
Fri Apr 29 19:08:06 EDT 2011
On 4/29/11 15:55 CDT, John Curran wrote:
> On Apr 29, 2011, at 4:40 PM, Scott Leibrand wrote:
>> Org A transfers part of their allocation/assignment to Org B.
> Note that space in a transfer could easily be only part of an
> original allocation, and still be the smallest block possible
> to transfer... i.e. I'm not certain how this metric is useful,
> but will endeavor to research and deliver this information.
>> Org C receives multiple CIDR blocks (or continuous address
>> ranges) from whatever source(s).
> The 10 recipient organizations received a total of 18 contiguous
> IPv4 address blocks; several of those recipients received blocks
> which were composed of adjacent /24's.
I assume from that that answer to the following would be, no then.
- If the original allocations were aggregate-able, would you aggregate
them in the database as part of the transfer, or transfer the original
Specific hypothetical situations;
- If the original allocations were made as two adjacent /16s and on the
necessary bit boundary, would you transfer two 16s or one /15 in the
- If the original allocations were a large contiguous range of /24s,
would you transfer them as N /24 blocks, or would make any partial
aggregations that you could in the database? (I think resulting in at
most Floor((N/2)+1) blocks )
I'll grant you there was nothing in the policy that required or even
suggested aggregation of the original blocks. However, there is noting
in my interpretation of the policy that would prevent it either. Would
you agree? Is there an operational downside to aggregating the blocks
in the database, when possible, as part of the transfer that I'm not seeing?
David Farmer Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 612-626-0815
Minneapolis, MN 55414-3029 Cell: 612-812-9952
More information about the ARIN-PPML