ARIN Proposal

Karl Denninger karl at MCS.NET
Thu Jan 23 12:11:54 EST 1997


> > I believe that any ISP should get their own /19 at the outset.  Among other
> > things, if you EVER multi-home you NEED IT if you want the multihoming to do
> > you ANY good.
>
> In a perfect world, I quite agree.

Well, actually in the current world I believe this is true.

> However, there are currently around 4,200 ISP's in the list.  Now, per
> Kim, 300 or so ISP's already get their address blocks directly from the
> 'NIC, so for the case of round numbers, let's say there are 4000 ISP's
> who are aware enough of services like the list that would qualify for
> that /19.

Yep.

> That works out to slightly less than 2 /8's... if you pack them in as
> tight as you can.  Again, in an ideal world, you'd reserve each ISP
> more room than you allocated... let's say for sake of discussion, we
> allocate enough space for each IS/P to have a /18... that ties up
> 4 /8's...or let's say we reserve a /16...  that takes us up to around
> 15 /8's either in use or reserved.

Allocate a /19. That's the routeable block size right now.

> There appears to be that much space out there, in various reserved blocks;
> if we're looking only at the here and now, it looks like there's the space
> and more to do as you suggest.

Correct.

> If - and despite dire warnings of industry consolidation - ISP's continue
> to grow at the current rates;  if another two or three thousand ISP's
> startup up next year and the next year, each asking for their allocation,
> at some point in the next two - five years, depending on how liberal
> we are with reservations, space starts to get tight;  and the above back
> of the envelope numbers do not take into account folks who already have
> allocations and need more.

Uh, no.  I'd pack the blocks in, and deal with the fact that the routing
table MIGHT, under that plan, double in 3-5 years.  The hardware we have
*RIGHT NOW* can handle this load.  Remember that the vast majority of ISPs
are NEVER going to get beyond the first /19.  In fact, those who don't sell
dedicated connectivity probably will never need anything near a /19, but
they still HAVE TO HAVE IT if they want to multihome in the future -- and
we CAN assign it.

Right now we have 42,866 network entries in our BGP core (we run
default-free).  I have ~29MB free (out of 64MB) in most of my core 7513
hardware.  Some of our edge devices have less (due to the people they
exchange with, and the number of paths available there, consumption is
slightly higher).

HOWEVER, CISCO currently wastes about 50% of that RAM allocation.  This I
have *proven* by looking at other implementations and their RAM requirements.
Assuming that CISCO tightens up their code (not unreasonable) I would expect
to see that usage drop by perhaps 30% during that same time.

If I go to 128MB of RAM (done with a chip swap on the 7513 RSP boards)
using today's metrics and software I can handle ~140,000 routes.  This is
WAY beyond any rational estimate during that device's service life based
on handing out /19s to people.

The bigger issue is route flapping.  The fix for flapping routes is an
architecture which doesn't croak when they happen and which can recompute
the table faster.  The *short term* work-around (which we and basically
everyone else these days uses) is dampening - which is working quite well.
Core CPU utilization rates in our hardware right now are very reasonable.

If we pack in the allocations, you get about 2 /8s.  Let's assume we double
the number of ISPs every year (this is frightening to think about, but let's
assume it anyway).  So instantly we need 2 /8s, in the first year we need 2
more /8s (for the first doubling), the second year we need 4 /8s and the
third year we need 8 /8s.

That's 16 /8s.  Less than 1/4 of what is reserved right now in the
historical Class "A" space.  If you think we'll see THREE doublings in the
next three years I frankly have to say you're nuts, but I'll be nice and
give you that at this point.   The issue is that we're still ok.

> If it were certain that a replacement for IPv4 would be available in the
> next couple years, what you suggest might be workable;  however, I've yet
> to be convinced that it's good policy for every startup ISP, such as a
> small 56K basement operation with 8 dialup modems being run by a high
> school junior to start out with a /19...at least until there's a handle
> on how long the current space must be made to last and what sort of
> growth we're going to see in that time.

If you can live out of one Class "C" then the pain of renumbering isn't too
horrid, even though its a pain in the ass.

Where it becomes a problem is when you start selling dedicated service or
hosting web sites.  Remember too, that despite people bitching about static
allocations, there ARE reasons for doing it that are fundamentally sound --
lots of people these days use their accounts to "punch through" corporate
firewalls, and without a static address THIS DOES NOT WORK.  I'd estimate
that at least half of our so-called "personal" account holders are really
"work-at-home" people who, with the security bar being raised as far as it
has been these days, NEED this service.  Also, there are ISDN and other
"router-based" devices which customers use that also need a static
allocation (or they don't work).

> It may well be that a set of objective criteria can be worked out for
> where it makes sense to allocate a /19;  given the number of open-ended
> issues, I have trouble agreeing that it should be applied across the board
> to all ISP's.

Once you go beyond the first /24 as an ISP (ie: the basement guy with a
half-dozen computers and modems) you NEED PI space.

-
--
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl     | T1's from $600 monthly to FULL DS-3 Service
                             | 99 Analog numbers, 77 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
Fax:   [+1 312 248-9865]     | 2 FULL DS-3 Internet links; 400Mbps B/W Internal



More information about the Naipr mailing list