[arin-ppml] Rationale for /22

[Leo Bicknell]

In a message written on Fri, Jul 31, 2009 at 12:11:09PM -0700, Owen DeLong wrote:
> Sure, but, I'm not buying that these numbers are large enough for
> that to be a bad thing.

I never said they were.  What I said was, I am worried there is a
tipping point, and I think that argues for making small steps, and
not large ones so we don't overshoot.

> I would agree with policy limits that prevent people from getting
> multiple /24s rather than trading up until they reach /22 or possibly
> even /21.

https://www.arin.net/policy/nrpm.html#four3

A /22 is the smallest prefix for a multi-homed end-user.

End users must demonstrate:

    * A 25% immediate utilization rate, and
    * A 50% utilization rate within one year.

So the current policy means that if you get a /24 from Provider A's
PA block, and a /24 from Provider B's PA block, use 50% of the
addresses in each block (256 used, which is 25% of a /22), and plan
to use 512 (50% of a /22) in one year you get a /22 from ARIN.

I suspect most of the folks popping up and saying they had 6-10
different /24's in the global table before getting an ARIN allocation
either did it prior to us relaxing the limits (at one time it was
a /20), or didn't want to deal with ARIN for some reason.  Today I
see no reason why a someone should need more than 2-3 blocks before
qualifing for an ARIN PI assignment.

I'll also note that in this system when getting the ARIN PI block
the PA blocks are usually returned, they are not permanently used
routing table slots where as the PI blocks are.

So I'm failing to see the big problem everyone describes. I think
in fact the last policy change that moved things to a /22 resolved
95%+ of all the problems that have been brought up in this forum
before.

However, I am quite willing to entertain moving the limit down
further, as there seems to have been few ill effects from the move
to /22.  I am however worried that there is a tipping point out
there, so I support going to a /23, not further, at this time.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 825 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090731/408a3ab4/attachment.sig>