PCH

PCH Peering Survey Response Format


We would like to know your Autonomous System Number, and the following five pieces of information relative to each other AS you peer with:

  • Your peer’s ASN (peers only, not upstream transit providers or downstream customers)
    • Whether a written and signed peering agreement exists (the alternative being a less formal arrangement, such as a "handshake agreement")
  • Whether the terms are roughly symmetric (the alternative being that they describe an agreement with different terms for each of the two parties, such as one compensating the other, or one receiving more or fewer than full customer routes)
  • Whether a jurisdiction of governing law is defined
  • Whether IPv6 routes are being exchanged (this year, we’ll still assume that IPv4 are)

The easiest way for us to receive the information is as a tab-text or CSV file or an Excel spreadsheet, consisting of rows with the following columns:

Your ASN: Integer
Peer ASN: Integer
Written agreement: Boolean [true,1,yes,y] or [false,0,no,n]
Symmetric: Boolean [true,1,yes,y] or [false,0,no,n]
Governing Law: ISO 3166 two-digit country-code, or empty
IPv6 Routes: Boolean [true,1,yes,y] or [false,0,no,n]

For instance:
42 <tab> 715 <tab> false <tab>> true <tab> us <tab> true <cr>
42 <tab> 3856 <tab> true <tab> true <tab> us <tab> true <cr>

We need the ASNs so we can avoid double-counting a single pair of peers when we hear from both of them, and so that when we hear about a relationship in responses from both peers we can see how closely the two responses match, an important check on the quality of the survey. As soon as we've collated the data, we'll strip the ASNs to protect privacy, and only the final aggregate statistics will be published. We will never disclose any ASN or any information about any ASN. We already have more than 8,000 ASN-pair relationships documented, and we hope to receive as many more as possible. We'd like to finish collecting data by the end of September, about two weeks from now.

If you’re peering with an MLPA route-server, you’re welcome to include just the route-server’s ASN, if that’s easiest, rather than trying to include each of the peer ASNs on the other side of the route-server. Either way is fine.