grow J. Zhao, Ed. Internet-Draft R. Pang Intended status: Informational X. Gao Expires: 7 January 2027 China Unicom 6 July 2026 BGP Graceful Degradation Under Control Plane Memory Pressure draft-zhao-grow-bgp-graceful-degradation-00 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. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Zhao, et al. Expires 7 January 2027 [Page 1] Internet-Draft BGP Graceful Degradation July 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Problem Description . . . . . . . . . . . . . . . . . . . . . 3 4. Objectives and Scope . . . . . . . . . . . . . . . . . . . . 4 5. Graceful Degradation Principles . . . . . . . . . . . . . . . 5 5.1. Prevention First . . . . . . . . . . . . . . . . . . . . 5 5.2. Minimum Impact Scope . . . . . . . . . . . . . . . . . . 5 5.3. Maintain Control Capability . . . . . . . . . . . . . . . 5 5.4. Prioritize Route Withdrawal Processing . . . . . . . . . 6 5.5. Recovery Must Be Executed in a Controlled Manner . . . . 6 5.6. Resource Monitoring and State Determination . . . . . . . 6 6. Graded Degradation Strategy . . . . . . . . . . . . . . . . . 8 6.1. Route Admission and Processing Slowdown . . . . . . . . . 8 6.2. Pause Admission of New Routes . . . . . . . . . . . . . . 9 6.3. Isolate Address Families or Services . . . . . . . . . . 10 6.4. Controlled Session Closure . . . . . . . . . . . . . . . 10 6.5. Last-Resort Protection . . . . . . . . . . . . . . . . . 11 7. Recovery Strategy . . . . . . . . . . . . . . . . . . . . . . 11 8. Deployment and Operations Considerations . . . . . . . . . . 12 8.1. Threshold Setting . . . . . . . . . . . . . . . . . . . . 13 8.2. Service Classification . . . . . . . . . . . . . . . . . 13 8.3. Observability . . . . . . . . . . . . . . . . . . . . . . 13 8.4. Gradual Deployment . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 11. Normative References . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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. Zhao, et al. Expires 7 January 2027 [Page 2] Internet-Draft BGP Graceful Degradation July 2026 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: * Neighbors erroneously advertise a large number of routes; * Route filtering or policy configuration anomalies; * Multiple neighbors performing full-route synchronization simultaneously; * Large-scale route flapping; * Rapid VPN or EVPN service expansion; Zhao, et al. Expires 7 January 2027 [Page 3] Internet-Draft BGP Graceful Degradation July 2026 * Malicious or anomalous route injection. 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: * Protection actions are triggered too late; * Failure impact scope is too broad; * They cannot take progressive measures based on resource status; * They cannot prioritize critical services; * Full routing state re-synchronization after restart may again cause resource peaks; * They are prone to forming an "exhaustion--restart--re- synchronization-- exhaustion again" loop. 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: * Identify resource risks before control-plane memory is exhausted; * Slow down or stop memory growth caused by new routes; * Maintain the BGP process, management plane, and existing forwarding state as much as possible; * Limit impact to smaller address families, services, or neighbor scopes; * Prioritize protection of critical services and critical neighbors; * Smoothly restore complete routing state after resource recovery; * Avoid large-scale simultaneous neighbor recovery causing new resource shocks. This document focuses on control-plane memory pressure caused or significantly aggravated by BGP routing state growth. Zhao, et al. Expires 7 January 2027 [Page 4] Internet-Draft BGP Graceful Degradation July 2026 This document does not replace the following mechanisms: * Network capacity planning; * Route filtering; * Maximum prefix limits; * Control plane protection; * BGP error handling; * Graceful Restart; * Planned Graceful Shutdown. 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; Zhao, et al. Expires 7 January 2027 [Page 5] Internet-Draft BGP Graceful Degradation July 2026 * 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. Zhao, et al. Expires 7 January 2027 [Page 6] Internet-Draft BGP Graceful Degradation July 2026 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. Zhao, et al. Expires 7 January 2027 [Page 7] Internet-Draft BGP Graceful Degradation July 2026 +==========+============================+==========================+ | State | Resource Level / Condition | Operational Action | +==========+============================+==========================+ | Normal | Memory level and growth | Normal BGP route | | | rate are within expected | admission and processing | | | ranges | | +----------+----------------------------+--------------------------+ | Warning | Memory utilization, growth | Slow down route | | | rate, or UPDATE backlog | admission or processing; | | | exceeds a warning | prioritize withdrawals | | | threshold | | +----------+----------------------------+--------------------------+ | Critical | Memory continues to | Pause admission for | | | deteriorate, allocation | selected scopes; isolate | | | failures occur, or backlog | AFI/SAFI, VRFs, or | | | memory becomes significant | services; close selected | | | | sessions | +----------+----------------------------+--------------------------+ | Recovery | Memory has returned below | Perform batched route | | | the recovery threshold and | re-synchronization; | | | remained stable for a | rebuild closed sessions; | | | period; resource level is | gradually restore normal | | | now Normal or near-Normal | processing rate | +----------+----------------------------+--------------------------+ Table 1 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. Zhao, et al. Expires 7 January 2027 [Page 8] Internet-Draft BGP Graceful Degradation July 2026 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. Zhao, et al. Expires 7 January 2027 [Page 9] Internet-Draft BGP Graceful Degradation July 2026 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. Zhao, et al. Expires 7 January 2027 [Page 10] Internet-Draft BGP Graceful Degradation July 2026 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: * Memory below recovery threshold; * Memory has stabilized for a certain period; * Memory growth rate has returned to normal; * UPDATE backlog has decreased; * Anomalous route injection or flapping has stopped; * The system has the resource margin required to execute route synchronization. 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: Zhao, et al. Expires 7 January 2027 [Page 11] Internet-Draft BGP Graceful Degradation July 2026 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: * Route Refresh; * Enhanced Route Refresh; * Local soft refresh, where sufficient local routing state has been retained; * Controlled BGP session re-establishment. 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 Zhao, et al. Expires 7 January 2027 [Page 12] Internet-Draft BGP Graceful Degradation July 2026 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; Zhao, et al. Expires 7 January 2027 [Page 13] Internet-Draft BGP Graceful Degradation July 2026 * 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. Zhao, et al. Expires 7 January 2027 [Page 14] Internet-Draft BGP Graceful Degradation July 2026 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: * Keep memory oscillating near degradation or recovery thresholds for long periods; * Induce a device to close specific BGP sessions by manipulating route volume or churn; * Consume resources by exploiting overly broad critical-neighbor exemptions; * Trigger repeated route re-synchronization during the recovery phase; * Cause persistent incomplete routing state if recovery procedures are not executed correctly. 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, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Zhao, et al. Expires 7 January 2027 [Page 15] Internet-Draft BGP Graceful Degradation July 2026 Authors' Addresses Jing Zhao (editor) China Unicom Beijing China Email: zhaoj501@chinaunicom.cn Ran Pang China Unicom Beijing China Email: pangran@chinaunicom.cn Xing Gao China Unicom Beijing China Email: gaox60@chinaunicom.cn Zhao, et al. Expires 7 January 2027 [Page 16]