anchor.diff:  <tr>
   	<td>Load Balancing</td>
   	<td>The sidecar uses the load balancing policy to determine which host is selected.</td>
  -	<td>Evenly distributed weighted routing between apps mapped to one service mesh internal route.</td>
  +	<td>Evenly distributed weighted routing between apps mapped to one service mesh internal route</td>
   </tr>
   <tr>
   	<td>Retries</td>
  -	<td>The sidecar automatically attempts to retry requests upon certain responses.</td>
  +	<td>The sidecar automatically attempts to retry requests upon certain responses</td>
   	<td>3 retries on 5xx status code responses.</td>
   </tr>
  -<tr>
  +<tr>ß
     <td>Timeouts</td>
   	<td>The sidecar automatically terminates connections if there are no responses in a specified amount of time.</td>
  -	<td>15 second timeout.</td>
  +	<td>15 second timeout</td>
   </tr>
   </table>
   
  
positive.code: 
  Consider the following when deploying service mesh:
  
  The Istio Router does not have feature parity with the existing routing plane in <%= vars.product_short %>.
  These service mesh features will not work when strict (mTLS) route integrity is also enabled.
  The Istio Router is for deployments with fewer than 20,000 routes. At greater scale, it may impact core platform functions.
  The control plane is not HA and registration of new routes may be delayed during upgrade.
  The domains for service mesh external routes, must be provided at deploy time on the cloud_controller_ng job copilot.temporary_istio_domains property.
  Mapping a service mesh external route can take up to 1 minute to take effect.
  
  The service mesh container to container networking data plane does not support UDP or ICMP traffic.
  The service mesh container to container networking data plane can only support up to 300 internal routes for the entire foundation.
  Mapping a service mesh internal route can take up to 1 minute to take effect.
  
  ## <a id="components"></a> Component VMs
  
  
negative.code: 
  ![A load balancer receives requests at *.YOUR-APPS-DOMAIN and forwards them to the Gorouter. The Gorouter then forwards them to an app. A separate load balancer receives requests at *.mesh.YOUR-APPS-DOMAIN and forwards them to the istio-router. The istio-router then forwards them to an app](service-mesh.png)
  
  ## <a id="features"></a> Features
  
  This section describe the features provided by service mesh for <%= vars.product_full %>.
  
  ### <a id="weighted-routing"></a> Weighted Routing
  
  External service mesh routes enable configuring weighted routing for apps. For more information, see [Using Weighted Routing (Beta)](../devguide/weighted-routing.html).
  
  ### <a id="c2c"></a> Container-to-Container Networking
  
  Service mesh supports container-to-container networking. In service mesh, traffic between two apps passes through the Envoy sidecar of the source app. In the existing Gorouter routing plane, apps do not use the sidecar. See the following diagram for an illustration:
  
  ![An app using the internal service mesh domain will communicate through its sidecar proxy to reach the destination app.](service-mesh-c2c.png)
  
  Container-to-container networking provides load balancing, retries, and timeouts. See the following table for details:
  
  <table>
  <tr>
  