BGP Community Support For Google

Serving
Release Beta

January 28, 2014

Google Global Cache

ggc@google.com

Contents

Background

Supported Communities
2.1 Communities for Indicating Access Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Communities for Indicating Differentiated Product Offerings . . . . . . . . . . . . . . . . . . . . . .
2.3 Communities for Indicating Preferred Ingress Point . . . . . . . . . . . . . . . . . . . . . . . . . . .

3
3
4
4

Frequently Asked Questions

Appendix: Full Reference Table

ii

CHAPTER 1

Background

Google supports the exchange of BGP community tags with GGC nodes and peering sessions to signal important
properties of a route for reporting, load-balancing, or policy enforcement. All information exchanged should be
considered advisory: Google may discard any of this information if it conflicts with a higher-priority policy on the
Google network, for example receiving announcements from a more direct peer, or a manually configured override
agreed upon with our operations teams. Google will use reasonable efforts to honor the data provided, and in cases
where we receive this signalling it will be considered the highest priority indication of preference.
All communities supported by GGC/Google peerings are in the 15169: space, to avoid conflict with any communities already in use on your network. The same community tags can be used with GGC nodes as well as direct
interconnections to AS15169 or AS36040.
Note: All information in this document is subject to change.

BGP Community Support For Google Serving, Release Beta

Chapter 1. Background

CHAPTER 2

Supported Communities

2.1 Communities for Indicating Access Technology

The GGC software currently supports communities that will indicate the class of connectivity that clients have in the
last mile. From this information, the GGC serving system may make determinations about things like:
Buffering parameters in the stream sent to the client (controlling the amount that the server over-sends to the
client with the goal of minimizing the number of bytes wasted in serving to the client while maintaining a
high-quality user experience).
TCP parameters that may be more optimized for certain classes of connectivity.
Providing performance breakdowns by access technology in the Google Peering portal.
In cases where the connectivity level can vary among clients within a subnet, the provider should advertise all applicable technologies available to that subnet. Google encourages providing specific announcements that cover only a
single access technology per block, though, as these will provide the most useful reporting data.
The currently supported access technology communities are:

BGP Community Support For Google Serving, Release Beta

Table 2.1: Access Technology Communities

Community
15169:10010
15169:10020
15169:10030
15169:10040
15169:10050
15169:10060
15169:10070
15169:10080
15169:10090
15169:10100
15169:10110
15169:10120
15169:10130
15169:10140
15169:10150
15169:10160
15169:10170

Access Technology
GPRS Mobile Broadband
2.5G/Edge Mobile Broadband
3G Mobile Broadband
4G Mobile Broadband
Dial-Up
ISDN
Cable
Cable-Business
Ethernet/Enterprise Access
Fiber to the Home
Fiber to the Premises-Business
ADSL
ADSL-Business
VDSL
VDSL-Business
Wholesale/Transit- Not directly user-facing
Satellite

For any technologies that specify Business, this is meant as a distinction to refer to an access product marketed towards
business customers.

2.2 Communities for Indicating Differentiated Product Offerings

Google provides the ability for providers to get performance reporting by product. Products can be built inside the
peering.google.com product editor by matching against access technologies: if a company offers a Fiber and a DSL
product they can setup each as an independent product in the product editor. Performance reporting is available on a
per-product basis.
In the event that an ISP offers a differentiated offering using the same access type, a group of communities is provided
to help distinguish between them. In order for reporting to be provided, the prefixes must also be tagged with an access
technology community.
The range for product differentiation is 15169:11000 - 15169:11005.

2.3 Communities for Indicating Preferred Ingress Point

Google allows peers and ISPs hosting GGC servers to send advisory data indicating preference about traffic ingress
point into their networks. There are a number of other signals that Google takes into account when making trafficrouting decisions that may override this preference, though Google will attempt to honor this signal between equally
good routes.
Google has chosen to not use MEDs to reflect the fact that these policies are not routing-level priorities: they are
advisory and they can span multiple different interconnection types with Google.
The supported communities are:
15169:13000-13300: preference for receiving traffic at a particular ingress point for a particular block.
15169:13300 indicates the highest preference while 15169:13000 is the lowest priority. Multiple egress-points
can share the same preference and in this case Google will treat as being equally good choices from the perspective of the peer network. In the case that no tag is applied, 15169:13200 is assumed as the priority.

Chapter 2. Supported Communities

BGP Community Support For Google Serving, Release Beta

The same community tags can be used with GGC nodes as well as direct interconnections to AS15169 or AS36040.
When preference is expressed across different deployment types or different peer ASNs, they will be treated globally
across all inbound traffic to a particular ASN.
In all cases they are advisory only to express desired intent in terms of ingress traffic delivery. While Google will
make a best-effort attempt to deliver traffic in accordance with these preferences, the decision of how to egress traffic
from our networks takes many factors into account and may not reflect stated preference.
Table 2.2: Preferred Ingress Signalling Communities
Community
15169:13000

...
15169:13100
...

15169:13200
...
15169:13300

Preferred Ingress Signalling Range

Lowest preference to receive traffic for this prefix at this interconnection point (try
to not serve traffic here). Attempt to serve traffic on an indirect path (through other
upstreams or peers) before using this prefix.
15169:13001 - 15169:13099 indicate very low preference (the higher the tag the higher
the preference). Any prefix tagged in this range is less preferred than an indirect path.
Default priority of traffic on an indirect path. Tagging with this community indicates
that the preference is equal to receiving traffic over an indirect path.
15169:13101 - 15159:13199 indicate low preference. Any prefix tagged in this range
is preferred over indirect paths but not preferred to an interconnection point where the
prefix is untagged.
Default priority to receive traffic for this prefix at this interconnection point (the same
as if the prefix is untagged).
15169:13201 - 15169:13299 indicate high preference (the higher the tag the higher
the preference).
Highest preference to receive traffic for this prefix at this interconnection point (try to
serve traffic here).

2.3. Communities for Indicating Preferred Ingress Point

BGP Community Support For Google Serving, Release Beta

Chapter 2. Supported Communities

CHAPTER 3

Frequently Asked Questions

Q: What happens if Google receives inconsistent communities on the same prefix in multiple locations (GGC
nodes and/or PNIs)?
A: This depends on the community:
For access technology communities, we will assume that all communities received on any session apply (since
multiple access communities can be supplied on any prefix).
For preferred-ingress signalling, differing communities on different sessions is intended. The differentiation
allows you to specify which session has a high or low preference for serving a particular block.
Q: What happens if Google receives a community in one place, but not another?
A: This depends on the community:
For access technology communities, we will assume that all communities received on any session apply (since
multiple access communities can be supplied on any prefix).
For preferred-ingress signalling, any prefix that does not have a community is assumed to have the default
priority: 15169:13200.

BGP Community Support For Google Serving, Release Beta

Chapter 3. Frequently Asked Questions

CHAPTER 4

Appendix: Full Reference Table

Community
15169:10010
15169:10020
15169:10030
15169:10040
15169:10050
15169:10060
15169:10070
15169:10080
15169:10090
15169:10100
15169:10110
15169:10120
15169:10130
15169:10140
15169:10150
15169:10160
15169:10170

Access Technology Range

GPRS Mobile Broadband
2.5G/Edge Mobile Broadband
3G Mobile Broadband
4G Mobile Broadband
Dial-Up
ISDN
Cable
Cable-Business
Ethernet/Enterprise Access
Fiber to the Home
Fiber to the Premises-Business
ADSL
ADSL-Business
VDSL
VDSL-Business
Wholesale/Transit- Not directly user-facing
Satellite

Community
15169:11000
...
15169:11005

Product Differentiation Community

Product Differentiator #1
Product Differentiator #2 - #5
Product Differentiator #6

BGP Community Support For Google Serving, Release Beta

Community
15169:13000

...
15169:13100
...

15169:13200
...
15169:13300

10

Preferred Ingress Signalling Range

Lowest preference to receive traffic for this prefix at this interconnection point (try
to not serve traffic here). Attempt to serve traffic on an indirect path (through other
upstreams or peers) before using this prefix.
15169:13001 - 15169:13099 indicate very low preference (the higher the tag the higher
the preference). Any prefix tagged in this range is less preferred than an indirect path.
Default priority of traffic on an indirect path. Tagging with this community indicates
that the preference is equal to receiving traffic over an indirect path.
15169:13101 - 15159:13199 indicate low preference. Any prefix tagged in this range
is preferred over indirect paths but not preferred to an interconnection point where the
prefix is untagged.
Default priority to receive traffic for this prefix at this interconnection point (the same
as if the prefix is untagged).
15169:13201 - 15169:13299 indicate high preference (the higher the tag the higher
the preference).
Highest preference to receive traffic for this prefix at this interconnection point (try to
serve traffic here).

Chapter 4. Appendix: Full Reference Table