Re: Peering Policies and Route Servers

[Matt Zimmerman <mdz () netrail net>]

On Mon, 29 Apr 1996, M. Christopher Davies wrote:

> On Mon, 29 Apr 1996, Nathan Stratton wrote:
> > On Mon, 29 Apr 1996, Ali Marashi 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
> > 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]