Policy Overview

ZeaCloud operates an open peering policy. We welcome peering sessions from networks that meet the criteria below. This policy applies to both public peering at Internet Exchange Points (IXPs) and private bilateral peering where mutually agreed.

ZeaCloud’s objective is to exchange traffic directly with other autonomous systems to improve performance, reduce latency, and reduce transit costs while maintaining a secure and stable routing environment.

Peering Principles

Open Peering

ZeaCloud will consider peering sessions with any network that adheres to the requirements below, subject to capacity, technical feasibility, and mutual benefit. This includes direct sessions at IXPs and private peering arrangements.

No Ratio or Contract Requirements

ZeaCloud does not enforce traffic ratio constraints and does not require formal peering contracts for standard bilateral peering, consistent with our Open policy.

Multiple Locations

Peering across multiple locations is not required; ZeaCloud will evaluate peering at the specific exchange or facility where interconnection is requested.

Technical and Operational Requirements

To establish peering with ZeaCloud, prospective peers should satisfy these conditions:.

Autonomous System and Routing

• Operate a public Autonomous System Number (ASN) with reachable prefixes.
• Maintain accurate prefix registration in a public routing registry (e.g., IRR) and, ideally, RPKI ROA where applicable.
• Support IPv4 and IPv6 announcements where available.

BGP Session Requirements

• BGP peering sessions will be established using standard BGPv4.
• Proper prefix filtering must be applied by both parties in accordance with Internet routing best practices.
• ZeaCloud expects peers to implement max-prefix limits as appropriate and adhere to common security practices (e.g., RPKI/ROA validation).

Public Peering Exchanges

• ZeaCloud peers at relevant IXPs (e.g., Extreme IX Delhi) where capacity and port availability allow.
• Prospective peers should have a physical or virtual presence and a suitable port capacity at the exchange.

Operational Contacts

• Peering exchanges require up-to-date and accurate contact data, including a reachable NOC email and phone number.
• Peers must respond to operational communications in a timely manner.

Announcements and Prefixes

ZeaCloud expects peers to announce only their own prefixes or space they are authorized to originate. ZeaCloud will not accept poorly aggregated or unauthorized prefix announcements and may withdraw peering or implement filters if routing hygiene issues arise.

Security and Abuse Handling

ZeaCloud follows industry-standard practices for routing security. Peers are expected to maintain operational security, including mitigation of prefix hijacks, route leaks, and denial of service attacks. ZeaCloud reserves the right to suspend or modify peering arrangements if persistent abuse or security violations occur.

Policy Changes

ZeaCloud may modify this policy as needed. Any changes will be publicly posted and updated in Peering DB.