Re: Request for Comments on a topological address block for N. Calif.
From: George Herbert <gherbert@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
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.
Well, if we use a concept of dynamic communities, by using tools to constantly analyze 'show ip bgp' outputs, and compare against existing community strucutures, I think we can built a distribution filter that can isolate specific routes to where they need to be, providing only a very minimum of free transit to various providers. It encompasses a combination of geographic and provider based addressing, and would float between the two as migrations occur (probably on a weekly basis). I'm working on such a thing now. Don't know when I'll have a proposal finished, though. -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP."
participants (2)
-
Dave Siegel
-
jnc@ginger.lcs.mit.edu