RFC 1998

RFC 1998: An Application of the BGP Community Attribute in Multi-home Routing 🎀

Okay bestie, let's get the basics straight first 💅 This is from the Network Working Group, and it's Informational, which means it shares info with the Internet community. It is not a standard. It came out in August 1996 🕰️ and the authors are:

• E. Chen from MCI 🌸
• T. Bates from cisco Systems 🦋

It doesn't obsolete or update any other RFCs (none are listed in its title block), so it's a standalone read 📖

Status of This Memo 📜

This memo gives info to the Internet community. It does not specify an Internet standard of any kind, so no pressure 🫶 Distribution of this memo is unlimited ✨

Abstract 🌟

So this doc shows off how the BGP community attribute [2] can make routing policies way easier to set up and manage across the multi-provider Internet 🌐 Right now a super common move is customizing the BGP LOCAL_PREF attribute on an AS basis, and this doc says community-based config can replace that. It doesn't just simplify configuration and management at the provider level. It's also a paradigm shift 🤯 because the customer gets the potential to control its own routing policy with respect to its service provider. On top of that, policy config can be done at a prefix-based granularity instead of the more common AS-based granularity. Iconic, honestly 👑

1. Introduction ✨

In the multi-provider Internet, it's really common for a service subscriber (aka customer) to have more than one service provider, or to have set up redundant connectivity to the global connected Internet 🌍 As discussed in [3], routing strategies in these situations usually need coordination between the subscriber and its providers. That coordination typically leads to customized router configs (like BGP LOCAL_PREF), and not just from the subscriber. The providers customize too 😩 Since a provider serves a huge number of customers, customizing router configs at the provider level can cause management and scalability problems.

This doc presents an application of the BGP community attribute to make routing strategies easier to implement in the multi-provider Internet 💖 The main move here is using community-based configuration of BGP LOCAL_PREF instead of the usual AS-based version. The big win is that providers no longer need customized LOCAL_PREF config, and you still get the same level of routing functionality and flexibility. Lowkey genius 🧠

It's also a paradigm shift 🦋 Customers can control their own routing policy with respect to their service provider, and policy config can be done at prefix-based granularity instead of the AS-based granularity that's the norm today.

2. AS-based Configuration and its Drawbacks 🥀

As discussed in [3], customized BGP LOCAL_PREF config is often needed in today's multi-provider Internet to set up common routing strategies like load-sharing or backup. There are two main reasons why:

• Lack of available implementations and deployment of routing software that supports the "Destination Preference Attribute" (DPA) as specified in [4].
  • DPA lets you specify a globally transitive preference so that return traffic favors a certain path. As discussed in [3], this attribute is going to be super useful for influencing route selection when routes have identical LOCAL_PREF and equal AS-path length 🔥
• In the multi-provider Internet, it's common for a provider to assign higher BGP LOCAL_PREF values to routes from its customers than to routes from other service providers. This gives some protection to customer routes and makes certain routing strategies easier to implement. The catch is that it also complicates other routing setups, like backup arrangements, which means customized LOCAL_PREF config is needed 😭

Figure 1 is a classic backup case in the multi-provider Internet 🎀 AS1 and AS2 are both providers, and AS3 and AS4 are customers of AS1 and AS2 respectively. AS3 and AS4 have a bilateral agreement to back each other up. In normal conditions, AS3 uses its direct link to AS4 to reach only AS4. If there's a failure between AS3 and AS1, AS3 uses that link for transit instead. To make this work, AS3 asks its provider AS1 to adjust its BGP LOCAL_PREF config so that AS1 reaches AS4 via AS2 🧚

                          +------+      +------+
                          | AS1  |------| AS2  |
                          +------+      +------+
                             |             |
                          +------+      +------+
                          | AS3  |------|  AS4 |
                          +------+      +------+

                     Figure 1: Typical Backup Scenario

Mostly because of scalability and management concerns, most providers only do LOCAL_PREF customization based on ASs, not on IP prefixes 🙈 If you do need prefix-based LOCAL_PREF config, you can use a technique called BGP AS-path manipulation. The catch? It's currently only available in certain vendors' products 💀

There are several drawbacks to AS-based BGP LOCAL_PREF config at the provider level, and they're honestly kind of a mess 😩

• The implementation tends to be less efficient because of the coordination and configuration process. Even worse, the whole process has to be repeated every time something changes (like adding a new AS).
• AS-based customization complicates router configuration and increases the complexity of network operation. It's become a serious scalability issue for providers.
• Prefix-based configuration can't be done without AS-path manipulation (aka using a fake AS).
• Keeping configuration up-to-date is sometimes problematic 🫠

3. How the BGP Community Attribute Can Help 💜

3.1 Overview of the Community Attribute 🦋

The BGP community path attribute is an optional transitive attribute of variable length [1,2]. It's made up of a set of four octet values, and each one specifies a community. The community attribute values encode an AS number in the first two octets, and the remaining two octets are defined by that AS. As defined in [2], a community is a group of destinations (i.e., prefixes) that share some common attribute. Each destination can belong to multiple communities, and all prefixes carrying the community attribute belong to the communities listed in it 🧩

The BGP community lets you group a set of prefixes and make routing decisions based on the identity of that group. Main character energy for prefixes 👑

The well-known communities NO_EXPORT (0xFFFFFF01) and NO_ADVERTISE (0xFFFFFF02) are super intuitive 💅 They can be used for optimizing routing and for improving route aggregation ✨

3.2 Community-based Configuration 🌈

With the BGP community attribute [2], a provider can now use community-based configuration of BGP LOCAL_PREF instead of AS-based configuration 🎀 First, the provider has to coordinate with its customers on a set of communities that get mapped to certain BGP LOCAL_PREF values. Then the provider can apply one uniform BGP config to all its customers. That config captures routes carrying those community values and sets the matching LOCAL_PREF values. If a customer needs customization in its provider's BGP LOCAL_PREF config, it can simply send the right community values in its routing announcements 💖

The major advantages of this technique include:

• The customer has full control of the process, and that makes a lot of sense, because the customer understands its own topology and routing policy requirements way better 🫶
• Route-based customization of BGP LOCAL_PREF config by providers can now be achieved, which removes the need for AS-path manipulation in certain cases 🔥
• It tackles the scalability issue facing providers, since the configuration work gets distributed to the customers who need the customization 🙌

5. References 📚

Okay bestie, here are the receipts for all the sources this doc leans on 🧾

• [1] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
• [2] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996.
• [3] Chen, E., and T. Bates, "Current Practice of Implementing Symmetric Routing and Load Sharing in the Multi-Provider Internet", Work in Progress.
• [4] Chen, E., and T. Bates, "Destination Preference Attribute for BGP", Work in Progress.
• [5] Chen, E., and T. Bates, "Application of the BGP Destination Preference Attribute in Implementing Symmetric Routing", Work in Progress.
• [6] cisco systems, cisco IOS Software Version 10.3 Router Products Configuration Guide (Addendum), May 1995.

---

6. Security Considerations 🚨

Real talk: this memo does not discuss security issues at all. So go in knowing that, and don't assume it covers security for you 💀

---

7. Acknowledgments 🫶

The authors wanna give a huge shoutout to Ravi Chandra, Tony Li and Paul Traina of cisco systems. They're the ones who came up with and built the community attribute, so honestly, icons 👑

---

8. Authors' Addresses 💌

Here's where you can find the authors. Slide into their inboxes if you have questions 💅

Enke Chen
MCI
2100 Reston Parkway
Reston, VA 22091

Phone: +1 703 715 7087
EMail: enke@mci.net


Tony Bates
cisco Systems
170 West Tasman Drive
San Jose, CA 95134

Phone: +1 408 527 2470
EMail: tbates@cisco.com

---

Appendix 🎀

Okay so these appendices show off some cisco systems specific config examples. They cover setting up communities, and a uniform route-map that sets the right "LOCAL_PREF" values based on the community values. These are only here to show a working example of how the effect described in this doc can actually be pulled off ✨ For the deeper cisco config and syntax details, go check out [6] 🤓

---

Appendix A. Community Configuration 🦋

The community values can be set up either based on an AS path list or an IP address access list. Here's one example that shows off both approaches 🌸

!!
router bgp xxxx
neighbor x.x.x.x remote-as 3561
neighbor x.x.x.x filter-list 20 out
neighbor x.x.x.x route-map config-community out
neighbor x.x.x.x send-community
!
!!# match all
ip as-path access-list 1 permit .*
!
!!# list of customer ASs
ip as-path access-list 20 permit ^$
ip as-path access-list 20 permit ^64700_
ip as-path access-list 20 deny .*
!
!!# AS path based matching, backup for another ISPs customer
ip as-path access-list 40 permit _64710_
ip as-path access-list 40 permit _64711_
ip as-path access-list 40 deny .*
!
!!# route-map
route-map config-community permit 10
match as-path 40
set community 0x0DE90046
route-map config-community permit 20
match as-path 1
!

Heads up 👀 you can also set the community based on IP prefixes instead of AS numbers. Here's what that looks like:

!
access-list 101 permit ip 192.160.154.0 0.0.0.0 255.255.255.0 0.0.0.0
!
route-map config-community permit 10
match ip address 101
set community 0x0DE90046
route-map config-community permit 20
match as-path 1
!

---

Appendix B. Uniform Route-map Configuration 💖

Here's the uniform route-map you can use for all BGP customers. It's giving organized 🧚

!!# routes primary via another ISP
ip community-list 70 permit 0x0DE90046
ip community-list 70 deny
!
!!# routes also homed to another ISP, but with DPA or
!!# AS-path length as the tie-breaker
ip community-list 80 permit 0x0DE90050
ip community-list 80 deny
!
!!# customer backup routes
ip community-list 90 permit 0x0DE9005A
ip community-list 90 deny
!
!!# the route-map applied to BGP customers
route-map set-customer-local-pref permit 10
match community 70
set local-preference 70
route-map set-customer-local-pref permit 20
match community 80
set local-preference 80
route-map set-customer-local-pref permit 30
match community 90
set local-preference 90
route-map set-customer-local-pref permit 40
match as-path 1
set local-preference 100
!

That's a wrap, bestie! 🌈✨ You made it through the whole RFC 1998 glow-up 💅💜