idnits 2.17.1 draft-ga-idr-as-migration-03.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 (January 6, 2014) is 3763 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: July 10, 2014 Apple, Inc. 6 January 6, 2014 8 Autonomous System (AS) Migration Features and Their Effects on the BGP 9 AS_PATH Attribute 10 draft-ga-idr-as-migration-03 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 July 10, 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. Documentation note . . . . . . . . . . . . . . . . . . . 3 57 2. ASN Migration Scenario Overview . . . . . . . . . . . . . . . 3 58 3. External BGP Autonomous System Migration Features . . . . . . 5 59 3.1. Local AS: Modify Inbound BGP AS_PATH Attribute . . . . . 6 60 3.2. Replace AS: Modify Outbound BGP AS_PATH Attribute . . . . 7 61 4. Internal BGP Autonomous System Migration Features . . . . . . 8 62 4.1. Internal BGP Alias . . . . . . . . . . . . . . . . . . . 9 63 5. Additional Operational Considerations . . . . . . . . . . . . 11 64 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 70 10.2. Informative References . . . . . . . . . . . . . . . . . 13 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 73 1. Introduction 75 This draft discusses common methods of managing an ASN migration 76 using some BGP features that while commonly-used are not formally 77 part of the BGP4 [RFC4271] protocol specification and may be vendor- 78 specific in exact implementation. This draft does not attempt to 79 standardize these features, because they are local to a given 80 implementation and do not require negotiation with or cooperation of 81 BGP neighbors. The deployment of these features do not need to 82 interwork with one another to accomplish the desired results. 83 However, it is necessary to document these de facto standards to 84 ensure that any future protocol enhancements to BGP that propose to 85 read, copy, manipulate or compare the AS_PATH attribute can do so 86 without inhibiting the use of these very widely used ASN migration 87 features. 89 It is important to understand the business need for these features 90 and illustrate why they are critical, particularly for ISPs' 91 operations. However, these features are not limited to ISPs and 92 organizations of all sizes use these features for similar reasons to 93 ISPs. During a merger, acquisition or divestiture involving two 94 organizations it is necessary to seamlessly migrate BGP speakers from 95 one ASN to a second ASN. The overall goal in doing so, particularly 96 in the case of a merger or acquisition, is to achieve a uniform 97 operational model through consistent configurations across all BGP 98 speakers in the combined network. In addition, and perhaps more 99 imporantly, it is common practice in the industry for ISPs to bill 100 customers based on utilization. ISPs bill customers based on the 101 95th percentile of the greater of the traffic sent or received, over 102 the course of a 1-month period, on the customer's PE-CE access 103 circuit. Given that the BGP Path Selection algorithm selects routes 104 with the shortest AS_PATH attribute, it is critical for the ISP to 105 not increase AS_PATH length during or after ASN migration, toward 106 both downstream transit customers as well as settlement-free peers, 107 who are likely sending or receiving traffic from those transit 108 customers. This would not only result in sudden changes in traffic 109 patterns in the network, but also (substantially) decrease 110 utilization driven revenue at the ISP. 112 Lastly, it is important to note that by default, the BGP protocol 113 requires an operator to configure a single remote ASN for the eBGP 114 neighbor inside a router, in order to successfully negotiate and 115 establish an eBGP session. Prior to the existence of these features, 116 it would have required an ISP to work with, in some cases, tens of 117 thousands of customers. In particular, the ISP would have to 118 encourage those customers to change their CE router configs to use 119 the new ASN, in a very short period of time, when the customer has no 120 business incentive to do so. Thus, it because critical to allow the 121 ISP to make this process a bit more asymmetric, so that it could 122 seamlessly migrate the ASN within its network(s), but not disturb 123 existing customers, and allow the customers to gradually migrate to 124 the ISP's new ASN at their leisure. 126 1.1. Documentation note 128 This draft uses Autonomous System Numbers (ASNs) from the range 129 reserved for documentation as described in RFC 5398 [RFC5398]. In 130 the examples used here, they are intended to represent Globally 131 Unique ASNs, not private ASNs as documented in RFC 1930 [RFC1930] 132 section 10. 134 2. ASN Migration Scenario Overview 136 The use case being discussed here is an ISP merging two or more ASNs, 137 where eventually one ASN subsumes the other(s). In this use case, we 138 will assume the most common case where there are two ISPs, A and B, 139 that use AS 64500 and 64510, respectively, before the ASN migration 140 is to occur. AS 64500 will be the permanently retained ASN used 141 going forward across the consolidated set of both ISPs network 142 equipment and AS 64510 will be retired. Thus, at the conclusion of 143 the ASN migration, there will be a single ISP A' with all internal 144 BGP speakers configured to use AS 64500. To all external BGP 145 speakers, the AS_PATH length will not be increased. 147 In this same scenario, AS 64496 and AS 64499 represent two, separate 148 customer networks: C and D, respectively. Originally, customer C (AS 149 64496) is attached to ISP B, which will undergo ASN migration from AS 150 64510 to AS 64500. Furthermore, customer D (AS 64496) is attached to 151 ISP A, which does not undergo ASN migration since ISP A's ASN will 152 remain constant, (AS 64500). Although this example refers to AS 153 64496 and 64499 as customer networks, either or both may be 154 settlement-free or other types of peers. In this use case they are 155 referred to as "customers" merely for convenience. 157 ------ ------ 158 / ISP A \ / ISP B \ 159 | AS 64500 | | AS 64510 | 160 \ / \ / 161 ------- ------- 162 | | 163 | | 164 ------------ ------------- 165 | Cust D | | Cust C | 166 | AS 64499 | | AS 64496 | 167 ------------ ------------- 169 Figure 1: Before Migration 171 --------------- 172 / \ 173 | ISP A' | 174 | AS 64500 | 175 \ / 176 --------------- 177 / \ 178 / \ 179 | | 180 ------------ ------------- 181 | Cust D | | Cust C | 182 | AS 64499 | | AS 64496 | 183 ------------ ------------- 185 Figure 2: After Migration 187 The general order of operations, typically carried out in a single 188 maintenance window by the network undergoing ASN migration, ISP B, 189 are as follows. First, ISP B, will change the global BGP ASN used by 190 a PE router, from ASN 64510 to 64500. At this point, the router will 191 no longer be able to establish eBGP sessions toward the existing CE 192 devices that are attached to it and still using AS 64510. Second, 193 ISP B will configure two separate, but related ASN migration features 194 discussed in this document on all eBGP sessions toward all CE 195 devices. These features modify the AS_PATH attribute received from 196 and transmitted toward CE devices to acheive the desired effect of 197 not increasing the length of the AS_PATH. 199 At the conclusion of the ASN migration, the CE devices at the edge of 200 the network are not aware of and do not observe any change in the 201 length of the AS_PATH attribute. However, after the changes 202 discussed in this document are put in place by ISP A', there is a 203 change to the contents of the AS_PATH attribute to ensure the AS_PATH 204 is not artifically lengthened for the duration of time that these AS 205 migration parameters are used. 207 In this use case, neither ISP is using BGP Confederations RFC 5065 208 [RFC5065] internally. 210 Additional information about this scenario, including vendor-specific 211 implementation details can be found as follows: 213 o Cisco [CISCO] 215 o Juniper [JUNIPER] 217 o Alcatel-Lucent [ALU] 219 Equivalent features do exist in other implementations, however the 220 authors were unable to find publicly available documentation of the 221 vendor-specific implementation to reference. Finally, the examples 222 cited below use Cisco IOS CLI for ease of illustration purposes only. 224 3. External BGP Autonomous System Migration Features 226 The following section addresses features that are specific to 227 modifying the AS_PATH attribute at the Autonomous System Border 228 Routers (ASBRs) of an organization, (typically a single Service 229 Provider). This ensures that external BGP customers/peers are not 230 forced to make any configuration changes on their CE routers before 231 or during the exact time the Service Provider wishes to migrate to a 232 new, permanently retained ASN. Furthermore, these features eliminate 233 the artificial lengthening of the AS_PATH both transmitted from and 234 received by the Service Provider that is undergoing AS Migration, 235 which would have negative implications on path selection by external 236 networks. 238 3.1. Local AS: Modify Inbound BGP AS_PATH Attribute 240 ISP B needs to reconfigure its router(s) to participate as an 241 internal BGP speaker in AS 64500, to realize the business goal of 242 becoming a single Service Provider: ISP A'. ISP B needs to do this 243 without coordinating the change of its ASN with all of its eBGP 244 peers, simultaneously. The first step is for ISP B to change the 245 global AS in its router configuration, used by the local BGP process 246 as the system-wide Autonomous System ID, from AS 64510 to AS 64500. 247 The next step is for ISP B to establish iBGP sessions with ISP A's 248 existing routers, thus consolidating ISP B into ISP A resulting in 249 operating under a single AS: ISP A', (AS 64500). 251 The next step is for ISP B to reconfigure its PE router(s) so that 252 each of its eBGP sessions toward all eBGP speakers with a feature 253 called "Local AS". This feature allows ISP B's PE router to re- 254 establish a eBGP session toward the existing CE devices using the 255 legacy AS, AS 64510, in the eBGP session establishment. Ultimately, 256 the CE devices, (i.e.: customer C), are completely unaware that ISP B 257 has reconfigured its router to participate as a member of a new AS. 258 Within the context of ISP B's PE router, the second effect this 259 feature has is that, by default, it prepends all received BGP 260 UPDATE's with the legacy AS of ISP B: AS 64510. Thus, within ISP A' 261 the AS_PATH toward customer C would appear as: 64510 64496, which is 262 an increase in AS_PATH length from previously. Therefore, a 263 secondary feature "No Prepend" is required to be added to the "Local 264 AS" configuration toward every eBGP neighbor on ISP B's PE router. 265 The "No Prepend" feature causes ISP B's PE router to not prepend the 266 legacy AS, AS 64510, on all received eBGP UPDATE's from customer C. 267 This restores the AS_PATH within ISP A' toward customer C so that it 268 is just one ASN in length: 64496. 270 In the direction of CE -> PE (inbound): 272 1. 'local-as ': appends the value to the AS_PATH 273 of routes received from the CE 275 2. 'local-as no-prepend': does not prepend value 276 to the AS_PATH of routes received from the CE 278 As stated previously, local-as no-prepend, (configuration 279 #2), is critical because it does not increase the AS_PATH length. 280 Ultimately, this ensures that routes learned from ISP B's legacy 281 customers will be transmitted through legacy eBGP sessions of ISP A, 282 toward both customers and peers, will contain only two AS'es in the 283 AS_PATH: 64500 64496. Thus, the legacy customers and peers of ISP A 284 will not see an increase in the AS_PATH length to reach ISP B's 285 legacy customers. Ultimately, it is considered mandatory by 286 operators that both the "Local AS" and "No Prepend" configuration 287 parameters always be used in conjunction with each other in order to 288 ensure the AS_PATH length is not increased. 290 PE-1 is a PE that was originally in ISP B. PE-1 has had its global 291 configuration ASN changed from AS 64510 to AS 64500 to make it part 292 of the permanently retained ASN. This now makes PE-1 a member of ISP 293 A'. PE-2 is a PE that was originally in ISP A. Although its global 294 configuration ASN remains AS 64500, throughout this exercise we also 295 consider PE-2 a member of ISP A'. 297 ISP A' ISP A' 298 CE-1 ---> PE-1 -------------------> PE-2 ---> CE-2 299 64496 Old_ASN: 64510 New_ASN: 64500 64499 300 New_ASN: 64500 302 Note: Direction of BGP UPDATE as per the arrows. 304 Figure 3: Local AS BGP UPDATE Diagram 306 The final configuration on PE-1 after completing the "Local AS" 307 portion of the AS migration is as follows: 309 router bgp 64500 310 neighbor remote-as 64496 311 neighbor local-as 64510 no-prepend 313 As a result of the "Local AS No Prepend" configuration, on PE-1, CE-2 314 will see an AS_PATH of: 64500 64496. CE-2 will not receive a BGP 315 UPDATE containing AS 64510 in the AS_PATH. (If only the "local-as 316 64510" feature was configured without the keyword "no-prepend" on 317 PE-1, then CE-2 would see an AS_PATH of: 64496 64510 64500, which is 318 unacceptable). 320 3.2. Replace AS: Modify Outbound BGP AS_PATH Attribute 322 The previous feature, "Local AS No Prepend", was only designed to 323 modify the AS_PATH Attribute received from CE devices by the ISP, 324 when CE devices still have an eBGP session established with the ISPs 325 legacy AS, (AS64510). Use of "Local AS No Prepend" has an 326 unfortunate side effect where its use does not concurrently modify 327 the AS_PATH Attribute for BGP UPDATEs that are transmitted by the ISP 328 to CE devices. Specifically, with "Local AS No Prepend" enabled on 329 ISP A's PE-1, it automatically causes a lengthening of the AS_PATH in 330 outbound BGP UPDATEs from ISP A' toward directly attached eBGP 331 speakers, (Customer C in AS 64496). This is the result of the "Local 332 AS No Prepend" feature automatically appending the new global 333 configuration ASN, AS64500, after the legacy ASN, AS64510, on ISP A' 334 PE-1 in BGP UPDATEs that are transmitted by PE-1 to CE-1. The end 335 result is that customer C, in AS 64496, will receive the following 336 AS_PATH: 64510 64500 64499. Therefore, if ISP A' takes no further 337 action, it will cause an increase in AS_PATH length within customer's 338 networks directly attached to ISP A', which is unacceptable. 340 A second feature, called "Replace AS", was designed to resolve this 341 problem. This feature allows ISP A' to not append the global 342 configured AS in outbound BGP UPDATEs toward its customer's networks 343 configured with the "Local AS" feature. Instead, only the historical 344 (or, legacy) AS will be prepended in the outbound BGP UPDATE toward 345 customer's network, restoring the AS_PATH length to what it what was 346 before AS Migration occurred. 348 To re-use the above diagram, but in the opposite direction, we have: 350 ISP A' ISP A' 351 CE-1 <--- PE-1 <------------------- PE-2 <--- CE-2 352 64496 Old_ASN: 64510 New_ASN: 64500 64499 353 New_ASN: 64500 355 Note: Direction of BGP UPDATE as per the arrows. 357 Figure 4: Replace AS BGP UPDATE Diagram 359 The final configuration on PE-1 after completing the "Replace AS" 360 portion of the AS migration is as follows: 362 router bgp 64500 363 neighbor remote-as 64496 364 neighbor local-as 64510 no-prepend replace-as 366 By default, without "Replace AS" enabled, CE-1 would see an AS_PATH 367 of: 64510 64500 64499, which is artificially lengthened by the ASN 368 Migration. After ISP A' changes PE-1 to include the "Replace AS" 369 feature, CE-1 would receive an AS_PATH of: 64510 64499, which is the 370 same AS_PATH length pre-AS migration. 372 4. Internal BGP Autonomous System Migration Features 374 The following section describes features that are specific to 375 performing an ASN migration within medium to large networks in order 376 to realize the business and operational benefits of a single network 377 using one, globally unique Autonomous System. These features assist 378 with a gradual and least service impacting migration of Internal BGP 379 sessions from a legacy ASN to the permanently retained ASN. It 380 should be noted that the following feature is very valuable to 381 networks undergoing AS migration, but its use does not cause changes 382 to the AS_PATH attribute. 384 4.1. Internal BGP Alias 386 In this case, all of the routers to be consolidated into a single, 387 permanently retained ASN are under the administrative control of a 388 single entity. Unfortunately, though, the traditional method of 389 migrating all Internal BGP speakers, particularly within larger 390 networks, is both time consuming and widely service impacting. 392 The traditional method to migrate Internal BGP sessions was strictly 393 limited to reconfiguration of the global configuration ASN and, 394 concurrently, changing of iBGP neighbor's remote ASN from the legacy 395 ASN to the new, permanently retained ASN on each router within the 396 legacy AS. These changes can be challenging to swiftly execute in 397 networks with with more than a few dozen internal BGP speakers. 398 There is also the concomitant service interruptions as these changes 399 are made to routers within the network, resulting in a reset of iBGP 400 sessions and subsequent reconvergence times to reestablish optimal 401 routing paths. Operators do not and, in some cases, cannot make such 402 changes given the associated risks and highly visible service 403 interruption; rather, they require a more gradual method to migrate 404 Internal BGP sessions, from one ASN to a second, permanently retained 405 ASN, that is not visibly service-impacting to its customers. 407 With the "Internal BGP Alias" [JUNIPER] feature, it allows an 408 Internal BGP speaker to form a single iBGP session using either the 409 old, legacy ASN or the new, permanently retained ASN. The benefits 410 of using this feature are several fold. First, it allows for a more 411 gradual and less service-impacting migration away from the legacy ASN 412 to the permanently retained ASN. Second, it (temporarily) permits 413 the coexistence of the legacy and permanently retained ASN within a 414 single network, allowing for uniform BGP path selection among all 415 routers within the consolidated network. 417 When the "Internal BGP Alias" feature is enabled, typically just on 418 one side of a iBGP session, it allows that iBGP speaker to establish 419 a single iBGP session with either the legacy ASN or the new, 420 permanently retained ASN, depending on which one it receives in the 421 "My Autonomous System" field of the BGP OPEN message from its iBGP 422 session neighbor. It is important to recognize that enablement of 423 the "Internal BGP Alias" feature preserves the semantics of a regular 424 iBGP session, (using identical ASNs). Thus, the BGP attributes 425 transmitted by and the acceptable methods of operation on BGP 426 attributes received from iBGP sessions configured with "Internal BGP 427 Alias" are no different than those exchanged across an iBGP session 428 without "Internal BGP Alias" configured, as defined by [RFC4271] and 429 [RFC4456]. 431 Typically, in medium to large networks, BGP Route Reflectors 432 [RFC4456] (RRs) are used to aid in reduction of configuration of iBGP 433 sessions and scalability with respect to overall TCP (and, BGP) 434 session maintenance between adjacent iBGP speakers. Furthermore, BGP 435 Route Reflectors are typically deployed in pairs within a single 436 Route Reflection cluster to ensure high reliability of the BGP 437 Control Plane. As such, the following example will use Route 438 Reflectors to aid in understanding the use of the "Internal BGP 439 Alias" feature. It should be noted that Route Reflectors are not a 440 prerequisite to enable "Internal BGP Alias" and this feature can be 441 enabled independent of the use of Route Reflectors. 443 The general order of operations is as follows: 445 1. Within the legacy network, (the routers comprising the set of 446 devices that still have a globally configured legacy ASN), take 447 one member of a redundant pair of RRs and change its global 448 configuration ASN to the permanently retained ASN. Concurrently, 449 enable use of "Internal BGP Alias" on all iBGP sessions. This 450 will comprise Non-Client iBGP sessions to other RRs as well as 451 Client iBGP sessions, typically to PE devices, both still 452 utilizing the legacy ASN. Note that during this step there will 453 be a reset and reconvergence event on all iBGP sessions on the 454 RRs whose configuration was modified; however, this should not be 455 service impacting due to the use of redundant RRs in each RR 456 Cluster. 458 2. Repeat the above step for the other side of the redundant pair of 459 RRs. The one alteration to the above procedure is to disable use 460 of "Internal BGP Alias" on the Non-Client iBGP sessions toward 461 the other (previously reconfigured) RRs, since it is no longer 462 needed. "Internal BGP Alias" is still required on all RRs for 463 all RR Client iBGP sessions. Also during this step, there will 464 be a reset and reconvergence event on all iBGP sessions whose 465 configuration was modified, but this should not be service 466 impacting. At the conclusion of this step, all RRs should now 467 have their globally configured ASN set to the permanently 468 retained ASN and "Internal BGP Alias" enabled and in use toward 469 RR Clients. 471 3. At this point, the network administrators would then be able to 472 establish iBGP sessions between all Route Reflectors in both the 473 legacy and permanently retained networks. This would allow the 474 network to appear to function, both internally and externally, as 475 a single, consolidated network using the permanently retained 476 network. 478 4. The next steps to complete the AS migration are to gradually 479 modify each RR Client, (PE), in the legacy network still 480 utilizing the legacy ASN. Specifically, each legacy PE would 481 have its globally configured ASN changed to use the permanently 482 retained ASN. The ASN used by the PE for the iBGP sessions, 483 toward each RR, would be changed to use the permanently retained 484 ASN. (It is unnecessary to enable "Internal BGP Alias" on the 485 migrated iBGP sessions). During the same maintenance window, 486 External BGP sessions would be modified to include the above 487 "Local AS No Prepend" and "Replace-AS" features, since all of the 488 changes are service interrupting to the eBGP sessions of the PE. 489 At this point, all PE's will have been migrated to the 490 permanently retained ASN. 492 5. The final step is to excise the "Internal BGP Alias" 493 configuration from the first half of the legacy RR Client pair -- 494 this will expunge "Internal BGP Alias" configuration from all 495 devices in the network. After this is complete, all routers in 496 the network will be using the new, permanently retained ASN for 497 all iBGP sessions with no vestiges of the legacy ASN on any iBGP 498 sessions. 500 The benefit of using "Internal BGP Alias" is a more gradual and less 501 externally visible, service-impacting change to accomplish an AS 502 migration. Previously, without "Internal BGP Alias", such an AS 503 migration change would carry a high risk and need to be successfully 504 accomplished in a very short timeframe, (e.g.: at most several 505 hours). In addition, it would cause substantial routing churn and, 506 likely, rapid fluctuations in traffic carried -- potentially causing 507 periods of congestion and resultant packet loss -- during the period 508 the configuration changes are underway to complete the AS Migration. 509 On the other hand, with "Internal BGP Alias", the migration from the 510 legacy ASN to the permanently retained ASN can occur over a period of 511 days or weeks with little disruption experienced by customers of the 512 network undergoing AS migration. (The only observable service 513 disruption should be when each PE undergoes the changes discussed in 514 step 4 above.) 516 5. Additional Operational Considerations 518 This document describes several implementation-specific features to 519 support ISPs and other organizations that need to perform ASN 520 migrations. Other variations of these features may exist, for 521 example, in legacy router software that has not been upgraded or 522 reached End of Life, but continues to operate in the network. Such 523 variations are beyond the scope of this document. 525 Companies routinely go through periods of mergers, acquisitions and 526 divestitures, which in the case of the former cause them to 527 accumulate several legacy ASNs over time. ISPs often do not have 528 control over the configuration of customer's devices, (i.e.: the ISPs 529 are often not providing a managed CE router service, particularly to 530 medium and large customers that require eBGP). Furthermore, ISPs are 531 using methods to perform ASN migration that do not require 532 coordination with customers. Ultimately, this means there is not a 533 finite period of time after which legacy ASNs will be completely 534 expunged from the ISP's network. In fact, it is common that legacy 535 ASNs and the associated External BGP AS Migration features discussed 536 in this document can and do persist for several years, if not longer. 537 Thus, it is prudent to plan that legacy ASNs and associated External 538 BGP AS Migration features will persist in a operational network 539 indefinitely. 541 With respect to the Internal BGP AS Migration Features, all of the 542 routers to be consolidated into a single, permanently retained ASN 543 are under the administrative control of a single entity. Thus, 544 completing the migration from iBGP sessions using the legacy ASN to 545 the permanently retained ASN is more straightforward and could be 546 accomplished in a matter of days to months. Finally, good 547 operational hygiene would dictate that it is good practice to avoid 548 using "Internal BGP Alias" over a long period of time for reasons of 549 not only operational simplicity of the network, but also reduced 550 reliance on that feature during the ongoing lifecycle management of 551 software, features and configurations that are maintained on the 552 network. 554 6. Conclusion 556 Although the features discussed in this document are not formally 557 recognized as part of the BGP4 specification, they have been in 558 existence in commercial implementations for well over a decade. 559 These features are widely known by the operational community and will 560 continue to be a critical necessity in the support of network 561 integration activities going forward. Therefore, these features are 562 extremely unlikely to be deprecated by vendors. As a result, these 563 features must be acknowledged by protocol designers, particularly 564 when there are proposals to modify BGP's behavior with respect to 565 handling or manipulation of the AS_PATH Attribute. More 566 specifically, assumptions should not be made with respect to the 567 preservation or consistency of the AS_PATH Attribute as it is 568 transmitted along a sequence of ASN's. In addition, proposals to 569 manipulate the AS_PATH that would gratuitously increase AS_PATH 570 length or remove the capability to use these features described in 571 this document will not be accepted by the operational community. 573 7. Acknowledgements 575 Thanks to Kotikalapudi Sriram, Stephane Litkowski, and Terry 576 Manderson for their comments. 578 8. IANA Considerations 580 This memo includes no request to IANA. 582 9. Security Considerations 584 This draft discusses a process by which one ASN is migrated into and 585 subsumed by another. This involves manipulating the AS_PATH 586 Attribute with the intent of not increasing the AS_PATH length, which 587 would typically cause the BGP route to no longer be selected by BGP's 588 Path Selection Algorithm in other's networks. This could result in a 589 loss of revenue if the ISP is billing based on measured utilization 590 of traffic sent to/from entities attached to its network. This could 591 also result in sudden, and unexpected shifts in traffic patterns in 592 the network, potentially resulting in congestion, in the most extreme 593 cases. 595 Given that these features can only be enabled through configuration 596 of router's within a single network, standard security measures 597 should be taken to restrict access to the management interface(s) of 598 routers that implement these features. 600 10. References 602 10.1. Normative References 604 [RFC5398] Huston, G., "Autonomous System (AS) Number Reservation for 605 Documentation Use", RFC 5398, December 2008. 607 10.2. Informative References 609 [ALU] Alcatel-Lucent, "BGP Local AS attribute", 2006-2012, 610 . 614 [CISCO] Cisco Systems, Inc., "BGP Support for Dual AS 615 Configuration for Network AS Migrations", 2003, 616 . 619 [JUNIPER] Juniper Networks, Inc., "Configuring the BGP Local 620 Autonomous System Attribute", 2012, . 624 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 625 selection, and registration of an Autonomous System (AS)", 626 BCP 6, RFC 1930, March 1996. 628 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 629 Protocol 4 (BGP-4)", RFC 4271, January 2006. 631 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 632 Reflection: An Alternative to Full Mesh Internal BGP 633 (IBGP)", RFC 4456, April 2006. 635 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 636 System Confederations for BGP", RFC 5065, August 2007. 638 Authors' Addresses 640 Wesley George 641 Time Warner Cable 642 13820 Sunrise Valley Drive 643 Herndon, VA 20171 644 US 646 Phone: +1 703-561-2540 647 Email: wesley.george@twcable.com 649 Shane Amante 650 Apple, Inc. 651 1 Infinite Loop 652 Cupertino, CA 95014 653 US 655 Email: samante@apple.com