Standard Peering Contract

For many years the LINX has provided a “Peering Template” which was intended to simplify the business of establishing Peering connections, by offering a standard form agreement for peering. (Unfortunately I could not find it when I last looked.)

Some time ago we decided at Thus to improve the Peering Template. The result was put in the public domain and offered to LINX members. It is available here in .pdf form and here in .rtf form. [Chris Hall produced the document, assisted by Andrew Bangs (network engineering) and Alison Russell (legal).]

There was some agreement amongst LINX members that a good standard form agreement would be a Good Thing. While the agreement we had produced was a definite improvement on its predecessor, I did not think that by itself it would solve the problem that LINX members thought it would solve. I wrote some notes on how the agreement might be developed, Towards a “Model” Peering Peering Contract. Nothing much happened.

Below are some notes on the motivation for a standard peering agreement, notes on the agreement itself, followed by a discussion of the limitations and possible development. Finally there are some suggestions for further work.

One thing that should be added is the requirement to use MD5 Authentication (A-4). Route aggregation is addressed (A-4.4), but that could be brought into line with more recent LINX policy. Of course, were there a suitable statement of Best Common Practice for Internet Network Interconnect, one would refer to that, too.

Note: the agreement is designed for simple peering connections where networks exchange only their own routes, so is not immediately suitable for Transit arrangements. The provisions of the agreement apply equally to both parties.

Why Worry ?

The obvious question is why should one worry about having a peering agreement at all ? Many peering arrangements are set up on a generally understood “best efforts” basis, often on the exchange of email between BGP Magi. Since the straightforward approach works, why would one want to jump into a legal tar pit ? The main reasons appear to be:

clarity: it’s a Good Thing for the parties to a peering arrangement to agree on what they mean by a ‘generally understood “best efforts” basis’. When examined closely there are almost as many opinions on the essentials of peering as there are peering experts.
completeness: formalising a peering arrangement can prompt the parties to cover all the bases, including, for example, NOC contacts.
liability: the absence of a formal agreement does not necessarily mean an absence of liability, indeed liability is literally indefinite. On the other hand, liability for the improper handling each other's traffic is a lot easier to enforce if enshrined in contract. Finally, the termination of a peering arrangement may cause resentment, so explicitly limiting redress can be desirable.
money: some peering arrangements are more valuable than others. Where real money or real value is involved it is clearly prudent to have a real contract.
confidentiality: it is not hard to discover who peers with whom, but other aspects of a peering arrangement may be better held confidential.
best practice: one way of spreading best practice is to embed it in contract (management understands contract requirements even when it may be hazy on the value of conforming to best practice).

Accepting that any or all of these are good reasons to formalise peering, the standard peering agreement is an obvious attempt to avoid lengthy legal review every time a peering arrangement is to be set up (as well as an attempt to provide a “best practice” form of words).

Notes on the Agreement

The agreement has a main part followed by a number of schedules. The first schedule covers the “Operational Requirements”, so separate the more technical provisions from the more generally contractual stuff. The other schedules document the peering connections and contact information.

The agreement is intended to provide:

a generally acceptable, best practice description of peering and the obligations of both parties – for simple (no transit) peering.
a straightforward legal framework binding both parties equally.
tables to capture essential data for peering connections.

suitable for situations where grubby commercial (money) considerations do not intrude – as is commonly the case at an Internet Exchange.

Section 1, Interpretation

This sets up definitions for various technical terms used and some common statements to guide the interpretation of the agreement.

The definitions depend on a number of terms of art, definitions for which are not attempted. The objective was to be able to tightly specify peering arrangements tightly, while remaining reasonably concise. [Any and all suggestions for improvement, gratefully received.]

This section could be used for Transit or other interconnections between IP networks.

Section 2, Scope

As narrow as possible, but no narrower.

Section 3, Connectivity and Network Peering

Specifies what the parties will do and not do. Refers to all the schedules. Allows for the peering arrangement to comprise a number of connections and for those connections to be via “public” interconnection (shared infrastructure such as a switch) or to be direct connections between the networks.

In fact the definition of Public Interconnection Point covers any form of connection where more than two networks may connect using some shared facilities – which includes facilities which might be better described as private. [This could be redrafted to be a Shared Interconnection Point without difficulty.]

The key distinction between “Public”and “Direct” connections is that in the public case each party is clearly responsible for their own circuit to some common infrastructure, where in the direct case there is a single circuit between the networks. This boils down to how the connection is paid for:

in the public case there are three costs, the cost of each party ’s circuit as far as the common infrastructure and the cost of the common infrastructure. The agreement imagines some point inside the common infrastructure and specifies that each party will fund traffic up to that point.
in the direct case there is one cost, the cost of the circuit between the networks. The default arrangement is for the parties to split the cost of the circuit 50/50, but allows for other arrangements.

In order to be able to refer to all peering connections as Interconnection Points the definitions are for Public Interconnection Points and Direct Interconnection Points. This is stretching the meaning of a Point somewhat, to include exchanges spread over quite a wide area (these days) and circuits that one would usually call point to point. The agreement that this grew out of was intended to cover the case of peering at a Public Exchange Point (for example, selecting at random, LINX). Looking at it again today, I think the definitions would benefit from being recast as Network Interconnection (replacing Interconnection Point), Direct Network Interconnection (replacing Direct Interconnection Point) and Shared Network Interconnection (replacing Public Interconnection Point).

Also on reflection, I would also have a go at the specification of how the cost of the shared portion of a Shared Network Interconnection is to be divided. In the case of an exchange point, such as LINX, it seems obvious that each network will cover its own costs for the use of the shared infrastructure, and that is implicit (not explicit) in the current wording. Further, one can imagine shared infrastructure where there is only one bill, or cases where one party agree to cover more of the costs.

Peering is to be settlement free, assuming some generally agreed meaning of that.

Nobody said this was going to be easy.

Section 4, Term and Termination

This is fairly straightforward stuff. All contracts need a term – the world changes and you do not want ancient, indefinite contracts hanging round your neck. Also, if the other party fails to live up to the contract you want a clear means terminate, both as a last resort and a last incentive.

The term is an initial, fixed twelve months, continuing indefinitely until either party gives 90 days notice.

There are provisions to deal with termination:

if either party fails to perform in some significant way, with provision for allowing that party to rectify things.
if one party goes bust, or appears to be heading that way.
if things have broken down for over three months.

Finally, most networks will not provide Transit and peering at the same time. So, if a Transit agreement is entered into, the Peering Agreement may be terminated.

These provisions are reasonable for straightforward peering, where the value to each party is sufficient incentive to maintain the connection. The agreement could be made more flexible by moving the actual term into a schedule, though that could in any case be modified by side letter. Where either party has circuits dedicated to a given peering connection, they may wish the term of the peering agreement to at least coincide with any term on those circuits or with a reasonable pay back period for them.

However, if the arrangement has particular value to one party they may wish to tie the other to a longer term. However, it must be noted that the agreement provides few means to prevent the other party from simply ceasing to pass traffic – some penalty or compensation mechanism is required.

Note that change of control is not a cause for termination.

Section 5, Customer Relations and Administration

To make it clear that neither party is responsible for the other’s customers.

Section 6, Customer Transmitted Data

Being some best practice provisions for the treatment of traffic.

Section 7, Warranties

Or, more precisely, the disclaimer of any warranty other than the ability to enter into the contract.

Note in particular that neither party undertakes to make any effort to properly handle each other's traffic. This is arguably a weakness. However, both parties are handling traffic to or from their own customers, so both have a built in incentive to properly handle the traffic. Including any specific warranties was judged to be likely to lead to objections from legal folk.

Section 8, Force Majeure

Shit happens.

Section 9, Limitation of Liability

Legal security blanket.

Section 10, Confidentiality; Section 15, Public Announcements

Confidentiality is easier to waive than to establish after the event.

The existence of the peering arrangement is easy enough to discover, and may in any case be something that both parties which to make known. However, almost everything else may be felt to be confidential, such as: the locations, means and capacities of interconnects; traffic volumes; network incidents; etc.

Section 11, Assignment

Assignment requires written consent, but is allowed. The agreement is quite open to either party’s business being rearranged (by acquisition, for example).

Section 12, Authorisations; Section 14, Regulatory Approval

Just in case.

Section 22, Dispute Resolution

A light weight procedure provided to help smooth out disputes. Given that both parties should have an incentive to keep the peering arrangement running, if this dispute resolution is insufficient then something has broken down.

Section 26, Governing Law and Submission to Jurisdiction

This specifies English Law. Other jurisdictions may be preferred.

Other Terms

The remaining terms are straightforward boilerplate.

Schedule A, Operational Requirements

This is intended to put the peering arrangement on a solid, best practice basis. It reads in best practice from a number of sources and specifies a number of particular requirements.

The requirement to use MD5 Authentication should be added.

Route aggregation is addressed (A-4.4), but that could be brought into line with more recent LINX recommendations.

Limitations and Possible Development

The agreement has two main limitations. First, it is designed for the most straightforward case of peering, where both parties are more or less equally happy to peer and the commercial consequences of the arrangement breaking down are relatively limited. Second, it is hard to use any “Standard Agreement” entirely unchanged even in straightforward applications.

Any contract has two functions. First, to specify what the parties expect of each other in the normal course of events – the “up side”. Second, to minimise the impact of either party failing to do what is expected and/or provide disincentives for such failure – the “down side”.

This agreement is intended to be uncontentious, so that it can be used with the minimum of changes by the maximum of people. This means that the agreement is very light on the “down side”. To repeat, this is fine for simple peering where:

the traffic exchanged is for straightforward “best efforts” delivery – anything else may require special operational and commercial handling.
all packets exchanged are either to or from the parties’ own network or customers, so both parties are committed to deliver traffic effectively – further incentives or disincentives are not required, nor is it necessary to specify performance metrics. [This is not to say that the two networks are bound to handle traffic equally well. It is to say that a network’s commitment to its customers is the same whether traffic arrives over a peering connection or via some other (transit) connection.]
both parties commercial interests are suffiently served by the arrangement – noting that peering connections are the most direct means to deliver customers’ packets.
failure (or refusal) of one party to perform properly (or at all) is not only unlikely (see above) but has limited commercial and/or operational impact – for example, where the traffic can be more or less equally exchanged with a transit provider, at less cost that trying to coerce a reluctant peer.

Where any of the above do not apply we have a more complex peering arrangement, requiring additional contract terms.

The real purpose of the Standard Agreement is to provide for the simple case, so that peering arrangements can be formalised with the absolute minimum of legal review – hopefully an organisation can review the agreement once and then execute contracts in that form without further review.

More complex peering will probably require special terms with legal review by both parties for each special contract.

The Standard Agreement could, nevertheless, form the basis for each special contract. The definitions, description of the peering process, operational requirements and so on could provide a framework which can be agreed straightforwardly and on to which special terms may be hung.

Straightforward Application – Small Changes

It is unusual for any given legal practitioner not to feel compelled to improve any contract put before them; they may even be required to ensure that all contracts meet their corporate standards. Engineers are equally prone to fine tuning. When reviewing the contract it is essential to remember the context for its use and that each change adds to the difficulty of applying it – the benefit of any change must be carefully weighed against the cost of stepping away from the Standard.

Two sorts of changes might be made:

changes specific to a given organisation. The obvious difficulty here is that when a peering agreement is to be formalised, if one or both organisations has its own varient of the Standard Agreement, some legal review will be inevitable – perhaps not much, but any is worse than none. Depending on the extent of the variations, two organisations may end up with incompatible agreements.
changes specific to a given peering arrangement. For example, the organisations may wish for a tighter or longer term, or wish the term to be tied to other arrangements, such as the circuit(s) used to make the peering connection(s).

In either case, as the agreement stands the recommended mechanism is a side letter (or any other means to effect changes without touching the standard text).

Further Development

In Towards a “Model” Peering Peering Contract are some ideas about how the Standard Agreement could be developed. (I wrote that some time ago. I have not revised it, so please forgive any repetition.)

The first idea is to identify parts of the agreement that will commonly be varied and provide either a standard set of alternatives, or a number of parameters with standard limits. When an organisation reviews the contract it can at that time decide which alternatives and parameter values it will accept and under what circumstances. The objective here is to enable two organisations to execute an agreement within the range of the Standard Model without further legal review, provided there is a suitable overlap in the alternatives and parameters acceptable to both organisations.

In building a measure of variability into the standard the aim would be minimise the number of non-standard changes that would be required in the practical application of a standard agreement. (I called the result a Model Contract to emphasise the fact that it would no longer be a single, fixed agreement, but a standard model from which particular agreements could be cast.)

The second idea is to further separate the various aspects of the agreement (technical, operational, legal and commercial) so that more radical customisation is made easier. This would allow, for example, the contract for a key peering arrangement to read in standard technical and operational requirements to sit alongside special legal and commercial provisions. This should clarify the agreement even for the straightforward application to simple peering.

The third idea is to build in to the Model Contract a reference to a schedule (hopefully empty) of special terms that take precedence over the body of the contract. This would go with the schedule(s) required to specify which of the standard alternatives apply and what values the standard parameters have.

There are then some ideas about how such a Model Contract could be applied (the Model Contract Protocol !), which includes capturing all the variable parts of a peering agreement (all the schedules other than the Schedule A, Operational Requirements) into one Model Contract Form. [Thinking about it, the trick may be to pull all the variable schedules into one.]

Further Work

Experience to date is that many people agree to the proposition “a Standard Peering Contract would be a Good Thing”, but not such a good thing to justify expending anyone’s time or treasure on.

Nevertheless, I suggest the following to move this on:

legal and technical review of the existing text by as many people as possible:
1. the whole purpose of a standard agreement is to have something that is generally acceptable !
2. this is a way to discover which parts of the agreement really need to have alternatives or be parameterised.
3. to bring it up to date with current practice.
redraft in the light of (1) above.
repeat as required.

Finally, the agreement as it stands fails to specify any consideration. I know asked a legal eagle about this, many, many moons ago but I am damned if I can remember...

Chris Hall, January 2007
chris.hall@highwayman.com