idnits 2.17.1 draft-ietf-idr-as-migration-04.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 (April 9, 2015) is 3304 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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: Standards Track S. Amante 5 Expires: October 11, 2015 Apple, Inc. 6 April 9, 2015 8 Autonomous System Migration Mechanisms and Their Effects on the BGP 9 AS_PATH Attribute 10 draft-ietf-idr-as-migration-04 12 Abstract 14 This draft discusses some commonly-used BGP mechanisms for ASN 15 migration that are not formally part of the BGP4 protocol 16 specification and may be vendor-specific in exact implementation. It 17 is necessary to document these de facto standards to ensure that they 18 are properly supported in future BGP protocol work. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on October 11, 2015. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 1.2. Documentation note . . . . . . . . . . . . . . . . . . . 3 57 2. ASN Migration Scenario Overview . . . . . . . . . . . . . . . 3 58 3. External BGP Autonomous System Migration Mechanisms . . . . . 5 59 3.1. Modify Inbound BGP AS_PATH Attribute . . . . . . . . . . 5 60 3.2. Modify Outbound BGP AS_PATH Attribute . . . . . . . . . . 7 61 3.3. Implementation . . . . . . . . . . . . . . . . . . . . . 8 62 4. Internal BGP Autonomous System Migration Mechanisms . . . . . 9 63 4.1. Internal BGP Alias . . . . . . . . . . . . . . . . . . . 9 64 4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 12 65 5. Additional Operational Considerations . . . . . . . . . . . . 13 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 69 9. Appendix: Implementation report . . . . . . . . . . . . . . . 14 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 72 10.2. Informative References . . . . . . . . . . . . . . . . . 15 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 75 1. Introduction 77 This draft discusses some commonly-used BGP mechanisms for Autonomous 78 System Number (ASN) migration that are not formally part of the BGP4 79 [RFC4271] protocol specification and may be vendor-specific in exact 80 implementation. These mechanisms are local to a given BGP Speaker 81 and do not require negotiation with or cooperation of BGP neighbors. 82 The deployment of these mechanisms do not need to interwork with one 83 another to accomplish the desired results, so slight variations 84 between existing vendor implementations exist, and will not 85 necessarily be harmonized due to this document. However, it is 86 necessary to document these de facto standards to ensure that new 87 implementations can be successful, and any future protocol 88 enhancements to BGP that propose to read, copy, manipulate or compare 89 the AS_PATH attribute can do so without inhibiting the use of these 90 very widely used ASN migration mechanisms. 92 The migration mechanisms discussed here are useful to ISPs and 93 organizations of all sizes, but it is important to understand the 94 business need for these mechanisms and illustrate why they are so 95 critical for ISPs' operations. During a merger, acquisition or 96 divestiture involving two organizations it is necessary to seamlessly 97 migrate both internal and external BGP speakers from one ASN to a 98 second ASN. The overall goal in doing so is to simplify operations 99 through consistent configurations across all BGP speakers in the 100 combined network. In addition, given that the BGP Path Selection 101 algorithm selects routes with the shortest AS_PATH attribute, it is 102 critical that the ISP does not increase AS_PATH length during or 103 after ASN migration, because an increased AS_PATH length would likely 104 result in sudden, undesirable changes in traffic patterns in the 105 network. 107 By default, the BGP protocol requires an operator to configure a 108 router to use a single remote ASN for the BGP neighbor, and the ASN 109 must match on both ends of the peering in order to successfully 110 negotiate and establish a BGP session. Prior to the existence of 111 these migration mechanisms, it would have required an ISP to 112 coordinate an ASN change with, in some cases, tens of thousands of 113 customers. In particular, as each router is migrated to the new ASN, 114 to avoid an outage due to ASN mismatch, the ISP would have to force 115 all customers on that router to change their router configurations to 116 use the new ASN immediately after the ASN change. Thus, it becomes 117 critical to allow the ISP to make this process a bit more asymmetric, 118 so that it could seamlessly migrate the ASN within its network(s), 119 but allow the customers to gradually migrate to the ISP's new ASN at 120 their leisure, either by coordinating individual reconfigurations, or 121 accepting sessions using either the old or new ASN to allow for truly 122 asymmetric migration. 124 1.1. Requirements Language 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC 2119 [RFC2119]. 130 1.2. Documentation note 132 This draft uses Autonomous System Numbers (ASNs) from the range 133 reserved for documentation as described in RFC 5398 [RFC5398]. In 134 the examples used here, they are intended to represent Globally 135 Unique ASNs, not private use ASNs as documented in RFC 6996 [RFC6996] 136 section 5. 138 2. ASN Migration Scenario Overview 140 The use case being discussed here is an ISP merging two or more ASNs, 141 where eventually one ASN subsumes the other(s). In this use case, we 142 will assume the most common case where there are two ISPs, A and B, 143 that prior to the ASN migration use AS 64500 and 64510, respectively. 144 AS 64500 will be the permanently retained ASN used across the 145 consolidated set of both ISPs network equipment, and AS 64510 will be 146 retired. Thus, at the conclusion of the ASN migration, there will be 147 a single ISP A' with all internal BGP speakers configured to use AS 148 64500. To all external BGP speakers, the AS_PATH length will not be 149 increased. 151 In this same scenario, AS 64496 and AS 64499 represent two separate 152 customer networks: C and D, respectively. Originally, customer C (AS 153 64496) is attached to ISP B, which will undergo ASN migration from AS 154 64510 to AS 64500. Furthermore, customer D (AS 64499) is attached to 155 ISP A, which does not undergo ASN migration since the ASN for ISP A 156 will remain constant, (AS 64500). Although this example refers to AS 157 64496 and 64499 as customer networks, either or both may be 158 settlement-free or other types of peers. In this use case they are 159 referred to as "customers" merely for convenience. 161 ------ ------ 162 / ISP A \ / ISP B \ 163 | AS 64500 | | AS 64510 | 164 \ / \ / 165 ------- ------- 166 | | 167 | | 168 ------------ ------------- 169 | Cust D | | Cust C | 170 | AS 64499 | | AS 64496 | 171 ------------ ------------- 173 Figure 1: Before Migration 175 --------------- 176 / \ 177 | ISP A' | 178 | AS 64500 | 179 \ / 180 --------------- 181 / \ 182 / \ 183 | | 184 ------------ ------------- 185 | Cust D | | Cust C | 186 | AS 64499 | | AS 64496 | 187 ------------ ------------- 189 Figure 2: After Migration 191 The general order of operations, typically carried out in a single 192 maintenance window by the network undergoing ASN migration (ISP B), 193 are as follows. First, ISP B will change the global BGP ASN used by 194 a Provider Edge (PE) router, from ASN 64510 to 64500. At this point, 195 the router will no longer be able to establish eBGP sessions toward 196 the existing Customer Edge (CE) devices that are attached to it and 197 still using AS 64510. Second, since ISP B needs to do this without 198 coordinating the simultaneous change of its ASN with all of its eBGP 199 peers, ISP B will configure two separate, but related ASN migration 200 mechanisms discussed in this document on all eBGP sessions toward all 201 CE devices. These mechanisms enable the router to establish BGP 202 neighbors using the legacy ASN, modify the AS_PATH attribute received 203 from a CE device when advertising it further, and modify AS_PATH when 204 transmitted toward CE devices to achieve the desired effect of not 205 increasing the length of the AS_PATH. 207 At the conclusion of the ASN migration, the CE devices at the edge of 208 the network are not aware of the fact that their upstream router is 209 now in a new ASN and do not observe any change in the length of the 210 AS_PATH attribute. However, after the changes discussed in this 211 document are put in place by ISP A', there is a change to the 212 contents of the AS_PATH attribute to ensure the AS_PATH is not 213 artificially lengthened while these AS migration parameters are used. 215 In this use case, neither ISP is using BGP Confederations RFC 5065 216 [RFC5065] internally. 218 3. External BGP Autonomous System Migration Mechanisms 220 The following section addresses optional capabilities that are 221 specific to modifying the AS_PATH attribute at the Autonomous System 222 Border Routers (ASBRs) of an organization, (typically a single 223 Service Provider). This ensures that external BGP customers/peers 224 are not forced to make any configuration changes on their CE routers 225 before or during the exact time the Service Provider wishes to 226 migrate to a new, permanently retained ASN. Furthermore, these 227 mechanisms eliminate the artificial lengthening of the AS_PATH both 228 transmitted from and received by the Service Provider that is 229 undergoing AS Migration, which would have negative implications on 230 path selection by external networks. 232 3.1. Modify Inbound BGP AS_PATH Attribute 234 The first instrument used in the process described above is called 235 "Local AS". This allows the router to supersede the globally 236 configured ASN in the "My Autonomous System" field of the BGP OPEN 237 [RFC4271] with a locally defined AS value, usually configured on a 238 per-neighbor basis. This mechanism allows the PE router that was 239 formerly in ISP B to establish an eBGP session toward the existing CE 240 devices using the legacy AS, AS 64510. Ultimately, the CE devices 241 (i.e.: customer C) are completely unaware that ISP B has reconfigured 242 its router to participate as a member of a new AS. Within the 243 context of the former ISP B PE router, the second effect this 244 specific mechanism has on AS_PATH is that, by default, it prepends 245 all received BGP UPDATEs with the legacy AS of ISP B: AS 64510, while 246 advertising it (Adj-RIB-Out) to other BGP speakers (A'). Within the 247 Loc-RIB on ISP B prior to the migration, the AS_PATH toward customer 248 C would appear as: 64510, whereas the same RIB on ISP A' (ISP B 249 routers post-migration) would contain AS_PATH: 64510 64496. 251 A second instrument, referred to as "No Prepend Inbound", is enabled 252 on PE routers migrating from ISP B. The "No Prepend Inbound" 253 capability causes ISP B's routers to not prepend the legacy AS, AS 254 64510, when advertising UPDATES received from customer C. This 255 restores the AS_PATH within ISP A' toward customer C so that it is 256 just one ASN in length: 64496. 258 In the direction of CE -> PE (inbound): 260 1. "Local AS": Allows the local BGP router to generate a BGP OPEN to 261 an eBGP neighbor with the old, legacy ASN value in the "My 262 Autonomous System" field. When this capability is activated, it 263 also causes the local router to prepend the value to 264 the AS_PATH when advertising routes received from a CE to iBGP 265 neighbors inside the Autonomous System. 267 2. "No Prepend Inbound (of Local AS)": the local BGP router does not 268 prepend value to the AS_PATH when advertising routes 269 received from the CE to iBGP neighbors inside the Autonomous 270 System 272 PE-B is a PE that was originally in ISP B, and has a customer eBGP 273 session to CE-B. PE-B has had its global configuration ASN changed 274 from AS 64510 to AS 64500 to make it part of the permanently retained 275 ASN. This now makes PE-B a member of ISP A'. PE-A is a PE that was 276 originally in ISP A, and has a customer peer CE-A. Although its 277 global configuration ASN remains AS 64500, throughout this exercise 278 we also consider PE-A a member of ISP A'. 280 ISP A' ISP A' 281 CE-A <--- PE-A <------------------- PE-B <--- CE-B 282 64499 New_ASN: 64500 Old_ASN: 64510 64496 283 New_ASN: 64500 285 Note: Direction of BGP UPDATE as per the arrows. 287 Figure 3: Local AS and No Prepend BGP UPDATE Diagram 289 As a result using both the "Local AS" and "No Prepend Inbound" 290 capabilities on PE-B, CE-A will see an AS_PATH of: 64500 64496. CE-A 291 will not receive a BGP UPDATE containing AS 64510 in the AS_PATH. 292 (If only the "Local AS" mechanism was configured without "No Prepend 293 Inbound" on PE-B, then CE-A would have seen an AS_PATH of: 64496 294 64510 64500, which results in an unacceptable lengthening of the 295 AS_PATH). 297 3.2. Modify Outbound BGP AS_PATH Attribute 299 The two aforementioned mechanisms, "Local AS" and "No Prepend 300 Inbound", only modify the AS_PATH Attribute received by the ISP's 301 PE's in the course of processing BGP UPDATEs from CE devices when CE 302 devices still have an eBGP session established with the ISPs legacy 303 AS, (AS64510). 305 In some existing implementations, "Local AS" and "No Prepend Inbound" 306 does not concurrently modify the AS_PATH Attribute for BGP UPDATEs 307 that are transmitted by the ISP's PE's to CE devices. In these 308 implementations, with "Local AS" and "No Prepend Inbound" used on PE- 309 B, it automatically causes a lengthening of the AS_PATH in outbound 310 BGP UPDATEs from ISP A' toward directly attached eBGP speakers, 311 (Customer C in AS 64496). The externally observed result is that 312 customer C, in AS 64496, will receive the following AS_PATH: 64510 313 64500 64499. Therefore, if ISP A' takes no further action, it will 314 cause an unacceptable increase in AS_PATH length within customer's 315 networks directly attached to ISP A'. 317 A tertiary mechanism is used to resolve this problem, referred to as 318 "Replace Old AS". This capability allows ISP A' to prevent routers 319 from appending the globally configured ASN in outbound BGP UPDATEs 320 toward directly attached eBGP neighbors that are using the "Local AS" 321 mechanism. Instead, only the old (or previously used) AS will be 322 prepended in the outbound BGP UPDATE toward the customer's network, 323 restoring the AS_PATH length to what it what was before AS Migration 324 occurred. 326 To re-use the above diagram, but in the opposite direction, we have: 328 ISP A' ISP A' 329 CE-A ---> PE-A -------------------> PE-B ---> CE-B 330 64499 New_ASN: 64500 Old_ASN: 64510 64496 331 New_ASN: 64500 333 Note: Direction of BGP UPDATE as per the arrows. 335 Figure 4: Replace AS BGP UPDATE Diagram 337 By default, without the use of "Replace Old AS", CE-B would see an 338 AS_PATH of: 64510 64500 64499, which is artificially lengthened, 339 typically by use of the "Local AS" and/or "No Prepend" capabilities 340 during the course of the ASN Migration. After ISP A' changes PE-B to 341 use "Replace Old AS", CE-B would receive an AS_PATH of: 64510 64499, 342 which is the same AS_PATH length pre-AS migration. NOTE: If there 343 are still routers in the old ASN, it is possible for them to accept 344 these manipulated routes as if they have not already passed through 345 their ASN, potentially causing a loop, since BGP's normal loop- 346 prevention behavior of rejecting routes that include its ASN in the 347 path will not catch these. Careful filtering between routers 348 remaining in the old ASN and routers migrated to the new ASN is 349 necessary to minimize the risk of routing loops. 351 3.3. Implementation 353 While multiple implementations already exist, the following documents 354 the expected behavior such that a new implementation of this 355 mechanism could be done on other platforms. 357 These mechanisms MUST be configurable on a per-neighbor or per peer- 358 group basis to allow for maximum flexibility. When the "Local AS" 359 capability is used, a local ASN will be provided in the configuration 360 that is different from the globally-configured ASN of the BGP router. 361 To implement this mechanism, a BGP speaker MUST send BGP OPEN 362 [RFC4271] (see section 4.2) messages to the configured eBGP peer(s) 363 using the local ASN configured for this session as the value sent in 364 "My Autonomous System". The BGP router MUST NOT use the ASN 365 configured globally within the BGP process as the value sent in "My 366 Autonomous System" in the OPEN message. This will avoid causing the 367 eBGP neighbor to unnecessarily generate a BGP OPEN Error message "Bad 368 Peer AS". This method is typically used to re-establish eBGP 369 sessions with peers expecting the legacy ASN after a router has been 370 moved to a new ASN. 372 Implementations MAY support a more flexible model where the eBGP 373 speaker attempts to open the BGP session using either the ASN 374 configured as "Local AS" or the globally configured AS as discussed 375 in BGP Alias (Section 4.2). If the session is successfully 376 established to the globally configured ASN, then the modifications to 377 AS_PATH described in this document SHOULD NOT be performed, as they 378 are unnecessary. The benefit to this more flexible model is that it 379 allows the remote neighbor to reconfigure to the new ASN without 380 direct coordination between the ISP and the customer. 382 When the BGP router receives UPDATEs from its eBGP neighbor 383 configured with the "Local AS" mechanism, it processes the UPDATE as 384 described in RFC4271 section 5.1.2 [RFC4271]. However the presence 385 of a second ASN due to "Local AS" adds the following behavior to 386 processing UPDATEs received from an eBGP neighbor configured with 387 this mechanism: 389 1. Internal: the router MUST append the configured "Local AS" ASN in 390 the AS_PATH attribute before advertising the UPDATE to an iBGP 391 neighbor. 393 2. External: the BGP router MUST first append the globally 394 configured ASN to the AS_PATH immediately followed by the "Local 395 AS" value before advertising the UPDATE to an eBGP neighbor. 397 Two options exist to manipulate the behavior of the basic "Local AS" 398 mechanism. They modify the behavior as described below: 400 1. "No Prepend Inbound" - When the BGP router receives inbound BGP 401 UPDATEs from its eBGP neighbor configured with this option, it 402 MUST NOT append the "Local AS" ASN value in the AS_PATH attribute 403 when advertising that UPDATE to iBGP neighbors, but it MUST still 404 append the globally configured ASN as normal when advertising the 405 UPDATE to other local eBGP neigbors (i.e. those natively peering 406 with the globally configured ASN). 408 2. "Replace Old AS", (outbound) - When the BGP router generates 409 outbound BGP UPDATEs toward an eBGP neighbor configured with this 410 option, the BGP speaker MUST NOT (first) append the globally 411 configured ASN from the AS_PATH attribute. The BGP router MUST 412 append only the configured "Local AS" ASN value to the AS_PATH 413 attribute before sending the BGP UPDATEs outbound to the eBGP 414 neighbor. 416 4. Internal BGP Autonomous System Migration Mechanisms 418 The following section describes mechanisms that assist with a gradual 419 and least service impacting migration of Internal BGP sessions from a 420 legacy ASN to the permanently retained ASN. The following mechanism 421 is very valuable to networks undergoing AS migration, but its use 422 does not cause changes to the AS_PATH attribute. 424 4.1. Internal BGP Alias 426 In this case, all of the routers to be consolidated into a single, 427 permanently retained ASN are under the administrative control of a 428 single entity. Unfortunately, the traditional method of migrating 429 all Internal BGP speakers, particularly within larger networks, is 430 both time consuming and widely service impacting. 432 The traditional method to migrate Internal BGP sessions was strictly 433 limited to reconfiguration of the global configuration ASN and, 434 concurrently, changing all iBGP neighbors' remote ASN from the legacy 435 ASN to the new, permanently retained ASN on each router within the 436 legacy AS. These changes can be challenging to swiftly execute in 437 networks with with more than a few dozen internal BGP routers. There 438 is also the concomitant service interruptions as these changes are 439 made to routers within the network, resulting in a reset of iBGP 440 sessions and subsequent route reconvergence to reestablish optimal 441 routing paths. Operators often cannot make such sweeping changes 442 given the associated risks of a highly visible service interruption; 443 rather, they require a more gradual method to migrate Internal BGP 444 sessions, from one ASN to a second, permanently retained ASN, that is 445 not visibly service-impacting to its customers. 447 With the "Internal BGP AS Migration" mechanism described herein, it 448 allows an Internal BGP speaker to form a single iBGP session using 449 either the old, legacy ASN or the new, permanently retained ASN. The 450 benefits of using this mechanism are several fold. First, it allows 451 for a more gradual and less service-impacting migration away from the 452 legacy ASN to the permanently retained ASN. Second, it (temporarily) 453 permits the coexistence of the legacy and permanently retained ASN 454 within a single network, allowing for uniform BGP path selection 455 among all routers within the consolidated network. 457 The iBGP router with the "Internal BGP AS Migration" capability 458 enabled allows the receipt of a BGP OPEN message with either the 459 legacy ASN value or the new, globally configured ASN value in the "My 460 Autonomous System" field of the BGP OPEN message from iBGP neighbors. 461 It is important to recognize that enablement of the "Internal BGP AS 462 Migration" mechanism preserves the semantics of a regular iBGP 463 session, (using identical ASNs). Thus, the BGP attributes 464 transmitted by and the acceptable methods of operation on BGP 465 attributes received from iBGP sessions configured with "Internal BGP 466 AS Migration" capability are no different than those exchanged across 467 an iBGP session without "Internal BGP AS Migration" configured, as 468 defined by [RFC4271] and [RFC4456]. 470 Typically, in medium to large networks, BGP Route Reflectors 471 [RFC4456] (RRs) are used to aid in reduction of configuration of iBGP 472 sessions and scalability with respect to overall TCP (and, BGP) 473 session maintenance between adjacent iBGP routers. Furthermore, BGP 474 Route Reflectors are typically deployed in pairs within a single 475 Route Reflection cluster to ensure high reliability of the BGP 476 Control Plane. As such, the following example will use Route 477 Reflectors to aid in understanding the use of the "Internal BGP AS 478 Migration" mechanism. Note that Route Reflectors are not a 479 prerequisite to enable "Internal BGP AS Migration" and this mechanism 480 can be enabled independent of the use of Route Reflectors. 482 The general order of operations is as follows: 484 1. Within the legacy network, (the routers comprising the set of 485 devices that still have a globally configured legacy ASN), one 486 member of a redundant pair of RRs has its global configuration 487 ASN changed to the permanently retained ASN. Concurrently, the 488 "Internal BGP AS Migration" capability is enabled on all iBGP 489 sessions on that device. This will comprise Non-Client iBGP 490 sessions to other RRs as well as Client iBGP sessions, typically 491 to PE devices, both still utilizing the legacy ASN. Note that 492 during this step there will be a reset and reconvergence event on 493 all iBGP sessions on the RRs whose configuration was modified; 494 however, this should not be service impacting due to the use of 495 redundant RRs in each RR Cluster. 497 2. The above step is repeated for the other side of the redundant 498 pair of RRs. The one alteration to the above procedure is that 499 the "Internal BGP AS Migration" mechanism is now removed from the 500 Non-Client iBGP sessions toward the other (previously 501 reconfigured) RRs, since it is no longer needed. The "Internal 502 BGP AS Migration" mechanism is still required on all RRs for all 503 RR Client iBGP sessions. Also during this step, there will be a 504 reset and reconvergence event on all iBGP sessions whose 505 configuration was modified, but this should not be service 506 impacting. At the conclusion of this step, all RRs should now 507 have their globally configured ASN set to the permanently 508 retained ASN and "Internal BGP AS Migration" enabled and in use 509 toward RR Clients. 511 3. At this point, the network administrators would then be able to 512 establish iBGP sessions between all Route Reflectors in both the 513 legacy and permanently retained networks. This would allow the 514 network to appear to function, both internally and externally, as 515 a single, consolidated network using the permanently retained 516 network. 518 4. To complete the AS migration, each RR Client (PE) in the legacy 519 network still utilizing the legacy ASN is now modified. 520 Specifically, each legacy PE would have its globally configured 521 ASN changed to use the permanently retained ASN. The ASN 522 configured within the PE for the iBGP sessions toward each RR 523 would be changed to use the permanently retained ASN. It is 524 unnecessary to enable "Internal BGP AS Migration" mechanism on 525 these migrated iBGP sessions. During the same maintenance 526 window, External BGP sessions would be modified to include the 527 above "Local AS", "No Prepend" and "Replace Old AS" mechanisms 528 described in Section 3 above, since all of the changes are 529 service interrupting to the eBGP sessions of the PE. At this 530 point, all PEs will have been migrated to the permanently 531 retained ASN. 533 5. The final step is to excise the "Internal BGP AS Migration" 534 configuration from the Router Reflectors in an orderly fashion. 535 After this is complete, all routers in the network will be using 536 the new, permanently retained ASN for all iBGP sessions with no 537 vestiges of the legacy ASN on any iBGP sessions. 539 The benefit of using the aforementioned "Internal BGP AS Migration" 540 capability is that it is a more gradual and less externally service- 541 impacting change to accomplish an AS migration. Previously, without 542 "Internal BGP AS Migration", such an AS migration change would carry 543 a high risk and need to be successfully accomplished in a very short 544 timeframe (e.g.: at most several hours). In addition, it would 545 likely cause substantial routing churn and rapid fluctuations in 546 traffic carried -- potentially causing periods of congestion and 547 resultant packet loss -- during the period the configuration changes 548 are underway to complete the AS Migration. On the other hand, with 549 "Internal BGP AS Migration", the migration from the legacy ASN to the 550 permanently retained ASN can occur over a period of days or weeks 551 with reduced customer disruption. (The only observable service 552 disruption should be when each PE undergoes the changes discussed in 553 step 4 above.) 555 4.2. Implementation 557 When configured with this mechanism, a BGP speaker MUST accept BGP 558 OPEN and establish an iBGP session from configured iBGP peers if the 559 ASN value in "My Autonomous System" is either the globally configured 560 ASN or a locally configured ASN provided when this capability is 561 utilized. Additionally, a BGP router configured with this mechanism 562 MUST send its own BGP OPEN [RFC4271] (see section 4.2) using both the 563 globally configured and the locally configured ASN in "My Autonomous 564 System". To avoid potential deadlocks when two BGP speakers are 565 attempting to establish a BGP peering session and are both configured 566 with this mechanism, the speaker SHOULD send BGP OPEN using the 567 globally configured ASN first, and only send a BGP OPEN using the 568 locally configured ASN as a fallback if the remote neighbor responds 569 with the BGP error "Bad Peer AS". In each case, the BGP speaker MUST 570 treat UPDATEs sent and received to this peer as if this was a 571 natively configured iBGP session, as defined by [RFC4271] and 572 [RFC4456]. 574 5. Additional Operational Considerations 576 This document describes several mechanisms to support ISPs and other 577 organizations that need to perform ASN migrations. Other variations 578 of these mechanisms may exist, for example, in legacy router software 579 that has not been upgraded or reached End of Life, but continues to 580 operate in the network. Such variations are beyond the scope of this 581 document. 583 Companies routinely go through periods of mergers, acquisitions and 584 divestitures, which in the case of the former cause them to 585 accumulate several legacy ASNs over time. ISPs often do not have 586 control over the configuration of customers' devices (i.e.: the ISPs 587 are often not providing a managed CE router service, particularly to 588 medium and large customers that require eBGP). Furthermore, ISPs are 589 using methods to perform ASN migration that do not require 590 coordination with customers. Ultimately, this means there is not a 591 finite period of time after which legacy ASNs will be completely 592 expunged from the ISP's network. In fact, it is common that legacy 593 ASNs and the associated External BGP AS Migration mechanisms 594 discussed in this document can and do persist for several years, if 595 not longer. Thus, it is prudent to plan that legacy ASNs and 596 associated External BGP AS Migration mechanisms will persist in a 597 operational network indefinitely. 599 With respect to the Internal BGP AS Migration mechanism, all of the 600 routers to be consolidated into a single, permanently retained ASN 601 are under the administrative control of a single entity. Thus, 602 completing the migration from iBGP sessions using the legacy ASN to 603 the permanently retained ASN is more straightforward and could be 604 accomplished in a matter of days to months. Finally, good 605 operational hygiene would dictate that it is good practice to avoid 606 using "Internal BGP AS Migration" capability over a long period of 607 time for reasons of not only operational simplicity of the network, 608 but also reduced reliance on that mechanism during the ongoing 609 lifecycle management of software, features and configurations that 610 are maintained on the network. 612 6. Acknowledgements 614 Thanks to Kotikalapudi Sriram, Stephane Litkowski, Terry Manderson, 615 David Farmer, Jaroslaw Adam Gralak, Gunter Van de Velde, Juan 616 Alcaide, Jon Mitchell, Thomas Morin, Alia Atlas, and Alvaro Retana 617 for their comments. 619 7. IANA Considerations 621 This memo includes no request to IANA. 623 8. Security Considerations 625 This draft discusses a process by which one ASN is migrated into and 626 subsumed by another. This involves manipulating the AS_PATH 627 Attribute with the intent of not increasing the AS_PATH length, which 628 would typically cause the BGP route to no longer be selected by BGP's 629 Path Selection Algorithm in others' networks. This could result in 630 sudden and unexpected shifts in traffic patterns in the network, 631 potentially resulting in congestion. 633 Given that these mechanisms can only be enabled through configuration 634 of routers within a single network, standard security measures should 635 be taken to restrict access to the management interface(s) of routers 636 that implement these mechanisms. Additionally, BGP sessions SHOULD 637 be protected using TCP Authentication Option [RFC5925] and the 638 Generalized TTL Security Mechanism [RFC5082] 640 9. Appendix: Implementation report 642 As noted elsewhere in this document, this set of migration mechanisms 643 has multiple existing implementations in wide use. 645 o Cisco [CISCO] 647 o Juniper [JUNIPER] 649 o Alcatel-Lucent [ALU] 651 This is not intended to be an exhaustive list, as equivalent features 652 do exist in other implementations, however the authors were unable to 653 find publicly available documentation of the vendor-specific 654 implementation to reference. 656 10. References 658 10.1. Normative References 660 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 661 Requirement Levels", BCP 14, RFC 2119, March 1997. 663 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 664 Protocol 4 (BGP-4)", RFC 4271, January 2006. 666 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 667 Reflection: An Alternative to Full Mesh Internal BGP 668 (IBGP)", RFC 4456, April 2006. 670 10.2. Informative References 672 [ALU] Alcatel-Lucent, "BGP Local AS attribute", 2006-2012, 673 . 677 [CISCO] Cisco Systems, Inc., "BGP Support for Dual AS 678 Configuration for Network AS Migrations", 2003, 679 . 683 [JUNIPER] Juniper Networks, Inc., "Configuring the BGP Local 684 Autonomous System Attribute", 2012, 685 . 688 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 689 System Confederations for BGP", RFC 5065, August 2007. 691 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 692 Pignataro, "The Generalized TTL Security Mechanism 693 (GTSM)", RFC 5082, October 2007. 695 [RFC5398] Huston, G., "Autonomous System (AS) Number Reservation for 696 Documentation Use", RFC 5398, December 2008. 698 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 699 Authentication Option", RFC 5925, June 2010. 701 [RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for 702 Private Use", BCP 6, RFC 6996, July 2013. 704 Authors' Addresses 706 Wesley George 707 Time Warner Cable 708 13820 Sunrise Valley Drive 709 Herndon, VA 20171 710 US 712 Phone: +1 703-561-2540 713 Email: wesley.george@twcable.com 714 Shane Amante 715 Apple, Inc. 716 1 Infinite Loop 717 Cupertino, CA 95014 718 US 720 Email: samante@apple.com