Mailing List Archive: ? re: Tony Bates' CIDR Report

On another list, we're discussing whether small ISPs should be able to
obtain globally routable /19s.

A well respected member of the NANOG community has suggested that "routers
would fall over" if the /19s were granted.

As you know, Tony Bates publishes the weekly CIDR report; therein he makes
the following comment:

"This lists the "Top 30" players who if they decided to aggregate their
announced classful prefixes at the origin AS level could make a significant
difference in the reduction of the current size of the Internet routing
table. This calculation does not take into account the inclusion of holes
when forming an aggregate so it is possible even larger reduction should be
possible."

Today's data indicates 2,791 router slots are involved in the "Top 30".

Could these router slots really be made available as Tony suggests?

If not, why not?

Thank you for your time and for your responses. If you will, respond to
pagans@texoma.net also.

If you prefer to remain off the record, reply privately with *OFF THE
RECORD* in your subject line.

Here's today's data as published at
<http://www.employees.org/~tbates/cidr-report.html#General_Status>:

--- 04Jul97 ---
ASnum NetsNow NetsCIDR NetGain % Gain Description

AS174 1148 819 329 28.7% Performance Systems International
AS2493 766 460 306 39.9% i*internet
AS3602 556 309 247 44.4% Sprint Canada Inc.
AS2048 251 120 131 52.2% LANET-1
AS1691 301 172 129 42.9% BCTEL
AS6541 186 59 127 68.3% GTE Intelligent Network Services
AS3804 248 135 113 45.6% Bell Solutions
AS1 1032 922 110 10.7% BBNPLANET
AS1967 186 82 104 55.9% Middle East Technical University
AS839 125 26 99 79.2% North West Territories Regional N
AS701 972 875 97 10.0% Alternet
AS7195 121 43 78 64.5% INTERRED
AS816 318 248 70 22.0% UUNET Canada (ASN-UUNETCA-AS4)
AS2704 256 186 70 27.3% HOOKUP-NET-A
AS4293 108 44 64 59.3% IMCI
AS549 250 189 61 24.4% ONet Backbone
AS5668 72 13 59 81.9% Century Telephone Inc.
AS4648 190 134 56 29.5% NZIX 2
AS3561 942 890 52 5.5% MCI
AS6181 53 4 49 92.5% FUSE-NET
AS3799 74 26 48 64.9% IDS
AS97 175 128 47 26.9% JvNCnet
AS813 208 161 47 22.6% UUNET Canada (ASN-UUNETCA-AS1)
AS719 565 518 47 8.3% LANLINK autonomous system
AS4454 74 27 47 63.5% TNET-AS
AS4763 100 56 44 44.0% Telstra New Zealand
AS2711 98 57 41 41.8% SUNBELT-AS
AS271 98 57 41 41.8% BCnet Backbone
AS3749 75 35 40 53.3% TECNET
AS225 63 25 38 60.3% VIRGINIA-AS
----
2791

Not that this is really all that NANOG relevant, but if one checks
into the archives on the NANOG and RIPE mailing lists, you will find
that after lots of discussion, I agreed with Daniel Karrenberg and many
others that /19s were eminently reasonable MAXIMUM prefix lengths for
globally-visible NLRI. A minimum aggregation boundary leading to
no prefixes larger than 18 bits is desirable, and any aggregation
that leads to even shorter global prefixes is a big plus for scalability.

Consequently, just to repeat myself, /19s for everyone meeting
registry requirements is probably just fine. Now let's eliminate
globally visible /24s. All of them. ESPECIALLY the historical
stuff in the swamp and toxic waste dump.

BTW, this probably can serve as notice to people that the step
from proxy aggregation of long prefixes to outright lNAT for offenders
is not that far in the future...

Of course, the plus then is that people at the edges can be as sloppy
as they want wrt routing announcements; from the perspective of large
chunks of the topology (peers' and suppliers' networks, for example),
even rather heavily meshed networks could and will appear to be
neatly aggregated into PA address space.

Sean.

P.S.: Those vendors who are crowing about flow-directed shortcuts
for IPv4 would be wise in investing in other flow-directed
technologies, such as lNAT, intrusive web caching and redirection,
and the like. I am fairly confident that the near future will
bring a popular recognition among large transit providers (that
is, your initial market) of the Internet as a services-based network
with congestion avoidance principally performed at the edges, with
unknown spaghetti (odd IP topologies, address and protocol translations
and gatewaying, etc.) in the middle. All this nonsense about
addressing MUST go away, and an ability to stage migrations to
post-IP transport protocol(s) is also very handy. Developing a
mindset wherein IP itself is not necessarily end to end, IP
addresses may change relative to topology, and may change over
time is a really keen way of accomplishing that.