SBFD for SRv6 TE Policy

BFD technologies are relatively mature. However, if a large number of BFD sessions are configured to detect links, the negotiation time of the existing BFD state machine is prolonged, adversely affecting system performance. To address this issue, a simplified BFD mechanism called seamless bidirectional forwarding detection (SBFD) is introduced to detect SRv6 TE Policies. With a simplified BFD state machine, SBFD shortens the negotiation time and improves network-wide flexibility.

SBFD Implementation

Figure 1 shows how SBFD is implemented through the communication between an initiator and a reflector. Before link detection, the initiator and reflector exchange SBFD control packets to advertise information, such as the SBFD discriminator. In link detection, the initiator proactively sends an SBFD packet, and the reflector loops this packet back. The initiator then determines the local status based on the looped packet.

The initiator is responsible for detection and runs an SBFD state machine and a detection mechanism. The state machine only has up and down states, so the initiator can only send packets in the up or down state and only receive packets in the up or admin down state.

The initiator first sends an SBFD packet with an initial down state and a destination port number of 7784 to the reflector.
The reflector does not run any SBFD state machine or detection mechanism. Therefore, it does not proactively send any SBFD echo packet, but constructs an SBFD packet to be looped back instead.

After receiving the SBFD packet sent by the initiator, the reflector checks whether the SBFD discriminator carried by the packet matches the locally configured global SBFD discriminator. If they do not match, the packet is discarded. If they match and the reflector is in the working state, the reflector constructs an SBFD packet to be looped back. If they match and the reflector is not in the working state, the reflector sets the packet state to admin down.

Figure 1 SBFD Implementation

SBFD State Machine of the Initiator

The initiator's SBFD state machine has only two alternating states: up and down. Figure 2 shows how the SBFD state machine works.

Figure 2 SBFD state machine of the initiator

Initial state: Before an SBFD packet is sent from the initiator to the reflector, the initial state on the initiator is down.
State transition: After receiving a looped packet that is in the up state, the initiator sets the local state to up. If the initiator receives a looped packet that is in the admin down state, it sets the local state to down. However, if the initiator does not receive any looped packet before the timer expires, it also sets the local state to down.
State retention: If the initiator is in the up state and receives a looped packet that is also in the up state, the initiator remains in the local up state. If the initiator is in the down state and receives a looped packet that is in the admin down state or receives no packet after the timer expires, the initiator remains in the local down state.

Implementation of SBFD for SRv6 TE Policy

Unlike RSVP-TE, which exchanges Hello messages between forwarders to maintain tunnel status, an SRv6 TE Policy cannot maintain its status in the same way. An SRv6 TE Policy is established immediately after the headend delivers a SID stack. It will not go down unless it is withdrawn. Therefore, seamless bidirectional forwarding detection (SBFD) for SRv6 TE Policy is introduced for SRv6 TE Policy fault detection. SBFD for SRv6 TE Policy is an end-to-end fast detection mechanism that quickly detects faults on the link through which an SRv6 TE Policy passes.

Figure 3 shows the SBFD for SRv6 TE Policy detection process.

Figure 3 SBFD for SRv6 TE Policy
Click to enlarge

The SBFD for SRv6 TE Policy detection process is as follows:

After SBFD for SRv6 TE Policy is enabled on the headend, the mapping between the destination IPv6 address and discriminator is configured on the headend. If multiple segment lists exist in the SRv6 TE Policy, the remote discriminators of the corresponding SBFD sessions are the same.
The headend sends an SBFD packet encapsulated with a SID stack corresponding to the SRv6 TE Policy.
After the endpoint device receives the SBFD packet, it returns an SBFD reply through the shortest IPv6 link.
If the headend receives the SBFD reply, it considers that the corresponding segment list in the SRv6 TE Policy is normal. Otherwise, it considers that the segment list is faulty. If all the segment lists referenced by a candidate path are faulty, SBFD triggers a candidate path switchover.

SBFD return packets are forwarded over IPv6. If the primary paths of multiple SRv6 TE Policies between two nodes differ due to different path constraints but SBFD return packets are transmitted over the same path, a fault in the return path may cause all involved SBFD sessions to go down. As a result, all the SRv6 TE Policies between the two nodes go down. The SBFD sessions of multiple segment lists in the same SRv6 TE Policy also have this problem.

By default, if HSB protection is not enabled for an SRv6 TE Policy, SBFD detects all the segment lists only in the candidate path with the highest preference in the SRv6 TE Policy. With HSB protection enabled, SBFD can detect all the segment lists referenced by candidate paths with the highest and second highest priorities in the SRv6 TE Policy. If all the segment lists referenced by the candidate path with the highest preference are faulty, a switchover to the HSB path is triggered.

Enabling SBFD Traffic to Bypass Local Protection Paths

In a scenario where SBFD for SRv6 TE Policy is deployed, if the segment lists of the primary candidate path all fail and a local protection path (for example, a TI-LFA or TE FRR path) exists, SBFD remains in the up state, and data traffic is switched to the TI-LFA or TE FRR path. However, the performance such as the bandwidth/latency of the TI-LFA or TE FRR path may be unstable, preventing the path from meeting the strict SLA requirements of high-value private line services. To resolve this problem, you can enable SBFD traffic to bypass local protection paths. In this way, SBFD goes down if the segment lists of the primary candidate path all fail, triggering the candidate path to also go down. As a result, traffic is switched to a backup candidate path or another SRv6 TE Policy.

Application of SBFD in a Network Slicing Scenario

In an SRv6 TE Policy network slicing scenario, SBFD can detect an SRv6 TE Policy based on a network slice. The detection process is as follows:

After SBFD for SRv6 TE Policy is enabled on the headend, SBFD packets are forwarded based on the network slice.
After receiving an SBFD packet, the endpoint device sends an SBFD reply packet.
If the headend receives the SBFD reply packet, it considers the SRv6 TE Policy normal. Otherwise, it considers the SRv6 TE Policy faulty and sets SBFD to down.

In this scenario, you must ensure that network slicing is deployed for the SRv6 TE Policy in E2E mode and that the primary path is working properly. Otherwise, SBFD fails.