Scaling ARIN proposal for small ISPs - and economic reality

[Dennis Ferguson]

> -- [ From: David Hakala * EMC.Ver #2.5.02 ] --
>
> > The issue is the amount of explicit route entries that the present
> > generation of routers can handle.
>
> I grok the issue, Jeremiah. I researched Sprint's blocking policy and the
> related route flapping issues rather thoroughly when I edited Boardwatch
> Magazine.
>
> But that's a temporary technical problem - "the current generation of
> routers" will yield to new technology. You can't perpetuate a nonprofit
> organization with a transient purpose - and *every* organization seeks to
> perpetuate itself.

No, the size of the IPv4 unicast routing table is a `forever' problem.  If
you didn't learn this from your research then you may not have grok'd the
issue as well as you thought.

I have no doubt that it is possible to build routers which can handle tables
which are one or two orders of magnitude larger than we have now, but I also
have no doubt that it is impossible to build routers where the size of the
forwarding table that can be supported is infinite.  That is, you can
replace a one pound sack with a 20 pound sack, but you're not going to
get 200 pounds of potatoes in either of them.  And while you may find
that 19 pounds of IPv4 unicast routes is perfectly adequate for your
purposes, the consumption of your entire routing and forwarding path
with IPv4 unicast routing information comes only at the expense of not
being able to do other things which need to share the same resources.

For example, if you fill your routers with IPv4 unicast routes you won't
be able to deploy IPv6 simultaneously.  Which means there'll never be a
transition to IPv6 since the only possible strategy for this is to provide
support for both.

Or, if you stress your routing to the max with IPv4 unicast routes you
won't ever be able to deploy a hot-routing, big forwarding path function
such as IP multicast (or, more likely, the only places which will be allowed
to originate multicasts will be big companies which pay big bucks to push
ads into your browser).

Or, if your forwarding path is cluttered with hoards of IPv4 unicast routes,
you'll never be able to deploy such forwarding-state-intensive functionality
as that needed to support RSVP.

Of course one may have no interest in any of the above, and hence may feel
perfectly free to consume the entire box (no matter how large) with IPv4
unicast routes anyway.  The trouble is that if one does this then one also
consumes the same resources in all one's competitors' routers, effectively
preventing them from ever doing any of the above as well.  Since one's
competitors may have different priorities than you do they may be unhappy
if you do this, and have no particular reason to allow you to do this.

Even ignoring all of this, however, the fact is that even a 20 pound sack
is still a lot easier to carry if you only put a pound or two of potatoes
in there.  If you keep the routing load smaller your boxes will respond to
failures faster, and deal with problems better, and just in general exhibit
better stability, no matter what their maximum rated carrying capacity might
be.  Fewer routes means better networks, pretty much independent of
technology.

So, while the technology will get better, there is no technological
`silver bullet' which will fix the routing problem.  Smaller will always
be better, and I suspect there will never be a (technological) reason to
radically loosen current allocation policies.

Dennis Ferguson