mass sed (#448)

_docs/concepts/network-and-auth/auth.md

@@ -55,7 +55,7 @@ When running on Kubernetes, Istio Auth uses [Kubernetes service accounts](https:
 
 ### Communication security
 
-Service-to-service communication is tunneled through the client side [Envoy](https://lyft.github.io/envoy/) and the server side Envoy. End-to-end communication is secured by:
+Service-to-service communication is tunneled through the client side [Envoy](https://envoyproxy.github.io/envoy/) and the server side Envoy. End-to-end communication is secured by:
 
 
 

_docs/concepts/traffic-management/load-balancing.md

@@ -31,7 +31,7 @@ As illustrated in the figure above, services in the mesh access each other
 using their DNS names. All HTTP traffic bound to a service is automatically
 re-routed through Envoy. Envoy distributes the traffic across instances in
 the load balancing pool. While Envoy supports several
-[sophisticated load balancing algorithms](https://lyft.github.io/envoy/docs/intro/arch_overview/load_balancing.html),
+[sophisticated load balancing algorithms](https://envoyproxy.github.io/envoy/intro/arch_overview/load_balancing.html),
 Istio currently allows three load balancing modes:
 round robin, random, and weighted least request.
 

_docs/concepts/traffic-management/pilot.md

@@ -24,9 +24,9 @@ resources, and third party resources that store traffic management rules.
 This data is translated into the canonical representation. Envoy-specific
 configuration is generated based on the canonical representation.
 
-Pilot exposes APIs for [service discovery](https://lyft.github.io/envoy/docs/configuration/cluster_manager/sds_api.html),
-dynamic updates to [load balancing pools](https://lyft.github.io/envoy/docs/configuration/cluster_manager/cds.html)
-and [routing tables](https://lyft.github.io/envoy/docs/configuration/http_conn_man/rds.html).
+Pilot exposes APIs for [service discovery](https://envoyproxy.github.io/envoy/configuration/cluster_manager/sds_api.html),
+dynamic updates to [load balancing pools](https://envoyproxy.github.io/envoy/configuration/cluster_manager/cds.html)
+and [routing tables](https://envoyproxy.github.io/envoy/configuration/http_conn_man/rds.html).
 These APIs decouple Envoy from platform-specific nuances, simplifying the
 design and increasing portability across platforms.
 

_docs/concepts/what-is-istio/overview.md

@@ -65,7 +65,7 @@ The following diagram shows the different components that make up each plane:
 
 ### Envoy
 
-Istio uses an extended version of the [Envoy](https://lyft.github.io/envoy/) proxy, a high-performance proxy developed in C++, to mediate all inbound and outbound traffic for all services in the service mesh. 
+Istio uses an extended version of the [Envoy](https://envoyproxy.github.io/envoy/) proxy, a high-performance proxy developed in C++, to mediate all inbound and outbound traffic for all services in the service mesh. 
 Istio leverages Envoy’s many built-in features such as dynamic service discovery, load balancing, TLS termination, HTTP/2 & gRPC proxying, circuit breakers,
 health checks, staged rollouts with %-based traffic split, fault injection, and rich metrics.
 

_docs/reference/config/traffic-rules/destination-policies.md

@@ -103,7 +103,7 @@ service version indicated in the destination policy.
 ### LoadBalancing
 Load balancing policy to use when forwarding traffic. These policies
 directly correlate to [load balancer
-types](https://lyft.github.io/envoy/docs/intro/arch_overview/load_balancing.html)
+types](https://envoyproxy.github.io/envoy/intro/arch_overview/load_balancing.html)
 supported by Envoy. Example,
 
 
@@ -160,8 +160,8 @@ implementation is fine-grained in that it tracks the success/failure
 rates of individual hosts in the load balancing pool. Hosts that
 continually return errors for API calls are ejected from the pool for a
 pre-defined period of time. See Envoy's 
-[circuit breaker](https://lyft.github.io/envoy/docs/intro/arch_overview/circuit_breaking.html) 
-and [outlier detection](https://lyft.github.io/envoy/docs/intro/arch_overview/outlier.html)
+[circuit breaker](https://envoyproxy.github.io/envoy/intro/arch_overview/circuit_breaking.html) 
+and [outlier detection](https://envoyproxy.github.io/envoy/intro/arch_overview/outlier.html)
 for more details.
 
 <table>

_faq/where-is-the-documentation.md

@@ -13,7 +13,7 @@ and the [complete reference documentation]({{home}}/docs/reference/).
 
 Detailed developer-level documentation is maintained for each component in GitHub, alongside the code. Please visit each repository for those docs:
 
-*   [Envoy](https://lyft.github.io/envoy/docs/)
+*   [Envoy](https://envoyproxy.github.io/envoy/)
 
 *   [Pilot](https://github.com/istio/pilot/tree/master/doc)
 

_glossary/envoy.md

@@ -3,4 +3,4 @@ title: Envoy
 type: markdown
 ---
 Envoy is the high-performance proxy that Istio uses to mediate all inbound and outbound traffic for all services in the service mesh. 
-Learn more about Envoy [here](https://lyft.github.io/envoy/).
+Learn more about Envoy [here](https://envoyproxy.github.io/envoy/).

_posts/2017-05-24-0.1-announcement.md

@@ -10,7 +10,7 @@ redirect_from: "/blog/0.1-announcement.html"
 ---
 
 Google, IBM, and Lyft are proud to announce the first public release of [Istio](https://istio.io/): an open source project that provides a uniform way to connect, secure, manage and monitor microservices. Our current release is targeted at the [Kubernetes](https://kubernetes.io/) environment; we intend to add support for other environments such as virtual machines and Cloud Foundry in the coming months.
-Istio adds traffic management to microservices and creates a basis for value-add capabilities like security, monitoring, routing, connectivity management and policy.  The software is built using the battle-tested [Envoy](https://lyft.github.io/envoy/) proxy from Lyft, and gives visibility and control over traffic *without requiring any changes to application code*. Istio gives CIOs a powerful tool to enforce security, policy and compliance requirements across the enterprise.
+Istio adds traffic management to microservices and creates a basis for value-add capabilities like security, monitoring, routing, connectivity management and policy.  The software is built using the battle-tested [Envoy](https://envoyproxy.github.io/envoy/) proxy from Lyft, and gives visibility and control over traffic *without requiring any changes to application code*. Istio gives CIOs a powerful tool to enforce security, policy and compliance requirements across the enterprise.
 
 <!--end_excerpt-->
 

_posts/2017-05-25-0.1-auth.md

@@ -63,7 +63,7 @@ Istio Auth uses [Kubernetes service accounts](https://kubernetes.io/docs/tasks/c
 
 ### Communication Security
 
-Service-to-service communication is tunneled through high performance client side and server side [Envoy](https://lyft.github.io/envoy/) proxies. The communication between the proxies is secured using mutual TLS. The benefit of using mutual TLS is that the service identity is not expressed as a bearer token that can be stolen or replayed from another source. Istio Auth also introduces the concept of Secure Naming to protect from a server spoofing attacks - the client side proxy verifies that the authenticated server's service account is allowed to run the named service. 
+Service-to-service communication is tunneled through high performance client side and server side [Envoy](https://envoyproxy.github.io/envoy/) proxies. The communication between the proxies is secured using mutual TLS. The benefit of using mutual TLS is that the service identity is not expressed as a bearer token that can be stolen or replayed from another source. Istio Auth also introduces the concept of Secure Naming to protect from a server spoofing attacks - the client side proxy verifies that the authenticated server's service account is allowed to run the named service. 
 
 ### Key Management and Distribution
 

_posts/2017-08-10-0.1-using-network-policy.md

@@ -30,7 +30,7 @@ In contrast, operating at the network layer has the advantage of being universal
 
 ## Implementation
 
-The Istio’s proxy is based on [Envoy](https://lyft.github.io/envoy/), which is implemented as a userspace daemon in the dataplane that interacts with the network layer using standard sockets. This gives it a large amount of flexibility in processing, and allows it to be distributed (and upgraded!) in a container.
+The Istio’s proxy is based on [Envoy](https://envoyproxy.github.io/envoy/), which is implemented as a userspace daemon in the dataplane that interacts with the network layer using standard sockets. This gives it a large amount of flexibility in processing, and allows it to be distributed (and upgraded!) in a container.
 
 Network Policy dataplane is typically implemented in kernel space (e.g. using iptables, eBPF filters, or even custom kernel modules). Being in kernel space allows them to be extremely fast, but not as flexible as the Envoy proxy.
 
@@ -77,7 +77,7 @@ spec:
     istio: ingress
 ```
 
-The istio-ingress exposes ports 80 and 443.  Let’s limit incoming traffic to just these two ports.  Envoy has a [built-in administrative interface](https://lyft.github.io/envoy/docs/operations/admin.html#operations-admin-interface), and we don’t want a misconfigured istio-ingress image to accidentally expose our admin interface to the outside world.  This is an example of defense in depth: a properly configured image should not expose the interface, and a properly configured Network Policy will prevent anyone from connecting to it.  Either can fail or be misconfigured and we are still protected.
+The istio-ingress exposes ports 80 and 443.  Let’s limit incoming traffic to just these two ports.  Envoy has a [built-in administrative interface](https://envoyproxy.github.io/envoy/operations/admin.html#operations-admin-interface), and we don’t want a misconfigured istio-ingress image to accidentally expose our admin interface to the outside world.  This is an example of defense in depth: a properly configured image should not expose the interface, and a properly configured Network Policy will prevent anyone from connecting to it.  Either can fail or be misconfigured and we are still protected.
 
 ```yaml
 apiVersion: networking.k8s.io/v1