Policy
AgileSP is a Tier 1 IP Transit aggregator that enables local and regional Internet Service Providers (ISPs), Wireless Internet Service Providers (WISPs), Content and Cloud Providers through our vastly interconnected Global footprint of Tier 1 Providers Below is a summary of our overall peering policy:
Introduction
Agile Solutions Provider (Agile) operates under ASN 328748 and maintains an open peering policy, subject to the conditions outlined in this document. This policy applies equally to both IPv4 and IPv6 peering. Agile reserves the right to refuse or terminate peering with any party for any reason it deems valid.
Agile Solutions Provider will:
1. Announce only prefixes legitimately assigned to Agile or received from Agile customers.
2. Maintain route objects in a route registry and keep them up to date.
3. Provide peers with a monitored, reachable email address for peering-related issues.
4. Prefer peering via public exchange points but consider private network interconnects on a case-by-case basis.
5. Ensure peering links remain uncongested and commit to upgrading any congested links causing performance degradation.
6. Apply anti-spoofing measures and follow BCP38 (or later revisions) routing security practices.
7. Adhere to the principles described in the Mutually Accepted Norms for Routing Security (MANRS).
8. Not default route or statically route to a peer without explicit permission.
9. Promptly address any routing mistakes or prefix leaks.
10. Maintain an up-to-date entry on PeeringDB for our AS (AS328748).
11. Peer only via eBGP on public ASNs and public address space (no RFC1918 address space or private ASNs).
12. Honor Multi-exit Discriminator (MED) bits.
13. Avoid unnecessary de-aggregation of prefixes.
14. Consider peering contracts on a case-by-case basis, though we generally prefer not to sign them.
What we expect from our Peers:
1. Announce only prefixes legitimately assigned to them or their customers.
2. Avoid excessive prepending and unnecessary de-aggregation.
3. Apply BCP38 (or later revisions) concepts and adhere to MANRS principles where feasible.
4. Never statically route or cause traffic to flow towards any prefix we do not explicitly announce via BGP.
5. Provide monitored contact details (phone or email) for addressing peering-related issues in a timely manner.
6. Maintain a route set in a route registry of their choice.
7. Ensure sufficient capacity on peering links to avoid congestion.
8. Honor MED (Multi-exit Discriminator) bits, though this is not a strict requirement.
9. Maintain an up-to-date PeeringDB entry.
10. Be open to implementing RPKI signing of transmitted prefixes if requested.
Agile reserves the right to de-peer any party consistently running congested peering circuits or violating the terms of this policy. We are committed to maintaining a robust and secure network for the benefit of all our peers and customers.
For any peering inquiries or issues, please contact: [email protected]