BFD Considerations for Redundant Control Planes
draft-li-bfd-rcp-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Zhiqiang Li , Zongpeng Du , Junjie Wang , Wei Cheng , Guoying Zhang , Xun Sun , Chunhao Zhao | ||
| Last updated | 2026-07-04 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-li-bfd-rcp-00
BFD Z. Li
Internet-Draft Z. Du
Intended status: Standards Track China Mobile
Expires: 5 January 2027 J. Wang
W. Cheng
G. Zhang
Centec
X. Sun
Inesa
C. Zhao
SAIA
4 July 2026
BFD Considerations for Redundant Control Planes
draft-li-bfd-rcp-00
Abstract
In systems with redundant control plane processors, Bidirectional
Forwarding Detection (BFD) sessions are typically managed by a single
active processor. When that processor fails and a standby takes
over, BFD sessions may be interrupted long enough for remote peers to
declare failure, even though the forwarding plane remains
operational.
This document describes requirements and operational considerations
for preserving BFD sessions across control plane switchover events.
It discusses how BFD session state can be maintained on a standby
processor and how BFD processing can be resumed by the standby within
the BFD Detection Time, without requiring cooperation from or
signaling to remote BFD peers.
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."
Li, et al. Expires 5 January 2027 [Page 1]
Internet-Draft BFD for Redundant CPs July 2026
This Internet-Draft will expire on 5 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. System Model . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Maintaining BFD State on the Standby Processor . . . . . . . 5
5. Switchover Behavior . . . . . . . . . . . . . . . . . . . . . 6
5.1. Packet Delivery . . . . . . . . . . . . . . . . . . . . . 6
5.2. Resuming BFD Processing . . . . . . . . . . . . . . . . . 6
5.3. Former Active Processor . . . . . . . . . . . . . . . . . 7
5.4. Timing Requirements . . . . . . . . . . . . . . . . . . . 7
6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. BFD Session Types . . . . . . . . . . . . . . . . . . . . 7
6.2. Relationship to BFD Graceful Restart . . . . . . . . . . 8
7. Manageability Considerations . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Normative References . . . . . . . . . . . . . . . . . . . . 9
11. Informative References . . . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
Bidirectional Forwarding Detection (BFD) [RFC5880] provides a low-
overhead mechanism for detecting forwarding path failures between
adjacent systems. BFD is widely deployed in conjunction with routing
protocols such as OSPF, IS-IS, and BGP to trigger rapid convergence
upon link or node failure.
Li, et al. Expires 5 January 2027 [Page 2]
Internet-Draft BFD for Redundant CPs July 2026
Many network devices employ redundant control plane architectures to
improve availability. Common examples include routers with dual
Route Processors (RPs), switch stacking topologies, Virtual Chassis
systems, and chassis with redundant Supervisor modules. In these
systems, one control plane processor is active while one or more
standby processors are available to take over upon failure.
In typical deployments, BFD sessions are managed entirely by the
active processor: the BFD state machine, timers, and packet
processing all reside there. When the active processor fails and
control transitions to a standby, BFD sessions must be re-
established. This re-establishment time frequently exceeds the BFD
Detection Time (the product of the negotiated transmit interval and
the detection multiplier, as defined in [RFC5880]), causing the
remote BFD peer to declare failure.
The result is unnecessary routing reconvergence and transient traffic
disruption, even when the forwarding plane remains fully operational.
The interactions between BFD and Graceful Restart (GR) described in
Section 4.3 of [RFC5882] address BFD behavior during control protocol
restarts, but rely on explicit signaling by the restarting system and
cooperation from remote peers in helper mode. Not all control
protocols support planned restart signaling, and GR cannot protect
against all unplanned failure scenarios.
This document describes an approach in which BFD session state is
maintained on the standby processor and BFD processing is resumed
there before the remote peer's Detection Time expires. Because this
operates entirely within the local system, the remote BFD peer is
unaware of the switchover, and no protocol extensions or new BFD
packet formats are introduced.
This document does not address forwarding plane failures, link-level
failures, or data plane issues, which are detected by normal BFD
operation as defined in [RFC5880]. The considerations in this
document are also distinct from Seamless BFD (S-BFD) [RFC7880], which
defines an initiator/responder model for unidirectional path
monitoring.
1.1. 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.
Li, et al. Expires 5 January 2027 [Page 3]
Internet-Draft BFD for Redundant CPs July 2026
2. Terminology
This document uses the following terms. BFD-specific terms such as
Detection Time, Discriminator, and state machine variables are
defined in [RFC5880].
Active Processor: The control plane processor in a redundant system
that is currently running the BFD state machine, managing BFD
session timers, and processing BFD control packets for all
locally-owned sessions.
Standby Processor: A control plane processor in a redundant system
that is available to take over BFD session processing from the
active processor. During normal operation, the standby processor
does not run BFD timers or generate BFD control packets.
Switchover: The event in which BFD session processing transitions
from the active processor to a standby processor, which then
becomes the new active processor. A switchover may be planned
(e.g., administrative action) or unplanned (e.g., processor
failure).
3. System Model
This document considers systems with the following characteristics:
* Two or more control plane processors, each capable of running BFD.
* A shared forwarding plane that continues to operate during control
plane switchover.
* An internal communication path between processors with sufficient
bandwidth and reliability to carry BFD session state.
Such systems include routers with redundant Route Processors, switch
stacking topologies, Virtual Chassis configurations, and chassis with
redundant Supervisor modules.
At any point in time, exactly one processor is active for any given
BFD session. This invariant MUST be maintained: there MUST NOT be a
period during which two processors simultaneously run timers or
transmit BFD control packets for the same session.
Li, et al. Expires 5 January 2027 [Page 4]
Internet-Draft BFD for Redundant CPs July 2026
4. Maintaining BFD State on the Standby Processor
To enable the standby processor to resume BFD processing after
switchover, the active processor MUST keep the standby informed of
current BFD session state. The following session variables, as
defined in Section 6.8.1 of [RFC5880], MUST be available on the
standby processor:
* bfd.LocalDiscr and bfd.RemoteDiscr
* bfd.SessionState and bfd.RemoteSessionState
* bfd.LocalDiag
* bfd.DesiredMinTxInterval and bfd.RequiredMinRxInterval
* bfd.RemoteMinRxInterval
* bfd.DemandMode and bfd.RemoteDemandMode
* bfd.DetectMult
* bfd.AuthType, and when authentication is enabled, bfd.RcvAuthSeq
and bfd.XmitAuthSeq
The state on the standby processor MUST be sufficiently current that
BFD processing can be resumed without the remote peer detecting a
discontinuity. In particular, the standby's copy of session state
MUST NOT lag behind the active processor by more than one BFD
transmission interval.
The specific method used to keep the standby processor informed is an
implementation choice. Possible approaches include shared memory
between processors on the same board, inter-processor messaging over
a backplane, checkpoint-based periodic synchronization, or any other
suitable internal transport. This document does not prescribe a
particular method.
While the standby processor holds copies of BFD session state, it
MUST NOT run BFD state machine timers, transmit BFD control packets,
or otherwise actively participate in BFD sessions. The standby MUST
be ready to begin active BFD processing at any time upon becoming the
active processor.
Li, et al. Expires 5 January 2027 [Page 5]
Internet-Draft BFD for Redundant CPs July 2026
5. Switchover Behavior
When a switchover occurs (whether planned or due to failure), the
system MUST ensure that BFD processing resumes on the newly active
processor before the remote peer's Detection Time expires. The
following requirements apply.
5.1. Packet Delivery
Incoming BFD control packets MUST be delivered to the processor that
is currently active for the corresponding BFD session. The system
MUST be capable of redirecting BFD packet delivery to the newly
active processor as part of the switchover.
If the system's forwarding plane can receive BFD packets on behalf of
multiple processors (e.g., in a stacking topology where different
member switches have physical ports), then the system MUST ensure
that BFD packets received on any port are delivered to the currently
active processor, regardless of which physical member receives the
packet.
5.2. Resuming BFD Processing
Upon becoming the active processor, the newly active processor MUST
begin running the BFD state machine for each session using the most
recently available session state. Specifically:
* BFD control packets transmitted by the newly active processor MUST
use the same bfd.LocalDiscr, bfd.RemoteDiscr, and bfd.SessionState
values that were in use by the former active processor. From the
remote peer's perspective, there MUST be no observable change in
these values.
* The transmit interval MUST be set to the previously negotiated
bfd.DesiredMinTxInterval.
* The Detection Time calculation MUST continue using the previously
negotiated parameters.
* If BFD authentication is enabled (as specified in Section 6.7 of
[RFC5880]), the newly active processor MUST continue the
authentication sequence from the values maintained on the standby.
For Meticulous Keyed modes, the sequence number used in the first
transmitted packet MUST be the successor of the most recently
transmitted sequence number.
Li, et al. Expires 5 January 2027 [Page 6]
Internet-Draft BFD for Redundant CPs July 2026
5.3. Former Active Processor
If the former active processor is still partially operational during
a planned switchover, it MUST cease all BFD timer processing and
packet transmission before the newly active processor begins
transmitting. This prevents duplicate packets and conflicting state
transitions. If the former active processor has failed completely,
this condition is inherently satisfied.
5.4. Timing Requirements
For BFD sessions to survive a switchover, the newly active processor
MUST transmit a valid BFD control packet before the remote peer's
Detection Time expires. The Detection Time is defined in
Section 6.8.4 of [RFC5880] as the product of the remote peer's
bfd.RequiredMinRxInterval (or the negotiated transmit interval) and
bfd.DetectMult.
Because BFD transmissions from the local system cease during the
switchover interval, and the remote peer's Detection Timer continues
to run, the total time consumed by the switchover -- including
redirecting packet delivery, loading session state on the new
processor, and transmitting the first BFD packet -- MUST be less than
the remaining time on the remote peer's Detection Timer.
In practice, the switchover time SHOULD be significantly shorter than
the Detection Time to account for scheduling variance and processing
delays. A switchover that completes within a small fraction of the
Detection Time provides adequate margin for reliable operation.
6. Applicability
6.1. BFD Session Types
The approach described in this document applies to BFD sessions
operating in Asynchronous mode, which is the most widely deployed
operational mode. Sessions using Demand mode MAY also benefit,
although the timing considerations differ because the remote peer
does not maintain a continuous Detection Timer in Demand mode.
BFD Echo mode operates in the forwarding plane and is typically
unaffected by control plane switchover. The considerations in this
document generally do not apply to the Echo function.
The approach applies to both single-hop BFD sessions [RFC5881] and
multihop sessions. The specific BFD encapsulation does not affect
the requirements described here.
Li, et al. Expires 5 January 2027 [Page 7]
Internet-Draft BFD for Redundant CPs July 2026
For BFD sessions associated with Link Aggregation Groups as described
in [RFC7130], session state for each per-member-link BFD session
(micro-BFD session) MUST be individually maintained on the standby.
All micro-BFD sessions associated with a LAG MUST be covered by the
switchover.
6.2. Relationship to BFD Graceful Restart
The approach described in this document operates entirely within the
local system and does not require remote peer awareness or
cooperation. In contrast, the BFD interactions with Graceful Restart
described in [RFC5882] rely on the remote peer entering helper mode
and on control-protocol-level restart signaling.
The two approaches are complementary. A system MAY implement both:
using standby-based BFD state maintenance for local recovery, while
also signaling GR capability for interoperability with peers that
support it. When both are present, the local switchover can provide
sub-Detection-Time recovery independent of whether the remote peer
supports GR.
If a system successfully preserves BFD sessions across switchover as
described in this document, the Control Plane Independent (C) bit in
the BFD control packet (Section 4.3 of [RFC5882]) accurately reflects
that BFD is not sharing fate with the control plane, since BFD
processing survives the control plane restart.
7. Manageability Considerations
Implementations supporting BFD across redundant control planes SHOULD
provide the following operational visibility:
* An indication of whether BFD session state is currently being
maintained on the standby processor for each session, and whether
the standby state is current.
* Counters tracking the number of switchover events that occurred
and whether BFD sessions were preserved during each event.
* Notifications when the state on the standby processor falls behind
the active processor by more than a configurable threshold.
* A mechanism to administratively enable or disable BFD state
maintenance on the standby, on a per-session or system-wide basis.
Li, et al. Expires 5 January 2027 [Page 8]
Internet-Draft BFD for Redundant CPs July 2026
8. Security Considerations
Maintaining BFD session state on a standby processor introduces an
internal communication path that carries sensitive information
including discriminator values and, when authentication is enabled,
authentication sequence numbers and keying material.
The internal communication path between processors MUST be protected
against unauthorized modification. An attacker who can alter session
state on the standby could cause BFD sessions to fail upon switchover
or could prevent legitimate failure detection by injecting false
state. If BFD authentication is in use, compromise of replicated
authentication state could enable session spoofing.
When the communication path between processors traverses media that
may be subject to interception or modification -- for example, a
backplane fabric accessible to line cards running third-party
software -- the path SHOULD be protected using integrity and
confidentiality mechanisms such as MACsec [IEEE802.1AE] or IPsec
[RFC4301]. When the path is entirely within a trusted hardware
boundary (e.g., shared memory on the same board), hardware-level
access controls MAY be sufficient.
Switchover is time-critical. If the newly active processor is unable
to begin BFD processing promptly -- for instance, due to a denial-of-
service condition exhausting CPU resources -- BFD sessions will time
out despite having state available. Implementations SHOULD ensure
that switchover-related BFD processing is appropriately prioritized
and isolated from general-purpose control plane tasks.
9. IANA Considerations
This document has no IANA actions.
10. Normative References
[IEEE802.1AE]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks: Media Access Control (MAC) Security", IEEE
802.1AE-2018, 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Li, et al. Expires 5 January 2027 [Page 9]
Internet-Draft BFD for Redundant CPs July 2026
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
DOI 10.17487/RFC5881, June 2010,
<https://www.rfc-editor.org/info/rfc5881>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11. Informative References
[RFC5882] Katz, D. and D. Ward, "Generic Application of
Bidirectional Forwarding Detection (BFD)", RFC 5882,
DOI 10.17487/RFC5882, June 2010,
<https://www.rfc-editor.org/info/rfc5882>.
[RFC7130] Bhatia, M., Chen, M., Boutros, S., Binderberger, M., and
J. Haas, "Bidirectional Forwarding Detection (BFD) on Link
Aggregation Group (LAG) Interfaces", RFC 7130,
DOI 10.17487/RFC7130, February 2014,
<https://www.rfc-editor.org/info/rfc7130>.
[RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S.
Pallagatti, "Seamless Bidirectional Forwarding Detection
(S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016,
<https://www.rfc-editor.org/info/rfc7880>.
Acknowledgements
The authors would like to thank the members of the BFD Working Group
for their review and feedback.
Authors' Addresses
Zhiqiang Li
China Mobile
Beijing
100053
China
Email: lizhiqiangyjy@chinamobile.com
Li, et al. Expires 5 January 2027 [Page 10]
Internet-Draft BFD for Redundant CPs July 2026
Zongpeng Du
China Mobile
Beijing
100053
China
Email: duzongpeng@chinamobile.com
Junjie Wang
Centec
Shanghai
201203
China
Email: wangjj@centec.com
Wei Cheng
Centec
Shanghai
201203
China
Email: chengw@centec.com
Guoying Zhang
Centec
Shanghai
201203
China
Email: zhanggy@centec.com
Xun Sun
Inesa
Shanghai
200030
China
Email: sunxun@inesa.com
Chunhao Zhao
SAIA
Shanghai
200125
China
Email: chunhao.zhao@sh-aia.com
Li, et al. Expires 5 January 2027 [Page 11]