DrPeering -

How do I create a peering policy? 

Does the old phrase “Good artists copy, great artists steal.” apply?

-- Arch Stanton

------

Arch - DrPeering just completed a quick study of 28 Peering Policies. Yes, most clauses in peering policies are similar or identical.  Take a look at the groups of peering policy clauses and select the clauses that are most important to you.  Also take a look at the text used to see how they phrase things.  Finally, take a look at the policies we studies in the list on the bottom of this article.

I think these sample policies will give you a good starting point.

Dr Peering

DrPeering@DrPeering.net

P.S. - It might be fun to create a web app called Frankenstein Peering Policy that allows the user to click and select the clauses and sample text to put into a peering policy.  Right now the copying of text takes way too much time.

Introduction

DrPeering reviewed 28 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.

http://drpeering.net/a/Peering_Rules_of_the_Road_-_A_Brief_Study_of_28_Peering_Policies.html

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.

Findings of the Study

We found generally three groups of Peering Policy clauses:

1. A)Operations,
   

2. B)Technical / Routing / Interconnect,
   

3. C)General
   

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

Operations Clauses

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.

Technical / Routing / Interconnect Clauses

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.

General Clauses

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.

Summary

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.