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.
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.
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.
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.
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.
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.
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.
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:
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.