idnits 2.17.1 draft-ietf-idr-as-migration-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 13, 2014) is 3605 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force W. George 3 Internet-Draft Time Warner Cable 4 Intended status: Informational S. Amante 5 Expires: December 15, 2014 Apple, Inc. 6 June 13, 2014 8 Autonomous System (AS) Migration Features and Their Effects on the BGP 9 AS_PATH Attribute 10 draft-ietf-idr-as-migration-01 12 Abstract 14 This draft discusses common methods of managing an ASN migration 15 using some BGP feaures that while commonly-used are not formally part 16 of the BGP4 protocol specification and may be vendor-specific in 17 exact implementation. It is necessary to document these de facto 18 standards to ensure that they are properly supported in future BGP 19 protocol work such as BGPSec. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 15, 2014. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 1.2. Documentation note . . . . . . . . . . . . . . . . . . . 3 58 2. ASN Migration Scenario Overview . . . . . . . . . . . . . . . 4 59 3. External BGP Autonomous System Migration Features . . . . . . 6 60 3.1. Modify Inbound BGP AS_PATH Attribute . . . . . . . . . . 6 61 3.2. Modify Outbound BGP AS_PATH Attribute . . . . . . . . . . 8 62 3.3. Implementation . . . . . . . . . . . . . . . . . . . . . 9 63 4. Internal BGP Autonomous System Migration Features . . . . . . 10 64 4.1. Internal BGP Alias . . . . . . . . . . . . . . . . . . . 10 65 4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 13 66 5. Additional Operational Considerations . . . . . . . . . . . . 14 67 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 14 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 71 10. Appendix: Implementation report . . . . . . . . . . . . . . . 15 72 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 74 11.2. Informative References . . . . . . . . . . . . . . . . . 16 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 77 1. Introduction 79 This draft discusses common methods of managing an ASN migration 80 using some BGP features that while commonly-used are not formally 81 part of the BGP4 [RFC4271] protocol specification and may be vendor- 82 specific in exact implementation. These features are local to a 83 given BGP Speaker and do not require negotiation with or cooperation 84 of BGP neighbors. The deployment of these features do not need to 85 interwork with one another to accomplish the desired results, so 86 slight variations between existing vendor implementations exist. 87 However, it is necessary to document these de facto standards to 88 ensure that any future protocol enhancements to BGP that propose to 89 read, copy, manipulate or compare the AS_PATH attribute can do so 90 without inhibiting the use of these very widely used ASN migration 91 features. 93 It is important to understand the business need for these features 94 and illustrate why they are critical, particularly for ISPs' 95 operations. However, these features are not limited to ISPs and 96 organizations of all sizes use these features for similar reasons to 97 ISPs. During a merger, acquisition or divestiture involving two 98 organizations it is necessary to seamlessly migrate BGP speakers from 99 one ASN to a second ASN. The overall goal in doing so, particularly 100 in the case of a merger or acquisition, is to achieve a uniform 101 operational model through consistent configurations across all BGP 102 speakers in the combined network. In addition, and perhaps more 103 imporantly, it is common practice in the industry for ISPs to bill 104 customers based on utilization. ISPs bill customers based on the 105 95th percentile of the greater of the traffic sent or received, over 106 the course of a 1-month period, on the customer's PE-CE access 107 circuit. Given that the BGP Path Selection algorithm selects routes 108 with the shortest AS_PATH attribute, it is critical for the ISP to 109 not increase AS_PATH length during or after ASN migration, toward 110 both downstream transit customers as well as settlement-free peers, 111 who are likely sending or receiving traffic from those transit 112 customers. This would not only result in sudden changes in traffic 113 patterns in the network, but also (substantially) decrease 114 utilization driven revenue at the ISP. 116 By default, the BGP protocol requires an operator to configure a 117 single remote ASN for the eBGP neighbor inside a router, in order to 118 successfully negotiate and establish an eBGP session. Prior to the 119 existence of these features, it would have required an ISP to work 120 with, in some cases, tens of thousands of customers. In particular, 121 the ISP would have to encourage those customers to change their CE 122 router configs to use the new ASN in a very short period of time, 123 when the customer has no business incentive to do so. Thus, it 124 becomes critical to allow the ISP to make this process a bit more 125 asymmetric, so that it could seamlessly migrate the ASN within its 126 network(s), but not disturb existing customers, and allow the 127 customers to gradually migrate to the ISP's new ASN at their leisure. 129 1.1. Requirements Language 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC 2119 [RFC2119]. 135 1.2. Documentation note 137 This draft uses Autonomous System Numbers (ASNs) from the range 138 reserved for documentation as described in RFC 5398 [RFC5398]. In 139 the examples used here, they are intended to represent Globally 140 Unique ASNs, not private use ASNs as documented in RFC 6996 [RFC6996] 141 section 10. 143 2. ASN Migration Scenario Overview 145 The use case being discussed here is an ISP merging two or more ASNs, 146 where eventually one ASN subsumes the other(s). In this use case, we 147 will assume the most common case where there are two ISPs, A and B, 148 that use AS 64500 and 64510, respectively, before the ASN migration 149 is to occur. AS 64500 will be the permanently retained ASN used 150 going forward across the consolidated set of both ISPs network 151 equipment and AS 64510 will be retired. Thus, at the conclusion of 152 the ASN migration, there will be a single ISP A' with all internal 153 BGP speakers configured to use AS 64500. To all external BGP 154 speakers, the AS_PATH length will not be increased. 156 In this same scenario, AS 64496 and AS 64499 represent two, separate 157 customer networks: C and D, respectively. Originally, customer C (AS 158 64496) is attached to ISP B, which will undergo ASN migration from AS 159 64510 to AS 64500. Furthermore, customer D (AS 64496) is attached to 160 ISP A, which does not undergo ASN migration since ISP A's ASN will 161 remain constant, (AS 64500). Although this example refers to AS 162 64496 and 64499 as customer networks, either or both may be 163 settlement-free or other types of peers. In this use case they are 164 referred to as "customers" merely for convenience. 166 ------ ------ 167 / ISP A \ / ISP B \ 168 | AS 64500 | | AS 64510 | 169 \ / \ / 170 ------- ------- 171 | | 172 | | 173 ------------ ------------- 174 | Cust D | | Cust C | 175 | AS 64499 | | AS 64496 | 176 ------------ ------------- 178 Figure 1: Before Migration 180 --------------- 181 / \ 182 | ISP A' | 183 | AS 64500 | 184 \ / 185 --------------- 186 / \ 187 / \ 188 | | 189 ------------ ------------- 190 | Cust D | | Cust C | 191 | AS 64499 | | AS 64496 | 192 ------------ ------------- 194 Figure 2: After Migration 196 The general order of operations, typically carried out in a single 197 maintenance window by the network undergoing ASN migration, ISP B, 198 are as follows. First, ISP B, will change the global BGP ASN used by 199 a PE router, from ASN 64510 to 64500. At this point, the router will 200 no longer be able to establish eBGP sessions toward the existing CE 201 devices that are attached to it and still using AS 64510. Second, 202 ISP B will configure two separate, but related ASN migration features 203 discussed in this document on all eBGP sessions toward all CE 204 devices. These features modify the AS_PATH attribute received from 205 and transmitted toward CE devices to acheive the desired effect of 206 not increasing the length of the AS_PATH. 208 At the conclusion of the ASN migration, the CE devices at the edge of 209 the network are not aware of and do not observe any change in the 210 length of the AS_PATH attribute. However, after the changes 211 discussed in this document are put in place by ISP A', there is a 212 change to the contents of the AS_PATH attribute to ensure the AS_PATH 213 is not artifically lengthened for the duration of time that these AS 214 migration parameters are used. 216 In this use case, neither ISP is using BGP Confederations RFC 5065 217 [RFC5065] internally. 219 There are multiple implementations with equivalent features deployed 220 and in use. Some documentation pointers to these implementations, as 221 well as additional documentation on migration scenarios can be found 222 in the appendix. The examples cited below use Cisco IOS CLI for ease 223 of illustration purposes only. 225 3. External BGP Autonomous System Migration Features 227 The following section addresses features that are specific to 228 modifying the AS_PATH attribute at the Autonomous System Border 229 Routers (ASBRs) of an organization, (typically a single Service 230 Provider). This ensures that external BGP customers/peers are not 231 forced to make any configuration changes on their CE routers before 232 or during the exact time the Service Provider wishes to migrate to a 233 new, permanently retained ASN. Furthermore, these features eliminate 234 the artificial lengthening of the AS_PATH both transmitted from and 235 received by the Service Provider that is undergoing AS Migration, 236 which would have negative implications on path selection by external 237 networks. 239 3.1. Modify Inbound BGP AS_PATH Attribute 241 ISP B needs to reconfigure its router(s) to participate as an 242 internal BGP speaker in AS 64500, to realize the business goal of 243 becoming a single Service Provider: ISP A'. ISP B needs to do this 244 without coordinating the change of its ASN with all of its eBGP 245 peers, simultaneously. The first step is for ISP B to change the 246 global AS in its router configuration, used by the local BGP process 247 as the system-wide Autonomous System ID, from AS 64510 to AS 64500. 248 The next step is for ISP B to establish iBGP sessions with ISP A's 249 existing routers, thus consolidating ISP B into ISP A resulting in 250 operating under a single AS: ISP A', (AS 64500). 252 The next step is for ISP B to reconfigure its PE router(s) so that 253 each of its eBGP sessions toward all eBGP speakers with a feature 254 called "Local AS". This feature allows ISP B's PE router to re- 255 establish a eBGP session toward the existing CE devices using the 256 legacy AS, AS 64510, in the eBGP session establishment. Ultimately, 257 the CE devices, (i.e.: customer C), are completely unaware that ISP B 258 has reconfigured its router to participate as a member of a new AS. 259 Within the context of ISP B's PE router, the second effect this 260 feature has is that, by default, it prepends all received BGP 261 UPDATE's with the legacy AS of ISP B: AS 64510. Thus, within ISP A' 262 the AS_PATH toward customer C would appear as: 64510 64496, which is 263 an increase in AS_PATH length from previously. Therefore, a 264 secondary feature "No Prepend" is required to be added to the "Local 265 AS" configuration toward every eBGP neighbor on ISP B's PE router. 266 The "No Prepend" feature causes ISP B's PE router to not prepend the 267 legacy AS, AS 64510, on all received eBGP UPDATE's from customer C. 268 This restores the AS_PATH within ISP A' toward customer C so that it 269 is just one ASN in length: 64496. 271 In the direction of CE -> PE (inbound): 273 1. 'local-as ': appends the value to the AS_PATH 274 of routes received from the CE 276 2. 'local-as no-prepend': does not prepend value 277 to the AS_PATH of routes received from the CE 279 As stated previously, local-as no-prepend, (configuration 280 #2), is critical because it does not increase the AS_PATH length. 281 Ultimately, this ensures that routes learned from ISP B's legacy 282 customers will be transmitted through legacy eBGP sessions of ISP A, 283 toward both customers and peers, will contain only two AS'es in the 284 AS_PATH: 64500 64496. Thus, the legacy customers and peers of ISP A 285 will not see an increase in the AS_PATH length to reach ISP B's 286 legacy customers. Ultimately, it is considered mandatory by 287 operators that both the "Local AS" and "No Prepend" configuration 288 parameters always be used in conjunction with each other in order to 289 ensure the AS_PATH length is not increased. 291 PE-1 is a PE that was originally in ISP B. PE-1 has had its global 292 configuration ASN changed from AS 64510 to AS 64500 to make it part 293 of the permanently retained ASN. This now makes PE-1 a member of ISP 294 A'. PE-2 is a PE that was originally in ISP A. Although its global 295 configuration ASN remains AS 64500, throughout this exercise we also 296 consider PE-2 a member of ISP A'. 298 ISP A' ISP A' 299 CE-1 ---> PE-1 -------------------> PE-2 ---> CE-2 300 64496 Old_ASN: 64510 New_ASN: 64500 64499 301 New_ASN: 64500 303 Note: Direction of BGP UPDATE as per the arrows. 305 Figure 3: Local AS BGP UPDATE Diagram 307 The final configuration on PE-1 after completing the "Local AS" 308 portion of the AS migration is as follows: 310 router bgp 64500 311 neighbor remote-as 64496 312 neighbor local-as 64510 no-prepend 314 As a result of the "Local AS No Prepend" configuration, on PE-1, CE-2 315 will see an AS_PATH of: 64500 64496. CE-2 will not receive a BGP 316 UPDATE containing AS 64510 in the AS_PATH. (If only the "local-as 317 64510" feature was configured without the keyword "no-prepend" on PE- 318 1, then CE-2 would see an AS_PATH of: 64496 64510 64500, which is 319 unacceptable). 321 3.2. Modify Outbound BGP AS_PATH Attribute 323 The previous feature, "Local AS No Prepend", was only designed to 324 modify the AS_PATH Attribute received by the ISP in updates from CE 325 devices, when CE devices still have an eBGP session established with 326 the ISPs legacy AS, (AS64510). In some existing implementations, 327 "Local AS No Prepend" does not concurrently modify the AS_PATH 328 Attribute for BGP UPDATEs that are transmitted by the ISP to CE 329 devices. Specifically, with "Local AS No Prepend" enabled on ISP A's 330 PE-1, it automatically causes a lengthening of the AS_PATH in 331 outbound BGP UPDATEs from ISP A' toward directly attached eBGP 332 speakers, (Customer C in AS 64496). This is the result of the "Local 333 AS No Prepend" feature automatically appending the new global 334 configuration ASN, AS64500, after the legacy ASN, AS64510, on ISP A' 335 PE-1 in BGP UPDATEs that are transmitted by PE-1 to CE-1. The end 336 result is that customer C, in AS 64496, will receive the following 337 AS_PATH: 64510 64500 64499. Therefore, if ISP A' takes no further 338 action, it will cause an increase in AS_PATH length within customer's 339 networks directly attached to ISP A', which is unacceptable. 341 A second feature was designed to resolve this problem (continuing the 342 use of Cisco CLI in the examples, it is called "Replace AS" in the 343 examples below). This feature allows ISP A' to prevent routers 344 configured with this feature from appending the global configured AS 345 in outbound BGP UPDATEs toward its customer's networks configured 346 with the "Local AS" feature. Instead, only the historical (or 347 legacy) AS will be prepended in the outbound BGP UPDATE toward 348 customer's network, restoring the AS_PATH length to what it what was 349 before AS Migration occurred. 351 To re-use the above diagram, but in the opposite direction, we have: 353 ISP A' ISP A' 354 CE-1 <--- PE-1 <------------------- PE-2 <--- CE-2 355 64496 Old_ASN: 64510 New_ASN: 64500 64499 356 New_ASN: 64500 358 Note: Direction of BGP UPDATE as per the arrows. 360 Figure 4: Replace AS BGP UPDATE Diagram 362 The final configuration on PE-1 after completing the "Replace AS" 363 portion of the AS migration is as follows: 365 router bgp 64500 366 neighbor remote-as 64496 367 neighbor local-as 64510 no-prepend replace-as 369 By default, without "Replace AS" enabled, CE-1 would see an AS_PATH 370 of: 64510 64500 64499, which is artificially lengthened by the ASN 371 Migration. After ISP A' changes PE-1 to include the "Replace AS" 372 feature, CE-1 would receive an AS_PATH of: 64510 64499, which is the 373 same AS_PATH length pre-AS migration. 375 3.3. Implementation 377 While multiple implementations already exist, the following should 378 document the expected behavior such that a new implementation of this 379 feature could be done on other platforms. 381 These features MUST be configurable on a per-neighbor or per peer- 382 group basis to allow for maximum flexibility. When this feature set 383 is invoked, an ASN that is different from the globally-configured ASN 384 is provided as a part of the command as exemplified above. To 385 implement this feature, a BGP speaker MUST send BGP OPEN messages to 386 the configured eBGP peer using the ASN configured for this session as 387 the value sent in MY ASN. The speaker MUST NOT use the ASN 388 configured globally within the BGP process as the value sent in MY 389 ASN in the OPEN message. This will avoid the BGP OPEN Error message 390 BAD PEER AS, and is typically used to re-establish eBGP sessions with 391 peers expecting the legacy ASN after a router has been moved to a new 392 ASN. Additionally, when the BGP speaker configured with this feature 393 receives updates from its neighbor, it MUST append the configured ASN 394 in the AS_PATH attribute before processing the update as normal. 395 Note that processing the update as normal will include appending the 396 globally configured ASN to the AS_PATH, thus processing this update 397 will result in the addition of two ASNs to the AS_PATH attribute. 398 Similarly, for outbound updates sent by the configured BGP speaker to 399 its neighbor, the speaker MUST append the configured ASN to the 400 AS_PATH attribute, adding to the existing global ASN in the AS_PATH, 401 for a total of two ASNs added to the AS_PATH. 403 Two options exist to manipulate the behavior of this feature. They 404 modify the behavior as described below: 406 No prepend inbound - When the BGP speaker configured with this option 407 receives inbound updates from its neighbor, it MUST NOT append the 408 configured ASN in the AS_PATH attribute and instead MUST append only 409 the globally configured ASN. 411 No prepend outbound - When the BGP speaker configured with this 412 option generates outbound BGP updates to the configured peer, the BGP 413 speaker MUST remove the globally configured ASN from the AS_PATH 414 attribute, and MUST append the locally configured ASN to the AS_PATH 415 attribute before sending outbound BGP updates to the configured peer. 417 While the exact command syntax is an implementation detail beyond the 418 scope of this document, the following consideration may be helpful 419 for implementers: Implementations MAY integrate the behavior of the 420 options described above into a single command that addresses both 421 inbound and outbound updates, but if this is done, implementations 422 MUST provide a method to select its applicability to inbound updates, 423 outbound updates, or updates in both directions. Several existing 424 implementations use separate commands (e.g. local-as no-prepend vs 425 local-as replace-as) for maximum flexibility in controlling the 426 behavior on the session to address the widest range of possible 427 migration scenarios. 429 4. Internal BGP Autonomous System Migration Features 431 The following section describes features that are specific to 432 performing an ASN migration within medium to large networks in order 433 to realize the business and operational benefits of a single network 434 using one, globally unique Autonomous System. These features assist 435 with a gradual and least service impacting migration of Internal BGP 436 sessions from a legacy ASN to the permanently retained ASN. It 437 should be noted that the following feature is very valuable to 438 networks undergoing AS migration, but its use does not cause changes 439 to the AS_PATH attribute. 441 4.1. Internal BGP Alias 443 In this case, all of the routers to be consolidated into a single, 444 permanently retained ASN are under the administrative control of a 445 single entity. Unfortunately, the traditional method of migrating 446 all Internal BGP speakers, particularly within larger networks, is 447 both time consuming and widely service impacting. 449 The traditional method to migrate Internal BGP sessions was strictly 450 limited to reconfiguration of the global configuration ASN and, 451 concurrently, changing of iBGP neighbor's remote ASN from the legacy 452 ASN to the new, permanently retained ASN on each router within the 453 legacy AS. These changes can be challenging to swiftly execute in 454 networks with with more than a few dozen internal BGP speakers. 455 There is also the concomitant service interruptions as these changes 456 are made to routers within the network, resulting in a reset of iBGP 457 sessions and subsequent reconvergence times to reestablish optimal 458 routing paths. Operators do not, and in some cases, cannot make such 459 changes given the associated risks and highly visible service 460 interruption; rather, they require a more gradual method to migrate 461 Internal BGP sessions, from one ASN to a second, permanently retained 462 ASN, that is not visibly service-impacting to its customers. 464 With the "Internal BGP Alias" [JUNIPER] feature, it allows an 465 Internal BGP speaker to form a single iBGP session using either the 466 old, legacy ASN or the new, permanently retained ASN. The benefits 467 of using this feature are several fold. First, it allows for a more 468 gradual and less service-impacting migration away from the legacy ASN 469 to the permanently retained ASN. Second, it (temporarily) permits 470 the coexistence of the legacy and permanently retained ASN within a 471 single network, allowing for uniform BGP path selection among all 472 routers within the consolidated network. NB: Cisco doesn't have an 473 exact equivalent to "Internal BGP Alias", but the combination of the 474 Cisco features iBGP local-AS and dual-as provides similar 475 functionality. 477 When the "Internal BGP Alias" feature is enabled, typically just on 478 one side of a iBGP session, it allows that iBGP speaker to establish 479 a single iBGP session with either the legacy ASN or the new, 480 permanently retained ASN, depending on which one it receives in the 481 "My Autonomous System" field of the BGP OPEN message from its iBGP 482 session neighbor. It is important to recognize that enablement of 483 the "Internal BGP Alias" feature preserves the semantics of a regular 484 iBGP session, (using identical ASNs). Thus, the BGP attributes 485 transmitted by and the acceptable methods of operation on BGP 486 attributes received from iBGP sessions configured with "Internal BGP 487 Alias" are no different than those exchanged across an iBGP session 488 without "Internal BGP Alias" configured, as defined by [RFC4271] and 489 [RFC4456]. 491 Typically, in medium to large networks, BGP Route Reflectors 492 [RFC4456] (RRs) are used to aid in reduction of configuration of iBGP 493 sessions and scalability with respect to overall TCP (and, BGP) 494 session maintenance between adjacent iBGP speakers. Furthermore, BGP 495 Route Reflectors are typically deployed in pairs within a single 496 Route Reflection cluster to ensure high reliability of the BGP 497 Control Plane. As such, the following example will use Route 498 Reflectors to aid in understanding the use of the "Internal BGP 499 Alias" feature. Note that Route Reflectors are not a prerequisite to 500 enable "Internal BGP Alias" and this feature can be enabled 501 independent of the use of Route Reflectors. 503 The general order of operations is as follows: 505 1. Within the legacy network, (the routers comprising the set of 506 devices that still have a globally configured legacy ASN), take 507 one member of a redundant pair of RRs and change its global 508 configuration ASN to the permanently retained ASN. Concurrently, 509 enable use of "Internal BGP Alias" on all iBGP sessions. This 510 will comprise Non-Client iBGP sessions to other RRs as well as 511 Client iBGP sessions, typically to PE devices, both still 512 utilizing the legacy ASN. Note that during this step there will 513 be a reset and reconvergence event on all iBGP sessions on the 514 RRs whose configuration was modified; however, this should not be 515 service impacting due to the use of redundant RRs in each RR 516 Cluster. 518 2. Repeat the above step for the other side of the redundant pair of 519 RRs. The one alteration to the above procedure is to disable use 520 of "Internal BGP Alias" on the Non-Client iBGP sessions toward 521 the other (previously reconfigured) RRs, since it is no longer 522 needed. "Internal BGP Alias" is still required on all RRs for 523 all RR Client iBGP sessions. Also during this step, there will 524 be a reset and reconvergence event on all iBGP sessions whose 525 configuration was modified, but this should not be service 526 impacting. At the conclusion of this step, all RRs should now 527 have their globally configured ASN set to the permanently 528 retained ASN and "Internal BGP Alias" enabled and in use toward 529 RR Clients. 531 3. At this point, the network administrators would then be able to 532 establish iBGP sessions between all Route Reflectors in both the 533 legacy and permanently retained networks. This would allow the 534 network to appear to function, both internally and externally, as 535 a single, consolidated network using the permanently retained 536 network. 538 4. The next steps to complete the AS migration are to gradually 539 modify each RR Client, (PE), in the legacy network still 540 utilizing the legacy ASN. Specifically, each legacy PE would 541 have its globally configured ASN changed to use the permanently 542 retained ASN. The ASN used by the PE for the iBGP sessions, 543 toward each RR, would be changed to use the permanently retained 544 ASN. (It is unnecessary to enable "Internal BGP Alias" on the 545 migrated iBGP sessions). During the same maintenance window, 546 External BGP sessions would be modified to include the above 547 "Local AS No Prepend" and "Replace-AS" features, since all of the 548 changes are service interrupting to the eBGP sessions of the PE. 549 At this point, all PE's will have been migrated to the 550 permanently retained ASN. 552 5. The final step is to excise the "Internal BGP Alias" 553 configuration from the first half of the legacy RR Client pair -- 554 this will expunge "Internal BGP Alias" configuration from all 555 devices in the network. After this is complete, all routers in 556 the network will be using the new, permanently retained ASN for 557 all iBGP sessions with no vestiges of the legacy ASN on any iBGP 558 sessions. 560 The benefit of using "Internal BGP Alias" is that it is a more 561 gradual and less externally visible, service-impacting change to 562 accomplish an AS migration. Previously, without "Internal BGP 563 Alias", such an AS migration change would carry a high risk and need 564 to be successfully accomplished in a very short timeframe, (e.g.: at 565 most several hours). In addition, it would cause substantial routing 566 churn and, likely, rapid fluctuations in traffic carried -- 567 potentially causing periods of congestion and resultant packet loss 568 -- during the period the configuration changes are underway to 569 complete the AS Migration. On the other hand, with "Internal BGP 570 Alias", the migration from the legacy ASN to the permanently retained 571 ASN can occur over a period of days or weeks with little disruption 572 experienced by customers of the network undergoing AS migration. 573 (The only observable service disruption should be when each PE 574 undergoes the changes discussed in step 4 above.) 576 4.2. Implementation 578 When configured with this feature, a BGP speaker MUST accept BGP OPEN 579 and establish an iBGP session from configured iBGP peers if the ASN 580 value in MY ASN is either the globally configured ASN or the locally 581 configured ASN provided in this command. Additionally, a BGP speaker 582 configured with this feature MUST send its own BGP OPEN using both 583 the globally configured and the locally configured ASN in MY ASN. To 584 avoid potential deadlocks when two BGP speakers are attempting to 585 establish a BGP peering session and are both configured with this 586 feature, the speaker SHOULD send BGP OPEN using the globally 587 configured ASN first, and only send a BGP OPEN using the locally 588 configured ASN as a fallback if the remote neighbor responds with the 589 BGP error BAD PEER ASN. In each case, the BGP speaker MUST treat 590 updates sent and received to this peer as if this was a natively 591 configured iBGP session, as defined by [RFC4271] and [RFC4456]. 593 Implementations of this feature MAY integrate the functionality from 594 the eBGP features (Section 3) section as a part of this command in 595 order to simplify support for eBGP migrations as well as iBGP 596 migrations, such that an eBGP session to a configured neighbor could 597 be established via either the global ASN or the locally configured 598 ASN. If the eBGP session is established with the global ASN, no 599 modifications to AS_PATH are required, but if the eBGP session is 600 established with the locally configured ASN, the modifications 601 discussed in eBGP features (Section 3) MUST be implemented to 602 properly manipulate the AS_PATH. 604 5. Additional Operational Considerations 606 This document describes several features to support ISPs and other 607 organizations that need to perform ASN migrations. Other variations 608 of these features may exist, for example, in legacy router software 609 that has not been upgraded or reached End of Life, but continues to 610 operate in the network. Such variations are beyond the scope of this 611 document. 613 Companies routinely go through periods of mergers, acquisitions and 614 divestitures, which in the case of the former cause them to 615 accumulate several legacy ASNs over time. ISPs often do not have 616 control over the configuration of customer's devices, (i.e.: the ISPs 617 are often not providing a managed CE router service, particularly to 618 medium and large customers that require eBGP). Furthermore, ISPs are 619 using methods to perform ASN migration that do not require 620 coordination with customers. Ultimately, this means there is not a 621 finite period of time after which legacy ASNs will be completely 622 expunged from the ISP's network. In fact, it is common that legacy 623 ASNs and the associated External BGP AS Migration features discussed 624 in this document can and do persist for several years, if not longer. 625 Thus, it is prudent to plan that legacy ASNs and associated External 626 BGP AS Migration features will persist in a operational network 627 indefinitely. 629 With respect to the Internal BGP AS Migration Features, all of the 630 routers to be consolidated into a single, permanently retained ASN 631 are under the administrative control of a single entity. Thus, 632 completing the migration from iBGP sessions using the legacy ASN to 633 the permanently retained ASN is more straightforward and could be 634 accomplished in a matter of days to months. Finally, good 635 operational hygiene would dictate that it is good practice to avoid 636 using "Internal BGP Alias" over a long period of time for reasons of 637 not only operational simplicity of the network, but also reduced 638 reliance on that feature during the ongoing lifecycle management of 639 software, features and configurations that are maintained on the 640 network. 642 6. Conclusion 644 Although the features discussed in this document are not formally 645 recognized as part of the BGP4 specification, they have been in 646 existence in commercial implementations for well over a decade. 647 These features are widely known by the operational community and will 648 continue to be a critical necessity in the support of network 649 integration activities going forward. Therefore, these features are 650 extremely unlikely to be deprecated by vendors. As a result, these 651 features must be acknowledged by protocol designers, particularly 652 when there are proposals to modify BGP's behavior with respect to 653 handling or manipulation of the AS_PATH Attribute. More 654 specifically, assumptions should not be made with respect to the 655 preservation or consistency of the AS_PATH Attribute as it is 656 transmitted along a sequence of ASN's. In addition, proposals to 657 manipulate the AS_PATH that would gratuitously increase AS_PATH 658 length or remove the capability to use these features described in 659 this document will not be accepted by the operational community. 661 7. Acknowledgements 663 Thanks to Kotikalapudi Sriram, Stephane Litkowski, Terry Manderson, 664 David Farmer, Jaroslaw Adam Gralak, Gunter Van de Velde, and Juan 665 Alcaide for their comments. 667 8. IANA Considerations 669 This memo includes no request to IANA. 671 9. Security Considerations 673 This draft discusses a process by which one ASN is migrated into and 674 subsumed by another. This involves manipulating the AS_PATH 675 Attribute with the intent of not increasing the AS_PATH length, which 676 would typically cause the BGP route to no longer be selected by BGP's 677 Path Selection Algorithm in other's networks. This could result in a 678 loss of revenue if the ISP is billing based on measured utilization 679 of traffic sent to/from entities attached to its network. This could 680 also result in sudden and unexpected shifts in traffic patterns in 681 the network, potentially resulting in congestion, in the most extreme 682 cases. 684 Given that these features can only be enabled through configuration 685 of router's within a single network, standard security measures 686 should be taken to restrict access to the management interface(s) of 687 routers that implement these features. 689 10. Appendix: Implementation report 691 As noted elsewhere in this document, this set of migration features 692 has multiple existing implementations in wide use. 694 o Cisco [CISCO] 696 o Juniper [JUNIPER] 698 o Alcatel-Lucent [ALU] 699 This is not intended to be an exhaustive list, as equivalent features 700 do exist in other implementations, however the authors were unable to 701 find publicly available documentation of the vendor-specific 702 implementation to reference. 704 11. References 706 11.1. Normative References 708 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 709 Requirement Levels", BCP 14, RFC 2119, March 1997. 711 [RFC5398] Huston, G., "Autonomous System (AS) Number Reservation for 712 Documentation Use", RFC 5398, December 2008. 714 11.2. Informative References 716 [ALU] Alcatel-Lucent, "BGP Local AS attribute", 2006-2012, 717 . 721 [CISCO] Cisco Systems, Inc., "BGP Support for Dual AS 722 Configuration for Network AS Migrations", 2003, 723 . 727 [JUNIPER] Juniper Networks, Inc., "Configuring the BGP Local 728 Autonomous System Attribute", 2012, 729 . 732 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 733 Protocol 4 (BGP-4)", RFC 4271, January 2006. 735 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 736 Reflection: An Alternative to Full Mesh Internal BGP 737 (IBGP)", RFC 4456, April 2006. 739 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 740 System Confederations for BGP", RFC 5065, August 2007. 742 [RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for 743 Private Use", BCP 6, RFC 6996, July 2013. 745 Authors' Addresses 747 Wesley George 748 Time Warner Cable 749 13820 Sunrise Valley Drive 750 Herndon, VA 20171 751 US 753 Phone: +1 703-561-2540 754 Email: wesley.george@twcable.com 756 Shane Amante 757 Apple, Inc. 758 1 Infinite Loop 759 Cupertino, CA 95014 760 US 762 Email: samante@apple.com