update architecture image. Add images for service model

_docs/concepts/service-model.md

@@ -29,10 +29,13 @@ additional control over traffic between services.
 
 ## Communication between services
 
-Clients of a service have no knowledge of different versions of the
-service. They can continue to access the services using the hostname/IP
-address of the service. Envoy sidecar/proxy intercepts and forwards all
-requests/responses between the client and the service.
+<img class="col-sm-5 landing-image-small" src="./img/manager/ServiceModel_Versions.svg" alt="Istio service model - service versions." />
+
+As illustrated in the figure above, clients of a service have no knowledge
+of different versions of the service. They can continue to access the
+services using the hostname/IP address of the service. Envoy sidecar/proxy
+intercepts and forwards all requests/responses between the client and the
+service.
 
 The actual choice of the service version is determined dynamically by Envoy
 based on the routing rules set forth by the operator. This model enables
@@ -46,5 +49,15 @@ Note that Istio does not provide a DNS. Applications can try to resolve the
 FQDN using the DNS service present in the underlying platform (kube-dns,
 mesos-dns, etc.).
 
+## Ingress and Egress Envoys
 
+Istio assumes that all traffic entering and leaving the istio service mesh
+transits through Envoy proxies. By deploying the Envoy proxy in front of
+services, operators can conduct A/B testing, deploy canary services,
+etc. for user-facing services. Similarly, by routing traffic to external
+web services (e.g., accessing Maps API, or a video service API) via Envoy,
+operators can add failure recovery features such as circuit breakers,
+impose rate limits via the Mixer, and provide authentication using
+Istio-Auth service.
 
+<img src="./img/manager/ServiceModel_RequestFlow.svg" alt="Istio service model - ingress and egress Envoy." />