[arin-ppml] Statistics regarding NRPM 8.3 Transfers to date

[Owen DeLong]

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.

Owen