NATIONAL CAPITAL INTERNET EXCHANGE
O/A OTTAWA-GATINEAU INTERNET EXCHANGE (“OGIX”)
Technical requirements
Technical requirements for interconnection and peering at OGIX
An organization that wants to peer at OGIX must also meet the following technical requirements:
1.) The organization has a unique 16- or 32- bit long global autonomous system number.
2.) The organization is interconnecting using either multi-mode or single-mode fibre associated to either short- or long-reach optics media only at port speeds offered by OGIX, which are currently: (1) 10 Gbps port; (2) 40Gbps port or (3) 100Gbps port, but note that sub-rated speeds are independent from the chosen media type.
3.) The organization is in charge of providing its own transceiver for the equipment connecting to OGIX peering fabric as well as arranging for the cross connect to the OGIX switch, whereas the transceiver on the OGIX switch is provided by OGIX. As a result, the demarcation for the NNI connection is on the OGIX side of the cross connect side.
4.) The ethernet link supporting the connection between the organization and the OGIX supports a 1500-byte IP MTU. There is no planned support for jumbo frames.
5.) The organization either provides its own Internet Protocol (“IP”) IPv4/IPv6 address space or a written authorization from the holder of the IP address space that the organization intends to advertise indicating that the organization is entitled to advertise that IP space.
6.) The organization does not advertise IPv4 IP address prefix sizes longer than a /24 of IPv4 space or a /48 of IPv6 space, since longer prefixes are typically filtered by peers.
7.)The organization maintains entries in the ARIN (https://www.arin.net/resources/routing/) or RADb (https://www.radb.net/) Internet Routing Registry.
8.) The organization has up-to-date entries in the database of networks that peer, called PeeringDB (https://www.peeringdb.com/) for all prefixes it wishes to announce. In accordance with MANRS for IXP recommendation, the OGIX route-server filtering policy is based on the combination of ARIN/RADb and PeeringDB entries. Any inconsistent entry will be filtered automatically.
9.)The authentication to the OGIX peering manager interface is done through PeeringDB OAuth which requires the organization to have valid user entries for the team in charge of maintaining the connection between the organization and the OGIX.
10.) Peering is accomplished through Border Gateway Protocol version 4 (“BGP4”) sessions to OGIX route servers configured according to the peering policy of the organization.
11.) The organization establishes respectively one IPv4 BGP session and one IPv6 BGP session to each of the two OGIX route-servers, resulting in a total of 4 BGP sessions between the organization and the OGIX infrastructure for a single homed connection. Sessions to all route-servers shall remain up all the time, except in the case of emergencies or maintenance windows.
IPv6 BGP sessions are established on the OGIX IPv6 subnet
12.) Broadcast traffic must not be sent to OGIX except as required for normal operations (reword for integrating Mc traffic link it to point 13 on Ethertypes).
13.) The organization must disable the following features on the interface facing the OGIX if/where applicable:
- IPv6 Router Solicitation or Advertisement packets
- Spanning tree protocol
- Layer 2 protocols such as CDP, UDLD, EDP, VTP, DTP, LLDP
- Interior routing protocols such as OSPF, ISIS, IGRP, and EIGRP
- Protocol-Independent Multicast (“PIM”) traffic
- Proxy-ARP
14.) The OGIX IXP switch only supports the following ethertypes:
- 0x0806 – ARP
- 0x0800 – IPv4
- 0x86dd – IPv6
15.)Participants must not point a default route towards other exchange peers without the permission of the other peers.
16.) Participants may only utilize a single MAC address to a single layer-3 router per port allocated from the OGIX IXP switch unless otherwise authorized as an exception to this requirement (which requires the approval of the board of directors of OGIX).
17.) Route filtering is implemented through the OGIX route-servers. The policy learned by the OGIX route-server is built around the IRR and PeeringDB entries globally, as well as, locally, by leveraging BGP Large communities to influence advertisement across the OGIX. Refer to the table below for supported BGP Large communities today:
| Community | Action |
| 18655:0:peer-as | Do not advertise a prefix to peer-as |
| 18655:1:peer-as | Advertise a prefix to a certain peer |
| 18655:0:0 | Prevent advertisement of a prefix to all peers |
| 18655:1:0 | Advertise a route to all peers |
| 18655:101:peer-as | Prepend 1 time to peer-as |
| 18655:102:peer-as | Prepend 2 times to peer-as |
| 18655:103:peer-as | Prepend 3 times to peer-as |
Policy breach
Breaches of this policy can lead to suspension and even termination of a peer’s right to interconnect at the OGIX IXP. Additional legal remedies may also apply depending on the consequences and any harm caused by such breaches.
OGIX peer, participant and member definitions
Organizations that peer at OGIX are known as peers or participants. Organizations that are participants in good standing may also apply for and become members in the OGIX corporate entity in accordance with the terms of the OGIX by-laws. A prescribed membership form is used for that purpose. Members are entitled to vote at annual and other meetings of members. Participants that do not choose to be members do not have such rights.