small multihomed organizations (fwd)

[Lee Howard]

This is the "micro-allocation" proposal.  I still don't support it.  In
refutation:

1)  I was talking about /24s, and you're talking about /20s; there's an
order of magnitude of difference.  If deception is a significant problem,
suggest remedies to that problem, such as stricter evaluation and
verification of justifications.

2) 
  	a)  A customer of two equally-connected (ha!) ISPs with a /24
from aggregate space of one of them should not have this problem, if
both ISPs propagate the customer's /24 BGP announcement.  Given that
a few organizations will filter the /24, routing will be asymmetric. 
But symmetric routing between multiple ASNs is doubtful.  
	One further concern:  can we be confident that ALL providers who
filter on RIR allocation boundaries will accept a "second swamp?"

	b)  The cost of renumbering is part of being on the Internet.  I
resisted that statement six years ago, as did many people, but it seems
to have become conventional wisdom.  If I have two customers, one of whom
is multihomed, and the other of whom is not, why should the multihomed
customer get an exemption to the renumbering rule?

Your requirements also don't fit with my original point.  At least the
third one doesn't--I'm concerned about small organizations that are
multihomed, and under current rules can't justify a /24 based on 
hostcount.  Requiring standard justification means they're still out of
luck.

You are correct that the micro-allocation pool would not significantly
affect the routing tables, except for providers who currently filter on
RIR allocation boundaries:  they would have a "second swamp" to route.
I'm certainly concerned about the growth of the routing tables, but I
don't think it's relevant.

Lee


---------- Forwarded message ----------
Date: Mon, 6 Aug 2001 19:14:28 -0400
From: Daniel Golding <dan at netrail.net>
To: David R Huberman <huberman at gblx.net>, vipar at verio.net
Cc: Lee Howard <lhoward at UU.NET>, ppml at arin.net
Subject: RE: small multihomed organizations 

It is well past time that organizations wishing to multihome, but not
requiring a /20 of space, should be able to acquire PI space from RIR's. The
problems with our current arrangement is that...

1) It provides an incentive to be less than truthful in requesting an
initial allocation, which leads to waste in the use of that initial /20. If
an organization can subsist on a /23, they should be able to request that.
By forcing only those who can "justify" a /20 to receive PI space, ARIN
inadvertently causes deception, which leads to a lack of trust.

2) Organizations that do not qualify for a /20, yet are multihomed, are at
several disadvantages. These include...
	a) The possibility of a severely non-symmetrical traffic load to upstreams,
if their address space is assigned out of an upstream's summary aggregate. A
lack of flexibility in making routing announcements.

	b) The additional cost of renumbering if they choose to change transit
providers. While changing transit providers was once quite difficult, it has
become very easy. However, those who choose to stay honest, and not
"gundeck" their Initial Allocation, are at a competitive disadvantage again
those who are not as honest. Honesty should never be a competitive
disadvantage.

It is well passed time to allow /24 allocations from a specific /8 block
that is set aside for the purpose of smaller allocations for multihomed
organizations. The requirements for allocation from this block should
include:

1) Possession of an Autonomous System number
2) Multihomed to two or more upstream networks
3) Standard justification on a per-host/per port/etc basis

ARIN's graphs of AS number depletion indicate that ARIN alone issues 3000
AS's per year, assuming a steady state. As economic conditions improve, and
taking into account the other RIR's, this indicates an extremely large
number of organizations that may benefit from this policy.

The effect of this change on global routing tables will probably be minimal,
as most providers currently allow /24s to be advertised through their
networks, with few exceptions. This will limit the growth in routing table
size, which, in any case, has proven to be a controllable linear growth,
rather than the much feared exponential growth. Current BGP-speaking edge
and core routers are certainly capable of handling any nominal growth in
table size caused by this change.

Most of those who might benefit from this sort of change are not a part of
ARIN's traditional membership, and do not present a uniform constituency to
ARIN. In spite of this, I would hazard to guess that organizations with
AS's, but not PI space now represent the majority of ARIN's membership base.

- Daniel Golding

> -----Original Message-----
> From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of David
> R Huberman
> Sent: Monday, August 06, 2001 5:26 PM
> To: vipar at verio.net
> Cc: Lee Howard; ppml at arin.net
> Subject: Re: small multihomed organizations
>
>
> Lee Howard wrote:
> > ARIN's current policy, as I understand it, is that multihoming is not
> > justification for a /24.  I would like to hear recommendations and best
> > practices from others for how to address the customer (pun intended)
> > without violating ARIN policy.  Should ARIN accept multihoming as
> > justification for a /24?
>
> Lyric Apted responded:
> > like you, I think most of us have an unofficial policy that runs against
> > ARIN's for the reasons you've mentioned - personally I believe that
> > multihoming should be justification for a /24.  in reality it
> is already.
>
> I'll chime in with a quick nod to Lyric's comment. More and more I am
> seeing bona fide engineering plans that require organizations to break
> from following ARIN's address usage policies. When we, as operators, deem
> customer and/or internal engineering goals as legitimate, it behooves us
> to support these efforts despite traditional policy.
>
> Interestingly, Bill Woodcock at RIPE-39 brought up the issue of "trust"
> between an RIR and its membership. To me, this is a classic example where
> the operator must be entrusted by the RIR to balance mutually exclusive
> goals.
>
> /david
>