OptiKabel Telecom - Peering Policy

OptiKabel Telecom operates an open peering policy and welcomes settlement-free peering with Internet Service Providers, content providers, cloud platforms, CDNs and other network operators.

Network	OptiKabel Telecom Sp. z o.o.
ASN	AS201966
Peering policy	Open
AS-SET	`AS201966:AS-OPTIKABEL`
IPv4	Supported
IPv6	Supported
Private Network Interconnect	Available on request

Peering Locations

Peering with AS201966 is available at the following locations:

Location	Interconnection type
EPIX Warszawa	Public IX
EPIX Katowice	Public IX
THINX Warszawa	Public IX
4DC Katowice	Public / Private interconnection
Bielsko-Biała POP	Private interconnection
Cieszyn POP	Private interconnection
Żywiec POP	Private interconnection
Kraków POP	Private interconnection

Technical Requirements

Peers should:

operate a public Autonomous System Number;
maintain accurate and current information in PeeringDB;
maintain valid IRR route objects for announced prefixes;
maintain valid RPKI ROAs where applicable;
announce only prefixes they are authorized to originate or transit;
maintain an operational NOC contact;
maintain sufficient interconnection capacity;
avoid route leaks, invalid announcements and abusive traffic.

OptiKabel Telecom may apply:

IRR-based prefix filtering;
RPKI Origin Validation;
maximum-prefix limits;
bogon filtering;
AS-path filtering;
route leak protection.

Routes with an invalid RPKI origin validation state may be rejected.

Routing Policy

OptiKabel Telecom generally prefers direct peering paths over IP transit where operationally appropriate.

Routing decisions may take into account:

BGP attributes;
route origin and validation status;
interconnection capacity;
traffic engineering requirements;
network stability;
network security.

OptiKabel Telecom does not provide IP transit over settlement-free peering sessions unless separately agreed.

Third-party routes should not be announced unless explicitly agreed.

Default routes should not be announced unless explicitly agreed.

Traffic Requirements

There is no strict minimum traffic requirement for establishing peering.

There is no strict traffic ratio requirement.

Peers are expected to maintain sufficient capacity to avoid persistent congestion.

Where traffic levels justify it, additional interconnection capacity or a Private Network Interconnect may be established.

BGP Sessions

IPv4 and IPv6 BGP sessions are supported.

Where an Internet Exchange provides multiple peering addresses, redundant BGP sessions are preferred.

BGP session authentication may be used where mutually agreed.

Appropriate maximum-prefix limits should be configured on both sides.

Routing Security

OptiKabel Telecom supports commonly accepted BGP routing security practices, including:

RPKI Origin Validation;
IRR-based filtering;
maximum-prefix limits;
bogon filtering;
route leak prevention.

Our operational practices are generally aligned with the recommendations described in RFC 7454 - BGP Operations and Security .

Where supported and mutually agreed, additional mechanisms such as BGP Roles and route-leak protection may be used.

Blackholing

Remote Triggered Black Hole routing may be supported on selected interconnections.

Details, including BGP communities and accepted prefix lengths, should be agreed individually with the peer.

Peering Requests

Peering requests should include:

ASN;
network name;
peering location;
IPv4 peering address;
IPv6 peering address;
AS-SET;
expected traffic volume;
NOC contact information.

Peering requests:
peering@optikabel.pl

Operational and NOC matters:
noc@optikabel.pl

General Conditions

Peering is subject to technical feasibility and available capacity.

OptiKabel Telecom reserves the right to reject, suspend or terminate a peering session where necessary for operational, security or capacity reasons.

Settlement-free peering does not create any obligation to provide transit, transport, colocation or other commercial services.

All peering arrangements are subject to mutual technical acceptance.