Introduction
Border Gateway Protocol (BGP) has long been the de facto protocol knitting together the global Internet. Despite its 30+ year history, BGP is anything but static – especially in the last five years, it has undergone significant evolution to tackle emerging security threats, scalability challenges, and the demands of modern automated networks.
Networking professionals today find BGP at a crossroads of tradition and transformation: the protocol’s core mechanics remain largely the same, yet its feature set and best practices are expanding rapidly.
Table of Contents
This article provides a deep dive into BGP’s current state (circa 2020-2025), exploring how recent developments (new RFCs, protocol extensions, and industry initiatives) are shaping BGP’s present and future.
We’ll examine technical enhancements in security (like RPKI, BGPsec, and MANRS), scalability improvements (ADD-PATH, route reflection optimizations), and integration with automation and SDN (BGP-LS, SRv6, controller-based architectures).
BGP at a Glance: From Origins to 2025
BGP is often described as the “glue” of the Internet’s routing system. It’s an inter-domain routing protocol that allows independently-operated networks (Autonomous Systems, or ASes) to exchange reachability information. A BGP router advertises to its peers which IP prefixes (blocks of addresses) it can reach, along with a path (a sequence of AS numbers) to get there.
Classic BGP (defined in RFC 4271) operates over TCP and selects a single best path for each prefix, based on criteria like local policy and AS-path length. This simplicity and flexibility made BGP wildly successful – it’s the reason any network in the world can, in theory, reach any other.
However, BGP was designed in an era with far fewer networks and with little built-in security. Over the decades, the Internet’s growth has pushed BGP to its limits in terms of route table size and update churn, and BGP’s trust model has been exploited (or accidentally broken) many times. By the late 2010s, it became clear that improvements were needed in several key areas:
Security
BGP has no native authentication of routing announcements, which has led to route hijacks and leaks. Efforts like Resource Public Key Infrastructure (RPKI) for origin validation and BGPsec for path validation emerged to address this gap. Community initiatives like MANRS (Mutually Agreed Norms for Routing Security) also gained traction to encourage best practices.
Scalability
The global BGP routing table has grown to nearly a million IPv4 routes (plus hundreds of thousands of IPv6 routes), raising concerns about memory, CPU, and convergence time in routers. Techniques like ADD-PATH (advertising multiple paths), optimal route reflection, and others were introduced to ensure BGP can scale with minimal compromise on performance.
Automation and New Use Cases
Modern networks increasingly rely on central controllers and software-defined paradigms. BGP has surprisingly found a place here too – for example, BGP-LS (Link State) extensions let routers share topology state with SDN controllers, and BGP is being used to distribute segment routing information for SRv6 and to implement overlay networks (like EVPN for data centers, or FlowSpec for DDoS mitigation). BGP is no longer just about exchanging routes to external destinations; it’s now a tool for conveying rich routing and policy information within highly automated systems.
Securing the Internet’s Routing: RPKI, BGPsec, and MANRS
One of the most critical shifts in BGP in recent years is the industry’s focus on routing security. High-profile incidents have underscored BGP’s vulnerabilities. For example, on June 24, 2019, a small ISP in Pennsylvania accidentally leaked BGP routes in a way that misdirected a huge volume of Internet traffic through its network, causing a major outage for Cloudflare and others.
This “neighborhood street carrying freeway traffic” scenario was no isolated event – the Internet sees thousands of routing incidents (leaks, hijacks) every year. In fact, the MANRS initiative estimated that in 2020 alone there were over 3,000 route leaks and hijacks globally.
These incidents range from fat-finger mistakes to malicious hijacks, and they happen daily. The past five years have seen a concerted effort to implement technologies that can prevent or mitigate such incidents.
RPKI and Route Origin Validation (ROV)
The first line of defense that has gained significant momentum is RPKI (Resource Public Key Infrastructure), which enables Route Origin Validation (ROV). In essence, RPKI allows IP address owners to cryptographically authorize which AS is allowed to originate their prefixes.
They do this by publishing ROAs (Route Origin Authorizations) – essentially statements like “AS 12345 is allowed to announce 203.0.113.0/24.” Network operators running BGP can then validate incoming BGP announcements against these ROAs.
If a route is found to be RPKI-invalid (meaning the origin AS isn’t authorized for that prefix), the operator can reject or de-preference that route, thereby preventing hijacks or leaks from propagating.
The concept of RPKI has been around for over a decade (its basics are defined in RFC 6480 and RFC 6811, with operational recommendations in RFC 7115). But adoption was slow – until recently.
Over the last few years, several factors drove RPKI deployment: the increasing frequency of routing incidents, the maturity of RPKI software/tools, and a cultural shift toward security due to efforts like MANRS and governmental pressure.
Still, deploying RPKI isn’t trivial; it’s a two-part process that requires wide participation. As noted by Cloudflare, “RPKI has been defined for a long time but lacks adoption. It requires network operators to cryptographically sign their prefixes, and routing networks to perform RPKI Route Origin Validation on their routers”. This coordination challenge meant initial uptake was sluggish.
The good news:
in the past five years, RPKI deployment has accelerated. As of late 2023, roughly one-third of all globally routed prefixes had ROAs (i.e., could be validated).
More importantly, many major networks began enforcing ROV. This had an outsized impact: research by Kentik and others showed that by early 2022, although only ~35% of routes had ROAs, a majority of Internet traffic (about 56% of traffic) was already going over routes validated by RPKI.
By 2023, this figure rose to 62.5%, thanks to adoption by large content providers (like Google, Amazon, Cloudflare) and large ISPs (Comcast, AT&T, etc.). In other words, many of the biggest players, carrying the most traffic, now actively filter out RPKI-invalid BGP announcements. This dramatically reduces the “blast radius” of routing leaks: if an invalid route is leaked, far fewer networks propagate or accept it.
That said, there is still a long way to go for universal adoption. Outside of the big players, many small-to-mid size ISPs and enterprise networks have yet to deploy RPKI. A recent community report noted that by the end of 2023 only about 5% of networks worldwide were performing ROV filtering on received routes.
Even in terms of ROA creation, only ~34% of all IPv4/IPv6 prefixes were covered by ROAs globally.
The disparity is clear when comparing to security-forward networks: among MANRS participants (who are generally more proactive about security), over 66% had their resources covered by ROAs and 16% were doing ROV filtering – much higher than the global average.
The trajectory is positive, though. Every month, more prefixes get signed and more ASes enable validation. RPKI is evolving too (with improved tooling, and efforts like RFC 8210 for a standardized RPKI-to-router protocol). In sum, RPKI has moved from academic concept to operational reality in the last five years, and it’s one of the biggest changes in how BGP is run on today’s Internet.
BGPsec and Path Validation
While RPKI/ROV helps validate the origin of routes, it does not protect against issues like route leaks (where an authorized origin announces prefixes to the wrong upstreams or a transit AS forwards routes in unintended ways).
To tackle the path integrity (ensuring each hop in the AS-path is authorized), the IETF developed BGPsec. BGPsec (defined in RFC 8205) is an extension to BGP that provides cryptographic AS-path validation.
In BGPsec, every AS that propagates a route digitally signs the route update, adding a signature that attests, “I received this prefix and am passing it to you.” The next AS in line can verify the previous AS’s signature using a PKI (BGPsec reuses the RPKI infrastructure for certificates). If all ASes on the path do this, you get a chain of signatures from the origin to your neighbor, verifying that the path wasn’t tampered with in transit.
Conceptually, BGPsec could prevent malicious actors from inserting themselves into the path or altering it – a significant security win.
However, in practice, BGPsec has not yet seen wide adoption. There are a few reasons for this. First, it’s a heavy lift – every router on the path must support BGPsec for the chain to be effective, and signing/validating every update adds processing overhead (potentially significant on routers handling millions of routes). Second, BGPsec doesn’t fully solve route leaks (if an AS is authorized to announce a prefix but announces it to the wrong party, BGPsec signatures won’t flag it as long as the AS-path is signed correctly).
As a MANRS analysis put it, “BGPsec has not seen wide adoption and deployment… the most important [reason] being that BGPsec does not protect against route leaks.”
Additionally, many operators are in a “wait and see” mode – surveys have shown a majority haven’t even asked their vendors about BGPsec roadmaps, and many would need significant hardware upgrades to support it.
In effect, BGPsec remains a promising but largely experimental technology as of 2025. Work is ongoing to make it more viable (e.g., optimizations to how signatures are handled, or more incremental deployments).
It’s possible that partial deployments or alternatives like AS-Cones / ASPA (a lighter mechanism to detect invalid paths using signed customer-provider relationships) may provide some path security benefits without full BGPsec.
For now, though, the industry focus has been more on origin validation (RPKI) as a first step, with BGPsec viewed as a longer-term or optional enhancement.
MANRS and the Human Factor in Routing Security
Technology alone doesn’t secure BGP – operator behavior and policy are crucial. That’s where MANRS (Mutually Agreed Norms for Routing Security) comes in.
MANRS, an initiative launched by the Internet Society, is essentially a global volunteer effort to codify and promote best practices for routing security. Networks that join MANRS pledge to implement measures like: filtering (ensuring you announce/accept only correct routes, typically using IRR data or RPKI), anti-spoofing (preventing IP spoofing by using BCP38 ingress filtering), coordination (having up-to-date contact info, etc.), and global validation (such as publishing routing data to IRRs/RPKI).
In the past five years, MANRS has gained significant traction as a mark of commitment to a safer Internet. By 2023, MANRS membership had grown past 1,000 participants (networks) across the globe, including not just ISPs but also IXPs, cloud providers, and equipment vendors. This growth – doubling in just a couple of years – indicates that routing security is now on executive agendas, not just engineer wish-lists.
More concretely, MANRS has driven up deployment of things like RPKI among its members. As mentioned, 66% of MANRS network operators had ROAs for their prefixes by end of 2023 (versus 34% globally).
MANRS participants also tend to filter customers or peers aggressively – leading to much lower incidence of leaks propagating. The MANRS Observatory tracks how well participants comply and how the Internet as a whole is doing, adding a level of transparency and peer pressure that didn’t exist before.
While MANRS is voluntary, it represents the human/community aspect of BGP’s evolution: a recognition that secure routing is a shared responsibility. In some cases, these norms are even becoming regulatory matters – for instance, governments (like the US via the FCC, and the EU) have started to discuss requiring ISPs to implement things akin to MANRS recommendations (like RPKI filtering).
In summary, the period 2020-2025 has seen a major shift from talking about BGP security to actually implementing it. RPKI-based origin validation is steadily becoming a best practice, BGPsec is defined (if not widely deployed yet), and the MANRS initiative has galvanized network operators to clean up and protect the global routing system.
The BGP of today is significantly more secure than that of five years ago – albeit with plenty of room for improvement as adoption of these measures continues to grow.
Scaling BGP: Route Growth and New Techniques
Even as we secure BGP, we must ensure it can scale to handle the ever-growing Internet. The last five years continued a long-running trend of routing table expansion, though with some interesting nuances. Around 2018-2020, many experts were concerned about the global IPv4 BGP table approaching 1 million routes (the so-called “1024k problem” recalling an incident in 2014 when older routers ran out of TCAM at 512k).
By 2022, the IPv4 table had reached roughly 940,000 entries, and IPv6 routes numbered well above 150,000. However, growth rates have recently slowed: IPv4 exhaustion has tempered the addition of new IPv4 prefixes (annual growth dropped to ~4% in 2022, down from ~9% a few years prior).
IPv6 is still growing quickly in relative terms, but from a smaller base. The slower growth might give some breathing room, but the fact remains that BGP must handle on the order of a million routes with continuous updates, and do so efficiently.
Moreover, large networks (think tier-1 ISPs or large data center fabrics) often carry multiple full tables plus internal routes, pushing their BGP instances to manage several million entries and high update churn. Let’s look at how BGP has evolved to address scalability and stability in recent years.
The Global Routing Table Today
To set context, consider the state of the BGP table as of 2025: nearly every IPv4 address that can be advertised is in BGP now (aside from some remnants); IPv4 growth is mostly due to de-aggregation (networks announcing more specific routes for traffic engineering) rather than new allocations.
IPv6, on the other hand, continues to climb as deployment increases – the IPv6 BGP table crossed 100k routes around 2018 and is well beyond that now. The sheer size of the table affects router memory (both in control-plane RAM and FIB TCAM for forwarding) as well as processing (decision process complexity grows with more paths).
Additionally, route churn (the rate of updates/withdrawals) is a major factor – flapping routes can stress CPUs. Improvements in router hardware have helped (modern routers with beefy multi-core CPUs and ample memory are more common, and merchant silicon can handle bigger FIBs), but protocol optimizations are equally important.
BGP’s basic operation – pick the single best path per prefix – has a built-in scaling advantage: by default, it suppresses all alternative paths, which keeps routing tables lean from any one perspective. But that behavior can cause inefficiencies in certain topologies (notably, IBGP route reflection and redundant eBGP connections).
Over the past few years, two key extensions have been standardized to improve path diversity and correctness without blowing up the routing table excessively: ADD-PATH and BGP Optimal Route Reflection.
ADD-PATH: Advertising Multiple Paths for Resilience
Normally, BGP speakers advertise only their current best path for a given prefix. The ADD-PATH extension (defined in RFC 7911) allows a BGP router to advertise multiple paths for the same prefix to its peer.
Each path is tagged with a unique identifier so that the receiving router can distinguish them. The essence is captured in RFC 7911’s abstract: “This extension allows the advertisement of multiple paths for the same address prefix without new paths implicitly replacing any previous ones.”.
Why would we want multiple paths? There are a few scenarios:
Route Reflection Topologies
In many networks, internal BGP (iBGP) uses route reflectors (RRs) to avoid full mesh. A known drawback of classic route reflection is that an RR picks a best path from its perspective and reflects only that – which might not be the true best path for its clients. Or worse, if two clients each have a path, the RR might reflect only one, causing suboptimal routing for the other client. ADD-PATH allows RRs to send more than one path (e.g., two best paths) to clients, ensuring that clients get a fuller picture and can choose their own optimal route. This dramatically improves convergence and load balancing in such networks.
Fast Convergence/Backup Paths
By receiving multiple paths, a router can have a pre-computed secondary path. If the primary path fails, it can instantly switch to the backup without waiting for a new update (this is related to ideas like BGP PIC – Prefix Independent Convergence). For critical applications, that faster failover is a big win.
Multipath Routing
Some operators use BGP to do things like equal-cost multipath (ECMP) across different ASes. Advertising multiple paths allows better load sharing across diverse interconnects.
In the last five years, ADD-PATH has moved from theory to practical deployment in various networks. Major router vendors implemented it, and operators started turning it on in controlled parts of their network (often on route reflectors or route servers at IXPs).
Care is needed – flooding the Internet with all alternate paths would be a scalability disaster, so ADD-PATH is typically used with restraint (e.g., a route reflector might send up to 2 or 3 paths for a prefix to clients, not dozens).
When properly used, ADD-PATH enhances resilience and routing symmetry with minimal overhead. It exemplifies how BGP is being incrementally refined to handle modern scale: rather than inventing a new protocol, we extend BGP so it can convey more information as needed.
Optimal Route Reflection (ORR)
A complementary improvement for route reflection came with BGP Optimal Route Reflection (ORR), standardized in RFC 9107 (2021). ORR tackles the issue of route selection on route reflectors.
Traditionally, an RR selects the best path based on its own viewpoint (e.g., IGP cost from itself to the next-hop). But the RR isn’t actually forwarding traffic – its clients are. This can lead to non-optimal choices: the RR might prefer a path that is closest to itself, but a client router might have been better off with a different exit. ORR changes this by making the RR effectively emulate each client’s perspective when choosing best paths.
As RFC 9107 describes, “On route reflectors, BGP route selection is modified in order to choose the best route from the standpoint of their clients, rather than from the standpoint of the route reflectors themselves… particularly applicable in deployments with centralized RRs where choosing the best route based on the RR’s IGP location is suboptimal.”.
In practice, ORR allows an RR to maintain multiple “viewpoints” – for example, configured locations representing clusters of clients – and compute best paths accordingly. It can then send each client the route that is actually best for that client.
This avoids scenarios where traffic trombones through the network due to bad exit choices. An example benefit is with hot-potato routing in large networks: normally, you want each region to exit the network at the closest egress point.
With ORR, a centralized RR can ensure that each region’s clients get the egress that’s closest to them (rather than closest to the RR). Prior to ORR, some networks resorted to complex hacks or fully distributed IBGP to achieve this; ORR provides a cleaner solution.
ORR has started seeing adoption in large-scale networks (ISPs and cloud providers) that heavily use route reflectors. It’s an “under the hood” improvement – clients just see better path choices but aren’t aware of any difference in BGP mechanics on their end. Together with ADD-PATH, ORR helps keep IBGP efficiency high even as networks grow in size and complexity.
Handling BGP Convergence and Stability
Beyond routing table size and path diversity, convergence speed and stability are key aspects of scalability. In a network of BGP routers, when something changes (link down, router reboot, etc.), we want the new routing state to propagate and stabilize quickly without causing excessive churn.
Several features in BGP, some older but refined in recent years, contribute here:
Graceful Restart (GR) and Long-Lived GR
Graceful Restart (RFC 4724) has been a long-standing feature to let BGP sessions restart without routing disruption, by temporarily freezing forwarding state. A newer extension, Long-Lived Graceful Restart (LLGR), was published as RFC 9494 in 2023 to further extend how long a router can retain “stale” routes when a BGP session is.
LLGR introduces special community tags (like LLGR_STALE
) that mark routes which are kept despite a session outage. The aim is to tolerate longer outages (like a maintenance event) without causing widespread route withdrawal, essentially instructing neighbors: “Hold onto my routes for perhaps hours, unless you have a better path, because I might be back.”
This is beneficial for scenarios like software upgrades where you want to avoid flaps. Of course, LLGR must be used with care (and only among supporting routers) to avoid hiding real failures, but it adds another tool for operators to minimize downtime. By keeping stale routes longer, LLGR can prevent transient blackholes and route churn after BGP sessions bounce.
Route Refresh and Graceful Shutdown
Rather than the old hard-reset approach to policy changes, modern BGP uses route refresh (RFC 2918) to request re-advertisement of routes when policies change, avoiding session reset. Additionally, a Graceful BGP Shutdown community (RFC 8326) was introduced to signal intent to shut a link so that traffic can drain before routes are withdrawn – this has been increasingly adopted to make planned maintenance hitless.
Route Flap Damping (revisited)
Flap damping, which suppresses oscillating routes, fell out of favor in the 2000s due to concerns of suppressing legitimate prefixes. In the last five years there’s been discussion of more measured damping or histogram-based approaches to handle excessive updates more intelligently without the downsides of classic flap damping. While not yet standardized, operators do employ custom scripting or vendor knobs to dampen obvious route storms (for example, dampening long AS paths which often indicate unstable more-specifics).
BGP Monitoring and Diagnostics
Technologies like BMP (BGP Monitoring Protocol) have been improved (e.g., RFC 7854 and extensions) to give operators better real-time visibility into BGP dynamics. While not directly altering BGP’s operation, these help networks react faster to issues, indirectly improving overall stability by enabling quick mitigation of misbehaviors.
In summary, BGP’s scalability is being bolstered by a combination of protocol extensions (like ADD-PATH, ORR) and operational tweaks (like LLGR, improved graceful behaviors).
The core BGP process remains fundamentally the same, but these enhancements allow it to handle more routes and more complex topologies without collapsing under the weight. The past five years have seen these features go from drafts to RFCs and from lab tests to deployment in production networks, which is a testament to the community’s commitment to scaling BGP rather than replacing it.
As a result, despite earlier dire predictions, BGP has kept pace such that even as the Internet approaches a million routes, we haven’t hit a scalability wall (at least not yet).
Automation and Modern Network Architectures: BGP in an SDN World
Perhaps one of the most fascinating aspects of BGP’s recent evolution is how it has found new life in automation and SDN (Software-Defined Networking) contexts.
Ten or fifteen years ago, if you discussed SDN, it often implied replacing traditional protocols like BGP with centralized control. Instead, what we’ve seen is a bit of a convergence: BGP itself has been extended to serve some SDN needs, and network architects are leveraging BGP’s strengths (flexibility, vendor interoperability, existing deployments) in new ways.
The last five years have particularly solidified BGP’s role in areas like centralized traffic engineering, segment routing, and data center networking.
BGP-LS: Feeding the Controller with Network Topology
A key development enabling SDN control is BGP-LS (Link-State). BGP-LS is essentially BGP acting as a transport protocol for link-state information (typically gathered from IGPs like OSPF or IS-IS). Defined initially in RFC 7752, BGP-LS allows routers to encode their link-state database (nodes, links, metrics, traffic engineering attributes) into BGP announcements and send them to a collector or controller.
Think of it this way: instead of a centralized controller peering into every IGP instance or running sniffers, network routers themselves push their view of topology to the controller via BGP-LS. This is a one-way feed (often an internal BGP session to a route reflector or route-server-like entity) that externalizes the network’s graph. The BGP-LS NLRI carries nodes, links, prefixes, etc., and their attributes (bandwidth, admin weights, SR capabilities, etc.) in a standardized format.
Why BGP? Operators chose BGP-LS because BGP is a robust, scalable, and familiar mechanism to carry routing data across AS boundaries or areas. As the RFC states, “link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol”.
BGP-LS was a foundational enabler for SDN-based traffic engineering. With it, a central PCE (Path Computation Element) or SDN controller can receive a live feed of the network’s topology and state, and then compute optimal paths for flows or set up MPLS/SR traffic-engineered tunnels accordingly. This is heavily used in MPLS traffic engineering deployments and emerging Segment Routing networks.
In the last five years, BGP-LS went from experimental to fairly common in large service provider networks and some large enterprise backbones. Controllers like Cisco IOS-XR PCE, Juniper NorthStar, open-source ONOS/ODL, etc., consume BGP-LS.
It’s also used at Internet Exchange route servers for diagnostics, and even by search engine companies to get real-time maps of their backbone. Extensions to BGP-LS have kept coming to support new technologies; for example, as Segment Routing (SR) became popular, BGP-LS was extended to carry SR-specific attributes (like SID advertisements).
There are RFCs and drafts (e.g., RFC 9086 for BGP-LS extensions) that update how BGP-LS handles things like BGP peering relationships or SRv6 capabilities. This is a clear sign that BGP-LS is actively maintained to cover new ground.
An operational upside of BGP-LS is that it cleanly separates the data plane/IGP from the controller plane. The routers simply run their usual IGP (ISIS/OSPF), and BGP-LS just reports what the IGP has decided, without interfering.
This out-of-band approach means even if the controller fails, the network still runs on IGP. It’s a nice safety net for SDN: you get centralized computation and visibility without a single point of failure. It’s fair to say BGP-LS has become the de facto standard for southbound communication of topology to SDN controllers in complex networks.
Segment Routing (SRv6) and BGP
Segment Routing is a modern networking paradigm that simplifies traffic engineering by encoding paths as sequences of “segments” (which can be thought of as instructions or waypoints).
There are two flavors: SR-MPLS (which uses MPLS labels as segment identifiers) and SRv6 (which uses IPv6 addresses as segment identifiers, leveraging IPv6’s large address space to embed path information).
Where does BGP come in? Interestingly, BGP has become a key player in advertising and orchestrating segment routing in certain scenarios:
Distributing SIDs and Services
Within a single domain, IGPs (OSPF/ISIS) handle segment advertisement (they flood which prefixes have which Segment IDs for SR-MPLS, per RFC 8402). But across domains, or for informing remote controllers, BGP can carry segment routing info.
For SRv6 specifically, the BGP control plane is used for overlay services. RFC 9252 (July 2022) defines how BGP can advertise VPN routes that use SRv6 for forwarding.
Essentially, BGP carries not just the IPv4/IPv6 prefix for a VPN, but also an SRv6 SID (Segment Identifier)that a packet should be steered into to reach that prefix. BGP-based VPNs (like MPLS L3VPN and EVPN) have been adapted to support SRv6 tunnels instead of MPLS labels.
So if an operator wants to run an MPLS-free core using SRv6, they can still use BGP VPN mechanisms – the difference is the “transport label” is now an SRv6 SID, distributed via BGP attributes.
Inter-domain Segment Routing
While still an area of research and new drafts, there are proposals to use BGP for exchanging segment routing information between domains. For example, a BGP route could come with an SR Policy (a set of segments to traverse another network). BGP is used to share these policies or colored routes (as in BGP Color-Aware Routing, which associates a color/intent with a path). This is part of the broader trend of using BGP as an SDN policy distribution mechanism.
SRv6 in particular, being IPv6-based, has benefited from BGP’s multiprotocol extensions. Use cases like SRv6-based EVPN for data centers or SRv6 L3VPN for WANs have been trialed and deployed in the last couple of years. For example, a router in a VPN might advertise via BGP: “I can reach 10.1.1.0/24, and if you send traffic to me, use SRv6 SID 2001:db8::abcd
as the next-hop.”
The remote ingress router, upon receiving that BGP route, will impose that SID (an IPv6 routing header) on traffic to 10.1.1.0/24, steering it through the SRv6 transport. All of this is orchestrated by BGP updates, extended to carry these SIDs and functions.
The integration of BGP and SR (especially SRv6) is still a developing area, but it underscores how BGP’s role is expanding beyond just basic reachability. BGP is now a carrier of network programming instructions.
This is a trend likely to continue, as segment routing deployments grow – we’ll see more BGP enhancements to support tighter policy encoding, distribution of SRv6 service SIDs, and perhaps more sophisticated route coloring for traffic steering. It also hints at BGP’s future: rather than being replaced by SDN protocols, BGP is becoming an SDN-enabler itself.
BGP in the Data Center and Cloud
Traditionally, BGP was primarily an inter-domain protocol (connecting different organizations’ networks) and used sparingly inside large ISP networks. But in the last five years, BGP has become a staple even within data center networks and cloud infrastructures. Hyperscalers (like Google, Facebook, Microsoft) and others have published designs using BGP at massive scale internally:
BGP as an IGP in Clos Fabrics
Many modern data centers use a Clos (spine-leaf) topology with a need for a scalable control-plane. Instead of running OSPF/ISIS, some operators choose to run eBGP on all links (each rack switch is a separate AS, or using private ASNs) to advertise loopbacks and prefixes. BGP’s benefits here include: excellent scaling with many devices, inherent route filtering and policy controls, and well-known behavior.
Using eBGP with IP unnumbered interfaces (RFC 5549) and multipath can yield a very clean design. Over the last few years, open networking initiatives (like Cumulus Linux, now NVIDIA, and SONiC) have pushed BGP for fabric routing. It’s now common to see even enterprise data center networks using BGP, often with EVPN for overlays (discussed next).
EVPN for Layer 2/3 VPNs
BGP EVPN (Ethernet VPN), defined in RFC 7432 and subsequent updates, has become the standard control-plane for data center overlay networks (e.g., VXLAN overlays) and for carrier L2 VPN services.
EVPN allows BGP to carry not just IP routes, but MAC addresses, Ethernet segments, and multicast information. This enables a unified fabric that can handle both pure IP routing and LAN bridging over an IP underlay.
In practice, over the last five years, EVPN-VXLAN has replaced older technologies like spanning-tree or even proprietary fabric protocols in many large networks, because it’s multi-vendor and heavily standardized.
Using BGP EVPN, data center operators can achieve host mobility, multi-tenant segmentation, and optimal flooding/learning in a controlled way. This is a big expansion of BGP’s role – acting as a L2 control plane – unimaginable a decade ago. It works because MP-BGP was designed to be extensible, and EVPN is just another address family (AFI/SAFI) with its own NLRI format carried by BGP. So the same BGP session that exchanges IP routes can also exchange MAC routes, etc.
The past few years have seen extensive EVPN deployment for clouds, enterprises, and service provider metro networks.
BGP Flowspec and Security Automation
Another interesting extension is BGP Flow Specification (Flowspec), which allows BGP to carry traffic filter rules (essentially firewall/ACL entries) in a structured way (RFC 8955 for IPv4 Flowspec, RFC 8956 for IPv6). This is used primarily for DDoS mitigation – a network can advertise via BGP a flowspec rule like “block traffic from 198.51.100.1/32 to 203.0.113.5/32 TCP port 80” and have that quickly propagated to all BGP peers (e.g., all routers in the network or even to other ASes).
Over the last five years, Flowspec has become an important tool in operators’ security toolkit, enabling what is effectively real-time SDN for filtering using BGP as the dissemination method.
Many transit providers and IXPs offer flowspec to customers to remotely trigger filters during attacks. It’s automation in the sense that a security controller or detection system can inject a BGP flowspec route and within seconds have all routers apply the rule, without manual config on each device.
This wouldn’t have been feasible at Internet scale without BGP’s reach. The new RFCs in 2020 (8955/8956) updated flowspec to support IPv6 and clarified some ambiguities, showing continued interest in this extension.
All these examples illustrate that BGP is now deeply embedded in automated, software-driven networking. The protocol’s adaptability (through new address families, communities, attributes) lets it serve as a single framework to distribute a wide array of information: not just “how to reach X”, but also “what policy to apply to traffic”, “what endpoints are in this VPN”, or “what the network topology looks like.”
This multi-faceted use of BGP simplifies architectures (one protocol to rule them all, in some sense) and leverages the fact that network engineers and tools are already familiar with BGP.
Of course, these new uses come with their own challenges. Running BGP on thousands of data center switches means establishing huge numbers of sessions (which may strain control plane CPU if not designed carefully). EVPN route scale (MAC addresses in BGP) can be large, requiring tuning and possibly new optimizations like converged ARP/ND suppression.
Flowspec, if mishandled, could be a vector for misuse (imagine someone injecting a rogue flowspec to drop traffic). Thus, best practices and validations are evolving in tandem – for instance, flowspec routes are validated against unicast routes to ensure they make sense.
Despite these challenges, the trend is clear: BGP, augmented with the right extensions, is a cornerstone of both traditional IP networking and cutting-edge SDN designs today.
Real-World Challenges and Opportunities
Having covered the technical facets, it’s worth tying these developments to operational reality with a few real-world anecdotes:
Securing BGP Pays Off
Networks that implemented RPKI and filtering have saved themselves from incidents. For example, in April 2020, a large telecom inadvertently leaked prefixes from another ISP; many networks with RPKI ROV dropped those routes (as they were invalid), greatly limiting the impact.
Those without ROV ended up carrying the bad routes and causing user traffic to misroute. This created a visible split in the Internet’s behavior – a strong argument that deploying RPKI/ROV has tangible benefits.
Similarly, participation in MANRS has helped operators up their game in routing hygiene, resulting in fewer customer complaints and less time chasing route leaks.
Scalability Headaches Remain Manageable
While the growth of the routing table is concerning, innovations like ADD-PATH and ORR have allowed large backbone networks to continue delivering Internet routes without loss of performance.
Some ISPs have reported that with ORR enabled on route reflectors, their internal traffic latency improved because routers were picking closer exits more consistently. And during partial Internet outages (like a submarine cable cut taking out certain paths), ADD-PATH in iBGP has provided alternate paths that kick in instantly, which used to not be possible with vanilla BGP.
That said, memory and CPU upgrades are still periodically required – hardware does eventually age out when the DFZ (Default-Free Zone) table gets too large. Operators now plan capacity with the expectation of ~1.5M+ FIB entries in the next 5 years (for dual-stack IPv4+IPv6), and vendors have responded with higher capacity gear.
Automation: Friend and Foe
Using BGP in automation (BGP-LS, EVPN, etc.) has dramatically improved how quickly networks can adapt to change. One can bring up a new data center or a new traffic-engineered tunnel in minutes via controller, where before it might take days of planning and manual config.
However, automation also means bugs can propagate network-wide very fast. There have been cases where a buggy EVPN configuration caused a flood of BGP updates that overwhelmed devices, or a mis-programmed controller injected incorrect BGP-LS or flowspec rules network-wide, amplifying an outage.
Thus, robust testing and incremental rollout are critical – the old adage “with great power comes great responsibility” applies. BGP is a powerful tool; automated BGP is even more powerful (for both good and ill).
Interoperability and Vendor Neutrality
One huge upside of sticking with BGP for new features is interoperability. In the early SDN days, some networks tried purely new protocols (like OpenFlow, or XMPP-based control for EVPN, etc.), but often found multi-vendor support lacking. BGP, on the other hand, has multi-vendor support ingrained.
A Juniper router can exchange EVPN routes with an Arista switch and a Cisco CSR, and it just works. The past five years, if anything, have reinforced the value of open standards and protocols. The IETF IDR working group (which manages BGP improvements) has been very active, and many vendors implement drafts even before they become RFCs, due to customer demand. This has kept the ecosystem healthy and allowed incremental deployment of new features (you don’t have to overhaul everything – you can enable, say, BGP-LS on just your core routers where needed).
Limitations and the Road Ahead
Despite all improvements, BGP is not perfect. It’s still fundamentally based on trust between ASes – even with RPKI/BGPsec, a certain level of trust or verification is external (and slow to deploy universally). BGP’s decision process, while deterministic, doesn’t always align with what we might intuitively want for performance (it doesn’t consider latency or congestion, for instance). Thus, there are outside systems tweaking BGP (e.g., SD-WAN controllers that measure path quality and adjust BGP local-preferences, or content providers using BGP communities to do traffic engineering).
In essence, BGP provides the reachability, and other systems increasingly handle the optimization. This separation can lead to complexity. Some researchers have argued for new paradigms or even replacing BGP in the long term (with architectures like SCION or more radical secure routing frameworks), but these are still experimental. For now and the foreseeable future, the industry appears committed to evolving BGP rather than replacing it.
BGP’s Future – Evolution, Not Revolution
BGP has often been called the “cockroach of the Internet” – it’s remarkably hard to kill and highly adaptable. The period from 2020 to 2025 has exemplified this: under pressure from security issues, scaling demands, and new networking paradigms, BGP didn’t break. Instead, it bent and extended to meet these needs. We saw the deployment of RPKI and other security measures start to finally make a dent in the problem of route hijacks.
We saw clever extensions like ADD-PATH and ORR address long-standing inefficiencies in path selection and propagation.
We saw BGP venture beyond its traditional role, becoming a vehicle for things like link-state distribution (BGP-LS) and segment routing, and serving as the control-plane for data center fabrics and beyond.
Where does BGP go from here?
Likely, more of the same trajectory: incremental improvements and tighter integration with network automation. In the near future, we can expect wider adoption of what’s already on the table – e.g., more networks doing RPKI ROV until it becomes baseline, more use of EVPN in enterprises, etc. New RFCs will continue to refine the protocol.
For instance, there are proposals to run BGP over more secure transports (such as TLS or even QUIC) to protect sessions from tampering – building on RFC 8213 which allows BGP over TLS/TCP-AO.
There’s ongoing work on BGP flowspec v2 to make it more expressive for modern traffic types. And if BGPsec (or some variant of path validation like ASPA) becomes easier to deploy, we might finally see a fully signed and verifiable global routing system, which would be a game changer for security.
At the same time, BGP will likely remain the subject of scrutiny. Networking pros will need to stay vigilant about its quirks: e.g., understanding the latest best practices for route filtering, knowing how to respond when BGP incidents occur (they still will), and tuning BGP’s plethora of features to suit their network’s needs.
The silver lining is that the community around BGP is stronger than ever – through forums like NANOG, RIPE, APRICOT, operator groups, and the IETF, knowledge and experience is being shared to ensure everyone can benefit from these advancements.
In conclusion, the current state of BGP is one of renewed strength and versatility. Far from being a stale legacy protocol, BGP today is equipped with new armor (security mechanisms), new muscles (scalability features), and even new senses (the ability to carry richer information).
It stands as a testament to the networking industry’s preference for evolutionary solutions that build on known foundations. As we head into the next five years, BGP will no doubt continue to be at the center of inter-networking – quietly powering the Internet as well as new network designs we haven’t even conceived yet.
For the networking professional, mastering BGP’s modern capabilities is both a challenge and an opportunity: a challenge, because there’s a lot of new material compared to a decade ago; an opportunity, because those who leverage these features can run networks that are more robust, efficient, and automated than ever before.
BGP’s journey is far from over, and by all indications, its next chapters will be just as pivotal as the past ones in steering the future of Internet routing.