How do ISPs create a peering policy?
"DrPeering
How do ISPs create a peering policy?
Does the old phrase "Good artists copy, great artists steal" apply?
-- Arch Stanton"
***
Arch - DrPeering just completed a study on this very thing. I think you will find it addresses your question.
A Brief Study of 28 Peering Policies
Introduction
DrPeering reviewed 28 peering policies to examine the language used in peering policies, and to see if one could categorize common peering policy clauses. As it turns out, many of the peering policy clauses were very similar if not identical. We placed these clauses into categories, each with their own web page so the community can compare the wording of their favorite peering policy clauses.
Why is this study interesting? Maybe you want to construct your own Frankenstein of peering policies - and based on the results of this study, you would not be the first. Peering Coordinators may want to peruse these lists to see if they should add language that deals with issues that other peering policies address. And for some of us geeky types in the Peering Coordinator community, a few of these clauses are comedy gold.
Findings of the Study
We found generally four high level categories of Peering Requirement clauses: Operations, Technical/Routing/Interconnect, General, and what we think should be its own category called “Don't Abuse Peering,” so well highlight some findings in each category.
OPERATIONS Clauses
- Almost everyone had a requirement for a 24/7 NOC - but there were many different ways to say it.
- Only a couple companies required registration in PeeringDB - and surprisingly, nLayer does not even suggest using it.
- Many had some form of interconnect capacity requirements as one would expect.
- The Traffic volume requirement clauses were the least similar - some were 95th percentile, some average, some measured in volume, some specified direction.
- The "We both will Work to fix things" clauses were popular.
- Almost everyone has some form of will deal with Spam/UCE, so the Internet Spam problem must be very close to be solved. (smiley face)
TECHNICAL/ROUTING/INTERCONNECT Clauses
- Consistent route announcements was a common clause with one outlier - BBC Due to the localised nature of BBC content, we reserve the right to advertise a different set of prefixes at each location.
- Mandating Hot Potato or Shortest-Exit was common.
- MEDs dont seem to be widely used - when they show up in peering policies they are usually either removed from announcements or require negotiation.
- Only a few networks required MD5: AboveNet, BBC, wbsconnect, and Charter.
GENERAL Clauses
Only about half of the Peering Policies had a date on the page.
- Almost everyone had a clause describing where to send the peering request, but there was variance here: some added how often you can request peering, and what information to include in peering requests.
- Here is a very common peering requirement: "You Can't Be Customer;" in some cases you can't have been a customer for some period of time, and in some cases the policy states that you can't be a customer of a customer or of a peer.
- Several companies are using their Peering Policy is a place for offering their Paid Peering product (Comcast, AT&T, Cox, tinet).
- DrPeering wonders if Comcast has International desires with their “Comcast requires that Applicants seeking SFI in the United States agree to provide reciprocal SFI arrangement with Comcast in the Applicants home market” clause.
DON’T ABUSE PEERING Clauses
- There are enough specific types of Peering Abuse that it may be worth having a category called “Don't Abuse Peering” in peering policies.
Redundancy has a Common Clause:
Peer must operate a fully redundant network capable of handling a single-node outage in each network without significantly affecting the traffic being exchanged. – LambdaNet
Each Network must operate a network with sufficient redundancy and capacity that the failure of a single node will not significantly affect performance. – AboveNet
Each Internet Network must operate a fully redundant network, capable of handling a simultaneous single-node outage in each network without significantly affecting the performance of the traffic being exchanged. – Verizon
Applicant must operate a fully redundant network capable of handling a single-node outage in each network without significantly affecting the traffic being exchanged. – ATDN
Where did this clause come from and what is this single-node outage? DrPeering is guessing that this means that no single node on either network can go out and adversely affect peering.
Peering Policy Awards
Most Comprehensive Peering Policy
Badly Grammar and Mispelling Award –Three Way Tie:
“Only send us traffic that destined for the prefixes we announce to you.”
“Agreements for best-exist or other forms of traffic exchange can be made in email.”
“Violation of these terms may result in immediate de-peering and other attention-getting mechanism.”
(DrPeering is imagining bunny on the stove.)
Honorable mention to the MSOs CableVision and Comcast:
”Potential peer must be able to demonstrate usage history with an aggregate peak average usage rate greater than 70 Megabits/s or sustain an average of 4.32 Terabits/day; bi-directionally. Whichever is applicable.”
”Applicants will be responded to within a reasonable timeframe to discuss their request.”
This last one is only slightly different from the better language of AT&Ts Peering policy from which it was most likely derived:
”Potential peers will be contacted within a reasonable timeframe to discuss their requests.” – AT&T
Ugliest Peering Policy:
With no categories at all and in typewriter font, the RCN policy surpasses all others in jumbling occasionally unrelated text in a form only an ADM-3A dumb terminal could love.
Outlier Peering Policy:
Comments
Post new comment