refining

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

@@ -9,44 +9,47 @@ description: >-
 
 This topic provides an overview of cluster peering, which is a process that connects two or more independent clusters so that services deployed to different partitions or datacenters can communicate.
 
-Cluster peering is enabled in Consul by default. You can use the API, the CLI, or the Consul UI for most cluster peering operations. However, be aware that the UI does not support exporting services between clusters or creating service intentions, both of which are required steps for establishing new cluster peering connections.
+Cluster peering is enabled in Consul by default. For specific information about cluster peering configuration and usage, refer to following pages.
 
-<Tip title="Looking for specific guidance?"> 
+**Reference information:**
 
-You can find specific cluster peering configuration and usage information in the following topics:
+- [HTTP API reference: `/peering/` endpoint](/consul/api-docs/peering)
+- [CLI reference: `peering` command](/consul/commands/peering).
+- [Cluster peering configuration reference](/docs/consul/cluster-peering/configuration)
 
-- If you use the HTTP API, refer to the [`/peering/` endpoint reference](/consul/api-docs/peering).
-- If you use the CLI, refer to the [`peering` command reference](/consul/commands/peering).
-- To review configuration requirements for gateways, sidecars, exported services, and ACLs, refer to [Cluster peering configuration](/docs/consul/cluster-peering/configuration).
-- To create new cluster peering connections, refer to [Establish cluster peering connections](/docs/connect/cluster-peering/create-manage-peering).
-- To manage or delete existing cluster peering connections, refer to [Manage cluster peering connections](/consul/docs/cluster-peering/usage/manage-connections).
-- To set up service failovers and redirects, refer to [L7 traffic management for cluster peering connections](/consul/docs/cluster-peering/usage/peering-traffic-management).
-- To use cluster peering with Kubernetes deployments, refer to [Cluster peering on Kubernetes](/consul/docs/cluster-peering/usage/k8s).
-- To use cluster peering with HCP Consul, refer to [Cluster peering in the HCP documentation](/hcp/docs/consul/usage/cluster-peering).
+**Usage information:**
 
-> To learn how to peer clusters and connect services across peers in AWS Elastic Kubernetes Service (EKS) environments, complete the [Consul Cluster Peering on Kubernetes tutorial](/consul/tutorials/developer-mesh/cluster-peering-aws).
+- [Establish cluster peering connections](/docs/connect/cluster-peering/create-manage-peering)
+- [Manage cluster peering connections](/consul/docs/cluster-peering/usage/manage-connections)
+- [L7 traffic management for cluster peering connections](/consul/docs/cluster-peering/usage/peering-traffic-management)
 
-</Tip>
+**Runtime-specific information:**
+
+- [Cluster peering on Kubernetes](/consul/docs/cluster-peering/usage/k8s)
+- [Cluster peering on HCP Consul](/hcp/docs/consul/usage/cluster-peering)
+
+**Tutorials:**
+
+- To learn how to peer clusters and connect services across peers in AWS Elastic Kubernetes Service (EKS) environments, complete the [Consul Cluster Peering on Kubernetes tutorial](/consul/tutorials/developer-mesh/cluster-peering-aws).
 
 ## Background
 
-Consul supports cluster peering connections between [admin partitions](/consul/docs/enterprise/admin-partitions) _in different datacenters_. Deployments without an Enterprise license can still use cluster peering because every datacenter automatically includes a default partition. Meanwhile, admin partitions _in the same datacenter_ do not require cluster peering connections because you can export services between them without generating or exchanging a peering token.
+Consul supports cluster peering connections between two [admin partitions](/consul/docs/enterprise/admin-partitions) _in different datacenters_. Deployments without an Enterprise license can still use cluster peering because every datacenter automatically includes a default partition. Meanwhile, admin partitions _in the same datacenter_ do not require cluster peering connections because you can export services between them without generating or exchanging a peering token.
 
 The following diagram describes Consul's cluster peering architecture.
 
 ![Diagram of cluster peering with admin partitions](/img/cluster-peering-diagram.png)
 
-In this diagram, the `default` partition in the first datacenter has a cluster peering connection with the `web` partition in the second datacenter. Enforced by their respective mesh gateways, this cluster peering connection enables `Service B` to communicate with `Service C` as a service upstream. Cluster peering leverages several components of Consul's architecture to enforce secure communication between services.
-
-A _peering token_ contains an embedded secret that securely establishes communication when shared symetrically between datacenters. Sharing this token enables each datacenter's server agents to recognize requests from authorized peers, similar to how the [gossip encryption key secures agent LAN gossip](/consul/docs/security/encryption#gossip-encryption).
-
-A _mesh gateway_ encrypts outgoing traffic, decrypts incoming traffic, and directs traffic to healthy services. Consul's service mesh features must be enabled in order to use mesh gateways. Mesh gateways support the specific admin partitions they are deployed on. Refer to [Mesh gateways](/consul/docs/connect/gateways/mesh-gateway) for more information.
+In this diagram, the `default` partition in the first datacenter has a cluster peering connection with the `web` partition in the second datacenter. Enforced by their respective mesh gateways, this cluster peering connection enables `Service B` to communicate with `Service C` as a service upstream. 
 
-An _exported service_ communicates with downstreams deployed in other admin partitions. They are explicitly defined in an [`exported-services` configuration entry](/consul/docs/connect/config-entries/exported-services).
+Cluster peering leverages several components of Consul's architecture to enforce secure communication between services:
 
-A _service intention_ secures [service-to-service communication in a service mesh](/consul/docs/connect/intentions). Intentions enable identity-based access between services by exchanging TLS certificates, which the service's sidecar proxy verifies upon each request.
+- A _peering token_ contains an embedded secret that securely establishes communication when shared symetrically between datacenters. Sharing this token enables each datacenter's server agents to recognize requests from authorized peers, similar to how the [gossip encryption key secures agent LAN gossip](/consul/docs/security/encryption#gossip-encryption).
+- A _mesh gateway_ encrypts outgoing traffic, decrypts incoming traffic, and directs traffic to healthy services. Consul's service mesh features must be enabled in order to use mesh gateways. Mesh gateways support the specific admin partitions they are deployed on. Refer to [Mesh gateways](/consul/docs/connect/gateways/mesh-gateway) for more information.
+- An _exported service_ communicates with downstreams deployed in other admin partitions. They are explicitly defined in an [`exported-services` configuration entry](/consul/docs/connect/config-entries/exported-services).
+- A _service intention_ secures [service-to-service communication in a service mesh](/consul/docs/connect/intentions). Intentions enable identity-based access between services by exchanging TLS certificates, which the service's sidecar proxy verifies upon each request.
 
-## Cluster peering and WAN federation comparison
+## Compared to WAN federation
 
 WAN federation and cluster peering are different ways to connect services through mesh gateways so that they can communicate across datacenters. 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.
 
@@ -68,10 +71,11 @@ Regardless of whether you connect your clusters through WAN federation or cluste
 
 ## Troubleshooting
 
-If you encounter errors when using Consul's cluster peering features, check if any of the following technical constraints apply:
+If you experience errors when using Consul's cluster peering features, refer to the following list technical constraints.
 
 - Peer names can only contain lowercase characters.
 - Services with node, instance, and check definitions totaling more than 8MB cannot be exported to a peer.
 - Two admin partitions in the same datacenter cannot be peered. Use the [`exported-services` configuration entry](/consul/docs/connect/config-entries/exported-services#exporting-services-to-peered-clusters) instead.
 - To manage intentions that specify services in peered clusters, use [configuration entries](/consul/docs/connect/config-entries/service-intentions). The `consul intention` CLI command is not supported.
+- The Consul UI does not support exporting services between clusters or creating service intentions. Use either the API or the CLI to complete these required steps when establishing new cluster peering connections.
 - Accessing key/value stores across peers is not supported.