anchor.diff:  This topic describes the components that form and interact with the Diego system in <%= vars.app_runtime_first %>.
   
   
  -## <a id='overview'></a> Overview 
  -
  -<%= vars.app_runtime_abbr %> uses the Diego system to manage app containers. Diego components assume app scheduling and management responsibility from the Cloud Controller. 
  +## <a id='overview'></a> Overview
  +
  +<%= vars.app_runtime_abbr %> uses the Diego system to manage app containers. Diego components assume app scheduling and management responsibility from the Cloud Controller.
   
   Diego is a self-healing container management system that attempts to keep the correct number of instances running in Diego cells to avoid network failures and crashes. Diego schedules and runs Tasks and Long-Running Processes (LRP). For more information about Tasks and LRPs, see [How the Diego Auction Allocates Jobs](diego-auction.html).
   
   You can submit, update, and retrieve the desired number of Tasks and LRPs using the Bulletin Board System (BBS) API. For more information, see the [BBS Server](https://github.com/cloudfoundry/bbs) repository on GitHub.
   
   
  -## <a id='diagram'></a> How Diego Runs an App 
  -
  -The following sections describe how Diego handles a request to run an app. This is only one of the processes that happen in Diego. For example, running an app assumes the app has already been staged. For more information about the staging process, see [How Apps are Staged](../how-applications-are-staged.html). 
  -
  -The diagrams below do not include all of the components Diego. For information about each Diego component, see [Diego Components](#components). 
  +## <a id='diagram'></a> How Diego Runs an App
  +
  +The following sections describe how Diego handles a request to run an app. This is only one of the processes that happen in Diego. For example, running an app assumes the app has already been staged. For more information about the staging process, see [How Apps are Staged](../how-applications-are-staged.html).
  +
  +The diagrams below do not include all of the components Diego. For information about each Diego component, see [Diego Components](#components).
   
   <%= vars.vm_note %>
   
   ### <a id='step-1'></a> Step 1: Receives the Request to Run an App
   
  -The Cloud Controller passes requests to run apps to the Diego BBS, which stores information about the request in its database. 
  +The Cloud Controller passes requests to run apps to the Diego BBS, which stores information about the request in its database.
   
   ![Several boxes represent the VMs involved in running an app with Diego. They have additional boxes within them to represent the components running on each VM. The boxes are as follows: the api VM includes the cloud_controller_ng process, the scheduler VM includes the auctioneer process, the diego-api VM includes the bbs process, the pxc-mysql VM includes the bbs db, the diego-cell VM includes the rep, loggregator-agent, garden, and route-emitter processes, the singleton-blobstore VM includes the droplets store, the doppler VM includes the doppler process, the log-api VM includes the traffic-controller process, and the gorouter VM includes the gorouter process. An arrow points from cloud_controller_ng to bbs to indicate that the cloud_controller_ng process is sending a request to run an app to the bbs process. Another arrow points from bbs to bbs db to indicate that the request gets stored in a database.](../images/oss-diego-architecture-1.png)
   [//]: https://docs.google.com/drawings/d/1p2ShJ8yJ3gVzKBh1sw1b_O8qMASXMzC37r2MU3L4xmI/edit?usp=sharing
   
   ### <a id='step-2'></a> Step 2: Passes Request to the Auctioneer Process
   
  -The BBS contacts the Auctioneer to create an auction based on the desired resources for the app. It references the information stored in its database. 
  +The BBS contacts the Auctioneer to create an auction based on the desired resources for the app. It references the information stored in its database.
   
   ![An arrow points from a box labeled "bbs" to a cylinder labeled "bbs db" to indicate the bbs process is receiving information from its database. Another arrow points from bbs to a box labeled "auctioneer" to indicate the bbs process is contacting the auctioneer process to create an auction.](../images/oss-diego-architecture-2.png)
   [//]: https://docs.google.com/drawings/d/1P_aSBm6fyHeqJyZ-8epM_CePS3u8O_GLTSzW-g1-32U/edit?usp=sharing
   
   ### <a id='step-3'></a> Step 3: Performs Auction
   
  -Through an auction, the Auctioneer finds a Diego Cell to run the app on. The Rep job on the Diego Cell accepts the auction request. 
  +Through an auction, the Auctioneer finds a Diego Cell to run the app on. The Rep job on the Diego Cell accepts the auction request.
   
   ![An arrow points from a box labeled "auctioneer" to a box labeled "rep" to indicate that the auctioneer finds a Diego Cell VM to satisfy the request to run the app.](../images/oss-diego-architecture-3.png)
   [//]: https://docs.google.com/drawings/d/1ug2RVCiW_fW4U6vH6dvG-sn6-Om9gXHTymnPBiZI8Hk/edit?usp=sharing
   
   ### <a id='step-4'></a> Step 4: Creates Container and Runs App
   
  -The in-process Executor creates a Garden container in the Diego Cell. Garden downloads the droplet that resulted from the staging process and runs the app in the container. 
  +The in-process Executor creates a Garden container in the Diego Cell. Garden downloads the droplet that resulted from the staging process and runs the app in the container.
   
   ![An arrow points from a box labeled "executor" to an unlabeled box inside of a box labeled "garden". This indicates that the executor sub-process of the rep process on the diego-cell VM communicates to the garden process on the diego-cell VM to create a new container. Another arrow points from garden to a cylinder labeled "droplets" to indicate that the garden process also communicates with the droplets bucket on the singleton-blobstore VM to download the droplet.](../images/oss-diego-architecture-4.png)
   [//]: https://docs.google.com/drawings/d/1IPLl2bKmR9iYOhjXvlRZJSvCeCnoaX_zqARdt04Yjv4/edit?usp=sharing
  
positive.code: 
  ## <a id='maximum-diego-cells'></a> Maximum Recommended Diego Cells
  
  The maximum recommended diego cells is 250 cells for each TAS tile. There is a hard limit of 256 addresses by default for vSphere deployments using silk for networking. This hard limit is described in the [silk release documentation](https://github.com/cloudfoundry/cf-networking-release/blob/develop/docs/large_deployments.md)
  The default CIDR address block for the overlay network is 10.255.0.0/16 Each diego cell needs a subnet, and subnets (0-255) for each diego cell are allocated out of this network.
  
  TAS Deployments that do not use silk for networking do not have a hard limit. However, operating a foundation with more than 250 diego cells is not recommended because:
  * Changes to the foundation will take a long time, potentially days or weeks depending on the [max-in-flight](https://docs.pivotal.io/application-service/operating/configuring.html#best-practices). For example, if a certificate is found to be expiring in a week, there may not be enough time to rotate the certificates before expiry.
  * A single foundation still has single points of failure such as the certificates on the platform. 250 diego cells is enough RAM to host many business critical applications
  
  
  
  ## <a id='components-ther'></a> Components from Other Releases
  
negative.code: 
  ## <a id='components'></a> Diego Components
  
  The following table describes the jobs that are part of the <%= vars.app_runtime_abbr %> Diego BOSH release.
  
  <table>
  	<tr>
  