idnits 2.17.1 draft-ietf-idr-community-usage-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 152 has weird spacing: '...mmunity allow...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1996) is 10269 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '5' is defined on line 264, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (ref. '1') (Obsoleted by RFC 4271) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Enke Chen 3 Tony Bates 4 MCI 5 March 1996 7 An Application of the BGP Community Attribute 8 in Multi-home Routing 9 11 Status of this Memo 13 This document is an Internet Draft. Internet Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its Areas, 15 and its Working Groups. Note that other groups may also distribute 16 working documents as Internet Drafts. 18 Internet Drafts are draft documents valid for a maximum of six 19 months. Internet Drafts may be updated, replaced, or obsoleted by 20 other documents at any time. It is not appropriate to use Internet 21 Drafts as reference material or to cite them other than as a "working 22 draft" or "work in progress". 24 Please check the I-D abstract listing contained in each Internet 25 Draft directory to learn the current status of this or any other 26 Internet Draft. 28 Abstract 30 This document presents an application of the BGP community attribute 31 [2] in simplifying the implementation and configuration of routing 32 policies in the multi-provider Internet. It shows how the community 33 based configuration can be used to replace the AS-based customization 34 of the BGP "LOCAL_PREF" attribute, a common method used today. Not 35 only does the technique presented simplifies configuration and 36 management at the provider level, it also represents a paradigm shift 37 in that it gives the potential for the customer to control its own 38 routing policy with respect to its service provider, as well as 39 providing the ability for policy configuration to be done at a prefix 40 based granularity rather than the more common AS based granularity. 42 1. Introduction 44 In the multi-provider Internet, it is common for a service subscriber 45 (i.e., customer) to have more than one service provider, or to have 46 arrangements for redundant connectivity to the global connected 47 Internet. As discussed in [3], routing strategies in these cases 48 usually require coordination between the service subscriber and its 49 providers, which typically leads to customization of router 50 configurations (e.g., BGP "LOCAL_PREF") not only by the subscriber, 51 but also by its providers. Due to the large number of customers a 52 provider serves, customization of router configurations at the 53 provider level may present management and scalability problems. 55 This document presents an application of the BGP community attribute 56 in simplifying the implementation of routing strategies in the multi- 57 provider Internet. More specifically, the technique presented uses a 58 community-based, rather than the common AS-based, configuration of 59 the BGP "LOCAL_PREF". It essentially removes the need for customized 60 configuration of the BGP "LOCAL_PREF" attribute at the provider level 61 while maintaining the same level of routing functionality and 62 flexibility. 64 It also represents a paradigm shift in that it gives the potential 65 for the customer to control its own routing policy with respect to 66 its service provider, as well as providing the ability for policy 67 configuration to be done at a prefix based granularity rather than 68 the more common AS based granularity in use today. 70 2. AS-based Configuration and its Drawbacks 72 As discussed in [3], in today's multi-provider Internet, customized 73 configuration of the BGP "LOCAL_PREF" attribute is often required to 74 implement common routing strategies such as load-sharing or backup. 75 There are two main reasons: 77 o Lack of available implementations and deployment of routing 78 software that supports the "Destination Preference Attribute" 79 (DPA) as specified in [4]. 81 DPA allows one to specify a globally transitive preference so 82 that return traffic favors certain path. As discussed in [3], 83 the attribute will be very useful in influencing route selection 84 for routes with identical "LOCAL_PREF" and equal AS-path length. 86 o In the multi-provider Internet, it is common for a provider 87 to assign higher BGP "LOCAL_PREF" values for routes from its 88 customers than from other service providers. This practice 89 provides some degree of protection for its customer routes, 90 and it facilitates implementation of certain routing 91 strategies. It, however, also complicates other routing 92 implementations such as backup arrangement, thus, requiring 93 customized "LOCAL_PREF" configuration. 95 Figure 1 shows a typical case of a backup arrangement in the multi- 96 provider Internet. In Figure 1, AS1 and AS2 are both providers, and 97 AS3 and AS4 are customers of AS1 and AS2, respectively. AS3 has 98 entered a bilateral agreement with AS4 to provide backup to each 99 other. That is, AS3 would use its direct link to AS4 to reach only 100 AS4 in the normal circumstance, and for transit in the case of a 101 failure between AS3 and AS1. To realize this routing agreement, AS3 102 requests that its provider AS1 adjust its BGP "LOCAL_PREF" 103 configuration so that AS1 reaches AS4 via AS2. 105 +------+ +------+ 106 | AS1 |------| AS2 | 107 +------+ +------+ 108 | | 109 +------+ +------+ 110 | AS3 |------| AS4 | 111 +------+ +------+ 113 Figure 1: Typical Backup Scenario 115 Primarily due to scalability and management concerns, most providers 116 only perform "LOCAL_PREF" customization based on ASs, not on IP 117 prefixes. If IP prefix-based "LOCAL_PREF" configuration is needed, a 118 technique known as as the BGP AS-path manipulation can be used. 119 However, it is currently only available in certain vendor's products. 121 There are several drawbacks with the the practice of AS-based BGP 122 "LOCAL_PREF" configuration at the provider level: 124 o The implementation tends to less efficient due to the process 125 of coordination and configuration. More importantly, the 126 process needs to be repeated each time a change (e.g., adding 127 a new AS) occurs. 129 o The AS-based customization complicates router configuration 130 and increases complexity of network operation. It has become 131 a serious scalability issue for providers. 133 o It can not implement prefix-based configuration without the 134 AS-path manipulation (i.e., using fake AS). 136 o Keeping configuration up-to-date is some times problematic. 138 3. How the BGP Community Attribute Can Help 140 3.1 Overview of the Community Attribute 142 The BGP community path attribute is an optional transitive attribute 143 of variable length [1,2]. The attribute consists of a set of four 144 octet values, each of which specify a community. The community 145 attribute values are encoded using an AS number in the first two 146 octets, with the remaining two octets defined by the AS. As defined 147 in [2], a community is a group of destinations (i.e. prefixes) that 148 share some common attribute. Each destination can belong to multiple 149 communities. All prefixes with the community attribute belong to the 150 communities listed in the attribute. 152 The BGP community allows one to group a set of prefixes and perform 153 routing decisions based on the identity of the group. 155 The well-known communities NO_EXPORT (0xFFFFFF01) and NO_ADVERTISE 156 (0xFFFFFF02) are intuitive, and can be used for optimizing routing 157 and for improving route aggregation. 159 3.2 Community-based Configuration 161 With the BGP community attribute [2], a provider can now use 162 community-based, rather than AS-based, configuration of BGP 163 "LOCAL_PREF". The provider first needs to coordinate with its 164 customers a set of communities to be mapped to certain BGP 165 "LOCAL_PREF" values. The provider can then apply a uniform BGP 166 configuration to all its customers that would capture routes with the 167 community values, and set up the appropriate BGP "LOCAL_PREF" values 168 accordingly. A customer that requires customization in its provider 169 BGP "LOCAL_PREF" configuration can simply send the appropriate 170 community values in its routing announcements. 172 The major advantages of using this technique include: 174 o The customer has full control in the process, which makes a 175 lot of sense as the customer is in a position to have better 176 understanding about its own topology and routing policy 177 requirement. 179 o The effect of route-based customization in BGP "LOCAL_PREF" 180 configuration by providers can now be achieved, thus, removing 181 the need of AS-Path manipulation in certain cases. 183 o It addresses the scalability issue facing providers as it 184 distributes the configuration work to the customer that 185 requires customization. 187 4. A Real-World Implementation Example 189 MCI currently makes heavy use of the BGP "LOCAL_PREF" attribute value 190 as part of its routing policy configuration process. Different BGP 191 "LOCAL_PREF" values are assigned for routes from different sources. 192 Table 1 details these values: 194 +-------------------------+------------+ 195 | Category | LOCAL_PREF | 196 +-------------------------+------------+ 197 |Customer Routes | 100 | 198 |Customer backup Routes | 90 | 199 |Other ISP Routes | 80 | 200 |Customer-Provided backup | 70 | 201 +-------------------------+------------+ 203 Table 1: Defined LOCAL_PREF Values 205 Note: 207 o The value '100' is the default value used within our network 208 configuration. 210 o In most cases, the MED attribute set by a customer is 211 sufficient for customer backup routes (e.g., T1 backs up T3). 212 However, in certain cases configuration of "LOCAL_PREF" will 213 still be necessary until the BGP DPA attribute is available. 215 To make use of the BGP community attribute, several community values 216 (MCI's AS number: 3561 = 0x0DE9) have been defined that can be used 217 by customers to tag routes so that the appropriate "LOCAL_PREF" val- 218 ues are configured. Table 2 lists the appropriate community attribute 219 values (and the mappings of community to LOCAL_PREF): 221 +---------------------+------------+ 222 | community | LOCAL_PREF | 223 +---------------------+------------+ 224 |3561:70 (0x0DE90046) | 70 | 225 |3561:80 (0x0DE90050) | 80 | 226 |3561:90 (0x0DE9005A) | 90 | 227 +---------------------+------------+ 229 Table 2: Community to LOCAL_PREF Mapping 231 A customer requiring MCI to configure BGP "LOCAL_PREF" values other 232 than the default can tag their routes with the defined communities. 233 The community values can be configured either based on an AS path 234 list or an IP address access list. A cisco systems software specific 235 configuration example is given in Appendix A to show how this can be 236 achieved. 238 A uniform BGP configuration (see Appendix B, again cisco systems 239 software specific) is applied by MCI to peers with customers that 240 configure the appropriate "LOCAL_PREF" values based on the communi- 241 ties received. 243 This technique has been tested and is in use with several customers, 244 and the response has been very positive. We are in the process of 245 migrating all other customized BGP "LOCAL_PREF" configurations to 246 this uniform community based configuration approach. 248 5. References 250 [1] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)", 251 RFC1771, March 1995. 253 [2] Chandra, R., Traina, P., and Li, T., "BGP Communities Attribute", 254 INTERNET-DRAFT, , April 1995. 256 [3] Chen, E., and Bates, T., "Current Practice of Implementing Sym- 257 metric Routing and Load Sharing in the Multi-Provider Internet", 258 INTERNET-DRAFT, , January 259 1996. 261 [4] Chen, E., and Bates, T., "Destination Preference Attribute for 262 BGP", INTERNET-DRAFT, , February 1996. 264 [5] Chen, E., and Bates, T., "Application of the BGP Destination 265 Preference Attribute in Implementing Symmetric Routing", INTERNET- 266 DRAFT, , January 1996. 268 [6] cisco systems, cisco IOS Software Version 10.3 Router Products 269 Configuration Guide (Addendum), May 1995. 271 6. Security Considerations 273 Security considerations are not discussed in this memo. 275 7. Acknowledgments 277 The authors would specifically like to thank Ravi Chandra, Tony Li 278 and Paul Traina of cisco systems for devising and implementing the 279 community attribute. 281 8. Author's Addresses 283 Enke Chen 284 MCI 285 2100 Reston Parkway 286 Reston, VA 22091 288 phone: +1 703 715 7087 289 email: enke@mci.net 291 Tony Bates 292 MCI 293 2100 Reston Parkway 294 Reston, VA 22091 296 phone: +1 703 715 7521 297 email: Tony.Bates@mci.net 299 Appendix 301 These appendices list cisco systems software specific configuration 302 examples for configuring communities, and for uniform route-map defi- 303 nition that sets up the appropriate "LOCAL_PREF" values based on the 304 corresponding community values. These examples are given purely to 305 show a working example of how the desired effect discussed in this 306 document can be achieved. Please refer to [6] for more specific 307 information on cisco configuration and syntax. 309 Appendix A. community Configuration 311 The community values can be configured either based upon an AS path 312 list or based an IP address access list. Here is an example that 313 includes both cases: 315 !! 316 router bgp xxxx 317 neighbor x.x.x.x remote-as 3561 318 neighbor x.x.x.x filter-list 20 out 319 neighbor x.x.x.x route-map config-community out 320 neighbor x.x.x.x send-community 321 ! 322 !!# match all 323 ip as-path access-list 1 permit .* 324 ! 325 !!# list of customer ASs 326 ip as-path access-list 20 permit ^$ 327 ip as-path access-list 20 permit ^64700_ 328 ip as-path access-list 20 deny .* 329 ! 330 !!# AS path based matching, backup for another ISPs customer 331 ip as-path access-list 40 permit _64710_ 332 ip as-path access-list 40 permit _64711_ 333 ip as-path access-list 40 deny .* 334 ! 335 !!# route-map 336 route-map config-community permit 10 337 match as-path 40 338 set community 0x0DE90046 339 route-map config-community permit 20 340 match as-path 1 341 ! 342 Note: The community can also be configured based on IP prefixes 343 instead of AS numbers. For example, 345 ! 346 access-list 101 permit ip 192.160.154.0 0.0.0.0 255.255.255.0 0.0.0.0 347 ! 348 route-map config-community permit 10 349 match ip address 101 350 set community 0x0DE90046 351 route-map config-community permit 20 352 match as-path 1 353 ! 355 Appendix B. Uniform Route-map Configuration 357 Here is the uniform route-map that can be used for all BGP customers: 359 !!# routes primary via another ISP 360 ip community-list 70 permit 0x0DE90046 361 ip community-list 70 deny 362 ! 363 !!# routes also homed to another ISP, but with DPA or 364 !!# AS-path length as the tie-breaker 365 ip community-list 80 permit 0x0DE90050 366 ip community-list 80 deny 367 ! 368 !!# customer backup routes 369 ip community-list 90 permit 0x0DE9005A 370 ip community-list 90 deny 371 ! 372 !!# the route-map applied to BGP customers 373 route-map set-customer-local-pref permit 10 374 match community 70 375 set local-preference 70 376 route-map set-customer-local-pref permit 20 377 match community 80 378 set local-preference 80 379 route-map set-customer-local-pref permit 30 380 match community 90 381 set local-preference 90 382 route-map set-customer-local-pref permit 40 383 match as-path 1 384 set local-preference 100 385 !