> > (2) Could anyone share opinions/facts regarding why organizations may or
> > may not exchange routes via the Route Servers rather than direct peering
> > relationships at the NAPs?
> Well, because say that Sprint and MCI would peer, a provider would only
> just stay at one NAP. That provider could then sell large dedicated
> connections and in a way do it on Sprint's and MCI's network. I think they
> they are trying to keep a lot of startups like me from growing and being a
> large competitor.
I think you've completely missed the boat on 1) what it means to peer,
and 2) why one would peer with you.
The idea (and I may be wrong here) that the big 6 may or may not choose
to peer with you is because they have no contract to provide TRANSIT for
your packets, but will gladly accept your packets for MCI or Sprint
connected sites. The idea behind peering is that it is a shared dropoff
point, but not a free transit to wherever on the net you want to go.
This has very little to do with peering...I know of no NSP's who are
offering transit service via peering at exchange points. The fact is, not
everyone is "gladly" offering routes to their customers. I won't go into
the various technical, economic and political reasons why.
If you peer, it is expected that you will not utilize MCI's (as an
example) network to talk to a non-MCI connected site on the other side of
the country just because you don't have a link at Mae-West. As a result
you wouldn't need any expensive circuits to build your network and you
could 'take' service from your competitors to deliver your packets.
Peering means sharing, not taking advantage of or using of someone else's
service or backbone to make a profit (although this does happen all too
True enough. And if the software side of the peering arrangement is
configured correctly, this will not happen.
Number two, what benefit is it to MCI to peer with you since you
obviously want to rest on the backbones of the other providers and try
and not pay a network provider good money to build a backbone that you
don't have to manage? What traffic do you generate that would benefit
MCI from peering with you?
"Rest on the backbones of the other providers"? Hardly. Is it wrong to
use NSP X's backbone to reach customers of NSP X? This makes for a very
sketchy moral model of Internet operations. Is there really a question of
"benefit" here? Peering can only increase connectivity, not hinder it.
Setting aside the technological barriers to such an arrangement, an
optimal configuration would be one in which all routing entities peer with
one another at all available locations, so as to provide the shortest path
between routing communities. Assuming the peer knows the best route to
all destinations within its AS, it's a good bet that fewer miles and/or
hops are involved via a near exchange than via a distant one.
If NSP Y peers with NSP Z at MAE-East and MAE-West, and one of its
east-coast customers wants to reach a west-coast customer of NSP Z, whose
responsibility is it to backhaul the traffic to the opposite coast? What
about in the opposite direction? There's a lot of closest-exit routing
going on these days.
Making a comment that the big 6 are restraining trade certainly won't win
you points with the people you're trying to get peering arrangements with.
Work cooperatively, not adversarily to get your peering arrangements. And
have a good reason for the big 6 to want to peer with you other than, 'I
want cheaper transit'
Transit is the use of a provider's backbone and peering arrangements to
reach "distant" neighbors (those outside of said provider's community).
Peering, in the traditional sense, will not accomplish this goal.
When you build a redundant, coast to coast network, will you deliver my
packets for free? I didn't think so.
Unless you decide to run connections to all of my customers or points of
presence, I don't think that can be avoided. Do any of our current peers
pay for the privilege of exchanging data without customers?
// Matt Zimmerman Chief of System Management NetRail, Inc.
// email@example.com firstname.lastname@example.org
// (703) 524-4800 [voice] (703) 524-4802 [data] (703) 534-5033 [fax]