idnits 2.17.1 draft-ietf-idr-dpa-application-01.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-03-28) 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 232 has weird spacing: '... routes shall...' -- The document date (June 1995) is 10514 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: '1' is defined on line 329, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 332, 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' Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Enke Chen 2 Tony Bates 3 Expires in six months MCI 4 June 1995 6 Application of the BGP Destination Preference Attribute 7 in Implementing Symmetric Routing 8 10 Status of this Memo 12 This document is an Internet Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, 14 and its Working Groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six 18 months. Internet Drafts may be updated, replaced, or obsoleted by 19 Internet Drafts are draft documents valid for a maximum of six 20 months. Internet Drafts may be updated, replaced, or obsoleted by 21 other documents at any time. It is not appropriate to use Internet 22 Drafts as reference material or to cite them other than as a "working 23 draft" or "work in progress". 25 Please check the I-D abstract listing contained in each Internet 26 Draft directory to learn the current status of this or any other 27 Internet Draft. 29 Abstract 31 This paper presents applications of the proposed Destination 32 Preference Attribute (DPA) for BGP. It shows how the DPA attribute 33 can aid in the implementation of symmetric inter-domain routing in 34 the multi-provider Internet. 36 1. Introduction 38 The Destination Preference Attribute (DPA) is proposed in [4] for 39 BGP. This attribute can be used by an autonomous system (AS) to 40 specify a globally transitive preference in its routing announcement 41 via BGP so that the upstream BGP speakers can use the preference to 42 favor certain path for return traffic. This paper presents a typical 43 application of this attribute. It illustrates how the DPA attribute 44 facilitates the implementation of symmetric inter-domain routing and 45 load-sharing for the the typical cases presented in [3]. 47 This paper assumes that in general an ISP treats other ISPs equally 48 (in terms of the "local_pref" parameter) in the route selection 49 process. It also assumes the following order of preference is 50 followed for the purpose of route selection: first the "local_pref" 51 parameter, followed by the DPA attribute, the shortest AS-path, the 52 MED and the IGP metric. 54 2. Application of the DPA Attribute 56 In [3] we present several typical topologies of Internet connections, 57 their inter-domain routing requirements, and the current practice to 58 implement these routing policies. This section illustrates how the 59 DPA attribute can be used to facilitate the implementation. 61 2.1 An Entity with a Single Direct Provider 63 +-----+ +-----+ +-----+ 64 | ISP | | ISP | | ISP | 65 +-----+ +-----+ +-----+ 66 | | | 67 +-----+ +-----+ +-----+ 68 | AS1 | | RSP | | RSP | 69 +-----+ +-----+ +-----+ 70 | 71 +-----+ 72 | AS1 | 73 +-----+ 75 (a) (b) (c) 77 Figure 1 79 The routing is always symmetric at the inter-domain level. The DPA 80 attribute should not be set as it is not needed. 82 AS1 can either take full routing or use default. 84 2.2 Backup of Entities with Different Direct Providers 86 +-----+ +------+ +------+ 87 | ISP | | ISP3 | | ISP3 | 88 +-----+ +------+ +------+ 89 / \ / \ / \ 90 / \ / (NAP) \ / (NAP) \ 91 +-----+ +-----+ +------+ +------+ +------+ +------+ 92 | AS1 |----| AS2 | | ISP1 |------| ISP2 | | ISP1 |-------| ISP2 | 93 +-----+ +-----+ +------+ +------+ +------+ +------+ 94 | | | | 95 +------+ +------+ +------+ +------+ 96 | AS1 |------| AS2 | | RSP1 | | RSP2 | 97 +------+ +------+ +------+ +------+ 98 | | 99 +------+ +------+ 100 | AS1 |------| AS2 | 101 +------+ +------+ 103 (a) (b) (c) 105 Figure 2 107 In all cases of Figure 2, in order to provide for backup, AS1 shall 108 permit the acceptance of AS2's routes from both AS2 and AS1's direct 109 providers, and permits their announcement to its direct providers. 110 Similar configuration for AS2. As presented in [3], the AS-based 111 "local_pref" configuration is sufficient to implement the routing 112 requirements. It is not necessary to use the DPA attribute. 114 However, the DPA attribute would simplify the implementation as shown 115 in the following. 117 Policy 1: Used solely as a backup link. 119 AS1 can simply announce all its routes with a higher DPA value to 120 its direct provider, and with a lower DPA value to AS2. AS1 can 121 either carry full routing or only take partial routing (AS2's 122 routes) from both its direct provider and AS2, and configure 123 default routes. Similar configuration for AS2. 125 Policy 2: Used for traffic between AS1 and AS2, and as backup in 126 general 128 As with Policy 1, AS1 can simply announce all its routes with a 129 higher DPA value to its direct provider, and with a lower DPA 130 value to AS2. AS1 also needs to configure proper AS-based 131 "local_pref" value for AS2's routes. This is to override the 132 higher DPA value for AS2's routes received from the direct 133 provider. AS1 can either carry full routing or only take partial 134 routing (AS2's routes) from both its direct provider and AS2, and 135 configure default routes. Similar configuration for AS2. 137 2.3 An Entity with Multiple Direct Providers 139 This is where the DPA attribute would be most useful. As shown in 140 Figure 3, AS1 has two direct providers. X and Y are routes of AS1. 141 Note that AS1 could be an RSP. 143 +------+ +-----+ +------+ 144 | ISP3 | | ISP | | ISP3 | 145 +------+ +-----+ +------+ 146 / \ / \ / \ 147 / (NAP) \ / \ / (NAP)\ 148 +------+ +------+ +------+ +------+ +------+ +-----+ 149 | ISP1 |------| ISP2 | | RSP1 | | RSP2 | | ISP1 |-----| ISP2| 150 +------+ +------+ +------+ +------+ +------+ +-----+ 151 \ / \ / | | 152 \L1 /L2 \ / | | 153 +------+ +------+ +------+ +-----+ 154 | AS1 | | AS1 | | RSP1 | | RSP2| 155 |X Y| |X Y| +------+ +-----+ 156 +------+ +------+ \ / 157 \ / 158 +------+ 159 | AS1 | 160 |X Y| 161 +------+ 163 (a) (b) (c) 165 Figure 3 167 Policy 1: One link is used as primary, the other as pure backup 169 AS discussed in [3], the routing policy can be implemented by 170 coordinating the AS-based "local_pref" parameter with direct 171 providers. It is not necessary to use the DPA attribute. 173 However, the DPA attribute would simplify the implementation as 174 detailed in the following. 176 AS1 can simply announce all its routes with a higher DPA value to 177 the primary provider, and with a lower DPA value to the other 178 provider. 180 AS1 can either carry full routing or use default. If AS1 takes 181 full routing, then AS1 also need to configure AS-based 182 "local_pref" so that the primary path is preferred. 184 Policy 2: Each link is used for traffic with the respective direct 185 provider. In general one link is used as primary, the other as 186 backup. 188 As with Policy 1, AS1 can simply announce all its routes with a 189 higher DPA value to the primary provider, and with a lower DPA 190 value to the other provider. 192 AS1 can be configured: 194 o either with partial routing (only routes of the direct 195 providers and their customers) and configure default routes 196 with different weights. 198 o or with full routing and configure AS-based "local_pref" val- 199 ues. The AS-list would still need to be updated and main- 200 tained, as discussed in [3]. 202 Policy 3: Partial load-sharing among these links 204 That is, the direct link is used for traffic between AS1 and its 205 direct providers including its customers. However, the closest 206 exit point would be taken for traffic beyond these direct 207 providers and their customers. 209 AS1 shall categorize its networks into two categories (say X and 210 Y). Then, X routes shall be configured with higher DPA value when 211 they are being announced to one direct provider, and with lower 212 DPA values when they are being announced to the other direct 213 provider. Similar configuration for Y routes. 215 In addition, AS1 also needs to configure AS-based "local_pref" so 216 that the direct link is taken between the AS and its direct 217 providers. 219 AS1 can take full routing. It can also take partial routing 220 (routes of direct providers and their customers), and configure 221 equal-weight default routes at its border routers and propagate 222 them into its AS. 224 Policy 4: Complete load-sharing among these links 226 That is, each network in AS1 sends packets to the closer (in terms 227 of internal route preference) border router that peers with a 228 direct provider. The return traffic is expected to take a symmet- 229 ric path. 231 AS1 shall categorize its networks into two categories (say X and 232 Y). Then, X routes shall be configured with higher DPA value 233 when they are being announced to one direct provider, and with 234 lower DPA values when they are being announced to the other direct 235 provider. Similar configuration for Y routes. 237 It is much simpler if AS1 does not take full routing. Then AS1 238 can configure default routes at its border routers and propagate 239 them into its AS (via iBGP). 241 If AS1 still prefers to take full routing, this policy can only be 242 achieved if AS1 manipulates the AS-path length so that routes 243 received from the direct providers would have equal AS-path 244 length. However, the routes with their AS paths manipulated would 245 not be propagated upstream. That is, the propagation of the 246 superfluous information in the AS path would be limited to the AS 247 and possibly its downstream ASs, rather than the whole Internet. 249 3. Configure Preference for Routes with the DPA Attribute 251 It is possible, although not common, that the DPA attribute has been 252 set by one AS (say AS1), and another AS (say AS2) desires further 253 preference between its direct providers. The following options are 254 available for AS2: 256 (1) AS2 uses the DPA attributes to do load sharing for routes other 257 than AS1's. That is, AS2 does not include AS1's routes in load shar- 258 ing with respect to AS2's direct providers. Instead, AS2 can coordi- 259 nate with its direct providers to configure the proper AS-based 260 "local_pref" values so that one provider is used as the primary, the 261 other as the backup, for all of AS1's routes. This is to make sure 262 that routing symmetry is maintained for routing to AS1. If there are 263 multiple ASs that have configured the DPA attributes, then AS2 can 264 perform load sharing by distribute (on per-AS basis) routes evenly 265 with respect to its direct providers. 267 (2) AS1 chooses to re-set the DPA attribute for route announcements 268 including AS1's routes. This may well cause the DPA attributes set 269 by AS1 not to be used by upstream BGP speakers (due to non-comparable 270 DPA attributes). 272 In many cases, Option (1) is probably preferred. However, Option (1) 273 may not be able to maintain routing symmetry, either. It should be 274 emphasized that when dealing with the complicated topologies of 275 Internet connections, one needs to take into account its internal 276 network topology, its connection to direct providers and to the major 277 interconnection points. Coordination between providers is strongly 278 recommended. 280 The following example illustrates Option (1). In Figure 4, AS1 has 281 two direct providers RSP1 and RSP2. AS1 does load sharing by setting 282 DPA attributes for routes W and Z. RSP1 has direct providers ISP1 283 and ISP2, and wishes to do load sharing. 285 +------+ 286 | ISP3 | 287 +------+ 288 / \ 289 / (NAP) \ 290 +------+ +------+ 291 | ISP1 |-----| ISP2 | 292 +------+ +------+ 293 | / | 294 | / | 295 +------+ +------+ 296 | RSP1 | | RSP2 | 297 |X Y| | | 298 +------+ +------+ 299 \ / 300 \ / 301 +------+ 302 | AS1 | 303 |W Z| 304 +------+ 306 Figure 4 308 In this example, RSP1 can use the DPA attributes to do load sharing 309 for routes without the DPA attributes. For AS1's routes (such as W 310 and Z) that are already configured with the DPA attribute, RSP1 can 311 coordinate, with ISP1 or ISP2, to configure the proper AS-based 312 "local_pref" value so that one acts as primary to reach routes of 313 AS1. For instance, ISP1 configures lower AS-based "local_pref" value 314 for all of AS1's routes so that the ISP1 - ISP2 link is preferred to 315 reach AS1's routes. This would also ensure that ISP3 would use ISP2 316 to reach AS1's routes. 318 4. Security Considerations 320 Security considerations are not discussed in this memo. 322 5. Acknowledgments 324 The authors would like to thank Yakov Rekhter of Cisco for his help- 325 ful comments and suggestions. 327 6. References 329 [1] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)", 330 RFC1771, March 1995. 332 [2] Y. Rekhter, and P. Gross, "Application of the Border Gateway Pro- 333 tocol in the Internet", RFC1772, March 1995. 335 [3] Chen, E., and Bates, T., "Analysis and Critique of the Current 336 Practice of Implementing Symmetric Routing in the Multi-Provider 337 Internet", INTERNET-DRAFT, , 338 June 1995. 340 [4] Chen, E., and Bates, T., "Destination Preference Attribute for 341 BGP", INTERNET-DRAFT, , June 1995. 343 6. Author's Addresses 345 Enke Chen 346 MCI 347 2100 Reston Parkway 348 Reston, VA 22091 350 phone: +1 703 715 7087 351 email: enke@mci.net 353 Tony Bates 354 MCI 355 2100 Reston Parkway 356 Reston, VA 22091 358 phone: +1 703 715 7521 359 email: Tony.Bates@mci.net