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]
0	ALL
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 Oakland	SFO (snfc01, snfc02), PAO (plal01), SJC (snjs01, snjs02)
701	KZBW Boston	BOS (bstn01, bstn02, somv01), CEF (chcp01), BED (wlhm01), MHT (mcnh01)
702	KZNY New York	EWR (nwrk01, whkn01, hbkn01, jrcy01), LGA (nycm01)
703	KZMA Miami	BCT (bcrt01), MIA (miat01), TPA (tamr01)
704	KZFW Fort Worth	DFW (dlls01)
705	KZAU Chicago	ORD (chcg01, chcg02, okbr01)
706	KZDC Washington DC	IAD (asbn01, stng01), DCA (wadc01), RDU (rlgh01)
707	KZTL Atlanta	ATL (atln01)
708	KZJX Jacksonville	JAX (jksn01)
709	KZKC Kansas City	MCI (kscy01)
710	KZLA/KZLX Los Angeles	LAX (lsan01, elsg01, irvn01, psdn01, lsan02), SAN (sndg01)
711	KZHU Houston	IAH (hstn01)
712	KZDV Denver	DEN (dnvr01)
713	KZOB Cleveland	CLE (clvn01), ROC (rcny01)
714	KZSE Seattle	SEA (sttl01)
790	CZEG Edmonton	YEG (edtn01)
791	CZYZ Toronto	YYZ (trnt01)
792	CZVR Vancouver	YVR (vanc01)
8..	EUC	European FIRs
800	ESAA Sweden	ARN (stkh01, stkh02)
801	EGTT London	LHR (lndn01, lndn02)
802	EHAA Amsterdam	AMS (amst01, amtn01)
803	EBUR Brussels	BRU (brus01)
804	LPPC Lisboa	LIS (lisb01)
805	EDDU Rhein	FRA (frnk01), MUC (mucn01)
806	LIMM Milano	MXP (miln01), BGY (brgm01)
807	LZBB Bratislava	BTS (brts01)
9..	ASP	Asia-Pacific FIRs
900	RJTI Tokyo	NRT (tokj01)
901	RJOO Osaka	KIX (oskj01)
910	RKRR Incheon	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.