Add paths filter doc

website/content/docs/enterprise/replication.mdx

@@ -47,9 +47,19 @@ replication that is configured between the primary and secondary. These types
 of relationships are either **disaster recovery** or **performance**
 relationships.
 
-## Performance Replication and Disaster Recovery (DR) Replication
+![](/img/replication-overview.png)
+
+The following table shows a capability comparison between disaster recovery and performance replications. 
+
+| Capability                                                                                                           | Disaster Recovery | Performance                                                                                                                                                                        |
+| -------------------------------------------------------------------------------------------------------------------- | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Mirrors the configuration of a primary cluster                                                                       | Yes               | Yes                                                                                                                                                                                |
+| Mirrors the configuration of a primary cluster’s backends (i.e., auth methods, secrets engines, audit devices, etc.) | Yes               | Yes                                                                                                                                                                                |
+| Mirrors the tokens and leases for applications and users interacting with the primary cluster                        | Yes               | No. Secondaries keep track of their own tokens and leases. When the secondary is promoted, applications must reauthenticate and obtain new leases from the newly-promoted primary. |
+| Allows the secondary cluster to handle client requests                                                               | No                | Yes                                            |                                                                                  
+
+## Performance Replication
 
-_Performance Replication_:
 In performance replication, secondaries keep track of their own tokens and leases
 but share the underlying configuration, policies, and supporting secrets (K/V values,
 encryption keys for `transit`, etc).
@@ -61,7 +71,48 @@ in `transit`, etc.) can be satisfied by the local secondary, allowing Vault to s
 relatively horizontally with the number of secondaries rather than vertically as
 in the past.
 
-_Disaster Recovery (DR) Replication_:
+### Paths Filter 
+
+The primary cluster's mount configuration gets replicated across its secondary
+clusters when you enable performance replication. In some cases, you may not
+want all data to be replicated. For example, your primary cluster is in the EU
+region, and you have a secondary cluster outside of the EU region. [General Data
+Protection Regulation (GDPR)](https://www.eugdpr.org/) requires that personally
+identifiable data not be physically transferred to locations outside the
+European Union unless the region or country has an equal rigor of data
+protection regulation as the EU.
+
+To comply with GDPR, leverage Vault's **paths filter**  feature to abide by
+data movements and sovereignty regulations while ensuring performance access
+across geographically distributed regions. 
+
+You can set filters based on the mount path of the secrets engines and
+namespaces.
+
+![Performance Replication - primary](/img/vault-mount-filter-7.png)
+
+In the above example, the `EU_GDPR_data/` path and `office_FR` namespace will
+not be replicated and remain only on the primary cluster.
+
+On a similar note, if you want to avoid secondary cluster's data to be
+replicated, you can mark those secrets engine and/or auth methods **local**.
+Local secrets engines and auth methods are not replicated or removed by
+replication.
+
+**Example:** When you enable a secrets engine on a secondary cluster, use the
+`-local` flag.  
+
+```shell-session 
+$ vault secrets enable -local -path=us_west_data kv-v2
+```
+
+-> **Learn:** Refer to the [Performance Replication with Paths
+Filter](https://learn.hashicorp.com/tutorials/vault/paths-filter) tutorial for 
+step-by-step instructions.
+
+
+## Disaster Recovery (DR) Replication
+
 In disaster recovery (or DR) replication, secondaries share the same underlying configuration,
 policy, and supporting secrets (K/V values, encryption keys for `transit`, etc) infrastructure
 as the primary. They also share the same token and lease infrastructure as the primary, as
@@ -71,12 +122,6 @@ original primary on the election of the DR secondary.
 DR is designed to be a mechanism to protect against catastrophic failure of entire clusters.
 They do not forward service read or write requests until they are elected and become a new primary.
 
-| Capability                                                                                                           | Disaster Recovery | Performance                                                                                                                                                                        |
-| -------------------------------------------------------------------------------------------------------------------- | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Mirrors the configuration of a primary cluster                                                                       | Yes               | Yes                                                                                                                                                                                |
-| Mirrors the configuration of a primary cluster’s backends (i.e.: auth methods, secrets engines, audit devices, etc.) | Yes               | Yes                                                                                                                                                                                |
-| Mirrors the tokens and leases for applications and users interacting with the primary cluster                        | Yes               | No. Secondaries keep track of their own tokens and leases. When the secondary is promoted, applications must reauthenticate and obtain new leases from the newly-promoted primary. |
-| Allows the secondary cluster to handle client requests                                                               | No                | Yes                                                                                                                                                                                |
 
 For more information on the capabilities of performance and disaster recovery replication, see the Vault Replication [API Documentation](/api/system/replication).