NSP ... New Information

Larry Vaden writes...

Does Congress need to pass "must carry" legislation similar to the "any
willing provider" medical legislation? IMHO, it would be better that some
old dogmas and implementations die and be replaced with efficient, robust
code and a rather less limiting view of the future.

Consider the following problem.

Suppose that IP space were not a problem. When IPv6 comes up all around,
it certainly won't be then. You can have and waste all the IP space you
could imagine, since we'll be numbering every atom in the known universe.

And suppose we have ASNs a plenty.

Would Sprint, Digex, and AGIS still be trying to cut out so many routes?

Are any other ISPs doing this filtering?

Phil Howard <phil@charon.milepost.com>

Are any other ISPs doing this filtering?



I know that Erol's was going to, and that Priori will likely, but for
different reasons than you are used to. The primary reason that I have
considered filtering is for protection against AS7007 type problems
affecting my network. I.e. If you deaggregate the entire world and send it
to me, I may be "not listening" to enough of it that I would be safe.

Justin W. Newton
Senior Network Architect
Priori Networks http://www.priori.net
ISP/C, Director at Large http://www.ispc.org

I continue to hear this used as a 'compelling reason' to
urge IPv6 migration, when in reality it appears to be nothing
more than people trying to do an 'end around' the address
allocation policies by thinking that once v6 is deployed,
the allocation policies will dissappear.

Simply because one increases the available amount of address
space does not in any way imply that allocation policies will change
significantly. If they did, and the number of routes increased
significantly, we would have much larger problems in the global
routing system than we would with people whining about not being
able to obtain large enough address allocations.

- paul

DataXchange is not filtering by prefix, we do occasionally filter out
someone who is ping bombing or something, or a cyberpromo site. My routers
seem to be able to handle the full table. How many entries are removed by
this prefix filtering anyway? Does anyone have a handle on that? Looking
at the weekly automated report of the possible gains by aggregating, it
apprears to me that a concerted effort by a dozen or so of the top names
could reduce the number of table rows by a considerable amount.

Best Regards,
Robert Laughlin

Erols will be doing so.


Well, um, er... it wasn't going to be this long but I got
  started, and then put some math in it (I'm sorry, I know
  math is hardly operational) and then some history.

  Hit "D" now if your brain is mush.


Phil Howard wrote...

Suppose TCP/IP had been designed from the beginning with 64-bits of flat
address space divided 32/32. We would not have the space crunch at all

Actually I beg to differ. IP was designed to handle a variety of network
sizes, and to automatically infer the size of the network from the number
of contiguous set bits in the first octet. You can skip most of the next
two paragraph but read the line in the ***'s...

DECnet, to contrast, was originally designed for 4-bit addressing. "After
all, Nobody could afford more than 16 machines." Eventually DEC realized
the error of their ways and upgraded to 8-bit addressing. "After
all, Nobody could afford more than 256 machines." But WANs were becoming
popular, and SPAN (discussed elsewhere, precursor to NSI) wanted to do it,
and HEPNET (discussed elsewhere) wanted to do it.

This resulted in DECnet V4, 16 bits of address space broken 6/10 into
"Areas" of "nodes." Worked great for small private networks, badly for
larger networks. Large internetworks were impossible as only 64 "areas"
could exist. *** This shortsighted design spec required workarounds
("hidden areas", "poor man's routing") which REQUIRED that the USER
know and specify the ROUTE from END TO END. ***

IP provided a solution where (suprise, surprise) routing was handled at
L3 and was oblivious to the user. It isn't until now, when most users
are "used to unreliable service" that traceroute has become a popular
end-user tool. If users expected their cars to be as reliable as the
cheap-ass $20/mo Internet Providers, there would be no warranty business
for GM, but let me jump back off this soapbox, as I digress.

Anyway, IP has the strong point that network sizing is (now) a dynamic
entity, so that a network (set of contiguous address space) is sized to
the needs of the organization. The whole set of networks is limited to
N bits (32 now, 64 under IPv6), but the masking is not fixed.

I don't take issue with "It's too bad IP wasn't designed 64..." but
rather that "32/32" is the end-all. I think 2^32 network spaces SOUNDS
enough now, but pre-allocates obscene parts of the address space for
no reason. Well, ok, to conserve routing entries. However, when you
consider that we now have ~45K routes, o(45K) is five orders of magnitude
off from o(4E9). It behooves us not to "make it easier" on the router
by limiting it to 4E9 entries since the problem is already "outside a
known technological solution today." (Well, with L3 anyway.)

Recall that in 1982 memory was not cheap. IBM had introduced the PC
the year before with 256K, upgradable to 640K. Memory was about $500/k
and addressing was 16 bits, minis to 32, Crays to 64. In the 80's the
NSFNET NSS could originally only handle one ASN announcing a route,
then eventually upgraded to 4... These were memory and processing

A table of 2^32 8-octet entries (4GB) is something that BACK THEN
was inconceivable for memory storage. Today we consider that it
would be possible to size the table at
2^32 entries of destination, gateway, netlength(mask), flag?
                8 octets 4x8 octets 1 octet

2^32 x 40 = 1.6E11 Bytes of table space. If you take the Cisco approach
to store this in multiple ways so you can fast-cache access to the
routes vs a sequential search, it appears to take 5x storage, or
8E11GB. Add the router code, and we're talking a box with a terrabyte
of RAM. That's a tad more than today's boxes.

Now contrast this with 64/? variable networks.
2^64 entries of 40 octets =~ 6E20 Bytes.

The technological difference between today's high-availability processors
and either of those two goals are so vast that "trying to save on space..."
wins nothing until we know what our real goalpost is.

If we hit IPv6 Implementation Year and Yer Average Router can only handle
2E10Bytes, someone's gonna say "29/35?". That would be the time to
haggle bits :wink:

Well, back to sleep.