NATIONAL CAPITAL INTERNET EXCHANGE
O/A OTTAWA-GATINEAU INTERNET EXCHANGE (“OGIX”)
CONNECTION AND PEERING POLICY
Purpose of the policy
The purpose of this policy is to articulate the rules that apply for connection to, and peering at, the Internet Exchange Point (“IXP”) locations operated by OGIX.
Current Peers
https://ixpdb.euro-ix.net/en/ixpdb/ixp/811/asns/
The Organization
OGIX is a not-for-profit corporation incorporated on March 29, 2018, as National Capital Internet Exchange under the Canada Not-for-profit Corporations Act, S.C. 2009, c.23. One of the stated purposes of the Corporation is: “To provide an infrastructure that facilitates the exchange of communications network traffic among Internet service providers, network service providers, content service providers and other entities that need to exchange communications network traffic within Canada”.
OGIX mandate
In order to fulfil its mandate, OGIX is in the process of establishing IXP peering infrastructure in the Ottawa-Gatineau region. Initially, the IXP is operational at the PureColo Inc. data centre located at 390 March Road in the City of Ottawa. Additional locations will be added as practicable.
Interconnection with the OGIX infrastructure at the IXP locations
Any organization that operates a communication network and satisfies the following conditions may connect at the OGIX peering infrastructure for the purpose of exchanging traffic with other peers connected to that infrastructure, thereby becoming a participant in the exchange
1.) The organization has delivered a complete and signed service order to OGIX specifying the peering services that it wishes to obtain from OGIX and the location(s) at which it intends to interconnect, based on the options that OGIX makes available to peers from time-to-time;
2.) The organization has paid the necessary installation charge so as to be in good financial standing with OGIX;
3.) The organization has provided the technical information that OGIX requires to connect the participant’s network to the OGIX exchange and interconnection is being requested to be accomplished in a manner that is compatible with the peering equipment operated by, and technical requirements of, OGIX;
4.) The organization commits to complying with the terms and conditions of service and policies of OGIX, as amended from time-to-time;
5.) The organization has made the necessary arrangements, including providing the necessary authorizations, to obtain meet-me-room cross-connect(s) to reach the OGIX peering infrastructure at its own expense in each IXP location at which it seeks interconnection; and
6.) The organization adheres to all required technical interconnection and peering rules of OGIX, as amended from time-to-time.
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.