Hello,
Newbie question, what criteria do you look for when you decide that you want to peer with someone or if you will accept peering with someone from an ISP point of view.
Thanks.
1) Are they present an IX where I am present?
2) Can they configure BGP correctly?
3) … Beer?
Private interconnect requires actual thinking. Putting a procedure in around public peering is just overhead we don’t need.
Also worth looking at your telemetries to see if it makes sense from an inbound/outbound point of view.
That is, you'll get more bang for your buck if you're eyeballs and peering with a content provider (or vice versa), as opposed to eyeballs <-> eyeballs or content <-> content.
I assume you mean "reciprocal peering" in the sense of shortcut from your
customers to their customers rather than the more generic sense that any
BGP neighbor is a "peer".
1. What does it cost? If you and they are already on an IX peering switch
or you're both at a relaxed location where running another cable carries no
monthly fee, there's not much down side.
2. Is the improvement to your service worth the cost? It's not worth buying
a data circuit or cross-connect to support a 100kbps trickle.
3. Do you have the technical acumen to stay on top of it? Some kinds of
breakage in the peering link could jam traffic between your customers and
theirs. If you're not able to notice and respond, you'd be better off
sending the traffic up to your ISPs and letting them worry about it.
If the three of those add up to "yes" instead of "no" then peering may be
smart.
Regards,
Bill Herrin
* bryan@shout.net (Bryan Holloway) [Tue 11 Jul 2017, 19:28 CEST]:
Also worth looking at your telemetries to see if it makes sense from an inbound/outbound point of view.
That is, you'll get more bang for your buck if you're eyeballs and peering with a content provider (or vice versa), as opposed to eyeballs <-> eyeballs or content <-> content.
Luckily these are not exclusionary so you can peer with all networks present at an Internet exchange with no repercussions.
-- Niels.
There is one more thing to consider based on your app or content latency
criteria needs. Do you provide a service that performs better with low
latency - such as live desktop, live video/voice. You may wish to peer to
have more control and more direct path to your customer base. If you
identify your customer base in a specific region - then explore the best
peering exchange points to utilize in that region. This can help you
reduce your packet hop count/ deliver time, etc. etc..
Thank You
Bob Evans
CTO
Considering the wording you use, I would include this,
'Peering' is not always necessary. If you can get an upstream provider to give you a pack of IP's and it is sufficient to just use them as a gateway instead of setting up peering that would be preferred.
If you decide you want to have multiple upstream providers or hit some kind of speed cap is when I would probably peer with someone else. So that you can keep your IP space but share it across a redundant connection from a different provider.
Then you need to decide if you want to be a hop between those two peers or if you want them to serve you only. You can change your routing so that both providers know of your routes but you are not sharing routes between the two providers.
BGP is an enormous protocol and extremely scalable so there is alot to consider before you even decide if you want to peer.
Because it can sometimes be a headache to setup.
craig washington wrote:
Newbie question, what criteria do you look for when you decide that
you want to peer with someone or if you will accept peering with
someone from an ISP point of view.
If you're new to the game, peer with everyone you can and use route
servers aggressively. You have nothing to lose and everything to gain.
At the point at which you have a medium sized network, in the sense of
maintaining multiple peering points, PNIs, transit customers, and tens
to hundreds of gigs of traffic (i.e. the stage at which you actually
have to think a bit about your traffic routing policies), you might want
to consider whether it's worth your while peering with smaller players
and also whether whether route servers are still a good fit for your
business requirements.
If you are very large, the rules are completely different and will
depend entirely on your business model. Some organisations thrive on
open interconnection models; others prefer to be highly selective.
Nick
Then you need to decide if you want to be a hop between those two peers or if you want them to serve you only. You can change your routing so that both providers know of your routes but you are not sharing routes between the two providers.
The definition of “peering” to most ISPs would definitely not include becoming a “hop” between two peers. Most networks would de-peer you if you sent their prefixes to another peer.
Hi Patrick,
I'm given to understand this practice is common in service providers
connecting academia. Three or more service providers serving schools will
agree to pass packets even if neither school terminates at the current ISP.
This comes up in the discussion of "valley free" inter-domain routing
because it's one of the cases that forms a valley where the participating
organization is not paid for or directly donating the transiting packets.
Regards,
Bill Herrin
Patrick W. Gilmore wrote:
1) Are they present an IX where I am present?
2) Can they configure BGP correctly?
3) … Beer?
Naah, way overthought. I prefer the traditional:
1) do they have a pulse?
Nick
4 ) are they in PeeringDB and keep their entry up to date? (especially the contact information)
cheers,
Wolfgang
I would state that peering gives more control over the traffic you handle
(since it is not going over someone else's network). Every hop is a
possible problem to your operations, I guess.
David
* craig washington
Newbie question, what criteria do you look for when you decide that
you want to peer with someone or if you will accept peering with
someone from an ISP point of view.
Routing hygiene. I expect the would-be peer to keep the number of
advertised routes that are either 1) not registered in RIPE/RADB, 2)
disaggregated, or 3) redundant (i.e., more-specifics of larger
advertisements) to an absolute minimum.
Tore
Is your AS registered with ARIN?2 byte or 4 byte ASN number?How many devices are you peering with?Dual homed, multi homed?Bandwidth?Type of traffic?
There are alot more...
Regards,Cyrus Ramirez
I would state that peering gives more control over the traffic you handle
(since it is not going over someone else's network). Every hop is a
possible problem to your operations, I guess.
David
You didn't say what kind of 'peering'. That could mean over an IXP or to be
directly connected. You do not need to be a member of an IX to peer.
There are at least three types of criteria to evaluate. Technical, business
and legal. Take a look here for a few ideas on technical and business
criteria:
"Me too" with the rest of the thread. If peering serves your mutual
interests (or just yours even), its an easy decision.
The Dr Peering http://drpeering.net/ website is also a resource for folks
new to peering.
Best Regards,
-M<
Speaking as a small ISP with 10 to 20 Gbps peak traffic. We are heavy
inbound as a pure eyeball network.
We use the route servers. We only maintain direct BGP sessions with a few
large peers. Think Google, Netflix, Akamai etc.
The reason for this is simply administrative overhead. Every BGP session
has to be configured and monitored. We know that it will not move a large
percentage of our traffic. We simply do not have the ressources currently
when the gain is so little.
Anyone who wants to pass traffic efficiently to us can either use the route
server or they can peer with Hurricane Electric. The later option will get
the traffic to us almost as efficiently as peering directly with us. In
this sense we outsourced the peering to them.
Regards
Baldur
Okay I will just throw this, in addition to what the others have said. From an ISP point of view, assuming the neighbor is able to provision their end of the cross-connect, you need to check the common POP cost requirements, and also consider if the neighbor is willing to either pay for the peering or provide a mutual benefit.
Payment is straight forward. Mutual benefit will depend on what you desire from the neighbor-ship; secure IPv6, Transit services, latency and capacity thresholds, route and path attribute requirements, responsiveness to collaboration over issues (abuse, outages, and instability), internetwork politics, and other BGP controls.
Opeyemi Olomola
Awesome!
Thanks for all of the feedback.
I am going through the links you sent me and I think they will be of very good help.
I guess it was a general question but that was kinda the point, get feed back from all the pro's 
thank you very much again.
If you develop a well tuned process for creating BGP sessions and even a moderate
system for monitoring not the individual sessions, but meaningful traffic events on
your network, then, maintaining a large number of peers and a promiscuous peering
policy is not such a daunting process.
As a general rule, promiscuous peering improves efficiency and keeps your options for
traffic delivery open. Restrictive peering generally has the opposite effect.
Route servers are a lazy form of promiscuous peering, with an attendant fate sharing
which can produce suboptimal results. YMMV.
I’ve worked for several networks of various sizes and observed the industry in general
for many years. As a general rule, a restrictive peering policy is a great way to lose
momentum in the market and convert a major ISP into a bit-player (e.g. SPRINT), whereas
promiscuous peering can be a key component in moving a trivial ISP into a major player
in the industry (e.g. HE).
Again, YMMV.
Owen