ByteDance Peering Policy

This document sets forth ByteDance’s policy for settlement-free peering.

ByteDance is listed in PeeringDB, the industry database for peering information for network operators. Please review our PeeringDB entry for the most current list of ByteDance’s public and private peering locations. New peering requests should be emailed to peering@bytedance.com.

ByteDance has an open peering policy, subject to certain requirements. At times, local infrastructure requirements or constraints may make it necessary for us to modify these requirements on a temporary or long-term basis.

ByteDance peers with route servers in Internet Exchange, and we send our routes to them. However, we do have restricted policy on which routes we accept.

General Peering Policy

General requirements for those networks who wish to peer with ByteDance are:

A fully redundant network with sufficient capacity to exchange traffic without congestion.
Publicly routable ASN
Publicly routable address space (at least one /24 of IPv4 and/or one /48 of IPv6 space)
24x7 NOC contact capable of resolving BGP routing issues, denial of service attacks and security issues (or more generically, network issues)
Maintaining accurate and up-to-date peeringDB information
Presence at one or more of the Internet Exchanges or private peering interconnection facilities listed for ByteDance in PeeringDB
Routes being sent should pass ROA validation (valid, instead of unknown)
MD5 passwords are supported, available upon request
Minimum traffic requirements as set forth below

Other requirements

Public peering

Traffic: We prefer to exchange routes via bilateral sessions, as we're not always connected to route servers. You can request bilateral BGP sessions over Internet Exchanges by contacting peering@bytedance.com.

Private peering

Diversity: A requesting network should have the ability to peer with ByteDance at a reasonable level of diversity (e.g., metro, facility, router) in a location where ByteDance has a peering point of presence
Traffic: ASNs exhibiting more than 10Gbps of ByteDance traffic at peak, in either direction, can request private peering via a bilateral BGP session over dedicated port(s). We require either 100G or 400G ports for such private peering. please contact peering@bytedance.com for detailed information.
ByteDance prefers private peering, also known as Private Network Interconnect (PNI), for networks with sufficient traffic volume.
ByteDance may remove a public peering session once a corresponding PNI has been established.

Routing policy

In general, networks that have established peering sessions with ByteDance will receive all ByteDance routes within that area. At times, local infrastructure requirements or constraints may result in a more limited set of routes being advertised from ByteDance. These routes would be relevant to the local peering region.

Maximum prefixes

We suggest peers set a max-prefix of at least 30 (IPv4) and 10 (IPv6) routes on peering sessions with ByteDance.

Alongside AS396986, ByteDance also manages the following ASNs: AS138699.

Peering process

All requests for settlement-free peering should be submitted via e-mail to peering@bytedance.com
The e-mail request should include the following:

the requesting network’s complete contact information (name, phone, and email of a network representative)
the requesting network’s ASN
a list of suggested interconnection points that would meet the criteria set forth in this ByteDance Peering Policy.
Traffic volume for at least recent 30 days shows that it meets the above requirement

ByteDance reserves the right to grant or refuse peering with a requesting network, whether or not the requesting network meets the criteria set forth in this ByteDance Peering Policy. ByteDance also reserves the right to: (1) terminate peering for any reason upon 30 calendar days’ prior notice to the other party; and (2) to terminate peering immediately should any event detrimentally affect, or threaten to detrimentally affect, the ByteDance network. Examples of such events include BGP session flaps, route flaps, excessive routes, denial of service attacks or spam.