DrPeering reviewed 28 Internet Peering Policies to examine the language used in peering policies, 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 might this study be interesting? Maybe you want to construct your own Peering Policy and learn from others. Maybe you want to construct a 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 of clauses to see if they should add or change language that deals with issues that other peering policies address well. And for some of us geeky types in the Peering Coordinator community, a few of these clauses are comedy gold.
Can we categorize Internet Peering Policy clauses? To answer this question, we did a brief study of 28 Internet Peering Policies.
We found generally three groups of Peering Policy clauses:
A) Operations clauses,
B) Technical / Routing / Interconnect clauses
C) General clauses.
Each of these groups had several Peering Policy Clauses that we categorized and/or generalized below.
[Editor's note: For on-line versions of this page, you can click on the links to see the actual clauses pulled from the peering policies along with their attribution.]
24/7 NOC - almost everyone (25 of 28) had this requirement but there were many different ways to say it.
Traffic volume requirement clauses were common (20 of 28) but the least similar - some were 95th percentile measures of minimum peering traffic volume, some average measures, some included measurement in monthly traffic volume, and some specified direction. Some had different measures for public and private, some mandated migration to privates once a volume was exceeded.
Interconnect capacity requirements was a popular (19 of 28) requirement one would expect.
Work to fix things clauses stated that both sides will work diligently, sometimes within a specified time frame. (19 of 28 had this clause.)
Interconnect Capacity, Geographic diversity and Peering in all places in common - these came up in some policies. We blended these together and at least 13 of 28 policies had these..
Traffic Ratio requirements were comparatively with only 9 of 28 having them.
Maintenance and Outage Notification and Interactions for network planning and Monitoring/Managing Interconnect (6 of 28) - focus on the interaction between the two companies.
Escalation Path (5 of 28) clauses specify that both peer will share their contact information and describe how and when they will be provided access to engineers to help solve the more difficult peering and routing issues.
Use of IRR - route registration wasn't as common as we expected (6 of 28).
Registration in PeeringDB - only 2 of 28 had this. nLayer does not even suggest using it - surprising, since Richard Steenbergen from nLayer leads the peeringDB project.
Consistent route announcements was a common clause (21 of 28). It was interesting that BBC said "Due to the localised nature of BBC content, we reserve the right to advertise a different set of prefixes at each location." All other clauses were requirements for consistent announcements.
"Hot Potato" or "Shortest-Exit" clauses came up (8 of 28).
MEDs don't seem to be widely used (2 of 28 mentioned them). When they are discussed in Peering Policy clauses, they tend to say that MEDs will be ignored or that they require negotiation.
MD5 was required by only a few: AboveNet, BBC, wbsconnect, and Charter
Don't Abuse Peering - was a popular clause (18 of 28 had some of these clauses). Here we bundled a list of clauses such as no pointing default, static routes, selling, bartering or giving away next hop, leaking routes, etc.
Filtering clauses, Prefix Length minimum clauses came up along wth a minimum number of prefix or ASes to announce clause - these and Single AS (8 of 28) requirements clump together.
Provide us with tools clauses - in some cases the ISP required access to in-network tools to diagnose/check routing.
Can't Be Customer - (18 in 28 had this clause) - 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.
Peering request clauses were very common in peering policies (17 of 28 mentioned how to request peering.) But there was variance here: some added how often you can request peering, and what information needed to be included in peering requests.
Peering may be suspended, terminated, and we can make exceptions at will. In here we also categorized the clauses about "meeting these requirements does not guarantee peering." At least 15 of 28 policies had these clauses.
Paid Peering product was mentioned by 3 of 28 as an alternative for those who could not meet the peering requirements (Comcast, AT&T, Cox, tinet).
Peering in Reciprocal Markets - this clause is new and as a result rare (2 of 28). With this clause, the peer agrees to peer in both foreign and domestic markets. 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 Applicant's home market." (It is common for a Tier 1 in one Internet region to be much more open in a foreign Internet Region. They would deny typically peering in their home market.)
Non-Disclosure Agreements and/or Peering contracts were required by 9 of 28.
This Policy May Change with some notice (10 in 28 had this one).
Financially Viable clauses showed up in 2 of 28 policies.
This brief review of 28 peering policies highlighted a great deal of commonality among policies. One can break down these policies into common groupings, and then further into clauses within the groupings to understand the nature of peering policies.
In some cases the peering policy clauses are identical, in most cases there is some commonality. It seems that many of these peering policies have a common lineage, that is, descended from the same source or from a recognized common issue.
Index of other white papers on peering
WIlliam B. Norton is the author of The Internet Peering Playbook: Connecting to the Core of the Internet, a highly sought after public speaker, and an international recognized expert on Internet Peering. He is currently employed as the Chief Strategy Officer and VP of Business Development for IIX, a peering solutions provider. He also maintains his position as Executive Director for DrPeering.net, a leading Internet Peering portal. With over twenty years of experience in the Internet operations arena, Mr. Norton focuses his attention on sharing his knowledge with the broader community in the form of presentations, Internet white papers, and most recently, in book form.
From 1998-2008, Mr. Norton’s title was Co-Founder and Chief Technical Liaison for Equinix, a global Internet data center and colocation provider. From startup to IPO and until 2008 when the market cap for Equinix was $3.6B, Mr. Norton spent 90% of his time working closely with the peering coordinator community. As an established thought leader, his focus was on building a critical mass of carriers, ISPs and content providers. At the same time, he documented the core values that Internet Peering provides, specifically, the Peering Break-Even Point and Estimating the Value of an Internet Exchange.
To this end, he created the white paper process, identifying interesting and important Internet Peering operations topics, and documenting what he learned from the peering community. He published and presented his research white papers in over 100 international operations and research forums. These activities helped establish the relationships necessary to attract the set of Tier 1 ISPs, Tier 2 ISPs, Cable Companies, and Content Providers necessary for a healthy Internet Exchange Point ecosystem.
Mr. Norton developed the first business plan for the North American Network Operator's Group (NANOG), the Operations forum for the North American Internet. He was chair of NANOG from May 1995 to June 1998 and was elected to the first NANOG Steering Committee post-NANOG revolution.
William B. Norton received his Computer Science degree from State University of New York Potsdam in 1986 and his MBA from the Michigan Business School in 1998.
Read his monthly newsletter: http://Ask.DrPeering.net or e-mail: wbn (at) TheCoreOfTheInter (dot) net
Click here for Industry Leadership and a reference list of public speaking engagements and here for a complete list of authored documents
The Peering White Papers are based on conversations with hundreds of Peering Coordinators and have gone through a validation process involving walking through the papers with hundreds of Peering Coordinators in public and private sessions.
While the price points cited in these papers are volatile and therefore out-of-date almost immediately, the definitions, the concepts and the logic remains valid.
If you have questions or comments, or would like a walk through any of the paper, please feel free to send email to consultants at DrPeering dot net
Please provide us with feedback on this white paper. Did you find it helpful? Were there errors or suggestions? Please tell us what you think using the form below.
Contact us by calling +1.650-614-5135 or sending e-mail to info (at) DrPeering.net
DrPeering.net ©2014 | Privacy Policy | Terms and Conditions | About Us | Contact Us
The 2014 Internet Peering Playbook is now available on the iPad at the Apple Store and for the Amazon Kindle. The Kindle, ePub and PDF form are also perpetually updated on the DrPeering DropBox share.
