Add SNI support in release notes for 0.8 (#1389)

* Add SNI support in release notes for 0.8

* Add SNI support in release notes for 0.8

* Add SNI support in release notes for 0.8

* Removed TBD.

* envoy apis

content/about/notes/0.8.md

@@ -14,13 +14,17 @@ This model adds many new features and addresses usability issues
 with the prior model. There is a conversion tool built into `istioctl` to help migrate your config from
 the old model. [Try out the new traffic management model](/docs/tasks/traffic-management).
 
-- **Envoy V2**. Users can choose to inject Envoy V2 as the sidecar. In this mode, Pilot uses Envoy's new API to push configuration to the data plane. This new approach
-increases effective scalability and should eliminate spurious 404 errors. [TBD: docs on how to control this?]
-
 - **Gateway for Ingress/Egress**. We no longer support combining Kubernetes Ingress specs with Istio route rules,
 as it has led to several bugs and reliability issues. Istio now supports a platform independent ingress/egress
 [Gateway](/docs/concepts/traffic-management/rules-configuration/#gateways) that works across
-Kubernetes and Cloud Foundry and works seamlessly with the routing rules.
+Kubernetes and Cloud Foundry and integrates seamlessly with the routing rules.
+
+- **The new Gateway supports [Server Name Indication](https://en.wikipedia.org/wiki/Server_Name_Indication)** based routing,
+as well as serving a certificate based on the SNI value. HTTPS access to external services will be auto configured based on SNI.
+
+- **Envoy v2 APIs**. Users can choose to inject a sidecar using Envoy's v2 APIs. In this mode, Pilot uses [Envoy's v2 Aggregated Discovery Service
+API](https://www.envoyproxy.io/docs/envoy/latest/configuration/overview/v2_overview) to push configuration to the data plane.
+This new approach increases scalability of the control plane.
 
 - **Constrained Inbound Ports**. We now restrict the inbound ports in a pod to the ones declared by the apps running inside that pod.