Communities

Jeff Aitken jaitken at aitken.com
Mon Oct 15 20:22:09 UTC 2001


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




More information about the NANOG mailing list