Request for Comments on a topological address block for N. Calif.

Mon Sep 25 16:55:14 UTC 1995

    From: George Herbert <gherbert at crl.com>

    You broke my critical assumption, which is that we're going to draw the
    "39/8" boundary around northern california.

Exactly!

The whole point of geographic addressing (which is what you're proposing,
effectively) is that it assumes that stuff which is inside a given geographic
entity, and addressed as such, is fully interconnected when it comes to the
'net's actual connectivity. I.e. you can draw a boundary around a contiguous
chunk of the network, and have that boundary contain everything that's in a
geographic area. Break that assumption, and all of a sudden things don't work
so well anymore.

Look, we have two choices: we can make the addressing follow the 'net's
topology, or we can make the 'net's topology follow the addressing. They
*have* to be connected, *we* only get to chose which comes first.

Making the addresses follow the topology means that we have a lot more
flexibility to make the connectivity respond to traffic patterns, policy
demands, etc, etc; the addresses then trail along behind. If the topology has
to follow the addressing, you *can't* have the topology be completely free to
respond to user's needs.

To me, this choice is a no-brainer.

    The right solution may not be this, it may end up being ... allocate
    larger blocks to backbone providers, and having backbone providers not
    fuss too much about small to midlevel ISPs going multihomed, and having
    backbone providers allocate space for growth for small to midlevel ISPs.
    But, at this point, that's not happening either.

Well, the Right Solution to a lot of these problems (but not renumbering of
routing-names as the topology changes, that will always be with us) is
variable length routing-names which grow from the bottom up, but that solution
isn't available in the system we have now. So, let's look at what we do have.

Within those limits, your proposal above sounds like a good start, although
perhaps there are problems that ithers with more operational experience than
I can see. If not, how can we make it happen?

	Noel