"Routing Warm Reboot with Dynamic Reconciliation Signal" document

[heidinet2007]

The document is a brief description on how to add a dynamic EOIU signal to indicate the start of fpmsyncd to AppDB reconciliation

[msftclas]

All CLA requirements met.

[jipanyang]

Could you add test plan as well?

[jipanyang]

While walking through FRR code with the proposed change in this design document, I noticed that:

1. eoiu mark from BGP will only be generated when bgp update-delay is configured. This is the prerequisite, but missing in the design.
2. all the proposed changes are embedded into the core processing logic of bgp/zebra route processing, quite some special handlings are needed here and there. The risk is relatively high, also how to keep compatible with FRR upstream will be a big issue.

[jipanyang]

I would recommend taking another approach to optimize the timing of route reconciliation in fpmsyncd upon warm-reboot/warm-restart.

1. Similar to restore_neigbors.py for neigborsyncd, start a eoiu_reconciliation.py for bgp docker.

2. The script check bgp neighbor state via cli interface periodically (every 1 second)
   It looks for explicit EOR and implicit EOR (keep alive after established) in the json output of show ip bgp neighbors A.B.C.D json

3. Once the script has collected all needed EORs, it set a EOIU flag in stateDB.

4. fpmsyncd could hold a few seconds (2~5 seconds) after getting the flag before starting routing reconciliation.
   2-5 seconds should be enough for all the route to be synced to fpmsyncd from bgp. If not, the system probably is already in wrong state.

5. For any reason the script failed to set EOIU flag in stateDB, the current warm_restart bgp_timer will kick in later.

This approach may have a few more seconds delay compared with the FRR embedded EOIU solution, but simple and less risk. It also shortens the reconciliation delay by one order of magnitude in most cases compared with the fixed warm_restart bgp_timer.