Forcible reclamation?
Karl Denninger
karl at MCS.NET
Tue Jul 8 12:03:34 EDT 1997
On Tue, Jul 08, 1997 at 11:10:00AM -0400, Paul Ferguson wrote:
> At 09:09 AM 07/08/97 +0100, Jeff Williams wrote:
>
> > Agreed. That is why we should be looking at adding more address space
> >as a priority rather than imposing restrictions on allocations as a
> >priority. I agree that if we can reclaim space that is not being used,
> >than this avenue should of course be exploited. BUT FIRST and FORMOST
> >providing new and additional address space should be the #1 priority.
> >This however does not seem to be the case according to the tennor of
> >the discussion on this list, nor form statments made by Board members
> >of ARIN.
>
> Deja vu. A discussion on this topic usually always results in
> someone stating that more address space is needed.
>
> I disagree that increasing the address space is the most
> important gaol here. In fact, I'm not sure it even rates
> in the top five, at least not in the near term.
The existing space is adequate for a *long* time, provided that we do
reasonable things with it.
If we start to run out, we can go take back all the people's space who
haven't met even 20% of the current requirements (ie: actual utilization
below 10% of allocated) -- that should reclaim all of the existing Class "A"
addresses, which is 1/4 of the total allocated, and 1/2 of the total
possible IPV4 space.
Now, on to issues that are real.....
Route table slots:
A real issue, but one which is solveable with the application of
*small* amounts of money. All existing current CISCO products, for
example, either can handle at least 128M of RAM or can easily be
upgraded to do so with one board swap.
Route CACHE entropy:
This is a real problem. The solution is to reduce ENTROPY in the
route table. Several fixes come to mind for this, all of them
politically unpalatable for the *MAJOR* ISPs (ie: Sprint flaps
enough that these fixes would render their backbone far less useful,
as it would be dampened out of existance frequently).
However, the purpose of this kind of discussion is to come up with
fixes, right? The problem areas aren't in forwarding performance
nearly so much as they are in entropy management. Entropy
management is doable in the EXISTING BGP4 code releases in
most major vendor's hardware *RIGHT NOW*.
So why is it that we focus on things like denying /19s to multi-homed ISPs,
when that has absolutely NOTHING to do with the performance and operation of
the network as a whole?
Things that make you go "hmmmmm...."
--
--
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, http://www.mcs.net/
Voice: [+1 312 803-MCS1 x219]| NOW Serving 56kbps DIGITAL on our analog lines!
Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
More information about the Naipr
mailing list