Mike Morris clean up requests

website/content/docs/connect/cluster-peering/create-manage-peering.mdx

@@ -94,8 +94,7 @@ In one of the client agents in "cluster-02," use `peering_token.json` and the [`
 $ curl --request POST --data @peering_token.json http://127.0.0.1:8500/v1/peering/establish
 ```
 
-When you connect server agents through cluster peering, they peer their default partitions. To establish peering connections for other partitions through server agents, you must add the `Partition` field to `peering_token.json` and specify the partitions you want to peer. For additional configuration information, refer to [Cluster Peering - HTTP API](/api-docs/peering).
-
+When you connect server agents through cluster peering, their default behavior is to peer to the `default` partition. To establish peering connections for other partitions through server agents, you must add the `Partition` field to `peering_token.json` and specify the partitions you want to peer. For additional configuration information, refer to [Cluster Peering - HTTP API](/api-docs/peering).
 
 You can dial the `peering/establish` endpoint once per peering token. Peering tokens cannot be reused after being used to establish a connection. If you need to re-establish a connection, you must generate a new peering token.
 
@@ -123,9 +122,9 @@ If you need to re-establish a connection, you must generate a new peering token.
 <Tab heading="Consul UI">
 
 1. In the Consul UI for the datacenter associated with `cluster 02`, click **Peers** and then **Add peer connection**.
-1. Click **Establish peering**.
-1. In the **Name of peer** field, enter `cluster-01`. Then paste the peering token in the **Token** field.
-1. Click **Add peer**.
+2. Click **Establish peering**.
+3. In the **Name of peer** field, enter `cluster-01`. Then paste the peering token in the **Token** field.
+4. Click **Add peer**.
 
 </Tab>
 </Tabs>

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

@@ -13,17 +13,18 @@ You can create peering connections between two or more independent clusters so t
 
 ## Overview
 
-Cluster peering allows Consul clusters in different datacenters to communicate with each other. The cluster peering process consists of the following steps:
+Cluster peering is a process that allows Consul clusters to communicate with each other. The cluster peering process consists of the following steps:
+
 1. Create a peering token in one cluster.
-1. Use the peering token to establish peering with a second cluster.
-1. Export services between clusters.
-1. Create intentions to authorize services for peers.
+2. Use the peering token to establish peering with a second cluster.
+3. Export services between clusters.
+4. Create intentions to authorize services for peers.
 
 For detailed instructions on setting up cluster peering, refer to [Create and Manage Peering Connections](/docs/connect/cluster-peering/create-manage-peering).
 
 ### Differences between WAN federation and cluster peering
 
-WAN federation and cluster peering are different ways to connect clusters. The most important distinction is that WAN federation assumes clusters are owned by the same operators, so it maintains and replicates global states such as ACLs and configuration entries. As a result, WAN federation requires a _primary datacenter_ to serve as an authority for replicated data.
+WAN federation and cluster peering are different ways to connect Consul deployments. WAN federation connects multiple datacenters to make them function as if they were a single cluster, while cluster peering treats each datacenter as a separate cluster. As a result, WAN federation requires a primary datacenter to maintain and replicate global states such as ACLs and configuration entries, but cluster peering does not.
 
 Regardless of whether you connect your clusters through WAN federation or cluster peering, human and machine users can use either method to discover services in other clusters or dial them through the service mesh.
 
@@ -34,14 +35,16 @@ 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 |    ❌    |    ✅      |
+| Gossip protocol: Requires LAN gossip only          |    ❌    |    ✅      |
 | Forwards service requests for service discovery    |    ✅     |    ❌     |
 | Shares key/value stores                            |    ✅     |    ❌     |
-| Uses gossip protocol                               |    ✅     |    ❌     |
+
 
 ## Beta release features and constraints
 
 The cluster peering beta includes the following features and functionality:
 
+- Consul datacenters that are already federated stay federated. You do not need to migrate WAN federated clusters to cluster peering.
 - Mesh gateways for _service to service traffic_ between clusters are available. For more information on configuring mesh gateways across peers, refer to [Service-to-service Traffic Across Peered Clusters](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-peers).
 - You can generate peering tokens, establish, list, read, and delete peerings, and manage intentions for peering connections with both the API and the UI.
 - You can configure [transparent proxies](/docs/connect/transparent-proxy) for peered services.
@@ -52,8 +55,6 @@ Not all features and functionality are available in the beta release. In particu
 - 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.
 - 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

@@ -11,7 +11,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 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.
+Unlike mesh gateways for datacenters and partitions, mesh gateways between peers terminate mTLS sessions to decrypt data to HTTP services and then re-encrypt traffic to send to services. Data must be decrypted in order to evaluate and apply dynamic routing rules at the destination cluster, which reduces coupling between peers.
 
 ## Prerequisites