This document sets out the Vox Telecom policy for peering and is also referred to herein as “this Policy”. Vox Telecom 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”). Vox Telecom peers on AS11845.
Beyond what is described in this Policy, Vox Telecom 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.
Overview
Vox Telecom owns and operates an IP network identified as AS11845 with AS-VOXTELECOM as-set and RS-VOXTELECOM route-set maintained in the Afrinic whois database.
Vox Telecom peers at internet exchanges and peering facilities, which are all listed in PeeringDB. We maintain a selective peering policy based on multiple interconnection regions, adequate backbone scale and mutual benefit for both networks.
Section 1 sets out the commitments and practices with regards to peering configurations that Vox Telecom will adhere to.
Section 2 states the reciprocal behavior that Vox Telecom will expect from peers.
Section 3 lists some general notifications with regards to this Policy.
1. Vox Telecom 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 Vox Telecom AS.
- Vox Telecom 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 Vox Telecom or received from a Vox Telecom customer.
- We will maintain route objects in Afrinic 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.
- We will maintain an entry on PeeringDB for our AS (AS11845).
2. Expectations from Peers
- We ask our peers to setup bilateral peering in 2 or more regional INX locations, please refer to PeeringDB for INX Peering points.
- 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.
- Vox Telecom 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 and as-set in an internet routing registry (IRR) 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 PeeringDB entry and adequately maintain the entry to reflect current information.
3. General Policy Notifications
- The requirements in Section 2 must be met at the time of the request, for peering with Vox Telecom 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 Vox Telecom has peering, we reserve the right to review the peering relationship.
- Vox Telecom 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. Vox Telecom 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 Vox Telecom via email at peering@voxtelecom.co.za
