Peering Policies and Route Servers

Mailman List Mirror (Read Only)
1

I had a few questions to direct to the group at large that I believe are
of a "network operational" nature.

(1) I have heard that Sprint and MCI currently require an organization to
peer with them at a minimum of three exchange points, where one must be on
a different coast. I have been unable to confirm this directly from the
sources yet. Would anyone care to share what knowledge they have on the
subject? Are any other large providers (e.g., ANS) adhering to similar
policies? As Internet traffic increases across the large backbones, could
this be a trend that continues with other providers?

(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?

Thank you for any information/enlightenment.
Ali....

2

I had a few questions to direct to the group at large that I believe are
of a "network operational" nature.

(1) I have heard that Sprint and MCI currently require an organization to
peer with them at a minimum of three exchange points, where one must be on
a different coast. I have been unable to confirm this directly from the
sources yet. Would anyone care to share what knowledge they have on the
subject? Are any other large providers (e.g., ANS) adhering to similar
policies? As Internet traffic increases across the large backbones, could
this be a trend that continues with other providers?

Yep, and yes I think it will continue.

(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 that if a provider only wants to peer at one point, that MCI and
Sprint should not peer, but I think that if a provider lays out a network
plan and works to say get a 2 more NAPs in say 6 months that they should
peer.

Nathan Stratton CEO, NetRail, Inc. Tracking the future today!

3

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.

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)

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?

That, I believe, is the reason that people don't peer as readily as you
want them to.

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'

When you build a redundant, coast to coast network, will you deliver my
packets for free? I didn't think so.

(*back into the deep*)

4

I think that you will find it much easier to get Sprint, MCI et al. to
peer with you at multiple NAP's if you have a reputation and that
reputation is a good one. The people at the large NSP's are rightly
conservative at making new peering decisions because the network is now so
big and so important to customers that they cannot risk significant
network failure.

If you want to peer, you will have to prove that your actions will not
endanger the network fabric especially the fabric of the NSP who you
are negotiating peering with. This is not an unsolvable problem.

The first step is to develop technical competence in your staff. This is
more than just reading manuals although it would help to have large
portions of Cisco's manuals committed to memory. It also requires you to
actually operate a complex network fabric of your own for a long enough
period of time for the learned theory to become understood reality. Part
of this effort should include familiarising yourself with much of the
leading edge research found in RFC's and other documents published by
various RFC authors and researchers. Some of this is at ra.net, merit.edu,
nlanr.net and so on.

In addition you have to develop a reputation of competence and this
demands that you physically attend several NANOG meetings and perhaps some
IETF's. There is nothing that can establish a reputation better than
personal contact. Of course, once you become a face and not just an email
address, even the "no" responses to a peering request are likely to lead
to some more explanation of "why?" so that you can remedy the situation.

The time required to go through these rites of passage will also allow you
to get your national network infrastructure built out so it is not a loss.
You *CAN* operate a national (or even international) network without
peering agreements. You *CAN* grow into being an NSP. You may even
discover that there are some benefits to multiple bilateral
peering/exchange points as opposed to becoming yet another NSP at an
octopus-like NAP.

Of course, the above is only my HUMBLE opinion, your mileage may vary :slight_smile:

Michael Dillon Voice: +1-604-546-8022
Memra Software Inc. Fax: +1-604-546-3049
http://www.memra.com E-mail: michael@memra.com

5

> > (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.

No I think you are vary wrong, I know what it is to peer, and I am not
askign for TRANSIT. Sprint and MCi will nto PEER unless you are at 3 NAPS.

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

No kiding.

That, I believe, is the reason that people don't peer as readily as you
want them to.

You have no idea.

Nathan Stratton CEO, NetRail, Inc. Tracking the future today!

6

I think that you will find it much easier to get Sprint, MCI et al. to
peer with you at multiple NAP's if you have a reputation and that
reputation is a good one. The people at the large NSP's are rightly
conservative at making new peering decisions because the network is now so
big and so important to customers that they cannot risk significant
network failure.

I don't think so show me a ISP that has setup peering with sprint this
year, and is only at one NAP.

If you want to peer, you will have to prove that your actions will not
endanger the network fabric especially the fabric of the NSP who you
are negotiating peering with. This is not an unsolvable problem.

That is how it is will a lot of people still, but is not the case with
sprint and MCI.

The first step is to develop technical competence in your staff. This is
more than just reading manuals although it would help to have large
portions of Cisco's manuals committed to memory. It also requires you to
actually operate a complex network fabric of your own for a long enough
period of time for the learned theory to become understood reality. Part
of this effort should include familiarising yourself with much of the
leading edge research found in RFC's and other documents published by
various RFC authors and researchers. Some of this is at ra.net, merit.edu,
nlanr.net and so on.

In addition you have to develop a reputation of competence and this
demands that you physically attend several NANOG meetings and perhaps some
IETF's. There is nothing that can establish a reputation better than
personal contact. Of course, once you become a face and not just an email
address, even the "no" responses to a peering request are likely to lead
to some more explanation of "why?" so that you can remedy the situation.

The time required to go through these rites of passage will also allow you
to get your national network infrastructure built out so it is not a loss.
You *CAN* operate a national (or even international) network without
peering agreements. You *CAN* grow into being an NSP. You may even
discover that there are some benefits to multiple bilateral
peering/exchange points as opposed to becoming yet another NSP at an
octopus-like NAP.

Of course, the above is only my HUMBLE opinion, your mileage may vary :slight_smile:

Well, I think that is how it should work, and that is what I look for
before I connect peers, but this is not what Sprint or MCI and more and
more providers are starting to do.

Nathan Stratton CEO, NetRail, Inc. Tracking the future today!

7

> > (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]

8

I think that you will find it much easier to get Sprint, MCI et al. to
peer with you at multiple NAP's if you have a reputation and that
reputation is a good one. The people at the large NSP's are rightly
conservative at making new peering decisions because the network is now so
big and so important to customers that they cannot risk significant
network failure.

If you want to peer, you will have to prove that your actions will not
endanger the network fabric especially the fabric of the NSP who you
are negotiating peering with. This is not an unsolvable problem.

There is no question of the risk involved in peering. Since caution is
most often the best way to approach risk, it needs no justification
either. What is being debated is whether or not the emerging policies of
large NSPs reflect this approach. I would have no objection to a
requirement of proof...it's requirements of money and resources that have
small corporations complaining.

[technical competence]
[networking experience]
[familiarity with current events]

In addition you have to develop a reputation of competence and this
demands that you physically attend several NANOG meetings and perhaps some
IETF's. There is nothing that can establish a reputation better than
personal contact. Of course, once you become a face and not just an email
address, even the "no" responses to a peering request are likely to lead
to some more explanation of "why?" so that you can remedy the situation.

These are all valuable resources in running an NSP...these are, in fact,
several of our goals here. Certainly some (most notably personal
appearances) are limited by available resources, but all are necessary to
some extent.

However...

- Is a small staff necessarily an incompetent one?
- Is a company which has operated on a small scale necessarily doomed to
  failure in a large scale endeavor?
- Does a scarcity of resources necessarily indicate an inability to
  efficiently utilize available resources?

These all seem to be generalizations made by peering policies which
discriminate against smaller providers. Meeting Sprint and MCI's peering
conditions requires only minimal competence. What it takes is money.

The time required to go through these rites of passage will also allow you
to get your national network infrastructure built out so it is not a loss.
You *CAN* operate a national (or even international) network without
peering agreements. You *CAN* grow into being an NSP. You may even
discover that there are some benefits to multiple bilateral
peering/exchange points as opposed to becoming yet another NSP at an
octopus-like NAP.

For the record, I fully realize the value of peering at multiple exchange
points. :slight_smile: Though it seems to have been interpreted as such, my crusade
is not to win peering arrangements at a NAP. My whining serves the far
larger (and more interesting) purpose of pointing out the arguable wisdom
of certain policies (which just happen to be detrimental to the pursuit of
my goals).

// 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]