anchor.diff:      - destination:
         host: reviews
         subset: v2
  -  - route:
  -    - destination:
  -      host: reviews
  -      subset: v3
  -EOF
  -----
  -
  -[id="ossm-routing-config-v-host_{context}"]
  -== Configuring your virtual host
  -
  -The following sections explain each field in the YAML file and explain how you can create a virtual host in a virtual service.
  -
  -[id="ossm-routing-hosts_{context}"]
  -=== Hosts
  -
  -The `hosts` field lists the virtual service’s user-addressable destination that these routing rules apply to. This is the address or addresses the client uses when sending requests to the service.
  -
  -The virtual service hostname can be an IP address, a DNS name, or, depending on the platform, a short name that resolves to a fully qualified domain name.
  -
  -[source,yaml]
  -----
  -spec:
  -  hosts:
  -  - reviews
  -----
  -
  -[id="ossm-routing-routing-rules_{context}"]
  -=== Routing rules 
  -
  -The `http` section contains the virtual service’s routing rules, describing match conditions and actions for routing HTTP/1.1, HTTP2, and gRPC traffic sent to the destination specified in the hosts field. A routing rule consists of the destination where you want the traffic to go and zero or more match conditions, depending on your use case.
  -
  -.Match condition
  -
  -The first routing rule in the example has a condition and begins with the match field. In this example, this routing applies to all requests from the user `jason`. Add the `headers`, `end-user`, and `exact` fields to select the appropriate requests.
  -
  -[source,yaml]
  -----
  -spec:
  -  hosts:
  -  - reviews
  -  http:
  -  - match:
  -    - headers:
  -      end-user:
  -        exact: jason
  -----
  -
  -.Destination
  -
  -The `destination` field in the route section specifies the actual destination for traffic that matches this condition. Unlike the virtual service’s host, the destination’s host must be a real destination that exists in the {ProductName} service registry. This can be a mesh service with proxies or a non-mesh service added using a service entry. In this example, the host name is a Kubernetes service name:
  -
  -[source,yaml]
  -----
  -spec:
  -  hosts:
  -  - reviews
  -  http:
  -  - match:
  -    - headers:
  -      end-user:
  -        exact: jason
  -    route:
  -    - destination:
  -      host: reviews
  -      subset: v2
   ----
   
   [id="ossm-routing-dr_{context}"]
   === Destination rules
   
  -Destination rules are applied after virtual service routing rules are evaluated, so they apply to the traffic’s real destination. Virtual services route traffic to a destination. Destination rules configure what happens to traffic at that destination. 
  +Destination rules are applied after virtual service routing rules are evaluated, so they apply to the traffic’s real destination. Virtual services route traffic to a destination. Destination rules configure what happens to traffic at that destination.
   
   [id="ossm-routing-lb_{context}"]
  -==== Load balancing options 
  +==== Load balancing options
   
   By default, {ProductName} uses a round-robin load balancing policy, where each service instance in the instance pool gets a request in turn. {ProductName} also supports the following models, which you can specify in destination rules for requests to a particular service or service subset.
   
  
positive.code: kind: VirtualService
  metadata:
    name: reviews
  spec:
    hosts:
    - reviews
  
negative.code: [id="ossm-routing_{context}"]
  = Routing and managing traffic
  
  Configure your service mesh by adding your own traffic configuration to {ProductName} with a custom resource definitions in a YAML file.
  
  [id="ossm-routing-traffic-management-vs_{context}"]
  == Traffic management with virtual services
  
  You can route requests dynamically to multiple versions of a microservice through {ProductName} with a virtual service. With virtual services, you can:
  
  * Address multiple application services through a single virtual service. If your mesh uses Kubernetes, for example, you can configure a virtual service to handle all services in a specific namespace. Mapping a single virtual service to many services is particularly useful in facilitating turning a monolithic application into a composite service built out of distinct microservices without requiring the consumers of the service to adapt to the transition.
  * Configure traffic rules in combination with gateways to control ingress and egress traffic.
  
  [id="ossm-routing-vs_{context}"]
  