Implement BGP read-only mode

Evaluate implementation of BGP read-only mode described below for better performance:

References:

• BGPCEP-483
• BGPCEP-502
• http://blog.ine.com/2010/11/22/understanding-bgp-convergence/
• http://kispernet.com/apps/Books/BGP%20Design%20and%20Implementation.pdf

"The BGP Router process can be in one of three states, depending on the IOS releases, BGP,
and router states, with increasing functionality and memory use:
• Read-only—BGP accepts updates only from peers. It does not calculate the best path,
nor does it install routes into the routing table. This reduces transient memory use.
During initial router bootup, BGP is typically in this mode.
• Calculating the best path—BGP accepts updates and runs through the pathselection
process, which generally is associated with the caching of some structures
and thus increased transient memory use. This typically is the transition mode.
• Read and write—BGP accepts updates, calculates the best path, installs the routes
into the IP routing table, and generates updates to be sent to peers. More transient
memory is needed. This is the normal BGP mode."

"BGP Read-Only Mode
Originally, when BGP peers came online and accepted prefixes, the path-selection process
would begin running before all the path information had been received from a peer. The
BGP process would begin advertising prefix information to peers based on the outcome of
the decision process. As more path information was received, the outcome from the
decision process for a particular prefix resulted in best-path changes. This in turn resulted
in multiple updates for the same prefix as the best path changed, which was inefficient.
Another similar issue is that the BGP process can begin advertising NLRI with a specific
attribute set, but not all NLRI has been received for that attribute combination. This reduces
the efficiency of the update packing.
This inefficiency can be removed by having a BGP peer remain in read-only mode until it
stops receiving updates. As soon as the full path information has been received from a
remote peer, the decision process can choose the best path for a prefix before sending any
BGP Updates. A BGP peer in read-only mode only receives updates; it doesn’t advertise
any prefixes. An upper bound of 2 minutes is placed on a BGP peer remaining in read-only
mode, based on the session initiation.
The addition of read-only mode also allows for optimal update packing. If the BGP router
is sending updates before receiving full path information from all peers, all the NLRI for a
particular attribute combination might not have been received before the BGP router begins
sending updates. After the BGP peer finishes receiving the initial routing information from
a peer, the BGP session changes to read-write mode. This allows the BGP router to run the
decision process and send updates. You can configure the maximum amount of time that
BGP stays in read-only mode using the command bgp update-delay RO_Limit.
RO_Limit is a limit on how long a BGP peer can remain in read-only mode. The BGP
process automatically leaves read-only mode when it receives a BGP keepalive, which
indicates that the initial routing update has completed. The end of the initial routing update
can be detected because the Cisco BGP implementation sends the entire routing update
before sending a BGP keepalive. The arrival of the first BGP keepalive signals the end of
the initial routing update. As soon as the BGP decision process has completed, the IP
routing table and CEF table are appropriately updated."