I need a quick refresh this morning...
From my understanding, the ONLY purpose of using eBGP soft reconfiguration is to facilitate the application of a new policy, or a change to an existing one, with a specified BGP neighbor.
The way it facilitates this is to store the entire BGP table locally for future use as it is sent from the eBGP neighbor, and then applying the new policies to that, instead of having the neighbor resend the entire BGP table all over again after the neighborship is reset. (The neighborship has to be reset to apply policy changes).
For this to happen, though, the neighbor has to be aware of the fact that you are configured for soft reconfguration inbound and that you have the capability, so it wont resend all its BGP updates if the BGP connection is reset.
Is all that correct?
Also, it requires a lot of memeory. If a router is accepting the entire Internet routing table from the eBGP neighbor, it probably will take a massive amount of memory to store the BGP table -- how much, I dont know.
Is that correct and is there a way of knowing how much memor will be used without labbing it up?
I believe that there is no need for your customer to enable the Soft Reconfiguration enabled. It only doubles the memory requirements of their BGP process and it does not provide them with any additional functionality or advantage.
As a matter of fact, with the current versions of BGP implemented in recent IOSes, I do not see any reason to use the Soft Reconfiguration at all. It can be more than adequately and far more effectively replaced with a combination of Route Refresh and Outbound Route Filtering capability.
The NSF/NSR techniques are somewhat different stuff. They assist during a route processor switchover so that the router continues routing packets and its neighbors continue forwarding packets to the router while the routing protocol sessions temporarily flap. The purpose of NSF/NSR is to provide stability and functionality of a network even during a route processor switchover. The purpose of the Soft Reconfig was to allow reapplying inbound BGP policies without tearing down the BGP peering. Though these two purposes seem similar, they are not identical.