loading

Digital communications

PEERING POLICY

  • Peer must be located at Gaza City – Palestine, where “DCC” maintains a presence, or negotiate peering.
  • Peer has publicly routable AS# (16bit or 32bit).
  • Peer has publicly routable IP (at least one prefix); Both IPv4 and IPv6 are supported (and expected)
  • Peer (local Members) for Interconnection or Exchange Traffic may receive Private AS# (not routable) and publicly IP range (IPv4, IPv6 not routable) only for exchange traffic.
  • Peer must send all technical information, AS number, IP addresses, and preferably a list of AS numbers / Prefixes hi will be announcing to us.
  • Peer is expected to register their routes in a public Internet Routing Registry (IRR) database, for the purpose of filtering.
  • Peer must operate an experienced 24/7 NOC - Network Operations Center, and provide email and contact numbers for the NOC. When notified of a peering or traffic issue(s), escalate immediately to a senior qualified engineer and provide timely resolution.
  • Peer shall report network maintenance issues that may affect BGP session and traffic exchanges Peer must not point any default route of last resort, add a static route, or otherwise send traffic for a route not advertised over BGP session.
  • Peer session with AS60268 will advertise all AS-DIGICOMMPS routes.
  • Peer suggest to set a max-prefix of 100 (IPv4) and 100 (IPv6) routes on peering sessions with DCC.
  • DCC reserve the right to immediately shutdown peering, at any event begin to detrimentally affect DCC network or services or other members. Such events may include, BGP session flaps, route flaps, excessive routes, denial of service attacks or spam.
  • DCC at this time, there are no minimum traffic requirements for establishing BGP sessions
  • DCC reserve the right to modify this document at anytime.