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

[Owen DeLong]

On May 5, 2011, at 6:55 PM, Brett Frankenberger wrote:

> 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.
> 
Yes

> #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.
> 
Depending on chronology, I'm not sure this could be avoided, but,
I agree it is not ideal.

> #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.  
> 
Same answer as #2.

> (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.)
> 
It would. Not because I want it that way, so much as I'm not sure there
is an effective mechanism by which to enforce solution #1 over
a longer chronology.

> 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?
> 
Ideally they'd split the /23, but, I don't see how we can usefully prevent
the other solutions without making the policy overly complex or
accidentally blocking transfers that should succeed.

> 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?)
> 
Ideally, they would transfer the /23, but, this is also subject to the
same caveats as above.

> 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?
> 
No.

>> In essence, I'm trying to say that transfers which create unnecessary
>> additional disaggregation should be avoided.
> 
> The devil is in the details, though.
> 

Agreed.

Owen