To participate in the peering VLANs (e.g. unicast or mcast6) a member must...
- operate the autonomous system that they connect to the exchange
- register the routing policy for the connecting AS on the IRR
- announce at least one prefix of at least 24 bits for IPv4 peering
- announce at least one prefix of at least 48 bits for IPv6 peering
- make sure all announced routes are also registered on the IRR
- make administrative, technical/NOC and peering contact information known to TREX. The maintainer should also be notified of all changes. The primary method of communication is email, but the contact information should also include phone numbers
- exchange IPv4 routes using BGPv4.
Exchange of IPv6 routes should be done using MP-BGP aka BGPv4+.
- no link local protocols (e.g. OSPF, IS-IS, CDP, STP, VTP, VRRP, GVRP, ...) may be enabled on the interface to the shared medium. These may be filtered by the shared medium if the need arises
- have at least two agreements for traffic exchange over TREX
- assign the addresses given on their routers. I.e. using EUI-64 or enabling autoconfiguration is not allowed
- set up a peering session with TREX's routers and announce and accept at least one route over that session
- have their router approved by TREX. This is just in order to prevent anyone from trying to exchange traffic with totally inappropriate equipment for the purpose.
All members must not...
- point any static routes over the shared medium. This includes static default routes! If transit is provided over the exchange the transit routes must be exchanged with a routing protocol
- disclose information relating to the exchange without the consent of all involved parties
- harm TREX equipment or the equipment of other members
- carry out illegal activities over the exchange.
Some requirements don't need to be filled immediately. Rather, the member has a month or two to fill them. This is specified in more detail in the agreement between the exchange and the member.