Difference between revisions of "Peering Policy"

Revision as of 11:05, 28 January 2014

Operational Requirements

1. Both parties provide an escalation path for resolving network issues in a timely fashion. Issues of a non-emergency technical nature should be responded to within 48 hours.
2. Both parties shall be responsive to unsolicited bulk email, hacking, Denial of Service, and other network security and abuse issues. A good faith effort should be made to provide a qualified network engineer to trace ongoing network attacks within a reasonable amount of time.
3. Both parties shall provide access to a route server, looking glass, or similar service for the purposes of routing audits, diagnostics, and troubleshooting.
4. Both parties shall work quickly and diligently to establish additional capacity to accommodate traffic growth.

Technical Requirements

1. Both parties shall announce consistent routes across all interconnection points.
2. Both parties are expected to register their routes in a public Internet Routing Registry (IRR) database, for the purposes of filtering. Both parties shall make good faith efforts to keep this information up to date.
3. Both parties shall make every reasonable effort to restrict the transmission of Denial of Service attacks and packets with forged source addresses from their network.
4. Both parties shall announce only their own routes and the routes of their transit customers to the other party. No other routes are permitted, and may be filtered if detected.
5. Neither party shall establish a static route, a route of last resort, or otherwise send traffic to the other party for a route not announced via BGP. Neither party shall alter, sell, or give next-hops to a third party. These activities are considered theft of service, and will be prosecuted to the fullest extent of the law.
6. Neither party shall announce to the other the more specific routes of prefixes learned via a third party transit customer.
7. BGP MD5 authentication is preferred, but not required.
8. Peers are expected to aggregate their routes. Anything smaller than a IPv4 /24 will be dropped.

General Policy

1. XMission reserves the right to change this policy at any time.
2. In the event of a severe or quality-of-service impacting violation of these policies, the interconnection may be temporarily suspended without notice.
3. Any interconnection may be terminated for any reason, with 30 days notice.
4. All requirements must be met at the time the request for Peering is made, and must continue to be met for the duration of the interconnection.
5. XMission reserves the right to accept or decline any interconnection request for any reason.

Peering Information

ASN: 6315

IRR AS-SET: AS-XMISSION

PeeringDB

Suggested IPv4 Max Prefix: 50

Suggested IPv6 Max Prefix: 5

Contact: peering@xmission.com