On Mon, 29 Apr 1996, M. Christopher Davies wrote:
On Mon, 29 Apr 1996, Nathan Stratton wrote:
(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
On Mon, 29 Apr 1996, Ali Marashi wrote: 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 often)
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. // mdz@netrail.net sales@netrail.net // (703) 524-4800 [voice] (703) 524-4802 [data] (703) 534-5033 [fax]