API design prevents correct GR Restarting Speaker deferral with multiple peers

[fujita]

RFC 4724 Section 4.2 requires the Restarting Speaker to defer route selection for a family until End-of-RIB is received from all GR-capable peers. This requires knowing all GR peer configurations before any session is established.

The current API model (start_bgp followed by repeated add_peer calls) starts connections immediately as peers are added. When multiple GR-capable peers are configured, the first peer may establish and begin sending routes before the remaining peers are added, making it impossible to correctly initialize route selection deferral across all peers.

The correct fix is to separate the configuration phase from the connection-start phase (e.g., split start_bgp into init_bgp and start_bgp), so the daemon can initialize deferral state for all configured GR families before any connection starts.

[YutaroHayakawa]

I think the initialization/start separation is also helpful for the case where we generate routes with AddPath API. After restart, we also need to restore all self-originated routes before peer establishment, otherwise GoBGP sends EOR too early.

We can guarantee this ordering in the current API by restoring all routes before adding neighbors, but from the user's perspective, this is not obvious. Having explicit sync phase is much easier to understand.

[fujita]

Agreed. A workaround is to add all peers in admin-down state before bringing them up, but that is a classical network operations style API and not intuitive for many of GoBGP's current use cases.

Splitting start_bgp into init_bgp and start_bgp is a breaking API change that would normally call for a major version bump, but only six months have passed since the last major release, which makes that less than ideal.

To avoid breaking existing users, we could introduce init_bgp as an optional initialization step while continuing to support the current flow where start_bgp is called directly without a prior init_bgp.

Opinions?

[YutaroHayakawa]

We (to be clear I'm talking with Cilium BGP maintainer's hat) are ok with the optional API like having global flag to control it. We're happy to help testing it.