OSPF Bidirectional Forwarding Detection (BFD) Strict-Mode
updates
- rfc-2328 — OSPF Version 2
Extracted elements (20)
Strict-mode is designed so that adjacency blocking applies only when both neighbors advertise BFD strict-mode, allowing OSPF operation in environments where not all routers support or have BFD enabled. This bilateral signaling approach preserves interoperability.
The Local Interface IPv4 Address TLV was introduced to solve the problem that OSPFv3 uses IPv6 link-local addresses for Hello packets even in IPv4 AF instances, meaning the neighbor's IPv4 address needed for BFD session setup is not otherwise available during Init state.
A router that does not support this specification ignores the B-bit in received LLS blocks and does not set it in its own Hellos, so its neighbors supporting this specification will not invoke strict-mode with it, resulting in behavior identical to pre-specification operation with no backward compatibility issues.
The OSPF BFD strict-mode extensions and procedures also apply to adjacencies over virtual links, using BFD multi-hop (RFC 5883) procedures.
A receiver MUST ignore the B-bit (i.e., not operate in strict-mode for BFD) when the Local Interface IPv4 Address TLV is not present in OSPFv3 Hello messages for OSPFv3 IPv4 AF instances.
A router MUST include the LLS block with the B-bit set in the LLS Type 1 Extended Options and Flags in its Hello and DD packets when OSPF BFD strict-mode is enabled on the link.
An implementation MUST NOT wait for BFD session establishment in Init state unless OSPF BFD strict-mode is enabled by the operator on the interface and the specific neighbor indicates OSPF BFD strict-mode capability via the LLS Type 1 Extended Options and Flags advertised in the Hello packet.
An implementation MUST support OSPF adjacency formation and operations with a neighbor router that does not advertise the OSPF BFD strict-mode capability, ensuring backward compatibility with non-supporting routers.
An implementation SHOULD report the BFD session status along with the OSPF Init adjacency state when OSPF BFD strict-mode is enabled, and support logging of neighbor state transitions that include BFD events.
If an adjacency is already up (Full or 2-Way) with a neighbor that also supports OSPF BFD strict-mode, an implementation SHOULD NOT bring this adjacency down into Init state when BFD is newly enabled, to avoid disruption to routing operations.
If authentication is being used in the OSPF routing domain, the Cryptographic Authentication TLV (RFC 5613) MUST also be used to protect the contents of the LLS block carrying the B-bit.
Implementations supporting OSPF BFD strict-mode for OSPFv3 IPv4 AF instances MUST include the Local Interface IPv4 Address TLV in the LLS block advertised in Hello packets whenever the B-bit is also set.
Once the OSPF state machine has moved beyond Init state, any change in the B-bit advertised in subsequent Hello packets MUST NOT result in any trigger in either the OSPF adjacency or the BFD session management.
When BFD is enabled but OSPF BFD strict-mode has not been signaled by both neighbors, an implementation SHOULD start BFD session establishment only in 2-Way or greater state.
When both graceful restart and OSPF BFD strict-mode are deployed together, it is RECOMMENDED that GR timers are set to provide sufficient time to allow for normal BFD session establishment delays, since adjacency formation is delayed until BFD session establishment.
The B-bit is defined in the LLS Type 1 Extended Options and Flags (bit position 0x00000010) and is included in Hello and Database Description (DD) packets to signal that BFD is enabled on the link and that the router requests OSPF BFD strict-mode.
This document assigns the B-bit at position 0x00000010 in the 'LLS Type 1 Extended Options and Flags' registry, and assigns Type 21 to the Local Interface IPv4 Address TLV in the 'Link Local Signaling TLV Identifiers (LLS Types)' registry.
Inappropriate use of the B-bit in the LLS block of an OSPF Hello message could prevent OSPF adjacency formation or cause failure to detect bidirectional forwarding failures. If authentication is used in the OSPF routing domain, the Cryptographic Authentication TLV MUST also be used to protect the LLS block contents.
In OSPF BFD strict-mode, the neighbor state machine is augmented so that BFD session establishment is requested upon entry to Init state, and progression from Init to 2-Way is blocked until the BFD session is successfully established. The B-bit is only evaluated in Init state; changes to it in subsequent Hellos have no effect.
The Local Interface IPv4 Address TLV has Type 21, Length 4 octets, and a single 32-bit field carrying the primary IPv4 address of the local interface. It is carried in the OSPFv3 LLS block for IPv4 AF instances.