Rethinking the role of the Peering Coordinator

In the past ten years, the Internet has evolved rapidly. Content delivery networks, commonly referred to as CDNs, have become increasingly prevalent. All major service provider networks have some sort of internal CDN offering or partner to provide a CDN service. As the landscape has changed, to what extent have the service provider business planning models evolved as a result? This post will examine how planning and the evolution of the sentries known as peering coordinators require change to maintain relevance.

In the early days of the Internet, email and light file sharing was what most demanded of Internet usage. As cable providers and incumbents began deploying broadband, content delivery networks began to whet the appetites of end users by providing access to games and movies. With a view of the high-margin of content delivery, service providers clamored to sign a big name CDN logo as a customer. Whether or not their networks, capital or operating expense budgets could sustain this initiative was an entirely different story.

Also in the early days of the Internet, the responsibility for interconnection planning was largely performed by a person commonly referred to as a peering coordinator. The qualification for this position was limited to a background in network engineering usually with a firm understanding of border gateway protocol or BGP. Each quarter, these individuals would meet at industry conferences around the world to plan. Although business acumen was not a requirement, the top tier peering coordinators were highly regarded within their companies and the industry.

In their exuberance to bring on CDN customers, services providers formed internal committees to make external interconnection decisions. Although included as a member of the committee, increasingly companies began to disregard the counsel of their peering coordinators. In the last ten years, many of the most tenured changed positions or left their companies or the industry altogether.

In 2013, both service provider business planning models and peering coordinators must evolve to maintain relevance. First, internal coordination must occur on a global-scale among the executive leadership, legal, finance, product and engineering organizations in advance of capturing the traffic volumes of a relevant CDN logo. Second, the peering coordinator must become increasingly commercially astute. Although helpful, an in-depth knowledge of BGP is not the required skill necessary to provide proper counsel to executive leadership on strategic planning and engagement.  Instead, peering coordinators need to understand how to describe, analyze and evaluate the operations and outcomes of capturing a particular customer.

At the end of the day, proper planning is all about the details. The peering coordinator should be able to provide those details in a format that enables an evolving organization to make proper decisions.

The following two tabs change content below.
The Level 3 Editor manages content for Level 3's Beyond Bandwidth blog.

2 thoughts on “Rethinking the role of the Peering Coordinator

  1. Marcellus, I disagree on the BGP-knowledge section. Unless someone really understand the BGP algorithm, he/she cannot be a successful peering coordinator. Apart from this, good thoughts. Thanks.

  2. Interesting. However, I tend to agree with Freddy. I think it’s also important for the peering co-ordinator to understand BGP, and more importantly, how changes to existing BGP config/setup etc. will affect the network/peering relationship, and how to act on that (either technically, or commercially). Traffic flow is essentially what you’re negotiating over, and BGP is your best tool for this; so you need to know, and understand, how your tool works.

    Being able to decode updates on the wire, isn’t needed though 🙂

    It goes without saying that the peering co-ordinator needs to be business astute.

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload the CAPTCHA.