small multihomed organizations (fwd)

[Daniel Golding]

Lee,

See below...

> -----Original Message-----
> From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Lee
> Howard
> Sent: Tuesday, August 07, 2001 10:00 AM
> To: ppml at arin.net
> Subject: RE: small multihomed organizations (fwd)
>
>
> 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.
>

The problem may be that there is frequently not outright deception, but the
current policy encourages people NOT to conserve address space, so that they
can expend enough to qualify for a /20. This seems to be at odds with the
RIR's mission, part of which is address space conservation.

> 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?"
>

Granted, filtering /24s is not widespread in general, but there are several
large providers who filter out /24s from their larger blocks (i.e. /8s) to
limit routing table size.

As far as providers towing the line on RIR policies - empirical evidence
suggests they will. If not, it's not the RIR's place to worry about what
providers will do. Of course, most providers will welcome this, because it's
that much less address space they will have to issue themselves, which
effectively reduces their administrative overhead.

> 	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?
>

For a couple reasons:

1) Multihomed customers are far more common these days, then six years ago.
Almost all medium and large enterprises are multihomed. All web intensive
businesses are, effectively, multihomed.

2) These are the folks for whom renumbering is the greatest burden

3) It prevents an unreasonable financial burden of renumbering on those who
are potentially most able to switch from provider to provider. Multihomed
enterprises can easily switch providers, or add, or disconnect additional
providers with no interuption in service. Well, except for renumbering...

> 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.
>

Well, I think this will need to be implimented in a step-wise fashion, to
achieve consensus. If the proposal to expand PI space to multihomed
enterprises is adopted, and it is successful, and the sky does not fall, it
is a great arguement for further micro-allocations. It is a good,
intermediate step, which will prevent an unreasonable scaling requirement on
the RIRs.

> 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.
>

Agreed.

> Lee
>

- Dan

>
> ---------- 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
> >
>