Fixes according to Freddy's review/comments

website/content/docs/connect/cluster-peering/index.mdx

@@ -34,9 +34,9 @@ Regardless of whether you connect your clusters through WAN federation or cluste
 | Connects clusters owned by different operators     |    ❌    |    ✅      |
 | Functions without declaring primary datacenter     |    ❌    |    ✅      |
 | Replicates exported services for service discovery |    ❌    |    ✅      |
+| Forwards service requests for service discovery    |    ✅     |    ❌     |
 | Shares key/value stores                            |    ✅     |    ❌     |
 | Uses gossip protocol                               |    ✅     |    ❌     |
-| Forwards service requests for service discovery    |    ✅     |    ❌     |
 
 ## Beta release features and constraints
 
@@ -50,9 +50,10 @@ The cluster peering beta includes the following features and functionality:
 Not all features and functionality are available in the beta release. In particular, consider the following technical constraints:
 
 - Mesh gateways for _server to server traffic_ are not available.
+- Services with node, instance, and check definitions totaling more than 4MB cannot be exported to a peer.
 - Dynamic routing features such as splits, custom routes, and redirects cannot target services in a peered cluster.
 - Configuring service failover across peers is not supported for service mesh.
 - Consul datacenters that are already federated stay federated. You do not need to migrate WAN federated clusters to cluster peering.
 - The `consul intention` CLI command is not supported. To manage intentions that specify services in peered clusters, use [configuration entries](/docs/connect/config-entries/service-intentions).
 - Accessing key/value stores across peers is not supported.
-- Non-enterprise Consul instances cannot sync services with namespaces outside of the `default` namespace.
+- Because non-Enterprise Consul instances are restricted to the `default` namespace, Consul Enterprise instances cannot export services from outside of the `default` namespace to non-Enterprise peers.

website/content/docs/connect/gateways/mesh-gateway/service-to-service-traffic-peers.mdx

@@ -12,7 +12,7 @@ description: >-
 
 Mesh gateways are required for you to route service mesh traffic between different Consul clusters. Clusters can reside in different clouds or runtime environments where general interconnectivity between all services in all clusters is not feasible.
 
-Unlike mesh gateways for datacenters and partitions, mesh gateways for cluster peering decrypts data to HTTP services within the mTLS session. Data must be decrypted in order to apply dynamic routing rules configured in the destination cluster.
+Unlike mesh gateways for datacenters and partitions, mesh gateways for cluster peering decrypt data to HTTP services within the mTLS session. Data must be decrypted in order to evaluate and apply dynamic routing rules at the destination cluster, which reduces coupling between peers.
 
 ## Prerequisites
 
@@ -21,6 +21,7 @@ To configure mesh gateways for cluster peering, make sure your Consul environmen
 - Consul version 1.13.0 or newer.
 - A local Consul agent is required to manage mesh gateway configuration.
 - [Enable Consul service mesh](/docs/agent/config/config-files#connect-parameters) in all clusters.
+- [Enable `peering`](/docs/agent/config/config-files) on all Consul servers.
 - Use [Envoy proxies](/docs/connect/proxies/envoy). Envoy is the only proxy with mesh gateway capabilities in Consul.
 
 ## Configuration