BGP Community Support For Google Serving Release Beta
January January 28, 2014
Google Global Cache
[email protected]
Contents
1
Background
1
2
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
3
Frequently Asked Questions
7
4
Appendix: Full Reference Table
9
i
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.
1
BGP Community Support For Google Serving, Release Beta
2
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:
3
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.
4
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 verylow preference(the higher thetag 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
5
BGP Community Support For Google Serving, Release Beta
6
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.
7
BGP Community Support For Google Serving, Release Beta
8
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
9
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 verylow preference(the higher thetag 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
