[arin-ppml] Statistics regarding NRPM 8.3 Transfers to date
Brett Frankenberger
rbf+arin-ppml at panix.com
Thu May 5 21:55:34 EDT 2011
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
More information about the ARIN-PPML
mailing list