🚀 go-pugleaf

Technically you're right that there is no difference between ISO and
IP as to the relationship between addresses and routing.  But
practically there is.  While IP may not specify an official routing
strategy based on addresses, there is a de facto one, and given the
addressing structure, it's hard to see any practical alternative.  We
have basically two-level hierarchical routes, with a table indexed by
network number doing routing between institutions and a table indexed
by subnet doing routing within institutions.  The network number
allocation procedures guarantee that there isn't any more structure in
the network numbers that we could use.  ISO has the possibility of
more structure.  It allows longer addresses, and it allows for
multiple address allocation authorities.  This allows for more levels
of hierarchy, and it supplies a builtin top level to the hierarchy
(authority responsible for the address format) that is not present in
IP.  Thus in theory we can hope that gateways won't have to have
routing tables that list the entire world.  There is a cost for this,
however, which is that addresses are harder to parse, and that the
structure we are trying to use for routing is different for different
addresses.  I don't think we'll know which approach is better for a
number of years.  Basically I expect the Internet to develop routing
technology that uses knowledge outside the address.  Until we get the
equivalent of the Internet using ISO technology, we simply won't know
whether the flexibility inherent in the ISO addresses is worth the
overhead of handling variable address formats.

There are several different ways of getting past the current Internet
routing problem.  (The problem being that at the moment every gateway
has to compute routes to every network in the Internet.)  The most
promising seem to involve additional routing technology other than
the conventional IP route table.  The following is a straw man that
has the same flavor as what seems to be floating around in the IP
community.  Suppose we no longer keep a complete routing table,
i.e. one that lists every possible network.  Instead we have several
levels of hierarchy.  E.g. the world is divided into USnet, Euronet,
and Japannet.  We don't care about routing within Euronet and
Japannet.  USnet is divided into NSFnet, NASAnet, and ARPAnet.
We are a member of NSFnet, so we don't bother to keep track of the
others.  etc.  The routing table at Rutgers looks sort of like
this:

   Euronet -> jvnc-euro-gw
   Japannet -> sri-japan-gw
   NASAnet -> ames-nasa-gw
   ARPAnet -> mills-1200baud-fuzzball-link
   nsfnet -> jvnc-nsfnet-gw  [default used for NSFnet nets we don't know]
   nysernet -> columbia-gw

In addition to this we have a conventional routing table based on
specific network numbers.  But that's just a cache.  When we get a
packet, we look for its network number in the conventional routing
table.  If it's there, we route it.  Otherwise, we go through the
routing equivalent of the domain name system.  If the root route
server tells us that the network in question is part of euronet, we
stop there and just send it to a European gateway.  If it's part of
USnet, we ask the USnet route server for more information, etc.  What
gets circulated in routing updates within NSFnet is then routes for
these higher-level entities, not for specific networks.  The current
NSFnet backbone routing is in effect a one-level version of this, with
fixed tables giving the membership of various networks in the
higher-level entities, rather than using route servers.

This sort of scheme, or various other similar suggestions, uses "route
servers" as an alternative to additional structure in the addresses.
My guess is that in the long run depending entirely upon address
structure is going to turn out not to be enough, and we're going to
have to go to a scheme like this.  But we probably won't know for sure
what the right tradeoffs are until 10 years of so from now, when we
have very large international networks that use routing technology
more complex than the current IP technology.