Generic Application of Bidirectional Forwarding Detection (BFD)
Extracted elements (29)
BFD is explicitly designed to have an advisory role to client protocols rather than replacing their liveness mechanisms. BFD does not carry application-specific information partly for architectural reasons and partly because BFD may have unpredictable latency characteristics, making it a poor transport mechanism.
BFD may interact with only one of a pair of systems for a particular client application without any ill effect, resulting in potentially asymmetric control protocol failure detection. This keeps the interaction loosely coupled and simple.
In hierarchical control protocol stacks (e.g., OSPF and IBGP), it is best for the protocol at the lowest point in the hierarchy to interact with BFD. Relaying fast failure detection to higher-level protocols like IBGP may be detrimental, as OSPF will naturally heal the path and the cost of a BGP peer state transition is high.
Running BFD inside a tunnel is recommended for OAM in tunneling and pseudowire protocols, as it exercises more aspects of the path than running BFD outside the tunnel. BFD packets should be addressed based on the tunnel endpoints if they are numbered.
Three deployment scenarios exist for BFD over multiple-link subnetworks: (1) complete decoupling where BFD runs only at layer N, (2) layer N-1 hints where the aggregation layer informs BFD of link failure for faster detection, and (3) aggregating per-link BFD sessions into a single layer N indication. Combinations are also valid.
BFD always interoperates at a basic level because asynchronous mode is mandatory and all other modes and functions are negotiated at run time. The interaction between BFD and client protocols is loosely coupled, so interoperability problems are very unlikely unless BFD is applied in contradictory ways.
For RIP, which does not maintain per-neighbor adjacency state, a BFD session failure for a neighbor should be handled by simulating expiration of the 'timeout' timer for each route installed from that neighbor. Routes with a next-hop different from the neighbor address may linger for up to 180 seconds unless implementations track all routes per neighbor.
A system MAY choose not to notify clients if a BFD session transitions from Up to Down and returns to Up within a reasonable period of time. If the BFD session does not return to Up state within that time frame, the clients SHOULD be notified that a session failure has occurred.
A system SHOULD NOT indicate a connectivity failure to a client if either the local or remote session state transitions to AdminDown, so long as the client has independent means of liveness detection. If the client has no independent means, the system SHOULD indicate a connectivity failure and assume the semantics of Down state.
An implementation SHOULD establish only a single BFD session per data protocol path, regardless of the number of applications wishing to utilize it. There is no additional value in having multiple BFD sessions to the same endpoints.
BFD authentication SHOULD be used and is strongly encouraged for OSPF Virtual Links (Section 10.1.3) and for EBGP sessions using BFD (Section 10.2).
BFD Control packets MUST be marked in the same way as the data packets they are protecting (e.g., for DiffServ), partly to ensure fate sharing with data traffic and partly to enable correct demultiplexing of initial packets before discriminator values have been exchanged.
BFD sessions supporting OSPF and IS-IS across a single IP hop MUST operate in accordance with BFD for IPv4 and IPv6 Single Hop (RFC 5881). For OSPF Virtual Links, which may traverse an arbitrary number of hops, the multihop BFD mechanism (RFC 5883) MUST be used.
BFD state machine transitions that occur during the process of bringing up a BFD session (including process restart situations) SHOULD NOT cause a connectivity failure notification to be sent to client applications.
For control protocols supporting multiple data protocols with a shared topology, when a BFD session transitions Up to Down, the path SHOULD be considered failed for all data protocols and a topology change signaled. Otherwise, traffic for the failed data protocol would be black-holed indefinitely.
For control protocols without planned restart signaling, if the restart is planned, an implementation MAY adjust BFD session timing parameters so that the Detection Time exceeds the restart period. The restarting system SHOULD NOT send any BFD Control packets until there is a high likelihood that neighbors know a Graceful Restart is taking place.
For non-protocol functions such as static routes, if the remote system is known or presumed BFD-capable and the BFD session is not Up, appropriate action SHOULD be taken (e.g., withdrawing the static route). If the remote is known not to support BFD, such action SHOULD NOT be taken.
If a BFD session transitions from Up to AdminDown (or the remote signals AdminDown), clients SHOULD NOT take any control protocol action. For other Up to Down transitions, the control protocol SHOULD signal the lack of connectivity, using an explicit path-state mechanism if available, or emulating a control protocol timeout if not.
If BFD is fate-independent of the control plane (C bit set in both directions), a BFD session failure during Graceful Restart SHOULD cause the Graceful Restart to be aborted and a topology change to be signaled, to avoid black holes.
If either the local or remote session state is AdminDown, establishment of a control protocol adjacency MUST be allowed; BFD has been administratively disabled and must not block adjacency formation.
If multiple control protocols wish to establish BFD sessions with the same remote system for the same data protocol, all MUST share a single BFD session.
If the control protocol supports planned restart signaling and a BFD session failure occurs during such a restart, the Graceful Restart SHOULD NOT be aborted and the session failure SHOULD NOT result in a topology change, since BFD shares fate with the control plane and the failure is a side effect of the restart.
The establishment of control protocol adjacencies SHOULD be blocked if both systems are willing to establish a BFD session but a BFD session cannot be established. If it is believed the neighboring system does not support BFD, adjacency establishment SHOULD NOT be blocked.
When deconfiguring BFD from a system, the session SHOULD be placed into AdminDown state and maintained for a Detection Time before ceasing BFD Control packet transmission, to avoid triggering an unintended session failure on the remote system.
When taking a planned outage on a path over which BFD is running, the BFD session SHOULD be taken to AdminDown state prior to the outage. The system asserting AdminDown SHOULD maintain that state for at least one Detection Time to ensure the remote system is aware.
An adaptation layer between the BFD state machine and client applications can implement session state hysteresis, hiding rapid Up/Down/Up transitions from clients. This is useful for supporting process restarts without necessitating complex protocol mechanisms.
BFD is intended to protect a single data protocol and is encapsulated within that protocol. A pair of systems may run multiple BFD sessions over the same topology if they support different protocols (e.g., separate sessions for IPv4 and IPv6 over the same link).
The Control Plane Independent 'C' bit in BFD Control packets announces whether BFD shares fate with the control plane. If the C bit is set in both directions, BFD is implemented in the forwarding plane and control plane restarts should not affect the BFD session.
This specification does not raise any additional security issues beyond those of the specifications in its normative references (the BFD base specification and encapsulation documents). BFD authentication is strongly encouraged for use with OSPF Virtual Links and BGP sessions.