Internet Engineering Task Force (IETF) W. George Request for Comments: 7705 Time Warner Cable Updates: 4271 S. Amante Category: Standards Track Apple, Inc. ISSN: 2070-1721 November 2015 Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute
AbstractThis document discusses some existing commonly used BGP mechanisms for Autonomous System Number (ASN) migration that are not formally part of the BGP4 protocol specification. It is necessary to document these de facto standards to ensure that they are properly supported in future BGP protocol work. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7705. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Documentation Note . . . . . . . . . . . . . . . . . . . 3 2. ASN Migration Scenario Overview . . . . . . . . . . . . . . . 3 3. External BGP Autonomous System Migration Mechanisms . . . . . 5 3.1. Modify Inbound BGP AS_PATH Attribute . . . . . . . . . . 5 3.2. Modify Outbound BGP AS_PATH Attribute . . . . . . . . . . 7 3.3. Implementation . . . . . . . . . . . . . . . . . . . . . 8 4. Internal BGP Autonomous System Migration Mechanisms . . . . . 9 4.1. Internal BGP AS Migration . . . . . . . . . . . . . . . . 10 4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 12 5. Additional Operational Considerations . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . 14 Appendix A. Implementation Report . . . . . . . . . . . . . . . 16 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 RFC4271] protocol specification. These mechanisms are local to a given BGP speaker and do not require negotiation with or cooperation of BGP neighbors. The deployment of these mechanisms do not need to interwork with one another to accomplish the desired results, so slight variations between existing vendor implementations exist and will not necessarily be harmonized due to this document. However, it is necessary to document these de facto standards to ensure that new implementations can be successful, and any future protocol enhancements to BGP that propose to read, copy, manipulate, or compare the AS_PATH attribute can do so without inhibiting the use of these very widely used ASN migration mechanisms. The migration mechanisms discussed here are useful to ISPs and organizations of all sizes, but it is important to understand the business need for these mechanisms and illustrate why they are so critical for ISPs' operations. During a merger, acquisition, or divestiture involving two organizations it is necessary to seamlessly migrate both internal and external BGP speakers from one ASN to a second ASN. The overall goal in doing so is to simplify operations through consistent configurations across all BGP speakers in the combined network. In addition, given that the BGP Path Selection algorithm selects routes with the shortest AS_PATH attribute, it is
critical that the ISP does not increase AS_PATH length during or after ASN migration, because an increased AS_PATH length would likely result in sudden, undesirable changes in traffic-patterns in the network. By default, the BGP protocol requires an operator to configure a router to use a single remote ASN for the BGP neighbor, and the ASN must match on both ends of the peering in order to successfully negotiate and establish a BGP session. Prior to the existence of these migration mechanisms, it would have required an ISP to coordinate an ASN change with, in some cases, tens of thousands of customers. In particular, as each router is migrated to the new ASN, to avoid an outage due to ASN mismatch, the ISP would have to force all customers on that router to change their router configurations to use the new ASN immediately after the ASN change. Thus, it was critical to define a more asymmetric migration method so that the ISP could seamlessly change the ASN within its network(s) but allow the customers to gradually migrate to the ISP's new ASN when convenient. These customer migrations could occur either by coordinating individual session reconfigurations or, to allow for truly asymmetric migration, by accepting sessions using either the old or new ASN. RFC2119]. RFC5398]. In the examples used here, they are intended to represent Globally Unique ASNs, not private use ASNs as documented in Section 5 of RFC 6996 [RFC6996].
In this same scenario, AS 64496 and AS 64499 represent two separate customer networks: C and D, respectively. Originally, customer C (AS 64496) is attached to ISP B, which will undergo ASN migration from AS 64510 to AS 64500. Furthermore, customer D (AS 64499) is attached to ISP A, which does not undergo ASN migration since the ASN for ISP A will remain constant, (AS 64500). Although this example refers to AS 64496 and 64499 as customer networks, either or both may be settlement-free or other types of peers. In this use case, they are referred to as "customers" merely for convenience. ------ ------ / ISP A \ / ISP B \ | AS 64500 | | AS 64510 | \ / \ / ------- ------- | | | | ------------ ------------- | Cust D | | Cust C | | AS 64499 | | AS 64496 | ------------ ------------- Figure 1: Before Migration --------------- / \ | ISP A' | | AS 64500 | \ / --------------- / \ / \ | | ------------ ------------- | Cust D | | Cust C | | AS 64499 | | AS 64496 | ------------ ------------- Figure 2: After Migration The general order of operations, typically carried out in a single maintenance window by the network undergoing ASN migration (ISP B), is as follows. First, ISP B will change the global BGP ASN used by a Provider Edge (PE) router, from ASN 64510 to 64500. At this point, the router will no longer be able to establish External BGP (eBGP) sessions toward the existing Customer Edge (CE) devices that are attached to it and still using AS 64510. Second, since ISP B needs to do this without coordinating the simultaneous change of its ASN
with all of its eBGP peers, ISP B will configure two separate, but related ASN migration mechanisms discussed in this document on all eBGP sessions toward all CE devices. These mechanisms enable the router to establish BGP neighbors using the legacy ASN, modify the AS_PATH attribute received from a CE device when advertising it further, and modify AS_PATH when transmitted toward CE devices to achieve the desired effect of not increasing the length of the AS_PATH. At the conclusion of the ASN migration, the CE devices at the edge of the network are not aware of the fact that their upstream router is now in a new ASN and do not observe any change in the length of the AS_PATH attribute. However, after the changes discussed in this document are put in place by ISP A', there is a change to the contents of the AS_PATH attribute to ensure the AS_PATH is not artificially lengthened while these AS migration parameters are used. In this use case, neither ISP is using BGP Confederations [RFC5065] internally. RFC4271] with a locally defined AS value for a specific BGP neighbor or group of neighbors. This mechanism allows the PE router that was formerly in ISP B to establish an eBGP session toward the existing CE devices using the legacy AS -- AS 64510. Ultimately, the CE devices (i.e., customer C) are completely unaware that ISP B has reconfigured its router to participate as a member of a new AS. Within the context of the former ISP B PE router, the second effect this specific mechanism has on AS_PATH is that, by default, it prepends all received BGP UPDATEs with the legacy AS of ISP B -- AS 64510 --
while advertising it (Adj-RIB-Out) to other BGP speakers (A'). Within the Loc-RIB on ISP B prior to the migration, the AS_PATH of route announcements received from customer C would appear as 64496, whereas the same RIB on ISP A' (ISP B routers post-migration) would contain AS_PATH 64510 64496. The second instrument, referred to as "No Prepend Inbound", is enabled on PE routers migrating from ISP B. The "No Prepend Inbound" capability causes ISP B's routers to not prepend the legacy AS (AS 64510), when advertising UPDATES received from customer C. This restores the AS_PATH within ISP A' for route announcements received from customer C so that it is just one ASN in length: 64496. In the direction of CE -> PE (inbound): 1. "Local AS": Allows the local BGP router to generate a BGP OPEN to an eBGP neighbor with the old, legacy ASN value in the "My Autonomous System" field. When this capability is activated, it also causes the local router to prepend the <old_ASN> value to the AS_PATH when installing or advertising routes received from a CE to Internal BGP (iBGP) neighbors inside the Autonomous System. 2. "No Prepend Inbound (of Local AS)": The local BGP router does not prepend the <old_ASN> value to the AS_PATH when installing or advertising routes received from the CE to iBGP neighbors inside the Autonomous System PE-B is a PE that was originally in ISP B, and has a customer eBGP session to CE-B. PE-B has had its global configuration ASN changed from AS 64510 to AS 64500 to make it part of the permanently retained ASN. This now makes PE-B a member of ISP A'. PE-A is a PE that was originally in ISP A, and has a customer peer CE-A. Although its global configuration ASN remains AS 64500, throughout this exercise we also consider PE-A a member of ISP A'. ISP A' ISP A' CE-A <--- PE-A <------------------- PE-B <--- CE-B 64499 New_ASN: 64500 Old_ASN: 64510 64496 New_ASN: 64500 Note: Direction of BGP UPDATE as per the arrows. Figure 3: Local AS and No Prepend BGP UPDATE Diagram As a result, using both the "Local AS" and "No Prepend Inbound" capabilities on PE-B, CE-A will see an AS_PATH of 64500 64496. CE-A will not receive a BGP UPDATE containing AS 64510 in the AS_PATH. (If only the "Local AS" mechanism was configured without "No Prepend
Inbound" on PE-B, then CE-A would have seen an AS_PATH of 64500 64510 64496, which results in an unacceptable lengthening of the AS_PATH). Note: If there are still routers in the old ASN (64510), it is possible for them to accept these manipulated routes (i.e., those with 64510 removed from the AS_PATH by this command) as if they have not already passed through their ASN, potentially causing a loop, since BGP's normal loop-prevention behavior of rejecting routes that include its ASN in the path will not catch these. Careful filtering between routers remaining in the old ASN and routers migrated to the new ASN is necessary to minimize the risk of routing loops.
To reuse the above diagram, but in the opposite direction, we have: ISP A' ISP A' CE-A ---> PE-A -------------------> PE-B ---> CE-B 64499 New_ASN: 64500 Old_ASN: 64510 64496 New_ASN: 64500 Note: Direction of BGP UPDATE as per the arrows. Figure 4: Replace AS BGP UPDATE Diagram By default, without the use of "Replace Old AS", CE-B would see an AS_PATH of 64510 64500 64499. After ISP A' changes PE-B to use "Replace Old AS", CE-B would receive an AS_PATH of 64510 64499, which is the same AS_PATH length pre-AS migration. RFC4271] (see Section 4.2) messages to the configured eBGP peer(s) using the local ASN configured for this session as the value sent in "My Autonomous System". The BGP router SHOULD NOT use the ASN configured globally within the BGP process as the value sent in "My Autonomous System" in the OPEN message. This prevents causing the eBGP neighbor to unnecessarily generate a BGP OPEN Error message "Bad Peer AS". This method is typically used to re-establish eBGP sessions with peers expecting the legacy ASN after a router has been moved to a new ASN. Implementations MAY support a more flexible model where the eBGP speaker attempts to open the BGP session using either the ASN configured as "Local AS" or the globally configured AS as discussed in BGP Alias (Section 4.2). If the session is successfully established to the globally configured ASN, then the modifications to AS_PATH described in this document SHOULD NOT be performed, as they are unnecessary. The benefit to this more flexible model is that it allows the remote neighbor to reconfigure to the new ASN without direct coordination between the ISP and the customer. Note that this procedure will vary slightly if the locally or globally configured ASN is a 4-octet ASN. See Section 3 of [RFC6793].
When the BGP router receives UPDATEs from its eBGP neighbor configured with the "Local AS" mechanism, it processes the UPDATE as described in RFC4271 Section 5.1.2 [RFC4271]. However, the presence of a second ASN due to "Local AS" adds the following behavior to processing UPDATEs received from an eBGP neighbor configured with this mechanism: 1. Internal: The router SHOULD append the configured "Local AS" ASN in the AS_PATH attribute before installing the route or advertising the UPDATE to an iBGP neighbor. The decision of when to append the ASN is an implementation detail outside the scope of this document. Some considerations factoring into this decision include consistency in the AS_PATH throughout the AS, and implementation of the loop detection mechanism. 2. External: The BGP router SHOULD first append the globally configured ASN to the AS_PATH immediately followed by the "Local AS" value before advertising the UPDATE to an eBGP neighbor. Two options exist to manipulate the behavior of the basic "Local AS" mechanism. They modify the behavior as described below: 1. "No Prepend Inbound": When the BGP router receives inbound BGP UPDATEs from its eBGP neighbor configured with this option, it MUST NOT append the "Local AS" ASN value in the AS_PATH attribute when installing the route or advertising that UPDATE to iBGP neighbors, but it MUST still append the globally configured ASN as normal when advertising the UPDATE to other local eBGP neighbors (i.e., those natively peering with the globally configured ASN). 2. "Replace Old AS" (outbound): When the BGP router generates outbound BGP UPDATEs toward an eBGP neighbor configured with this option, the BGP speaker MUST NOT append the globally configured ASN from the AS_PATH attribute. The BGP router MUST append only the configured "Local AS" ASN value to the AS_PATH attribute before sending the BGP UPDATEs outbound to the eBGP neighbor.
Typically, in medium to large networks, BGP Route Reflectors (RRs) [RFC4456] are used to aid in reduction of configuration of iBGP sessions and scalability with respect to overall TCP (and BGP) session maintenance between adjacent iBGP routers. Furthermore, BGP Route Reflectors are typically deployed in pairs within a single Route Reflection cluster to ensure high reliability of the BGP Control Plane. As such, the following example will use Route Reflectors to aid in understanding the use of the "Internal BGP AS Migration" mechanism. Note that Route Reflectors are not a prerequisite to enable "Internal BGP AS Migration" and this mechanism can be enabled independent of the use of Route Reflectors. The general order of operations is as follows: 1. Within the legacy network, (the routers comprising the set of devices that still have a globally configured legacy ASN), one member of a redundant pair of RRs has its global configuration ASN changed to the permanently retained ASN. Concurrently, the "Internal BGP AS Migration" capability is enabled on all iBGP sessions on that device. This will comprise Non-Client iBGP sessions to other RRs as well as Client iBGP sessions, typically to PE devices, both still utilizing the legacy ASN. Note that during this step there will be a reset and reconvergence event on all iBGP sessions on the RRs whose configuration was modified; however, this should not be service impacting due to the use of redundant RRs in each RR Cluster. 2. The above step is repeated for the other side of the redundant pair of RRs. The one alteration to the above procedure is that the "Internal BGP AS Migration" mechanism is now removed from the Non-Client iBGP sessions toward the other (previously reconfigured) RRs, since it is no longer needed. The "Internal BGP AS Migration" mechanism is still required on all RRs for all RR Client iBGP sessions. Also during this step, there will be a reset and reconvergence event on all iBGP sessions whose configuration was modified, but this should not be service impacting. At the conclusion of this step, all RRs will have their globally configured ASN set to the permanently retained ASN and "Internal BGP AS Migration" enabled and in use toward RR Clients. 3. At this point, the network administrators would then be able to establish iBGP sessions between all Route Reflectors in both the legacy and permanently retained networks. This would allow the network to appear to function, both internally and externally, as a single, consolidated network using the permanently retained network.
4. To complete the AS migration, each RR Client (PE) in the legacy network still utilizing the legacy ASN is now modified. Specifically, each legacy PE would have its globally configured ASN changed to use the permanently retained ASN. The ASN configured within the PE for the iBGP sessions toward each RR would be changed to use the permanently retained ASN. It is unnecessary to enable the "Internal BGP AS Migration" mechanism on these migrated iBGP sessions. During the same maintenance window, External BGP sessions would be modified to include the above "Local AS", "No Prepend", and "Replace Old AS" mechanisms described in Section 3 above, since all of the changes are service interrupting to the eBGP sessions of the PE. At this point, all PEs will have been migrated to the permanently retained ASN. 5. The final step is to excise the "Internal BGP AS Migration" configuration from the Router Reflectors in an orderly fashion. After this is complete, all routers in the network will be using the new, permanently retained ASN for all iBGP sessions with no vestiges of the legacy ASN on any iBGP sessions. The benefit of using the aforementioned "Internal BGP AS Migration" capability is that it is a more gradual and less externally service impacting change to accomplish an AS migration. Previously, without "Internal BGP AS Migration", such an AS migration change would carry a high risk and need to be successfully accomplished in a very short time frame (e.g., at most several hours). In addition, it would likely cause substantial routing churn and rapid fluctuations in traffic carried -- potentially causing periods of congestion and resultant packet loss -- during the period when the configuration changes are underway to complete the AS Migration. On the other hand, with "Internal BGP AS Migration", the migration from the legacy ASN to the permanently retained ASN can occur over a period of days or weeks with reduced customer disruption. (The only observable service disruption should be when each PE undergoes the changes discussed in step 4 above.) RFC4271] (see Section 4.2) using either the globally configured or the locally
configured ASN in "My Autonomous System" as follows. To avoid potential deadlocks when two BGP speakers are attempting to establish a BGP peering session and are both configured with this mechanism, the speaker SHOULD send BGP OPEN using the globally configured ASN first, and only send a BGP OPEN using the locally configured ASN as a fallback if the remote neighbor responds with the BGP error "Bad Peer AS". In each case, the BGP speaker MUST treat UPDATEs sent and received to this peer as if this was a natively configured iBGP session, as defined by [RFC4271] and [RFC4456]. Note that this procedure will vary slightly if the locally or globally configured ASN is a 4-octet ASN. See Section 3 of [RFC6793].
but also reduced reliance on that mechanism during the ongoing life cycle management of software, features, and configurations that are maintained on the network. RFC5925] and the Generalized TTL Security Mechanism [RFC5082] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>. [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, <http://www.rfc-editor.org/info/rfc4456>. [ALU] Alcatel-Lucent, "BGP Local AS attribute", 2006-2012, <https://infoproducts.alcatel-lucent.com/html/0_add-h-f/ 93-0074-10-01/7750_SR_OS_Routing_Protocols_Guide/ BGP-CLI.html#709567>.
[CISCO] Cisco Systems, Inc., "BGP Support for Dual AS Configuration for Network AS Migrations", 2013, <http://www.cisco.com/c/en/us/td/docs/ios-xml/ ios/iproute_bgp/configuration/xe-3s/asr1000/ irg-xe-3s-asr1000-book/irg-dual-as.html>. [JUNIPER] Juniper Networks, Inc., "Understanding the BGP Local AS Attribute", December 2013, <http://www.juniper.net/techpubs/en_US/junos13.3/topics/ concept/bgp-local-as-introduction.html>. [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 5065, DOI 10.17487/RFC5065, August 2007, <http://www.rfc-editor.org/info/rfc5065>. [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, <http://www.rfc-editor.org/info/rfc5082>. [RFC5398] Huston, G., "Autonomous System (AS) Number Reservation for Documentation Use", RFC 5398, DOI 10.17487/RFC5398, December 2008, <http://www.rfc-editor.org/info/rfc5398>. [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <http://www.rfc-editor.org/info/rfc5925>. [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012, <http://www.rfc-editor.org/info/rfc6793>. [RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for Private Use", BCP 6, RFC 6996, DOI 10.17487/RFC6996, July 2013, <http://www.rfc-editor.org/info/rfc6996>.