anchor.diff:  	</tr>
   	<tr>
   		<td><a href="https://istio.io/docs/concepts/what-is-istio/#pilot">Pilot</a> </td>
  -		<td>Pilot is an Istio component that can accept configuration from multiple sources simultaneously and distribute configuration intelligently across ingress and sidecar envoys. There is one Pilot on the Istio Control VM and a Pilot on every Diego cell </td>
  +		<td>Pilot is an Istio component that can accept configuration from multiple sources simultaneously and distribute configuration intelligently across ingress and sidecar envoys.</td>
   	</tr>
   	<tr>
   		<td><a href="https://www.envoyproxy.io/">Envoy</a></td>
  -		<td>Envoy Proxy is a lightweight proxy designed for microservices. It routes traffic based on configuration it receives from Pilot and emits in-depth metrics based on that traffic. There is one edge envoy for ingress traffic and there is a sidecar envoy in every app container. </td>
  +		<td>Envoy Proxy is a lightweight edge proxy designed for microservices. It routes traffic based on configuration it receives from Pilot and emits in-depth metrics based on that traffic.</td>
   	</tr>
   	<tr>
   		<td>Load Balancer </td>
  
positive.code: 		<td><a href="https://github.com/cloudfoundry/istio-release">istio-release</a></td>
  		<td>A BOSH release that deploys Istio-related components and configures any existing components to use them.</td>
  	</tr>
  </table>
  
  
negative.code: owner: Networking
  ---
  
  This topic describes the routing flow and architecture of the service mesh data and control plane in <%= vars.product_runtime %> <%= vars.runtime_abbr %>.
  
  
  ## <a id="overview"></a> Overview
  
  The service mesh data plane is a parallel routing path for ingress traffic for apps on <%= vars.product_runtime %>. It is deployed alongside the existing Cloud Foundry routing tier and manages istio routes for applications. 
  
  We use [Istio's](https://istio.io/) Pilot component to configure ingress [Envoy Proxies](https://www.envoyproxy.io/), and these proxies are the routers. We use a custom component called Copilot to push Cloud Foundry configuration to into Pilot.
  
  A route is managed by istio if it is associated with an istio managed domain. These are specified in the manifest.
  
  ![Istio Routing Architecture](../images/istio_boxes_lines.jpg)
  
  ## <a id="control-plane"></a> Control Plane
  
  0. A new route is added to CAPI and mapped to one or more applications
  0. The route and mapping are sent to copilot
  0. Copilot then exposes that configuration in a way Pilot can understand, Pilot polls for it
  0. Pilot distributes the configuration to the ingress envoys
  
  ## <a id="data-plane"></a> Data Plane
  
  0. The request hits your load balancer.
  0. The load balancer directs the request to one of your ingress envoys (on the istio-router vm)
  0. The ingress envoy then chooses which app container to send the request to
  0. The app container has an iptables rule which DNATs the request to its local envoy sidecar
  0. The envoy sidecar passes the request along to the application
  
  ## <a id="component-manifest"></a> Service Mesh Components
  
  