Reduce route selection deferral timer for bgp graceful restart

[shi-su]

Why I did it

There are scenarios that End-of-RIB comes from a part of the peers arrives after reconciliation. In such scenarios, if the route selection deferral timer has the default value of 360 seconds, FRR would not set up routes and all routes would be removed after reconciliation. This PR reduces the route selection deferral timer so that at least routes to parts of the peers get restored at the point of reconciliation.

Fix #7488

How I did it

Reduce route selection deferral timer for bgp graceful restart to 45 seconds.

How to verify it

Which release branch to backport (provide reason below if selected)

• 201811
• 201911
• 202006
• 202012

Description for the changelog

A picture of a cute animal (not mandatory but encouraged)

[zhenggen-xu]

If we disable "route selection deferral timer", the restarting speaker could get into the situation where it only gets some peers EOR and then do route selection too early, and then had some unnecessary routes updates at BGP layer. This could propagate to peers and impact traffic.

Can we just reduce this timer (route selection deferral timer) to some value that fit your environment? The default seemed to be 360 seconds.

Also, the original issue (#7488) where we don't get EOR after reconciliation (120 seconds) from one peer is also bit odd as that timer value is very big already.

[lguohan]

i agree with @zhenggen-xu, if the deferral time is too small, it could cause negative impact by send the routes to early to the peers. I think this timer can be around 90 seconds so that it will timeout before fpmsync reconcilation timeout, meanwhile not too small so that given peer a chance to send EOR.

meanwhile, I do think we need to understand when EOR is not received after 120 seconds.

[shi-su]

this timer can be around 90 seconds so that it will timeout before fpmsync reconcilation timeout, meanwhile not too small so that given peer a chance to send EOR.

One tricky thing about this selection deferral timer is that it seems to take effect per peer and starts counting from a peer to get established. That is to say, we are unable to control its timeout in the timeline of reconciliation since we do not know when the first peer gets established.

I am updating the selection deferral timer to 15 seconds, as per my observation, the EOR from all peers is likely to arrive within 15 seconds from the first one to get established. Assuming the reconciliation timer has a 15 seconds margin that the first peer should get established at least 15 seconds before the reconciliation happens, such a deferral timer should address the issue while not impose a negative effect.

In the meantime, we can put some effort into understanding why EOR comes after 120 seconds.

[lguohan]

as per my observation, the EOR from all peers is likely to arrive within 15 seconds from the first one to get established

is this valid? should we give more tolerance here?

[shi-su]

as per my observation, the EOR from all peers is likely to arrive within 15 seconds from the first one to get established

is this valid? should we give more tolerance here?

I think we need to have an elaborate analysis on the timing to find a good value for the timer here. Let me collect more data and will circle back with my findings.

[shi-su]

I collected some data on the KVM platform about the timing of the first peer gets established after the reconciliation timer starts, and the interval between the first peer gets established and the last EOR is received. The distribution is presented in the figure attached. The results show that the typical time for the first peer to be established after the reconciliation timer starts is about 70 seconds, whereas the interval between the first peer gets established and the last EOR received ranges between 5 to 20 seconds. So I think 25 seconds would be a reasonable choice for the selection deferral timer to ensure some routes can be selected while avoiding unnecessary route updates.

I think another method might be extending the reconciliation timer to the same value as the selection deferral timer. This could better prevent running into the empty route table issue. The price is that the control plane might come back a bit later.

[judyjoseph]

Please raise a new PR for 202111 branch, as this patch cannot be cleanly cherry-picked.

[shi-su]

Please raise a new PR for 202111 branch, as this patch cannot be cleanly cherry-picked.

This PR is already included in 202111 branch, no need for cherry-picking.