A Study of 28 Peering Policies

The following are snippets of Peering Policy Clauses found in the Peering Rules of the Road - A Study of 28 Peering Policies study. Clauses were categorized and put into rough categories for comparison.

Do Not Abuse Peering Policy Clause

Peers must not utilize any form of gateway of last resort or default route that is directed at Speakeasy. – SpeakEasy

Only send us traffic that destined for the prefixes we announce to you. Do not point default at us or use static routes to send us traffic that does not match the routes we announce to you. – Hurricane Electric

2.6. Neither Network shall point default into or transit the other Network where that network has not advertised a route for the destination in question. – AboveNet

Each Internet Network must set next hop to be itself, the advertising router of the network. Each Internet Network will propagate such routes to its transit customers with its own router as next hop. – Verizon

Each Internet Network will restrict its advertisements to non-transit routes originating within the geographic region for which peering is established and will not propagate the received route announcements outside such region. – Verizon

– note, more like keeping announcements in region No route of last resort will be (default route) directed at ATDN. – ATDN

Both parties shall announce only their own routes and the routes of their transit customers to the other party. No other routes are permitted, and may be filtered if detected. – InterNap Neither party shall abuse the peering relationship in any way. Neither party shall establish a static route, a route of last resort, or otherwise send traffic to the other party for a route not announced via BGP. Neither party shall alter, sell, or give next-hops to a third party. Neither party shall use the other party's network for transit, or engage in any other routing manipulation that causes the other party's network to provide transit to peers. This would include, but is not limited to, establishing a tunnel between two different peering interconnection points, or announcing to the other the more specific routes of prefixes learned via a third party mutual transit customer. – InterNap Neither party shall point default "route of last resort"; add a static route; or otherwise send traffic to the other party for a route not advertised via BGP. – NAC

tw telecom Peers must not abuse the peering relationship. For example, pointing a default, resetting next hop, selling or giving next hop to others, improper filtering, and leaking routes originating outside the peer's network. – TW Telecom

Neither party shall establish a static route, a route of last resort, or otherwise send traffic to the other party for a route not announced via BGP. – nLayer

All peers must not abuse the peering relationship by doing any of the following non-exhaustive list: - pointing default - resetting next hop - selling, bartering, trading or giving either routes or next hop to third parties (non-customers) - leaking routes to third parties (non-customers) - sending inconsistent prefixes (in number, origin, or other attributes) without prior agreement –RCN

Both parties shall refrain from using one another as a route of last resort, or otherwise sending traffic to the other party for a route not announced via BGP. – wbsconnect

Neither party shall abuse the SFI network peering relationship by engaging in activities such as, but not limited to: pointing a default route at the other or otherwise forwarding traffic for destinations not explicitly advertised, resetting next-hop, selling or giving next-hop to others. – Comcast

# No route of last resort (default route) will be directed at LambdaNet. – LambdaNet

# Peers must not utilize any form of gateway of last resort or default route that is directed at OpenAccess. – OpenAccess # Not direct a route of last resort (default route) at New Edge Networks. – NewEdge

Must not implement a "gateway of last resort" or default route directed at AS20115 – Charter

Interconnection Candidate must not establish a route of last resort (i.e., default route) directed toward Qwest. – Qwest

--------------------------- Neither party shall modify, sell, or provide the next-hop to a third party. – NAC The Peer shall announce only its own customer routes to tw telecom. – TW Telecom tw telecom Peers must not abuse the peering relationship. For example, pointing a default, resetting next hop, selling or giving next hop to others, improper filtering, and leaking routes originating outside the peer's network. – TW Telecom

Both parties shall announce only their own routes and the routes of their transit customers to the other party. No other routes are permitted, and may be filtered if detected. – nLayer

Neither party shall alter, sell, or give next-hops to a third party. These activities are considered theft of service, and will be prosecuted to the fullest extent of the law. – nLayer

Neither party shall announce to the other the more specific routes of prefixes learned via a third party transit customer. – nLayer

# Both parties shall announce only their own routes and the those of their transit customers to one another. Route leaking is prohibited, and will be filtered if detected. – wbsconnect

No transit or third party routes are to be announced; all routes exchanged must be Applicant's and Applicant's customers' routes. – Comcast

Applicant shall not be permitted to offer or sell any IP transit services providing only AS7922. – Comcast # Applicant must use the peering connection for all Traffic destined towards the TISCALI network – tinet

Applicant must not sell or give next-hop to any 3rd party (i.e. peer must not re-advertise Tinet routes to any peer) – tinet Neither party shall modify, sell or provide the next-hop to a third party. – OpenAccess

Each Internet Network will restrict its advertisements to non-transit routes originating within the geographic region for which peering is established and will not propagate the received route announcements outside such region. – Note – more about keeping routes within region 1.12. Each Internet Network must set next-hop to be itself, the advertising router of the network. Each Internet Network will propagate such routes to its transit customers with its own router as next-hop. – Highwinds

Must advertise routes, including customer routes, but eliminate all transit or third party routes – Charter

Must not abuse the peering relationship by doing any of the following: a. Resetting next hop b. Reselling, bartering, trading or giving either routes or next hop to third parties (non-customers) c. Leaking routes to third parties (non-customers) d. Sending inconsistent prefixes (in number, origin, or other attributes) unless agreed to in writing – Charter

Must agree not to offer or sell any IP transit service providing only AS20115 – Charter

The Interconnection Candidate may not advertise third party routes that allow direct traffic exchange (in either direction) between Qwest and customers of the Interconnection Candidate. – Qwest

Both parties shall announce only their own routes and the routes of their transit customers to the other party. No other routes are permitted, and may be filtered if detected. – WVFiber

Neither party shall establish a static route, a route of last resort, or otherwise send traffic to the other party for a route not announced via BGP. Neither party shall alter, sell, or give next-hop to a third party. These activities are considered theft of service, and will be prosecuted to the fullest extent of the law. – WVFiber

Neither party shall announce to the other a more specific route of a prefix heard from a third party transit customer. – WVFiber

No transit or third party routes are to be announced; all routes exchanged must be peer's and peer's customers' routes. – AT&T

Neither party shall abuse the peering relationship by engaging in activities such as but not limited to: pointing a default route at the other or otherwise forwarding traffic for destinations not explicitly advertised, resetting next-hop, selling or giving next-hop to others. – AT&T



About the Author

William B. Norton photo

Mr Norton is Founder of DrPeering, an Internet Peering portal and consultancy, with over twenty years of Internet experience.

From 1998-2008, Mr. Norton’s title was Co-Founder and Chief Technical Liaison for Equinix. From the beginning, Mr. Norton focused on building a critical mass of carriers, ISPs and Content Providers. 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 folks. He published and presented his research white papers in a variety of international operations and research forums. These activities helped establish the relationships necessary to atract the set of Tier 1 ISPs, Tier 2 ISPs, Cable Companies, and Content Providers necessary for a healthy Internet Exchange Point ecosystem.

 

 

Back To DrPeering Home

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.

Sponsors