BGP reset - hard or soft?

There are many reasons as to why one would like to reset a BGP peer. One example would be when configuring inbound filtering for a specific peer - then a reset is necessary to allow BGP to apply the filtering on the received Update message.
As is well known, BGP uses incremental updates, so the reset is necessary to see ALL the previously sent update information and have it applied to immediately.

There are two ways to reset a peer: hard and soft.

Hard Reset
This will tear down the TCP connection between the peers and re-establish the connection with a BGP Open message and proceed with the regular message exchanges between peers.

This will severely impact network reachability as the cached routing information for the peer is invalidated by the hard reset and will potentially cause a failure in route lookups, while the neighbors exchange routing information again.

This should be the last resort, when attempting to reset a peer as it will impact the forwarding of packets.

A hard reset can be performed on a per peer basis, by specifying a particular peer address, or on all neighbors using the '*' instead of a peer address. Below is an example of a hard reset done on router R1.

R1#clear ip bgp 140.1.14.4
R1#
*Mar 30 10:16:37.175: %BGP-5-ADJCHANGE: neighbor 140.1.14.4 Down User reset
*Mar 30 10:16:37.175: %BGP_SESSION-5-ADJCHANGE: neighbor 140.1.14.4 IPv4 Unicast topology base removed from session  User reset
*Mar 30 10:16:37.361: %BGP-5-ADJCHANGE: neighbor 140.1.14.4 Up

As seen with the timestamps, the peer relationship is established almost immediately after the reset and the NLRI information is exchanged. Had this been routers carrying the full BGP Internet routing table - it might not have been quite as fast. As they chug away at exchanging routes with each other - traffic from clients are not reaching their intended destination or is maybe routed through a less desirable failover path.

Soft Reset
This allows for the neighbors to use function known as Route Refresh. This feature will allow for BGP peers to request an update without tearing down the entire neighbor relationship.

This feature, however, requires that both peers support the Route Refresh capability. This can be verified by a simple show command like shown in the output below.

R1#show ip bgp neighbors 140.1.14.4 | section Neighbor capabilities
  Neighbor capabilities:
    Route refresh: advertised and received(new)
    Four-octets ASN Capability: advertised and received
    Address family IPv4 Unicast: advertised and received
    Enhanced Refresh Capability: advertised and received
    Multisession Capability:
    Stateful switchover support enabled: NO for session 1

Here the router both advertises and receives the Route Refresh capability.

The soft reset is performed on a per peer basis in either the inbound or outbound direction. Inbound can be done in two ways, either dynamically, by sending out a refresh request to the peer, or by using stored information from that peer. The latter will allow the use of route refresh inbound with peers that do not support route refresh, but in turn will consume more memory resources as the neighbors inbound update message has to be cached.

To use the dynamic feature, both routers need to support route refresh capability. That is all. Most newer Cisco routers, that I know of, will support this feature out of the box - no additional configuration needed. However, to use the stored information, some additional configuration will have to be done for the neighbor.
Below I will configure the router R1 to store the inbound updates from router R4.

R1(config)#router bgp 1.23
R1(config-router)#neighbor 140.1.14.4 soft-reconfiguration inbound

After enabling the storing of updates in cache, the peering is cleared with a few debug options enabled beforehand.

R1#debug ip bgp in
BGP debugging is on for address family: IPv4 Unicast
R1#debug ip bgp 140.1.14.4 updates
R1#clear ip bgp 140.1.14.4 soft in
*Mar 30 10:39:27.303: BGP(0): start inbound soft reconfiguration for
*Mar 30 10:39:27.303: BGP(0): process 21.0.0.0/8, next hop 140.1.14.4, metric 0 from 140.1.14.4
*Mar 30 10:39:27.303: BGP(0): No inbound policy. Prefix 21.0.0.0/8 accepted unconditionally
<output omitted>
*Mar 30 10:39:27.303: BGP(0): complete inbound soft reconfiguration, ran for 0ms

Now with the soft-reconfig turned on for the peer, the router will do all routing policy matching towards the stored update information without dynamically requesting the peer to send an update.

Note that turning on the stored information feature will disable the dynamic route refresh feature - they are mutually exclusive.

There is only one way to do outbound route refresh. Seeing as the information sent out is already stored locally on the router, there would be no need for a separate database containing this information.

TL;DR
Hard reset is bad for the forwarding of packets - just use the soft reset instead.

This will either use route refresh to request an update from the peer, without affecting the forwarding plane, or it will use a stored update from local cache. And, of course, we prefer to use the route refresh method as the stored update method can adversely affect performance.

Some further reading on the matter
RFC 2918: Describes the initial implementation of the route refresh feature
RFC 7313: Describes the enhanced route refresh feature
BGP Soft Reset Enhancement: a document from Cisco detailing the Soft Reset feature in IOS