Dear All,
Please take some time to go through this survey which shall help us
contribute towards the development of IXPs in the AFRICAN region :)
Regards,
Keessun
-------- Forwarded Message --------
Subject: [af-ix] Fwd: PCH peering survey 2016
Date: Thu, 15 Sep 2016 09:37:38 +0200
From: Nishal Goburdhan <nishal(a)ispa.org.za>
To: af-ix <af-ix(a)af-ix.net>
hi there af-ix.
could you help circulate this survey request within your respective IX
communities please.
the results of the last survey are still used as reference matter (i
know that both michuki and i use “the 99% don’t need a peering
agreement statistic all the time) and we’d really like to update the
data.
thanks in advance,
—n.
Forwarded message:
> From: Bill Woodcock <woody(a)pch.net>
> To: afnog(a)afnog.org
> Subject: [afnog] PCH peering survey 2016
> Date: Wed, 14 Sep 2016 17:04:16 -0700
>
> Background:
>
> Five years ago PCH conducted the first, and to date only,
> comprehensive survey characterizing Internet peering agreements.
>
> The document that resulted can be found here:
> https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2011…
> <https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2011…>
>
> That document was one of the principal inputs to an important document
> that the OECD publishes every five years, one that recommends
> communications regulatory policy to OECD member nations:
> http://www.oecd.org/officialdocuments/publicdisplaydocumentpdf/?cote=DSTI/I…
> <http://www.oecd.org/officialdocuments/publicdisplaydocumentpdf/?cote=DSTI/I…>
>
> The survey had several useful findings which hadn’t previously been
> established as fact—most notably the portion of peering
> relationships that are “handshake” agreements, without written
> contract. These findings have improved the regulatory environments in
> which many of us operate our networks.
>
> At the time of the 2011 survey, we committed to repeating the survey
> every five years, so as to provide an ongoing indication of the
> direction peering trends take. It’s now five years later, so we’re
> repeating the survey.
>
> The survey is global in scope, and our goal is to reflect the
> diversity of peering agreements in the world; we’re interested in
> large ISPs and small ISPs, ISPs in Afghanistan and in Zimbabwe,
> bilateral agreements and multilateral, private and public. Our intent
> is to be as comprehensive as possible. In 2011, the responses we
> received represented 86% of all of the world’s ISPs and 96
> countries. We would like to be at least as inclusive this time.
>
> Privacy:
>
> In 2011, we promised to collect the smallest set of data necessary to
> answer the questions, to perform the analysis immediately, and not to
> retain the data after the analysis was accomplished. In that way, we
> ensured that the privacy of respondents was fully protected. We did as
> we said, no data was leaked, and the whole community benefited from
> the trust that was extended to us. We ask for your trust again now as
> we make the same commitment to protect the privacy of all respondents,
> using the same process as last time. We are asking for no more data
> than is absolutely necessary. We will perform the analysis immediately
> upon receiving all of the data. We will delete the data once the
> analysis has been performed.
>
> The Survey:
>
> We would like to know the following five pieces of information
> relative to each Autonomous System you peer with:
>
> • Your ASN
> • 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
> Symmetric: Boolean
> Governing Law: ISO 3166 two-digit country-code, or empty
> IPv6 Routes: Boolean
>
> 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 are asking for the ASNs only 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.
>
> If all of your sessions have the same characteristics, you can just
> tell us what those characteristics are once, your own ASN once, and
> give us a simple list of your peer ASNs.
>
> If your number of peers is small enough to be pasted or typed into an
> email, rather than attached as a file, and that’s simpler, just go
> ahead and do that.
>
> If you have written peering agreements that are covered by
> non-disclosure agreements, or if your organizational policy precludes
> disclosing your peers, but you’d still like to participate in the
> survey, please let us know, and we’ll work with whatever information
> you’re able to give us and try to ensure that your practices are
> statistically represented in our results.
>
> If you're able to help us, please email me the data in whatever form
> you can. If you need a non-disclosure, we're happy to sign one.
>
> Finally, if there are any other questions you’d like to see answered
> in the future, please let us know so that we can consider addressing
> them in the 2021 survey. The question about IPv6 routing in this
> year’s survey is there because quite a few of the 2011 respondents
> asked us to include it this time.
>
> Please respond by replying to this email, before the end of September.
>
> Thank you for considering participating. We very much appreciate it,
> and we look forward to returning the results to the community.
>
> -Bill Woodcock
> Executive Director
> Packet Clearing House
_______________________________________________
af-ix mailing list
af-ix(a)af-ix.net
http://af-ix.net/mailman/listinfo/af-ix_af-ix.net
As most of you probably don’t follow the AFRINIC Resource Policy discussion mailing list, just to let you know there’s been some mention of the MIXP.
But it’s not necessarily easy to spot in the archives as it’s in between into a longer unrelated thread about IPv6 statistics.
If you’re interested, the mention of the MIXP is in these messages:
https://lists.afrinic.net/pipermail/rpd/2016/005894.htmlhttps://lists.afrinic.net/pipermail/rpd/2016/005898.htmlhttps://lists.afrinic.net/pipermail/rpd/2016/005899.html
What I mostly wanted to address was that there was mention of our IX being “down” and have a /22 of IPv4 space reserved, neither of which are I can assure are at all accurate or true.
Do note that the transit kindly donated by one of our participants was out for a short while, and that did affected *global* access to the web site. But as this is separate from the actual switch, the IX always keeps exchanging traffic!
But this allows me to remind everyone of a few thing:
- Don’t forget that the administrative and management services of the MIXP also *peer* at the IX! So in cases like this, if *your* ASN peers to the MIXP’s management ASN, you won’t see the outage. If you are reading this and are able to set up peering for your AS and don’t have a session to AS327821, please please get in touch with peering(a)mixp.org to configure.
- We have https://lg.mixp.org/ to showcase the participants ASN’s and the associated number of prefixes - but we need folks to peer to the route collector to show up here.
Having good data here is a way to attract possible future content providers!
And peering to the route collector does *not* cause any actual traffic to be exchanged with anyone - so is therefore zero risk and cannot affect your policies or business. But it helps the MIXP hugely!
Please also contact peering(a)mixp.org asap to get this up.
- And don’t forget we also have live route-servers. (Sometimes called route-reflectors). These allow you to set up one single eBGP session and immediately exchange traffic with all others also talking to them. Much less work, but exponentially more traffic changed over time.
Anyone that is open to peering with the maximum of others and does’t yet have a session here is just lazy!
Same contact to get connected: peering(a)mixp.org.
Again, we understand that not everyone has an open policy and so not everyone will find the RS useful. But please use the RC even if you don't operate an open peering policy.
Finally, as always, IXPs work most effectively when they're used by all participants. We encourage peering where practical across the public fabric as it is still a free-to-use IX.
All the best
Daniel
As most of you probably don’t follow the AFRINIC Resource Policy discussion mailing list, just to let you know there’s been some mention of the MIXP.
But it’s not necessarily easy to spot in the archives as it’s in between into a longer unrelated thread about IPv6 statistics.
If you’re interested, the mention of the MIXP is in these messages:
https://lists.afrinic.net/pipermail/rpd/2016/005894.htmlhttps://lists.afrinic.net/pipermail/rpd/2016/005898.htmlhttps://lists.afrinic.net/pipermail/rpd/2016/005899.html
What I mostly wanted to address was that there was mention of our IX being “down” and have a /22 of IPv4 space reserved, neither of which are I can assure are at all accurate or true.
Do note that the transit kindly donated by one of our participants was out for a short while, and that did affected *global* access to the web site. But as this is separate from the actual switch, the IX always keeps exchanging traffic!
But this allows me to remind everyone of a few thing:
- Don’t forget that the administrative and management services of the MIXP also *peer* at the IX! So in cases like this, if *your* ASN peers to the MIXP’s management ASN, you won’t see the outage. If you are reading this and are able to set up peering for your AS and don’t have a session to AS327821, please please get in touch with peering(a)mixp.org to configure.
- We have https://lg.mixp.org/ to showcase the participants ASN’s and the associated number of prefixes - but we need folks to peer to the route collector to show up here.
Having good data here is a way to attract possible future content providers!
And peering to the route collector does *not* cause any actual traffic to be exchanged with anyone - so is therefore zero risk and cannot affect your policies or business. But it helps the MIXP hugely!
Please also contact peering(a)mixp.org asap to get this up.
- And don’t forget we also have live route-servers. (Sometimes called route-reflectors). These allow you to set up one single eBGP session and immediately exchange traffic with all others also talking to them. Much less work, but exponentially more traffic changed over time.
Anyone that is open to peering with the maximum of others and does’t yet have a session here is just lazy!
Same contact to get connected: peering(a)mixp.org.
Again, we understand that not everyone has an open policy and so not everyone will find the RS useful. But please use the RC even if you don't operate an open peering policy.
Finally, as always, IXPs work most effectively when they're used by all participants. We encourage peering where practical across the public fabric as it is still a free-to-use IX.
All the best
Daniel