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

[Brett Frankenberger]

On Mon, May 02, 2011 at 01:32:43PM -0700, Owen DeLong wrote:
> 
> So... I'll try to provide some examples of what should and shouldn't
> be allowed...

The following questions aren't intended to be argumentative, but
rather, to define the line more clearly.
 
> 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.
> 
> 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.
> 
> 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.

As part of your #4 above, which of the following disaggregations would
you allow:

#1 (this is the most efficient possible, so I'm assuming you'd allow
this):  Org. A splits /20 #1 into 4 /24s all from one /22 (and
transfers the four /24s), leaving it with a /22 and a /21 and the other
three /20s it startd with.

#2:  Org. A splits /20 #1 such that one /24 can be transferred from
each /22, so four /24s are transferred, leaving Org. A with four /24s
and four /23 (from /20 #1) and the other three /20s it started with.

#3:  Org. A splits each /20 and transfers one /24 from each, leaving it
with a /24, /23, /22, and a /21 from each /20.  So the result is 4
/24s transferred, and Org. A has 5 /24s, 4 /23s, 4 /22s, and 4 /21s
remaining.  

(If the answer to #2 or #3 is "no", is it dependant on Orgs B, C, D,
and E all coming at the same time.  Would the answer change if the Org
B transfer were completed, then a few months later, Org C came along
(and a transfer completed), then Org D a few months later, and so on.)

Also, separately, suppose Org A. has one /20, and Org. B has a need
for a /23.  Org. A splits the /20 into two /23s, a /22, and a /21,
and transfers one of the /23s.  (Presumably this would be allowed.) 
Now, a few months after that Org. C comes along and demonstrates a need
for a /24.  What is Org. A allowed to do?  Can they split the /23 they
have left and transfer half of it?  (Presuambly yes).  But would they
have to split the /23?  Or could they split the /22 or the /21 instead?

Suppose that, instead of needing a /24, Org. C needed a /23.  Does the
answer change? (That is, is Org. A allowed only to transfer the /23? 
Or can they split the /22 or the /21?)

Finally, suppose that Org. A has two /23, a /22, and a /21, but they
didn't get there by splitting a /20.  Instead, it's four separate
allocations they received from ARIN several years in the past. 
(Assume that's possible.  Or, if you prefer, subtract 3 from the mask
length of every prefix in my examples to keep everything at /21 and
longer.) Does that change the answers to what happens when Org. C comes
along wanting a /23 or a /24?

> In essence, I'm trying to say that transfers which create unnecessary
> additional disaggregation should be avoided.

The devil is in the details, though.

     -- Brett