idnits 2.17.1 draft-ietf-idr-as-migration-06.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4271, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4271, updated by this document, for RFC5378 checks: 2006-01-13) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 6, 2015) is 3189 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) -- Obsolete informational reference (is this intentional?): RFC 4893 (Obsoleted by RFC 6793) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 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 Updates: 4271 (if approved) S. Amante 5 Intended status: Standards Track Apple, Inc. 6 Expires: January 7, 2016 July 6, 2015 8 Autonomous System Migration Mechanisms and Their Effects on the BGP 9 AS_PATH Attribute 10 draft-ietf-idr-as-migration-06 12 Abstract 14 This draft discusses some existing commonly-used BGP mechanisms for 15 ASN migration that are not formally part of the BGP4 protocol 16 specification. It is necessary to document these de facto standards 17 to ensure that they are properly supported in future BGP protocol 18 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 January 7, 2016. 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 AS Migration . . . . . . . . . . . . . . . . 10 64 4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 12 65 5. Additional Operational Considerations . . . . . . . . . . . . 13 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 71 9.2. Informative References . . . . . . . . . . . . . . . . . 15 72 Appendix A. Implementation report . . . . . . . . . . . . . . . 15 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 75 1. Introduction 77 This draft discusses some existing commonly-used BGP mechanisms for 78 Autonomous System Number (ASN) migration that are not formally part 79 of the BGP4 [RFC4271] protocol specification. These mechanisms are 80 local to a given BGP Speaker and do not require negotiation with or 81 cooperation of BGP neighbors. The deployment of these mechanisms do 82 not need to interwork with one another to accomplish the desired 83 results, so slight variations between existing vendor implementations 84 exist, and will not necessarily be harmonized due to this document. 85 However, it is necessary to document these de facto standards to 86 ensure that new implementations can be successful, and any future 87 protocol enhancements to BGP that propose to read, copy, manipulate 88 or compare the AS_PATH attribute can do so without inhibiting the use 89 of these very widely used ASN migration mechanisms. 91 The migration mechanisms discussed here are useful to ISPs and 92 organizations of all sizes, but it is important to understand the 93 business need for these mechanisms and illustrate why they are so 94 critical for ISPs' operations. During a merger, acquisition or 95 divestiture involving two organizations it is necessary to seamlessly 96 migrate both internal and external BGP speakers from one ASN to a 97 second ASN. The overall goal in doing so is to simplify operations 98 through consistent configurations across all BGP speakers in the 99 combined network. In addition, given that the BGP Path Selection 100 algorithm selects routes with the shortest AS_PATH attribute, it is 101 critical that the ISP does not increase AS_PATH length during or 102 after ASN migration, because an increased AS_PATH length would likely 103 result in sudden, undesirable changes in traffic patterns in the 104 network. 106 By default, the BGP protocol requires an operator to configure a 107 router to use a single remote ASN for the BGP neighbor, and the ASN 108 must match on both ends of the peering in order to successfully 109 negotiate and establish a BGP session. Prior to the existence of 110 these migration mechanisms, it would have required an ISP to 111 coordinate an ASN change with, in some cases, tens of thousands of 112 customers. In particular, as each router is migrated to the new ASN, 113 to avoid an outage due to ASN mismatch, the ISP would have to force 114 all customers on that router to change their router configurations to 115 use the new ASN immediately after the ASN change. Thus, it becomes 116 critical to allow the ISP to make this process a bit more asymmetric, 117 so that it could seamlessly migrate the ASN within its network(s), 118 but allow the customers to gradually migrate to the ISP's new ASN at 119 their leisure, either by coordinating individual reconfigurations, or 120 accepting sessions using either the old or new ASN to allow for truly 121 asymmetric migration. 123 1.1. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 1.2. Documentation note 131 This draft uses Autonomous System Numbers (ASNs) from the range 132 reserved for documentation as described in RFC 5398 [RFC5398]. In 133 the examples used here, they are intended to represent Globally 134 Unique ASNs, not private use ASNs as documented in RFC 6996 [RFC6996] 135 section 5. 137 2. ASN Migration Scenario Overview 139 The use case being discussed here is an ISP merging two or more ASNs, 140 where eventually one ASN subsumes the other(s). In this use case, we 141 will assume the most common case where there are two ISPs, A and B, 142 that prior to the ASN migration use AS 64500 and 64510, respectively. 143 AS 64500 will be the permanently retained ASN used across the 144 consolidated set of both ISPs network equipment, and AS 64510 will be 145 retired. Thus, at the conclusion of the ASN migration, there will be 146 a single ISP A' with all internal BGP speakers configured to use AS 147 64500. To all external BGP speakers, the AS_PATH length will not be 148 increased. 150 In this same scenario, AS 64496 and AS 64499 represent two separate 151 customer networks: C and D, respectively. Originally, customer C (AS 152 64496) is attached to ISP B, which will undergo ASN migration from AS 153 64510 to AS 64500. Furthermore, customer D (AS 64499) is attached to 154 ISP A, which does not undergo ASN migration since the ASN for ISP A 155 will remain constant, (AS 64500). Although this example refers to AS 156 64496 and 64499 as customer networks, either or both may be 157 settlement-free or other types of peers. In this use case they are 158 referred to as "customers" merely for convenience. 160 ------ ------ 161 / ISP A \ / ISP B \ 162 | AS 64500 | | AS 64510 | 163 \ / \ / 164 ------- ------- 165 | | 166 | | 167 ------------ ------------- 168 | Cust D | | Cust C | 169 | AS 64499 | | AS 64496 | 170 ------------ ------------- 172 Figure 1: Before Migration 174 --------------- 175 / \ 176 | ISP A' | 177 | AS 64500 | 178 \ / 179 --------------- 180 / \ 181 / \ 182 | | 183 ------------ ------------- 184 | Cust D | | Cust C | 185 | AS 64499 | | AS 64496 | 186 ------------ ------------- 188 Figure 2: After Migration 190 The general order of operations, typically carried out in a single 191 maintenance window by the network undergoing ASN migration (ISP B), 192 are as follows. First, ISP B will change the global BGP ASN used by 193 a Provider Edge (PE) router, from ASN 64510 to 64500. At this point, 194 the router will no longer be able to establish eBGP sessions toward 195 the existing Customer Edge (CE) devices that are attached to it and 196 still using AS 64510. Second, since ISP B needs to do this without 197 coordinating the simultaneous change of its ASN with all of its eBGP 198 peers, ISP B will configure two separate, but related ASN migration 199 mechanisms discussed in this document on all eBGP sessions toward all 200 CE devices. These mechanisms enable the router to establish BGP 201 neighbors using the legacy ASN, modify the AS_PATH attribute received 202 from a CE device when advertising it further, and modify AS_PATH when 203 transmitted toward CE devices to achieve the desired effect of not 204 increasing the length of the AS_PATH. 206 At the conclusion of the ASN migration, the CE devices at the edge of 207 the network are not aware of the fact that their upstream router is 208 now in a new ASN and do not observe any change in the length of the 209 AS_PATH attribute. However, after the changes discussed in this 210 document are put in place by ISP A', there is a change to the 211 contents of the AS_PATH attribute to ensure the AS_PATH is not 212 artificially lengthened while these AS migration parameters are used. 214 In this use case, neither ISP is using BGP Confederations RFC 5065 215 [RFC5065] internally. 217 3. External BGP Autonomous System Migration Mechanisms 219 The following section addresses optional capabilities that are 220 specific to modifying the AS_PATH attribute at the Autonomous System 221 Border Routers (ASBRs) of an organization, (typically a single 222 Service Provider). This ensures that external BGP customers/peers 223 are not forced to make any configuration changes on their CE routers 224 before or during the exact time the Service Provider wishes to 225 migrate to a new, permanently retained ASN. Furthermore, these 226 mechanisms eliminate the artificial lengthening of the AS_PATH both 227 transmitted from and received by the Service Provider that is 228 undergoing AS Migration, which would have negative implications on 229 path selection by external networks. 231 3.1. Modify Inbound BGP AS_PATH Attribute 233 The first instrument used in the process described above is called 234 "Local AS". This allows the router to supersede the globally 235 configured ASN in the "My Autonomous System" field of the BGP OPEN 236 [RFC4271] with a locally defined AS value for a specific BGP neighbor 237 or group of neighbors. This mechanism allows the PE router that was 238 formerly in ISP B to establish an eBGP session toward the existing CE 239 devices using the legacy AS, AS 64510. Ultimately, the CE devices 240 (i.e.: customer C) are completely unaware that ISP B has reconfigured 241 its router to participate as a member of a new AS. Within the 242 context of the former ISP B PE router, the second effect this 243 specific mechanism has on AS_PATH is that, by default, it prepends 244 all received BGP UPDATEs with the legacy AS of ISP B: AS 64510, while 245 advertising it (Adj-RIB-Out) to other BGP speakers (A'). Within the 246 Loc-RIB on ISP B prior to the migration, the AS_PATH of route 247 announcements received from customer C would appear as: 64496, 248 whereas the same RIB on ISP A' (ISP B routers post-migration) would 249 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' for route announcements received 256 from customer C so that it is 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 installing or advertising routes received from a 265 CE to iBGP 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 installing or 269 advertising routes received from the CE to iBGP neighbors inside 270 the Autonomous 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: 64500 294 64510 64496, which results in an unacceptable lengthening of the 295 AS_PATH). NOTE: If there are still routers in the old ASN (64510), 296 it is possible for them to accept these manipulated routes (i.e. 297 those with 64510 removed from the AS_PATH by this command) as if they 298 have not already passed through their ASN, potentially causing a 299 loop, since BGP's normal loop-prevention behavior of rejecting routes 300 that include its ASN in the path will not catch these. Careful 301 filtering between routers remaining in the old ASN and routers 302 migrated to the new ASN is necessary to minimize the risk of routing 303 loops. 305 3.2. Modify Outbound BGP AS_PATH Attribute 307 The two aforementioned mechanisms, "Local AS" and "No Prepend 308 Inbound", only modify the AS_PATH Attribute received by the ISP's 309 PE's in the course of processing BGP UPDATEs from CE devices when CE 310 devices still have an eBGP session established with the ISPs legacy 311 AS (AS64510). 313 In some existing implementations, "Local AS" and "No Prepend Inbound" 314 does not concurrently modify the AS_PATH Attribute for BGP UPDATEs 315 that are transmitted by the ISP's PE's to CE devices. In these 316 implementations, with "Local AS" and "No Prepend Inbound" used on PE- 317 B, it automatically causes a lengthening of the AS_PATH in outbound 318 BGP UPDATEs from ISP A' toward directly attached eBGP speakers, 319 (Customer C in AS 64496). The externally observed result is that 320 customer C, in AS 64496, will receive the following AS_PATH: 64510 321 64500 64499. Therefore, if ISP A' takes no further action, it will 322 cause an unacceptable increase in AS_PATH length within customer's 323 networks directly attached to ISP A'. 325 A tertiary mechanism, referred to as "Replace Old AS", is used to 326 resolve this problem. This capability allows ISP A' to prevent 327 routers from appending the globally configured ASN in outbound BGP 328 UPDATEs toward directly attached eBGP neighbors that are using the 329 "Local AS" mechanism. Instead, only the old (or previously used) AS 330 will be prepended in the outbound BGP UPDATE toward the customer's 331 network, restoring the AS_PATH length to what it what was before AS 332 Migration occurred. 334 To re-use the above diagram, but in the opposite direction, we have: 336 ISP A' ISP A' 337 CE-A ---> PE-A -------------------> PE-B ---> CE-B 338 64499 New_ASN: 64500 Old_ASN: 64510 64496 339 New_ASN: 64500 341 Note: Direction of BGP UPDATE as per the arrows. 343 Figure 4: Replace AS BGP UPDATE Diagram 345 By default, without the use of "Replace Old AS", CE-B would see an 346 AS_PATH of: 64510 64500 64499. After ISP A' changes PE-B to use 347 "Replace Old AS", CE-B would receive an AS_PATH of: 64510 64499, 348 which is the same AS_PATH length pre-AS migration. 350 3.3. Implementation 352 The mechanisms introduced in this section MUST be configurable on a 353 per-neighbor or per neighbor group (i.e. a group of similar BGP 354 neighbor statements that reuse some common configuration to simplify 355 provisioning) basis to allow for maximum flexibility. When the 356 "Local AS" capability is used, a local ASN will be provided in the 357 configuration that is different from the globally-configured ASN of 358 the BGP router. To implement this mechanism, a BGP speaker SHOULD 359 send BGP OPEN [RFC4271] (see section 4.2) messages to the configured 360 eBGP peer(s) using the local ASN configured for this session as the 361 value sent in "My Autonomous System". The BGP router SHOULD NOT use 362 the ASN configured globally within the BGP process as the value sent 363 in "My Autonomous System" in the OPEN message. This will avoid 364 causing the eBGP neighbor to unnecessarily generate a BGP OPEN Error 365 message "Bad Peer AS". This method is typically used to re-establish 366 eBGP sessions with peers expecting the legacy ASN after a router has 367 been moved to a new ASN. 369 Implementations MAY support a more flexible model where the eBGP 370 speaker attempts to open the BGP session using either the ASN 371 configured as "Local AS" or the globally configured AS as discussed 372 in BGP Alias (Section 4.2). If the session is successfully 373 established to the globally configured ASN, then the modifications to 374 AS_PATH described in this document SHOULD NOT be performed, as they 375 are unnecessary. The benefit to this more flexible model is that it 376 allows the remote neighbor to reconfigure to the new ASN without 377 direct coordination between the ISP and the customer. 379 Note that this procedure will vary slightly if the locally or 380 globally configured ASN is a 4-octet ASN. See section 3 of 381 [RFC4893]. 383 When the BGP router receives UPDATEs from its eBGP neighbor 384 configured with the "Local AS" mechanism, it processes the UPDATE as 385 described in RFC4271 section 5.1.2 [RFC4271]. However the presence 386 of a second ASN due to "Local AS" adds the following behavior to 387 processing UPDATEs received from an eBGP neighbor configured with 388 this mechanism: 390 1. Internal: the router SHOULD append the configured "Local AS" ASN 391 in the AS_PATH attribute before installing the route or 392 advertising the UPDATE to an iBGP neighbor. The decision of when 393 to append the ASN is an implementation detail outside the scope 394 of this document. Some considerations factoring into this 395 decision include consistency in the AS_PATH throughout the AS, 396 and implementation of the loop detection mechanism. 398 2. External: the BGP router SHOULD first append the globally 399 configured ASN to the AS_PATH immediately followed by the "Local 400 AS" value before advertising the UPDATE to an eBGP neighbor. 402 Two options exist to manipulate the behavior of the basic "Local AS" 403 mechanism. They modify the behavior as described below: 405 1. "No Prepend Inbound" - When the BGP router receives inbound BGP 406 UPDATEs from its eBGP neighbor configured with this option, it 407 MUST NOT append the "Local AS" ASN value in the AS_PATH attribute 408 when installing the route or advertising that UPDATE to iBGP 409 neighbors, but it MUST still append the globally configured ASN 410 as normal when advertising the UPDATE to other local eBGP 411 neighbors (i.e. those natively peering with the globally 412 configured ASN). 414 2. "Replace Old AS", (outbound) - When the BGP router generates 415 outbound BGP UPDATEs toward an eBGP neighbor configured with this 416 option, the BGP speaker MUST NOT append the globally configured 417 ASN from the AS_PATH attribute. The BGP router MUST append only 418 the configured "Local AS" ASN value to the AS_PATH attribute 419 before sending the BGP UPDATEs outbound to the eBGP neighbor. 421 4. Internal BGP Autonomous System Migration Mechanisms 423 The following section describes mechanisms that assist with a gradual 424 and least service impacting migration of Internal BGP sessions from a 425 legacy ASN to the permanently retained ASN. The following mechanism 426 is very valuable to networks undergoing AS migration, but its use 427 does not cause changes to the AS_PATH attribute. 429 4.1. Internal BGP AS Migration 431 In this case, all of the routers to be consolidated into a single, 432 permanently retained ASN are under the administrative control of a 433 single entity. Unfortunately, the traditional method of migrating 434 all Internal BGP speakers, particularly within larger networks, is 435 both time consuming and widely service impacting. 437 The traditional method to migrate Internal BGP sessions was strictly 438 limited to reconfiguration of the global configuration ASN and, 439 concurrently, changing all iBGP neighbors' remote ASN from the legacy 440 ASN to the new, permanently retained ASN on each router within the 441 legacy AS. These changes can be challenging to swiftly execute in 442 networks with with more than a few dozen internal BGP routers. There 443 is also the concomitant service interruptions as these changes are 444 made to routers within the network, resulting in a reset of iBGP 445 sessions and subsequent route reconvergence to reestablish optimal 446 routing paths. Operators often cannot make such sweeping changes 447 given the associated risks of a highly visible service interruption; 448 rather, they require a more gradual method to migrate Internal BGP 449 sessions, from one ASN to a second, permanently retained ASN, that is 450 not visibly service-impacting to its customers. 452 With the "Internal BGP AS Migration" mechanism described herein, it 453 allows an Internal BGP speaker to form a single iBGP session using 454 either the old, legacy ASN or the new, permanently retained ASN. The 455 benefits of using this mechanism are several fold. First, it allows 456 for a more gradual and less service-impacting migration away from the 457 legacy ASN to the permanently retained ASN. Second, it (temporarily) 458 permits the coexistence of the legacy and permanently retained ASN 459 within a single network, allowing for uniform BGP path selection 460 among all routers within the consolidated network. 462 The iBGP router with the "Internal BGP AS Migration" capability 463 enabled allows the receipt of a BGP OPEN message with either the 464 legacy ASN value or the new, globally configured ASN value in the "My 465 Autonomous System" field of the BGP OPEN message from iBGP neighbors. 466 It is important to recognize that enablement of the "Internal BGP AS 467 Migration" mechanism preserves the semantics of a regular iBGP 468 session (i.e. using identical ASNs). Thus, the BGP attributes 469 transmitted by and the acceptable methods of operation on BGP 470 attributes received from iBGP sessions configured with "Internal BGP 471 AS Migration" capability are no different than those exchanged across 472 an iBGP session without "Internal BGP AS Migration" configured, as 473 defined by [RFC4271] and [RFC4456]. 475 Typically, in medium to large networks, BGP Route Reflectors 476 [RFC4456] (RRs) are used to aid in reduction of configuration of iBGP 477 sessions and scalability with respect to overall TCP (and, BGP) 478 session maintenance between adjacent iBGP routers. Furthermore, BGP 479 Route Reflectors are typically deployed in pairs within a single 480 Route Reflection cluster to ensure high reliability of the BGP 481 Control Plane. As such, the following example will use Route 482 Reflectors to aid in understanding the use of the "Internal BGP AS 483 Migration" mechanism. Note that Route Reflectors are not a 484 prerequisite to enable "Internal BGP AS Migration" and this mechanism 485 can be enabled independent of the use of Route Reflectors. 487 The general order of operations is as follows: 489 1. Within the legacy network, (the routers comprising the set of 490 devices that still have a globally configured legacy ASN), one 491 member of a redundant pair of RRs has its global configuration 492 ASN changed to the permanently retained ASN. Concurrently, the 493 "Internal BGP AS Migration" capability is enabled on all iBGP 494 sessions on that device. This will comprise Non-Client iBGP 495 sessions to other RRs as well as Client iBGP sessions, typically 496 to PE devices, both still utilizing the legacy ASN. Note that 497 during this step there will be a reset and reconvergence event on 498 all iBGP sessions on the RRs whose configuration was modified; 499 however, this should not be service impacting due to the use of 500 redundant RRs in each RR Cluster. 502 2. The above step is repeated for the other side of the redundant 503 pair of RRs. The one alteration to the above procedure is that 504 the "Internal BGP AS Migration" mechanism is now removed from the 505 Non-Client iBGP sessions toward the other (previously 506 reconfigured) RRs, since it is no longer needed. The "Internal 507 BGP AS Migration" mechanism is still required on all RRs for all 508 RR Client iBGP sessions. Also during this step, there will be a 509 reset and reconvergence event on all iBGP sessions whose 510 configuration was modified, but this should not be service 511 impacting. At the conclusion of this step, all RRs should now 512 have their globally configured ASN set to the permanently 513 retained ASN and "Internal BGP AS Migration" enabled and in use 514 toward RR Clients. 516 3. At this point, the network administrators would then be able to 517 establish iBGP sessions between all Route Reflectors in both the 518 legacy and permanently retained networks. This would allow the 519 network to appear to function, both internally and externally, as 520 a single, consolidated network using the permanently retained 521 network. 523 4. To complete the AS migration, each RR Client (PE) in the legacy 524 network still utilizing the legacy ASN is now modified. 526 Specifically, each legacy PE would have its globally configured 527 ASN changed to use the permanently retained ASN. The ASN 528 configured within the PE for the iBGP sessions toward each RR 529 would be changed to use the permanently retained ASN. It is 530 unnecessary to enable "Internal BGP AS Migration" mechanism on 531 these migrated iBGP sessions. During the same maintenance 532 window, External BGP sessions would be modified to include the 533 above "Local AS", "No Prepend" and "Replace Old AS" mechanisms 534 described in Section 3 above, since all of the changes are 535 service interrupting to the eBGP sessions of the PE. At this 536 point, all PEs will have been migrated to the permanently 537 retained ASN. 539 5. The final step is to excise the "Internal BGP AS Migration" 540 configuration from the Router Reflectors in an orderly fashion. 541 After this is complete, all routers in the network will be using 542 the new, permanently retained ASN for all iBGP sessions with no 543 vestiges of the legacy ASN on any iBGP sessions. 545 The benefit of using the aforementioned "Internal BGP AS Migration" 546 capability is that it is a more gradual and less externally service- 547 impacting change to accomplish an AS migration. Previously, without 548 "Internal BGP AS Migration", such an AS migration change would carry 549 a high risk and need to be successfully accomplished in a very short 550 timeframe (e.g.: at most several hours). In addition, it would 551 likely cause substantial routing churn and rapid fluctuations in 552 traffic carried -- potentially causing periods of congestion and 553 resultant packet loss -- during the period the configuration changes 554 are underway to complete the AS Migration. On the other hand, with 555 "Internal BGP AS Migration", the migration from the legacy ASN to the 556 permanently retained ASN can occur over a period of days or weeks 557 with reduced customer disruption. (The only observable service 558 disruption should be when each PE undergoes the changes discussed in 559 step 4 above.) 561 4.2. Implementation 563 The mechanism introduced in this section MUST be configurable on a 564 per-neighbor or per neighbor group basis to allow for maximum 565 flexibility. When configured with this mechanism, a BGP speaker MUST 566 accept BGP OPEN and establish an iBGP session from configured iBGP 567 peers if the ASN value in "My Autonomous System" is either the 568 globally configured ASN or a locally configured ASN provided when 569 this capability is utilized. Additionally, a BGP router configured 570 with this mechanism MUST send its own BGP OPEN [RFC4271] (see section 571 4.2) using either the globally configured or the locally configured 572 ASN in "My Autonomous System" as follows. To avoid potential 573 deadlocks when two BGP speakers are attempting to establish a BGP 574 peering session and are both configured with this mechanism, the 575 speaker SHOULD send BGP OPEN using the globally configured ASN first, 576 and only send a BGP OPEN using the locally configured ASN as a 577 fallback if the remote neighbor responds with the BGP error "Bad Peer 578 AS". In each case, the BGP speaker MUST treat UPDATEs sent and 579 received to this peer as if this was a natively configured iBGP 580 session, as defined by [RFC4271] and [RFC4456]. 582 Note that this procedure will vary slightly if the locally or 583 globally configured ASN is a 4-octet ASN. See section 3 of 584 [RFC4893]. 586 5. Additional Operational Considerations 588 This document describes several mechanisms to support ISPs and other 589 organizations that need to perform ASN migrations. Other variations 590 of these mechanisms may exist, for example, in legacy router software 591 that has not been upgraded or reached End of Life, but continues to 592 operate in the network. Such variations are beyond the scope of this 593 document. 595 Companies routinely go through periods of mergers, acquisitions and 596 divestitures, which in the case of the former cause them to 597 accumulate several legacy ASNs over time. ISPs often do not have 598 control over the configuration of customers' devices (i.e.: the ISPs 599 are often not providing a managed CE router service, particularly to 600 medium and large customers that require eBGP). Furthermore, ISPs are 601 using methods to perform ASN migration that do not require 602 coordination with customers. Ultimately, this means there is not a 603 finite period of time after which legacy ASNs will be completely 604 expunged from the ISP's network. In fact, it is common that legacy 605 ASNs and the associated External BGP AS Migration mechanisms 606 discussed in this document can and do persist for several years, if 607 not longer. Thus, it is prudent to plan that legacy ASNs and 608 associated External BGP AS Migration mechanisms will persist in a 609 operational network indefinitely. 611 With respect to the Internal BGP AS Migration mechanism, all of the 612 routers to be consolidated into a single, permanently retained ASN 613 are under the administrative control of a single entity. Thus, 614 completing the migration from iBGP sessions using the legacy ASN to 615 the permanently retained ASN is more straightforward and could be 616 accomplished in a matter of days to months. Finally, good 617 operational hygiene would dictate that it is good practice to avoid 618 using "Internal BGP AS Migration" capability over a long period of 619 time for reasons of not only operational simplicity of the network, 620 but also reduced reliance on that mechanism during the ongoing 621 lifecycle management of software, features and configurations that 622 are maintained on the network. 624 6. IANA Considerations 626 This memo includes no request to IANA. 628 7. Security Considerations 630 This draft discusses a process by which one ASN is migrated into and 631 subsumed by another. This involves manipulating the AS_PATH 632 Attribute with the intent of not increasing the AS_PATH length, which 633 would typically cause the BGP route to no longer be selected by BGP's 634 Path Selection Algorithm in others' networks. This could result in 635 sudden and unexpected shifts in traffic patterns in the network, 636 potentially resulting in congestion. 638 Given that these mechanisms can only be enabled through configuration 639 of routers within a single network, standard security measures should 640 be taken to restrict access to the management interface(s) of routers 641 that implement these mechanisms. Additionally, BGP sessions SHOULD 642 be protected using TCP Authentication Option [RFC5925] and the 643 Generalized TTL Security Mechanism [RFC5082] 645 8. Acknowledgements 647 Thanks to Kotikalapudi Sriram, Stephane Litkowski, Terry Manderson, 648 David Farmer, Jaroslaw Adam Gralak, Gunter Van de Velde, Juan 649 Alcaide, Jon Mitchell, Thomas Morin, Alia Atlas, Alvaro Retana, and 650 John Scudder for their comments. 652 9. References 654 9.1. Normative References 656 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 657 Requirement Levels", BCP 14, RFC 2119, March 1997. 659 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 660 Protocol 4 (BGP-4)", RFC 4271, January 2006. 662 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 663 Reflection: An Alternative to Full Mesh Internal BGP 664 (IBGP)", RFC 4456, April 2006. 666 9.2. Informative References 668 [ALU] Alcatel-Lucent, "BGP Local AS attribute", 2006-2012, 669 . 673 [CISCO] Cisco Systems, Inc., "BGP Support for Dual AS 674 Configuration for Network AS Migrations", 2003, 675 . 679 [JUNIPER] Juniper Networks, Inc., "Configuring the BGP Local 680 Autonomous System Attribute", 2012, 681 . 684 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 685 Number Space", RFC 4893, May 2007. 687 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 688 System Confederations for BGP", RFC 5065, August 2007. 690 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 691 Pignataro, "The Generalized TTL Security Mechanism 692 (GTSM)", RFC 5082, October 2007. 694 [RFC5398] Huston, G., "Autonomous System (AS) Number Reservation for 695 Documentation Use", RFC 5398, December 2008. 697 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 698 Authentication Option", RFC 5925, June 2010. 700 [RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for 701 Private Use", BCP 6, RFC 6996, July 2013. 703 Appendix A. Implementation report 705 As noted elsewhere in this document, this set of migration mechanisms 706 has multiple existing implementations in wide use. 708 o Cisco [CISCO] 710 o Juniper [JUNIPER] 712 o Alcatel-Lucent [ALU] 713 This is not intended to be an exhaustive list, as equivalent features 714 do exist in other implementations, however the authors were unable to 715 find publicly available documentation of the vendor-specific 716 implementation to reference. 718 Authors' Addresses 720 Wesley George 721 Time Warner Cable 722 13820 Sunrise Valley Drive 723 Herndon, VA 20171 724 US 726 Phone: +1 703-561-2540 727 Email: wesley.george@twcable.com 729 Shane Amante 730 Apple, Inc. 731 1 Infinite Loop 732 Cupertino, CA 95014 733 US 735 Email: samante@apple.com