anchor.diff:  - Developers must manually provision/configure route services out of the context of Cloud Foundry; no service broker automates these operations.
   - Traffic to apps that use the route service makes additional network hops, as compared to the static model.
   
  -### <a id="route-architecture-summary"></a>Route Architecture Summary ###
  +### <a id="architecture-comparison"></a>Architecture Comparison ###
   
   The models above require the [broker](#broker-responsibilities) and [service instance](#service-instance-responsibilities) responsibilities below, as summarized in the following table:
   
  -<table id='route-architecture-summary' border="1" class="nice" >
  +<table id='architecture-comparison' border="1" class="nice" >
     <tr>
       <th>Route Services Architecture</th>
       <th>Fulfills CF <a href="#service-instance-responsibilities">Service Instance Responsibilities</a></th>
       <th>Fulfills CF <a href="#broker-responsibilities">Broker Responsibilities</a></th>
     </tr><tr>
  +    <td>Fully-Brokered</td>
  +    <td>Yes</td>
  +    <td>Yes</td>
  +  </tr><tr>
       <td>Static Brokered</td>
       <td>No</td>
  -    <td>Yes</td>
  -  </tr><tr>
  -    <td>Fully-Brokered</td>
  -    <td>Yes</td>
       <td>Yes</td>
     </tr><tr>
       <td>User-Provided</td>
  
positive.code: 
  ## <a id='architecture'></a>Architecture ##
  
  Cloud Foundry supports three models for Route Services: static, brokered services; fully-brokered services; and user-provided services. In each case, you configure a route service to run either inside or outside of Cloud Foundry, in order to process traffic addressed to an app.
  
  ### <a id="static-brokered"></a>Static, Brokered Service ###
  
  In this model, an operator installs a static routing service, which might be a piece of hardware, in front of the Load Balancer. This routing service receives traffic to all apps running in the Cloud Foundry deployment. The service provider creates a service broker to publish the service to the CF marketplace. Developers can then create an instance of the service and bind it to their apps with the following commands:
  
  `cf create-service BROKER_SERVICE_PLAN SERVICE_INSTANCE`
  `cf bind-route-service YOUR_APP_DOMAIN SERVICE_INSTANCE [--hostname HOSTNAME]`
  
  In this model, you configure route services on an app-by-app basis. When you bind a service to an app, the service broker tells the routing service to process that app's traffic rather than pass the requests through unchanged.
  
  ![Static, brokered](images/route-services-static-brokered.png)
  
  **Advantages:**
  
  
negative.code: - Adding route services requires manual infrastructure configuration.
  - Unnecessary network hops for traffic to apps that do not use the route service; requests for all apps hosted by the the deployment pass through the route service component.
  
  ### <a id="user-provided"></a>User-Provided Service ###
  
  If a route service is not listed in the CF marketplace by a broker, a developer can still bind it to their app as a User-Provided service. The service can run anywhere, either inside or outside of CF, but it must fulfill the integration requirements described in [Service Instance Responsibilities](#service-instance-responsibilities). The service also needs to be reachable by an outbound connection from the CF Router.
  
  ![User-provided](images/route-services-user-provided.png)
  
  This model is identical to the [fully-brokered service](#fully-brokered) model, except without the broker. Developers configure the service manually, outside of Cloud Foundry. They can then create a user-provided service instance and bind it to their application with the following commands, supplying the URL of their route service:
  
  `cf create-user-provided-service SERVICE_INSTANCE -r ROUTE_SERVICE_URL`
  `cf bind-route-service DOMAIN SERVICE_INSTANCE [--hostname HOSTNAME]`
  
  **Advantages:**
  
  