[arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3

[Frank Bulk]

Brett:

You've have captured an approach that I think will serve all parties quite
well.  

It doesn't make the IPv4 transfer market as liquid as some might like it to
be, but disaggregation needs to be kept in mind.  By limiting it to so many
units over time, the expansion of the routing table will occur more slowly,
giving time for operators to upgrade and replace their gear or optimize
their routing tables as necessary.  As some others have commented on NANOG
some time ago, as IPv4 becomes less important it's possible that there will
be higher levels of route summarization and greater use of default routes.

If we had had a monetize the expansion of the routing table then
disaggregation would be taken care of automatically, but that hasn't
happened, so RIR policies need to take that into consideration.  

Frank

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
Behalf Of Brett Frankenberger
Sent: Monday, May 30, 2011 10:42 AM
To: Owen DeLong
Cc: Brett Frankenberger; arin-ppml at arin.net
Subject: Re: [arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3

On Sun, May 29, 2011 at 08:46:28PM -0700, Owen DeLong wrote:
> 
> On May 29, 2011, at 7:14 PM, Brett Frankenberger wrote:
> > 
> > Now I'm confused . The language below says "No organization shall
> > offer ... more than one address block per year where said address block
> > is smaller than its original registered size".  
> > 
> 
> You are correct. I missed that in the original and would probably remove
> it from what I actually would include in the policy.
> 
> What I would think makes more sense as policy would be:
> 
> Organizations may transfer multiple address blocks but
> no organization shall receive more than one address block
> per year where said address block is smaller
> than its original registered size.
> 
> I believe that accomplishes the intent without undue restrictions on the
> suppliers.

So, looking at the other side, if Organization A justified a /15, they
would be allowed to transfer a /16 from Org B and a /16 from Org C to
get their /15, provided that at least one of the /16s had originally
been assigned to Org B or Org C as a /16 (so they would be receiving
only zero or one "smaller than its original registered size" blocks)?

Matthew Kaufman wrote:
   If the *only* way to fulfill a /14 is to get two /15s, one from each 
   of two suppliers, that should be allowed as long as there is
   demonstrated need for the /14.
and you (Owne) responded:
   We can agree to disagree.

Based on your proposed language above, I assume that the disagreement
is only over the case where both of the /15s are deaggregates of a
larger original assignment.  If one of the /15s is what was originally
allocated by ARIN, then it would be allowed?

> You didn't miss anything. I misread Bill's language the first time through
> and your diligence caused me to re-examine it and propose a corrected
> version above. Does that seem to do what you think is right?

See my question above.

Also, if we have the above restriction (can only receive one
deaggregate per year), then perhaps we don't need the existing one
transfer per three months limit.  John has indicated that ARIN will
interpret the NRPM provision restricting a provider to one allocation
from ARIN every three months (except in exceptional cases) as also
restricting a provider to one receipt of address space via transfer
every three months.  So if we have the single aggregate clause, the
three month rule, and the proposed "one deaggregation per year" clause,
then we have a situation where an organization that needs a /15 and
finds two /16s available, can transfer one of them immediately, and can
transfer the second one (a) three months later, if one or both of the
/16s are blocks that were originally allocated as /16s, or (b) 12
months later, if both the /16s are part of larger allocations.

I don't think there would be any reason to not allow, if one or both of
the /16s were originally allocated as /16s, both transfers to complete
initially.  (Or, if one is located and transferred, and the second one
is then located one months later, to allow that transfer to occur
immediately -- so we don't need the three month rule with transfers,
either.) The point of a "single aggregate" clause and/or a one transfer
per three months clause would seem to be to prevent deaggregation.  If
we instead attain that goal more directly, with a "one deaggregation
per recipient year" policy, then the other requirements are no longer
needed.

Going forward, there may also be a need to think more about the
definition of "original registered block size".  Today, we are in the
early stages of this game, and second order transfers (i.e. 8.3
transfers of space that has already been transferred under 8.3) are
rare or nonexistant.  But a few years down the road, that might not be
the case.  

Under the "original registered size" rule above, three years from now,
an organization needing a /15 would be able to tranfer two /16s from
two different holders of blocks originally assigned by ARIN as /16s. 
But such an organization wuld not be able to transfer two /16s from
two different holders of /16s where those /16s were transferred to
those holders as /16s, but which /16s were originally part of a larger
allocation from ARIN.  I'm not sure that's a meaningful distinction. 
Once space is deaggregated, it's not likely to ever be reaggregated. 
So it doesn't make a lot of sense to distinguish between a /16
originally provided as a /16, and a /16 originally provided as part of
a /14, but which /16 was deaggregated and transferred years prior. 
Either way, it's a /16 that isn't likely to ever be reaggregated, so
there's no deaggregation resulting from moving it around.

Of course, if we seek to fix that, we need to do it in a way that
doesn't encourage two-step transfers just to get around the rule. 
Perhaps allow a deaggregate to count as an "originally registered
block" one year (or some other period) after it's transferred as a
deaggregate.

All this seems complicated, but necessarily so, I think, due to the
competing objectives and the strong incentive to seek loopholes that
will exist once ARIN runs out of space.

As far as doing what I think is right, I have previosuly commented that
a limit on transfers per unit time was the only realistic way to
prevent massive deaggregation, but I now think a limit on
deaggregations (such as you propose above) to a single entity per unit
time might be a better approach to that goal.  But I'm not certain. 
(One clear effect of the policy is to place a higher value on blocks
offered for transfer that were originally registered in the size being
transferred.  An organization would pay more for a block that wouldn't
use up their one deaggregate for this year than for a block that would
use up their one deaggregate for the year and restrict them to
transferring onyl whole blocks for the next year.  That's probably
good, but it's not clear ...)

     -- Brett
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.