Using disaggregated route information bases ('ribs') to increase the resiliency of protocols such as the border gateway protocol ('bgp')

Abstract

The challenge of isolating a protocol peer(s) from routing information churn caused by to a peering protocol (e.g., due to updating the peering protocol, due to a bug in the peering protocol, due to a crash in the peering protocol, etc.) is solved by using a separate data store to isolate the protocol peer(s) from the peering protocol. The separate data store may: (a) receive, from at least one of the outside peering devices, incoming routing information; (b) store the incoming routing information received in a first storage system; (c) provide a copy of at least some of the stored incoming routing information received to a second storage system used by a process for selecting routes using the routing information, the process generating state information to be distributed (e.g., one or more routes with BGP properties (which may include one or more selected routes) and a set of outside peers to distribute them to) and storing the state information in the second storage system; (d) receive a copy of the state information generated and stored by the process; (e) store the received copy of the state information in the first storage system; and (f) provide at least some information from the copy of the state information to at least one outside peer device in accordance with a route advertisement process, regardless of a state or status of the process for selecting routes.