↑ Return to Peering

Print this Page

Peering Policy

AS8218 Peering Policy v2

AS8218 International Settlement-Free Peering Agreement

    Introduction

  • AS8218 is the NeoTelecoms European & North American backbone operated by NeoTelecoms’ IP engineering team. AS8218 provides services to customers in the following countries: France, United Kingdom, Netherlands, Germany, Ireland, Austria, Switzerland, Luxembourg, Belgium, Spain, and the United States. AS8218 is an IPv4, IPv6, and MPLS-enabled network.
  • Scope

  • Settlement-free peering is the exchange of mutually beneficial route announcements (and thus traffic) between NeoTelecoms (referred to as .AS8218. in this document) and other network operators (hereafter referred to as .the peer.). Mutual benefits of peering include improved routing (and thus improved service to customers), cost reduction, route redundancy, increased bandwidth, more granular control over traffic flow, and various other benefits. NeoTelecoms’ goal in establishing settlement-free peering with other operators is to maximize these benefits to our customers and those of our peers.
  • Peering Points

  • Public peering with AS8218 is currently possible on the exchange points listed at as8218.peeringdb.com. Private peering with NeoTelecoms is technically possible at any NeoTelecoms POP.
  • Terms and Conditions

  • AS8218 reserves the right to modify these terms with 30 days advance notice as well as the right to refuse or grant peering to other network operators as it sees fit regardless of these requirements. Unless otherwise specified, AS8218 will adhere to the policy below on its own network. Peering with NeoTelecoms and AS8218 is subject to the following terms and conditions:
  • Technical Requirements

  • The peer is strongly requested to maintain a looking glass or route server (or at least a traceroute gateway) for troubleshooting purposes. A courtesy shell account can substitute for this functionality.
  • The peer will have network routing infrastructure in at least two metropolitan areas in common with AS8218.
  • Peering will be established via one session in each common metropolitan area.
  • The peer will not run any layer 2 protocols or routing protocols other than BGP4 & BGP4+ on the peering interconnection, except in the case of ethernet OAM protocols agreed to on private interconnects.
  • AS8218 applies a maximum-prefix filter on all peering sessions. The peer should notify us, preferably via email or via the AS8218 peering database, if they intend to announce more prefixes than previously specified. We have multiple levels of filter protection (customers filtered by prefix-lists as well as universal customer and peer maxprefix filters in case of human error) on our customer facing sessions and peers, and we expect the same two-level route leak prevention from the peer. These measures are critical for the stability of our network and the Internet in general.
  • The peer will put forth their best effort to keep peering connections and backbone links free of congestion, including packet loss, excessive delay, and jitter, as well as to maintain connectivity across the peering link(s).
  • If a peering link is consistently more than 85% full in at least one direction with for more than 1 hour/day, AS8218 and the peer will work to upgrade the private interconnect or public exchange connection with due diligence.
  • The peer must send & receive all traffic to & from AS8218 and its customers via the peering connections.
  • AS8218 does not apply in/out ratio requirements to peering traffic.
  • Aggregate traffic exchanged with the peer (in+out) must be at least 0.01% of AS8218′s aggregate monthly traffic on a 95th percentile basis. This traffic level will be determined based on netflow data analysis.
  • Potential peering candidates will be evaluated with a test peering lasting at least one month. Test peerings will be evaluated at the beginning of each calendar month after having been established for at least 28 days.
  • Routing Requirements

  • The applicant’s routes must not be learned via an existing AS8218 private settlement-free peer.
  • AS8218 does not peer with any ASN announced by its customers.
  • Peering must be via both IPv4 and IPv6, or IPv6-only. New IPv4-only peers will not be accepted.
  • The peer must uniquely originate the equivalent of at least a /19 of IPv4 space.
  • The peer must be a member of their Regional Internet Registry (i.e. peer must be a Local Internet Registry).
  • The peer must announce at least a /48 of IPv6 space.
  • The peer must accept prefixes of length /24 and shorter throughout the range of valid routable public IPv4 addresses (see http://www.team-cymru.org/Services/Bogons/ for a list of bogon IPv4 & IPv6 addresses). NeoTelecoms filters peer v4 announcements longer than /24, v6 announcements longer than /48, and bogon announcements.
  • The peer shall aggregate their announcements as much as possible. Controlled deaggregation using the NOPEER/NO-EXPORT well-known BGP communities is possible, but only with the active cooperation of both parties in specific cases where it is deemed necessary as a means to efficiently route geographically diverse traffic.
  • The peer shall register their routes and AS objects in a global routing registry such as the RIPE or the RADB, and keep their entries up to date. See irr.net for more information. Maintaining a profile on peeringdb.com is also recommended.
  • The peer will not point default or static routes to AS8218′s routers.
  • The peer will announce an identical set of prefixes at all peering points. .MEDs. (BGP metrics) may be used to indicate the desirability of a route on a given link at NeoTelecoms discretion (or in other cases, controlled desaggregation as specified above). By default, we do not accept MEDs but it is possible with the active cooperation of both parties in specific cases where it is deemed necessary.
  • The peer may reset received communities, and we will send geographically useful MEDs if the peer wishes to use them.
  • The peer will set next-hop-self on all advertised routes.
  • AS8218 does not support multicast peering at this time.
  • Additional requirements for private interconnection

  • Private peering is possible if a public peer consistently exchanges more than 1.5gbps with AS8218 in one direction on a monthly 95th percentile basis.
  • Private peering will be connected via optical 10 gigabit ethernet interfaces with a minimum of two such connections in diverse interconnection locations (datacenters).
  • Any cabling fees will be appropriately divided between AS8218 and the peer. In cases where AS8218 and the peer are not mutually present in two diverse datacenters, costs associated with the second connection (usually a metro fibre or wave) will be shared between the two parties unless arrangements are otherwise specifically predetermined.
  • Administrative requirements

  • The peer will use e-mail or the AS8218 peering database for initial establishment of peering.
  • The peer will have technical staff and/or a NOC available by telephone 24×7.
  • The peer will include contact information for these personnel in the AS8218 peering database. The peer will also maintain an incident tracking (.trouble ticket.) system.
  • The peer will put forth their best effort to cooperate with AS8218 to resolve instances of network abuse, including and not limited to DDoS attacks, mail abuse, intrusion, etc.
  • No financial exchange or compensation will take place between AS8218 and the peer (private interconnect charges detailed above excluded), and neither party shall be liable to the other for any damages that may occur as a result of the peering and/or this agreement.
  • The quality and/or availability of network resources outside the administrative domain of AS8218 or the peer (exchange points, datacenter interconnects, telco circuits, etc.) shall not be taken into account vis-a-vis the terms of this agreement.
  • If AS8218 or the peer wishes to terminate the agreement, written notice will be given to the affected party at least 30 days in advance of the planned disconnection date.
  • AS8218 reserves the right to temporarily cease peering if above conditions are not met, in case of network abuse, or in case of Force Majeure.
  • The peer will read, understand, agree to and accept NeoTelecoms’ AS8218 peering agreement (this document).

Permanent link to this article: http://www.as8218.eu/?page_id=31