Introduction:

Liquid Telecommunications has an open peering policy subject to the conditions defined in this document.
What is contained in this document applies equally to both IPv4 and IPv6 peering. Liquid Telecom peers on AS30844.

Beyond what is described in this document, Liquid Telecommunications 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.

Liquid Telecom will:

• Not geographically limit which prefixes are received at which exchange.
• Give preference to received prefixes in the following order:
  Customer > PNI > Exchange Prefix > Transit
• Honour Multi-­‐exit discriminator bits
• Endeavour not to de-­‐aggregate unless absolutely necessary
• Wherever possible, apply anti-­‐spoofing and BCP38 (or later revisions) concepts to our routing
• Subscribe to the principles described in the Mutually Accepted Norms for Routing Security (MANRS)
• Not default route or statically route to a peer without permission
• Diligently watch our routing filters and when and if mistakes happen and prefixes get leaked, we will apply all due effort to rectifying such problems in the shortest possible timeframe.
• We will only announce space that is legitimately assigned to Liquid or received from a Liquid customer. 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.
• Never peer with our customers
• Avoid peering with customers of our customers (where feasible)
• Maintain route objects in a route registry and ensure these are kept up to date.
• Prefer NOT to sign peering contracts, but will consider peering contracts where requested on a case by case basis.
• Peer via public exchange points,but will consider peering via private network interconnect on a case by case basis.
• Ensure our peering links are uncongested and commit to upgrading any peering link that is congested and causing performance degradation.
• Maintain an entry on peeringdb for our AS (AS30844).
• Liquid 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)

What we expect from our Peers:

• Avoid excessive pre-­‐pending and de-­‐aggregation where possible
• Apply BCP38 (or later revisions) concepts and where feasible understand and subscribe to the principles described in the Mutually Accepted Norms for Routing Security (MANRS)
• Must agree never to statically route, or otherwise cause traffic, to flow towards any prefix we do not explicitly announce via BGP
• 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.
• To only announce prefixes that are legitimately assigned to them or their customers.
• To maintain a route set in a route registry of their choice.
• 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.
• Honor MED, but do not require it.
• To have a peeringdb entry and adequately maintain the entry to reflect current information.