BGP Route Dampening Part 2: RFC 7454, BFD, and Where Dampening Still Belongs

28 May 2026 ciscobgpnetworkingiosroutingbfd

Part 1 of this series covered the mechanics of BGP route dampening: the exponential decay algorithm, every Cisco parameter, the operational state machine, and a complete configuration and verification reference. This part covers the consequences. The networking community spent the better part of a decade discovering that dampening, applied at internet scale with the default parameters Cisco shipped, caused more harm than the flapping it was meant to cure. The story of how that happened, the IETF’s response in RFC 7454, how Bidirectional Forwarding Detection changes the equation, and the specific environments where dampening still earns its place — that is what this post is about.

A Feature That Became a Liability

In the early 2000s, BGP route dampening was widely deployed at internet service providers worldwide. It seemed like the obvious solution to flapping routes, it was a standard feature in every major router OS, and the defaults had been set by Cisco with what seemed like reasonable conservatism. What the networking community discovered over the next several years was that the feature had a fundamental blind spot.

The Path Hunting Problem

BGP does not converge instantaneously. When a route is withdrawn, routers that relied on that path do not simply fail over to their next-best path in a single step. Instead, they begin a process called path hunting: each router queries its BGP table for an alternative path, sends its own withdrawal if none exists, waits for the withdrawal to propagate, then potentially receives an alternative path advertised by a neighbour that had a backup. In a large, well-connected topology, this process can produce a sequence of withdrawals and re-announcements for the same prefix as the topology converges through several intermediate states toward a final best-path.

From the perspective of a router with dampening enabled, path hunting during BGP convergence looks exactly like route flapping. Each intermediate convergence step generates a withdrawal followed by a re-announcement. Dampening cannot distinguish between a genuinely unstable prefix and one that is merely convergence-hunting a stable alternative path. The result was that route dampening would fire on completely valid prefixes during normal convergence events — major link failures, planned maintenance, BGP session resets — and suppress them for 30 to 60 minutes after the network had already converged to a stable alternative. The route was functionally available; dampening had simply hidden it.

This was not an edge case. Studies of RouteViews data from the early-to-mid 2000s found that a substantial proportion of BGP UPDATE bursts that would trigger dampening with default parameters were attributable to path hunting during convergence rather than genuine instability. The feature was suppressing correct routes in response to BGP’s own normal behaviour.

Amplification Through the Topology

The second problem was amplification. Because dampening decisions are made locally at each router without coordination, a flapping prefix would be independently suppressed and released by every router along the path, with each router potentially on a different decay schedule. A prefix that stabilised might be reinstated by a router at the edge of an AS, trigger a re-announcement, which looked like a new flap to a router deeper in the network that was already carrying a penalty, causing a second suppression. The distributed nature of the mechanism turned a single flapping event into a series of cascading suppressions across the topology.

The 2010 Wake-Up Call

By around 2010, enough operational data had accumulated that the BGP operations community had developed a clear consensus: global dampening with default parameters was doing more harm than good. The work by Meikal Mumin and Geoff Huston, drawing on large-scale BGP measurement data, quantified what operators had been observing anecdotally: routes that should have been available were being held suppressed for tens of minutes after their underlying paths had fully stabilised, with the sole cause being dampening’s inability to distinguish convergence from instability.

The fix was already in use at well-run networks: restrict dampening to eBGP sessions with directly-connected customers and upstream peers where the operator had no control over link stability, apply it selectively rather than globally, and use conservative parameters that required genuine sustained instability rather than normal convergence to trigger suppression.

RFC 7454: What the IETF Actually Says

RFC 7454, “BGP Operations and Security,” was published in February 2015 by Jérémy Durand, Ivan Pepelnjak, and Gert Döring. It is a BCP (Best Current Practice) document, meaning it carries more normative weight than an informational RFC but less than a full standards-track specification. Section 6.2, “Route Flap Damping,” is the relevant part, and it is worth reading the original language rather than paraphrasing:

“BGP route flap damping SHOULD NOT be deployed in the Internet Default-Free Zone (DFZ). In other environments, route flap damping SHOULD be deployed sparingly, and only for routes learned from directly connected neighbors. If it is deployed, the threshold values SHOULD be set according to [RFC7196].”

RFC 7196, “Making Route Flap Damping Usable,” was published in the same month and provides the specific parameter recommendations. Its core guidance is that dampening parameters should be set so that a prefix needs to flap substantially more than once before suppression triggers, and that suppression times should be short enough that they do not meaningfully outlast a genuine BGP convergence event. The RFC 7196 recommendations:

Half-life: 15 minutes (unchanged from Cisco default)
Reuse limit: 750 (unchanged from Cisco default)
Suppress limit: 6000 (three times higher than the Cisco default of 2000)
Max suppress time: 60 minutes (unchanged from Cisco default)

The tripling of the suppress limit is the critical change. With a suppress limit of 6000 rather than 2000, a single rapid flap-burst of two or three withdrawals no longer triggers suppression. Six rapid withdrawals are required to reach the threshold from a zero baseline, which substantially reduces the probability of convergence-hunting traffic triggering dampening on a stable prefix.

The SHOULD NOT for the DFZ (the global internet routing table) is an explicit acknowledgment that the feature’s original context — protecting router CPUs at internet exchanges in the late 1990s — is no longer the primary concern. Modern core routers handle full BGP table churn without approaching CPU saturation. The cost of incorrect suppression (traffic loss on valid paths) now routinely exceeds the cost of the instability dampening was designed to absorb.

Bidirectional Forwarding Detection: A Deeper Look

BFD is frequently cited as a reason not to use dampening, usually with the summary explanation that “BFD detects failures faster so you don’t need dampening.” The reality is more nuanced. BFD and dampening solve different problems, have opposing objectives, and under certain conditions actively conflict with each other.

What BFD Actually Is

RFC 5880 defines BFD as a generic mechanism for detecting failures in the forwarding path between two adjacent forwarding engines. The key phrase is “forwarding path” — BFD operates at the data plane, not the control plane. It does not monitor the BGP session itself; it monitors whether packets are actually traversing the path between two endpoints. This distinction matters because a BGP session can be operationally alive (TCP connection maintained, keepalives exchanged) while the forwarding path it represents has failed — something that happens in certain interface flap scenarios, hardware failures, and misconfigured networks.

The BFD Protocol

BFD works by establishing a bidirectional hello mechanism between two directly-connected (or single-hop logical) endpoints. Once a BFD session is up, each endpoint transmits BFD control packets at a negotiated interval. If a configured number of consecutive hello packets are not received (the detection multiplier), the session is declared failed.

Three operational modes exist:

Asynchronous mode is the standard mode and the one used with BGP. Both endpoints periodically send BFD control packets. Each endpoint independently runs its own detection timer. If either endpoint fails to receive packets for Detection Multiplier × Minimum Receive Interval, it declares the session Down.

Demand mode is an optimisation for environments where BFD control traffic overhead needs to be minimised. Instead of continuous hellos, demand mode sends “poll” sequences periodically. Between polls, no BFD packets are exchanged unless either endpoint sends a poll. Not commonly used with BGP.

Echo function sends BFD echo packets that loop back through the remote system’s forwarding engine (not its BFD process) and return to the sender. If the sender’s own echo packets stop returning, the path is declared down. Echo mode can detect forwarding failures even in single-homed scenarios and can achieve sub-millisecond detection times. When combined with asynchronous mode, it reduces the required control packet rate while maintaining fast detection.

BFD Timers

The negotiated detection interval is determined by the minimum of what each side can transmit and what each side is willing to receive. The negotiated detection multiplier is set by the system on which the timer is being calculated.

In Cisco IOS, BFD is configured with minimum transmit interval, minimum receive interval, and multiplier:

interface GigabitEthernet0/0
 bfd interval 50 min_rx 50 multiplier 3

This configures a transmit interval of 50 ms, a minimum receive interval of 50 ms, and a detection multiplier of 3. The detection time is 50 ms × 3 = 150 ms. If three consecutive BFD hellos are missed, the session is declared Down.

Common production values:

Use Case	Interval	Multiplier	Detection Time
Fast LAN failover	50 ms	3	150 ms
WAN with some jitter tolerance	300 ms	3	900 ms
Wireless/high-jitter links	1000 ms	5	5 s
Low-overhead monitoring	1000 ms	3	3 s

Very aggressive BFD timers (sub-100ms) should be applied only to hardware-assisted BFD implementations. Software BFD (most IOS platforms) with 50ms intervals may impose non-trivial CPU overhead when running many sessions simultaneously.

BFD State Machine

BFD has four session states: AdminDown, Down, Init, and Up.

AdminDown: the session is administratively disabled. The endpoint sends AdminDown control packets to notify the peer.
Down: no session exists or the session has failed. The endpoint sends its local state (Down) in control packets and listens for the peer to enter Init.
Init: the local endpoint has received a Down packet from the peer and is responding with Init, indicating readiness to come Up.
Up: both endpoints have received Init from each other and the session is active. This is the only state in which the detection timer is running and data-plane traffic is considered verified.

Integrating BFD with BGP on Cisco IOS

! Enable BFD on the interface facing the BGP peer
interface GigabitEthernet0/1
 bfd interval 300 min_rx 300 multiplier 3
 ip address 10.10.10.1 255.255.255.0

! Tell BGP to use BFD for failure detection with this neighbor
router bgp 65001
 neighbor 10.10.10.2 fall-over bfd

The fall-over bfd directive instructs BGP to tear down the session with this neighbor immediately when BFD declares the session Down, rather than waiting for the BGP hold-timer to expire. Without BFD, a standard BGP hold timer of 90 seconds means a failure is not detected for up to 90 seconds. With BFD at 300ms × 3 = 900ms detection time, the BGP session is torn down in under a second.

Verify BFD sessions with:

show bfd neighbors
show bfd neighbors details
show bfd neighbors interface GigabitEthernet0/1

Sample output:

IPv4 Sessions
NeighAddr                              LD/RD         RH/RS     State     Int
10.10.10.2                           4097/4097       Up        Up        Gi0/1

RH/RS is Remote Heard / Remote State. Both Up means the BFD session is fully established and the BGP fall-over bfd tracking is active.

The BFD + Dampening Interaction

Here is the conflict that is often glossed over in introductory explanations: BFD, applied to a genuinely flapping link, makes the flapping worse from the perspective of the BGP control plane.

Without BFD, a flapping physical link creates BGP events at the pace of the BGP hold timer — typically every 90 seconds, or whenever the link state change propagates to the BGP session level. A link that physically bounces every 10 seconds generates one BGP UPDATE per hold-timer expiry, not one per physical flap.

With BFD at 300ms detection, that same link physically bouncing every 10 seconds generates a BGP session teardown followed by a session re-establishment (and a full initial UPDATE exchange) every 10 seconds. The BGP control plane sees ten times the event rate compared to the no-BFD case. BFD has taken what was a relatively slow-moving control-plane event and made it fire at the rate of the underlying physical instability.

Now consider the network downstream of this router. Each BGP session teardown and re-establishment generates a burst of WITHDRAW and UPDATE messages that propagates to all peers of the affected router, which propagate it to all of their peers. At the detection speed of BFD, you can generate more BGP UPDATE traffic in five minutes from a single flapping link than the 1990s internet generated from hundreds of links in a day.

This is precisely the scenario in which dampening provides value even in a modern network — and it is also the scenario in which naive dampening (applied globally, with Cisco defaults) can make things worse by suppressing the wrong routes for too long. The correct answer is a calibrated, targeted combination:

BFD on the interface for fast detection of genuine failures.
Interface dampening (described below) to prevent single-digit-second physical flaps from generating rapid BGP session churn.
BGP dampening with RFC 7196 parameters applied selectively at the edge, targeted at prefixes from untrusted or volatile peers.

The goal of this layered approach is that a genuine link failure (interface goes down and stays down) is detected in sub-second time by BFD and BGP converges quickly. A flapping link (interface bounces repeatedly) is dampened at the interface level before it can generate BGP session churn, and if it does generate BGP events, the higher suppress limit from RFC 7196 means that convergence-hunting traffic does not accidentally trigger prefix suppression.

Interface Dampening: The First Line of Defence

IOS supports a per-interface dampening command that is completely separate from BGP route dampening. Interface dampening applies the same exponential decay mechanism at the link layer, controlling how quickly an interface state change (carrier up/carrier-down) is propagated to higher-layer protocols including BGP.

interface GigabitEthernet0/1
 dampening

With default interface dampening parameters, an interface must be stable for several seconds before its up/down state is reported to BGP. A link that bounces faster than this threshold is held in the “dampened” state by the interface layer — the physical flap is absorbed without ever generating a BGP event.

Custom interface dampening parameters:

interface GigabitEthernet0/1
 dampening 5 1000 4000 20

Parameters: <half-life seconds> <reuse threshold> <suppress threshold> <max-suppress-time seconds>. This example uses a 5-second half-life, suppress at 4000, reuse at 1000, max suppress 20 seconds — appropriate for a high-bandwidth LAN interface where you want rapid flaps absorbed but genuine failures detected quickly.

Interface dampening fires before BFD does, which means on a link configured with both, a brief carrier loss that recovers in milliseconds will be absorbed by interface dampening without BFD ever firing and without BGP ever seeing the event. Only a failure that exceeds the interface dampening suppress threshold generates a state change that BFD and BGP then act on.

The interaction:

Physical link bounces once (50 ms) 
  → Interface dampening absorbs it
  → BFD: no event
  → BGP: no event

Physical link bounces repeatedly (10 flaps in 30 seconds)
  → Interface dampening suppress threshold crossed
  → Interface declared administratively down to higher protocols
  → BFD session Down
  → BGP fall-over fires: session torn down
  → BGP dampening (RFC 7196 suppress limit 6000):
     If only 2–3 UPDATE cycles generated before interface dampening fired,
     penalty likely < 6000. Route not suppressed.
     If many cycles, route suppressed for up to 60 minutes.

BGP Graceful Restart

A second mechanism that interacts with dampening is BGP Graceful Restart (RFC 4724). GR allows a BGP speaker undergoing a restart (software reload, process restart, ISSU) to signal its peers to preserve the routes they have received from it during the restart window, rather than withdrawing them. From the peer’s perspective, the BGP session goes down and comes back up, but because GR is in use, no withdrawal is propagated to the downstream network during the restart.

GR does not help with genuine link flapping — if the underlying path is actually unreliable, GR preserving a stale route is worse than withdrawing it, because traffic continues forwarding to a path that may be dropping packets. GR is specifically valuable for control-plane restarts where the forwarding plane remains functional throughout.

For dampening purposes, GR reduces the BGP event rate during maintenance operations and software upgrades, which lowers the accumulated penalty that a well-behaved but frequently-restarted router accumulates. This matters in environments where network equipment is rebooted regularly (rolling patches, etc.) and where a naive dampening policy would eventually suppress valid routes from that equipment.

Configure GR on Cisco IOS:

router bgp 65001
 bgp graceful-restart
 bgp graceful-restart restart-time 120
 bgp graceful-restart stalepath-time 360

restart-time is the window within which the restarting router must re-establish the BGP session and re-advertise routes before peers purge the preserved paths. stalepath-time is how long peers retain stale routes.

Where BGP Dampening Still Belongs in 2026

With RFC 7454’s SHOULD NOT for the DFZ and the operational lessons of two decades, where does dampening still make sense? The answer is specific and bounded.

PE-CE Boundaries with Untrusted Customers

A provider edge router peering with a customer edge router over an eBGP session has no control over the customer’s network stability. If the customer’s WAN link is physically flapping — a common occurrence with leased-line circuits, MPLS access circuits, or poorly-maintained premises equipment — BFD on the PE-CE interface will generate rapid BGP session churn, and that churn will propagate as UPDATE storms into the provider’s core.

Applying BGP dampening with RFC 7196 parameters on the inbound PE-CE session is exactly the original use case and remains valid. The key constraints are:

Apply only to eBGP sessions facing the customer, not to any iBGP sessions inside the provider network.
Use RFC 7196 suppress limit (6000) rather than the Cisco default (2000) to avoid triggering on normal convergence.
Consider a route-map to apply different dampening aggressiveness to different prefix size ranges — a /24 from a customer representing a single site is a more appropriate dampening candidate than an aggregate /16 representing the customer’s entire address space.

ip prefix-list PL-CE-SPECIFICS permit 0.0.0.0/0 ge 24

route-map RM-CE-DAMPENING permit 10
 match ip address prefix-list PL-CE-SPECIFICS
 set dampening 15 750 6000 60

route-map RM-CE-DAMPENING permit 20

router bgp 65001
 neighbor 10.200.0.2 dampening route-map RM-CE-DAMPENING

This applies RFC 7196-aligned dampening to specific prefixes (/24 and longer) from the customer, without dampening the customer’s aggregate announcements.

Mobile and Wireless Backhaul

Satellite and microwave backhaul links have fundamentally different physical characteristics from fibre — they experience signal fading, weather-related attenuation, and rapid oscillation that has no equivalent in wired networking. A microwave link in heavy rain can cycle up and down multiple times per minute while the underlying path is “working” in the sense that it is carrying traffic most of the time.

BFD on these links, if set aggressively, generates exactly the BFD-induced flap storm described above. The recommended approach is:

BFD with conservative timers (1000ms × 5 = 5 second detection) so that brief fades do not trigger a session teardown.
Interface dampening to absorb sub-second carrier oscillations before they reach BFD.
BGP dampening with RFC 7196 parameters and a longer half-life (30 minutes instead of 15) to account for the higher natural variability of these links.

interface GigabitEthernet0/2
 description Microwave backhaul to Site-7
 bfd interval 1000 min_rx 1000 multiplier 5
 dampening 10 2000 8000 40

router bgp 65001
 neighbor 172.16.7.1 fall-over bfd
 neighbor 172.16.7.1 dampening route-map RM-BACKHAUL-DAMPENING

The combination of 5-second BFD detection and 10-second interface dampening means that brief fading events (< 10 seconds) are absorbed before reaching BGP, medium-duration outages (10–50 seconds) trigger BFD without BGP dampening firing, and only persistent instability triggers BGP-level suppression.

Internet Exchange Peering Under Specific Conditions

At an internet exchange, where a router may peer with dozens or hundreds of route servers and bilateral peers, a participant with a flapping uplink can generate massive UPDATE volumes across the exchange fabric. Most modern IXPs have monitoring and member policies that address this at the operations level, but dampening on inbound IXP peering sessions with RFC 7196 parameters provides a local technical backstop.

This is more conservative guidance than PE-CE dampening — IXP peers are generally well-operated networks, and the suppress limit should be set high enough that normal convergence events never trigger suppression. RFC 7196 suppress limit of 6000 is appropriate; some operators use 8000 or 12000 for IXP sessions.

Preventing BFD-Induced Flap Storms

The most nuanced use case is combining BFD and dampening on the same session specifically because of BFD’s amplification effect. If you are deploying BFD with aggressive timers on a link you suspect may be physically unreliable, dampening provides the safety valve. Without dampening, a 300ms BFD session on a link that flaps every two seconds will generate a BGP session teardown and re-establishment every two seconds, indefinitely. With dampening (suppress limit 6000), the BGP-level events that result from the first few BFD-triggered session cycles are absorbed; after six or so cycles, the prefix is suppressed and the churn stops propagating into the network.

The operational procedure when this happens is:

show ip bgp dampening dampened-paths — confirm which prefixes are suppressed.
show bfd neighbors — confirm BFD is firing repeatedly.
Investigate and resolve the physical layer issue.
clear ip bgp dampening — once the physical issue is resolved, manually release suppressed routes rather than waiting for the decay timer.

The important point is that clear ip bgp dampening is the operational escape hatch, not a failure of the dampening design. Requiring manual intervention to release a suppressed route after a genuine instability event is resolved is acceptable; having routes suppressed unexpectedly during normal operations is not.

Feature Comparison: BGP Dampening vs. BFD

Dimension	BGP Route Dampening	Bidirectional Forwarding Detection
Primary purpose	Protect control planes by suppressing oscillating prefixes	Detect forwarding path failures at sub-second speed
Layer	Control plane (BGP application layer)	Data plane / link layer
Problem it solves	Sustained, repeated instability causing UPDATE storms	Slow detection of genuine failures due to BGP hold timer
Action on failure	Suppresses the affected prefix; route becomes unreachable	Tears down BGP session; traffic fails over to backup path
Effect on convergence	Deliberately slows it down	Deliberately speeds it up
Effect when link flaps	Reduces UPDATE propagation; may cause prolonged blackhole	Amplifies event rate; may cause UPDATE storm
Modern guidance	SHOULD NOT in DFZ; use selectively at edges with RFC 7196 params	Standard best practice for fast failover everywhere
Complementary or competing?	Complementary when layered correctly; conflicting when both applied naively

Decision Framework: Should You Apply Dampening?

Work through these questions in order.

1. Is this an iBGP session? If yes, do not apply dampening. Full stop.

2. Is this a session in the DFZ (carrying full internet routing)? If yes, follow RFC 7454: do not apply dampening unless you have a specific, documented reason and you are using RFC 7196 parameters with a suppress limit of at least 6000.

3. Is the peer a customer, reseller, or third-party site you do not control? If yes, dampening at the PE-CE boundary with RFC 7196 parameters is appropriate and valuable.

4. Is the underlying physical medium volatile (microwave, satellite, LTE backhaul)? If yes, the combination of interface dampening + conservative BFD timers + BGP dampening with extended half-life is the right architecture.

5. Are you deploying BFD with aggressive timers (< 1 second detection)? If yes, consider whether dampening is needed as a flap-storm safeguard. The need is highest on links that are physically unreliable; on stable fibre connections with aggressive BFD it is generally unnecessary.

6. Have you confirmed you are using RFC 7196 parameters (suppress ≥ 6000)? If you are applying dampening and you are using the Cisco default suppress limit of 2000, reconfigure before going to production.

Putting It All Together: A Modern Edge Configuration

A complete example for a provider edge router peering with a customer site over an eBGP session, with BFD for fast failover and targeted dampening for instability protection:

! =============================================
! Interface configuration with BFD + dampening
! =============================================
interface GigabitEthernet0/1
 description PE-CE to Customer-A (AS 65100)
 ip address 10.200.0.1 255.255.255.252
 bfd interval 300 min_rx 300 multiplier 3
 dampening 5 1000 4000 20

! =============================================
! Dampening policy: RFC 7196 for customer specifics
! =============================================
ip prefix-list PL-CUSTOMER-SPECIFICS permit 0.0.0.0/0 ge 24

route-map RM-CE-INBOUND-DAMPENING permit 10
 match ip address prefix-list PL-CUSTOMER-SPECIFICS
 set dampening 15 750 6000 60

route-map RM-CE-INBOUND-DAMPENING permit 20

! =============================================
! BGP session with BFD fall-over and dampening
! =============================================
router bgp 65001
 neighbor 10.200.0.2 remote-as 65100
 neighbor 10.200.0.2 description Customer-A
 neighbor 10.200.0.2 fall-over bfd
 neighbor 10.200.0.2 route-map RM-CE-INBOUND-DAMPENING in
 neighbor 10.200.0.2 dampening route-map RM-CE-INBOUND-DAMPENING

What this achieves:

Interface dampening (5-second half-life, suppress at 4000) absorbs sub-second carrier flaps before BFD or BGP see them.
BFD (300ms × 3 = 900ms detection) detects genuine failures faster than the BGP hold timer.
BGP fall-over bfd tears down the BGP session in under a second when BFD fires.
BGP dampening (suppress = 6000, per RFC 7196) applies only to /24 and longer prefixes. The customer’s aggregate announcement is not dampened; only their individual site prefixes are. Three to six rapid convergence events are required to trigger suppression, substantially reducing false positives.

Verify the full state with:

show bfd neighbors details
show ip bgp dampening parameters
show ip bgp dampening flap-statistics
show ip bgp dampening dampened-paths
show interfaces GigabitEthernet0/1 dampening

Summary

BGP route dampening is a feature with a legitimate origin, a troubled operational history, and a specific — much narrower — valid use case today. The exponential decay mechanism is well-designed for what it does. The problem was never the algorithm; it was the application of the algorithm globally, with parameters tuned for a 1990s internet that no longer exists.

The right mental model for dampening in 2026 is not “enable this to protect against flapping routes” but rather “apply this surgically at untrusted eBGP boundaries, using RFC 7196 parameters, as the second line of defence behind interface dampening and ahead of BFD.” Used that way, it solves a real problem. Applied globally with default parameters, it causes the very connectivity failures it was designed to prevent.

BFD and dampening are not alternatives to each other. They operate at different layers, solve different problems, and work best in combination — as long as the combination is designed with the flap-storm interaction in mind. Interface dampening is the glue between them. The complete picture is: interface dampening absorbs physical layer noise, BFD detects genuine forwarding failures fast, and BGP dampening with RFC 7196 parameters prevents BFD-amplified flap storms from propagating into the wider network.

For further reading: RFC 2439 (original dampening specification), RFC 7196 (updated parameter recommendations), RFC 7454 (BGP operations and security best practices), and RFC 5880 (BFD specification). The Geoff Huston BGP measurement analyses on APNIC blog provide the empirical data behind the RFC 7454 recommendations for those who want to understand the operational evidence rather than just take the SHOULD NOTs on faith.