On Mon, Oct 15, 2001 at 05:26:54PM +0000, E.B. Dreger wrote:
Let's take a simple example. Say that I connect to AS65123 in DFW and AS65456 in Chicago. Assume that both ASen have similar peering with other networks. [...] If I need traffic headed for MSP, it should go through CHI.
Perhaps, but in order to be sure we need to know more. First of all, we need to know who the third network is -- the upstream for the end user in MSP. Let's assume it's AS65535. You've decided on geography alone that it's better to hand MSP-destined traffic to AS65456 in ORD. Do AS65456 and AS6535 even have peering in that area? What if the only two places they peer are on the west and east coasts? You also didn't identify the starting point on your network. Let's assume it's Dallas. You have two choices: 1. You carry the bits from DFW to ORD on your network and hand them to AS65456. AS65456 then carries them to wherever they peer with AS65535 and hand them over for final delivery. 2. You hand off to AS65123 in DFW. AS65123 carries the bits to a location where they peer with AS65535, who takes them the rest of the way. Without any knowledge of the topology, routing policy, backbone capacity, and peering placement and density of the three networks involved, how can you say for sure which option is "better"? I'd be inclined to ask why you're paying AS65123 for service if you can do a better job of carrying bits to MSP than they can, personally.
If I need traffic to go to Houston, it should be routed through Dallas.
Not necessarily. See above. Where is the starting point on your network? If it's Dallas, maybe. But what about from other points on your network?
Furthermore, define "clear understanding".
Clear understanding means: 1. You need to know each providers' backbone. Just because two cities are close together on a map or have fiber between them doesn't mean that they're connected at layer 3. 2. You need to know each provider's routing policy. Just because two networks peer here doesn't mean they won't exchange bits there. 3. You need to know where each provider has peering, and with whom. Just because a provider has a POP in a given city doesn't mean that they peer there. Just because two providers have routers in the same room in the same building in the same city doesn't mean they peer there. If you don't have this information, then what you're doing is guessing based on nothing more than geographical information. If you're going to do that, how granular do you want the data? I don't think city-level is a good idea -- too often you'll make the wrong choice. Regional-level might work, but for what definition of "region"? As a provider, I'd rather hear from my customers that there is a problem so that I can fix the root cause, rather than telling them to hack around it. --Jeff