About Membership Partnership News Our Network Initiatives

Network Overview
Network Topology
Network Tools
BGP Routing Policy
Peering Policy

This section contains documentation on OCCAID's BGP routing policies, including BGP communities sent and received by our network. As part of the internet community, it is important for networks to publicly document these policies for customers, peers and prospective customers.

Receivable: Export Control Communities | Receivable: Import Control Communities |
Receivable: Special-use Communities | Announced Communities | Community Area Codes |
Community-use Examples

Local Preferences | General BGP Policies

Receivable: Export Control Communities
Export control communities are those sent by our customers to control distribution of their routes throughout the internet, beyond the OCCAID network.

The export control format is NNNNN:4AAAR, where "NNNNN" is the Calling Code -- the calling code is used to define which group of peers or which specific adjacent AS you wish to apply your policy to. The first digit of the second component is always "4" then followed by variables of the "AAA", for Area Code, and "R" for Request for Action Code, which are defined in the following tables.

The list of Area Codes is available below.
Calling Code [NNNNN:4AAAR]
30071 OCCAID customers
64512 Commercial peers and transits in North America
64513 Commercial peers and transits in Europe
64514 Commercial peers and transits in Asia-Pacific
65000 Academic, National Research and Education Networks (NRENs)
XXX To apply your policy against a particular network adjacent to OCCAID, place its AS number.
Request for Action Code [NNNNN:4AAAR]
0 Do not announce
1 Prepend 30071
2 Prepend 30071 30071
3 Prepend 30071 30071 30071
4 If supported by our upstream, forward a request to treat the route as a peering partner learned route.
5 If supported by our upstream, forward a request to treat the route as a transit learned route.
6 If supported by our upstream, forward a request to not announce to anybody.
7 If supported by our upstream, forward a request to not announce to transits.
8 If supported by our upstream, forward a request to not announce to peers.
9 If supported by our upstream, forward a request to not announce to customers.

Receivable: Import Control Communities
Import control communities are those sent by our customers to influence OCCAID's routing decision; such as how OCCAID's network will treat the customer's route in terms of preference amongst its peers, other customers and transits.
Import Control Communities
30071:50 Set local-preference to 50 (last resort route).
30071:100 Set local-preference to 100 (normal transit route).
30071:150 Set local-preference to 150 (depreferenced peering route).
30071:200 Set local-preference to 200 (normal peering route).
30071:205 Set local-preference to 205 (depreferenced NREN route).
30071:210 Set local-preference to 210 (normal NREN route).
30071:250 Set local-preference to 250 (backup customer route).
30071:300 Set local-preference to 300 (normal customer route; default behavior).

Receivable: Special-use Communities
These communities are used in exceptional, debugging or emergency cases and are not normally used. Incorrect use of these communities may result in partial or total destruction of connectivity to the affected routes. Please use them with careful consideration.
Exceptional Special-use Communities
30071:911 Discard traffic. Will also request all peers and transits to do the same, if they support such community.
30071:950 Bypass label switched traffic-engineering. Disables MPLS hop-hiding activity.
(Warning: experimental and works in IPv4 only)
30071:31337 Also advertise route to NBONE experimental networking group.

Announced Communities
Every route entering the OCCAID network is tagged with a community to assist in classifying and identifying its type and origin. OCCAID uses these communities to enforce its routing policies and for informational purposes. These communities are also advertised to customer BGP sessions to help our customers in achieving their own traffic engineering practice.

The format is 30071:5AAAT, where "AAA" is again, the Area Code, significant to where the route was learned from. And "T" stands for Type Code which is defined in the following table.
Type Code [NNNNN:5AAAT]
1 Commercial transit learned route.
2 Commercial peer learned route.
3 NREN peer learned route.
4 Customer learned route.
5 Internally originated route.

Community Area Codes
Area Code is used to associate the general geographic location to a route. For Export Control communities, Area Code can be used to specify which geographical location you wish to have your policy propagated to.

When applying policies toward OCCAID's transit upstreams, you may not only specify which upstream AS you want to influence, but also the geographic location of a port by using Area Code. You can also do the exact same thing to OCCAID customer ASes. Please do note however, use of the Area Code toward OCCAID's peers is NOT supported. If you wish to influence an OCCAID's peer, you should always set 000 as your Area Code, which means "all possible locations." The reason why we do not support Area Code for peers is because most Settlement-Free Interconnection Agreements (click on the link for an example) require consistent route propagation at all locations.

For Announced Communities, the Area Code is used to classify where a route has been learned from.

We use ICAO and IATA aviation codes to classify our network regions and POP codes. We find it easier and scalable to classify geographically dispersed network assets using an already successful naming scheme than coming up with our own.

The ICAO Flight Information Region (FIR) codes signify a region, which contains number of POPs that belong within its borders. The IATA's three-letter airport codes are used to classify each individual POPs. For example, there are three POPs that reside inside the FIR region, KZOA: Palo Alto (PAO), San Francisco (SFO) and San Jose (SJC).
Area Code [NNNNN:(4|5)AAAT]
000 All locations.
7.. FDC North American FIRs
700 KZOA
SFO (snfc01, snfc02), PAO (plal01), SJC (snjs01, snjs02)
701 KZBW
BOS (bstn01, bstn02, somv01), CEF (chcp01), BED (wlhm01), MHT (mcnh01)
702 KZNY
New York
EWR (nwrk01, whkn01, hbkn01, jrcy01), LGA (nycm01)
703 KZMA
BCT (bcrt01), MIA (miat01), TPA (tamr01)
704 KZFW
Fort Worth
DFW (dlls01)
705 KZAU
ORD (chcg01, chcg02, okbr01)
706 KZDC
Washington DC
IAD (asbn01, stng01), DCA (wadc01), RDU (rlgh01)
707 KZTL
ATL (atln01)
708 KZJX
JAX (jksn01)
709 KZKC
Kansas City
MCI (kscy01)
Los Angeles
LAX (lsan01, elsg01, irvn01, psdn01, lsan02), SAN (sndg01)
711 KZHU
IAH (hstn01)
712 KZDV
DEN (dnvr01)
713 KZOB
CLE (clvn01), ROC (rcny01)
714 KZSE
SEA (sttl01)
790 CZEG
YEG (edtn01)
791 CZYZ
YYZ (trnt01)
792 CZVR
YVR (vanc01)
8.. EUC European FIRs
800 ESAA
ARN (stkh01, stkh02)
801 EGTT
LHR (lndn01, lndn02)
802 EHAA
AMS (amst01, amtn01)
803 EBUR
BRU (brus01)
804 LPPC
LIS (lisb01)
805 EDDU
FRA (frnk01), MUC (mucn01)
806 LIMM
MXP (miln01), BGY (brgm01)
807 LZBB
BTS (brts01)
808 LFFF
CDG (pari01)
809 ENOR
OSL (oslo01)
810 EKDK
COP (cphg01)
9.. ASP Asia-Pacific FIRs
900 RJTI
NRT (tokj01)
901 RJOO
KIX (oskj01)
910 RKRR
ICN (incn01), GMP (selk01)
920 VHHH
Hong Kong
HKG (newt01)
930 YBBB
Brisbane Service Center
BNE1 (qbne01), SYD1 (nsyd01)
940 YMMM
Melbourne Service Center
MEL1 (melb01)

Community-use Examples
Here are some examples of our BGP communities in action.
Receivable Communities (those sent to OCCAID by customers)
0:40000 Do not announce (no-export) to anyone, anywhere.
0:47020 Do not announce to anyone in New York-New Jersey (KZNY).
30071:47070 Do not announce to customers in Atlanta (KZTL).
30071:40000 Do not announce to any customers.
64513:40001 Prepend once to peers and uplink ports in Europe.
65000:47052 Prepend twice to NRENs in Chicago.
3549:40002 Prepend twice to Global Crossing.
4725:40000 Do not announce to Japan Telecom.
3257:40006 Request Tiscali (uplink) to not announce to anybody (proxy/transitive no-export).
1273:47032 1273:47021 Prepend twice to C&W (uplink) in Miami, once in New York.
Announced Communities (those sent by OCCAID to customers)
30071:57021 Upstream/transit route learned from New York area (KZNY).
30071:57002 Peering partner route learned from San Francisco Bay area (KZOA).
30071:57004 Customer route learned from San Francisco Bay area (KZOA).
30071:58012 Peering partner route learned from London area (EGTT).

Local Preferences
Localpref Description
50 Depreferenced transit or last resort route.
100 Normal transit route.
150 Depreferenced peering route.
200 Normal peering route.
205 Depreferenced NREN route.
210 Normal NREN route.
250 Depreferenced or backup customer route.
300 Normal customer route.
400 Normal internal route.

General BGP Policies
Prefixes Receivable & Length Policy
1. OCCAID propagates prefixes shorter than or equal to /48 in their length to other IPv6 internet networks.
2. Customers may advertise up to /128 sized IPv6 prefixes to OCCAID -- however, only prefixes matching RIR boundaries (i.e. /32) or /48 for multihoming purposes will be distributed to other internet networks. The purpose of allowing up to /128 in prefix length is to provide more granularity to customers for traffic engineering and blackhole routing.
3. Customers must beware of maximum prefix limit on their BGP session. By default, the max-prefix limit for IPv6 is 50. Exceeding this limit by advertising more than 50 routes will result in automatic shutdown of the BGP session. In such case, customer must contact the NOC to revive the session. Customers who provide transit to other ASes or have legitimate reasons for advertising more than 50 routes are placed on a higher threshold to satisfy their needs.
4. OCCAID by default will not accept any AS_PATHs containing a private number (64512-65535). For customers engaging in BGP without a public AS number, OCCAID will accept the prefix from private ASN, however will not propagate it to other internet networks. Customers engaging in BGP with a private AS number and advertising their own RIR allocated prefix will see their announcement get incorporated into AS30071 for origin AS.
IRR Policy
1. As of November 2005, OCCAID's route filtering management has become completely autonomous. This automatic maintenance of route filters is done by checking the Internet Routing Registry (IRR) records. Customers engaging in BGP with OCCAID must register their routes to IRR (route object for IPv4, route6 object for IPv6). Failure to register proper route objects may cause OCCAID to forcibly register them by proxy, on customer's behalf.
2. All of OCCAID's announcements to internet are recorded in the following AS-SET objects: (a) for IPv4, AS-OCCAID; and (b) for IPv6, AS-OCCAID6.
MED (Multi Exit Discriminator) Policy
1. OCCAID does not exchange MEDs with peers, as hot potato (closest exit routing) is implied. However, OCCAID may accept MEDs from peers who have agreed bilaterally with OCCAID to (a) cold potato or enter into non-closest-exit traffic exchange; and (b) provide reasonable assurance for quality of advertised MED values.
2. OCCAID advertises MEDs to customer BGP sessions, using good aggregates and meaningful values derived from IGP metrics. Customers may decide to honor these MEDs at their discretion.

Last updated: January 19, 2011

Copyright © 2005 OCCAID, Inc. All rights reserved.
About | Contact Us | Membership | Partnerships | News | Our Network | Initiatives