[Warning: Long post. Get another cup of coffee before reading. To save time
for those of you looking for the short answer: "Mark - start peering with your
upstreams with a small announcement of /23 or /24, and you'll be fine -
there's
no need for you to get a block from ARIN for your requirements."]
Let's add a little spice to you list...run it up the flag pole etc... but
please let's deal with this professionally with out to much flame!
My goal is to ensure the network meets the business objective of our
company, not simply to debug traffic etc. In order to do this I need
redundant connections to multiple ISP's, and a method for delivering delay
sensitive traffic in the most efficient way possible.
The above implies BGP.
Correct so far.
I've applied to ARIN for a number block large enough to ensure
routablility, and have been rejected. This leaves me with three
alternatives, please correct me if you see any another alternatives. First,
we can attempt to buy address space which may or may not be transferable,
or more likely we acquire a small company, and/or it's assets, one of which
just happens to be a large chuck of address space. Second, I can do the
time proven technique of lying about how many hosts I have or how many I
plan to have, this I find uncomfortable as I think it is dishonest! I'd bet
at least one of the readers of this list has exaggerated about how may
hosts they have in their network, or how many they planed to have on a
template, so don't be to quick to grab for the high moral ground!! Finally,
I can appeal ARIN's decision, which I have already requested from IANA, and
was told to request an appeal from hostmaster@ARIN.net. I'm still waiting
to here something.
Your implied assertion that you need a set of address space that is larger
than
a /24 (or /23, or even /22) to "ensure routability" is not valid _enough_.
Currently, only Sprint, AGIS, and a handful of others are filtering >/19
routes
(in certain /8 ranges) at their borders, unless the number of aggressively
filtering NSPs has changed significantly since it was last brought up on this
list some months ago.
If your "primary" upstream from whom you've received a /24 is advertising
your /24 in a larger aggregate, and you also are advertising your /24 through
at least one other NSP that is not Sprint (the other possibly being Sprint or
some other NSP) then you have two valid inbound paths with acceptable
redundancy. You could also ask your primary upstream to "de-CIDRize" their
own
announcement and double-announce the /24 with your AS tag and also the larger
aggregate with only their own AS path, but that's how you get into The CIDR
Report more often. 
Anyway, you're indicating that a significant
portion of
your customers are single-homed with Sprint or AGIS (or some other
route-limiting NSP) who can't hear or won't choose the more specific /24 over
the larger aggregate announcement.
I think the number of sites that have this particular situation is very small
and does not justify such an enormous waste of address space to circumvent the
filters on these particular providers. Small address advertisements (>/19)
are
sufficient to provide acceptable redundancy in a multi-homed environment.
In any case, your intended use of a larger aggregate completely invalidates
the
reasons that (from what I understand) Sprint and AGIS block those routes:
overfull and unstable routing tables. You're creating the same end result
with
the same number of announcements, and using up valuable IPv4 space as a side
effect. Double plus ungood. You should opt for the "least worst" scenario,
and simply advertise a /24 through multiple upstreams out of your primary's
larger aggregate.
Furthermore enforcing "acceptable redundancy", regardless of Sprint/AGIS
filters: Most regionals are multi-homed through at least two NSPs, at least
one
of which will not be Sprint or AGIS. This means that the packets find their
way to you even if your connection to your "primary" drops (and therefore all
traffic from Sprint to your network in the aggregate starts to blackhole at
your primary's IGP-BGP border.) Therefore, Sprint/AGIS can't get to you, but
the overwhelming majority of the Internet still can get to you through a more
specific path, even if many of those people have some of their connectivity
provisioned by Sprint/AGIS. I will certainly not say that you won't have some
number of customers that can't get to your service. If you're that concerned
about them, pull in T1s from both Sprint and AGIS - they'll announce routes
from customers that they won't accept (at least, Sprint seems to - can't say
about AGIS) and I expect the bandwidth costs for those "Sprint/AGIS only"
links
will not be unfairly priced compared with what you'd have to pay for
transit to
Sprint/AGIS across someone else's backbone, anyway.
Essentially, I disagree that the premise for your address requirements of any
size to ARIN is valid based on the information that you have revealed thus
far. If you have 5,000 hosts that all must see the Internet and are running
web servers, then it's a different story. But if you're just a few dozen (or
even hundred) servers, a /24 or /23 should be sufficient for an acceptable
delivery-of-service level.
On appeal I plan to quote RFC2050 which according to the ARIN web site is
what they use make allocation descions. Basically I think ARIN procedures
only take into account network size, and nothing else. I don't think
RFC2050 language is that strict.
Please see item '3b' below:
"In order for the Internet to scale using existing technologies, use of
regional registry services should be limited to the
assignment of IP addresses for organizations meeting one or more of the
following conditions:
a) the organization has no intention of connecting to the Internet-either
now or in the future-but it still requires a globally
unique IP address. The organization should consider using reserved
addresses from 1918. If it is determined this is not
possible, they can be issued unique (if not Internet routable) IP addresses.
b) the organization is multi-homed with no favored connection.
c) the organization's actual requirement for IP space is very large, for
example, the network prefix required to cover the
request is of length /18 or shorter.
All other requesters should contact its ISP for address space or utilize
the addresses reserved for non-connected networks
described in 1918 until an Internet connection is established. Note that
addresses issued directly from the
IRs,(non-provider based), are the least likely to be routable across the
Internet.
"
You may be right, since option "b" is pretty clear. And I might even agree
with you that ARIN should allocate you addresses (small addresses, though)
using this as the only criteria. But it's not the only criteria used. RFC
2050 is a "guideline" as expressed in http://www.arin.net/ip-allocation.html ,
but other CIDR-based RFCs are listed as resources, and the document even goes
so far as to say:
"These potential policies may include such steps
as setting limits on the size of Classless Inter-Domain
Routing (CIDR) prefixes added to the routing tables or
filtering of non-aggregated routes."
I'm just reading the text; it's fairly clear that ARIN can be ambiguous about
their allocation sizes. That may be unfair, or may play favorites, or
what-have-you, but that's not the issue we're debating and should be taken to
another thread (threat? thread? 
which can heartily fill my /dev/null
procmail ruleset.
Also, from 3.1 "utilization is a key factor" implying it's not the only
factor.
"
3.1 Common Registry Requirements
Because the number of available IP addresses on the Internet is limited,
the utilization rate of address space will be a key
factor in network number assignment.
"
Basically our normal output traffic is about 45mb/s with a peak as high as
67.6Mb/s during Clinton's shinangians, we've been listed as the 16th
busiest web site in the world, and I think that ought to count toward
getting a routable address space!!!
Hardly. According to nitrous.digex.net - Looking Glass: ad.DoubleClick.com is
on a /23. www.ABCNews.com is in a /20. www.weather.com is on a /24. These
sites are working just fine in >/19 networks, and I'm sure they push just as
much data as you, and are no less "important" as you, unless you care to tell
us how your bits per second output should influence policy that effects
everyone. So are you a proponent of "largest bit _output_ wins"? If so,
please see the settlement argument of a few weeks ago on this list for some
excellent discussion. Shouldn't you be giving IP addresses to ME?
I also wonder if there aren't free speech issues involved if US entities
start dropping traffic based on non technical factors?
I don't see how this is relevant, and in any case, no.
I welcome any suggestions you may have as to how I can archive my goal of
obtaining an address block big enough to implement BGP succesfully.
See my initial invalidation of your address size requirement above. I think
you'll be happy with a properly advertised block from within an aggregate.
JT