idnits 2.17.1 draft-ietf-idr-symm-multi-prov-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-24) 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. ** There are 9 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 245 has weird spacing: '...rs) and defau...' -- 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 (May 1995) is 10572 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: '2' is defined on line 449, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 459, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 462, 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. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Downref: Normative reference to an Informational RFC: RFC 1787 (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 6 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 May 1995 7 Analysis and Critique of the Current 8 Practice of Implementing Symmetric Routing 9 in the Multi-Provider Internet 10 12 Status of this Memo 14 This document is an Internet Draft. Internet Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its Areas, 16 and its Working Groups. Note that other groups may also distribute 17 working documents as Internet Drafts. 19 Internet Drafts are draft documents valid for a maximum of six 20 months. Internet Drafts may be updated, replaced, or obsoleted by 21 Internet Drafts are draft documents valid for a maximum of six 22 months. Internet Drafts may be updated, replaced, or obsoleted by 23 other documents at any time. It is not appropriate to use Internet 24 Drafts as reference material or to cite them other than as a "working 25 draft" or "work in progress". 27 Please check the I-D abstract listing contained in each Internet 28 Draft directory to learn the current status of this or any other 29 Internet Draft. 31 Abstract 33 In the current multi-provider Internet, it is common for an entity to 34 have multiple service providers. Symmetric routing becomes 35 increasingly important for various reasons. This memo documents and 36 analyzes the current practice in implementing symmetric inter-domain 37 routing using BGP for several representative topologies of Internet 38 connections. 40 1. Introduction 42 In the multi-provider Internet, it is common for an entity to have 43 multiple service providers. These connections would provide for the 44 capability of load sharing, path diversification and backup. 46 Symmetric routing is generally preferred as it facilitates problem 47 resolution, and provides for better resource (especially network 48 capacity) planning and utilization. Routing symmetry is also 49 desirable in achieving optimal traffic flow in terms of reliability, 50 delay character, cost and other QoS metrics. In the multi-provider 51 Internet, routing asymmetry, especially at the inter-domain level, 52 could have serious economic and legal ramifications. 54 This paper presents several representative topologies of Internet 55 connection and their inter-domain routing requirements. It then 56 documents and analyzes the current practice in implementing symmetric 57 inter-domain routing in these cases using BGP. 59 This paper assumes that in general an ISP treats other ISPs equally 60 (in terms of the "local_pref" parameter) in the route selection 61 process. It also assumes that the following order of preference is 62 followed for the purpose of route selection: first the "local_pref" 63 parameter, followed by the shortest AS-path, the MED, and the IGP 64 metric. 66 It is noted that the length of the AS-path has not been specified in 67 the BGP document [1] as a route selection criteria. However, it has 68 been included in more than one implementations, and has been widely 69 used as such. 71 2. Internet Connection and Routing 73 The Internet is a mesh of transit Internet Service Providers (ISPs), 74 Regional Service Providers (RSPs), and service subscribers. In 75 general this mesh is rather sparsely connected with loose hierarchy. 76 In the multi-provider Internet, a good routing plan for an entity 77 (i.e., autonomous system) requires good understanding of its internal 78 network topology, its connection to direct providers (and neighboring 79 ASs), and its path to the major interconnection points (or network 80 access points, NAPs). 82 In this section, we present several typical topologies of Internet 83 connections, and their inter-domain routing requirements. Although 84 these cases are not meant to be exhaustive, they are expected to 85 cover the vast majority of Internet connection topologies. 87 2.1 An Entity with a Single Direct Provider 89 +-----+ +-----+ +-----+ 90 | ISP | | ISP | | ISP | 91 +-----+ +-----+ +-----+ 92 | | | 93 +-----+ +-----+ +-----+ 94 | AS1 | | RSP | | RSP | 95 +-----+ +-----+ +-----+ 96 | 97 +-----+ 98 | AS1 | 99 +-----+ 101 (a) (b) (c) 103 Figure 1 105 The routing is always symmetric at the inter-domain level. Routing 106 policies can be achieved using the current version of BGP. AS1 can 107 either take full routing or use default. 109 2.2 Backup of Entities with Different Direct Providers 111 Several topologies are shown in Figure 2. Both AS1 and AS2 have 112 their direct provider(s), and they would like to backup each other. 113 That is, if the link between AS1 and its direct provider is down, the 114 link between AS1 and AS2 would be used to reach the Internet. 116 +-----+ +------+ +------+ 117 | ISP | | ISP3 | | ISP3 | 118 +-----+ +------+ +------+ 119 / \ / \ / \ 120 / \ / (NAP) \ / (NAP) \ 121 +-----+ +-----+ +------+ +------+ +------+ +------+ 122 | AS1 |----| AS2 | | ISP1 |------| ISP2 | | ISP1 |-------| ISP2 | 123 +-----+ +-----+ +------+ +------+ +------+ +------+ 124 | | | | 125 +------+ +------+ +------+ +------+ 126 | AS1 |------| AS2 | | RSP1 | | RSP2 | 127 +------+ +------+ +------+ +------+ 128 | | 129 +------+ +------+ 130 | AS1 |------| AS2 | 131 +------+ +------+ 133 (a) (b) (c) 135 Figure 2 137 Note that in Figures 2(a)-2(b), AS1 and AS2 could be RSPs. 139 In all cases of Figure 2, in order to provide for backup, AS1 needs 140 to receive AS2's routes from both AS2 and its direct provider, and 141 permit their announcements to its direct providers. Similar 142 configuration is required for AS2. 144 There are two common routing policies depending upon how the link 145 between AS1 and AS2 is used. 147 Policy 1: Used solely as a backup link 149 The routing policy can be implemented by coordinating AS-based 150 "local_pref" values between neighboring ASs. 152 In all cases of Figure 2, the "local_pref" value for the peer of 153 AS1 or AS2 with its direct provider shall be higher than that for 154 the peer between AS1 and AS2. Either full routing or partial 155 routing can be configured. 157 For example, in Figure 2(a), AS1 can take full routing from ISP 158 and AS2. An alternative is for AS1 to take only AS2's routes 159 from ISP and AS2, and configure default routes (with different 160 weights) at its border routers and then propagate them into its 161 own AS (via, e.g., iBGP). The ISP needs to make sure that the 162 "local_pref" values are equal for the peers with AS1 and AS2 so 163 that the shorter AS-path would be selected. 165 Policy 2: Used for traffic between AS1 and AS2, and as backup in gen- 166 eral 168 In general this routing policy can be implemented by coordinating 169 AS-based "local_pref" values among the neighboring ASs and direct 170 providers. 172 In Figure 2(a), equal "local_pref" values could be configured for 173 all the peers. Then the length of AS path would be used as tie- 174 breaker in the route selection. AS1 can either take full routing 175 from AS2 and its direct provider. It can also choose to take only 176 AS2's routes from its direct provider and AS2, and configure 177 default routes (with a different weights) at its border routers 178 and then propagate them into its own AS (via, e.g., iBGP). Simi- 179 lar configuration for AS2. 181 In Figures 2(b)-(c), AS1 can either take full routing from AS2 and 182 its direct provider, and configure the "local_pref" parameter so 183 that traffic to AS2 prefers the AS1 - AS2 link over the link to 184 its direct provider. AS1 can choose to take only AS2's routes from 185 its direct provider and AS2, and configure default routes (with 186 different weight) at its border routers and then propagate them 187 into its own AS (via, e.g., iBGP). Similar configuration for AS2. 189 AS1's direct provider (and possible its ISP) needs to configure 190 the "local_pref" parameter so that traffic to AS2 does not prefer 191 the link to AS1. Similar configuration is required for AS2's 192 direct provider. 194 2.3 An Entity with Multiple Direct Providers 196 As shown in Figure 3, AS1 has two direct providers. X and Y are 197 routes of AS1. Note that AS1 could be an RSP. 199 +------+ +-----+ +------+ 200 | ISP3 | | ISP | | ISP3 | 201 +------+ +-----+ +------+ 202 / \ / \ / \ 203 / (NAP) \ / \ / (NAP)\ 204 +------+ +------+ +------+ +------+ +------+ +-----+ 205 | ISP1 |------| ISP2 | | RSP1 | | RSP2 | | ISP1 |-----| ISP2| 206 +------+ +------+ +------+ +------+ +------+ +-----+ 207 \ / \ / | | 208 \L1 /L2 \L1 /L2 | | 209 +------+ +------+ +------+ +-----+ 210 | AS1 | | AS1 | | RSP1 | | RSP2| 211 |X Y| |X Y| +------+ +-----+ 212 +------+ +------+ \ / 213 \L1 /L2 214 +------+ 215 | AS1 | 216 |X Y| 217 +------+ 219 (a) (b) (c) 221 Figure 3 223 Depending upon the quality of these links and the internal network 224 topology of the AS, there are several common routing policies. 226 Policy 1: One link is used as primary, the other as pure backup 228 This policy is common when the quality of these links differ dra- 229 matically. 231 This policy can be implemented by coordinating AS-based 232 "local_pref" values between the entity and its direct providers. 233 The AS can either take full routing or use default routes. In the 234 case of default, each border router can configure a default route 235 and then propagate it into the AS (via, e.g., iBGP). 237 Policy 2: Each link is used for traffic with the respective direct 238 provider. In general one link is used as primary, and the other as 239 backup. 241 If the traffic between AS1 and its direct providers (and their 242 customers) shall take the direct link, AS1 needs to be configured: 244 o either with partial routing (only routes of the direct 245 providers and their customers) and defaults with different 246 weights. 248 o or with full routing and configure AS-based "local_pref" val- 249 ues. 251 The difficulty is that the indirect providers (e.g., ISP3 in 252 Figure 3(a)) may have to be involved to achieve symmetric rout- 253 ing. More specifically, 255 o In Figure 3(a), ISP3 would receive routes X and Y from both 256 ISP1 and ISP2 with identical length of AS paths. In order 257 for L1 to be favored by ISP3 to AS1, ISP1 would need to 258 manipulate the AS-path length, which is discussed in Section 259 3.1. Another approach is for ISP3 to configure AS-based 260 "local_pref" parameter, which certainly does not scale well 261 as there are many ISPs at an NAP. In addition, it is almost 262 impossible to do as AS1 is not a customer of ISP3. 264 o In Figure 3(b), ISP would receive routes X and Y from both 265 RSP1 and RSP2 with identical length of AS paths. Either RSP1 266 needs to manipulate the AS-path length, or ISP needs to con- 267 figure AS-based "local_pref" parameter. 269 o In Figure 3(c), ISP1 would receive routes X and Y from both 270 RSP1 and ISP2. In order for traffic from ISP1 to AS1 to 271 favor the ISP1 - ISP2 link, either RSP1 needs to manipulate 272 the AS-path length, or ISP1 needs to configure AS-based 273 "local_pref" parameter. 275 Another problem is that it is difficult for AS1 to implement 276 "full routing", as AS1 needs to update the AS list for the 277 "local_pref" parameter each time its direct providers acquire a 278 new AS as a customer. Nevertheless, some entities still prefer 279 full routing. 281 Policy 3: Partial load-sharing among these links 283 That is, the direct link is used for traffic between AS1 and its 284 direct providers including its customers. However, the closest 285 exit point would be taken for traffic beyond these direct 286 providers and their customers. For example, in Figure 3(a) traffic 287 between AS1 and ISP1 (and its customers) would use the direct link 288 between AS1 and ISP1; traffic between AS1 and ISP2 (and its cus- 289 tomers) would use the direct link between AS1 and ISP2. For traf- 290 fic destined to ISP3, either ISP1 or ISP2 would be used depending 291 on where the traffic is originated in AS1. 293 AS1 can take full routing. It can also take partial routing 294 (routes of direct providers and their customers), and configure 295 equal-weight default routes at its border routers and propagate 296 them into its AS. 298 The problem is how to make sure the return traffic from a 4th 299 party (e.g., ISP3 in Figure 3(a)) is symmetric. 301 Policy 4: Complete load-sharing among these links 303 That is, each network in AS1 sends packets to the closer (in terms 304 of internal route preference) border router that peers with a 305 direct providers. The return traffic is expected to take a sym- 306 metric path. For example, in Figure 3(a) a packet, which is orig- 307 inated from network X and is destined outside AS1, would be for- 308 warded to ISP1, even when the destination is in ISP2. 310 The simpler approach is for AS1 to use default. That is, AS1 311 would first configure default route at each connection to a 312 provider and propagate (e.g., via iBGP) them into the AS. Then, 313 each network in AS1 choose the closest exit point (determined by 314 IGP metric). The problem is how to make sure the return traffic 315 to X and Y takes symmetric paths. Currently this is achieved by 316 manipulating the AS-path length or other approaches detailed in 317 the following section. 319 If AS1 still prefers to take full routing, more coordination would 320 be required for using the AS path manipulation or other techniques 321 as described in Section 3. 323 3. Current Practices 325 Currently there are mainly three approaches to implement Polices 2-4 326 for Figure 3. This section presents analysis and critique of these 327 approaches. Without loss of generality, Figure 3(a) is used as an 328 example. 330 3.1 Manipulation of AS Path Length 332 Although the length of the AS path was not specified in [1] as a 333 parameter in the route selection process, it has been widely used as 334 such. 336 Some router software offers the ability of prepending AS numbers to 337 the AS path for the purpose of influencing the route selection. Here 338 is how the feature can be used. First, AS1 categorizes all of its 339 routes and prepends an AS number (either its own AS or a different AS 340 number): 342 AS1 Prepend AS Path 343 Route To ISP1 To ISP2 ISP1 ISP2 344 ===== ======= ======= ======= ====== 345 X AS1 AS1 AS1 AS1 346 Y AS1 AS1 AS1 AS1 348 In general the different AS paths can be used by ISP1 and ISP2 to 349 configure AS-based "local_pref" values to implement the desired rout- 350 ing policy. The "local_pref" configuration would not be necessary if 351 there are sufficient number of ASs inserted. 353 With this approach the AS that originates the preference has full 354 control, and only that AS needs to manipulate the AS path on a per- 355 route basis. 357 The drawbacks of this approach includes: 359 o It extends the AS path with superfluous information. In par- 360 ticular, the superfluous information in the AS path would be 361 propagated upstream and to the whole Internet. 363 o The number of ASs that need to be preprended is in general 364 proportional to the number of direct providers. 366 o Compatibility with other BGP implementation may be a problem. 368 3.2 Splitting AS 370 This approach requires an AS to be split into multiple ASs and run 371 external BGP between these ASs (possibly with MEDs configured for 372 load balancing among multiple links). Then the cases in Figure 3 can 373 be reduced to the cases in Figure 2, which have been discussed in 374 Section 2. 376 This is probably the cleanest approach the current BGP version can 377 offer. However, there is a great deal of reluctance in using this 378 approach. Practical problems with this approach include: 380 o Splitting ASs and having them maintained could be quite 381 involved depending upon the internal network topology. 383 o Extra AS numbers are required [7]. It would be necessary to 384 apply for AS numbers at the InterNIC. 386 o Wasting of AS numbers. The exhaustion of the AS number space 387 could become real with the ever-increasing number of such 388 needs. 390 o The increased number of ASs would add complexity to the Inter- 391 net topology, and therefore complicate problem resolution. 393 o An AS number has been traditionally tied to an organization. 394 Splitting AS means loss of coherence for some customers. 396 3.3 NLRI-based Preference Specification 398 This is the approach that has been used for the NSFNET. Here is how 399 it is done with Figure 3(a). ISP1 and ISP2 configure net-based pref- 400 erence on their routers, according to preference provided by AS1. 401 For example, for route X, ISP1 would configure higher preference for 402 its direct link with AS1, and lower preference for its direct link 403 with ISP2. 405 This approach requires NRLI-based customization with the direct 406 providers and sometimes indirect providers as well as the originating 407 AS. The NSFNET configuration experience has shown that this approach 408 requires non-trivial administrative coordination, and it places a 409 burden on routers with limited memory capacity. For these reasons, 410 the NLRI-based preference configuration should be avoided at the 411 provider level if possible. Instead, such a configuration should be 412 pushed as close to the originating AS as possible. 414 4. Discussion 416 As has been illustrated in Section 3, it is not easy to implement 417 routing symmetry for an entity with multiple direct providers using 418 the current functionality of BGP. There are many drawbacks with the 419 current practice of implementation. Even the implementation of the 420 AS-based "local_pref" parameter can sometimes be quite involved. The 421 difficulty is caused by the lack of a globally transitive preference 422 an AS (with multiple direct providers) can specify, and be used in 423 the route selection process. 425 An Multi-Provider Preference (MPP) attribute is proposed [3] for the 426 purpose of facilitating the implementation. As illustrated in [4], 427 the routing policies presented in Section 2 can be implemented with 428 ease by using the MPP attribute. In particular, only the AS that 429 originates this preference needs to specify this preference on a per- 430 route basis. 432 5. Security Considerations 434 Security considerations are not discussed in this memo. 436 6. Acknowledgments 438 The authors would like to thank Roy Alcala, Dennis Ferguson, John 439 Stewart, and Jack Waters of MCI for the many interesting hallway dis- 440 cussions related to this work. We also acknowledge Sean Doran of 441 Sprint as the first person (to the authors knowledge) to make use of 442 the AS path manipulation technique. 444 7. References 446 [1] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)", 447 RFC1771, March 1995. 449 [2] Y. Rekhter, and P. Gross, "Application of the Border Gateway Pro- 450 tocol in the Internet", RFC1772, March 1995. 452 [3] Chen, E., and Bates, T., "Multi-Provider Preference Attribute for 453 BGP", INTERNET-DRAFT, , April 1995. 455 [4] Chen, E., and Bates, T., "Application of the BGP Multi-Provider 456 Preference Attribute in Implementing Symmetric Routing", INTERNET- 457 DRAFT, , April 1995. 459 [5] Antonov, V., "BGP AS Path Metrics", INTERNET DRAFT, , March 1995. 462 [6] Rekhter, Y., "Routing in a Multi-provider Internet", RFC1787, 463 April 1995. 465 [7] Hawkinsin, J., and Bates, T., "Guidelines for creation, selec- 466 tion, and registration of an Autonomous System (AS)", INTERNET-DRAFT, 467 , May 1995. 469 8. Author's Addresses 471 Enke Chen 472 MCI 473 2100 Reston Parkway 474 Reston, VA 22094 476 phone: +1 703 715 7087 477 email: enke@mci.net 479 Tony Bates 480 MCI 481 2100 Reston Parkway 482 Reston, VA 22094 484 phone: +1 703 715 7521 485 email: Tony.Bates@mci.net