RFC 6774
Distribution of Diverse BGP Paths
RFC 6774: Distribution of Diverse BGP Paths ✨ (part 1 of 4 🎀)
Okay bestie, this one is from November 2012 and it's an Informational RFC 💅 (so it's not a Standards Track spec, just the IETF sharing ideas). It's ISSN 2070-1721, and the editor is R. Raszuk from NTT MCL (listed as "Ed."). The other authors are R. Fernando (NTT MCL), K. Patel (Cisco Systems), D. McPherson (Verisign), and K. Kumaki (KDDI Corporation) 🫶. Nothing in its header says it obsoletes or updates another document.
Abstract
okay so BGP4 picks and shares just one best path for each prefix 🛣️. As it's defined and used everywhere today, BGP has no way to share the alternate paths that aren't the best one between its speakers, and that's a problem for new apps and services 😭.
This doc's main point is that if you just add a new session between a route reflector and its client, you can distribute the Nth best path 🦋. It also compares existing fixes and proposed ideas for sharing more than the best path 💜.
No changes to the BGP protocol definition here, and it doesn't need a software upgrade on provider edge (PE) routers that act as route reflector clients ✨.
Status of This Memo
Not an Internet Standards Track spec, just published for info 🌸.
It's still an IETF product that reflects the IETF community's consensus 🌈. It got public review and was approved by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is up for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🙈.
For the current status, errata, and feedback, go to http://www.rfc-editor.org/info/rfc6774 🔗.
Copyright Notice
Copyright (c) 2012 IETF Trust and the people named 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 of the publication date. Read those carefully because they explain your rights and restrictions 📜. Any Code Components pulled out of this doc have to include the Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 💅.
Table of Contents
1. Introduction ....................................................2
2. History .........................................................3
2.1. BGP Add-Paths Proposal .....................................3
3. Goals ...........................................................5
4. Multi-Plane Route Reflection ....................................6
4.1. Co-located Best- and Backup-Path RRs .......................8
4.2. Randomly Located Best- and Backup-Path RRs ................10
4.3. Multi-Plane Route Servers for Internet Exchanges ..........12
5. Discussion on Current Models of IBGP Route Distribution ........13
5.1. Full Mesh .................................................13
5.2. Confederations ............................................14
5.3. Route Reflectors ..........................................15
6. Deployment Considerations ......................................15
7. Summary of Benefits ............................................17
8. Applications ...................................................18
9. Security Considerations ........................................19
10. Contributors ..................................................19
11. Acknowledgments ...............................................20
12. References ....................................................20
12.1. Normative References ....................................20
12.2. Informative References ..................................201. Introduction ✨
okay so the current BGP4 spec [RFC4271] lets you pick and propagate only one best path per prefix 🫠. As it's defined today, BGP has no mechanism to share non-best paths between speakers, and that causes a bunch of problems when people try to deploy new apps and services 😩.
This doc is basically a mechanism for fixing that, built on the idea of conceptually creating parallel route-reflector planes 🧚. It also compares existing solutions and proposes ideas for sharing more than the best path 💜. The parallel route-reflector planes approach is seriously iconic because it brings big benefits at a negligible capex and opex cost compared to the other options (a full BGP mesh or add-paths [ADD-PATHS]) 🤑. Some network operators are already considering it for their networks 👑.
This proposal doesn't change the BGP protocol definition 🙌. It doesn't need upgrades to provider edge or core routers, and it doesn't need network-wide upgrades either 😌. The only upgrade needed is the new functionality on the new or existing route reflectors 🎀.
2. History 🌸
The need to spread more paths than just the best one is mainly driven by three issues 🍓. The first is BGP oscillations [RFC3345]. The second is wanting faster reachability restoration when a network link or network element fails ⚡. The third is needing better BGP load-balancing 🫧. These issues led to the proposal of BGP add-paths [ADD-PATHS] 💅.
2.1. BGP Add-Paths Proposal
Okay so it's been proven that sharing only the best path of a route isn't enough for the ever-growing number of services riding on BGP 📈. That's why the add-paths proposal was submitted in 2002, so BGP could distribute more than one path 🦋. It works by adding a four-octet value called the "Path Identifier" to the Network Layer Reachability Information (NLRI) 🔑.
Here's the catch: a BGP implementation now has to keep per-path peer advertisement state instead of per-prefix state, so it can track which peers each path was advertised to. That comes with its own memory and processing cost 🥲.
Another big observation is that when Autonomous System Border Routers (ASBRs) with multiple External BGP (EBGP) peers don't set next-hop self, sharing more than one best path can lead to inconsistent best-path selection inside the autonomous system 😬. So you also have to attach the possible tiebreakers as a new attribute and propagate them within the domain 🎀. The add-paths document [ADD-PATHS] gives an example attribute for fast connectivity restoration, specifically for the case where an ASBR injects multiple external paths into the Internal BGP (IBGP) mesh 🧠. Based on that extra information, best-path selection is recommended to be modified so best- and backup-path selection stays consistent across the domain 💖. There's more on this in Section 6, "Deployment Considerations" 📚. In the solution proposed here, we noticed that for most applications, just the best external advertisement is required 🌈. For ASBRs peering with multiple upstream domains, setting next-hop self is recommended 🫶.
The add-paths protocol extensions have to be implemented by all the routers in an Autonomous System (AS) for the system to work correctly 🚨. How partial add-paths deployments benefit or risk anything is still a research topic 🔬. The risk gets even bigger in networks that don't use some form of edge-to-edge encapsulation 💀.
The required code changes can be a foundation for enhancements, like "Fast Connectivity Restoration Using BGP Add-path" [FAST-CONN] ✨. Deploying that across an entire service-provider network takes software and maybe even hardware upgrades, especially for End-of-Engineering or End-of-Life equipment 🛠️. Whether that's economically feasible is up in the air 🤷♀️. Even if add-path functionality were available on all commercial routing equipment from all vendors today, it could easily take years to reach 100% deployment coverage in any medium or large global network 😭.
To be clear, add-path is the most general way to tackle distributing many paths between BGP speakers 👑. But this document offers a solution that's way easier to deploy and needs no BGP protocol modifications, which is perfect when only a few extra paths are needed 💅. This alternative can handle critical service-provider requirements for sharing more than one path across an AS at a much lower deployment cost 🤑. Given the general network scaling concerns in RFC 4984 [RFC4984], "Report from the IAB Workshop on Routing and Addressing", that could be a big advantage 🌸.
3. Goals 🎯
Okay so this proposal isn't trying to compete with add-paths 🙅♀️. It's an interim solution until add-paths is standardized and implemented, and until that function can be deployed across the network 🕰️.
It's presented to network operators as a possible choice 🦋. It gives operators who need extra paths today a way to avoid having to move to a full mesh 🫧. The Nth best path describes a set of N paths with different BGP next hops, and there's no implied ordering or preference among those N paths 💜.
It's meant to buy more time 🧚. That allows a smoother, gradual migration, where router upgrades will be needed for other reasons anyway 🌈. It also gives standard RP/RE memory sizes time to comfortably absorb the overhead of other techniques without any compromises 💖.
4. Multi-Plane Route Reflection ✨
okay bestie, so the idea in this proposal assumes you're using route reflection inside the network 🦋
Let's look at today's picture of a simple route-reflected domain 🎀
ASBR3
***
* *
+------------* *-----------+
| AS1 * * |
| *** |
| |
| |
| |
| RR1 *** RR2 |
| *** * * *** |
|* * * P * * *|
|* * * * * *|
| *** *** *** |
| |
| IBGP |
| |
| |
| *** *** |
| * * * * |
+-----* *---------* *----+
* * * *
*** ***
ASBR1 ASBR2
EBGP
Figure 1: Simple route reflectionAbbreviations used:
RR - Route Reflector
P - Core routerFigure 1 shows an AS that connects via EBGP peering at ASBR1 and ASBR2 to an upstream AS or a set of ASes 🌸 For a given destination "D", ASBR1 and ASBR2 may have an external path P1 and P2, respectively. The AS network uses two route reflectors, RR1 and RR2, for redundancy reasons. The route reflectors propagate the single BGP best path for each route to all clients. All ASBRs are clients of RR1 and RR2 💅
Here are the possible cases for the path information ASBR3 may receive from route reflectors RR1 and RR2:
- When the best-path tiebreaker is the IGP distance: When paths P1 and P2 are considered equally good best-path candidates, the selection depends on the distance of the path's next hops from the route reflector making the decision. Depending on where the route reflectors sit in the IGP topology, they may choose the same best path or a different one. In that case, ASBR3 may receive either the same path or different paths from each route reflector 🧚
- When the best-path tiebreaker is MULTI_EXIT_DISC (MED) or LOCAL_PREF: In this case, only one path from the preferred exit point ASBR will be available to RRs, since the other peering ASBR will consider the IBGP path as best and will not announce (or, if already announced, will withdraw) its own external path. The exception here is the use of the BGP Best-External proposal [EXT-PATH], which allows a stated ASBR to still propagate its own external path to the RRs. Unfortunately, RRs will not be able to distribute it any further to other clients, as only the overall best path will be reflected 💀
There is no requirement of path ordering. The "Nth best path" really just describes a set of N paths with different BGP next hops 🙈
The proposed solution is based on additional route reflectors, or new functionality enabled on the existing route reflectors, that distribute an alternative path other than the best one instead of the overall best path for each route 🔥 The best-path (main) reflector plane distributes the best path for each route like it does today. The second plane distributes the second-best path for each route, and so on. Distributing N paths for each route can be achieved by using N reflector planes 👑
Since diverse-path functionality may be enabled on a per-peer basis, one deployment model can keep advertising the overall best path from both route reflectors, while a new session is provisioned to get an additional path. This allows uninterrupted use of the best path even if one of the RRs goes down, provided the overall best path is still a valid one 🫶
Each plane of route reflectors is a logical entity and may or may not be co-located with the existing best-path route reflectors. Adding a route-reflector plane to a network may be as easy as enabling a logical router partition, a new BGP process, or just a new configuration knob on an existing route reflector, plus configuring an additional IBGP session from the current clients if required. There are no code changes required on the route-reflector clients for this mechanism to work. Honestly it's easy to see that installing one or more additional route-reflector control planes is much cheaper and easier than upgrading hundreds of route-reflector clients across the whole network to support a different BGP protocol encoding 😭✨
Diverse-path route reflectors need the new ability to calculate and propagate the Nth best path instead of the overall best path. An implementation is encouraged to enable this new functionality on a per-neighbor basis 🌈
While this is an implementation detail, the code to calculate the Nth best path is also required by other BGP solutions. For example, for fast connectivity restoration, BGP must calculate a backup path for installation into the Routing Information Base (RIB) and Forwarding Information Base (FIB) ahead of the actual failure 🍓
To address the problem of external paths not being available to route reflectors due to LOCAL_PREF or MED factors, it is recommended that ASBRs enable [EXT-PATH] functionality so they always inject their external paths into the route reflectors 💜
4.1. Co-located Best- and Backup-Path RRs
To keep things simple, let's assume we only use two route-reflector planes (N=2) 🎀 When co-located, the additional second-best-path reflectors connect to the network at the same points from the perspective of the IGP as the existing best-path RRs. Let's also assume best-external functionality is enabled on all ASBRs 🦋
ASBR3
***
* *
+------------* *-----------+
| AS1 * * |
| *** |
| |
| RR1 RR2 |
| *** *** |
|* * *** * *|
|* * * * * *|
| *** * P * *** |
|* * * * * *|
|* * *** * *|
| *** *** |
| RR1' IBGP RR2'|
| |
| |
| *** *** |
| * * * * |
+-----* *---------* *----+
* * * *
*** ***
ASBR1 ASBR2
EBGP
Figure 2: Co-located Second-Best-Path RR PlaneHere's the list of configuration changes needed to turn on the second-best-path route-reflector plane 🧚
- Unless the same RR1/RR2 platform is being used, add RR1' and RR2' either as logical or physical new control-plane RRs at the same IGP points as RR1 and RR2, respectively.
- Enable best-external functionality on ASBRs.
- Enable RR1' and RR2' for second-plane route reflection. Alternatively, instruct the existing RR1 and RR2 to calculate the second-best path as well.
- Unless one of the existing RRs is set to advertise only the diverse path to its current clients, configure new ASBRs-RR' IBGP sessions.
The expected behavior is that under any BGP condition, ASBR3 and P routers receive both paths P1 and P2 for destination D ✨ Having both paths lets them implement a number of new services, as listed in Section 8 ("Applications") 🌸
As an alternative to fully meshing all RRs and RR's, an operator with a large number of reflectors deployed today may choose to peer newly introduced RR's to a hierarchical RR', which would be an IBGP interconnect point within the second plane as well as between planes 👑
One deployment model of this scenario can be achieved by simply upgrading the existing route reflectors without deploying any new logical or physical platforms. Such an upgrade lets route reflectors serve both peers that have upgraded to add-paths and those that can't be upgraded right away, while still distributing more than a single best path 🫶 The obvious protocol benefit of using existing RRs to send their clients the best and diverse BGP paths over different IBGP sessions is the automatic assurance that such a client always gets different paths, with different next hops 💖
The way to do this is to create a separate IBGP session for each Nth BGP path. Ideally, each such session terminates at a different loopback address of the route reflector 🌈 At the BGP OPEN stage of each session, a different bgp_router_id may be used. Correspondingly, the route reflector should also allow its clients to use the same bgp_router_id on each such session 🍓
4.2. Randomly Located Best- and Backup-Path RRs ✨
okay so now let's talk about a setup where an operator wants to switch on a second RR' plane using just one extra router, parked in a totally different network location from their current route reflectors 🗺️🦋. This model would be especially useful in networks where some kind of end-to-end encapsulation (IP or MPLS) is turned on between provider-edge routers 💅.
Quick heads-up: this model of operation assumes that the current best-path route reflectors are only control-plane devices 🙈. If the route reflector is in the data-forwarding path, then the implementation must be able to clearly separate the Nth best-path selection from the selection of the paths used for data forwarding ⚠️. The basic premise here is that all reflector planes have the same information to choose from, which includes the same set of BGP paths 🫶. It also requires the ability to ignore the step that compares the IGP metric to reach the BGP next hop during best-path calculation 💀.
ASBR3
***
* *
+------------* *-----------+
| AS1 * * |
| IBGP *** |
| |
| *** |
| * * |
| RR1 * P * RR2 |
| *** * * *** |
|* * *** * *|
|* * * *|
| *** RR' *** |
| *** |
| * * |
| * * |
| *** |
| *** *** |
| * * * * |
+-----* *---------* *----+
* * * *
*** ***
ASBR1 ASBR2
EBGPFigure 3: Experimental Deployment of Second-Best-Path RR Plane 🎀
So here's the checklist of config changes you'd need, whether you're setting up the second-best-path route reflector RR' as a single platform or turning one of the existing control-plane RRs into a diverse-path box 📝:
- If needed, add RR' (logical or physical) as a new route reflector anywhere in the network. 🌸
- Enable best-external functionality on ASBRs. ✨
- Disable the IGP metric check in BGP best path on all route reflectors. 🙅♀️
- Enable RR' or any of the existing RRs for second-plane path calculation. 🧚
- If required, fully mesh the newly added RRs' with all the other reflectors in both planes. This doesn't apply if the newly added RR'(s) already peer with all ASBRs/PEs 💜.
- Configure new BGP sessions between ASBRs and RRs (unless one of the existing RRs is set to advertise only diverse path to its current clients) 🔥.
In this scenario, the operator has tons of flexibility 👑. They can introduce the new route-reflector functionality on any existing or brand-new hardware in the network. Any existing routers that aren't already members of the best-path route-reflector plane can easily be set up to serve the second plane, either through a logical/virtual router partition or by having their BGP implementation comply with this specification 🌈.
Even when the IGP metric isn't considered while comparing paths during best-path calculation, an implementation still has to treat paths with unreachable next hops as invalid 🚫. Worth pointing out: some implementations today already allow configurations that result in no IGP metric comparison during best-path calculation 💅.
The additional planes of route reflectors don't need to be fully redundant the way the primary plane is 🦋. If we're preparing for a single network failure event, a failure of a non-backed-up Nth best-path route reflector would not cause a connectivity outage of the actual data plane 😭. The reason is that this would, at most, affect the presence of a backup path (not an active one) on the same parts of the network ✨. If the operator decides to build the Nth best-path plane redundantly by installing two or more route reflectors serving each additional plane, the extra robustness is achieved 🫶.
As a result of this solution, ASBR3 and other ASBRs peering with RR' will be receiving the second best path 🍓.
Similar to Section 4.1, as an alternative to fully meshing all RRs and diverse-path RRs', operators may choose to peer newly introduced RRs' with a hierarchical RR', which would be an IBGP interconnect point between planes 🧚♀️.
It is recommended that an implementation advertise the overall best path over the Nth diverse-path session if there is no other BGP path with a different next hop present. This is equivalent to today's case where the client is connected to more than one RR 💖.
4.3. Multi-Plane Route Servers for Internet Exchanges 🌐
Another group of devices where the proposed multi-plane architecture may be especially applicable is the EBGP route servers used at many Internet exchange points 🦋.
So in these setups, hundreds of ISPs are interconnected on a common LAN 😳. Instead of each exchange client having hundreds of direct EBGP sessions, a single peering gets created to the transparent route server 🎀. The route server can only propagate a single best path. Mandating an upgrade for hundreds of different service providers just to implement add-path may be way harder than asking them to provision one new EBGP session to an Nth best-path route server plane 💀. This allows distribution of more than the single best BGP path from a given route server to such an Internet exchange point (IX) peer 👑.
The solution proposed in this document fits really well with the need for broader EBGP path diversity among the members of any Internet exchange point 💜.
5. Discussion on Current Models of IBGP Route Distribution 🧁
In today's networks, BGP4 operates as specified in [RFC4271] ✨.
There are a number of technology choices for intra-AS BGP route distribution 💅:
- Full mesh
- Confederations
- Route reflectors
5.1. Full Mesh 🕸️
A full mesh, the most basic IBGP architecture, exists when all BGP-speaking routers within the AS peer directly with all other BGP-speaking routers within the AS, no matter where a given router sits in the AS (e.g., P router, PE router, etc.) 🫶.
This is the simplest intra-domain path-distribution method, but historically there have been a bunch of challenges in making an IBGP full mesh work in a large-scale network 😩. Some of these challenges no longer apply, but the following (along with others) may still apply 👇:
- Number of TCP sessions: The number of IBGP sessions on a single router in a full-mesh topology of a large-scale service provider can easily reach hundreds. Such numbers could be a concern on hardware and software used in the late 70s, 80s, and 90s. Today, customer requirements for the number of BGP sessions per box are reaching thousands. That's already an order of magnitude more than the potential number of IBGP sessions 💀. Advancements in the hardware and software used in production routers mean that running a full mesh of IBGP sessions should not be dismissed due to the resulting number of TCP sessions alone 🌸.
- Provisioning: When operating and troubleshooting large networks, one of the topmost requirements is keeping the design as simple as possible 🧠. When the autonomous system is composed of hundreds of nodes, it gets really hard to manually provision a full mesh of IBGP sessions. Adding or removing a router requires reconfiguring all other routers in the AS 😵💫. While this is a real concern today, there's already work in progress in the IETF to define IBGP peering automation through an IBGP Auto Discovery mechanism [AUTO-MESH] 🧚.
- Number of paths: Another concern when deploying a full IBGP mesh is the number of BGP paths for each route that have to be stored at every node 📦. This number is very tightly related to the number of external peerings of an AS, the use of LOCAL_PREF or MED techniques, and the presence of best-external [EXT-PATH] advertisement configuration. If we make a rough assumption that the BGP4-path data structure consumes about 80-100 bytes, the resulting control-plane memory requirement for 500,000 IPv4 routes with one additional external path is 38-48 MB, while for 1 million IPv4 routes, it grows linearly to 76-95 MB 📈. It is not possible to reach a general conclusion about whether this condition is negligible or a show stopper for a full-mesh deployment without direct reference to a given network 🤷♀️.
To summarize, a full-mesh IBGP peering can offer natural dissemination of multiple external paths among BGP speakers 💖. When it's realized with the help of IBGP Auto Discovery peering automation, this seems like a viable deployment, especially in medium- and small-scale networks ✨.
5.2. Confederations 🎀
For the purpose of this document, let's observe that confederations [RFC5065] can be viewed as a hierarchical full-mesh model 🧩.
Within each sub-AS, BGP speakers are fully meshed, and as discussed in Section 2.1, all full-mesh characteristics (number of TCP sessions, provisioning, and the potential concern over number of paths) still apply at the sub-AS scale 🫶.
On top of the direct peering of all BGP speakers within each sub-AS, all sub-AS border routers must also be fully meshed with each other 🕸️. Sub-AS border routers configured with best-external functionality can inject additional (diverse) paths within a sub-AS 🦋.
To summarize, it is technically sound to use confederations together with best-external to distribute more than a single best path per route in large autonomous systems 👑.
In topologies where route reflectors are deployed within the confederation sub-ASes, the technique described here applies 🌈.
5.3. Route Reflectors 🪞
The main motivation behind using route reflectors [RFC4456] is avoiding the full-mesh session management problem described above 🙌. Route reflectors, for good or for bad, are the most common solution today for interconnecting BGP speakers within an internal routing domain 💅.
Route-reflector peerings follow the advertisement rules defined by the BGP4 protocol. As a result, only a single best path per prefix is sent to client BGP peers 😭. This is the main reason many current networks are exposed to a phenomenon called BGP path starvation, which essentially results in the inability to deliver a number of applications discussed later 💀.
When interconnecting BGP speakers between domains, the route reflection equivalent is popularly called the "Route Server" 🍓, and it's globally deployed today in many Internet exchange points 🌍.
6. Deployment Considerations 💖
okay bestie, so the diverse-BGP-paths proposal lets way more paths get passed along to route-reflector or route-server clients than just the best one, which is literally the whole point ✨. For deployment, you need to know that fast connectivity restoration and most of the intra-domain BGP-level load balancing needs can be handled with only two paths (overall best and second best) 🥹. So as a deployment recommendation, this document suggests using N=2 with diverse-path 🎀.
From the client's point of view, getting extra paths over separate IBGP sessions that end at the new route-reflector plane is functionally the same as a full-mesh peering, minus all the problems a full mesh comes with, like we talked about in an earlier section 🫶.
By precisely defining the number of reflector planes, operators get full control over how many redundant paths exist in the network. You can set that number to match the needs of whatever service(s) are being deployed 💅.
The Nth-plane route reflectors should act as control-plane network entities 🧚. They can be provisioned on the current production routers, but selected Nth-best BGP paths should not be used directly in the data plane, unless the path is BGP multipath eligible and that functionality is enabled 🙈. As for RRs being in the data plane when multipath isn't enabled, the second best path is expected to be a backup path and should be installed as one into the local RIB/FIB 🍓.
The word "planes" here is more of a conceptual thing, not a literal one ✨. In practice, all the paths are still kept in the single table where the normal best path gets calculated. That means tools like the looking glass shouldn't notice any changes or impact once diverse-path is enabled 👀.
The proposed architecture, deployed along with the BGP best-external functionality, covers all three cases where the classic BGP route-reflection paradigm would fail to distribute alternate (diverse) paths. Those are:
- ASBRs advertising their single best-external paths with no LOCAL_PREF or MED present.
- ASBRs advertising their single best-external paths with LOCAL_PREF or MED present and with BGP best-external functionality enabled.
- ASBRs with multiple external paths.
This section focuses on case 3 in more detail 🔥. That's the scenario of a single ASBR connected to multiple EBGP peers. Honestly, this peering setup is super common, mostly because of where the EBGP peers are located and how diverse they are (like peering with multiple tier-1 ISPs, etc.) 🌍. It isn't designed for failure recovery, though, since a single failure of the ASBR would take down connectivity to all of the peers at once 💀. In most medium and large geographically distributed networks, there's always another ASBR, or multiple ASBRs, providing peering backups, typically in other geographically diverse locations in the network 🦋.
When an operator uses ASBRs with multiple peerings, setting next-hop self will effectively allow local repair of the atomic failure of any external peer, without any compromise to the data plane 🎀. Traditionally, the most common reason for not setting next-hop self is the drawback of losing the ability to signal external failures of peering ASBRs, or of links to those ASBRs, by fast IGP flooding 😭. That potential drawback can be easily avoided by using a different peering address from the address used for next-hop mapping, and by removing the next-hop from the IGP at the last possible BGP path failure ✨.
Now, one could correctly observe that when next-hop self is set on an ASBR, the attributes of the other external paths that the ASBR is peering with may be different from the attributes of its best external path 🤔. So not injecting all of those external paths with their corresponding attributes can't be compared to equivalent paths for the same prefix coming from different ASBRs.
That observation is correct in principle, but you have to put things in perspective with the overall goal 💖. The goal is to provide data-plane connectivity upon a single failure, with minimal interruption and packet loss. During those transient conditions, using even potentially suboptimal exit points is reasonable, as long as forwarding information loops are not introduced 🔄. Meanwhile, the BGP control plane will on its own re-advertise the newly elected best external path, and the route-reflector planes will calculate their Nth best paths and propagate them to their clients. The result is that after seconds, even if some suboptimality were encountered, it will be quickly and naturally healed 🌸.
7. Summary of Benefits 🏆
Compared to the alternatives, the diverse-BGP-paths proposal gives you these benefits:
- No modifications to the BGP4 protocol.
- No requirement for upgrades to edge and core routers (as required in [ADD-PATHS]). It is backward compatible with existing BGP deployments 🫶.
- It can be easily enabled by introducing a new route reflector, a route server plane dedicated to the selection and distribution of Nth best-path, or just by new configuration of the upgraded current route reflector(s) ⚙️.
- It doesn't require major modifications to BGP implementations across the entire network. That would otherwise cause an unnecessary increase in memory and CPU consumption, due to the shift from today's per-prefix to a per-path advertisement state tracking 🧠.
- It can be safely deployed gradually, on an RR cluster basis 🌈.
- The proposed solution is equally applicable to any BGP address family, as described in "Multiprotocol Extensions for BGP-4" [RFC4760]. In particular, it can be used "as is" without any modifications for both IPv4 and IPv6 address families 🌍✨.
8. Applications 🎀
This section lists the most common applications that need redundant BGP paths:
- Fast connectivity restoration, where backup paths with alternate exit points would be pre-installed, as well as pre-resolved in the FIB of routers. This allows for a local action upon reception of a critical event notification of network/node failure 🚨. This failure recovery mechanism, based on the presence of backup paths, is also suitable for gracefully addressing scheduled maintenance requirements, as described in [BGP-SHUTDOWN] 🛠️.
- Multi-path load balancing for both IBGP and EBGP ⚖️.
- BGP control-plane churn reduction for both intra-domain and inter-domain 📉.
An important point is that all of the above intra-domain applications are based on the use of reflector planes, but they're also applicable to the inter-domain Internet exchange point examples 🌐. As discussed in Section 4.3, an Internet exchange can conceptually deploy shadow route server planes, each one responsible for distributing an Nth best path to its EBGP peers 👑. In practice, that may just amount to a new short configuration and the establishment of new BGP sessions to IX peers 💅.
9. Security Considerations 🔐
⚠️ Read this one carefully, bestie. The security stuff is serious even when the vibe isn't.
The new mechanism for diverse BGP path dissemination proposed in this document does not introduce any new security concerns compared to the base BGP4 specification [RFC4271], and especially compared to a full-IBGP-mesh topology 🛡️.
On top of that, the authors observe that all BGP security issues described in [RFC4272] apply to the additional BGP session or sessions recommended by this specification 🚩. So all the recommended mitigation techniques for BGP security are applicable here too 🫡.
10. Contributors 🫶
The following people contributed significantly to the content of this document 💜:
Selma Yilmaz
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
US
Email: seyilmaz@cisco.com
Satish Mynam
Juniper Networks
1194 N. Mathilda Ave
Sunnyvale, CA 94089
US
Email: smynam@juniper.net
Isidor Kouvelas
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
US
Email: kouvelas@cisco.com11. Acknowledgments 🌸
The authors would like to thank Bruno Decraene, Bart Peirens, Eric Rosen, Jim Uttaro, Renwei Li, Wes George, and Adrian Farrel for their valuable input 🙌.
The authors would also like to express a special thank you to a number of operators who helped optimize the provided solution so it's as close as possible to their daily operational practices 🧡. In particular, many thanks to Ted Seely, Shane Amante, Benson Schliesser, and Seiichi Kawamura ✨.
12. References 📚
12.1. Normative References
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, January
2006.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, April 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, January
2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.12.2. Informative References
[ADD-PATHS] Walton, D., Chen, E., Retana, A., and J. Scudder,
"Advertisement of Multiple Paths in BGP", Work in Progress,
June 2012.
[AUTO-MESH] Raszuk, R., "IBGP Auto Mesh", Work in Progress, January
2004.
[BGP-SHUTDOWN]
Decraene, B., Francois, P., Pelsser, C., Ahmad, Z., and
A. Armengol, "Requirements for the Graceful Shutdown of
BGP Sessions", Work in Progress, September 2009.
[EXT-PATH] Marques, P., Fernando, R., Chen, E., Mohapatra, P., and
H. Gredler, "Advertisement of the Best External Route in
BGP", Work in Progress, January 2012.
[FAST-CONN] Mohapatra, P., Fernando, R., Filsfils, C., and R. Raszuk,
"Fast Connectivity Restoration Using BGP Add-path", Work
in Progress), October 2011.
[RFC3345] McPherson, D., Gill, V., Walton, D., and A. Retana,
"Border Gateway Protocol (BGP) Persistent Route
Oscillation Condition", RFC 3345, August 2002.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC
4272, January 2006.
[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous
System Confederations for BGP", RFC 5065, August 2007.Authors' Addresses 💌
Robert Raszuk (editor)
NTT MCL
101 S Ellsworth Avenue Suite 350
San Mateo, CA 94401
United States
EMail: robert@raszuk.net
Rex Fernando
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
United States
EMail: rex@cisco.com
Keyur Patel
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
United States
EMail: keyupate@cisco.com
Danny McPherson
Verisign, Inc.
12061 Bluemont Way
Reston, VA 20190
United States
EMail: dmcpherson@verisign.com
Kenji Kumaki
KDDI Corporation
Garden Air Tower
Iidabashi, Chiyoda-ku, Tokyo 102-8460
Japan
EMail: ke-kumaki@kddi.com📦 where this page comes from
- ietf: rfc6774 2012-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms