[arin-ppml] Statistics regarding NRPM 8.3 Transfers to date
owen at delong.com
Mon May 2 19:17:18 EDT 2011
On May 2, 2011, at 2:04 PM, Matthew Kaufman wrote:
> On May 2, 2011, at 1:32 PM, Owen DeLong wrote:
>> 1. Org. A has a /8 and wants to transfer 32 of it's constituent /24s to Org. B.
>> However, Org. A doesn't want to put any effort into renumbering,
>> so, those 32 /24s are each individual non-aggregable /24s.
>> This transfer should not be allowed.
> 1A. Org A has a /8 and wants to transfer 32 of its /24s to Org B. Org A is already announcing each of these /24s separately at different points around the world, so they've already done the deaggregation. Should the transfer still not be allowed?
Correct... The transfer still shouldn't be allowed.
>> 2. Org. A has a /20 and a /18. Org. B has need for a /19. Org. A has
>> deprecated their use of the /20 and all of their resources are in
>> the /18, but, they are using just under 75% of the /18.
>> Org. A would rather transfer the /20 and the top 1/4 of the /18 than
>> renumber that 1/4 of the /18 into the /20.
>> This transfer should not be allowed (though I admit the case against
>> it is weak).
>> 3. Org. A has four disparate /20s. Org B. has need of a /19. Org. A
>> would like to transfer two of their /20s to Org. B, but does not have
>> any pair of /20s which can be aggregated.
>> This transfer should be allowed. The /20s are already disaggregated
>> in the routing table and there is no increase in routing table
>> size that results.
> Wouldn't it be even better if Org B was forced to find a different Org that can fulfill a /19?
I would hope that Org. B would see incentives to finding a /19, but, I don't think
there is any community benefit to forcing them to do so.
> (Not that I'm suggesting that this would be good policy)
>> 4. Org. A has four disparate /20s. Orgs. B, C, D, and E all have need
>> for /24s. Org. A would like to sell individual /24s from one of their
>> /20s to each of the above Orgs. (B,C, D, and E).
>> These transfers should be allowed as there is no significant
>> difference between this and transfers where ARIN has
>> carved up a block during the initial allocations. The transfer
>> sizes comply with community accepted policy.
> What is Orgs B, C, D, and E are legal subsidiaries of a single organization?
Then they are Org. B and not Orgs. B, C, D, and E.
>> In essence, I'm trying to say that transfers which create unnecessary
>> additional disaggregation should be avoided.
> For what definition of "unnecessary" and why is "additional" the criteria? EVERY SINGLE TIME ARIN allocates space to someone, it creates additional disaggregation... and apparently you're ok with that.
You misuse the term disaggregation. ARIN does deaggregation.
When an organization needs a /20 and gets 16 separate /24s from a
block that was previously treated as a /16 or some other shorter prefix,
that is unnecessary disaggregation.
More information about the ARIN-PPML