[arin-ppml] Summary: lowering the ARIN minimum allocation

[William Herrin]

A hundred messages later, here's a summary of the discussion on
lowering the ARIN minimum allocation for Multihomed organizations:

1. Singlehomed and single-vendor multihomed uses a priori excluded
from the discussion. Single-homed users' routes are aggregable with
the ISP's if assigned by the ISP. If assigned by ARIN they're not
aggregable. Multi-vendor multihomed users' routes are not aggregable
regardless of who assigns them. Hence it is appropriate to consider
the two cases (multihomed, not multihomed) separately.

2. Current ARIN minimum allocation is /22 for multihomed
organizations. Defacto Internet backbone routing minimum is /24.

3. RIR minimums are about routing. They help suppress the growth of
the backbone BGP table by encouraging aggregability. They appear to
serve no other purpose and are actually counterproductive to ARIN's
companion goal of allocating the minimum number of addresses an
organization needs.

4. If a multihomed organization announcing a /24 cut from an ISPs's
space trades that /24 for a CIDR block from ARIN, there is zero net
impact on the routing table. The impact comes if organizations who
weren't multihoming before start announcing a route.

5. Should make cautious, conservative changes to the minimum
allocation and look for unintended consequences before lowering the
minimums further.

6. Doubtful value to lowering the minimums beyond /24 since routes
smaller than /24 are not generally routable on the backbone right now.
Would probably be counterproductive since we'd  allocate scarce IP
addresses in quantities that aren't actually usable for any valid
purpose.

7. Unable to identify any ISPs who presently both filter on RIR
minimums and choose not to carry a default route to an upstream ISP
that doesn't filter. Hence no apparent route filtering value to the
RIR minimums, at least not in practice.

8. Common counterproductive situations with the current policy
observed where an organization separately announced as many as 6
discontiguous /24's from ISPs' space into the BGP table before finally
requesting and receiving a single ARIN allocation.

9. The current minimum can result in allocating more addresses than
the requesting organization actually wants, as long as it finds a way
to qualify.

10. No major ill effects noted from APNIC (I think it was) lowering
their minimums to a level that includes /24 allocations.

11. Worries about the effect of multihomed DSL users on the routing
table, regardless of whether addresses are assigned from ISP space or
from ARIN. Some observe that ISPs generally don't provide BGP service
to DSL or cable modem users.

12. Worries about whether the availability of provider-independent
(PI) space for multihomers would push folks who don't already
multihome to start.


With all of this in mind, it seems to me that there are two ways we
can reasonably go with the policy:

Alternative #1: Lower the minimum for multihomed organizations to /23.
Give it a year to see if we get unintended consequences. Then lower it
to /24.

Alternative #2: Craft a fresh policy for small multihomed
organizations to fill the gap between the current /22 ARIN minimum and
the /24 defacto minimum on the backbone. Limit folks to 1 assignment
at a time longer than /24 and none once they have at least a /22 so
that starting allocations smaller doesn't induce routing table growth.
Exclude folks for whom their ISP bills are less than the systemic cost
of carrying a route. Make sure folks getting these allocations are and
stay multihomed with multiple vendors who are really doing BGP. Make
sure they're not just using it as an excuse to get PI space. Maybe
eventually raise the regular minimum from /22 back to /20 in order to
encourage aggregation if this /24 policy works out.


Both approaches are cautious steps forward. The first approach is very
straightforward but offers no protection against the mostly
hypothetical problems with allowing more orgs to qualify for ARIN
addresses. The second tries to more creatively tackle the risks and
liabilities at a cost of greater complexity.

Thoughts?


Regards,
Bill Herrin

-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004