Internet-Draft BGP Graceful Degradation July 2026
Zhao, et al. Expires 7 January 2027 [Page]
Workgroup:
grow
Internet-Draft:
draft-zhao-grow-bgp-graceful-degradation-00
Published:
Intended Status:
Informational
Expires:
Authors:
J. Zhao, Ed.
China Unicom
R. Pang
China Unicom
X. Gao
China Unicom

BGP Graceful Degradation Under Control Plane Memory Pressure

Abstract

This document describes an operational framework for graceful degradation of BGP under control-plane memory pressure. When BGP speakers experience rapid growth in routing state due to route flapping, configuration errors, or anomalous route injection, control-plane memory can become exhausted, leading to session resets, routing process restarts, or device reboots.

The framework described in this document progressively reduces BGP route admission and processing based on local resource conditions, isolates non-critical neighbors or services when necessary, and restores routing state in a controlled manner after recovery. The objective is to preserve basic device operation and reduce service impact. This document does not define any new BGP messages, path attributes, capabilities, or protocol state machines.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 7 January 2027.

▲

Table of Contents

1. Introduction

BGP speakers may experience rapid control-plane memory consumption when routing state grows quickly due to route flapping, configuration errors, large-scale route synchronization, rapid service expansion, or anomalous route injection.

When implementations lack active resource-protection mechanisms, continuously receiving and processing routes can lead to memory exhaustion, which may trigger BGP session resets, routing process restarts, board resets, or even device reboots. Such failures not only affect existing services but may also create renewed resource pressure after recovery, because full routing state re-synchronization can again consume significant control-plane resources. This may lead to a cycle of exhaustion, restart, re-synchronization, and renewed exhaustion.

This document describes a BGP graceful degradation operations framework oriented toward control-plane memory pressure. The framework progressively reduces BGP route admission and processing based on resource status and, when necessary, isolates selected neighbors, address families, or services to maintain basic device operation. After resource recovery, the device re-synchronizes routing state in a controlled manner and returns to normal operation.

This document does not define new BGP messages, path attributes, capabilities, or protocol state machines.

2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Problem Description

BGP is a stateful, incremental routing protocol. Upon receiving routes, a BGP speaker must maintain control-plane state including prefixes, paths, attributes, policy results, and next-hops.

BGP routing state may grow rapidly in a short time under the following scenarios:

Existing resource protection typically resets neighbors after the route count exceeds a static threshold, or restarts the protocol process after memory is exhausted. While these methods can stop resource growth, they often have the following limitations:

Therefore, an active protection mechanism based on resource feedback is needed to limit BGP resource growth while the device still has management and recovery capabilities.

4. Objectives and Scope

The objectives of BGP graceful degradation are:

This document focuses on control-plane memory pressure caused or significantly aggravated by BGP routing state growth.

This document does not replace the following mechanisms:

5. Graceful Degradation Principles

5.1. Prevention First

Graceful degradation is a resource-protection mechanism for abnormal states and should not replace normal route filtering, maximum prefix limits, and capacity planning.

5.2. Minimum Impact Scope

Protection actions should start from a smaller scope and only expand progressively when resources continue to deteriorate.

The reference order is as follows:

  • Reduce route admission or processing rate

  • Pause admission of new routes for selected scopes

  • Isolate selected address families, VRFs, or services

  • Close selected non-critical BGP sessions

  • Invoke process-level or device-level last-resort protection

5.3. Maintain Control Capability

During degradation, the following should be preserved as much as possible:

  • Management access;

  • Alarms and telemetry;

  • Basic BGP session processing;

  • Route withdrawal processing;

  • Recovery and route re-synchronization capabilities.

5.4. Prioritize Route Withdrawal Processing

When resources are constrained, route withdrawal is usually more important than new route advertisement. Delaying new routes may cause temporary absence of new reachable paths, while delaying withdrawal may allow invalid routes to persist. Therefore, during degradation, it is preferable to prioritize processing withdrawals and updates affecting existing reachability.

5.5. Recovery Must Be Executed in a Controlled Manner

Recovery cannot simply be equated with lifting all restrictions. Route refresh, neighbor re-establishment, and full-route learning may all cause memory peaks again, so the recovery process needs to be batched, rate-limited, and have hysteresis.

5.6. Resource Monitoring and State Determination

Devices can comprehensively use the following information to determine whether to enter a graceful degradation state:

  • System memory utilization;

  • Absolute available memory;

  • Memory growth rate;

  • Memory allocation failures;

  • BGP process or module memory share;

  • Route and path counts;

  • Route growth rate per neighbor and address family;

  • UPDATE processing rate and queue length;

  • Estimated remaining safe operation time.

Relying solely on a fixed memory percentage may not accurately reflect risk. Devices can consider both current resource level and growth trends.

Before executing BGP degradation, devices SHOULD also try to determine whether BGP is the main source of current memory pressure. If the main resource consumption comes from other modules, limiting BGP route admission and processing may only slow down the risk without solving the root problem. In such cases, devices SHOULD rely on platform-level resource management, shorten the monitoring interval, and MAY escalate directly to last-resort protection if the non-BGP source cannot be contained. BGP degradation SHOULD NOT be used as the sole response to non-BGP memory pressure.

Devices can divide operational states into:

  • Normal state;

  • Warning state;

  • Critical state;

  • Recovery state.

Normal, Warning, and Critical reflect the current resource level and associated protection actions. Recovery is a transitional operational state entered after the resource level has returned to safe ranges, during which the device executes controlled restoration of routing state. It is not a resource level itself.

Implementations can add finer states based on platform architecture, but the externally presented model should remain simple.

The following table provides an example mapping between resource states and candidate degradation actions. Implementations may define more detailed internal states based on platform architecture.

Table 1
State Resource Level / Condition Operational Action
Normal Memory level and growth rate are within expected ranges Normal BGP route admission and processing
Warning Memory utilization, growth rate, or UPDATE backlog exceeds a warning threshold Slow down route admission or processing; prioritize withdrawals
Critical Memory continues to deteriorate, allocation failures occur, or backlog memory becomes significant Pause admission for selected scopes; isolate AFI/SAFI, VRFs, or services; close selected sessions
Recovery Memory has returned below the recovery threshold and remained stable for a period; resource level is now Normal or near-Normal Perform batched route re-synchronization; rebuild closed sessions; gradually restore normal processing rate

6. Graded Degradation Strategy

6.1. Route Admission and Processing Slowdown

When a device enters the warning state, it can reduce BGP route admission and processing speed to slow down memory growth. Methods that can be adopted include:

  • Limit the number of new routes processed per unit time;

  • Allocate processing quotas by neighbor or address family;

  • Batch policy calculation and best-path calculation;

  • Merge duplicate updates for the same route within a short time;

  • Limit non-critical background tasks;

  • Reserve processing capability for route withdrawals.

Route processing slowdown should not cause input queues to grow indefinitely. Implementations need to monitor both UPDATE backlogs and the memory consumed by queued messages. If the input queue backlog itself becomes a significant source of memory pressure, the implementation SHOULD narrow the affected scope, pause new route admission for the affected peers or AFI/SAFI, or close the affected sessions in a controlled manner.

An implementation that discards queued UPDATE messages MUST mark the affected routing state as incomplete and MUST perform route re-synchronization before returning the affected scope to normal operation.

6.2. Pause Admission of New Routes

When learning slowdown is insufficient to control resource growth, new route admission can be paused within a selected scope.

The pause scope can be:

  • Specific neighbors;

  • Neighbor groups;

  • Specific AFI/SAFI;

  • Specific VRFs or services;

  • All non-critical route sources.

During degradation, route withdrawals and necessary updates affecting existing route validity can continue to be processed.

When new route admission is paused, the implementation MUST treat the affected Adj-RIB-In scope, or its equivalent implementation state, as incomplete. The implementation MUST record the affected peers, peer groups, AFI/SAFI, VRFs, and services, as applicable. Routes that are not admitted during the pause period will not necessarily be restored by subsequent incremental UPDATE messages.

Before the affected scope is considered fully recovered, the implementation MUST perform route re-synchronization, such as Route Refresh, Enhanced Route Refresh, local soft refresh where applicable, or controlled session re-establishment. If Route Refresh is not supported by the peer, controlled session re-establishment may be required.

6.3. Isolate Address Families or Services

When pausing new route admission is insufficient to control memory growth, devices can isolate specific address families, services, or VRFs.

Isolation means ceasing BGP route admission and processing for the selected scope. Depending on the implementation and local policy, isolation may include withdrawing affected routes from the local RIB.

Where the implementation supports independent per-AFI/SAFI processing or uses separate transport sessions for different services, isolation may be applied to the affected AFI/SAFI without closing the entire BGP peer session. Otherwise, isolating an AFI/SAFI may require closing the corresponding BGP session.

This action is more severe than pausing admission and is applied before closing entire neighbors or peer sessions.

6.4. Controlled Session Closure

When a BGP speaker remains in a critical resource state and narrower degradation actions cannot stop resource deterioration, selected BGP sessions can be closed in a controlled manner.

Session selection can consider multiple factors, including:

  • Estimated memory that may be released by closing the session;

  • Total number of routes and paths received from the peer;

  • Number or ratio of non-best paths;

  • Recent route growth rate;

  • Evidence of anomalous route injection or excessive route churn;

  • Service importance and configured protection priority;

  • Availability of alternative paths or redundant peers;

  • Expected recovery cost and recovery time.

Prioritizing closure of sessions with a large number of non-best paths is an optional strategy, but should not be the sole basis.

To reduce service impact, implementations may allow operators to configure protection priority for critical neighbors. Such protection should be combined with explicit resource budgets or exemption limits. Otherwise, an excessively large protected scope can make the degradation mechanism ineffective and may prevent the device from preserving basic operation.

Sessions should be closed in batches. After each batch of actions, the memory release effect can be observed before deciding whether to continue expanding the scope.

6.5. Last-Resort Protection

If available degradation actions cannot preserve basic device operation, the platform may need to invoke BGP process-level, control-unit-level, line-card-level, or device-level protection.

Such actions are last-resort measures and are not the normal objective of graceful degradation.

7. Recovery Strategy

When memory returns to a safe range, the device can enter the recovery state.

Recovery determination can simultaneously consider:

Entering and exiting degradation MUST use different thresholds (hysteresis) to avoid frequent state switching. The recovery threshold for a given state SHOULD be set sufficiently below its entry threshold, taking into account observed memory volatility, the resource cost of route synchronization, and the time required for memory to stabilize.

The recovery process can be executed in the following order:

  1. Confirm management and monitoring capabilities are normal;

  2. Restore new route admission for neighbors that were not disconnected;

  3. Perform full route synchronization, such as Route Refresh, session rebuild, or local soft refresh, for affected neighbors and address families to recover routes missed during degradation;

  4. Batch rebuild closed sessions;

  5. Gradually restore normal processing speed;

  6. Verify RIB, FIB, and resource status;

  7. Exit recovery state.

For neighbors whose new route admission was paused, merely restoring normal processing speed will not fill in the missed routing state.

Recovery can use:

Local soft refresh is applicable only when the implementation has retained sufficient local pre-policy or post-policy routing state. Under memory pressure, such retained state may be unavailable or may have been released as part of resource protection.

Both route refresh and session re-establishment may generate full-route updates, so the number of simultaneously recovering neighbors and address families needs to be limited.

If memory grows rapidly again during recovery, the implementation SHOULD stop starting new recovery batches. Scopes that have already recovered and remained stable do not need to be degraded again unless resource pressure continues to worsen or reaches a critical threshold.

8. Deployment and Operations Considerations

8.1. Threshold Setting

This document does not specify uniform memory thresholds.

Thresholds can be combined with:

  • Device total memory;

  • Control plane minimum safe margin;

  • Normal route scale;

  • Abnormal period route growth rate;

  • Memory reclamation delay;

  • Resources required for route refresh and neighbor rebuilding;

  • Resource requirements for other protocols and management functions.

8.2. Service Classification

Critical services can be identified by neighbor, address family, VRF, or neighbor group.

Service classification should remain simple and be consistent with real network redundancy relationships. Critical service protection should not be understood as absolute exemption; when the system is about to lose basic operation capability, last-resort protection may still affect critical neighbors.

8.3. Observability

Devices should provide the following information:

  • Current resource state;

  • Current degradation level;

  • Trigger reason;

  • Current memory level and memory growth rate;

  • Affected peers, peer groups, AFI/SAFI, VRFs, and services;

  • Route admission or processing rate-limit status;

  • Number of new routes not admitted, where available;

  • Whether the affected routing state is marked as incomplete;

  • Sessions closed due to resource protection and their selection reasons;

  • Current recovery stage;

  • Route re-synchronization method and progress;

  • Whether recovery is paused due to renewed resource pressure.

Operations systems need to be able to distinguish session closures caused by resource protection from ordinary link failures or protocol anomalies.

8.4. Gradual Deployment

Initial deployment can proceed according to the following steps:

  1. Enable only monitoring and alarms;

  2. Collect normal resource baselines;

  3. Verify route admission and processing slowdown;

  4. Verify recovery after pausing new route admission by injecting a controlled volume of test routes under simulated memory pressure. The test should confirm that the device pauses admission for the intended scope, marks the affected routing state as incomplete, records the affected peers and AFI/SAFI, and subsequently performs route re-synchronization without persistent missing state;

  5. Configure a small number of critical neighbors;

  6. Enable automatic slowdown;

  7. Then enable pause admission and controlled session closure;

  8. Regularly drill the recovery process.

9. Security Considerations

Attackers may cause devices to enter resource pressure states by continuously advertising a large number of legitimate routes.

Graceful degradation can reduce the probability of a single anomalous neighbor causing a device crash, but cannot replace route filtering, maximum prefix limits, neighbor authentication, and anomaly detection.

Attackers may also attempt to:

Therefore, devices can adopt recovery hysteresis, reconnection backoff, batch recovery, and multi-factor neighbor ranking to reduce risks.

Pausing new route admission can make the local routing view temporarily incomplete. Implementations MUST clearly record the affected scope and MUST perform route re-synchronization before the affected scope is considered fully recovered. Otherwise, some routes may remain missing for an extended period of time.

10. IANA Considerations

This document does not request IANA to allocate new code points.

11. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.

Authors' Addresses

Jing Zhao (editor)
China Unicom
Beijing
China
Ran Pang
China Unicom
Beijing
China
Xing Gao
China Unicom
Beijing
China