The customer would like to JTAC provide the best practice to configure both BFD and graceful helper for the BGP neighbor and also clarify the Juniper Technical document statement.

Juniper Technical document statement:

https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/topic-map/bfd-for-bgp-session.html

Configuring both BFD and graceful restart for BGP on the same device is counterproductive. When an interface goes down, BFD detects this instantly, stops traffic forwarding and the BGP session goes down whereas graceful restart forwards traffic despite the interface failure, this behavior might cause network issues. Hence we do not recommend configuring both BFD and graceful restart on the same device.



https://www.juniper.net/documentation/us/en/software/junos/high-availability/topics/task/graceful-restart-for-routing-protocols-configuring.html

Do not configure both Bidirectional Forwarding Detection (BFD) for BGP and graceful restart for BGP. Routing performance may be sub-optimal if you do this.

Further explanation to the customer:

There is no RFC or any standard document to define or coordinate the interactions between BFD and Graceful-restart, Juniper designs the programming logic based on the best practice. So, the behavior might be different depending on the platform and Junos version.

BFD protocol is designed to speed up the network convergence when it detects the forward plane issue, such as link failure. However, GR helper is designed to retain the BGP neighbor prefixes when the BGP neighbor control plane got some issue, such as RPD restart. It is not easy to coordinate the behavior in all scenarios since it is hard to judge whether it is control plane issue or forwarding plane problem in all conditions.

Based on the test: MX204 with Junos 21.4R2-S1.4, no-matter the user configures “dont-help-shared-fate-bfd-down” knob or not, the system can detect BFD failure due to Layer2 packet drop and treat it as the forwarding-plane failure, so it is making no sense to keep the stale routes for 120 seconds and the system immediately flush the routes even GR helper is enabled (by default) in the control plane. 

However, in MX960, depending on the Junos version and Line-card model, the system might not be able to determine whether this is a remote router control-plane issue, or forwarding-plane issue, or there is no alternative path in the FIB. In this case, the GR helper will retain the stale routes for 120 seconds. 

In summary:

1) For the control plane thing, such as RPD restart in BGP neighbor device, it is making sense to retain the stale prefixes for a while (e.g., default 2 mins) to wait the neighbor device control plane coming back since the forwarding plane is still working, and the traffic still can go through.

2) For forwarding plane issue, such as L2 dis-connected in this case, Junos detected it and immediately flush the routes no-matter you configured “dont-help-shared-fate-bfd-down” knob, it is also making sense to speed up the convergence. NOTE, this routing table flush request is from the Junos Fundamental codes since this portion of codes detected the connection failure. It should not be classified as a bug.

However, the programming codes are not like human being, who has intelligence to judge control plane thing or forwarding plane issue, the Junos codes are not guaranteed 100% making the correct decision for different scenarios, all based on the best practice.