idnits 2.17.1 draft-ietf-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 (September 29, 2014) is 3490 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) ** Downref: Normative reference to an Informational RFC: RFC 5398 Summary: 1 error (**), 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: April 2, 2015 Apple, Inc. 6 September 29, 2014 8 Autonomous System Migration Features and Their Effects on the BGP 9 AS_PATH Attribute 10 draft-ietf-idr-as-migration-03 12 Abstract 14 This draft discusses some BGP features for ASN migration that, while 15 commonly used, 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 such as BGPSec. 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 April 2, 2015. 37 Copyright Notice 39 Copyright (c) 2014 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 . . . . . . . . . . . . . . . 4 58 3. External BGP Autonomous System Migration Features . . . . . . 6 59 3.1. Modify Inbound BGP AS_PATH Attribute . . . . . . . . . . 6 60 3.2. Modify Outbound BGP AS_PATH Attribute . . . . . . . . . . 7 61 3.3. Implementation . . . . . . . . . . . . . . . . . . . . . 8 62 4. Internal BGP Autonomous System Migration Features . . . . . . 9 63 4.1. Internal BGP Alias . . . . . . . . . . . . . . . . . . . 10 64 4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 12 65 5. Additional Operational Considerations . . . . . . . . . . . . 13 66 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 69 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 70 10. Appendix: Implementation report . . . . . . . . . . . . . . . 15 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 73 11.2. Informative References . . . . . . . . . . . . . . . . . 15 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 76 1. Introduction 78 This draft discusses some BGP features for ASN migration that, while 79 commonly used, are not formally part of the BGP4 [RFC4271] protocol 80 specification and may be vendor-specific in exact implementation. 81 These features are local to a given BGP Speaker and do not require 82 negotiation with or cooperation of BGP neighbors. The deployment of 83 these features do not need to interwork with one another to 84 accomplish the desired results, so slight variations between existing 85 vendor implementations exist, and will not necessarily be harmonized 86 due to this document. However, it is necessary to document these de 87 facto standards to ensure that new implementations can be successful, 88 and any future protocol enhancements to BGP that propose to read, 89 copy, manipulate or compare the AS_PATH attribute can do so without 90 inhibiting the use of these very widely used ASN migration features. 92 The migration features discussed here are useful to ISPs and 93 organizations of all sizes, but it is important to understand the 94 business need for these features 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, it is common practice in the industry 101 for ISPs to bill customers based on utilization. ISPs bill customers 102 based on the 95th percentile of the greater of the traffic sent or 103 received, over the course of a 1-month period, on the customer's 104 access circuit. Given that the BGP Path Selection algorithm selects 105 routes with the shortest AS_PATH attribute, it is critical that the 106 ISP does not increase AS_PATH length during or after ASN migration 107 toward downstream transit customers or settlement-free peers, who are 108 likely sending or receiving traffic from those transit customers. 109 This would not only result in sudden changes in traffic patterns in 110 the network, but also substantially decrease utilization driven 111 revenue at the ISP. 113 By default, the BGP protocol requires an operator to configure a 114 router to use a single remote ASN for the BGP neighbor, and the ASN 115 must match on both ends of the peering in order to successfully 116 negotiate and establish a BGP session. Prior to the existence of 117 these migration features, it would have required an ISP to coordinate 118 an ASN change with, in some cases, tens of thousands of customers. 119 In particular, as each router is migrated to the new ASN, to avoid an 120 outage due to ASN mismatch, the ISP would have to force all customers 121 on that router to change their router configurations to use the new 122 ASN immediately after the ASN change. Thus, it becomes critical to 123 allow the ISP to make this process a bit more asymmetric, so that it 124 could seamlessly migrate the ASN within its network(s), but allow the 125 customers to gradually migrate to the ISP's new ASN at their leisure, 126 either by coordinating individual reconfigurations, or accepting 127 sessions using either the old or new ASN to allow for truly 128 asymmetric migration. 130 1.1. Requirements Language 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC 2119 [RFC2119]. 136 1.2. Documentation note 138 This draft uses Autonomous System Numbers (ASNs) from the range 139 reserved for documentation as described in RFC 5398 [RFC5398]. In 140 the examples used here, they are intended to represent Globally 141 Unique ASNs, not private use ASNs as documented in RFC 6996 [RFC6996] 142 section 5. 144 2. ASN Migration Scenario Overview 146 The use case being discussed here is an ISP merging two or more ASNs, 147 where eventually one ASN subsumes the other(s). In this use case, we 148 will assume the most common case where there are two ISPs, A and B, 149 that prior to the ASN migration use AS 64500 and 64510, respectively. 150 AS 64500 will be the permanently retained ASN used across the 151 consolidated set of both ISPs network equipment, and AS 64510 will be 152 retired. Thus, at the conclusion of the ASN migration, there will be 153 a single ISP A' with all internal BGP speakers configured to use AS 154 64500. To all external BGP speakers, the AS_PATH length will not be 155 increased. 157 In this same scenario, AS 64496 and AS 64499 represent two separate 158 customer networks: C and D, respectively. Originally, customer C (AS 159 64496) is attached to ISP B, which will undergo ASN migration from AS 160 64510 to AS 64500. Furthermore, customer D (AS 64499) is attached to 161 ISP A, which does not undergo ASN migration since the ASN for ISP A 162 will remain constant, (AS 64500). Although this example refers to AS 163 64496 and 64499 as customer networks, either or both may be 164 settlement-free or other types of peers. In this use case they are 165 referred to as "customers" merely for convenience. 167 ------ ------ 168 / ISP A \ / ISP B \ 169 | AS 64500 | | AS 64510 | 170 \ / \ / 171 ------- ------- 172 | | 173 | | 174 ------------ ------------- 175 | Cust D | | Cust C | 176 | AS 64499 | | AS 64496 | 177 ------------ ------------- 179 Figure 1: Before Migration 181 --------------- 182 / \ 183 | ISP A' | 184 | AS 64500 | 185 \ / 186 --------------- 187 / \ 188 / \ 189 | | 190 ------------ ------------- 191 | Cust D | | Cust C | 192 | AS 64499 | | AS 64496 | 193 ------------ ------------- 195 Figure 2: After Migration 197 The general order of operations, typically carried out in a single 198 maintenance window by the network undergoing ASN migration (ISP B), 199 are as follows. First, ISP B will change the global BGP ASN used by 200 a Provider Edge (PE) router, from ASN 64510 to 64500. At this point, 201 the router will no longer be able to establish eBGP sessions toward 202 the existing Customer Edge (CE) devices that are attached to it and 203 still using AS 64510. Second, since ISP B needs to do this without 204 coordinating the simultaneous change of its ASN with all of its eBGP 205 peers, ISP B will configure two separate, but related ASN migration 206 features discussed in this document on all eBGP sessions toward all 207 CE devices. These features enable the router to establish BGP 208 neighbors using the legacy ASN, modify the AS_PATH attribute received 209 from a CE device when advertising it further, and modify AS_PATH when 210 transmitted toward CE devices to achieve the desired effect of not 211 increasing the length of the AS_PATH. 213 At the conclusion of the ASN migration, the CE devices at the edge of 214 the network are not aware of the fact that their upstream router is 215 now in a new ASN and do not observe any change in the length of the 216 AS_PATH attribute. However, after the changes discussed in this 217 document are put in place by ISP A', there is a change to the 218 contents of the AS_PATH attribute to ensure the AS_PATH is not 219 artificially lengthened while these AS migration parameters are used. 221 In this use case, neither ISP is using BGP Confederations RFC 5065 222 [RFC5065] internally. 224 There are multiple implementations with equivalent features deployed 225 and in use. Some documentation pointers to these implementations, as 226 well as additional documentation on migration scenarios can be found 227 in the appendix. The examples cited below use Cisco IOS CLI for ease 228 of illustration purposes only. 230 3. External BGP Autonomous System Migration Features 232 The following section addresses features that are specific to 233 modifying the AS_PATH attribute at the Autonomous System Border 234 Routers (ASBRs) of an organization, (typically a single Service 235 Provider). This ensures that external BGP customers/peers are not 236 forced to make any configuration changes on their CE routers before 237 or during the exact time the Service Provider wishes to migrate to a 238 new, permanently retained ASN. Furthermore, these features eliminate 239 the artificial lengthening of the AS_PATH both transmitted from and 240 received by the Service Provider that is undergoing AS Migration, 241 which would have negative implications on path selection by external 242 networks. 244 3.1. Modify Inbound BGP AS_PATH Attribute 246 The first feature used in the process described above is called 247 "Local AS". This feature allows the PE router that was formerly in 248 ISP B to re-establish an eBGP session toward the existing CE devices 249 using the legacy AS, AS 64510. Ultimately, the CE devices (i.e.: 250 customer C) are completely unaware that ISP B has reconfigured its 251 router to participate as a member of a new AS. Within the context of 252 the former ISP B PE router, the second effect this feature has on 253 AS_PATH is that, by default, it prepends all received BGP UPDATEs 254 with the legacy AS of ISP B: AS 64510, while advertising it (Adj-RIB- 255 Out) to other BGP speakers (A'). Within Loc-RIB on ISP B prior to 256 the migration, the AS_PATH toward customer C would appear as: 64510, 257 whereas the same RIB on ISP A' (ISP B routers post-migration) would 258 contain AS_PATH: 64510 64496. To avoid changes to the AS_PATH 259 length, a secondary feature "No Prepend" is added to the "Local AS" 260 configuration toward every eBGP neighbor on PE routers migrating from 261 ISP B. The "No Prepend" feature causes those routers to not prepend 262 the legacy AS, AS 64510, when advertising UPDATES received from 263 customer C. This restores the AS_PATH within ISP A' toward customer 264 C so that it is just one ASN in length: 64496. 266 In the direction of CE -> PE (inbound): 268 1. 'local-as ': prepends the value to the AS_PATH 269 when advertising routes received from the CE 271 2. 'local-as no-prepend': does not prepend value 272 to the AS_PATH when advertising routes received from the CE 274 PE-B is a PE that was originally in ISP B, and has a customer peer 275 CE-B. PE-B has had its global configuration ASN changed from AS 276 64510 to AS 64500 to make it part of the permanently retained ASN. 277 This now makes PE-B a member of ISP A'. PE-A is a PE that was 278 originally in ISP A, and has a customer peer CE-A. Although its 279 global configuration ASN remains AS 64500, throughout this exercise 280 we also consider PE-A a member of ISP A'. 282 ISP A' ISP A' 283 CE-A <--- PE-A <------------------- PE-B <--- CE-B 284 64499 New_ASN: 64500 Old_ASN: 64510 64496 285 New_ASN: 64500 287 Note: Direction of BGP UPDATE as per the arrows. 289 Figure 3: Local AS BGP UPDATE Diagram 291 The final configuration on PE-B after completing the "Local AS" 292 portion of the AS migration is as follows: 294 router bgp 64500 295 neighbor remote-as 64496 296 neighbor local-as 64510 no-prepend 298 As a result of the "Local AS No Prepend" configuration, on PE-B, CE-A 299 will see an AS_PATH of: 64500 64496. CE-A will not receive a BGP 300 UPDATE containing AS 64510 in the AS_PATH. (If only the "local-as 301 64510" feature was configured without the keyword "no-prepend" on PE- 302 B, then CE-A would see an AS_PATH of: 64496 64510 64500, which 303 results in an unacceptable lengthening of the AS_PATH). 305 3.2. Modify Outbound BGP AS_PATH Attribute 307 The previous feature, "Local AS No Prepend", was designed to modify 308 the AS_PATH Attribute received by the ISP in updates from CE devices, 309 when CE devices still have an eBGP session established with the ISPs 310 legacy AS, (AS64510). In some existing implementations, "Local AS No 311 Prepend" does not concurrently modify the AS_PATH Attribute for BGP 312 UPDATEs that are transmitted by the ISP to CE devices. Specifically, 313 with "Local AS No Prepend" enabled on PE-B, it automatically causes a 314 lengthening of the AS_PATH in outbound BGP UPDATEs from ISP A' toward 315 directly attached eBGP speakers, (Customer C in AS 64496). This is 316 the result of the "Local AS No Prepend" feature automatically 317 appending the new global configuration ASN, AS64500, after the legacy 318 ASN, AS64510, in BGP UPDATEs that are transmitted by PE-B to CE-B. 319 The end result is that customer C, in AS 64496, will receive the 320 following AS_PATH: 64510 64500 64499. Therefore, if ISP A' takes no 321 further action, it will cause an unacceptable increase in AS_PATH 322 length within customer's networks directly attached to ISP A'. 324 A second feature was designed to resolve this problem (continuing the 325 use of Cisco CLI in the examples, it is called "Replace AS" in the 326 examples below). This feature allows ISP A' to prevent routers 327 configured with this feature from appending the global configured AS 328 in outbound BGP UPDATEs toward its customer's networks configured 329 with the "Local AS" feature. Instead, only the historical (or 330 legacy) AS will be prepended in the outbound BGP UPDATE toward the 331 customer's network, restoring the AS_PATH length to what it what was 332 before AS 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 The final configuration on PE-B after completing the "Replace AS" 346 portion of the AS migration is as follows: 348 router bgp 64500 349 neighbor remote-as 64496 350 neighbor local-as 64510 no-prepend replace-as 352 By default, without "Replace AS" enabled, CE-B would see an AS_PATH 353 of: 64510 64500 64499, which is artificially lengthened by the ASN 354 Migration. After ISP A' changes PE-B to include the "Replace AS" 355 feature, CE-B would receive an AS_PATH of: 64510 64499, which is the 356 same AS_PATH length pre-AS migration. 358 3.3. Implementation 360 While multiple implementations already exist, the following should 361 document the expected behavior such that a new implementation of this 362 feature could be done on other platforms. 364 These features MUST be configurable on a per-neighbor or per peer- 365 group basis to allow for maximum flexibility. When this feature set 366 is invoked, an ASN that is different from the globally-configured ASN 367 is provided as a part of the command as exemplified above. To 368 implement this feature, a BGP speaker MUST send BGP OPEN messages to 369 the configured eBGP peer using the ASN configured for this session as 370 the value sent in MY ASN. The speaker MUST NOT use the ASN 371 configured globally within the BGP process as the value sent in MY 372 ASN in the OPEN message. This will avoid the BGP OPEN Error message 373 BAD PEER AS, and is typically used to re-establish eBGP sessions with 374 peers expecting the legacy ASN after a router has been moved to a new 375 ASN. Additionally, when the BGP speaker configured with this feature 376 receives updates from its neighbor, it MUST process the update as 377 normal, but it MUST append the configured ASN in the AS_PATH 378 attribute before advertising the UPDATE to any other BGP speaker. 379 Note that processing the update as normal will include appending the 380 globally configured ASN to the AS_PATH, thus processing this update 381 will result in the addition of two ASNs to the AS_PATH attribute. 382 Similarly, for outbound updates sent by the configured BGP speaker to 383 its neighbor, the speaker MUST append the configured ASN to the 384 AS_PATH attribute, adding to the existing global ASN in the AS_PATH, 385 for a total of two ASNs added to the AS_PATH. 387 Two options exist to manipulate the behavior of this feature. They 388 modify the behavior as described below: 390 No prepend inbound - When the BGP speaker configured with this option 391 receives inbound updates from its neighbor, it MUST NOT append the 392 configured ASN in the AS_PATH attribute when advertising that UPDATE 393 to other peers and instead MUST append only the globally configured 394 ASN. 396 No prepend outbound - When the BGP speaker configured with this 397 option generates outbound BGP updates to the configured peer, the BGP 398 speaker MUST remove the globally configured ASN from the AS_PATH 399 attribute, and MUST append the locally configured ASN to the AS_PATH 400 attribute before sending outbound BGP updates to the configured peer. 402 While the exact command syntax is an implementation detail beyond the 403 scope of this document, the following consideration may be helpful 404 for implementers: Implementations MAY integrate the behavior of the 405 options described above into a single command that addresses both 406 inbound and outbound updates, but if this is done, implementations 407 MUST provide a method to select its applicability to inbound updates, 408 outbound updates, or updates in both directions. Several existing 409 implementations use separate commands (e.g. local-as no-prepend vs 410 local-as replace-as) for maximum flexibility in controlling the 411 behavior on the session to address the widest range of possible 412 migration scenarios. 414 4. Internal BGP Autonomous System Migration Features 416 The following section describes features that assist with a gradual 417 and least service impacting migration of Internal BGP sessions from a 418 legacy ASN to the permanently retained ASN. The following feature is 419 very valuable to networks undergoing AS migration, but its use does 420 not cause changes to the AS_PATH attribute. 422 4.1. Internal BGP Alias 424 In this case, all of the routers to be consolidated into a single, 425 permanently retained ASN are under the administrative control of a 426 single entity. Unfortunately, the traditional method of migrating 427 all Internal BGP speakers, particularly within larger networks, is 428 both time consuming and widely service impacting. 430 The traditional method to migrate Internal BGP sessions was strictly 431 limited to reconfiguration of the global configuration ASN and, 432 concurrently, changing all iBGP neighbors' remote ASN from the legacy 433 ASN to the new, permanently retained ASN on each router within the 434 legacy AS. These changes can be challenging to swiftly execute in 435 networks with with more than a few dozen internal BGP speakers. 436 There is also the concomitant service interruptions as these changes 437 are made to routers within the network, resulting in a reset of iBGP 438 sessions and subsequent route reconvergence to reestablish optimal 439 routing paths. Operators often cannot make such sweeping changes 440 given the associated risks of a highly visible service interruption; 441 rather, they require a more gradual method to migrate Internal BGP 442 sessions, from one ASN to a second, permanently retained ASN, that is 443 not visibly service-impacting to its customers. 445 With the "Internal BGP Alias" [JUNIPER] feature, it allows an 446 Internal BGP speaker to form a single iBGP session using either the 447 old, legacy ASN or the new, permanently retained ASN. The benefits 448 of using this feature are several fold. First, it allows for a more 449 gradual and less service-impacting migration away from the legacy ASN 450 to the permanently retained ASN. Second, it (temporarily) permits 451 the coexistence of the legacy and permanently retained ASN within a 452 single network, allowing for uniform BGP path selection among all 453 routers within the consolidated network. NB: Cisco doesn't have an 454 exact equivalent to "Internal BGP Alias", but the combination of the 455 Cisco features iBGP local-AS and dual-as provides similar 456 functionality. 458 When the "Internal BGP Alias" feature is enabled, typically just on 459 one side of a iBGP session, it allows that iBGP speaker to establish 460 a single iBGP session with either the legacy ASN or the new, 461 permanently retained ASN, depending on which one it receives in the 462 "My Autonomous System" field of the BGP OPEN message from its iBGP 463 session neighbor. It is important to recognize that enablement of 464 the "Internal BGP Alias" feature preserves the semantics of a regular 465 iBGP session, (using identical ASNs). Thus, the BGP attributes 466 transmitted by and the acceptable methods of operation on BGP 467 attributes received from iBGP sessions configured with "Internal BGP 468 Alias" are no different than those exchanged across an iBGP session 469 without "Internal BGP Alias" configured, as defined by [RFC4271] and 470 [RFC4456]. 472 Typically, in medium to large networks, BGP Route Reflectors 473 [RFC4456] (RRs) are used to aid in reduction of configuration of iBGP 474 sessions and scalability with respect to overall TCP (and, BGP) 475 session maintenance between adjacent iBGP speakers. Furthermore, BGP 476 Route Reflectors are typically deployed in pairs within a single 477 Route Reflection cluster to ensure high reliability of the BGP 478 Control Plane. As such, the following example will use Route 479 Reflectors to aid in understanding the use of the "Internal BGP 480 Alias" feature. Note that Route Reflectors are not a prerequisite to 481 enable "Internal BGP Alias" and this feature can be enabled 482 independent of the use of Route Reflectors. 484 The general order of operations is as follows: 486 1. Within the legacy network, (the routers comprising the set of 487 devices that still have a globally configured legacy ASN), one 488 member of a redundant pair of RRs has its global configuration 489 ASN changed to the permanently retained ASN. Concurrently, 490 "Internal BGP Alias" is configured on all iBGP sessions. This 491 will comprise Non-Client iBGP sessions to other RRs as well as 492 Client iBGP sessions, typically to PE devices, both still 493 utilizing the legacy ASN. Note that during this step there will 494 be a reset and reconvergence event on all iBGP sessions on the 495 RRs whose configuration was modified; however, this should not be 496 service impacting due to the use of redundant RRs in each RR 497 Cluster. 499 2. The above step is repeated for the other side of the redundant 500 pair of RRs. The one alteration to the above procedure is that 501 "Internal BGP Alias" is now removed from the Non-Client iBGP 502 sessions toward the other (previously reconfigured) RRs, since it 503 is no longer needed. "Internal BGP Alias" is still required on 504 all RRs for all RR Client iBGP sessions. Also during this step, 505 there will be a reset and reconvergence event on all iBGP 506 sessions whose configuration was modified, but this should not be 507 service impacting. At the conclusion of this step, all RRs 508 should now have their globally configured ASN set to the 509 permanently retained ASN and "Internal BGP Alias" enabled and in 510 use toward RR Clients. 512 3. At this point, the network administrators would then be able to 513 establish iBGP sessions between all Route Reflectors in both the 514 legacy and permanently retained networks. This would allow the 515 network to appear to function, both internally and externally, as 516 a single, consolidated network using the permanently retained 517 network. 519 4. To complete the AS migration, each RR Client (PE) in the legacy 520 network still utilizing the legacy ASN is now modified. 521 Specifically, each legacy PE would have its globally configured 522 ASN changed to use the permanently retained ASN. The ASN used by 523 the PE for the iBGP sessions toward each RR would be changed to 524 use the permanently retained ASN. (It is unnecessary to enable 525 "Internal BGP Alias" on the migrated iBGP sessions). During the 526 same maintenance window, External BGP sessions would be modified 527 to include the above "Local AS No Prepend" and "Replace-AS" 528 features described in Section 3 above, since all of the changes 529 are 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 Alias" 534 configuration from the first half of the legacy RR Client pair -- 535 this will expunge "Internal BGP Alias" configuration from all 536 devices in the network. After this is complete, all routers in 537 the network will be using the new, permanently retained ASN for 538 all iBGP sessions with no vestiges of the legacy ASN on any iBGP 539 sessions. 541 The benefit of using "Internal BGP Alias" is that it is a more 542 gradual and less externally service-impacting change to accomplish an 543 AS migration. Previously, without "Internal BGP Alias", such an AS 544 migration change would carry a high risk and need to be successfully 545 accomplished in a very short timeframe (e.g.: at most several hours). 546 In addition, it would likely cause substantial routing churn and 547 rapid fluctuations in traffic carried -- potentially causing periods 548 of congestion and resultant packet loss -- during the period the 549 configuration changes are underway to complete the AS Migration. On 550 the other hand, with "Internal BGP Alias", the migration from the 551 legacy ASN to the permanently retained ASN can occur over a period of 552 days or weeks with reduced customer disruption. (The only observable 553 service disruption should be when each PE undergoes the changes 554 discussed in step 4 above.) 556 4.2. Implementation 558 When configured with this feature, a BGP speaker MUST accept BGP OPEN 559 and establish an iBGP session from configured iBGP peers if the ASN 560 value in MY ASN is either the globally configured ASN or the locally 561 configured ASN provided in this command. Additionally, a BGP speaker 562 configured with this feature MUST send its own BGP OPEN using both 563 the globally configured and the locally configured ASN in MY ASN. To 564 avoid potential deadlocks when two BGP speakers are attempting to 565 establish a BGP peering session and are both configured with this 566 feature, the speaker SHOULD send BGP OPEN using the globally 567 configured ASN first, and only send a BGP OPEN using the locally 568 configured ASN as a fallback if the remote neighbor responds with the 569 BGP error BAD PEER ASN. In each case, the BGP speaker MUST treat 570 updates sent and received to this peer as if this was a natively 571 configured iBGP session, as defined by [RFC4271] and [RFC4456]. 573 Implementations of this feature MAY integrate the functionality from 574 the eBGP features (Section 3) section as a part of this command in 575 order to simplify support for eBGP migrations as well as iBGP 576 migrations, such that an eBGP session to a configured neighbor could 577 be established via either the global ASN or the locally configured 578 ASN. If the eBGP session is established with the global ASN, no 579 modifications to AS_PATH are required, but if the eBGP session is 580 established with the locally configured ASN, the modifications 581 discussed in eBGP features (Section 3) MUST be implemented to 582 properly manipulate the AS_PATH. 584 5. Additional Operational Considerations 586 This document describes several features to support ISPs and other 587 organizations that need to perform ASN migrations. Other variations 588 of these features may exist, for example, in legacy router software 589 that has not been upgraded or reached End of Life, but continues to 590 operate in the network. Such variations are beyond the scope of this 591 document. 593 Companies routinely go through periods of mergers, acquisitions and 594 divestitures, which in the case of the former cause them to 595 accumulate several legacy ASNs over time. ISPs often do not have 596 control over the configuration of customers' devices (i.e.: the ISPs 597 are often not providing a managed CE router service, particularly to 598 medium and large customers that require eBGP). Furthermore, ISPs are 599 using methods to perform ASN migration that do not require 600 coordination with customers. Ultimately, this means there is not a 601 finite period of time after which legacy ASNs will be completely 602 expunged from the ISP's network. In fact, it is common that legacy 603 ASNs and the associated External BGP AS Migration features discussed 604 in this document can and do persist for several years, if not longer. 605 Thus, it is prudent to plan that legacy ASNs and associated External 606 BGP AS Migration features will persist in a operational network 607 indefinitely. 609 With respect to the Internal BGP AS Migration Features, all of the 610 routers to be consolidated into a single, permanently retained ASN 611 are under the administrative control of a single entity. Thus, 612 completing the migration from iBGP sessions using the legacy ASN to 613 the permanently retained ASN is more straightforward and could be 614 accomplished in a matter of days to months. Finally, good 615 operational hygiene would dictate that it is good practice to avoid 616 using "Internal BGP Alias" over a long period of time for reasons of 617 not only operational simplicity of the network, but also reduced 618 reliance on that feature during the ongoing lifecycle management of 619 software, features and configurations that are maintained on the 620 network. 622 6. Conclusion 624 Although the features discussed in this document are not formally 625 recognized as part of the BGP4 specification, they have been in 626 existence in commercial implementations for well over a decade. 627 These features are widely known by the operational community and will 628 continue to be a critical necessity in the support of network 629 integration activities going forward. Therefore, these features are 630 extremely unlikely to be deprecated by vendors. As a result, these 631 features must be acknowledged by protocol designers, particularly 632 when there are proposals to modify BGP's behavior with respect to 633 handling or manipulation of the AS_PATH Attribute. More 634 specifically, assumptions should not be made with respect to the 635 preservation or consistency of the AS_PATH Attribute as it is 636 transmitted along a sequence of ASNs. In addition, proposals to 637 manipulate the AS_PATH that would gratuitously increase AS_PATH 638 length or remove the capability to use these features described in 639 this document will not be accepted by the operational community. 641 7. Acknowledgements 643 Thanks to Kotikalapudi Sriram, Stephane Litkowski, Terry Manderson, 644 David Farmer, Jaroslaw Adam Gralak, Gunter Van de Velde, Juan 645 Alcaide, Jon Mitchell, and Thomas Morin for their comments. 647 8. IANA Considerations 649 This memo includes no request to IANA. 651 9. Security Considerations 653 This draft discusses a process by which one ASN is migrated into and 654 subsumed by another. This involves manipulating the AS_PATH 655 Attribute with the intent of not increasing the AS_PATH length, which 656 would typically cause the BGP route to no longer be selected by BGP's 657 Path Selection Algorithm in others' networks. This could result in a 658 loss of revenue if the ISP is billing based on measured utilization 659 of traffic sent to/from entities attached to its network. This could 660 also result in sudden and unexpected shifts in traffic patterns in 661 the network, potentially resulting in congestion, in the most extreme 662 cases. 664 Given that these features can only be enabled through configuration 665 of routers within a single network, standard security measures should 666 be taken to restrict access to the management interface(s) of routers 667 that implement these features. 669 10. Appendix: Implementation report 671 As noted elsewhere in this document, this set of migration features 672 has multiple existing implementations in wide use. 674 o Cisco [CISCO] 676 o Juniper [JUNIPER] 678 o Alcatel-Lucent [ALU] 680 This is not intended to be an exhaustive list, as equivalent features 681 do exist in other implementations, however the authors were unable to 682 find publicly available documentation of the vendor-specific 683 implementation to reference. 685 11. References 687 11.1. Normative References 689 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 690 Requirement Levels", BCP 14, RFC 2119, March 1997. 692 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 693 Protocol 4 (BGP-4)", RFC 4271, January 2006. 695 [RFC5398] Huston, G., "Autonomous System (AS) Number Reservation for 696 Documentation Use", RFC 5398, December 2008. 698 11.2. Informative References 700 [ALU] Alcatel-Lucent, "BGP Local AS attribute", 2006-2012, 701 . 705 [CISCO] Cisco Systems, Inc., "BGP Support for Dual AS 706 Configuration for Network AS Migrations", 2003, 707 . 711 [JUNIPER] Juniper Networks, Inc., "Configuring the BGP Local 712 Autonomous System Attribute", 2012, 713 . 716 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 717 Reflection: An Alternative to Full Mesh Internal BGP 718 (IBGP)", RFC 4456, April 2006. 720 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 721 System Confederations for BGP", RFC 5065, August 2007. 723 [RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for 724 Private Use", BCP 6, RFC 6996, July 2013. 726 Authors' Addresses 728 Wesley George 729 Time Warner Cable 730 13820 Sunrise Valley Drive 731 Herndon, VA 20171 732 US 734 Phone: +1 703-561-2540 735 Email: wesley.george@twcable.com 737 Shane Amante 738 Apple, Inc. 739 1 Infinite Loop 740 Cupertino, CA 95014 741 US 743 Email: samante@apple.com