Policies

This document sets out the ECN policy for peering and is also referred to herein as “this Policy”. ECN employs an open peering policy subject to the conditions defined in this Policy and also outlines our philosophies and practices as regards our own peering configurations.

What is contained in this document applies equally to both IPv4 and IPv6 peering.

For purposes of this Policy, an Internet Network must be a single Autonomous System (“AS”). ECN peers on AS36968.

Beyond what is described in this Policy, ECN also reserves the right to refuse peering to any third party for any reason, and reserves the right to de-peer any third party for any reason it sees as valid.

Section 1 sets out the commitments and practices with regards to peering configurations that ECN will adhere to.

Section 2 states the reciprocal behavior that ECN will expect from peers.

Section 3 lists some general notifications with regards to this Policy.

  1. ECN commitments
  • We do shortest exit (‘hot potato’) routing.
  • We do not geographically limit which prefixes are received at which exchange.
  • We will announce the following set of prefixes from all peering points:
    • RIR assigned supernets to the ECN AS.
    • ECN customer prefixes.
  • We will endeavor not to de-aggregate unless absolutely necessary.
  • We give preference to received prefixes in the following order:
    • Customer > Private Peer > IX Peer > Transit
  • We reserve the right to preserve or overwrite the following BGP routing attributes received from peers:
    • MED
    • Communities
  • We will honour the ‘no-export’ BGP community received from peers.
  • We will not default route or statically route to a peer without permission.
  • We will provide peers with a working, reachable email address contact for peering related issues and ensure this address is adequately monitored and responded to.
  • We will regularly audit our routing filters for accuracy. In the event that a fault occurs and prefixes are leaked, we will work to correct the problem in the shortest time possible.
  • We will only announce prefixes that are legitimately assigned to ECN or received from a ECN customer.
  • We will maintain route objects in radb.net and ensure these are kept up to date.
  • While we prefer NOT to sign peering contracts, we will consider peering contracts where requested on a case by case basis.
  • We will ensure our peering links are uncongested and commit to upgrading any peering link that is congesting and causing performance degradation.
  1. Expectations from Peers
  • We ask our peers to reciprocate with shortest exit (‘hot potato’) routing.
  • We ask peers to avoid excessive pre‐pending and de-aggregation where possible.
  • We do not expect peers to preserve or honour the following BGP attributes advertised by us:
    • MED
    • Communities
  • We expect peers to honour the ‘no-export’ BGP community sent by us.
  • Peers must agree never to statically route, or otherwise cause traffic, to flow towards any prefix we do not explicitly announce via BGP.
  • ECN will only peer via eBGP on public ASN’s, on public address space (we will not peer over RFC1918 address space or to a private ASN).
  • We expect peers to provide us contact details (either telephonic or email based) where we can address peering related issues. Such contact points should be monitored and responded to in a timely fashion.
  • While seldom used, we reserve the right to request RPKI signing of transmitted prefixes.
  • We expect peers to only announce prefixes that are legitimately assigned to them or their customers.
  • We expect peers to maintain a route set in a route registry of their choice.
  • We expect peers to have sufficient capacity on their peering links to avoid congestion and reserve the right to de-peer any party who is consistently running congested peering circuits.
  • We require peers to have a peering db entry and adequately maintain the entry to reflect current information.
  1. General Policy Notifications
  • The requirements in Section 2 must be met at the time of the request, for peering with ECN to be established.
  • The requirements of this Policy must continue to be met to continue a peering relationship.
  • The status under the policy will be evaluated periodically. In the case of a change in ownership or control of an Internet Network with which ECN has peering, we reserve the right to review the peering relationship.
  • ECN will continue to monitor the development of the Internet and traffic conditions and make appropriate changes in this Policy as the Internet continues to evolve. ECN reserves the right to modify this Policy at any time.
  • Any contractual rights shall arise out of a bilateral Peering Agreement and not out of this Policy.
  • All requests for peering should be submitted to ECN via e-mail at peering@ecn.co.za