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