From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7705.txt | 899 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 899 insertions(+) create mode 100644 doc/rfc/rfc7705.txt (limited to 'doc/rfc/rfc7705.txt') diff --git a/doc/rfc/rfc7705.txt b/doc/rfc/rfc7705.txt new file mode 100644 index 0000000..0be764a --- /dev/null +++ b/doc/rfc/rfc7705.txt @@ -0,0 +1,899 @@ + + + + + + +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 + +Abstract + + This 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. + + + + + +George & Amante Standards Track [Page 1] + +RFC 7705 AS Migration Features November 2015 + + +Table of Contents + + 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 + +1. Introduction + + This document discusses some existing commonly used BGP mechanisms + for Autonomous System Number (ASN) migration that are not formally + part of the BGP4 [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 + + + +George & Amante Standards Track [Page 2] + +RFC 7705 AS Migration Features November 2015 + + + 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. + +1.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +1.2. Documentation Note + + This document uses Autonomous System Numbers (ASNs) from the range + reserved for documentation as described in RFC 5398 [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]. + +2. ASN Migration Scenario Overview + + The use case being discussed here is an ISP merging two or more ASNs, + where eventually one ASN subsumes the other(s). In this use case, we + will assume the most common case where there are two ISPs, A and B, + that prior to the ASN migration use AS 64500 and 64510, respectively. + AS 64500 will be the permanently retained ASN used across the + consolidated set of both ISPs network equipment, and AS 64510 will be + retired. Thus, at the conclusion of the ASN migration, there will be + a single ISP A' with all internal BGP speakers configured to use AS + 64500. To all external BGP speakers, the AS_PATH length will not be + increased. + + + +George & Amante Standards Track [Page 3] + +RFC 7705 AS Migration Features November 2015 + + + 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 + + + +George & Amante Standards Track [Page 4] + +RFC 7705 AS Migration Features November 2015 + + + 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. + +3. External BGP Autonomous System Migration Mechanisms + + The following section addresses optional capabilities that are + specific to modifying the AS_PATH attribute at the Autonomous System + Border Routers (ASBRs) of an organization (typically a single Service + Provider). This ensures that external BGP customers/peers are not + forced to make any configuration changes on their CE routers before + or during the exact time the Service Provider wishes to migrate to a + new, permanently retained ASN. Furthermore, these mechanisms + eliminate the artificial lengthening of the AS_PATH both transmitted + from and received by the Service Provider that is undergoing AS + Migration, which would have negative implications on path selection + by external networks. + +3.1. Modify Inbound BGP AS_PATH Attribute + + The first instrument used in the process described above is called + "Local AS". This allows the router to supersede the globally + configured ASN in the "My Autonomous System" field of the BGP OPEN + [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 -- + + + +George & Amante Standards Track [Page 5] + +RFC 7705 AS Migration Features November 2015 + + + 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 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 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 + + + +George & Amante Standards Track [Page 6] + +RFC 7705 AS Migration Features November 2015 + + + 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. + +3.2. Modify Outbound BGP AS_PATH Attribute + + The two aforementioned mechanisms, "Local AS" and "No Prepend + Inbound", only modify the AS_PATH attribute received by the ISP's PEs + in the course of processing BGP UPDATEs from CE devices when CE + devices still have an eBGP session established with the ISPs legacy + AS (AS64510). + + In some existing implementations, "Local AS" and "No Prepend Inbound" + do not concurrently modify the AS_PATH attribute for BGP UPDATEs that + are transmitted by the ISP's PEs to CE devices. In these + implementations, with "Local AS" and "No Prepend Inbound" used on + PE-B, there is an automatic lengthening of the AS_PATH in outbound + BGP UPDATEs from ISP A' toward directly attached eBGP speakers + (customer C in AS 64496). The externally observed result is that + customer C in AS 64496 will receive the following AS_PATH: 64510 + 64500 64499. Therefore, if ISP A' takes no further action, there + will be an unacceptable increase in the AS_PATH length within the + customer's networks directly attached to ISP A'. + + A tertiary mechanism, referred to as "Replace Old AS", is used to + resolve this problem. This capability allows ISP A' to prevent + routers from appending the globally configured ASN in outbound BGP + UPDATEs toward directly attached eBGP neighbors that are using the + "Local AS" mechanism. Instead, only the old (or previously used) AS + will be prepended in the outbound BGP UPDATE toward the customer's + network, restoring the AS_PATH length to what it what was before AS + Migration occurred. + + + + + + + + + + + + +George & Amante Standards Track [Page 7] + +RFC 7705 AS Migration Features November 2015 + + + 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. + +3.3. Implementation + + The mechanisms introduced in this section MUST be configurable on a + per-neighbor or per-neighbor-group basis to allow for maximum + flexibility. (Here, "neighbor group" refers to a group of similar + BGP neighbor statements that reuse some common configuration to + simplify provisioning.) When the "Local AS" capability is used, a + local ASN will be provided in the configuration that is different + from the globally configured ASN of the BGP router. To implement + this mechanism, a BGP speaker SHOULD send BGP OPEN [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]. + + + +George & Amante Standards Track [Page 8] + +RFC 7705 AS Migration Features November 2015 + + + 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. + +4. Internal BGP Autonomous System Migration Mechanisms + + The following section describes mechanisms that assist with a gradual + and least service-impacting migration of Internal BGP sessions from a + legacy ASN to the permanently retained ASN. The following mechanism + is very valuable to networks undergoing AS migration, but its use + does not cause changes to the AS_PATH attribute. + + + + + + +George & Amante Standards Track [Page 9] + +RFC 7705 AS Migration Features November 2015 + + +4.1. Internal BGP AS Migration + + In this case, all of the routers to be consolidated into a single, + permanently retained ASN are under the administrative control of a + single entity. Unfortunately, the traditional method of migrating + all Internal BGP speakers, particularly within larger networks, is + both time-consuming and widely service impacting. + + The traditional method to migrate Internal BGP sessions was strictly + limited to reconfiguration of the global configuration ASN and, + concurrently, changing all iBGP neighbors' remote ASN from the legacy + ASN to the new, permanently retained ASN on each router within the + legacy AS. These changes can be challenging to swiftly execute in + networks with more than a few dozen internal BGP routers. There are + also the concomitant service interruptions as these changes are made + to routers within the network, resulting in a reset of iBGP sessions + and subsequent route reconvergence to reestablish optimal routing + paths. Operators often cannot make such sweeping changes given the + associated risks of a highly visible service interruption; rather, + they require a more gradual method to migrate Internal BGP sessions, + from one ASN to a second, permanently retained ASN, that is not + visibly service impacting to its customers. + + With the "Internal BGP AS Migration" mechanism described herein, it + allows an Internal BGP speaker to form a single iBGP session using + either the old, legacy ASN or the new, permanently retained ASN. The + benefits of using this mechanism are several fold. First, it allows + for a more gradual and less service-impacting migration away from the + legacy ASN to the permanently retained ASN. Second, it (temporarily) + permits the coexistence of the legacy and permanently retained ASN + within a single network, allowing for uniform BGP path selection + among all routers within the consolidated network. + + The iBGP router with the "Internal BGP AS Migration" capability + enabled allows the receipt of a BGP OPEN message with either the + legacy ASN value or the new, globally configured ASN value in the "My + Autonomous System" field of the BGP OPEN message from iBGP neighbors. + It is important to recognize that enablement of the "Internal BGP AS + Migration" mechanism preserves the semantics of a regular iBGP + session (i.e., using identical ASNs). Thus, the BGP attributes + transmitted by and the acceptable methods of operation on BGP + attributes received from iBGP sessions configured with "Internal BGP + AS Migration" capability are no different than those exchanged across + an iBGP session without "Internal BGP AS Migration" configured, as + defined by [RFC4271] and [RFC4456]. + + + + + + +George & Amante Standards Track [Page 10] + +RFC 7705 AS Migration Features November 2015 + + + 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. + + + + +George & Amante Standards Track [Page 11] + +RFC 7705 AS Migration Features November 2015 + + + 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.) + +4.2. Implementation + + The mechanism introduced in this section MUST be configurable on a + per-neighbor or per-neighbor-group basis to allow for maximum + flexibility. When configured with this mechanism, a BGP speaker MUST + accept BGP OPEN and establish an iBGP session from configured iBGP + peers if the ASN value in "My Autonomous System" is either the + globally configured ASN or a locally configured ASN provided when + this capability is utilized. Additionally, a BGP router configured + with this mechanism MUST send its own BGP OPEN [RFC4271] (see + Section 4.2) using either the globally configured or the locally + + + +George & Amante Standards Track [Page 12] + +RFC 7705 AS Migration Features November 2015 + + + 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]. + +5. Additional Operational Considerations + + This document describes several mechanisms to support ISPs and other + organizations that need to perform ASN migrations. Other variations + of these mechanisms may exist, for example, in legacy router software + that has not been upgraded or reached End of Life, but continues to + operate in the network. Such variations are beyond the scope of this + document. + + Companies routinely go through periods of mergers, acquisitions, and + divestitures, which in the case of the former cause them to + accumulate several legacy ASNs over time. ISPs often do not have + control over the configuration of customers' devices (i.e., the ISPs + are often not providing a managed CE router service, particularly to + medium and large customers that require eBGP). Furthermore, ISPs are + using methods to perform ASN migration that do not require + coordination with customers. Ultimately, this means there is not a + finite period of time after which legacy ASNs will be completely + expunged from the ISP's network. In fact, it is common that legacy + ASNs and the associated External BGP AS Migration mechanisms + discussed in this document can and do persist for several years, if + not longer. Thus, it is prudent to plan that legacy ASNs and + associated External BGP AS Migration mechanisms will persist in an + operational network indefinitely. + + With respect to the Internal BGP AS Migration mechanism, all of the + routers to be consolidated into a single, permanently retained ASN + are under the administrative control of a single entity. Thus, + completing the migration from iBGP sessions using the legacy ASN to + the permanently retained ASN is more straightforward and could be + accomplished in a matter of days to months. Finally, good + operational hygiene would dictate that it is good practice to avoid + using "Internal BGP AS Migration" capability over a long period of + time for reasons of not only operational simplicity of the network, + + + +George & Amante Standards Track [Page 13] + +RFC 7705 AS Migration Features November 2015 + + + but also reduced reliance on that mechanism during the ongoing life + cycle management of software, features, and configurations that are + maintained on the network. + +6. Security Considerations + + This document discusses a process by which one ASN is migrated into + and subsumed by another. This involves manipulating the AS_PATH + attribute with the intent of not increasing the AS_PATH length, which + would typically cause the BGP route to no longer be selected by BGP's + Path Selection Algorithm in others' networks. This could result in + sudden and unexpected shifts in traffic patterns in the network, + potentially resulting in congestion. + + Given that these mechanisms can only be enabled through configuration + of routers within a single network, standard security measures should + be taken to restrict access to the management interface(s) of routers + that implement these mechanisms. Additionally, BGP sessions SHOULD + be protected using TCP Authentication Option [RFC5925] and the + Generalized TTL Security Mechanism [RFC5082] + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [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, + . + + [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, + . + +7.2. Informative References + + [ALU] Alcatel-Lucent, "BGP Local AS attribute", 2006-2012, + . + + + + + +George & Amante Standards Track [Page 14] + +RFC 7705 AS Migration Features November 2015 + + + [CISCO] Cisco Systems, Inc., "BGP Support for Dual AS + Configuration for Network AS Migrations", 2013, + . + + [JUNIPER] Juniper Networks, Inc., "Understanding the BGP Local AS + Attribute", December 2013, + . + + [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous + System Confederations for BGP", RFC 5065, + DOI 10.17487/RFC5065, August 2007, + . + + [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, + . + + [RFC5398] Huston, G., "Autonomous System (AS) Number Reservation for + Documentation Use", RFC 5398, DOI 10.17487/RFC5398, + December 2008, . + + [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP + Authentication Option", RFC 5925, DOI 10.17487/RFC5925, + June 2010, . + + [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet + Autonomous System (AS) Number Space", RFC 6793, + DOI 10.17487/RFC6793, December 2012, + . + + [RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for + Private Use", BCP 6, RFC 6996, DOI 10.17487/RFC6996, July + 2013, . + + + + + + + + + + + + + + +George & Amante Standards Track [Page 15] + +RFC 7705 AS Migration Features November 2015 + + +Appendix A. Implementation Report + + As noted elsewhere in this document, this set of migration mechanisms + has multiple existing implementations in wide use. + + o Cisco [CISCO] + + o Juniper [JUNIPER] + + o Alcatel-Lucent [ALU] + + This is not intended to be an exhaustive list, as equivalent features + do exist in other implementations; however, the authors were unable + to find publicly available documentation of the vendor-specific + implementation to reference. + +Acknowledgements + + Thanks to Kotikalapudi Sriram, Stephane Litkowski, Terry Manderson, + David Farmer, Jaroslaw Adam Gralak, Gunter Van de Velde, Juan + Alcaide, Jon Mitchell, Thomas Morin, Alia Atlas, Alvaro Retana, and + John Scudder for their comments. + +Authors' Addresses + + Wesley George + Time Warner Cable + 13820 Sunrise Valley Drive + Herndon, VA 20171 + United States + + Phone: +1 703-561-2540 + Email: wesley.george@twcable.com + + + Shane Amante + Apple, Inc. + 1 Infinite Loop + Cupertino, CA 95014 + United States + + Email: amante@apple.com + + + + + + + + + +George & Amante Standards Track [Page 16] + -- cgit v1.2.3