move architecture docs (#15010)

* move architecture docs

* dem hbones gonna walk around

* clarify hash for now

* y'all angry about one space

content/en/docs/ambient/architecture/_index.md

@@ -11,15 +11,22 @@ test: n/a
 
 ## Ambient APIs
 
+To enforce L7 policies, add the `istio.io/use-waypoint` label to your resource to use waypoint for the labeled resource.
+  - If a namespace is labeled with `istio.io/use-waypoint` with its default waypoint for the namespace, the waypoint will apply to all pods in the namespace.
+  - The `istio.io/use-waypoint` label can also be set on individual services or pods when using a waypoint for the entire namespace is not desired.
+  - If the `istio.io/use-waypoint` label exists on both a namespace and a service, the service waypoint takes
+  precedence over the namespace waypoint as long as the service waypoint can handle service or all traffic.
+  Similarly, a label on a pod will take precedence over a namespace label
+
 ### Labels
 
 You can use the following labels to add your resource to the mesh, use a waypoint for traffic to your resource, and control what traffic is sent to the waypoint.
 
 |  Name  | Feature Status | Resource | Description |
-| --- | --- | --- | --- | --- |
-| `istio.io/dataplane-mode` | Beta | `Namespace` |  Add your resource to the mesh, valid value: `ambient`. |
-| `istio.io/use-waypoint` | Beta | `Namespace` or `Service` or `Pod` | Use a waypoint for traffic to the labeled resource for L7 policy enforcement, valid values: `{waypoint-name}`, `{namespace}/{waypoint-name}`, or `#none` |
-| `istio.io/waypoint-for` | Alpha | `Gateway` | Specifies what types of endpoints the waypoint will process traffic for, valid value: `service` or `none` or `workload` or `all`. This label is optional and the default value is `service`. |
+| --- | --- | --- | --- |
+| `istio.io/dataplane-mode` | Beta | `Namespace` |  Add your resource to an ambient mesh. <br><br> Valid value: `ambient`. |
+| `istio.io/use-waypoint` | Beta | `Namespace`, `Service` or `Pod` | Use a waypoint for traffic to the labeled resource for L7 policy enforcement. <br><br> Valid values: `{waypoint-name}`, `{namespace}/{waypoint-name}`, or `#none` (with hash). |
+| `istio.io/waypoint-for` | Alpha | `Gateway` | Specifies what types of endpoints the waypoint will process traffic for. <br><br> Valid values: `service`, `workload`, `none` or `all`. This label is optional and the default value is `service`. |
 
 In order for your `istio.io/use-waypoint` label value to be effective, you have to ensure the waypoint is configured for the endpoint which is using it. By default waypoints accept traffic for service endpoints. For example, when you label a pod to use a specific waypoint via the `istio.io/use-waypoint` label, the waypoint should be labeled `istio.io./waypoint-for` with the value `workload` or `all`.
 
@@ -58,81 +65,3 @@ the `productpage-viewer` policy to the `productpage` service in the `default` na
         group: ""
         name: productpage
     {{< /text >}}
-
-## Traffic routing
-
-In {{< gloss "ambient" >}}ambient mode{{< /gloss >}}, workloads can fall into 3 categories:
-1. **Out of Mesh:** this is a standard pod without any mesh features enabled.
-1. **In Mesh:** this is a pod that has traffic intercepted at the Layer 4 level by {{< gloss >}}ztunnel{{< /gloss >}}. In this mode, L4 policies can be enforced for pod traffic. This mode can be enabled for a pod by setting the `istio.io/dataplane-mode=ambient` label on the pod's namespace. This will enable *in mesh* mode for all pods in that namespace.
-1. **Waypoint enabled:** this is a pod that is "in mesh" *and* has a {{< gloss "waypoint" >}}waypoint proxy{{< /gloss >}} deployed. To enforce L7 policies, add the `istio.io/use-waypoint` label to your resource to use waypoint for the labeled resource.
-  - If a namespace is labeled with `istio.io/use-waypoint` with its default waypoint for the namespace, the waypoint will apply to all pods in the namespace.
-  - The `istio.io/use-waypoint` label can also be set on individual services or pods when using a waypoint for the entire namespace is not desired.
-  - If the `istio.io/use-waypoint` label exists on both a namespace and a service, the service waypoint takes
-  precedence over the namespace waypoint as long as the service waypoint can handle service or all traffic.
-  Similarly, a label on a pod will take precedence over a namespace label.
-
-Depending on which category a workload is in, the request path will be different.
-
-### Ztunnel routing
-
-#### Outbound
-
-When a pod in an ambient mesh makes an outbound request, it will be transparently redirected to ztunnel which will determine where and how to forward the request.
-In general, the traffic routing behaves just like Kubernetes default traffic routing;
-requests to a `Service` will be sent to an endpoint within the `Service` while requests directly to a `Pod` IP will go directly to that IP.
-
-However, depending on the destination's capabilities, different behavior will occur.
-If the destination is also added in the mesh, or otherwise has Istio proxy capabilities (such as a sidecar), the request will be upgraded to an encrypted {{< gloss "HBONE" >}}HBONE tunnel{{< /gloss >}}.
-If the destination has a waypoint proxy, in addition to being upgraded to HBONE, the request will also be forwarded to that waypoint for L7 policy enforcement.
-
-Note that in the case of a request to a `Service`, if the service *has* a waypoint, the request will be sent to its waypoint to enforce L7 policies to the traffic.
-Similarly, in the case of a request to a `Pod` IP, if the pod *has* a waypoint, the request will be sent to its waypoint to enforce L7 policies to the traffic.
-Since it is possible to vary the labels associated with pods in a `Deployment` it is technically possible for
-some pods to use a waypoint while others do not. Users are generally recommended to avoid this advanced use-case.
-
-#### Inbound
-
-When a pod in an ambient mesh receives an inbound request, it will be transparently redirected to ztunnel.
-When ztunnel receives the request, it will apply Authorization Policies and forward the request only if the request meets the policies.
-
-A pod can receive HBONE traffic or plaintext traffic.
-By default, both will be accepted by ztunnel.
-Because requests from sources out of mesh will have no peer identity when Authorization Policies are evaluated,
-a user can set a policy requiring an identity (either *any* identity, or a specific one) to block all plaintext traffic.
-
-When the destination is waypoint enabled, if the source is in ambient mesh, the source's ztunnel ensures the request **must** go through
-the waypoint where policy is enforced. However, a workload outside of the mesh doesn't know anything about waypoint proxies therefore it sends
-requests directly to the destination without going through any waypoint proxy even if the destination is waypoint enabled.
-Currently, traffic from sidecars and gateways won't go through any waypoint proxy either and they will be made aware of waypoint proxies
-in a future release.
-
-### Waypoint routing
-
-A waypoint exclusively receives HBONE requests.
-Upon receiving a request, the waypoint will ensure that the traffic is for a `Pod` or `Service` which uses it.
-
-Having accepted the traffic, the waypoint will then enforce L7 policies (such as `AuthorizationPolicy`, `RequestAuthentication`, `WasmPlugin`, `Telemetry`, etc) before forwarding.
-
-For direct requests to a `Pod`, the requests are simply forwarded directly after policy is applied.
-
-For requests to a `Service`, the waypoint will also apply routing and load balancing.
-By default, a `Service` will simply route to itself, load balancing across its endpoints.
-This can be overridden with Routes for that `Service`.
-
-For example, the below policy will ensure that requests to the `echo` service are forwarded to `echo-v1`:
-
-{{< text yaml >}}
-apiVersion: gateway.networking.k8s.io/v1
-kind: HTTPRoute
-metadata:
-  name: echo
-spec:
-  parentRefs:
-  - group: ""
-    kind: Service
-    name: echo
-  rules:
-  - backendRefs:
-    - name: echo-v1
-      port: 80
-{{< /text >}}

content/en/docs/ambient/architecture/hbone/index.md

@@ -1,16 +1,14 @@
 ---
-title: TLS & Tunneling
+title: HBONE
 description: Understanding Istio's secure tunneling protocol.
 weight: 2
 owner: istio/wg-networking-maintainers
 test: no
 ---
 
-## Understanding the HBONE protocol
+**HBONE** (or HTTP-Based Overlay Network Environment) is a secure tunneling protocol used between Istio components. HBONE is an Istio-specific term. It is a mechanism to transparently multiplex TCP streams related to many different application connections over a single, mTLS encrypted network connection: an encrypted tunnel.
 
-HBONE (HTTP Based Overlay Network Encapsulation) is an Istio-specific term. It is a mechanism to transparently multiplex TCP streams related to many different application connections over a single, mTLS encrypted network connection - an encrypted tunnel.
-
-In its current implementation within Istio, the HBONE protocol composes 3 open standards:
+In its current implementation within Istio, the HBONE protocol composes three open standards:
 
 - [HTTP/2](https://httpwg.org/specs/rfc7540.html)
 - [HTTP CONNECT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/CONNECT)

content/en/docs/ambient/architecture/traffic-redirection/index.md

@@ -11,12 +11,6 @@ test: no
 
 In the context of ambient mode, _traffic redirection_ refers to data plane functionality that intercepts traffic sent to and from ambient-enabled workloads, routing it through the {{< gloss >}}ztunnel{{< /gloss >}} node proxies that handle the core data path. Sometimes the term _traffic capture_ is also used.
 
-{{< boilerplate ambient-alpha-warning >}}
-
-{{< tip >}}
-The method described in this guide was first included in Istio version 1.21.0, and [replaces previous methods](/blog/2024/inpod-traffic-redirection-ambient/).
-{{< /tip >}}
-
 ## Istio's in-pod traffic redirection model
 
 The core design principle underlying ambient mode's in-pod traffic redirection is that the ztunnel proxy has the ability to perform data path capture inside the Linux network namespace of the workload pod. This is achieved via a cooperation of functionality between the [`istio-cni` node agent](/docs/setup/additional-setup/cni/) and the ztunnel node proxy. A key benefit of this model is that it enables Istio's ambient mode to work alongside any Kubernetes CNI plugin, transparently, and without impacting Kubernetes networking features.
@@ -98,7 +92,7 @@ To view the iptables rules setup inside one of the application pods, execute thi
 $ kubectl debug $(kubectl get pod -l app=sleep -n ambient-demo -o jsonpath='{.items[0].metadata.name}') -it --image gcr.io/istio-release/base --profile=netadmin -n ambient-demo -- iptables-save
 
 Defaulting debug container name to debugger-m44qc.
-# Generated by iptables-save v1.8.7 on Wed Feb 21 20:38:16 2024
+# Generated by iptables-save
 *mangle
 :PREROUTING ACCEPT [320:53261]
 :INPUT ACCEPT [23753:267657744]
@@ -117,8 +111,8 @@ Defaulting debug container name to debugger-m44qc.
 -A ISTIO_PRERT -p tcp -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
 -A ISTIO_PRERT ! -d 127.0.0.1/32 -p tcp -m mark ! --mark 0x539/0xfff -j TPROXY --on-port 15006 --on-ip 0.0.0.0 --tproxy-mark 0x111/0xfff
 COMMIT
-# Completed on Wed Feb 21 20:38:16 2024
-# Generated by iptables-save v1.8.7 on Wed Feb 21 20:38:16 2024
+# Completed
+# Generated by iptables-save
 *nat
 :PREROUTING ACCEPT [0:0]
 :INPUT ACCEPT [0:0]

content/en/docs/ambient/architecture/traffic-routing/index.md

@@ -0,0 +1,78 @@
+---
+title: Traffic routing
+description: Understand how traffic is routed between workloads in an ambient mesh.
+weight: 2
+owner: istio/wg-networking-maintainers
+test: no
+---
+
+In {{< gloss "ambient" >}}ambient mode{{< /gloss >}}, workloads can fall into 3 categories:
+1. **Out of Mesh**: a standard pod without any mesh features enabled.
+1. **In Mesh**: a pod that has traffic intercepted at the Layer 4 level by {{< gloss >}}ztunnel{{< /gloss >}}. In this mode, L4 policies can be enforced for pod traffic. This mode can be enabled for a pod by setting the `istio.io/dataplane-mode=ambient` label on the pod's namespace. This will enable *in mesh* mode for all pods in that namespace.
+1. **Waypoint enabled**: a pod that is "in mesh" *and* has a {{< gloss "waypoint" >}}waypoint proxy{{< /gloss >}} deployed.
+
+Depending on which category a workload is in, the request path will be different.
+
+## Ztunnel routing
+
+### Outbound
+
+When a pod in an ambient mesh makes an outbound request, it will be transparently redirected to ztunnel which will determine where and how to forward the request.
+In general, the traffic routing behaves just like Kubernetes default traffic routing;
+requests to a `Service` will be sent to an endpoint within the `Service` while requests directly to a `Pod` IP will go directly to that IP.
+
+However, depending on the destination's capabilities, different behavior will occur.
+If the destination is also added in the mesh, or otherwise has Istio proxy capabilities (such as a sidecar), the request will be upgraded to an encrypted {{< gloss "HBONE" >}}HBONE tunnel{{< /gloss >}}.
+If the destination has a waypoint proxy, in addition to being upgraded to HBONE, the request will also be forwarded to that waypoint for L7 policy enforcement.
+
+Note that in the case of a request to a `Service`, if the service *has* a waypoint, the request will be sent to its waypoint to enforce L7 policies to the traffic.
+Similarly, in the case of a request to a `Pod` IP, if the pod *has* a waypoint, the request will be sent to its waypoint to enforce L7 policies to the traffic.
+Since it is possible to vary the labels associated with pods in a `Deployment` it is technically possible for
+some pods to use a waypoint while others do not. Users are generally recommended to avoid this advanced use-case.
+
+### Inbound
+
+When a pod in an ambient mesh receives an inbound request, it will be transparently redirected to ztunnel.
+When ztunnel receives the request, it will apply Authorization Policies and forward the request only if the request meets the policies.
+
+A pod can receive HBONE traffic or plaintext traffic.
+By default, both will be accepted by ztunnel.
+Because requests from sources out of mesh will have no peer identity when Authorization Policies are evaluated,
+a user can set a policy requiring an identity (either *any* identity, or a specific one) to block all plaintext traffic.
+
+When the destination is waypoint enabled, if the source is in ambient mesh, the source's ztunnel ensures the request **must** go through
+the waypoint where policy is enforced. However, a workload outside of the mesh doesn't know anything about waypoint proxies therefore it sends
+requests directly to the destination without going through any waypoint proxy even if the destination is waypoint enabled.
+Currently, traffic from sidecars and gateways won't go through any waypoint proxy either and they will be made aware of waypoint proxies
+in a future release.
+
+## Waypoint routing
+
+A waypoint exclusively receives HBONE requests.
+Upon receiving a request, the waypoint will ensure that the traffic is for a `Pod` or `Service` which uses it.
+
+Having accepted the traffic, the waypoint will then enforce L7 policies (such as `AuthorizationPolicy`, `RequestAuthentication`, `WasmPlugin`, `Telemetry`, etc) before forwarding.
+
+For direct requests to a `Pod`, the requests are simply forwarded directly after policy is applied.
+
+For requests to a `Service`, the waypoint will also apply routing and load balancing.
+By default, a `Service` will simply route to itself, load balancing across its endpoints.
+This can be overridden with Routes for that `Service`.
+
+For example, the below policy will ensure that requests to the `echo` service are forwarded to `echo-v1`:
+
+{{< text yaml >}}
+apiVersion: gateway.networking.k8s.io/v1
+kind: HTTPRoute
+metadata:
+  name: echo
+spec:
+  parentRefs:
+  - group: ""
+    kind: Service
+    name: echo
+  rules:
+  - backendRefs:
+    - name: echo-v1
+      port: 80
+{{< /text >}}

content/en/docs/ambient/usage/ztunnel/index.md

@@ -9,8 +9,6 @@ owner: istio/wg-networking-maintainers
 test: no
 ---
 
-{{< boilerplate ambient-alpha-warning >}}
-
 ## Introduction {#introsection}
 
 This guide describes in-depth the functionality and usage of the ztunnel proxy and Layer 4 networking functions in Istio ambient mode. To simply try out Istio ambient mode, follow the [Ambient Quickstart](/docs/ambient/getting-started/) instead. This guide follows a user journey and works through multiple examples to detail the design and architecture of Istio ambient. It is highly recommended to follow the topics linked below in sequence.
@@ -29,7 +27,7 @@ The ztunnel (Zero Trust Tunnel) component is a purpose-built per-node proxy for
 Pods/workloads using sidecar proxies can co-exist within the same mesh as pods that operate in ambient mode. Mesh pods that use sidecar proxies can also interoperate with pods in the same Istio mesh that are running in ambient mode. The term ambient mesh refers to an Istio mesh that has a superset of the capabilities and hence can support mesh pods that use either type of proxying.
 {{< /tip >}}
 
-The ztunnel node proxy is responsible for securely connecting and authenticating workloads within the ambient mesh. The ztunnel proxy is written in Rust and is intentionally scoped to handle L3 and L4 functions in the ambient mesh such as mTLS, authentication, L4 authorization and telemetry. Ztunnel does not terminate workload HTTP traffic or parse workload HTTP headers. The ztunnel ensures L3 and L4 traffic is efficiently and securely transported to **waypoint proxies**, where the full suite of Istio’s L7 functionality, such as HTTP telemetry and load balancing, is implemented. The term "Secure Overlay Networking" is used informally to collectively describe the set of L4 networking functions implemented in an ambient mesh via the ztunnel proxy. At the transport layer, this is implemented via an HTTP CONNECT-based traffic tunneling protocol called [HBONE](/docs/ambient/architecture/tls-tunnel).
+The ztunnel node proxy is responsible for securely connecting and authenticating workloads within the ambient mesh. The ztunnel proxy is written in Rust and is intentionally scoped to handle L3 and L4 functions in the ambient mesh such as mTLS, authentication, L4 authorization and telemetry. Ztunnel does not terminate workload HTTP traffic or parse workload HTTP headers. The ztunnel ensures L3 and L4 traffic is efficiently and securely transported to **waypoint proxies**, where the full suite of Istio’s L7 functionality, such as HTTP telemetry and load balancing, is implemented. The term "Secure Overlay Networking" is used informally to collectively describe the set of L4 networking functions implemented in an ambient mesh via the ztunnel proxy. At the transport layer, this is implemented via an HTTP CONNECT-based traffic tunneling protocol called [HBONE](/docs/ambient/architecture/hbone).
 
 Some use cases of Istio in ambient mode may be addressed solely via the L4 secure overlay networking features, and will not need L7 features thereby not requiring deployment of a waypoint proxy. Other use cases requiring advanced traffic management and L7 networking features will require deployment of a waypoint proxy. This guide focuses on functionality related to the L4 secure overlay network using ztunnel proxies. This guide refers to L7 only when needed to describe some L4 ztunnel function. Other guides are dedicated to cover the advanced L7 networking functions and the use of waypoint proxies in detail.
 
@@ -40,9 +38,7 @@ Some use cases of Istio in ambient mode may be addressed solely via the L4 secur
 
 ## Current Caveats {#caveats}
 
-{{< boilerplate ambient-alpha-warning >}}
-
-The following is a list of feature restrictions or caveats in ambient mode alpha. These restrictions are planned to be addressed or removed in future releases.
+The following is a list of feature restrictions or caveats in ambient mode. These restrictions are planned to be addressed or removed in future releases.
 
 1. **Kubernetes only:** Istio in ambient mode is currently only supported for deployment on Kubernetes clusters. Deployment on non-Kubernetes endpoints such as virtual machines is not currently supported.
 
@@ -94,17 +90,17 @@ caption="Basic ztunnel L4-only datapath"
 
 The figure depicts ambient pod workloads running on two nodes W1 and W2 of a Kubernetes cluster. There is a single instance of the ztunnel proxy on each node. In this scenario, application client pods C1, C2 and C3 need to access a service provided by pod S1 and there is no requirement for advanced L7 features such as L7 traffic routing or L7 traffic management so no Waypoint proxy is needed.
 
-The figure shows that pods C1 and C2 running on node W1 connect with pod S1 running on node W2 and their TCP traffic is tunneled through HBONE tunnel instances that have been created by the ztunnel proxy pods of each node. Mutual TLS (mTLS) is used for encryption as well as mutual authentication of traffic being tunneled. SPIFFE identities are used to identify the workloads on each side of the connection. The term `HBONE` (for HTTP Based Overlay Network Encapsulation) is used in Istio ambient to refer to a technique for transparently and securely tunneling TCP packets encapsulated within HTTPS packets. For more details on the datapath, including HBONE and the traffic redirection details, refer to the [ztunnel traffic redirection](/docs/ambient/usage/traffic-redirection) guide.
+The figure shows that pods C1 and C2 running on node W1 connect with pod S1 running on node W2 and their TCP traffic is tunneled through {{< gloss >}}HBONE{{< /gloss >}} tunnel instances that have been created by the ztunnel proxy pods of each node. Mutual TLS (mTLS) is used for encryption as well as mutual authentication of traffic being tunneled. SPIFFE identities are used to identify the workloads on each side of the connection. For more details on the datapath, refer to the architecture guides on [HBONE](/docs/ambient/architecture/hbone) and [ztunnel traffic redirection](/docs/ambient/architecture/traffic-redirection).
 
 {{< tip >}}
-Note: Although the figure shows the HBONE tunnels to be between the two ztunnel proxies, in the in-pod redirection implementation introduced in Istio 1.21.0 the tunnels are in fact between the source and destination pods. Traffic is HBONE encapsulated and encrypted in the network namespace of the source pod itself, and eventually decapsulated and decrypted in the network namespace of the destination pod on the destination worker node. The ztunnel proxy still logically handles both the control plane and data plane needed for HBONE transport, however it is able to do that from inside the network namespaces of the source and destination pods.
+Note: Although the figure shows the HBONE tunnels to be between the two ztunnel proxies, the tunnels are in fact between the source and destination pods. Traffic is HBONE encapsulated and encrypted in the network namespace of the source pod itself, and eventually decapsulated and decrypted in the network namespace of the destination pod on the destination worker node. The ztunnel proxy still logically handles both the control plane and data plane needed for HBONE transport; however, it is able to do that from inside the network namespaces of the source and destination pods.
 {{< /tip >}}
 
 Note that the figure shows that local traffic - from pod C3 to destination pod S1 on worker node W2 - also traverses the local ztunnel proxy instance so that L4 traffic management functions such as L4 Authorization and L4 Telemetry are enforced identically on traffic, whether or not it crosses a node boundary.
 
 #### Ztunnel datapath via waypoint
 
-The next figure depicts the data path for a use case which requires advanced L7 traffic routing, management or policy handling. Here ztunnel uses HBONE tunneling to send traffic to a waypoint proxy for L7 processing. After processing, the waypoint sends traffic via a second HBONE tunnel to the ztunnel on the node hosting the selected service destination pod. In general the waypoint proxy may or may not be located on the same nodes as the source or destination pod.
+The next figure depicts the datapath for a use case which requires advanced L7 traffic routing, management or policy handling. Here ztunnel uses HBONE tunneling to send traffic to a waypoint proxy for L7 processing. After processing, the waypoint sends traffic via a second HBONE tunnel to the ztunnel on the node hosting the selected service destination pod. In general the waypoint proxy may or may not be located on the same nodes as the source or destination pod.
 
 {{< image width="100%"
 link="ztunnel-waypoint-datapath.png"
@@ -183,7 +179,7 @@ This indicates the traffic path is working. The next section looks at how to mon
 
 ## Monitoring the ztunnel proxy & L4 networking {#monitoringzt}
 
-This section describes some options for monitoring the ztunnel proxy configuration and data path. This information can also help with some high level troubleshooting and in identifying information that would be useful to collect and provide in a bug report if there are any problems. Additional advanced monitoring of ztunnel internals and advanced troubleshooting is out of scope for this guide.
+This section describes some options for monitoring the ztunnel proxy configuration and datapath. This information can also help with some high level troubleshooting and in identifying information that would be useful to collect and provide in a bug report if there are any problems. Additional advanced monitoring of ztunnel internals and advanced troubleshooting is out of scope for this guide.
 
 ### Viewing ztunnel proxy state
 
@@ -321,7 +317,7 @@ $ kubectl -n istio-system logs -l app=ztunnel | grep -E "inbound|outbound"
 --snip--
 {{< /text >}}
 
-Here note the logs from the ztunnel proxies first indicating the http CONNECT request to the new destination pod (10.240.1.11) which indicates the setup of the HBONE tunnel to ztunnel on the node hosting the additional destination service pod. This is then followed by logs indicating the client traffic being sent to both 10.240.1.11 and 10.240.2.10 which are the two destination pods providing the service. Also note that the data path is performing client-side load balancing in this case and not depending on Kubernetes service load balancing. In your setup these numbers will be different and will match the pod addresses of the httpbin pods in your cluster.
+Here note the logs from the ztunnel proxies first indicating the http CONNECT request to the new destination pod (10.240.1.11) which indicates the setup of the HBONE tunnel to ztunnel on the node hosting the additional destination service pod. This is then followed by logs indicating the client traffic being sent to both 10.240.1.11 and 10.240.2.10 which are the two destination pods providing the service. Also note that the datapath is performing client-side load balancing in this case and not depending on Kubernetes service load balancing. In your setup these numbers will be different and will match the pod addresses of the httpbin pods in your cluster.
 
 This is a round robin load balancing algorithm and is separate from and independent of any load balancing algorithm that may be configured within a `VirtualService`'s `TrafficPolicy` field, since as discussed previously, all aspects of `VirtualService` API objects are instantiated on the Waypoint proxies and not the ztunnel proxies.
 

content/en/docs/ops/deployment/requirements/index.md

@@ -139,11 +139,11 @@ Because TLS communication is not server first, TLS encrypted server first traffi
 In order to support Istio's traffic routing capabilities, traffic leaving a pod may be routed differently than
 when a sidecar is not deployed.
 
-For HTTP based traffic, traffic is routed based on the `Host` header. This may lead to unexpected behavior if the destination IP
+For HTTP-based traffic, traffic is routed based on the `Host` header. This may lead to unexpected behavior if the destination IP
 and `Host` header are not aligned. For example, a request like `curl 1.2.3.4 -H "Host: httpbin.default"` will be routed to the `httpbin` service,
 rather than `1.2.3.4`.
 
-For Non-HTTP based traffic (including HTTPS), Istio does not have access to an `Host` header, so routing decisions are based on the Service IP address.
+For Non HTTP-based traffic (including HTTPS), Istio does not have access to an `Host` header, so routing decisions are based on the Service IP address.
 
 One implication of this is that direct calls to pods (for example, `curl <POD_IP>`), rather than Services, will not be matched. While the traffic may
 be [passed through](/docs/tasks/traffic-management/egress/egress-control/#envoy-passthrough-to-external-services), it will not get the full Istio functionality

content/en/docs/reference/glossary/hbone.md

@@ -4,4 +4,4 @@ test: n/a
 ---
 
 HBONE (or HTTP-Based Overlay Network Environment) is a secure tunneling protocol used between Istio components.
-[Learn more about HBONE](/docs/ambient/architecture/tls-tunnel/)
+[Learn more about HBONE](/docs/ambient/architecture/hbone/)