RFC 7705
Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute
RFC 7705: Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute 🦋
Okay bestie, this one is RFC 7705 from the IETF 💖 It was published in November 2015 with ISSN 2070-1721, and the authors are W. George (Time Warner Cable) and S. Amante (Apple, Inc.). It's a Standards Track doc, and it updates RFC 4271 (that's the BGP4 spec 👑).
Abstract
This doc talks about some BGP tricks that lots of networks already use for Autonomous System Number (ASN) migration ✨ They aren't formally part of the BGP4 protocol spec yet, but they're basically de facto standards. Writing them down makes sure they stay 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 went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 5741 🌸
Info about the current status of this doc, any errata, and how to send feedback lives 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 doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were in effect on the publication date. Please actually read these docs, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 💜
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 . . . . . . . . . . . . . . . . . . . . . . . 161. Introduction ✨
This doc talks about BGP mechanisms for ASN migration that people already use all the time, even though they aren't formally part of the BGP4 [RFC4271] protocol spec 🦋 These mechanisms are local to a single BGP speaker. They don't need any negotiation with, or cooperation from, BGP neighbors 🫶 Different mechanisms don't need to interwork with each other to get the job done, so vendor implementations are a little different from each other, and this doc won't necessarily make them match 🙈 Still, writing these de facto standards down means new implementations can succeed. It also means any future BGP protocol enhancement that wants to read, copy, manipulate, or compare the AS_PATH attribute can do that without breaking these super popular ASN migration mechanisms 💖
These mechanisms are useful to ISPs and organizations of every size. It's important to get why they're needed, though, because they're seriously critical for ISP operations 😭 When two organizations merge, get acquired, or divest, both internal and external BGP speakers have to move from one ASN to another, and it has to be seamless 🔥 The big goal is simpler operations through consistent configurations on every BGP speaker in the combined network 👑 There's another big thing: BGP Path Selection picks the route with the shortest AS_PATH attribute. So an ISP absolutely cannot let AS_PATH length go up during or after an ASN migration, because a longer AS_PATH would likely cause sudden, undesirable shifts in traffic patterns across the network 🌈
By default, BGP makes an operator configure a router with a single remote ASN for each BGP neighbor. That ASN has to match on both ends of the peering, or the BGP session just won't negotiate and establish 💀 Before these migration mechanisms existed, an ISP had to coordinate an ASN change with, in some cases, tens of thousands of customers 😵 As each router got moved to the new ASN, the ISP would have had to force every customer on that router to update their router configs to the new ASN right after the change, or else they'd get an outage from the ASN mismatch. So it was crucial to define a more asymmetric migration method. That way the ISP could change the ASN within its network(s) seamlessly, while customers migrate to the ISP's new ASN gradually, whenever it's convenient for them 🧚 Those customer migrations could happen either by coordinating individual session reconfigurations or, for truly asymmetric migration, by accepting sessions using either the old or the new ASN 🎀
1.1. Requirements Language
Okay so the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are interpreted exactly as described in RFC 2119 [RFC2119] 📚
1.2. Documentation Note
This doc uses ASNs from the range reserved for documentation, as described in RFC 5398 [RFC5398] 🧸 In the examples here, the ASNs are meant to stand in for Globally Unique ASNs, not the private use ASNs documented in Section 5 of RFC 6996 [RFC6996] 🍓
2. ASN Migration Scenario Overview 🌸
The use case here is an ISP merging two or more ASNs, where eventually one ASN absorbs the other(s) 💅 We'll go with the most common case: two ISPs, A and B, who use AS 64500 and 64510 before the migration. AS 64500 is the ASN that gets permanently kept for the combined network equipment of both ISPs, and AS 64510 gets retired 😤 So once the migration is done, there's one ISP A' with every internal BGP speaker configured to use AS 64500. For all external BGP speakers, the AS_PATH length doesn't go up 🙌
Now bring in two customer networks, C and D, which are AS 64496 and AS 64499. Customer C (AS 64496) starts out attached to ISP B, which is going through the ASN migration from AS 64510 to AS 64500 🫣 Customer D (AS 64499) is attached to ISP A, which doesn't migrate at all, since ISP A's ASN stays the same (AS 64500). Btw, even though this example calls AS 64496 and 64499 "customer networks," either or both could be settlement-free peers or some other kind of peer. The word "customers" is just for convenience here 💜
------ ------
/ 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 MigrationHere's the general order of operations, usually done in one maintenance window by the network that's migrating (ISP B) 🕯️ First, ISP B changes the global BGP ASN used by a Provider Edge (PE) router, from ASN 64510 to 64500. Right then, the router can't establish External BGP (eBGP) sessions with the Customer Edge (CE) devices attached to it that still use AS 64510 😬 Second, because ISP B has to do this without coordinating the simultaneous ASN change with all of its eBGP peers, ISP B configures two separate but related ASN migration mechanisms from this doc on every eBGP session toward every CE device 🫶 These mechanisms let the router 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 it's transmitted toward CE devices, so the AS_PATH length doesn't go up. That's the whole goal 🎯
When the migration is finished, the CE devices at the edge of the network don't know their upstream router is now in a new ASN, and they don't see any change in AS_PATH length 🦋 But once ISP A' puts the changes from this doc in place, the contents of the AS_PATH attribute do change. This makes sure AS_PATH doesn't get artificially lengthened while these AS migration parameters are in use 🌈
In this use case, neither ISP uses BGP Confederations [RFC5065] internally 🧩
3. External BGP Autonomous System Migration Mechanisms 💖
This section covers optional capabilities that are specific to modifying the AS_PATH attribute at the Autonomous System Border Routers (ASBRs) of an organization, which is usually a single Service Provider 🎀 The whole point is that external BGP customers and peers don't have to make any configuration changes on their CE routers before or during the exact moment the Service Provider wants to migrate to its new, permanently retained ASN ✨ On top of that, these mechanisms get rid of the artificial lengthening of AS_PATH, both the AS_PATH transmitted from and the one received by the Service Provider going through AS Migration. That lengthening would have bad effects on path selection by external networks 😭
3.1. Modify Inbound BGP AS_PATH Attribute 💖
Okay bestie, the first tool in this whole process is called "Local AS" 🦋 It lets the router swap the globally configured ASN in the My Autonomous System field of the BGP OPEN [RFC4271] for a locally defined AS value, but only for a specific BGP neighbor or a group of neighbors. So the PE router that used to live in ISP B can set up an eBGP session with the existing CE devices using the legacy AS, which is AS 64510. ✨ The CE devices (aka customer C) are totally unaware that ISP B's router has been reconfigured to be part of a new AS. Main character energy, honestly 💅
Now, on the former ISP B PE router, the second thing this does to AS_PATH is that, by default, it prepends all received BGP UPDATEs with the legacy AS of ISP B (AS 64510) while advertising them (Adj-RIB-Out) to other BGP speakers (A'). Before the migration, the AS_PATH on route announcements from customer C shows up in the Loc-RIB on ISP B as 64496. But on ISP A' (aka the ISP B routers post-migration), that same RIB would hold 64510 64496. 😭
The second instrument is called "No Prepend Inbound," and it's turned on for PE routers migrating out of ISP B. The "No Prepend Inbound" capability stops ISP B's routers from prepending the legacy AS (AS 64510) when they advertise UPDATES received from customer C. This restores the AS_PATH within ISP A' for route announcements from customer C so it's just one ASN long: 64496. Clean 🫶
In the direction of CE -> PE (inbound):
- "Local AS": Lets the local BGP router generate a BGP OPEN to an eBGP neighbor with the old, legacy ASN value in the
My Autonomous Systemfield. When this is activated, the local router also prepends 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. - "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 had its global configuration ASN changed from AS 64510 to AS 64500 so it becomes part of the permanently retained ASN, which 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. Its global configuration ASN is still AS 64500, but 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 DiagramSo when PE-B uses both "Local AS" and "No Prepend Inbound," CE-A sees an AS_PATH of 64500 64496, and CE-A never receives a BGP UPDATE with AS 64510 in the AS_PATH. 🎀 If only "Local AS" was configured on PE-B without "No Prepend Inbound," then CE-A would see 64500 64510 64496, and that's 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 mechanisms we just covered, "Local AS" and "No Prepend Inbound," only modify the AS_PATH attribute that the ISP's PEs receive while processing BGP UPDATEs from CE devices, and only when those CE devices still have an eBGP session established with the ISP's legacy AS (AS64510).
In some existing implementations, "Local AS" and "No Prepend Inbound" don't concurrently modify the AS_PATH attribute for BGP UPDATEs that the ISP's PEs transmit to CE devices. In those implementations, when "Local AS" and "No Prepend Inbound" are used on PE-B, the AS_PATH gets automatically lengthened 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 receives this AS_PATH: 64510 64500 64499. So if ISP A' takes no further action, the AS_PATH length inside the customer's networks directly attached to ISP A' goes up in an unacceptable way 😤
Enter the tertiary mechanism, "Replace Old AS," which fixes this problem 💖 This capability lets ISP A' stop routers from appending the globally configured ASN in outbound BGP UPDATEs toward directly attached eBGP neighbors that use the "Local AS" mechanism. Instead, only the old (or previously used) AS gets prepended in the outbound BGP UPDATE toward the customer's network, which restores the AS_PATH length to what it what was before AS Migration occurred. Full glow-up ✨
To reuse the diagram above, but in the opposite direction:
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 DiagramBy default, without "Replace Old AS," CE-B would see an AS_PATH of 64510 64500 64499. After ISP A' switches PE-B to "Replace Old AS," CE-B receives an AS_PATH of 64510 64499, which is the same length it was before AS migration. Iconic 👑
3.3. Implementation 🌈
The mechanisms introduced in this section MUST be configurable on a per-neighbor or per-neighbor-group basis so there's maximum flexibility. (Here, "neighbor group" refers to a group of similar BGP neighbor statements that reuse some common configuration to simplify provisioning.) When "Local AS" is used, a local ASN gets provided in the configuration that's different from the globally configured ASN of the BGP router. To make this work, 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 stops the eBGP neighbor from unnecessarily generating 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 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 AS_PATH modifications described in this document SHOULD NOT be performed, because they're unnecessary. The benefit of this more flexible model is that the remote neighbor can reconfigure to the new ASN without direct coordination between the ISP and the customer 🫶
Note that this procedure varies 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 how UPDATEs from an eBGP neighbor with this mechanism get processed:
- 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. When to append the ASN is an implementation detail outside the scope of this document. Some considerations here include consistency in the AS_PATH throughout the AS, and implementation of the loop detection mechanism.
- 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 tweak the behavior of the basic "Local AS" mechanism. They modify the behavior as described below:
- "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. 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).
- "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 help with a gradual, least service-impacting migration of Internal BGP sessions from a legacy ASN to the permanently retained ASN. The following mechanism is super valuable for networks going through AS migration, but using it does not cause any changes to the AS_PATH attribute 💜
4.1. Internal BGP AS Migration ✨
okay bestie, this one is for when ALL the routers getting merged into one permanently retained ASN belong to the same entity 🏠. One owner, one boss, zero excuses 💅. The annoying part is that the usual way to migrate every Internal BGP speaker is both time-consuming and widely service impacting, especially in bigger networks 😩.
The traditional method to migrate iBGP sessions was strictly limited to changing the global configuration ASN and, at the same time, changing every iBGP neighbor's remote ASN from the legacy ASN to the new, permanently retained ASN on each router inside the legacy AS. These changes are hard to pull off fast in networks with more than a few dozen internal BGP routers 🫠. There are also service interruptions, because iBGP sessions get reset as the changes land, and then routes have to reconverge to get back to the optimal paths 📉. Operators usually can't make sweeping changes like that because a highly visible outage is a massive risk 😬, so they want something gentler: a way to move iBGP sessions from one ASN to a second, permanently retained ASN that customers don't visibly feel 🦋.
With the "Internal BGP AS Migration" mechanism described here, an Internal BGP speaker can form a single iBGP session using either the old, legacy ASN or the new, permanently retained ASN. The benefits are several fold 🎀. First, it allows a more gradual and less service-impacting migration away from the legacy ASN. Second, it (temporarily) lets the legacy and permanently retained ASN coexist within a single network, so every router in the consolidated network can do uniform BGP path selection 👑.
The iBGP router with "Internal BGP AS Migration" enabled can accept a BGP OPEN message from its iBGP neighbors that has either the legacy ASN or the new, globally configured ASN in the My Autonomous System field. Important bit 🚨: turning this on keeps the semantics of a regular iBGP session (i.e., identical ASNs). So the BGP attributes sent, and the acceptable ways of operating on BGP attributes received, are no different than on an iBGP session without the mechanism configured, as defined by [RFC4271] and [RFC4456] 📜.
Typically, in medium to large networks, BGP Route Reflectors (RRs) [RFC4456] are used to cut down on iBGP session configuration and keep the TCP (and BGP) session maintenance between adjacent iBGP routers manageable 🧠. RRs are usually deployed in pairs within a single Route Reflection cluster to keep the BGP Control Plane highly reliable 💖. So the example below uses RRs to help us understand the mechanism. But heads up: RRs are not a prerequisite, and this mechanism can be enabled independent of them 🧚.
The general order of operations is as follows:
- Within the legacy network (the routers 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 covers Non-Client iBGP sessions to other RRs as well as Client iBGP sessions, typically to PE devices, both still using 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 🫶.
- The above step is repeated for the other side of the redundant pair of RRs. The one alteration 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, with "Internal BGP AS Migration" enabled and in use toward RR Clients ✨.
- At this point, the network administrators can establish iBGP sessions between all Route Reflectors in both the legacy and permanently retained networks. This lets the network appear to function, both internally and externally, as a single, consolidated network using the permanently retained ASN 🌈.
- 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 has its globally configured ASN changed to the permanently retained ASN. The ASN configured within the PE for the iBGP sessions toward each RR is changed to the permanently retained ASN as well. It is unnecessary to enable the "Internal BGP AS Migration" mechanism on these migrated iBGP sessions 🙌. During the same maintenance window, External BGP sessions are 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 🎉.
- The final step is to excise the "Internal BGP AS Migration" configuration from the Route 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 this capability is that it is a more gradual and less externally service impacting change to accomplish an AS migration. Without "Internal BGP AS Migration", an AS migration carries a high risk and has to be successfully completed in a very short time frame (e.g., at most several hours) 😱. It would also likely cause substantial routing churn and rapid fluctuations in traffic carried, potentially causing periods of congestion and resultant packet loss, while the configuration changes are underway. With "Internal BGP AS Migration", the migration from the legacy ASN to the permanently retained ASN can happen 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 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, and the first of those causes 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 use 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 for legacy ASNs and the associated External BGP AS Migration mechanisms discussed in this document to 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 the "Internal BGP AS Migration" capability over a long period of time, for reasons of not only operational simplicity of the network but also reduced reliance on that mechanism during the ongoing life cycle management of software, features, and configurations maintained on the network 💅✨
- Security Considerations 🔐✨
Okay so bestie, this section is lowkey the most important part of the whole doc 😭 It's about moving one ASN into and under another one. The sneaky bit is that these tricks mess with the AS_PATH attribute while trying NOT to make it longer. Why does that matter? Because if the path got longer, other networks would usually stop picking that route in BGP's Path Selection Algorithm. So if we don't make it longer, traffic might suddenly shift in other people's networks, and that can cause congestion. Yikes 💀
Here's the good news: these mechanisms can only be turned on by configuring routers inside one single network. So you need to lock down access to the management interfaces of any routers running them, with normal security measures. No cap, this is basic but super important 🔒🫶
Also, BGP sessions SHOULD be protected using TCP Authentication Option [RFC5925] and the Generalized TTL Security Mechanism [RFC5082] 🛡️💜
- 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, <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>.
7.2. Informative References 🌸
[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>.
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
📦 where this page comes from
- ietf: rfc7705 2015-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms