The only difference I'd make is to _START_ with 192, not end there. We
get a lot more bang for the buck there, as renumbering will help
aggregate both continentally and regionally, and also free up badly
managed space for the future.
I think this is actually a pretty good idea. I think not dealing with
pre-existing allocations is going to mean putting an ever-tighter
squeeze on future allocations in a way that is counter-productive,
since if you squeeze the number of IPv4 routes used to route a chunk
of address space too hard you'll end up applying pressure which
encourages people to use the address space less efficiently. I'm
not particularly fond of prefix length filtering since I think
there are times when it is appropriate and useful to route longer-prefix
routes (though I guess I recognize the necessity at this point), a
better aim would be to get the average number of routes it takes to
route a chunk of address space down without resorting to implementing
prefix-length filters.
The one thing that hasn't been done, however, is to set an actual
goal for routing efficiency. I don't think it is rational to
expect we'll be able to maintain a 30,000 route forwarding table
until the end of time, since I think doing so while simultaneously
allocating addresses in a way which ensures both good continued
growth and efficient use of the address space is not possible. I
also wouldn't bet the farm on some amazing new routing architecture
saving us, so what I think we should be doing is trying to pick a
routing efficiency which gives us a number of routes at the IPv4 end
state (i.e. the number of routes needed to route the full address
space) which seems tractable given the current routing architecture
and plausible not-too-distant future hardware.
I'd like to state my guess that a good number to aim at might be
about 1200 routes per fully-utilized class-A-sized chunk of address
space. This would put the IPv4 end state at a maximum of about 250,000
routes, a number which I think is not an unreasonable target for new
high-end router designs since I think it represents both a tractable
routing problem with the current architecture given modern enough
hardware, and it is not too out-of-line with what I am guessing might
be accomodated in a fast forwarding path. I think if both router
vendors and users aimed at this (or some other mutually satisfactory)
target, without exceptions, the outcome would be happier than trying
to muddle along designing both hardware and address allocation plans
without either a quantitative measure of what's good and what's not,
or a well-defined goal of where we'd like to end up. And I'd like to
aim for a place we can get to without any magic bullets, I think it
would be better to save those for IPv6 where we have a cleaner slate
to deploy onto.
I like the idea of measuring each and every class-A-sized block
against some standard separately, since a lot of the class-C space has
been allocated to regional registries this way and it inconveniences
those places which have done the best the least. I'm less attached to
the number 1200 in particular, but I do think an explicit target should
be chosen which represents both a tractable limit to design big routers for
and which allows the implementation of efficient address allocation strategies
which won't have to be tighened over time. I do note that 1200 is
close to the threatened /18 address filter, but this is mostly accidental.
I'd much rather see each space filled with /14's and /20's, and even
an occasional /23 or /25, as appropriate and as long as the filled block
was only 1200 (or N, for some well-defined N) routes, rather than
picking an arbitrary, one-size-fits-all filter limit. The latter is
a sign of failure.
I think cidrd, which after all is a deployment group, would be
much more productive if it concentrated on deciding on an appropriate N,
and then figuring out how to fix each class-A-sized block where the
number of routes exceeds N, without exception. It's fine to work
on magic bullets too, but I really think it would save a lot of
noise if we could also get back to doing some basic engineering of what
we have and know already.
I've included a modified table of the current situation, this one done
using data from a more neutrally-located router (one belonging to
Haavard Eidnes, the same one that the top 20 list comes from) to
lose the bias that fetching this from one of MCI's routers causes.
Dennis Ferguson
A B 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206
---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
8 23 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
9 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
10 0 3 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0
11 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
12 0 8 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0
13 0 13 0 2 1 0 0 0 0 2 0 0 0 0 0 1 4
14 0 40 0 4 1 0 0 0 6 2 0 0 0 0 7 3 6
15 0 71 0 21 5 0 0 0 6 8 0 0 1 0 14 12 3
16 1 4675 28 43 45 0 6 0 53 47 6 0 13 5 71 35 21
17 0 0 5 4 8 0 0 0 4 14 2 0 5 9 17 2 11
18 1 1 10 9 9 0 1 0 17 29 2 0 27 15 38 17 24
19 0 3 29 36 31 0 0 0 29 22 6 0 43 15 51 61 145
20 0 1 55 45 32 0 6 0 33 35 9 0 49 16 95 32 5
21 1 1 74 61 40 0 9 0 61 51 5 0 92 12 95 44 6
22 1 0 162 89 53 0 17 0 79 59 7 0 125 32 74 43 5
23 3 2 337 98 97 0 21 0 116 91 22 0 136 20 115 61 2
24 21 18 6272 1462 1230 1 225 1 2970 2431 278 1 892 357 2539 1119 103
26 0 5 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
27 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0
28 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0
29 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0
30 0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0
31 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0