Skip to main content

Peering

May Mobility Peering Policy

May Mobility operates a global network spanning multiple cities in the United States and Japan. May Mobility (AS398351) has an open peering policy, and will peer with networks that have a presence on mutual exchange points in accordance with the policies described below:

  • Only send us traffic that is destined for the prefixes we announce to you. Do not point default at us or use static routes to send us traffic that does not match the routes we announce to you.

  • May Mobility prefers to peer at all exchange fabrics we have in common if we peer with you via public exchanges or all facilities we have in common if we peer via private interconnect with you. This is to prevent traffic crossing the Pacific or Atlantic twice to return back to the same continent.

  • May Mobility sets up IPv6 peering with all networks that meet our guidelines, including our BCP criteria.

    • We also support IPv4 peering, however we vastly prefer IPv6-only peering, as our network services are generally IPv6-only.

If you operate a peering network, you can reach out to [email protected] to discuss options.

Requirements

May Mobility uses PeeringDB as a single authoritative source of truth. This means peering partners must have an up-to-date PeeringDB entry before a bilateral peering session can be established.

May Mobility will use industry standards to secure the peering sessions. This includes industry standard practices and best common practices, including but not limited to BCP-38 and route filtering. Both parties should have a well set-up route-set or AS-SET as well as up-to date prefix maximums defined in PeeringDB. May Mobility will use this data to filter routes received from the network’s BGP sessions.

Both parties must have an up-to-date NOC contact email, which is responsive to raised issues and concerns.

Important Notices

To ensure quality of operations, we reserve the following rights under our Peering Policy:

  • To alter our peering policy and peering requirements at any time.
  • To accept or decline a peering request at any time for any reason.
  • To suspend, without notice, peering connectivity in the event of a severe quality of service issue such as high latency, packet loss, or jitter pattern is detected and to take appropriate traffic engineering steps to maintain service quality.
  • To selectively withdraw prefixes from public IXP fabrics as needed to protect service quality.
  • To terminate any peering connection at any time without notice.