diff --git a/OIX-1.md b/OIX-1.md index 66a9194..7f66dd3 100644 --- a/OIX-1.md +++ b/OIX-1.md @@ -1,287 +1,231 @@ -# **IXP Technical Requirements OIX-1** +# **IXP Technical Requirements OIX-1** -Version 3.1, June 16, 2025 +Version 3.2, May 1, 2026 Questions: ix-group@oix.org -This standard defines the technical requirements for an IXP to be certified by OIX. The purpose of the requirements is to provide publicly available information on what the participants of a certified IXP can expect, and not to describe in detail how the IXP is designed, built or operated. IXPs can comply with the OIX standards to serve different communities with different requirements, from a small single datacenter IXPs serving a local community to a large IXP located in multiple datacenters in a metro area. +This standard defines the technical requirements for an IXP to be certified by OIX. The purpose of the requirements is to provide publicly available information on what the customer of a certified IXP can expect, and not to describe in detail how the IXP is designed, built or operated. IXPs can comply with the OIX standards to serve different communities with different requirements, from a small single datacenter IXPs serving a local community to a large IXP located in multiple datacenters in a metro area. The keywords used throughout the document are as defined in RFC 2119\. The IXP **SHOULD** follow the Best Current Operational Practices for an Internet Exchange, posted at [https://github.com/Open-IX/BCOP](https://github.com/Open-IX/BCOP) -## +--- ## **Table of Contents** -**[IXP Technical Requirements OIX-1](#ixp-technical-requirements-oix-1)** -- [Table of Contens](#table-of-contents) -- [Forward](#forward) -- [Definition of Internet Exchange \- IX](#definition-of-internet-exchange---ix) -- [Definition of an Internet Exchange Point \- IXP](#definition-of-an-internet-exchange-point---ixp) -- [Definition of Community Supported IXP](#definition-of-community-supported-ixp) -- [Services](#services) - - [Minimal Service Offering](#minimal-service-offering) - - [Public Exchange VLAN (IX)](#public-exchange-vlan-\(ix\)) - - [Additional Service Offering](#additional-service-offering) - - [Private VLAN (PVLAN)](#private-vlan-\(pvlan\)) - - [Physical Interface](#physical-interface) - - [Traffic Forwarding / Fabric Protection](#traffic-forwarding-/-fabric-protection) - - [Layer 2](#layer-2) - - [Layer 3](#layer-3) - - [Customer Interface](#customer-interface) - - [Conforming to MANRS](#conforming-to-manrs) -- [Infrastructure](#infrastructure) - - [Switching Platform](#switching-platform) - - [IP Address Space](#ip-address-space) - - [Route Server](#route-server) - - [Topology](#topology) -- [Operations](#operations) - - [NOC](#noc) - - [Monitoring](#monitoring) - - [Statistics](#statistics) - - [Website](#website) -- [Pricing](#pricing) -- [Miscellaneous](#miscellaneous) - -## - -## **Forward** - -This update is to provide a single OIX-1 Specification for “Regular” and “Community Supported” IXP submissions and to also include some sample configurations for IXP Fabric Switches. +[IXP Technical Requirements OIX-1](#ixp-technical-requirements-oix-1) +- [Table of Contents](#table-of-contents) +- [Foreward](#foreward) +- [1\. Definitions](#definitions) +- [2\. Services](#services) + - [2.1. Minimal Service Offering](#minimal-service-offering) + - [2.1.1. Public Exchange VLAN (IX)](#public-exchange-vlan-\(ix\)) + - [2.2. Additional Service Offering](#additional-service-offering) + - [2.2.1. Private VLAN (PVLAN)](#private-vlan-\(pvlan\)) + - [2.2.2. Optional Layer 3 Services](#optional-layer-3-services) + - [2.3. Physical Interface](#physical-interface) + - [2.4. Traffic Forwarding / Fabric Protection](#traffic-forwarding-/-fabric-protection) + - [2.4.1. Layer 2](#layer-2) + - [2.4.2. Layer 3](#layer-3) + - [2.5. Access Lists](#access-lists) + - [2.6. Customer Interface](#customer-interface) + - [2.7. Conforming to MANRS](#conforming-to-manrs) +- [3\. Infrastructure](#infrastructure) + - [3.1. Switching Platform](#switching-platform) + - [3.2. IP Address Space](#ip-address-space) + - [3.3. Route Server](#route-server) + - [3.4. Topology](#topology) +- [4\. Operations](#operations) + - [4.1. NOC](#noc) + - [4.2. Monitoring](#monitoring) + - [4.3. Statistics](#statistics) + - [4.4. Website](#website) + - [4.5. Pricing](#pricing) + - [4.6. Miscellaneous](#miscellaneous) + +--- + +## Forward + +**Changes:** + +- Initial updating to include numbering +- Minor formatting updates +- Add optional Layer 3 Services +- Clarification on Rate Limiting +- Use of AS Number for Route Server(s) +- Maximum Pricing Clarification +- RPKI use in Route Servers Please feel free to comment and make any suggestions. -Thanks, +Receptfully, Paul Emmons ix-group@oix.org -Chair IX Committee -June 16, 2025 - -## **Definition of Internet Exchange \- IX** - -An IX is the entity that operates one or more switching fabrics at one or more locations for the purpose of peering (interconnection). - -## **Definition of an Internet Exchange Point \- IXP** - -From IX-F at [https://www.ix-f.net/ixp-definition.html](https://www.ix-f.net/ixp-definition.html) \- An Internet Exchange Point (IXP) is a network facility that enables the interconnection of more than two independent Autonomous Systems, primarily for the purpose of facilitating the exchange of Internet traffic. - -An IXP provides interconnection only for Autonomous Systems. - -An IXP does not require the Internet traffic passing between any pair of participating Autonomous Systems to pass through any third Autonomous System, nor does it alter or otherwise interfere with such traffic. - -“Autonomous Systems” has the meaning given in BCP6/RFC4271 , “A Border Gateway Protocol BGP4”. - -“Independent” means Autonomous Systems that are operated by organizational entities with separate legal personality. - ---- - -**Explanatory Notes** - -1. An Internet Exchange Point is a technical facility. This is distinct from the organization that provides that facility, which might be termed an *IXP operator*. - - - -2. An IXP is distinct from an Internet access network or a transit network/carrier. - - - -3. The function of an IXP is to interconnect networks. An IXP does not provide network access or act as a transit provider/carrier. An IXP also does not provide other services unrelated to interconnection (although this does not preclude an IXP operator from also providing unrelated services). - - - -4. An IXP exists to interconnect networks that are technically and organizationally separate. - 1. Without qualification the term “network” is too flexible and fails to identify the degree or kind of separation required. Once interconnected, separate networks are arguably part of the same network: the entire Internet is often considered a network of networks. - 2. To resolve this terminological problem we employ the term “Autonomous System”, which is the standard technical definition of a technically stand-alone network. - - - -5. The network operators whose networks are interconnected in an IXP are sometimes collectively termed “*IXP participants*”, which generalizes the relationship between those entities and the IXP operator; IXP participants **MAY** be members of the IXP operator, customers of the IXP operator, or some other relationship. - - - -6. An IXP is a facility where numerous participants interconnect (at least three); this distinguishes Internet Exchanges from bilateral network interconnection, in which one network connects to one another. - ---- - -**We note that within general practice IX and IXP are largely interchangeable.** - -To be certified an IXP **MUST** be operating with at least 3 globally routable ASes. - -The IXP **SHOULD** also be listed in a publicly available resource Such as IXPDB, PeeringDB or similar - -The IXP’s ASN and IP resources **MUST** be verifiable with the RIR and assigned to the IXP - -If an IXP discontinued its operations or has any material changes it **MUST** notify OIX within 30 days. - -## Definition of Community Supported IXP {#definition-of-community-supported-ixp} - -To achieve “Community Supported” Status for this certification: - -1. Is not owned or controlled, operated or managed by a colocation provider or service provider; and -2. Has the appropriate government recognition as an organized entity, Community Association, Unincorporated Association, Trade Group or similar organization such that the organization benefits the member / participant “Community” (hereinafter “Community Supported”); and -3. Has either: - 1. no recurring charges for connected networks (pass-through / cost-recovery charges exempted); or - 2. a maximum yearly revenue of $100,000 USD (or local equivalent) as updated by the OIX Board. - -4. A community IXP shall recertify on an annual basis - -## - -## **Services** - -### **Minimal Service Offering** - -The IXP **MUST** provide the minimum services described below. This also allows the IXP operator to provide additional services, or methods of interconnection. - -#### **Public Exchange VLAN (IX)** - -A switch platform which allows any-to-any interconnection. Customer interfaces with Ethernet frames tagged for the public exchange VLAN **MUST** be forwarded in accordance with the traffic rules indicated in this document. - -### **Additional Service Offering** - -The IXP **MAY** provide additional services, as long as they are described on a publicly available website of the IXP. - -#### **Private VLAN (PVLAN)** - -A private switch platform, whereby any two or more parties may consent to interconnect through either the same physical port that delivers their access to the Public Exchange VLAN or alternatively dedicated physical port(s). If a PVLAN service is offered, in case there are exactly two parties in the private VLAN the connection **MUST** be delivered guaranteed congestion free. In case of more than two parties the service **MAY** be provided on a best efforts basis. - -### **Physical Interface** - -The IXP **MUST** offer IEEE 802.3 Ethernet connectivity on a common switch infrastructure. Service offerings **MAY** be available at any IEEE defined rate, including IEEE 802.3ad or IEEE 802.1AX link aggregation of any of these rates. - -The complete service offering **MUST** be described on a publicly available website. The information provided **MUST** contain: link rate and physical media (copper, fiber and fiber type). The information **SHOULD** describe how each port type is connected to the fabric. - -The IXP **SHOULD NOT** allow for physical port speed and duplex negotiation. - -The IXP **MUST** protect the IXP fabric from user misconfiguration, broadcast / unknown and multicast storms, and port flapping. - -### **Traffic Forwarding / Fabric Protection** - -#### **Layer 2** - -The IXP **MUST** forward frames with the following Ethertypes: - -* 0x0800 IPv4 -* 0x86dd IPv6 - -Valid frames with Ethertype 0x86dd may be suppressed on the Public Exchange VLAN using snooping, or alternate methods used to implement IPv6 Neighbor Discovery. +Chair Standards Committee +May, 1 2026 -If there is no provision to handle ARP in any other way, the IXP **MUST** forward frames with the following Ethertype: +1. ## **Definitions** -* 0x0806 ARP +OIX Common Definitions \- OIX has created a Glossary of Data Center and Networking Nomenclature ([https://github.com/Open-IX/Standards/blob/main/definitions.md](https://github.com/Open-IX/Standards/blob/main/definitions.md)) containing our definations of an Internet Exchange / Internet Exchange Point as used in this document. -If the IXP has reason to limit certain traffic, the IXP **MUST** publish on a publicly available website what traffic is not allowed and or not forwarded on the exchange platform. +2. ## **Services** -If the IXP applies a MAC address locking mechanism on a participants port, then the IXP **MUST** make known to customers the process to update MAC addresses. + 1. ### **Minimal Service Offering** -#### **Layer 3** + The IXP **MUST** provide the minimum services described below. This also allows the IXP operator to provide additional services, or methods of interconnection. -The IXP **SHOULD** provide a method to ensure that BGP Peering Sessions only originate from the IPv4 and IPv6 Ranges utilized by the IXP. + 1. #### **Public Exchange VLAN (IX)** -#### **Access Lists** + A switch platform which allows any-to-any interconnection. Customer interfaces with Ethernet frames tagged for the public exchange VLAN **MUST** be forwarded in accordance with the traffic rules indicated in this document. -Per interface access lists as described in BCP214 **SHOULD** be implemented on each member / participant facing port. + 2. ### **Additional Service Offering** -### **Customer Interface** + The IXP **MAY** provide additional services, as long as they are described on a publicly available website of the IXP -The IXP **MUST** provide a clear demarcation point between the IXP services and the customer. This can be either directly on the exchange or via a common demarcation point available to the participants. + 1. #### **Private VLAN (PVLAN)** {#private-vlan-(pvlan)} -### **Conforming to MANRS** + A private switch platform, whereby any two or more parties may consent to interconnect through either the same physical port that delivers their access to the Public Exchange VLAN or alternatively dedicated physical port(s). If a PVLAN service is offered, in case there are exactly two parties in the private VLAN the connection **MUST** be delivered guaranteed congestion free. In case of more than two parties the service **MAY** be provided on a best efforts basis. -The IXP **SHOULD** participate in Mutually Agreed Norms for Routing Security (MANRS) [https://www.manrs.org/](https://www.manrs.org/) and **SHOULD** encourage its members / participants to participate in MANRS. + 2. #### **Optional Layer 3 Services** -## + A routed platform to provide Layer 3 services, that **MAY** be provided on a best efforts basis. -## **Infrastructure** + 1. Examples include + 1. Caching + 2. Transit + 3. Limited Routing such as Google Verified Peering Provider services + 2. If an AS Number is utilized it **MUST** be a publicly assigned AS Number from an RIR. + 3. Use of IRR Filters and RPKI validation **SHOULD** be done. + 4. If the use of BGP Communities for routing decisions / AS path altering or modification are used, they **MUST** be disclosed to the users. -### **Switching Platform** + 3. ### **Physical Interface** -The IXP switching platform **MUST** have backplane capacity to sufficiently handle the aggregate traffic of all customer facing ports, without oversubscription. If individual switching elements contain multiple switch fabric modules, the same conditions **MUST** apply during single component failures. + 1. The IXP **MUST** offer IEEE 802.3 Ethernet connectivity on a common switch infrastructure. Service offerings **MAY** be available at any IEEE defined rate, including IEEE 802.3ad or IEEE 802.1AX link aggregation of any of these rates. + 2. The complete service offering **MUST** be described on a publicly available website. The information provided **MUST** contain: link rate and physical media (copper, fiber and fiber type). The information **SHOULD** describe how each port type is connected to the fabric. + 3. The IXP **SHOULD NOT** allow for physical port speed and duplex negotiation. + 4. The IXP **MUST** protect the IXP fabric from user misconfiguration, broadcast / unknown and multicast storms, and port flapping. + 5. The IXP **MAY** provide Rate Limiting (packet shaping and / or packet dropping) on a parties port or link aggregation to provide a speed less than the total speed upon the request of the party. -The IXP **MUST** run any inter-switch links congestion free. + 4. ### **Traffic Forwarding / Fabric Protection** -The IXP **SHOULD** have redundant power feeds fed from discrete sources (A and B) for all exchange infrastructure. If the IXP does not have redundant power feeds on any components, it **MUST** describe where not on a publicly available website. + 1. #### **Layer 2** -If the IXP does not have full path diversity between two discrete switching elements in different physical locations, this **MUST** be described on the IXPs publicly available website. + 1. The IXP **MUST** forward frames with the following Ethertypes: + 1. **0x0800 IPv4** + 2. **0x86dd IPv6** -The IXP **SHOULD** describe on a publicly available website the switching platform and the redundancy measures implemented to overcome single component failures. + Valid frames with Ethertype 0x86dd may be suppressed on the Public Exchange VLAN using snooping, or alternate methods used to implement IPv6 Neighbor Discovery. -### **IP Address Space** + 3. **0x0806 ARP** -In order to be independent of any of the connected parties, the IP space used on the “Public Exchange VLAN” **MUST** be Provider Independent space or other IP space directly assigned by a RIR for the purpose of operating an IXP. This applies to both IPv4 and IPv6. The IXP operator is responsible for obtaining address space from the respective RIR, as well as providing all material for justification, documentation, and applicable fees as required by the RIR. + If there is no provision to handle ARP in any other way, the IXP **MUST** forward frames with this ethertype. -### + 2. If the IXP has reason to limit certain traffic, the IXP **MUST** publish on a publicly available website what traffic is not allowed and or not forwarded on the exchange platform. + 3. The IXP **SHOULD** apply a MAC address locking mechanism on a customer port: + 1. The IXP **MUST** make the policy known to the Customers. + 2. The IXP **MUST** make known to customers the process to update MAC addresses. -### **Route Server** + 2. #### **Layer 3** -If a route server service is offered then it **MUST** support both IPv4 and IPv6, and 16-bit and 32-bit ASNs. The AS number used for the route server implementation **MUST** be a unique AS number assigned by one of the RIRs. The AS **MAY** be utilized by multiple IX fabrics operated by the same entity. The IXP **SHOULD** use a 16 bit ASN. + The IXP **SHOULD** provide a method to ensure that BGP Peering Sessions only originate from the IPv4 and IPv6 Ranges utilized by the IXP. -The Route Server **will** operate in such a way: + 5. ### **Access Lists** -1. That the Route Server AS Number **MUST** not be shown in the AS routing path. -2. That the NEXT-HOP ip address and AS is the originating member / participant. -3. That rather than honoring the NO-EXPORT community, it **MUST** pass that community onto the connected member / participant. -4. That the originated IP announcements: - 1. **MUST** be filtered for reserved or special IP address ranges and AS numbers. - 2. **MUST** limit the number of BGP prefixes each member / participant may originate. - 3. **MUST** disallow the propagation of a default route. - 4. **SHOULD** be filtered against the originating networks IRR entries. - 5. **SHOULD** be filtered against invalid RPKI origination. - 6. **SHOULD** honor the request of networks not to have announcements in the route servers that the originating networks do not intend to have on route servers (e.g. PeeringDB’s “Never-via-Route-Server”). - 7. **SHOULD** ensure that paths with well known transit networks are not propagated. - 8. **SHOULD** limit the use of excessive AS path length. - 9. **SHOULD** disallow routes that are: - 1. Shorter than /8 for IPv4 and /19 for IPv6. - 2. Longer than /24 for IPv4 and /48 for IPv6. except for /32 or /128 for Black Holing purposes. + Per interface access lists as described in BCP214 **SHOULD** be implemented on each customer facing port. -The IXP **SHOULD** have at least two route servers. The route servers **SHOULD** be in diverse locations, and connected to discrete switching elements. If the IXP does not have route servers in diverse locations, or does not have two route servers connected to discrete switching elements, it **MUST** be described on the IXP’s publicly available website. + 6. ### **Customer Interface** -The IXP **SHOULD** have redundant power feeds fed from discrete sources (A and B) for the Route Servers. If the Route Servers do not have redundant power feeds, it **MUST** describe where not on a publicly available website. + The IXP **MUST** provide a clear demarcation point between the IXP services and the customer. This can be either directly on the exchange or via a common demarcation point available to the customer. -The IXP **SHOULD** publish the Route Server setup on a publically website. If not then the Route Server setup **MUST** be made available to members / participants. + 7. ### **Conforming to MANRS** -Route Servers filtering policies **MUST** be disclosed to its members / participants. + The IXP **SHOULD** participate in Mutually Agreed Norms for Routing Security (MANRS) [https://www.manrs.org/](https://www.manrs.org/) and **SHOULD** encourage its customer to participate in MANRS. -A looking glass **SHOULD** be made available to the members / participants to verify announcements. +3. ## **Infrastructure** -### **Topology** + 1. ### **Switching Platform** -If the IXP operates at more than one location, the IXP **MUST** indicate what paths are redundant and **SHOULD** indicate capacity of the links. + 1. The IXP switching platform **MUST** have backplane capacity to sufficiently handle the aggregate traffic of all customer facing ports, without oversubscription. If individual switching elements contain multiple switch fabric modules, the same conditions **MUST** apply during single component failures. + 2. The IXP **MUST** run any inter-switch links congestion free. + 3. The IXP **SHOULD** have redundant power feeds fed from discrete sources (A and B) for all exchange infrastructure. If the IXP does not have redundant power feeds on any components, it **MUST** describe where not on a publicly available website. + 4. If the IXP does not have full path diversity between two discrete switching elements in different physical locations, this **MUST** be described on the IXPs publicly available website. + 5. The IXP **SHOULD** describe on a publicly available website the switching platform and the redundancy measures implemented to overcome single component failures. + 6. The IXP **MUST** facilitate “Mitigating the Negative Impact of Maintenance through BGP Session Culling” as described in RFC 8327 for ports on the Public Peering VLAN. -## + 2. ### **IP Address Space** -## **Operations** + 1. In order to be independent of any of the connected parties, the IP space used on the “Public Exchange VLAN” **MUST** be Provider Independent space or other IP space directly assigned by a RIR for the purpose of operating an IXP. This applies to both IPv4 and IPv6. The IXP operator is responsible for obtaining address space from the respective RIR, as well as providing all material for justification, documentation, and applicable fees as required by the RIR. + 2. IP space used for Optional Layer 3 Services **MUST** be publicly routable from the Global Internet and **SHOULD** appear in the global internet routing table. Use of RFC 1918 space **MUST** not be utilized. + + 3. ### **Route Server** {#route-server} -### **NOC** + The IXP **SHOULD** offer two route servers to facilitate multilateral peering between the customer on the Public Peering VLAN. + 1. If a route server service is offered: + 1. It **MUST** support both IPv4 and IPv6, and 16-bit and 32-bit ASNs. + 2. The AS number used for the route server implementation **MUST** be a unique AS number assigned by one of the RIRs. + 1. The AS **MUST** be utilized only for Route Servers + 2. The AS **MAY** be utilized by multiple IX fabrics operated by the same entity. + 3. The IXP **SHOULD** use a 16 bit ASN. + 2. The Route Server **SHALLwill** operate in such a way: + 1. That the Route Server AS Number **MUST** not be shown in the AS routing path. + 2. That the NEXT-HOP **MUST** be the ip address and AS is the originating customer. + 3. That rather than honoring the NO-EXPORT community, it **MUST** pass that community onto the connected customer. + 3. Route announcements: + 1. **MUST** be filtered for reserved or special IP address ranges and AS numbers. + 2. **MUST** limit the number of BGP prefixes each customer may originate. + 3. **MUST** disallow the propagation of a default route. + 4. **RPKI** validation by Route Servers + 1. **MUST** do RPKI Validation and Drop RPKI Invalids. + 2. **MUST** update from ALL RIR Trust anchors and delegations + 3. **MUST** drop all “Stale” records, manifests and CRLs if the time given in their next-update field is in the past. + 4. Each Route Server **SHOULD** use two different validators. + 5. **SHOULD** be filtered against the originating networks IRR entries. + 6. **SHOULD** be filtered against invalid RPKI origination. + 7. **SHOULD** honor the request of networks not to have announcements in the route servers that the originating networks do not intend to have on route servers (e.g. PeeringDB’s “Never-via-Route-Server”). + 8. **SHOULD** ensure that paths with well known transit networks are not propagated. + 9. **SHOULD** limit the use of excessive AS path length. + 10. **SHOULD** disallow routes that are: + 1. Shorter than /8 for IPv4 and /19 for IPv6. + 2. Longer than /24 for IPv4 and /48 for IPv6. except for /32 or /128 for Black Holing purposes. + 11. The IXP **SHOULD** have at least two route servers. The route servers **SHOULD** be in diverse locations, and connected to discrete switching elements. If the IXP does not have route servers in diverse locations, or does not have two route servers connected to discrete switching elements, it **MUST** be described on the IXP’s publicly available website. + 12. The IXP **SHOULD** have redundant power feeds fed from discrete sources (A and B) for the Route Servers. If the Route Servers do not have redundant power feeds, it MUST describe where not on a publicly available website. + 13. The IXP **SHOULD** publish the Route Server setup on a publically website. If not then the Route Server setup **MUST** be made available to the customer. + 14. Route Servers filtering policies **MUST** be disclosed to its customer. + 15. A looking glass **SHOULD** be made available to the customer to verify announcements -The IXP **MUST** publish a telephone number, email address or any other means that provides immediate access to technical support, on a website available to its participants, on how to contact operational staff that is capable of managing the IXP infrastructure. The access method **MUST** be available 24x7, note this does not mean staff needs to be available 24x7, but the IXP **MUST** publish staff hours. + 4. ### **Topology** -The IXP **MUST** provide and publish a procedure to announce service affecting maintenance to its participants. + If the IXP operates at more than one location, the IXP **MUST** indicate what paths are redundant and **SHOULD** indicate capacity of the links. -### **Monitoring** +4. ## **Operations** -The IXP **MUST** monitor the exchange platform for performance degradation and service affecting events. + 1. ### NOC -The IXP **MUST** provide a procedure to inform its participants on performance degradation and service affecting events. + 1. The IXP **MUST** publish a telephone number, email address or any other means that provides immediate access to technical support, on a website available to its customer, on how to contact operational staff that is capable of managing the IXP infrastructure. The access method **MUST** be available 24x7, note this does not mean staff needs to be available 24x7, but the IXP **MUST** publish staff hours. + 2. The IXP **MUST** provide and publish a procedure to announce service affecting maintenance to its customer. -### **Statistics** + 2. ### Monitoring -The IXP **MUST** publish on a publicly available website the participants on the peering platform and the relevant AS numbers. + 1. The IXP **MUST** monitor the exchange platform for performance degradation and service affecting events. + 2. The IXP **MUST** provide a procedure to inform its customer on performance degradation and service affecting events. -The IXP **MUST** publish on a publicly available website the total sum of all incoming and outgoing traffic in bps from all connected networks on the public peering VLAN. The traffic sum **MUST** include the traffic on customer facing ports only and **MUST** be made up of 5 min average traffic measurements. A distinction **MUST** be made between the traffic on the public peering VLAN and any other interconnection service. + 3. ### Statistics -### **Website** + 1. The IXP **MUST** publish on a publicly available website the customer on the peering platform and the relevant AS numbers. + 2. The IXP **MUST** publish on a publicly available website the total sum of all incoming and outgoing traffic in bps from all connected networks on the public peering VLAN. The traffic sum **MUST** include the traffic on customer facing ports only and **MUST** be made up of at least 5 min average traffic measurements. A distinction **MUST** be made between the traffic on the public peering VLAN and any other interconnection service. -The IXP **MUST** have available and maintain a publicly available website where at least the subjects mentioned in this document **MUST** be addressed. + 4. ### Website -## **Pricing** + The IXP **MUST** have available and maintain a publicly available website where at least the subjects mentioned in this document **MUST** be addressed. -The IXP **MUST** disclose any pricing, terms and conditions (if any) on its website. + 5. ### Pricing -## **Miscellaneous** + The IXP **MUST** disclose any maximum pricing, terms and conditions (if any) on its website. -The IXP **MUST** publish and maintain an accurate entry for a peering contact and configuration directory such as [https://www.peeringdb.com](https://www.peeringdb.com/) or [https://ixpdb.euro-ix.net/](https://ixpdb.euro-ix.net/) or any regional IXP organizations. This entry **MUST** contain a list of all facilities that the IXP maintains a point of presence. + 6. ### Miscellaneous + The IXP **MUST** publish and maintain an accurate entry for a peering contact and configuration directory such as [https://www.peeringdb.com](https://www.peeringdb.com/) or [https://ixpdb.euro-ix.net/](https://ixpdb.euro-ix.net/) or any regional IXP organizations. This entry **MUST** contain a list of all facilities that the IXP maintains a point of presence.